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
If the proposal is in Round::Fast, it counts as locked, so the client must re-propose that same block in a later round.
If it is in Round::MultiLeader(r) and the client wants to propose a block, it should not do that in the same round, but it can make a proposal in round r + 1 without waiting for a timeout.
In the first case, the block cannot use any oracles.
In the second case, however, the block could be using oracles and therefore handling it locally could fail. On the other hand, we don't really care about the block itself there: We only need to know that a proposal was made, not which one.
Let's add a way for the client to keep track of proposals in the current round without executing them (but still checking the proposer's signature), so that the protocol works as intended in the second case even for blocks using oracles.
Alternative: Use Timeouts?
We could also just rely on timeouts instead, and by default configure all multi-leader rounds to have timeout 0. That requires one more round-trip in the second case, but simplifies the protocol and brings the multi leader mode in line with the single leader one.
The text was updated successfully, but these errors were encountered:
The client currently asks validators for pending block proposals and then handles them locally. This serves two purposes:
Round::Fast
, it counts as locked, so the client must re-propose that same block in a later round.Round::MultiLeader(r)
and the client wants to propose a block, it should not do that in the same round, but it can make a proposal in roundr + 1
without waiting for a timeout.In the first case, the block cannot use any oracles.
In the second case, however, the block could be using oracles and therefore handling it locally could fail. On the other hand, we don't really care about the block itself there: We only need to know that a proposal was made, not which one.
Let's add a way for the client to keep track of proposals in the current round without executing them (but still checking the proposer's signature), so that the protocol works as intended in the second case even for blocks using oracles.
Alternative: Use Timeouts?
We could also just rely on timeouts instead, and by default configure all multi-leader rounds to have timeout 0. That requires one more round-trip in the second case, but simplifies the protocol and brings the multi leader mode in line with the single leader one.
The text was updated successfully, but these errors were encountered: