Conversation
Add documentation for Tempo's consensus mechanism: - Simplex BFT via Commonware - Deterministic sub-second finality - Validator fault tolerance (up to 1/3 Byzantine) - Distributed validation vs single sequencer - Degraded state behavior - Integrator guidance for finality
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
|
||
| ### Block Production | ||
|
|
||
| Blocks are produced approximately every 0.5 seconds under normal network conditions. Proposer selection follows a round-robin pattern among active validators. Once a block is finalized, it cannot be reverted. |
There was a problem hiding this comment.
Blocks are produced approximately every 0.5
0.5 is an absolute lower bound, which is not reachable in practice because we only interrupt our builder loop after 500ms - if you then add network latencies + block validation this number is pushed up. I think a more realistic number is 600ms, but we still have to benchmark this with validators that are not all running in the same datacenter.
round-robin
We use a VRF for leader selection, so this is random (and offers DoS protection/MEV games).
SuperFluffy
left a comment
There was a problem hiding this comment.
Looks good except for the things I have mentioned.
Could add these links for folks who are interested in reading more:
Commonware simplex: https://docs.rs/commonware-consensus/0.0.65/commonware_consensus/simplex/
Section on simplex with bls12381 threshold scheme: https://docs.rs/commonware-consensus/0.0.65/commonware_consensus/simplex/index.html#schemebls12381_threshold
- Change block time from 0.5s to ~600ms (more realistic with network latency) - Replace round-robin with VRF-based random leader selection - Add Further Reading section with Commonware Simplex docs links
docs: add GitHub URLs for predeployed contracts in Lento testnet
Adds a new Consensus and Finality documentation page under the Blockspace section.
Content
This addresses documentation gaps identified when preparing RFP responses.