Howdy everyone, just an update on our progress:
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.