-
Notifications
You must be signed in to change notification settings - Fork 367
Investigate consensus steps timeouts #87
Copy link
Copy link
Closed
Labels
C:consensusrelated to the core consensusrelated to the core consensusC:data-availabilityComponent: Data Availability ProofsComponent: Data Availability ProofsC:minimal-executionParts that require on-chain execution (i.e. via the cosmos-sdk)Parts that require on-chain execution (i.e. via the cosmos-sdk)T:investigateFurther investigation neededFurther investigation needed
Metadata
Metadata
Assignees
Labels
C:consensusrelated to the core consensusrelated to the core consensusC:data-availabilityComponent: Data Availability ProofsComponent: Data Availability ProofsC:minimal-executionParts that require on-chain execution (i.e. via the cosmos-sdk)Parts that require on-chain execution (i.e. via the cosmos-sdk)T:investigateFurther investigation neededFurther investigation needed
We will have to experiment with block times and tendermint consensus related timeout to find a reasonable middle ground.
Update: Increasing the timeouts is no longer relevant but what we instead really we want is: tendermint/tendermint#5911
We should help the tendermint team to get that feature shipped.
The current default timeouts can be found here:
https://github.com/lazyledger/lazyledger-core/blob/b68e2dc394c0fc1840d57b1a763c77c1ef7a13cd/config/config.go#L869-L874
For immediate execution, we might need to increase
TimeoutProposeas a proposer would need to execute Tx against the state before proposing. Also, we'd like the block data to propagate through the p2p network (reaching at least some storage nodes (ref: celestiaorg/celestia-specs#3).Also we likely would need to increase the(this is no longer planned)TimeoutPrevoteto allow validators to validate blocks via DA proofs (see #65).We could start with the current defaults and experiment our way up to defaults where consensus nodes don't end up timing out and starting new rounds without making blocks.
ref: tendermint/tendermint#5911