You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This DIP proposes to have nodes accept a candidate block upon producing or receiving an Agreement message instead of requiring a quorum of Agreement messages.
Motivation
Currently, the Ratification loop collects Agreement messages until a quorum is reached (with respect to the Second Reduction committee); when this occurs, the node broadcasts an AggrAgreement message containing the aggregated signatures from the received Agreement messages, generates a Certificate with the same signatures, and accept the candidate block to the chain.
This approach is flawed due to the fact that signatures in Agreement messages are equivalent to those of the (second) Reduction votes. In fact, they both sign the message "Round||Step||BlockHash".
As a consequence:
A quorum of Agreement signatures is equivalent (from a consensus point of view) to a quorum of Reduction signatures. This is confirmed by the fact that it is possible to create a valid AggrAgreement message (and hence a valid block Certificate) using just a single Agreement message (aggregated) signature (that is, the aggregated signatures of the quorum committees). In turn, this implies that a node can skip the Ratification phase and accept the block with a valid certificate.
Given the above, waiting for a quorum of Agreement messages does not add any additional value to the security of the protocol. It is, then, redundant.
Details
This DIP changes the Ratification phase in the following way:
Instead of collecting multiple Agreement messages for the current round/iteration, the Ratification step ends upon receiving (or producing) a single valid Agreement message for the current round/iteration.
The block Certificate is generated using the Reduction signatures included in Agreement message.
AggrAgreement messages are removed from the protocol.
The behavior of the step when receiving the expected Agreement message should be the same as it is now when a quorum of Agreement messages is reached, except for what stated above.
Optional changes
Since the acceptance of the block could be simply triggered at the end of the Second Reduction step (if reaching a quorum for both Reductions), we could move the collection of votes in the Ratification loop. That is, the following changes can be introduced:
The Reduction steps simply consist in broadcasting the vote (if member of the committee) and waiting the timeout (to move on to the next step)
The Ratification loop collects Reduction votes for both steps and if reaching a quorum on both, or receiving a valid Agreement message, it generates an Agreement message, the Certificate, and accepts the block.
Similarly to the current version, all nodes running the Ratification loop, can collect votes and generate the Agreement message is seeing a quorum on both Reductions. Note that any node seeing such a quorum can independently aggregate the signatures and produce the Agreement.
The text was updated successfully, but these errors were encountered:
Summary
This DIP proposes to have nodes accept a candidate block upon producing or receiving an Agreement message instead of requiring a quorum of Agreement messages.
Motivation
Currently, the Ratification loop collects Agreement messages until a quorum is reached (with respect to the Second Reduction committee); when this occurs, the node broadcasts an AggrAgreement message containing the aggregated signatures from the received Agreement messages, generates a Certificate with the same signatures, and accept the candidate block to the chain.
This approach is flawed due to the fact that signatures in Agreement messages are equivalent to those of the (second) Reduction votes. In fact, they both sign the message "Round||Step||BlockHash".
As a consequence:
Given the above, waiting for a quorum of Agreement messages does not add any additional value to the security of the protocol. It is, then, redundant.
Details
This DIP changes the Ratification phase in the following way:
The behavior of the step when receiving the expected Agreement message should be the same as it is now when a quorum of Agreement messages is reached, except for what stated above.
Optional changes
Since the acceptance of the block could be simply triggered at the end of the Second Reduction step (if reaching a quorum for both Reductions), we could move the collection of votes in the Ratification loop. That is, the following changes can be introduced:
Similarly to the current version, all nodes running the Ratification loop, can collect votes and generate the Agreement message is seeing a quorum on both Reductions. Note that any node seeing such a quorum can independently aggregate the signatures and produce the Agreement.
The text was updated successfully, but these errors were encountered: