On using Instantseal on a public standalone network

Question

What are the ramifications of using InstantSeal on a public standalone chain? According to the comments on How to reject empty blocks?, it's quite evident that babe/aura based chains require blocks to be produced in the current epoch, however it is also fact that many chains simply don't see their bandwidth being used and most blocks are empty, taking up unnecessary space on disk.

As a consequence, it would be desirable to have a combination of instant seal/epoch based consensus, where let's say hypothetically, it's not just blocks that get produced when the network meets a transaction, but an entire epoch/era that gets triggered. Then the network can start and run through an entire era, until it again goes to sleep, where it waits for a transaction to occur, thus saving disk/network/cpu resources.

I'd like to know why would this work or won't work. Is there something I am missing about the way block production algorithms like babe/aura?

Answer 1

The goal of only producing blocks when a block is needed makes sense. This is similar to how parathreads will behave on Polkadot. You will most likely need to write your own consensus logic to achieve this in a production-ready manner.

At minimum, you will need to write logic to reject empty blocks as instant seal does not currently do this. While it's true that instant seal only authors blocks when it has a transaction to include, it still needs to reject blocks authored by other potentially-malicious nodes, and it does not do this.

Instant seal, as it is written in Substrate today, allows anyone to produce a block at any time. Practically speaking, you will also need to throttle block production in some way so that a malicious user does not spam the network with trivial blocks. I can think of two ways that might work.

1. Use some kind of PoA or PoS scheme to restrict authors so that only certain trusted or staked accounts can author. This makes it similar to Aura.
2. Make transaction fees high enough to account for the overhead of importing an entire block. This is higher than the typical fees that are just for including a transaction in a block.