Owner: @David Rusu
Reviewers: đ¨@Ălvaro Castro-Castilla đ¨@Thomas Lavaur đ¨@Giacomo Pasini
Sovereign Rollups use the Mantle to make their updates available on chain. These state updates are posted in the form of blobs. The order of these blobs on chain must reflect the order of the state changes in the rollup. The issue is that re-orgs are not rare in Cryptarchia and since we are relying on message ordering to derive Sovereign Rollup state, sequencers need to wait a sufficiently long time between posting channel messages in order to have high confidence that a re-org does not re-order Rollup state updates.
Instead of forcing sequencers to wait for Cryptarchia to finalize between channel messages, we take advantage of the âvirtual chainâ structure of these channels and allow Sovereign Rollups to encode their message ordering requirements on these messages. In the case that Cryptarchia re-orgs, the message ordering requirements would prevent messages from being included in a way that breaks the virtual chain order.
This ordering invariant is what we call âCausal Finalityâ: Sovereign Rollups can trust that once the messages finalize, they will finalize in the order imposed by the sequencer. This allows sequencers to safely bypass the slowness of Cryptarchia and work collaboratively with other sequencers optimistically.
We will support two types of orderings
Same channel ordering allows sequencers to build virtual chains on top of the Cryptarchia blockchain.
Same-channel ordering needs additional crypto-economic incentives to ensure the channel does not fork. The fork here is a Sovereign Rollup posting two messages to the same channel, both representing conflicting rollup state updates chaining from the same parent state
graph LR
subgraph Channel B
direction LR
subgraph Tip B
B3
end
B3 --> B2 --> B1
end
subgraph Channel A
direction LR
subgraph Tip A
A3
end
A3 --> A2 --> A1
end
graph LR
subgraph Conflict
A3
A3'
end
A2 --> A1
A3 --> A2
A3' --> A2
When conflicting messages are detected, the misbehaving sequencer is slashed. Due to the strict same-channel ordering conditions, only one of the conflicting messages will end up on chain, the other will be rejected as an invalid transaction. The final chain state will look something like the following:
graph LR
subgraph Cryptarchia Blockchain
subgraph Block4
SLASH
end
subgraph Block3
A3
end
subgraph Block2
A2
end
subgraph Block1
A1
end
Block4 -.-> Block3 -.-> Block2 -.-> Block1
end
A2 --> A1
A3 --> A2
A3' --> A2
SLASH --> A3
SLASH --> A3'
graph TB
subgraph Channel B
direction LR
B3 --> B2 --> B1
end
subgraph Channel A
direction LR
A3 --> A2 --> A1
end
A3 --> B2
Cross-channel ordering is used for cross-rollup communication. For example, a Sovereign Rollup that depends on the state of another Sovereign Rollup can make this dependency explicit by referencing the other rollupâs messages. This ensures that any state changes that are dependent on the other Rollupâs state will not finalize unless the other rollupâs messages also finalize.
Things get a bit more complicated if the rollup that a channel depend on double signs. In that case, one of the double signed messages will be accepted on chain, and the other will be abandoned. If the message that the channel depends on is abandoned, then channelâs updates will also be abandoned.
In this case, the channel will need to rollback its updates and re-sign a new message that does not depend on the abandoned, double signed message.
graph TB
style B2' color:red
A3 --> B2'
B2' --> B1
subgraph Mempool
A3
B2'
end
subgraph Finalized on Cryptarchia
subgraph Channel B
direction LR
B3 --> B2 --> B1
end
subgraph Channel A
direction LR
A3 --> A2 --> A1
end
end