Introducing the Crosschain Broadcaster

Authors: @0x_allan (Allan), @0xgodzillaba (Henry), @yahgwai (Chris)

The rollup ecosystem is expanding at a remarkable rate and coalescing around Ethereum for its security and data availability properties. However, most of these Layer 2 or Layer 3 chains have their own state and finality guarantees. While this multi-chain world enables faster and cheaper transactions, it also introduces fragmentation. As a result, users and applications rely on Crosschain communication that is not always secure, standard, or seamless.

In this blog post, our team introduces the Crosschain Broadcaster Standard — a smart contract system that aims to solve a piece of this puzzle. This standard is built on the idea that all data needed to prove a particular message is already onchain somewhere, accessible via storage proofs. For context, a storage proof is a cryptographic proof that a certain piece of data really does exist in a given blockchain’s state at a specific block. Broadcaster enables rollups that share a common ancestor–like Ethereum–to authenticate messages on each other’s chains without additional trust assumptions.

In this blog post, we’ll explore what the Crosschain Broadcaster Standard is, what problems it solves, and how it works, including:

• Why Crosschain messaging is difficult and why the ecosystem needs a standardized solution
• The major components of the Crosschain Broadcaster Standard: Broadcaster, Receiver, BlockHashProver, and Pointers
• An example of a burn-and-mint token bridge built on top of the Crosschain Broadcaster Standard
• A high-level look at how messages flow through the system

Let’s jump in!

Why Crosschain Messaging Matters

Imagine an application that’s deployed on multiple chains, like Arbitrum One and Base. A user wants to take some action on Arbitrum One that triggers a response on Base. Maybe a user wants to prove they locked some collateral on Arbitrum One to borrow something on Base. Today, crosschain actions like these often rely on third party bridging solutions that introduce several issues, such as:

1. Trust: Many existing crosschain solutions rely on a small set of centralized parties (ex. validators, oracles, relayers) to confirm that data from one chain is valid on another. Trusting those parties to do the right thing with your message or your funds is a prerequisite for users.
2. Complexity: Different rollups have different ways of achieving and recording finality. Consequently, Crosschain developers must create custom integrations with each chain to access finality data and stitch it together with other, dissimilar chains.
3. Maintenance: Rollups undergo upgrades. During these upgrades, chain owners may change finality conditions or update storage mechanisms. A Crosschain application that worked previously may break if the rollup changes where finality outcomes can be found.

The Crosschain Broadcaster seeks to solve this by providing a trustless, flexible messaging standard that is rollup agnostic. Rather than trusting offchain actors, Broadcaster utilizes onchain storage proofs for rollups rooted in Ethereum. As a smart contract standard, Broadcaster can provide standardized interfaces for messaging across any EVM-compatible chain. It is also upgradeable by design, anticipating rollup evolution while providing immutable endpoints for continuous integration. No trust assumptions, no complex customizations, no core protocol requirements.

How Crosschain Broadcaster Works

The Crosschain Broadcaster standard builds on the idea that all data needed to prove a particular message is already onchain somewhere. If a chain can figure out the correct block hash information for another chain, it can verify the existence of any piece of data in that chain’s state. Put another way, if the block hash of a given chain is final, then so is the existence of any messages stored at or before that block.

Let’s walk through a simple scenario:

1. A user on Arbitrum One submits a message to the Broadcaster contract on Arbitrum One.
2. The Broadcaster contract stores that message in a unique slot on Arbitrum One.
3. On Base, someone wants to confirm that message indeed exists on Arbitrum One; they call the Receiver contract on Base and provide:

• a “route” of Pointer addresses that leads from Base (L2) to Ethereum (L1) to Arbitrum One (L2)
• the necessary storage proofs for verification

4. The Receiver on Base works through each Pointer/Prover in the route, eventually obtaining Arbitrum’s block hash and reading the Broadcaster’s storage.

5. If the message is found, the Receiver returns success plus a timestamp. This result can trigger an arbitrary action in a smart contract that is subscribed to the Receiver

Now let’s go through a practical example: intents-based bridging. Intents-based bridging–like Across–allows users to move assets faster than they can through canonical bridges. Today, many intents-based bridges do this in four main steps:

1. User deposits funds into an Escrow contract on Base
2. A solver sends funds to the user through a Fulfillment contract on Arbitrum One
3. The Fulfillment contract sends a message to the Escrow contract saying “solver X sent Y tokens to user Z at time T”
4. The Escrow contract receives and validates the message from the Fulfillment contract, releasing the user’s funds to the solver on Base

In this example, a message is sent and received in Step 3 and Step 4; depending on the solution, this message may be relayed and verified offchain or sent via a slow message onchain. Instead, an intents system could easily use the Crosschain Broadcaster to store and verify these messages in a transparent, trustless way.

1. User deposits funds into an Escrow contract on Base
2. A solver sends funds to the user through a Fulfillment contract on Arbitrum
3. The Fulfillment contract calls the the Broadcaster contract on Arbitrum and publishes a message saying “solver X sent Y tokens to user Z at time T”
4. Back on Base, the Escrow contract calls the Receiver contract and validates the message in the Broadcaster on Arbitrum One; user funds are then released to the solver

In this case, the Fulfillment contract plugs into the Broadcaster on Arbitrum while the Escrow contract plugs into the Receiver on Base. Messaging pathways like this could be created in any direction using the same standardized set of Broadcaster contracts.

Breaking Down the Core Contracts

Broadcaster Contract

Broadcaster is one of, if not the simplest concept: it’s a contract that stores messages on a particular chain. Any user, called a Publisher, can submit a bytes32 message. After verifying it hasn’t seen the same message from that user before, the contract stores the message in its own storage slot. As soon as the message is stored in the Broadcaster, it has been “broadcast”.

When another chain wants to check if a given message was indeed broadcast, it just has to read that slot in the Broadcaster’s storage on the home chain and confirm the metadata.

BlockHashProver Contracts

To figure out the state of a remote chain, one must verify its block hashes. However, each rollup might store finalized block hashes using different methods. The job of a BlockHashProver is to get block hashes of a target chain from its home chain. It can accomplish this with two functions:

• getTargetBlockHash(…): when called on its home chain, it directly fetches the final block hash of its target chain from that chain’s state
• verifyTargetBlockHash(…): when called on a non-home chain, it uses a storage proof to check that a given homeBlockHash implies a specific targetBlockHash

A BlockHashProver effectively creates a one-way link between two chains. BlockHashProvers can also be daisy chained together across L2s and L3s, enabling robust routing between rollups.

BlockHashProverPointer Contracts

Because rollups are upgradeable, the hardcoded methods in a BlockHashProver may break if rollups change where they store block hashes. A BlockHashProverPointer can solve this by:

• storing the code hash of the current, correct BlockHashProver for a chain pair (i.e. home chain, target chain)
• updating the Pointer to a new version of the BlockHashProver that incorporates the rollup changes

The BlockHashProverPointer contract simply holds the code hash of the real BlockHashProver. That way, references to the Pointer address remain stable even if the underlying Prover changes. It is the responsibility of the chain owner to maintain the BlockHashProverPointers on their chain.

Receiver Contract

The Receiver contract on a local chain is responsible for verifying that a Broadcaster contract on a remote chain truly contains a message. To do so, it takes the following steps:

1. The user provides a list of Pointer addresses (i.e. the “route”) that leads from the local chain back to the remote chain in question along with the corresponding storage proofs
2. The Receiver contract calls or references each Pointer in turn, using the Provers they point to to verify block hashes hop-by-hop until it obtains the final block hash of the remote chain
3. Armed with that final block hash, the Receiver checks a proof that the remote Broadcaster’s storage slot indeed holds the user’s message

If all is well, the Receiver returns a confirmation along with the original broadcast timestamp.

Routes and IDs

Because every chain can reference many others, there must be a standardized way to identify which chain is being read from. The Crosschain Broadcaster Standard accomplishes this via a route-based “accumulator” method:

• Suppose you have a route: [PointerA, PointerB, PointerC]. At each hop, the local chain references that Pointer’s code to read or verify the next block hash.
• If the actual account you want to prove is address D, the combined remoteAccountId is keccak256(keccak256(keccak256(keccak256(0,A),B),C),D).
• This method guarantees a unique ID for any contract address given the exact route taken to get there.

So if different routes exist that eventually point to the same chain, that’s fine: they just produce different IDs. But from the local chain’s perspective, each route is an unambiguous path to verifying message data.

Conclusion

As the Ethereum ecosystem grows, so does the need for reliable, trustless Crosschain communication. The Crosschain Broadcaster Standard is a potential stepping stone towards that goal:

• It defines a simple interface for broadcasting 32-byte messages on any rollup chain
• It provides a universal way to verify those messages on chains with a common ancestor
• It is built around storage proofs rather than external relays, eliminating trust assumptions
• It provides forward-looking flexibility for rollups that are expected to evolve

These properties also align with Arbitrum’s vision for interoperability, which prioritizes interoperability building blocks that are:

1. Trustless: Crosschain communication should not introduce any new trust assumptions, or it risks undermining the core value proposition of blockchains today.
2. Cheap: Crosschain communication should not result in high fees that restrict accessibility.
3. Fast: Crosschain communication should occur much faster than L1 finality to help ensure practical functionality.
4. Accessible: Interoperability should be a feature available to everybody. Developers should have a clear path toward enabling Crosschain communication, with no vendor lock-in, politics, or boundaries.

While Broadcaster meets the criteria for trustless, cheap, and accessible, it is worth noting that the speed is limited by the finality of chains in a given route. If the Ethereum L1 anchors a route, then it cannot be faster than L1 finality; however, if an L2 anchors a route between L3s, then it can be faster than L1 finality. The latter is especially relevant for the Universal Intent Engine vision, which seeks to enable crosschain swaps and transfers for all Arbitrum chains (L2s and L3s) and EVM chains more broadly. For example, a full intents stack could enable fast fulfillment for end users while using Broadcaster for trustless settlement for solvers.

Whether or not the Crosschain Broadcaster Standard progresses is up to you, the community! If there is sufficient demand, Offchain Labs will set its sights on building out the complete implementation in collaboration with the Ethereum ecosystem. So if you’re looking to build crosschain applications with strong security guarantees, or if you’re just enthusiastic about multi-chain design, share your thoughts on the Eth Magicians post or contribute to the standard directly!