Avalanche Bridge: Secure Cross-Chain Asset Transfers Using Intel SGX
Learn how the revolutionary Avalanche Bridge works using Intel SGX
The Avalanche Bridge (“Bridge”) is a new service developed to support quick, secure, and low cost asset transfers between the Avalanche and Ethereum networks. The Bridge leverages Intel SGX (Software Guard Extensions) to create a secure service (enclave) resistant to interference and private from the Bridge Operator.
As opposed to the legacy AEB Bridge, the new Avalanche Bridge dramatically simplifies the transfer process. While the legacy AEB bridge requires a smart contract call by the user and four additional on-chain transactions (3 votes and 1 execution) by the relayers to process a single asset transfer across the Bridge, the new Avalanche Bridge reduces this to a single Ethereum transaction or Avalanche Smart Contract call. Using the Bridge’s frontend, a user sends ERC20 assets to an Ethereum address controlled by the Bridge. The Bridge indexes this transaction and mints an equal amount of the corresponding wrapped ERC20 to the same address on the Avalanche C-chain. Conveniently, the same private keys control the public addresses across both the Avalanche C-Chain and Ethereum Network. The wrapped funds can subsequently be unwrapped and burned via a smart contract call on the Avalanche side, which tells the Bridge to release funds to the corresponding Ethereum wallet. By reducing the on-chain requirements to a single action performed by a single on-chain identity, the Avalanche Bridge dramatically reduces the gas and on-chain complexity required to perform cross-chain transfers.
https://medium.com/media/df8b0ba1710c53df4ee3deb4089b25ae/href
How does the Avalanche Bridge work?
The Bridge can be broken down into two main parts: the SGX application and a set of third-party indexers and verifiers called “Wardens.” The Wardens are responsible for indexing the Avalanche and Ethereum blockchains and submitting eligible transactions to the enclave for processing. The Wardens 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 wardens. The Bridge’s frontend calculates these requirements in real-time in order to prevent users from sending ineligible transactions.
The SGX application requires 3 of 4 Wardens 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 warden 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 Wardens 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 Wardens will be encrypted and verified using TLS and include an HMAC signature. For relaying information to the Bridge user base, each warden hosts a JSON file containing the current bridge settings, assets requirements, and attestation report. The frontend 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 Wardens.
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 warden will perform attestation upon startup and post the report to a public JSON file.
The enclave communicates directly with the wardens 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 4 wardens. The sharing process starts with the enclave using TLS to verify the identity of each warden. Each time the enclave starts up or the wardens receive a request for their shares, each warden 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 warden) to individually encrypt each share before sending them to the wardens.
On restart, the enclave requests the shares from the wardens over a TLS connection, requiring 3 of 4 to recompute the master secret. After attestation, the warden 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).
Warden
The Warden 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 Wardens’ responsibilities are broken down below:
- Storing secret shares: Each warden 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 Wardens 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 Wardens 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 warden 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 wardens are responsible for tracking wrapping and unwrapping transactions that have been processed by the enclave. Once the enclave receives a warden consensus on an eligible transaction, it kicks off a two-phase commit process. The first commit sends an encrypted signed transaction to each warden 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 warden for processing. Upon receiving the signed transaction, the Warden 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 Warden 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 Wardens to publicly host that information. In addition, the Wardens are responsible for hosting an attestation report for public consumption. Each warden posts this information to a publicly accessible S3 file, which can be used for independent verification.
- Verify Enclave Codebase: Through remote attestation, each warden is able to verify the hash of the enclave’s binary code. The Wardens 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 Warden partners must explicitly approve the new hash and add it to a local configuration file on the warden 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.
Conclusion
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 warden 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.
Project Contributors
https://medium.com/media/b8a596544f943e3618682869c7e2f97a/href
About Avalanche
Avalanche is the fastest smart contracts platform in the blockchain industry, as measured by time-to-finality, and has the most validators securing its activity of any proof-of-stake protocol. Avalanche is blazingly fast, low cost, and eco-friendly. Any smart contract-enabled application can outperform its competition by deploying on Avalanche. Don’t believe it? Try an app on Avalanche today.
Website | Whitepapers | Twitter | Discord | GitHub | Documentation | Forum | Avalanche-X | Telegram | Clubhouse | Facebook | LinkedIn | Reddit | YouTube
About Ava Labs
Ava Labs makes it simple to launch finance applications using blockchain technology–with highly scalable and efficient networks, customizable public and private blockchains, the capability to create any digital asset, and more. We are empowering people to build an open, simple, and democratic internet of finance.
Ava Labs was founded by Cornell computer scientists who brought on talent from Wall Street to execute their vision. The company has received funding from leading investors like Andreessen Horowitz, Initialized Capital, Galaxy Digital, Bitmain, and Polychain Capital, with angel investments from Balaji Srinivasan and Naval Ravikant. www.avalabs.org
Avalanche Bridge: Secure Cross-Chain Asset Transfers Using Intel SGX was originally published in Avalanche on Medium, where people are continuing the conversation by highlighting and responding to this story.
