How does the Wormhole bridge work? (2024)

So many chains, so little noise!

A lot of chains have spun up in the last three years, especially built on different infrastructures like EVM like Ethereum, Avalanche, Binance Smart Chain, or Substrate-based chains like Polkadot, Cosmos-SDK chains like Terra and BNB. This makes it incredibly difficult to communicate between chains. This communication entails not just token transfers but also more generic messaging for applications like cross-chain voting or playing games where you could own assets on one chain and make your moves on another one.

This is where Wormhole comes in. From their docs,

Wormhole is a generic message passing protocol that connects to multiple chains including Ethereum, Solana, Terra, Binance Smart Chain, Polygon, Avalanche, Oasis, and Fantom.

This serves us perfectly. Wormhole operates with the help of a network of nodes called guardians which signs and verifies transactions on the origin chain and with relayers to relay the message to the target chain. More details here:

Wormhole has core bridge contracts deployed on all chains (published list available here). They implement emitVAA() and verifyVAA() functions. VAA or Verifiable Action Approval is a struct containing your message payload along with guardian signatures. emitVAA reads and publishes messages to the “mempool” of VAAs and verifyVAA takes VAA and matches the guardian signatures to make sure the proof is valid. This is the VAA payload:

// headbyte version // VAA Versionu32 guardian_set_index // Indicates which guardian set is signingu8 len_signatures // Number of signatures stored[][66]byte signatures // Collection of ecdsa signatures// bodyu32 timestampu32 nonceu16 emitter_chain[32]byte emitter_addressu64 sequenceu8 consistency_level[]byte payload

Once you send the transactions to the wormhole, each and every guardian will confirm and sign the payload in isolation and these signatures get collectively stored in stored[][66]byte. This is similar to users who independently sign transactions on a Gnosis multi-sig wallet. There are only 19 guardians on the network and most of these are Solana validators.
Upon reaching 2/3rd majority of guardian signatures, the emitVAA the function gets triggered and the VAAs are ready to be picked up from the Wormhole network and submit it to the target chain.
On the target chain, the VAA is processed by the core receiving contract. You can manually go fetch your message from the guardian RPC and submit the VAA on the target chain. Usually, this burden is abstracted away from the user by the dapps built on top of the core Wormhole bridge. In a lot of cases, they use “relayer” which acts as an automation script. Relayers can be run in an untrusted environment and cannot forge VAAs as they aren’t running any cryptographic function and if they taper with the code it gets rejected at the target chain bridge contracts.

Who pays for the gas fees, on which chain, and in whichtoken?

Since the transaction is settled on the target chain, gas fees should be paid there. If a user doesn’t have the native currency on the target chain, the bridge lets users pay a portion of the token being transferred via relayers. The relayers then cover the gas expenditure on the target chain. Oftentimes, dapps built on Wormhole will pay on the user’s behalf as meta-transactions to improve ease of use.

What if the target chain has a longer finality period than the lifetime of this message-passing?

In this case, messages on the origin chain may get slashed by a fork. Wormhole attempts to fix this by allowing the message emitting contract on the origin chain to specify the waiting period before sending it to the wormhole guardian network. If you’re on Ethereum, you need to wait for 13 network confirmations before assuming immutability of your transaction and as a dapp builder, you can specify this number as you deploy your contracts.

How does a lock/mint token bridge work with Wormhole?

The token is locked on the origin chain and its wrapped version is minted on the target chain. The origin chain emits a message saying the tokens have been locked in the following structure:

u8 payload_id = 1 Transferu256 amount Amount of tokens being transferred.u8[32] token_address Address on the origin chain.u16 token_chain Numeric ID for the origin chain.u8[32] to Address on the destination chain.u16 to_chain Numeric ID for the destination chain.u256 fee Portion of amount paid to a relayer.

This event however doesn’t specify the implementation of how the tokens were locked. They could have been locked in a smart contract or in a custody, this is up to the implementation of the token bridge.

Is having 19 guardians pose a centralization risk?

Yes. In comparison to trustless liquidity bridges like Connext or light client bridges like LayerZero or Gravity, Wormhole falls in the “External validators” category of bridges which makes it one of the riskier ones and prone to centralization risk especially because these 19 validators are also validators for the Solana network.

What if you can’t trust the guardiannetwork?

This is a valid concern. On Feb 2nd, a hacker was able to spook guardian signatures by calling an outdated version of the Secp256k1 contract for the verify_signatures function on Solana, generating a fake SignatureSet and signing fraudulent VAA to drain 120k ETH on Ethereum, making WETH on Solana worthless. Read more about this hack here. Lock/mint token bridges like the Wormhole Portal essentially behave as massive escrow accounts and aren’t supported by the economic security of the connecting L1s. And operating on multiple chains, they have multiple points of failure. This paints them as big targets for being exploited by hackers.

Example code

This is how a user interacts and the bridge user flows:

Say you’ve deployed your contract on Eth mainnet but you want to send a message to Solana. So, using the Wormhole SDK, you can wrap your address in IWormhole and use _wormhole.publishMessage() with:

import "./interfaces/IWormhole.sol";contract Messenger { // Hardcode the Wormhole Core Bridge contract address // In a real contract, we would set this in a constructor address a = address(0xC89Ce4735882C9F0f0FE26686c53074E09B0D550); IWormhole _wormhole = IWormhole(a); function sendStr(bytes memory str, uint32 nonce) public returns (uint64 sequence) { sequence = _wormhole.publishMessage(nonce, str, 1); return sequence; } function wormhole() public view returns (IWormhole) { return _wormhole; }}

Token transfer from Ethereum to Solana:

// Submit transactionconst receipt = await transferFromEth( ETH_TOKEN_BRIDGE_ADDRESS, // specified in the doc signer, tokenAddress, // WETH token address amount, CHAIN_ID_SOLANA, recipientAddress // already attested address on solana);// signedVAA needs to be fetchedconst { signedVAA } = await getSignedVAA( WORMHOLE_RPC_HOST, CHAIN_ID_ETH, emitterAddress, sequence);// post signVAAawait postVaaSolana( connection, wallet, SOL_BRIDGE_ADDRESS, payerAddress, signedVAA);// redeem WETH on Solanaconst transaction = await redeemOnSolana( connection, SOL_BRIDGE_ADDRESS, SOL_TOKEN_BRIDGE_ADDRESS, payerAddress, signedVAA, isSolanaNative, mintAddress);

Unanswered questions

How does Wormhole handle multiple chains talking to each other at the same time? If chain A sends a message to chain B and also sends a different message to chain C which then sends it to chain B, which version will be considered to be accurate?

Can Wormhole mitigate its centralization factor? Is there a way to get the counterparty validator set on either side of the bridge to behave as additional members of the guardian network?
How does Wormhole deal with interactions between deterministic vs probabilistic consensus models?