The following guide is meant to help developers onboard quickly to Nethermind’s implementation of the Wormhole cross-chain messaging bridge on Aztec devnet. It also refers to a demo app example by Nethermind leveraging this infrastructure.

Introduction

Wormhole is a generic message-passing protocol that enables communication between different blockchains. It acts as a cross-chain bridge, allowing smart contracts on separate networks to interact with each other. At its core, Wormhole is not a token bridge itself but a foundational layer upon which developers can build a wide range of cross-chain applications, including token bridges, cross-chain governance, and multi-chain dApps.

The protocol's security is upheld by a decentralized network of Guardians who observe messages (called Verifiable Action Approvals or VAAs) on a source chain, sign them to attest to their validity, and make them available for relay to a destination chain.

Our integration brings the full Wormhole messaging protocol to the Aztec network, enabling both inbound and outbound cross-chain communication.

<aside> ℹ️

To learn more about the Wormhole Cross-Chain messaging protocol, please see: Wormhole Messaging Overview.

To learn how VAAs are structured (and how they ought to be parsed and consumed by applications), please see: Verified Action Approvals.

</aside>

Architecture

Next, we detail the key components of the Wormhole protocol which will be relevant for our implementation. For a diagram of where each component falls into place, see below.

Source: Wormhole Messaging Overview

Core Contracts

The Wormhole Core Contract, written in Noir, is the central hub for all Wormhole messages on the Aztec network. It is responsible for emitting messages to be sent to other chains and for receiving and verifying messages destined for Aztec.

• Aztec Core Contract Source Code: https://github.com/NethermindEth/wormhole/tree/aztec/aztec/contracts/src
• Deployed Address: https://github.com/NethermindEth/wormhole/blob/aztec/aztec/contracts/addresses.json

The core contract on Aztec implements the following key methods:

• publish_message_in_public(...) and publish_message_in_private(...): These functions are called by an Emitter contract to broadcast a message from Aztec. The contract provides both public and private versions to handle interactions originating from public or private state, respectively. Both functions:
  • Take a nonce for ordering, a payload, a consistency_level, and a message_fee.
  • Handle the transfer of a message_fee token payment.
  • Increment a sequence number for the sending address to prevent replays.
  • Construct the message and emit it as a public log for the off-chain Watcher to observe.
• verify_vaa(bytes: [u8; 2000], actual_length: u32): This is the core private function for message receiving. A public-facing function (e.g., receive_message) would be responsible for taking the VAA bytes from a Relayer and calling this internal function to perform several critical security steps:
  1. It calls an unconstrained helper (verify_vaa_unconstrained) to parse the VAA, extract signatures and the body, and compute the VAA hash.
  2. It then performs on-chain, constrained verification of the Guardian signatures against the VAA hash. On devnet, only a single valid signature is required.
  3. After successful verification, the public-facing wrapper would check for replays and dispatch the verified message payload to the target Receiver contract on Aztec.

Emitter Contracts

An Emitter, or Source contract is any smart contract on the source chain that interacts with the Core Contract to send a message to another chain.

<aside> ℹ️

To build a cross-chain application sending messages, you will write an Emitter contract that defines the specific data you want to send.

• If sending from Aztec: our demo app provides an emitter example on Aztec here.
• For Solidity emitters meant to be deployed on other L2s, see an example by the Wormhole team here. </aside>