Tendermint: No empty blocks

[ebuchman]

It would be nice if Tendermint didn't spam us with empty blocks,
but changing the protocol to support this is non-trivial. If we simply prevoted nil on empty blocks, or didn't propose them at all, and went to the next round, the TimeoutPropose would increase, so we'd be risking downtime if a proposer at a high round is down and we have to wait a while to skip him.

Instead, we might be able to do this by adding two new fields to the block header:

• emptyBlockNum (int64)
• lastNonEmptyBlockHash ([]byte)

Thus a block would be indexed by the pair (height, emptyBlockNum), and we would only display blocks for users with (height, 0), as those would be the only ones with transactions. Blocks which increment the emptyBlockNum are like virtual blocks that ensure we have consensus on moving to the next proposer and not increasing the timeout, despite not wanting to tell the user about a block.

By including the lastNonEmptyBlockHash, clients doing fast sync (verifying chain of headers) can skip all the empty blocks for catching up.

Related: https://github.com/tendermint/tendermint/issues/230

[uhrobots]

I think this is an interesting idea, however, I'm interested in the impact of empty blocks on the size of the chain as that's my primary concern.

[mappum]

:+1: This could be a huge optimization, although it mostly applies to chains which aren't being used much. But it would be worth it even just for working with test chains while debugging.

[ryansealy]

Please don't discount the value of using Tendermint for smaller blockchains that have a lot of idle time. At least in my case, Tendermint's greatest strength is its decoupling of the application logic from the consensus engine, which facilitates creation of various ad-hoc chains. These chains might be 99.9+% empty blocks, that combined with logs, chews up tons of drive space. And over days, months, years, the amount of utilized drive space becomes ridiculous considering the chain is almost totally empty.

This is a huge deal for me in a production environment, and likely is so for many others as well.

Sure it's annoying to see the height increment every second, but who really who cares what value we assign to height? An empty virtual block as proposed seems promising. The real need is in

1. skipping empty blocks on replay / catchup and
2. keeping the tendermint data folder growth in check while the chain sits idle

[zramsay]

closed in #584