Feature for consensus mechanism for avoiding empty blocks

[vncoelho]

There are two points to be discussed here:

1. Create the mechanism for, at least, guiding the consensus for not generating empty blocks on private nets
2. Discuss if empty blocks are really useful for NEO Mainnet. I believe that since NEO is strict one-block finality we could discuss if empty blocks are useful. On the other hand, I believe that with the amount of DApps and use of NEO and GAS that we currently have, empty blocks will also not be very common (even when thinking about 5s blocks as proposed in Decrease block time to 5 sec #375).

By avoiding the generation of empty blocks the possible results are:

• Users, exchange, among others start to send "watch-only" transactions for ensuring that a block will be published within the expected minimum block time;
• One-block finality will be more spread among other projects, which will start to see that for NEO txs there is no need to really wait for more than 1 block.

Regarding the first point, recently we had another good discussion, with @igormcoelho and other guys from other Blockchain projects (such as Ethereum), regarding failing tx's that does not modify storage.
But, in general, I think that there is no problem, NEO economic model is different.
If someone wants to pay for registering a call I do not see a problem, sys_fees should be consistent and provide the expected distribution.

[lock9]

This is very important, we don't need empty blocks. Any chance this could break the current code?

[vncoelho]

Current it would not break the code. In fact, it would be a simply modification on the Consensus side.

However, we would need a better formula for GAS (perhaps, in terms of time and not blocks).
This is something that @erikzhang would need to discuss with careful with @dahongfei.

I do not know for sure, @lock9, it is just an idea. While there might be benefits there might be consequences out of my control.

In general, I support it, otherwise I would not take time of everybody to discuss that. I believe it would be good in long term.
But this insight can be wrong and keep generation based on blocks might still be the best way to produce the remaining GAS.

[shargon]

If you don't allow empty blocks, you must remove the threshold timestamp between blocks, and if you remove this, one CN could send a block with one year more than expected, and the next blocks, will wait for be validated one year.

[lock9]

@shargon what if we have a limit of 15 seconds? If 15 seconds passes, we generate an empty block, but for 5 seconds interval, we only generate the block if there is data.

So:
A block every 5 seconds, if there are transactions OR, if no transactions, a block every 15 seconds.
What do you think?

[uvmetal]

OOps. I bungled some math. cringe

[shargon]

I like it, 5 blocks if there are tx, and 15 if there are not. good @lock9 , but hard to implement in consensus...

[lock9]

@shargon I guess this is not my problem? 😂

@vncoelho what is your opinion? Do you think it is possible to have a block every 5 seconds, only if we have data?
@igormcoelho you mentioned something about keeping the "current state shared". Do you think we could use this strategy to have "blocks every 5 seconds", that are not actually "blocks"? Like one block every 15 seconds, but every 5, if there is data, there is a "state agreement"?
Maybe it is not possible... we will need a whole block structure every 5 seconds, right?

[shargon]

also "unpredictable" time, is not a good idea, because you can't stimate times according to block numbers

[txhsl]

@lock9 That's a little bit like the vBFT in Ontology. But in Neo, the CNs generate blocks in a fixed sequence instead of randomly, which will result in a problem in the reward of GAS.
@vncoelho Removing empty blocks will also cause the same issue unless that rule of sequence is changed. 🤔

[vncoelho]

@neo-project/core, some people are asking for this feature for privatenets.

@devhawk, for example, commented about a feature for triggering consensus when running a smart contract (perhaps, something related to when transactions arrives in the mempool).

I believe that the best way to design this is as a plugin, which will not affect any configuration for normal use.
Perhaps we already have all the ingredients for pushing this plugin.
For example, the feature mentioned by @devhawk, could be a plugin that triggers consensus every time there are >= X Transactions in the mempool.