tendermint / tendermint

⟁ Tendermint Core (BFT Consensus) in Go
https://tendermint.com/
Apache License 2.0
5.72k stars 2.07k forks source link

[docs] explain different create_empty_blocks configurations better #3307

Closed jstuczyn closed 5 years ago

jstuczyn commented 5 years ago

Tendermint version: 0.27.4-1e1ca15b + also tried 0.30.0-28d75ec8 ABCI app: not really applicable, but persists on both kvstore and a self-built one OS: Ubuntu 18.04.1

Hi!

I've been trying to increase the minimum time between blocks being created, however, I've repeatedly failed to achieve this. From what I've figured from the documentation (on related note: there is a very limited information regarding the matter), I've tried increasing blocktime_iota = "10s", but this doesn't seem to have changed anything. Then for the test sake I've tried to increase all consensus timeouts tenfolds to see whether there would be any increase in time between blocks:

timeout_propose = "30s"
timeout_propose_delta = "5000ms"
timeout_prevote = "10s"
timeout_prevote_delta = "5000ms"
timeout_precommit = "10s"
timeout_precommit_delta = "5000ms"
timeout_commit = "10s"

But that seems to have only affected the initial blocks written upon genesis:

I[2019-02-13|13:02:17.416] Version info                                 module=main software=0.30.0 block=10 p2p=7
I[2019-02-13|13:02:17.437] Starting Node                                module=main impl=Node
E[2019-02-13|13:02:17.437] Couldn't connect to any seeds                module=p2p 
I[2019-02-13|13:02:17.440] Started node                                 module=main nodeInfo="{ProtocolVersion:{P2P:7 Block:10 App:1} ID_:bfd203973e22de188c505a949210d827ac9a1b87 ListenAddr:tcp://0.0.0.0:26656 Network:test-chain-Cpss48-SINGLE Version:0.30.0 Channels:4020212223303800 Moniker:testingNode Other:{TxIndex:on RPCAddress:tcp://0.0.0.0:26657}}"
I[2019-02-13|13:02:27.458] Executed block                               module=state height=1 validTxs=0 invalidTxs=0
I[2019-02-13|13:02:27.460] Committed state                              module=state height=1 txs=0 appHash=0000000000000000
I[2019-02-13|13:02:37.475] Executed block                               module=state height=2 validTxs=0 invalidTxs=0
I[2019-02-13|13:02:37.478] Committed state                              module=state height=2 txs=0 appHash=0000000000000000

When sending the 'regular' transactions, that delay seem to be unaffected:

I[2019-02-13|13:03:10.909] Executed block                               module=state height=3 validTxs=1 invalidTxs=0
I[2019-02-13|13:03:10.910] Committed state                              module=state height=3 txs=1 appHash=0200000000000000
I[2019-02-13|13:03:10.926] Executed block                               module=state height=4 validTxs=1 invalidTxs=0
I[2019-02-13|13:03:10.927] Committed state                              module=state height=4 txs=1 appHash=0400000000000000
I[2019-02-13|13:03:10.939] Executed block                               module=state height=5 validTxs=1 invalidTxs=0
I[2019-02-13|13:03:10.940] Committed state                              module=state height=5 txs=1 appHash=0600000000000000
E[2019-02-13|13:03:17.438] Couldn't connect to any seeds                module=p2p 
I[2019-02-13|13:03:20.960] Executed block                               module=state height=6 validTxs=0 invalidTxs=0
I[2019-02-13|13:03:20.962] Committed state                              module=state height=6 txs=0 appHash=0600000000000000

I've expected block at height=4 to be created no sonner than 13:03:20.909 and contain two Txs (that were commited at height 4 and 5). I also expected block at height=5 to not have been created since block at height=4 should have contained that transaction. I'm not 100% sure why the block at height=6 is created, but I think it might be the same cause as in issue #1783. But regardless, that one seems to have the correct delay...

I'm not entirely sure whether it is an actual bug or simply the case of user (myself) configuring the node(s) incorrectly. But if it's the latter, I've literally searched through entire docs as well as the issue tracker and could not figure it out by myself.

I will appreciate any advice Thanks!

melekes commented 5 years ago

create_empty_blocks=true

If you have create_empty_blocks=true in your config, blocks will be created ~ every 1s (with default consensus params which are explained here https://forum.cosmos.network/t/consensus-timeouts-explained/1421). You can regulate the delay between blocks by changing the timeout_commit. E.g. timeout_commit = "10s" should result in ~10s blocks.

create_empty_blocks=false

In this setting, blocks are created when txs received. Note after the block N, Tendermint creates something we call a "proof block" (if the app hash changes) N+1 https://github.com/tendermint/tendermint/issues/2487#issuecomment-424899799. Plus, if you set create_empty_blocks_interval to something other than the default, Tendermint will be creating empty blocks even in the absence of transactions every create_empty_blocks_interval.

Hope that helps! We'll try to improve the docs 📜

jstuczyn commented 5 years ago

Allowing Tendermint to create empty blocks and only modifying timeout_commit did the trick! In retrospect it makes sense, because otherwise without regular empty blocks it'd be difficult to sync and have the proper delay between blocks with txs... Anyway, my issue is solved, thanks! However, just from pure curiosity, what is the intended purpose of blocktime_iota?

melekes commented 5 years ago

blocktime_iota - minimum time between two consecutive blocks.

melekes commented 5 years ago

Done in #3349.