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
once sequence reboots, we will generate duplicate consensus msgs as we don't persist the last state of the sequencer we saw in state. in case the sequencer is in a restart loop this can nasty.
The text was updated successfully, but these errors were encountered:
It is impossible (or at least hardly feasible) to persist the sequencer set in both full node and proposer modes because we need to persist not the latest sequencer set but the one we had while applying the latest block. And in full node mode we cannot get this unless the proposer persists this info into the block. Finally, I came up with storing two versions of the sequencer set:
The latest set that we get from polling: Store it in memory and use it for both modes.
The last block sequencer set: the one we used while producing the last block. Store it in the store while producing blocks in the proposer mode.
Now the proposer will create consensus messages during block production based on the difference between these two sets.
On reboots:
The proposer gets the last set from the Hub.
While producing the block, get the last block set from the store.
Memorize the current set (from memory == from Hub).
Compute diff and create consensus messages.
If the block production is successful, save the memorized set from (3) as the last block set (and use it on the next production).
The only drawback is that the full node does not persist in the sequencer set, so on rotation it will duplicate consensus messages, but only once.
once sequence reboots, we will generate duplicate consensus msgs as we don't persist the last state of the sequencer we saw in state. in case the sequencer is in a restart loop this can nasty.
The text was updated successfully, but these errors were encountered: