Owner: @David Rusu

Reviewers: 🟨@Álvaro Castro-Castilla 🟨@Thomas Lavaur 🟨@Giacomo Pasini

Introduction

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.

Overview

We will support two types of orderings

  1. same channel ordering, where messages in the channel form a chain
  2. cross channel ordering, where messages in one channel may reference messages in other channels as dependencies.

Same Channel Ordering

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'

Cross Channel Ordering

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

Serializing Channel DAGs on Cryptarchia