Substrate and Polkadot Stack Exchange is a question and answer site for developers building blockchains with the Substrate SDK. It only takes a minute to sign up.
Sign up to join this community
In Substrate-based blockchains like substrate_node-template, blocks are being produced in a continuous manner, even during periods of inactivity when no active transactions are taking place. Ideally, new blocks should only be generated when transactions are actively initiated or created.
The ongoing creation of blocks, regardless of transaction activity, raises concerns about perpetual block generation and the potential for memory limitations to arise.
The substrate-node-template uses Aura for block authoring. In Aura time is divided up into "slots" of a fixed length. During each slot one block is produced, and the authorities take turns producing blocks in order forever.
In Aura, forks only happen when it takes longer than the slot duration for a block to traverse the network. Thus forks are uncommon in good network conditions.
Because Substrate provides a modular framework for building blockchains it is possible to build a custom consensus model.
And example of what you want to implement is Substrate contracts node, that uses Instant seal.
With Instant Seal, the node will automatically authorise the block the second it gets a transaction. It will not create the empty blocks on the chain.
As an example of how to migrate from Aura & Grandpa (What node-template uses) to use instant-seal you can take a look in this PR on the Substrate Contracts Node: Changed consensus to manual-seal
You can read more about Consensus System in Substrate Docs and specifically the node-template in this StackExchange question: What are current and finalized blocks in the substrate blockchain node template?.
Substrate-based blockchains like the substrate_node-template consistently generate blocks, even during periods of inactivity, due to their utilization of slot-based consensus mechanisms such as Aura or Babe. In these systems, time is divided into distinct slots, each designated for a validator responsible for producing a block. Regardless of whether the block contains transactions, it is imperative for the validator to create a block within the slot. Failure to do so could result in a wasted slot and potential forks, driven by other nodes suspecting malicious actions like intentional network delays.
The continuous block production also serves to uphold network liveness, assuring observers that the network remains operational and dynamic. This analogy can be likened to a conventional server that remains active to field incoming requests, even in the absence of ongoing demands. Comparable to serverless setups that can scale down to zero but still maintain an accessible API for requests, the unceasing block generation guarantees the network's liveliness, availability, and effectively showcases the network's correctness.
