A while back, we completed the re-architecture of our bridge to support BridgeHub, AssetHub, and XCMv3. Please read the following for more details: https://docs.snowbridge.network/architecture/
The Ethereum side of our bridge (also known as the Gateway), is now completely governed by Polkadot OpenGov on the Polkadot side of the bridge. This means there are no governance fallbacks or escape hatches on the Ethereum side. We found a way to make it work.
The main audit of our code has been completed, and after a QA process, we can expect the final report to be published some time next month. We’re working on several issues discovered in the audit. However these are largely straightforward fixes and don’t impact our timelines substantially. Some of the more important audit issues include:
On BridgeHub, a permissionless API (create_agent) could be used as DOS vector. The solution involves requiring a deposit for the use of this API.
On BridgeHub, Administrative commands to the Ethereum side of the bridge could be throttled and delayed. The solution involves giving these admin commands priority in the outbound queue to Ethereum.
On BridgeHub, Incoming messages from Ethereum could be silently discarded if there was HRMP congestion between BridgeHub and the final destination parachain. The solution involves failing the entire substrate transaction, so that message relayers back-off until congestion resolves.
With help from W3F and CommonPrefix, we’ve designed improvements that increase the security of our BEEFY light client running on Ethereum. The light client uses RANDAO on Ethereum PoS as a source of randomness for selecting a subset of BEEFY validators which relayers must provide signatures for. The solution forces relayers to provide increasingly larger number of signatures if they attempt to game the system in a way that biases the selected RANDAO seed in their favour.
We’ve successfully tested bidirectional ERC20 token transfers between Rococo and Goerli (An ethereum PoS testnet). We’ll want to start testing with other Rococo parachains soon.
As an estimation, we’re looking at another month of development before starting the process of deploying on Kusama. Since our bridge lives on a system parachain (BridgeHub), we need to align with Parity’s release process for system parachains.
Fixing remaining audit issues (should not take longer than 2-3 weeks)
Updating to latest Polkadot-SDK dependencies which includes new BridgeHub & AssetHub APIs we have to consume.
Merging portions of our codebase into the bridges subproject of the Polkadot-SDK monorepo
Some outstanding issues relating to collecting XCM delivery fees on BridgeHub
We also require that BEEFY is deployed and activated on Kusama first.
To be clear, while the core of our bridge is designed to be general-purpose, we are launching features in an iterative manner. Our initial launch will include ERC20 token transfers. A subsequent upgrade post-launch will enable XCM::Transact. Followed by support for transferring Polkadot-native tokens to Ethereum. We believe this iterative process increases the security of the bridge by allowing our team and our auditors to focus on one feature at a time. Nevertheless, we’ve made sure our core architecture and APIs are flexible enough to support this iterative model. For example, on Ethereum, our Gateway.sendToken API will be used to send both Ethereum-native and Polkadot-native tokens to Polkadot
I’ll be presenting at Sub0 next week. We’ll also have a demo booth where people can try out our Rococo bridge.
Hearty congratulations! Its a very long road, I hope you guys enjoy the sweat and tears of the journey =)
Can you write up how this works here (and update snowbridge governance), specifically sharing the timing of regular vs emergency actions that you anticipate could be needed?
Some easy basic FAQ stuff:
Does registerToken (of ERC20 vs Assethub tokens) require an explicit OpenGov action?
What does a parachain need to do to get their AssetHub / Polkadot native asset as an ERC20?
How can the bridge/gateway be paused/resumed?
Congratulations! For Rococo Assethub => Goerli Testnet, can you share the following:
working registerToken AssetHub on Rococo extrinsicID
working sendToken extrinsicID and the evidence of success (tx logs/events) on Goerli Testnet
For Goerli Testnet => Rococo Assethub, can you share the following:
Please highlight the outbound/inbound messages and post your Goerli contract addresses / Bridgehub / Assethub runtime versions so people can do a deep-dive, thank you!
Selectively pausing/resuming the Gateway on Ethereum, for example to disable outbound messages to Polkadot
Pausing/resumingspecific bridging pallets on BridgeHub. For the sake of uniformity These APIs are actually shared with Polkadot-Kusama bridge, and so we can expect to have similar governance playbooks.
Regular governance actions will include upgrading the Gateway contract (and any of its dependencies, such as our Beefy light client). The upgrades should be audited before being proposed to OpenGov.
Emergency actions would be a halting/resuming parts of the bridge, as per the APIs described above.
Does registerToken (of ERC20 vs Assethub tokens) require an explicit OpenGov action?
Nope. Token registration is permissionless. However it will require a hefty deposit to discourage spamming. Even so, malicious parties on Ethereum can pay that deposit and register fake ERC20 tokens. It’s up to indexers, users, and other parachains to exercise good judgement when deciding whether to trust a specific bridged token on AssetHub.
What does a parachain need to do to get their AssetHub / Polkadot native asset as an ERC20?
As I described in my original post, the bridge does not currently support bridging Polkadot-native tokens to Ethereum. This will be one of the priorities after our initial launch.
We do have a design mapped out, and it will be a 2-step process:
Parachain governance calls a register_token(location, metadata) extrinsic on BridgeHub using Xcm::Transact. This will send a command over to Ethereum, resulting in a new ERC20 contract being instantiated with the provided metadata (name, symbols, decimals).
The parachain can then send regular XCM asset instructions to BridgeHub, resulting in new tokens being minted in the ERC20 contract from (1).
To send Polkadot-native tokens back to Polkadot, users can use the existing Gateway.sendToken API.
We’re not quite ready to support the public in using our Rococo testnet, but in the meantime, here are some of those transactions you’ve requested .
Note that we are running our own instances of BridgeHub and Asset on Rococo until our auditing process is completed.
Bridge transfer initiated on Snowbridge AssetHub fork (Parachain 3416) to send WETH back to Goerli. (Note this extrinsic is being depreciated in favor of pallet-xcm in future versions)
.