The Avalanche Bridge™ can be broken down into two main parts: the SGX application and a set of third-party indexers and verifiers called “Bridge Nodes.” The Bridge Nodes are responsible for indexing the Avalanche® and Ethereum blockchains and submitting eligible transactions to the enclave for processing. The Bridge Nodes first look for transactions involving supported ERC20s (Supported ERC20s) being sent to the Ethereum wallet and successful calls to the unwrap function on the Bridge’s Avalanche tokens (Example Bridge Token). For these transactions to be considered eligible, they must transfer enough tokens so that the operator can keep a portion in order to pay for the gas fees. If the USD value of the assets moving across the Bridge is less than the USD value of the gas costs plus a small buffer (set to $5 at launch, but configurable), the transactions will not be indexed by the Bridge Nodes. The Bridge’s front end calculates these requirements in real time in order to prevent users from sending ineligible transactions.
The SGX application requires 6 of 8 Bridge Nodes to submit the same transaction before generating the signed transaction to process the Bridge transfer on the other network. It’s important to note that each Bridge Node communicates directly with the secure SGX enclave both in providing its secret share and submitting eligible transactions (more details are provided in the below section).
For security reasons, neither the enclave nor the Bridge Nodes are directly accessible to bridge users. Instead, they’ll explicitly whitelist each other’s IP addresses for direct communication. In addition, all communication between the Enclave and Bridge Nodes will be encrypted and verified using TLS and include an HMAC signature. For relaying information to the Bridge user base, each Bridge Node hosts a JSON file containing the current bridge settings, assets requirements, and attestation report. The front-end is set to disable itself if there’s any discrepancy within the critical information (Ethereum wallet address, supported token information, etc) reported by the four Bridge Nodes.
Intel SGX Application
The Intel SGX application consists of a trusted codebase that runs within an enclave, and an untrusted codebase that runs outside. The untrusted code is responsible for initializing and starting the enclave as well as running the remote attestation server. Remote attestation is the process by which a third party can attest to a remote entity that it is trusted, and establish an authenticated communication channel with that entity. As part of attestation, the enclave proves its identity, that the source code hasn’t been tampered with, that it’s running on a genuine SGX enabled platform, and that it has the latest security updates. Within the Bridge Architecture, each Bridge Node will perform attestation upon startup and post the report to a public JSON file.
The enclave communicates directly with the Bridge Nodes to learn about on-chain events and send signed transactions. Signed transactions include the creation of smart contracts on the Avalanche C-Chain for wrapped ERC20s, minting assets on Avalanche, and releasing assets on the Ethereum EVM to designated addresses.
All private keys for the addresses used by the enclave on both Ethereum and the Avalanche C-Chain are derived from a single master secret generated on the initial startup within the enclave. At no point does the Bridge operator have access to this secret. Within the enclave, the secret is split into shares using Shamir secret sharing and distributed to a collection of 8 Bridge Nodes. The sharing process starts with the enclave using TLS to verify the identity of each Bridge Node Each time the enclave starts up or the Bridge Nodes receive a request for their shares, each Bridge Node performs remote attestation with the enclave to verify its status and establish a shared session key. The enclave uses this shared key (unique to each Bridge Node) to individually encrypt each share before sending them to the Bridge Node.
On the restart, the enclave requests the shares from the Bridge Nodes over a TLS connection, requiring 6 of 8 to recompute the master secret. After attestation, the Bridge Node encrypts and returns its secret share using the shared session key generated during remote attestation. The Bridge reconstructs the master secret from a threshold of secret shares and uses the master secret to rederive the private keys for an Ethereum address (used to hold funds) and Avalanche address (used to deploy the smart contracts and mint new assets).
Bridge Node
The Bridge Node instances consist of three main components, a Golang server used to index ETH and Avalanche transactions and communicate with the Bridge, an AvalancheGo node, and an Ethereum Geth node. The Bridge Nodes’ responsibilities are broken down below:
Storing secret shares: Each Bridge Node gets a single secret share from the enclave when the enclave first initializes. A set threshold of these shares is sufficient to regenerate the enclave’s “master secret”. If the enclave ever restarts, it will query the Bridge Nodes to get their secret shares and recompute its master secret value. All keys used by the enclave are deterministically derived from the master secret.
Indexing supported blockchains: The enclave needs to be able to query the Bridge Nodes for transactions sent to a specific address on each blockchain network. Geth nodes do not have the database indices necessary to support this API. Instead, each Bridge Node builds this index in its own database by querying Geth and AvalancheGo nodes for each block and iterating through the transactions.
Processing transactions and tracking which bridge requests have been processed: The Bridge Nodes are responsible for tracking wrapping and unwrapping transactions that have been processed by the enclave. Once the enclave receives a Bridge Node consensus on an eligible transaction, it kicks off a two-phase commit process. The first commit sends an encrypted signed transaction to each Bridge Node to store in its database as a backup. The transaction can only be decrypted by the enclave and serves as a backup in case of an outage mid-process. Once the enclave receives confirmation that the encrypted transaction has been successfully stored, the enclave then sends the unencrypted transaction to each Bridge Node for processing. Upon receiving the signed transaction, the Bridge Node attempts to broadcast it to its Avalanche or Ethereum node. On either confirmation of the transaction or being notified that the transaction’s nonce has already been included, the Bridge Node marks that the transaction has been processed successfully.
Host public information: Information such as fees, minimum transfer requirements, and which ERC20s are supported will be configured and maintained in the enclave. As the enclave is not publicly accessible, it’s up to the Bridge Nodes to publicly host that information. In addition, the Bridge Nodes are responsible for hosting an attestation report for public consumption. Each Bridge Node posts this information to a publicly accessible S3 file, which can be used for independent verification.
Verify Enclave Codebase: Through remote attestation, each Bridge Node is able to verify the hash of the enclave’s binary code. The Bridge Nodes have access to the full codebase and are able to check this hash against each code change. Each time the enclave code is updated, the Bridge Node partners must explicitly approve the new hash and add it to a local configuration file on the Bridge Node server.
Upcoming AEB Sunset
As announced previously, the AEB relayers will sunset their bridge during the week of August 9th in favor of the new Avalanche Bridge. The sunset process will consist of the AEB bridge being shut down. Asset transfers across the AEB bridge will be disabled permanently. Once the Bridge has been shut down and any pending transactions finalized, the AEB relayers will come together to transfer all ERC20s on the Ethereum side to the Avalanche Bridge Wallet. The Avalanche Bridge has been configured to ignore transfers coming from the AEB contract addresses so no funds will be minted in response. Once the transfer has finished, a new enclave build will be pushed enabling swaps on the Bridge token contracts. At this point, the Bridge frontend will enable token swaps and a set of token conversion tutorials will be released.
The Avalanche Bridge makes use of Intel SGX to create a quick, secure, and low-cost bridge between the Avalanche and Ethereum Networks. It consists of a secure SGX enclave and a collection of trusted partners running Bridge Nodes. The design enables the Bridge to reduce the on-chain requirements to a single action (smart contract call or ERC20 transfer) without sacrificing security. As a result, the Avalanche Bridge provides one of the cheapest, fastest and easiest-to-use cross-chain transfer processes available today.
For a more in-depth read on how the Avalanche Bridge works, please read the following articles.
For any additional questions, please view our other knowledge base articles or contact a support team member via the chat button. Examples are for illustrative purposes only.