| Home | About John | Resume/CV | References | Writing | Research |
|---|
Snowbridge
Overview
Snowbridge is a general purpose, trustless and decentralized bridge between Polkadot and Ethereum. The goal is to launch as common-good bridge on the proposed BridgeHub parachain. Quick Links
- Bridge Type : Proof Based Validity Proofs
- Design: bridge has a layered architecture, inspired by networking protocols such as TCP/IP. At the lowest level we have channels, which send messages across the bridge. At the highest level, we have apps, which can invoke methods on apps living on foreign chains.
- Docs: Snowbridge documentation
- Implementation snowfork snowbridge: A trustless bridge between Polkadot and Ethereum.
- FronteEnd: Still Under Development
- Explorer: Can be used to review if a common good parachain is deployed. Bridge messages will be displayed as Cross Chain Messages (XCM) on this xcm dashboard.
- Roadmap: The Snowbridge Funding Proposal includes a link to the roadmap which details the milestones and rollout.
Design Notes
light-client verification polkadot
We use Polkadot’s BEEFY gadget to implement an efficient light client that only needs to verify a very small subset of relay chain validator signatures. BEEFY is live on Rococo, and is awaiting deployment on Kusama and Polkadot. Fundamentally, the BEEFY light client allows the bridge to prove that a specified parachain header was finalized by the relay chain.
BEEFY bridge pallet.
This pallet is an on-chain BEEFY light client for Substrate-based chains that are using the following pallets bundle:
pallet-mmr,pallet-beefyandpallet-beefy-mmr.The pallet is able to verify MMR leaf proofs and BEEFY commitments, so it has access to the following data of the bridged chain:
- header hashes
- changes of BEEFY authorities
- extra data of MMR leafs
Given the header hash, other pallets are able to verify header-based proofs (e.g. storage proofs, transaction inclusion proofs, etc.).
light-client verification ethereum
We have implemented a Proof-of-Stake (PoS) light client for the Beacon chain. This client deprecates the older PoW light client we developed in 2020.
The beacon client tracks the beacon chain, the new Ethereum chain that will replace Ethereum’s Proof-of-Work consensus method around mid-September, called the Merge. The work we have done consists of the following parts:
- Beacon Client pallet
- Initial chain snapshot (forms part of the Genesis Config)
- Sync committee updates
- Finalized beacon header updates
- Execution header updates
- Message verification
- Beacon Relayer
- Sends data from a beacon node to the beacon client
Code Review
Signing Mechanisms
Cryptographic Primitives
Proving Mechanisms
Relayer Mechanisms
The relays folder has multiple relayers controlled by execution. All written in go.
- Relaying from Ethereum to Polkadot
- beacon: Responsible for retrieving state from the beacon chain including
- synching:
- functions include
- GetSyncPeriodsToFetch
- GetInitialSync
- GetSyncCommitteePeriodUpdate
- GetBlockRoots
- GetFinalizedUpdate
- HasFinalizedHeaderChanged
- GetLatestFinalizedHeader
- getNextBlockRootBySlot
- GetNextHeaderUpdateBySlotWithAncestryProof
- GetNextHeaderUpdateBySlot
- GetHeaderUpdateWithAncestryProof
- getBlockHeaderAncestryProof
- GetSyncAggregate
- GetSyncAggregateForSlot
- ethereum: Responsible for retreiving block headers from the execution chain.
- beacon: Responsible for retrieving state from the beacon chain including
- Relaying from Polkadot to Etherem