# [Draft] Shared Publisher: A Horizontal Scaling Architecture for Synchronous Cross-Rollup Composability

## Abstract

The Shared Publisher (SP) architecture presents a novel approach to cross-rollup composability through the separation of sequencing and publishing responsibilities. This paper introduces the technical foundations of SP, demonstrating how distributed CIRC coordination via Two-Phase Commit enables atomic and synchronous cross-rollup execution while preserving rollup sovereignty and horizontal scaling. The proposed architecture can achieve superior throughput scaling for cross-rollup composability while maintaining Ethereum alignment through based publishing mechanisms.

## 1. Introduction

On one hand, the proliferation of rollups creates multi execution environments across isolated state machines, while, on the other hand, applications seek seamless integrations across these environments, as previously enjoyed in Ethereum L1. The fundamental challenge lies in enabling synchronous composability—atomic execution across multiple rollups—while preserving the sovereignty and scalability benefits that motivate rollup adoption.

The Shared Publisher architecture introduces a coordination mechanism that separates local sequencing from cross-rollup publishing. This separation enables each rollup to maintain control over its transaction ordering and execution while participating in a coordinated publishing protocol that ensures atomic cross-rollup execution.

The core innovation of SP lies in its distributed algorithm based on CIRC, where multiple independent sequencers coordinate through a permissionless publisher to achieve synchronous composability without sacrificing individual rollup performance or autonomy.

## 2. Architectural Foundation

### 2.1 Core Design Principles

The SP architecture builds on three fundamental principles:

**Sovereignty Preservation**: Each rollup maintains complete control over its sequencing mechanism, fee markets, and execution environment while participating in cross-rollup coordination.

**Horizontal Scaling**: Rather than consolidating and limiting execution to a single coordinator (as in shared sequencing solutions), SP achieves the desired parallel processing across rollups with coordinated publishing.

**Ethereum Alignment**: The publisher election mechanism leverages Ethereum's validator set, following a based approach and inheriting Ethereum's security and decentralization properties.

### 2.2 Component Architecture

**Independent Sequencers**: Each participating rollup operates its own sequencer responsible for:
- Building L2 blocks from rollup-specific mempools
- Participating in a synchronous composability protocol for cross-rollup transactions
- Delivering its blocks to the current shared publisher

**Shared Publisher Network**: A permissionless network in which the current shared publisher:
- Lead the synchronous composability protocol for cross-rollup transactions
- Aggregate L2 blocks into optimized Super Blocks
- Publish aggregated data to Ethereum L1

**Registry and Bridge Infrastructure**: L1 and L2 contracts that manage:
- Rollups registration and configuration
- Publisher set management and slashing
- Unified bridging for cross-rollup assets
- Settlement and proof verification

## 3. Message-Passing Composability

In Ethereum L1, composability was achieved by simply calling another contract's function. For example:

function swapWithCondition(uint256 amount, uint256 threshold) {
    uint256 receivedDAI = uniswap.swap(ETH, DAI, amount);
    require(receivedDAI >= threshold, "Insufficient DAI");
}

In a network of rollups, SP achieves composability through a standardized message-passing protocol, that uses a Mailbox abstraction.

function swapWithCondition(uint256 amount, uint256 threshold) {

    // Equivalent to function call
    Mailbox.write(chainU,
                  uniswapAddr,
                  "SWAP",
                  abi.encode(msg.sender, ETH, DAI, amount));

    // Equivalent to function response
    bytes m = Mailbox.read(chainU,
                           uniswapAddr,
                           "SWAP ACK");
    (receivedDAI) = abi.decode(m, (uint256));

    require(receivedDAI >= threshold, "Insufficient DAI");
}

- In `Mailbox.write`, it is specified a destination chain, a contract address, and a message label to be consumed, along with call arguments, in an equivalent manner to the `uniswap.swap(ETH, DAI, amount)` call in Ethereum composability.
- The result from the call is caught through a `Mailbox.read`, which again identifies the other chain and contract along with an expected message label response.

While the dApp is abstracted from the how the actual integration with other chains will work, the sequencer will be responsible for managing such a Mailbox through the synchronous composability protocol.

Note that, for the example above, there must be another function of the contract `uniswapAddr` in chain `chainU` that reads a `SWAP` message, performs some logic, and responds with an `SWAP ACK` message.

function swapper(uint256 srcChain, address srcContract, uint256 amount, uint256 threshold) {

    // Handler for being called
    bytes m = Mailbox.read(srcChain,
                           srcContract,
                           "SWAP");

    (userAddr, token1, token2, amount) = abi.decode(m, (address, address, address, uint256));

    // Performs some logic
    // ...

    // Response
    Mailbox.write(srcChain,
                  srcContract,
                  "SWAP ACK",
                  abi.encode(tradedAmount));
}

In this context, the cross-rollups transaction bundle would be the set of transactions `{srcChain.swapWithCondition(...), chainU.swapper(...)}`.
An execution of this bundle satisfying **atomicity** means that either both transactions are included and finalized, or none.
Achieving **synchronous composability** means that both transactions will be included in the same L1 block which, in turn, guarantees atomicity.

## 4. SP Synchronous Composability Protocol

On top of the message-passing abstraction, a synchronous composability protocol will define:
- How these messages are exchanged (i.e., how the mailboxes are populated).
- How the bundle is guaranteed to have either all transactions included or none.

### 4.1 The CIRC Building Block

The SP protocol is based on CIRC (Coordinated Inter-Rollup Communication), which is a shared sequencer solution to synchronous composability.

In CIRC, the shared sequencer starts by simulating all transactions tracking calls to the Mailbox:
- Once a `Mailbox.write` is called by a transaction to write a message $m$ to the destination chain $D$, the shared sequencer adds $m$ to the Mailbox of chain $D$. This is accomplished by adding a transaction (e.g. `Mailbox.addMessage`) placed before the bundle's transaction.
- In the example of the previous section, the shared sequencer would add a prior transaction to `chainU` that populates the Mailbox with a message from chain `srcChain` with label `SWAP`, and the same would be for `chainSrc` with a `SWAP ACK` message label from chain `chainU`.

After all messages are included to their respective mailboxes, the bundle can be executed and included to each block if successful.
For ensuring inclusion in the same L1 block, the L2 blocks are aggregated into a superblock and published as a single L1 transaction.

Notice that, underneath, the Mailbox is not really sending any messages, as we would expect from a solidity code.
Indeed, it just stores messages, with the shared sequencer being responsible for correctly managing them.

**Mailbox Pseudocode**

Mailbox Contract:
    inbox: map[(srcChain, dstChain, sender, receiver, label)] -> data (arguments)
    outbox: map[(srcChain, dstChain, sender, receiver, label)] -> data (arguments)

    clear():
        inbox ← ∅
        outbox ← ∅

    addMessage(srcChain, dstChain, sender, receiver, label, data):
        inbox[(srcChain, dstChain, sender, receiver, label)] = data

    read(srcChain, dstChain, sender, receiver, label):
        if (srcChain, dstChain, sender, receiver, label) not in inbox:
            revert
        return inbox[(srcChain, dstChain, sender, receiver, label)]

    write(srcChain, dstChain, sender, receiver, label, data):
        outbox[(srcChain, dstChain, sender, receiver, label)] = data

- `clear` is added as a transaction in the beginning of the block.
- `read` and `writes` are called by other dApps functions. While `write` just adds to the oubox and will be tracked by the sequencer, `read` may revert if a message doesn't exist in the mailbox.
- `addMessage` is added by the sequencer as a result of a `write` in some other chain inteded to this chain.

Moreover, notice that, because of dependency, some messages may only be generated after a re-simulation.
For example, in the example of the last section, the `swapper` function can only reach `Mailbox.write` after it receives the `ACK` message, produced in the first simulation.

### 4.2 The SP Protocol

The SP protocol decentralizes CIRC. Instead of a shared sequencer entity, each rollup has its own sequencer, while a shared publisher, a permissionless party, is responsible for cross-chain transaction coordination.
This achieves synchronous composability with horizontal scaling, while preserving rollups' sovereignty over sequencing rights.

The protocol works in a similar manner:
1. Each sequencer simulates its local transaction from the cross-chain transaction bundle, keeping track of Mailbox calls.
- From the result of the simulation, Mailbox messages are generated and the sequencer sends them to the other sequencer of the destination chain.
- Upon receiving a Mailbox message from another sequencer, a sequencer adds it as a `Mailbox.addMessage` transaction, populating the Mailbox as it would do in CIRC.
2. After all messages are exchanged, sequencers can fully execute their transactions and conclude if they are valid or not.
3. To determine if the bundle is successful, the shared publisher would check if all transactions were indeed successful. The same must be accomplished in a decentralized way.
- A lightweight agreement algorithm, Two-Phase Commit (2PC), is executed, being coordinated by the shared publisher.
- In 2PC, Each sequencers sends a vote (0 or 1) indicating whether its transaction is successful or not.
- The shared publisher waits for all votes from all sequencers within a timeout period.
- If all votes are received with 1, it sends a `Decided(1)` message indicating that the bundle should be included.
- Else, if at least one vote has 0 or the timer expires, it sends `Decided(0)`.


Throughout a slot, sequencers will build blocks with local transactions as well as cross-chain bundles as explained in the above protocol.
After the block is built, it's sent to the shared publisher who will aggregate all blocks into a superblock and publish it to L1 as a single transaction.

## 5. Permissionless Based Publisher Election

The SP protocol leverages Ethereum's validator set by following a based approach for the publisher election.

state variables
    current_publisher
    publisher_set // opted-in L1 validators

procedure Initialize(initial_publisher, initial_set)
    publisher_set ← initial_set
    current_publisher ← initial_publisher

upon new Ethereum slot with L1 proposer V:
    if V in publisher_set then
        current_publisher ← V
    // Else current_publisher remains unchanged

procedure optIn(V, slashingBond)

## 6. Settlement

In the SP architecture, validity proofs (ZK-proofs) will be used for ensuring the correctness of both individual rollup blocks as well as cross-chain interactions.
Key benefits include:
- **Blob Space Optimization**: By improving the blob usage per L1 transaction.
- **Constant-Time Verification on L1**: By aggregating ZK proofs into a single proof for all blocks.

## 7. Conclusion

The Shared Publisher architecture represents a paradigm shift in cross-rollup composability, introducing the first horizontally scalable solution for atomic cross-rollup execution. By separating sequencing from publishing concerns and implementing lightweight coordination through distributed 2PC, SP achieves superior throughput scaling while preserving rollup sovereignty and maintaining synchronous composability guarantees.

Furthermore, the shared publisher role can enjoy Ethereum economic alignment by adopting a permissionless based approach that inherits Ethereum’s security and decentralization properties.
In doing so, SP reinforces the rollup-centric scaling thesis at the heart of Ethereum’s roadmap. As the rollup ecosystem continues to expand, the Shared Publisher offers the unifying infrastructure needed to enable a truly composable, cross-rollup execution environment—without compromising the independence or performance of individual rollups.