Nomad Docs
  • Nomad 101
    • Funds Recovery
    • Introduction
    • Our Mission
    • Getting Started
  • The Nomad Protocol
    • Overview
    • Cross-chain Messaging
      • Lifecycle of a Message
    • Verification Mechanisms
      • Background on Verification
      • Native Verification
      • External Verification
      • Optimistic Verification
      • Comparing Mechanisms
    • Security
      • Root of Trust
        • Fraud
          • Optimistic Timeout Period
          • Fraud Recovery
        • App-Governed Root of Trust
        • Liveness Assumptions
      • Attack Vectors
        • Key Compromise
        • Economic Attacks
        • Smart Contract Bugs
      • Long-Term Security
        • Permissionless Watchers
        • Financial Controls
        • Cross-Domain MEV
    • Smart Contracts
      • Home
      • Replica
      • XAppConnectionManager
    • Off-chain Agents
      • Updater
      • Watchers
      • Relayer
      • Processor
  • Token Bridge
    • Overview
    • How to Bridge
      • Using Etherscan
      • Nomad Bridge App
      • Testnet Bridge App
    • Asset Issuers
      • Custom Representations
    • Deployed Tokens
      • Mainnet
      • Testnet
    • Smart Contracts
      • BridgeRouter
      • TokenRegistry
      • BridgeToken
      • BridgeMessage
    • Architecture
    • FAQ
  • Governance Bridge
    • Overview
    • Zodiac: Nomad Module
    • Smart Contracts
      • NomadModule
    • Architecture
  • Developers
    • Quickstart
      • Send Messages
      • Receive Messages
    • Environments
      • Domain (Chain) IDs
    • Application Developers
      • Building xApps
      • SDK
        • Contracts SDK
        • Typescript SDK
      • Examples
        • Ping Pong
        • Example Bridge GUI
        • xApp Example
      • Advanced
        • Router Pattern
    • Node Operators
      • Running Agents Guide
        • Troubleshooting
      • Running a Watcher
      • Agent Operations
      • Agent Gas Values
      • The Keymaster
    • Core Developers
      • Upgrade Setup
      • Deploying Contracts
        • Development
        • Production
  • Operational Security
    • Audits
    • Bug Bounty
    • Governance
    • Contracts
    • Agent Operations
  • Resources
    • Awesome Interoperability
    • Brand Kit
    • FAQ
    • Glossary
    • GitHub
    • Discord
    • Twitter
    • Website
Powered by GitBook
On this page
  • Nomad Channels
  • The Home Contract
  • Replica Contracts
  • Broadcast Channels
  1. The Nomad Protocol

Cross-chain Messaging

PreviousOverviewNextLifecycle of a Message

Last updated 2 years ago

Cross-chain messaging is a subset of , where the provenance of the desired data is another blockchain. In order to push data from one chain into another, we have no choice but to rely on someone in the real world to verify and relay this data. The goal of all cross-chain messaging systems is, ostensibly, to reduce the trust assumptions in .

Nomad achieves this by leveraging an that relies on an off-chain to attest to data, and to provide checks and balances. Each Updater is responsible for a that broadcasts uni-directionally to any number of , each corresponding to a destination chain.

This section will cover how Nomad channels work and how they are secured.

Nomad Channels

All cross-chain messaging channels are uni-directional. As mentioned above, chains cannot pull data from or push data out to any external system.

To facilitate secure two-way communications between chains, we need to establish dual simplex channels, meaning two one-way channels that form a composite bi-directional channel.

The Home Contract

Nomad does this by following a uni-directional , where each sending chain is the source of truth, and contains a Nomad where messages are enqueued.

Messages from all applications are committed in a Merkle tree (the “message tree”). Each new message is stored as a leaf, with the root of the tree serving as an accumulator. New roots are calculated upon each message insertion, and inserted into a queue that tracks all roots, current and historic.

Periodically, the Updater signs an update, which acts as an attestation. Updates commit to the previous root and a new root, and are relayed to Replica contracts corresponding to the Home. Updates can happen as frequently as new roots are generated, or be batched to reduce costs.

Replica Contracts

Every destination chain that wishes to replicate the state and receive messages from a given Home contract must maintain a , corresponding to that Home.

Any chain can maintain a Replica, which holds knowledge of the corresponding Home's Updater and the current root. Signed updates are held by the Replica, and accepted after a timeout (the optimistic dispute window).

The Replica effectively replays a series of updates to reach the same root as the Home chain. Because the root commits to the message tree, once the root has been transmitted and settled, honest messages can be proven against the root.

Broadcast Channels

Unlike other cross-chain messaging channels which facilitate 1-to-1 comms between chains, Nomad by default allows for 1-to-n messaging. This is because Nomad follows a single-producer, multi-consumer model.

Each Home contract acts as a broadcast channel, whose corresponding Replicas can receive updates from without any bespoke logic.

Because the messages need not be coupled with the destination, we anticipate novel use cases that leverage this pattern and enable quick one-to-many comms between blockchains.

the oracle problem
this verification process
optimistic mechanism
Updater
Watchers
Home contract
Replica contracts
broadcast model
Home contract
Replica contract