[dip-213] decoupled execution#214
Conversation
dahliamalkhi
left a comment
There was a problem hiding this comment.
wonderful proposal! see stylistic/clarification comments inline.
| To prevent consensus going too fast and create ever-growing backlog for other stages, back pressure is implemented to stop consensus making progress if the difference between committed block and ordered block is large. | ||
|
|
||
| ## Reconfiguration | ||
| A reconfiguration transaction is the last transaction of an epoch. Execution recognizes this type of transaction and buffer manager would stop processing any blocks after the reconfiguration block. |
There was a problem hiding this comment.
| A reconfiguration transaction is the last transaction of an epoch. Execution recognizes this type of transaction and buffer manager would stop processing any blocks after the reconfiguration block. | |
| Recall that a reconfiguration transaction must be the last transaction of an epoch. Execution recognizes this type of transaction and BufferManager stops processing blocks succeeding the reconfiguration block. |
There was a problem hiding this comment.
what about the empty/special block that must follow a reconfiguration block to reach a 2-chain commit?
There was a problem hiding this comment.
those empty blocks won't be committed (both before and after), they're just used to facilitate the commit of reconfiguration block.
|
|
||
| ## Reconfiguration | ||
| A reconfiguration transaction is the last transaction of an epoch. Execution recognizes this type of transaction and buffer manager would stop processing any blocks after the reconfiguration block. | ||
| Consensus would stop once the backpressure is triggered, blocks after the reconfiguration block would be discarded and transactions would be retried in next epoch. |
There was a problem hiding this comment.
not clear. Please explain
| `StateComputer` is the trait that consensus uses for `compute`, `commit` or `sync_to` blocks. | ||
| A simple `ordering_state_computer` is implemented to bypass execution and send blocks to next stage when ordered. | ||
|
|
||
| ## BufferManager |
There was a problem hiding this comment.
it's really a block state-machine, but that's of course overloaded.
how about ConsensusStageManager or BFTStageManager or SMRStageManager?
| Recall that a reconfiguration transaction must be the last transaction of an epoch. Before this proposal, consensus-ordering is aware of | ||
| reconfiguration and leader proposes empty suffix. After the proposal, execution on each node recognizes this type of transaction and BlockStateManager stops processing any blocks succeeding the reconfiguration block. | ||
| Ordered blocks after the reconfiguration block are discarded and transactions inside those blocks would be retried in next epoch. | ||
| Imagine a few block batches [1, 2] [r, 3], [4], [5, 6], r represents a block has reconfiguration transaction. The ledger info is aggregated on block 3 (transactions in 3 are skipped) and 4, 5, 6 are discarded. |
There was a problem hiding this comment.
what is the purpose of the bracket notation? what do you mean by "block batches" (transactions batched into blocks?)
There was a problem hiding this comment.
| Imagine a few block batches [1, 2] [r, 3], [4], [5, 6], r represents a block has reconfiguration transaction. The ledger info is aggregated on block 3 (transactions in 3 are skipped) and 4, 5, 6 are discarded. | |
| Imagine a few block batches [1, 2] [r, 3], [4], [5, 6], r represents a block that contains a reconfiguration transaction. The ledger info is aggregated on block 3 (transactions in 3 are skipped) and 4, 5, 6 are discarded. |
There was a problem hiding this comment.
it's a batches of blocks that certified by a ledger info, not every block gets a ledger info in case of timeout
| After the reconfiguration block gets committed, the old epoch instance is dropped, a new epoch is instantiated via a virtual genesis block derived from the last ledger info in previous epoch. | ||
|
|
||
| ## Upgrade | ||
| To enable the feature in existing blockchain requires coordination via reconfiguration, on-chain consensus config would be updated to a newer version supporting the upgrade protocol. |
There was a problem hiding this comment.
| To enable the feature in existing blockchain requires coordination via reconfiguration, on-chain consensus config would be updated to a newer version supporting the upgrade protocol. | |
| To enable the feature in an existing blockchain requires coordination via reconfiguration, on-chain consensus config would be updated to a newer version supporting the upgrade protocol. |
|
|
||
| ## Reconfiguration | ||
| Recall that a reconfiguration transaction must be the last transaction of an epoch. Before this proposal, consensus-ordering is aware of | ||
| reconfiguration and leader proposes empty suffix. After the proposal, execution on each node recognizes this type of transaction and BlockStateManager stops processing any blocks succeeding the reconfiguration block. |
There was a problem hiding this comment.
does this mean that the consensus stage continues moving forward, oblivious of the reconfiguration transaction, until either execution catches up with the reconfig tx or back-pressure prevents progress? if yes, perhaps add this clarification to the text?
There was a problem hiding this comment.
it moves forward until it hits backpressure and then blocks until next epoch
mimoo
left a comment
There was a problem hiding this comment.
wow this is great, is this implemented already? Are there any downsides of this approach?
| - `Ordered` block is sent to execution and advanced to `Executed` after receiving execution result. | ||
| - `Executed` block is sent to safety rules and advanced to `Signed` after receiving a signature. | ||
| - Signature on `Signed` block is broadcasted to all validators. At all stages except `Aggregated`, signatures from other validators on the block are collected. | ||
| - A block in either `Executed` or `Signed` stage is advanced to `Aggregated` after receiving a quorum of signatures. |
There was a problem hiding this comment.
I would suggest "certification of correct execution", as 2f+1 have agreed that this is the correct execution output
|
@mimoo yes it's already implemented. one trade-off is that it adds one hop latency due to the extra execution certification |
|
oh right, makes sense! thanks |
for #213