Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lower the empty block creation interval #102

Open
RiccardoM opened this issue Feb 20, 2020 · 1 comment
Open

Lower the empty block creation interval #102

RiccardoM opened this issue Feb 20, 2020 · 1 comment
Labels
kind/enhancement Enhance an already existing feature; no "New feature" to add status/waiting-upstream This issue is waiting for a dependency to be updated in order to be worked on

Comments

@RiccardoM
Copy link
Contributor

Context

Currently inside Desmos we have the following Tendermint consensus params set:

  • create_empty_blocks: true
  • create_empty_blocks_interval: 0s
  • timeout_commit: 1s
  • timeout_propose: 3s
  • peer_gossip_sleep_duration: 100ms

This has lead the chain to produce a lot of empty blocks at the current rate of 1 every 5-6 seconds, causing new validators to take up to 6 hours to completely sync the node the first time they start it up.

While empty blocks are used to tell the chain has not stopped (its the only meaning they have), I really think that this should be addressed in some way.

After @kwunyeung told me e-Money have been able to create a 1-minute-heartbeat system, I've browsed through their code and seen that they have set the following parameters instead:

  • create_empty_blocks: false
  • create_empty_blocks_interval: 60s
  • timeout_commit: 500ms
  • timeout_propose: 2s
  • peer_gossip_sleep_duration: 25ms

This code can be found inside e-Money's cmd main.go file.

As @kwunyeung said, they are setting all the other parameters as the create_empty_blocks might not work now (but Ethan Frey should have pointed this out already). To fix these they are using all the other 4 to make all the nodes act the same way, effectively lowering the production of empty blocks.

@kwunyeung also said IOV has managed to do a similar thing but with a 5 minutes heartbeat instead.

What I think we should do is implement a 2 minutes heartbeat, as I think we will have enough transactions in any case in the future, and lowering this amount could affect the calculations of slashing and block rewards which are currently based on block height, as @kwunyeung said too.

What are your thoughts @kwunyeung @bragaz?

CC @angelorc

@RiccardoM RiccardoM added the kind/enhancement Enhance an already existing feature; no "New feature" to add label Feb 20, 2020
@RiccardoM RiccardoM added this to the v0.4.0 milestone Feb 20, 2020
@kwunyeung
Copy link
Contributor

The default behaviour create_empty_block = false of Tendermint is to have block committed immediately when there is tx. Otherwise, it will just keep waiting unless the create_empty_block_interval is not 0 as we need the H+1 block as a proof of block H.

https://github.com/tendermint/tendermint/blob/15e80d244886768e9813ce9d4b7d4c9c19471d83/docs/tendermint-core/configuration.md#empty-blocks-vs-no-empty-blocks

It works well in the early time that I built a simple test app directly with Tendermint.

I have tested it few months ago after Ethan Frey had submitted the fix but it didn't work with distribution and slashing modules. This should be because with these two modules, the states of rewards and signing info in slashing keeps updating in endblock and the states changed, application hash changed and the H+1 proof block keeps creating even if there is no tx.

IOV is different because Ethan Frey didn't build it with Cosmos SDK. He built another SDK called weave which keeps the feature of create_empty_block as they don't have slashing and reward calculations.

I think it won't work as expected unless the entire distribution and slashing calculations can be replaced by consensus timestamp instead of height.

@RiccardoM RiccardoM modified the milestones: v0.4.0, v0.5.0 Mar 10, 2020
@RiccardoM RiccardoM removed this from the v0.5.0 milestone Apr 25, 2020
@RiccardoM RiccardoM added status/on-hold This issue is temporarily suspended status/waiting-upstream This issue is waiting for a dependency to be updated in order to be worked on and removed status/on-hold This issue is temporarily suspended labels Jul 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Enhance an already existing feature; no "New feature" to add status/waiting-upstream This issue is waiting for a dependency to be updated in order to be worked on
Projects
None yet
Development

No branches or pull requests

2 participants