diff --git a/docs/general/glossary.md b/docs/general/glossary.md index 123e9321291c..789c9e847ba9 100644 --- a/docs/general/glossary.md +++ b/docs/general/glossary.md @@ -691,7 +691,7 @@ parachains. For developers, see the Parachains that are part of the Polkadot core protocol. These are allocated a parachain execution core by governance rather than by auction. Examples of system parachains include -[Asset Hub](../learn/learn-assets.md), [Bridge Hub](../learn/learn-bridge-hub.md), +[Asset Hub](../learn/learn-assets.md), [Bridge Hub](../learn/learn-system-chains.md#bridge-hub), [Collectives](../learn/learn-system-chains.md#collectives) and People Chain. ## Tabling diff --git a/docs/learn/learn-bridge-hub.md b/docs/learn/learn-bridge-hub.md deleted file mode 100644 index 2b57c0a30638..000000000000 --- a/docs/learn/learn-bridge-hub.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -id: learn-bridge-hub -title: Bridge Hub -sidebar_label: Bridge Hub -description: Overview of the Bridge Hub System Parachain. -keywords: [Bridge, XCM, Bridge Hub] -slug: ../learn-bridge-hub ---- - -The primary functionality of the {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} -relay chain is to secure the parachains and facilitate secure communication between them. All other -functionalities like asset transfers, governance, identities and bridging (a potentially resource -intensive task) can benefit from operating separately on -[system parachains](./learn-system-chains.md). System parachains are responsible for delegating -functionality away from the relay chain for peformance reasons, taking advantage of the inherent -parallelization the architecture of Polkadot provides. - -The Bridge Hub system parachain operates on -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }}, and is responsible for faciliating -bridges to the wider Web3 space. It contains the required bridge -[pallets](../general/glossary.md#pallet) in its runtime, which enable trustless bridging with other -blockchain networks like {{ polkadot: Kusama :polkadot }}{{ kusama: Polkadot :kusama }} and Ethereum -. The Bridge Hub uses the native token of the relay chain, -{{ polkadot: DOT :polkadot }}{{ kusama: KSM :kusama }}. - -## Trustless Bridges on Bridge Hub - -A two-way trustless bridge between chains A and B can be viewed as two one-way bridges (A → B and B -→ A). Hence, the design of a two-way bridge can be explained in terms of a one-way bridge with a -source and a target chain. Any bridge operating on the Bridge Hub will have on-chain (pallets) and -offchain (relayers) components. - -Examples of trustless bridges on Bridge Hub include: - -- Snowfork, a decentralized bridge between Polkadot and Ethereum -- [The Polkadot-to-Kusama Bridge](./learn-DOT-KSM-bridge.md) - -### On-chain Bridge Components - -On-chain bridge components are modules (pallets or smart contracts) that are deployed on the chain's -runtime. Modules that track the finality of the source chain are required to be deployed on the -target chain, while the modules that deal with cross-chain messaging need to be deployed on both, -source and target chains. - -Operating a bridge between chains that finalize through GRANDPA consensus is straight-forward. A -GRANDPA light client of the source chain built into the target chain's runtime provides a "source of -truth" about the source chain's finality. For instance, Polkadot Bridge Hub runs an on-chain light -client of Kusama which uses GRANDPA consensus and infers the finality of all the transactions on -Kusama and its parachains. - -Operating a bridge between chains with different consensus models can require a sophisticated -design. For instance, {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} Bridge Hub -needs to run an on-chain light client of Ethereum to infer the finality of transactions on Ethereum -chain. On the other hand, running a GRANDPA light client through smart contracts on Ethereum is -possible but can be very expensive. Hence, BEEFY (Bridge Efficiency Enabling Finality Yielder) -consensus layer has been added to {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} -which enables a cost effective solution for operating a trustless bridge with Ethereum. Trustless -bridges to chains like Solana, Cosmos, Avalanche, NEAR etc. would require custom pallets to be -deployed on {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} Bridge Hub. - -There are also on-chain components that are responsible for queuing messages at the source chain and -for receiving the messages proofs at the target chain. The messages are sent through a particular -**lane**, where they are guaranteed to be received in the same order they are sent. On -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} Bridge Hub, the messages are in XCM -format and an XCM executor is used to dispatch them. - -### Offchain Bridge Components - -Offchain bridge components are separate processes, called relayers. Relayers are connected both to -the source chain and target chain nodes. For instance, the task of relayer between chains that run -on GRANDPA consensus is to submit source chain GRANDPA justifications and their corresponding -headers to the Bridge GRANDPA Finality Pallet deployed at the target chain. For that, the relayer -subscribes to the source chain GRANDPA justifications stream and submits every new justification it -sees to the target chain GRANDPA light client. - -Messages between chains are relayed through the relayers, which involve messages delivery relay and -delivery confirmation relay. For more information on relayers and the Bridge Hub design, read -through the -[high level documentation on bridges on the Polkadot-SDK repository](https://github.com/paritytech/polkadot-sdk/blob/master/bridges/docs/high-level-overview.md). diff --git a/docs/learn/learn-bridges.md b/docs/learn/learn-bridges.md index 0f654eeefd33..076c73726fc0 100644 --- a/docs/learn/learn-bridges.md +++ b/docs/learn/learn-bridges.md @@ -9,76 +9,108 @@ slug: ../learn-bridges import DocCardList from '@theme/DocCardList'; -A cornerstone technology of blockchain interoperability is the blockchain bridge. Blockchain bridges -are ways for two economically sovereign and technologically diverse chains to communicate with each -other. Bridge designs come in a variety of flavors ranging from centralised and trusted to more -decentralised and trustless. Polkadot favors the latter bridge designs for its ecosystem. However, -there is nothing that blocks a development team from building and deploying the former. - -While bridge designs are now getting to a place where they are sufficiently planned out, there have -not been too many used heavily in production. For this reason, you can consider this page a work in -progress. It will be updated as more information is determined and available. +Bridges are vital infrastructure, enabling cross-chain communication between technically diverse +networks like Polkadot and Ethereum. Bridges allow these chains to acknowledge and trust each +other’s finalized states, paving the way for many applications like asset swaps and chain +migrations. + +Current bridge architectures rely on centralized intermediaries, such as multi-signature relayers, +to validate information passed between chains. This approach introduces additional trust assumptions +and creates a single point of failure, opening up attack vectors like censorship. Recent history has +shown how risky this can be — centralized entities can be compromised or act maliciously. According +to [Chainalysis report](https://www.chainalysis.com/blog/cross-chain-bridge-hacks-2022/), failures +in centralized bridges account for over 60% of all crypto hacks, resulting in losses exceeding $2 +billion. Four of the top five incidents on the [rekt leaderboard](https://rekt.news/tr/leaderboard/) +are bridge-related hacks. A system’s security is only **as strong as its weakest link**, and bridges +have proven to be a critical vulnerability. :::info Purpose of bridging -Bridges are specifically for making the -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} ecosystem compatible with external -blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCM, the native -interoperability technology that allows parachains to communicate trustlessly, please see the +Bridges enable Polkadot to communicate with external blockchains such as Bitcoin and Ethereum. +Within Polkadot, chains already benefit from secure interoperability. For more information about the +native interoperability technology that allows parachains to communicate trustlessly, please see the dedicated [cross consensus](learn-xcm.md) page on the Wiki. ::: +Thus, Bridge designs come in various flavors ranging from centralized and trusted to more +decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem. + -## Bridging Methods +## Trustless Bridges + +A two-way trustless bridge between chains A and B can be viewed as two one-way bridges (A → B and B +→ A). Hence, the design of a two-way bridge can be explained in terms of a one-way bridge with a +source and a target chain. Any trustless bridge will have **on-chain and off-chain components**. + +Trustlessness means that users do not need to trust particular individuals or organizations; they +only need to trust mathematics, code, cryptography, and protocol. An example of a system which +implies a high level of trust would be that of a bridge which is controlled via a multi-signature +scheme, wherein you must trust the cosignatories. -Building a bridge that is as decentralised and trustless as possible can be done through any of the -following methods (ordered by suggested methodology): +Basic assumptions are always needed in principle when defining a trustless system as a completely +trustless setup cannot always be guaranteed. -- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (e.g. Kusama `<->` Polkadot - bridge, since both networks' parachains use Substrate). +## On-chain Bridge Components + +Building a trustless bridge can be done through the implementation of the following on-chain +components (ordered by suggested methodology): + +- _Bridge pallets_ - For Substrate-native chains, use a bridge pallet (e.g. + [Kusama `<->` Polkadot bridge](./learn-DOT-KSM-bridge.md), since both networks' parachains use + Substrate). - _Smart contracts_ - If the chain is not on Substrate, you should have smart contracts on the - non-Substrate chain to bridge (e.g. Ethereum mainnet will have a bridge smart contract that - initiates Eth transactions based on incoming XCMP messages). + non-Substrate chain to bridge (e.g. [Snowbridge](./learn-snowbridge.md), Ethereum mainnet has a + bridge smart contract that initiates Eth transactions based on incoming XCMP messages). - _Higher-order protocols_ - If your chain does not support smart contracts (e.g. Bitcoin), you should use [XClaim](https://eprint.iacr.org/2018/643.pdf) or similar protocols to bridge. +On-chain bridge components are modules (usually pallets or smart contracts) deployed on the chain's +runtime. Modules that track the finality of the source chain are required to be deployed on the +target chain, while the modules that deal with cross-chain messaging need to be deployed on both +source and target chains. + +There are also on-chain components responsible for queuing messages at the source chain and +receiving the message proofs at the target chain. The messages are sent through a particular lane, +where they are guaranteed to be received in the same order they are sent. On Bridge Hub, the +messages are in XCM format, and an XCM executor is used to dispatch them. + ### via Bridge Pallets -Receiving messages on {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} from an -external, non-parachain blockchain can be possible through a Substrate pallet. The Substrate -instance can then be deployed to {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} -either as a system-level parachain (native extension to the core -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} software) or as a community-operated -parachain. +Operating a bridge between chains that finalize through GRANDPA consensus is straightforward. A +GRANDPA light client of the source chain built into the target chain's runtime provides a "source of +truth" about the source chain's finality. For instance, +[Bridge Hub](./learn-system-chains.md#bridge-hub) runs an on-chain light client of Kusama which uses +GRANDPA consensus and infers the finality of all the transactions on Kusama and its parachains. + +Receiving messages on Polkadot from an external, non-parachain blockchain is possible through a +Substrate pallet. The Substrate instance can then be deployed to Polkadot either as a system-level +parachain (native extension to the core Polkadot software) or as a community-operated parachain. -An example of a bridge that would strictly use bridge pallets would be a Kusama `<->` Polkadot -bridge, since both use parachains based on Substrate. +An example of a bridge that would strictly use bridge pallets would be +[the Kusama `<->` Polkadot bridge](./learn-DOT-KSM-bridge.md), since both use parachains based on +Substrate. -For the standalone chains that will not have a parachain bridging module on -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} (non-Substrate), it will be necessary -to deploy bridge contracts (see below). +For the standalone chains that will not have a parachain bridging module (non-Substrate), it will be +necessary to deploy bridge contracts. ### via Smart Contracts Given the generality of blockchain platforms with Turing-complete smart contract languages, it is -possible to bridge {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} and any other -smart contract capable blockchain. - -Those who are already familiar with Ethereum may know of the now archived -[Parity Bridge](https://github.com/paritytech/parity-bridge) and the efforts being made to connect -PoA sidechains to the Ethereum mainnet. The Parity bridge is a combination of two smart contracts, -one deployed on each chain, that allow for cross-chain transfers of value. As an example of usage, -the initial Parity Bridge proof of concept connects two Ethereum chains, `main` and `side`. Ether -deposited into the contract on `main` generates a balance denominated in ERC-20 tokens on `side`. -Conversely, ERC-20 tokens deposited back into the contract on `side` can free up Ether on `main`. +possible to bridge Polkadot and any other smart-contract-capable blockchain. For instance, +[Snowbridge](./learn-snowbridge.md) uses the Polkadot Bridge Hub to run an on-chain light client of +Ethereum to infer the finality of transactions on the Ethereum chain. Running a GRANDPA light client +through smart contracts on Ethereum is possible but expensive. Hence, +[BEEFY consensus layer](./learn-consensus.md#bridging-beefy) sitting on top of GRANDPA enables a +cost-effective solution for operating a trustless bridge with Ethereum and other protocols. +Trustless bridges to chains like Cosmos, Avalanche, NEAR, etc., would require custom pallets to be +deployed on Bridge Hub. :::note -To learn more on how Bitcoin and Ethereum can cooperate and collaborate Through -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }}, check out this explainer video -[here](https://www.youtube.com/watch?v=rvoFUiOR3cM) +To learn more on how Bitcoin and Ethereum can cooperate and collaborate through Polkadot, check out +this explainer video [here](https://www.youtube.com/watch?v=rvoFUiOR3cM) ::: @@ -90,43 +122,75 @@ swappable asset to be backed by a collateral of higher value than the swappable additional overhead. An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since -it does not support smart-contracts and it's not based on Substrate. - -## Examples - -### Ethereum Bridge (Smart Contracts <-> Polkadot) - -As explained by Dr. Gavin Wood in a -[blog post](https://medium.com/polkadot-network/polkadot-substrate-and-ethereum-f0bf1ccbfd13) from -late 2019, there are three ways that the -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} and Substrate ecosystem can be -bridged to the Ethereum ecosystem. - -1. {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} <-> Ethereum Public Bridge. -1. Substrate <-> Parity Ethereum (Openethereum) Bridge. -1. The Substrate EVM module. +it does not support smart contracts, and it's not based on Substrate. -Please read the blog article for fuller descriptions of each one of these options. - -### Bitcoin Bridge (XCLAIM <-> Substrate <-> Polkadot) +#### Bitcoin Bridge (XCLAIM <-> Substrate <-> Polkadot) The Interlay team has written a [specification](https://spec.interlay.io/) on a Bitcoin bridge that is based on the [XCLAIM](https://eprint.iacr.org/2018/643.pdf) design paper. The protocol enables a -two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to "teleport" their assets to -Polkadot as iBTC, and holders of iBTC to burn their assets for BTC on the Bitcoin chain. +two-way bridge between Polkadot and Bitcoin. It allows holders of BTC to issue iBTC in Polkadot and +holders of iBTC to redeem BTC on the Bitcoin chain. The Bitcoin bridge, as documented in the specification, is composed of two logically different components: - The XCLAIM component maintains all accounts that own iBTC. -- The BTC-Relay is responsible for verifying the Bitcoin state when a new transaction is submitted. +- The BTC-Relay verifies the Bitcoin state when a new transaction is submitted. For full details on how it works, please refer to the specification. There is now a [working implementation and mainnet bridge available](https://app.interlay.io/btc?tab=issue). -## Additional Resources and Examples +## Offchain Bridge Components + +Offchain bridge components are separate processes called relayers. Relayers are connected both to +the source chain and target chain nodes. For instance, the task of relayer between chains that run +on GRANDPA consensus is to submit source chain GRANDPA justifications and their corresponding +headers to the Bridge GRANDPA Finality Pallet deployed at the target chain. For that, the relayer +subscribes to the source chain GRANDPA justifications stream and submits every new justification to +the target chain GRANDPA light client. + +Messages between chains are relayed through the relayers, which involve messages delivery relay and +delivery confirmation relay. For more information on relayers and the Bridge Hub design, read +through the +[High-level bridge documentation on the Polkadot-SDK repository](https://github.com/paritytech/polkadot-sdk/blob/master/bridges/docs/high-level-overview.md). + +## Bridge Comparison + +[Snowbridge](./learn-snowbridge.md) and [Hyperbridge](./learn-hyperbridge.md) are two trustless +bridges that connect Polkadot with other ecosystems. Here below is a main technical comparison +between the two. + +:::danger Tokens sent through different bridges are different + +Unless specific logic is implemented, WETH sent through Snowbridge cannot be sent back using +Hyperbridge, and _vice versa_. **Sending tokens using different bridges might lead to loss of +funds.** + +::: + +| Snowbridge | Hyperbridge | +| :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | +| Ethereum only1. | Multichain. | +| Ethereum light client on [Bridge Hub System Chain](./learn-system-chains.md#bridge-hub)2 and Polkadot light client on Ethereum smart contract. | Own parachain. | +| [DOT token](./learn-DOT.md). | Hyperbridge native token. | +| [Random-sampling BEEFY](./learn-snowbridge.md#random-sampling-beefy) for prover. | Zero-knowledge Proofs. | +| Simple codebase but complex analysis by the verifier. | Complex codebase, but simple analysis by the verifier. | +| Low-spec hardware for prover, permissionless. | High-spec hardware for prover, permissionless but somewhat permissioned due to the ZK-based nature. | +| Possible high-level decentralization for the prover. | Prover decentralization possible but probably by removing dependency on ZK circuits through BLS ([Boneh–Lynn–Shacham](https://en.wikipedia.org/wiki/BLS_digital_signature)) version of BEEFY and BLS precompiles on Ethereum. | +| High latency as two epochs ([tens of minutes](https://app.snowbridge.network/status)) are needed on Ethereum to achieve unpredictable randomness to update the Polkadot's state. | Low latency, 5-7 minutes on reference hardware. | +| No dependency on external libraries. | Dependency on external libraries due to ZK-based nature. Such libraries include [PLONK](https://eprint.iacr.org/2019/953.pdf). | +| Live. | On Testnet. | + +1 WETH sent through different bridges are different. Unless specific logic is +implemented, WETH sent through Snowbridge cannot be sent back using Hyperbridge.

+ +2 Because Snowbridge is deployed on a system chain, Snowbridge WETH can be considered as +the "official" WETH on Polkadot (although this must not be interpreted as a positive sign for +Snowbridge and negative sign for Hyperbridge).

+ +## Resources - [Snowbridge - a trustless, decentralized bridge between Polkadot and Ethereum](https://docs.snowbridge.network/) - [Parity Bridges Common Resources](https://github.com/paritytech/parity-bridges-common) @@ -148,12 +212,13 @@ There is now a [Wave 5](https://medium.com/web3foundation/web3-foundation-grants-wave-5-recipients-2205f4fde096) to build a trust-minimized BTC bridge. - [ChainX BTC Bridge](https://github.com/chainx-org/ChainX/tree/master/xpallets/gateway/bitcoin) - - ChainX have implemented a BTC to Substrate bridge for their parachain. + ChainX has implemented a BTC to Substrate bridge for their parachain. - [POA Network](https://poa.network/) - [Case study](https://medium.com/giveth/ethereum-dapp-scaling-poa-network-acee8a51e772) of POA Network's implementation of Parity's bridge chain solution. - [Edgeth Bridge](https://github.com/hicommonwealth/edgeth_bridge/) - a bridge from Ethereum to - Edgeware chain (a Substrate-based chain) - now defunct and not maintained, but a good example. + Edgeware chain (a Substrate-based chain) is now defunct and not maintained, but it is a good + example. - [XCLAIM](https://eprint.iacr.org/2018/643.pdf) - XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets. - [Celer cBridge](https://github.com/celer-network/cBridge-contracts) - a bridge to transfer assets diff --git a/docs/learn/learn-consensus.md b/docs/learn/learn-consensus.md index 9807981fc8f2..e8ab26a0d328 100644 --- a/docs/learn/learn-consensus.md +++ b/docs/learn/learn-consensus.md @@ -193,31 +193,24 @@ The two main differences between GRANDPA and Casper FFG are: ## Bridging: BEEFY The BEEFY (Bridge Efficiency Enabling Finality Yielder) is a secondary protocol to GRANDPA to -support efficient bridging between the -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} network (relay chain) and remote, -segregated blockchains, such as Ethereum, which were not built with the -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} interchain operability in mind. The -protocol allows participants of the remote network to verify finality proofs created by the -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} relay chain validators. In other -words: clients in the Ethereum network should be able to verify that the -{{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} network is at a specific state. +support efficient bridging between relay chains (Polkadot and Kusama) and remote, segregated +blockchains, such as Ethereum, which were not built with the Polkadot native interoperability in +mind. The protocol allows participants of the remote network to efficiently verify finality proofs +created by validators on the relay chain, i.e. clients in the Ethereum network can verify that the +Polkadot network is at a specific state. Storing all the information necessary to verify the state of the remote chain, such as the block -headers, is too expensive. BEEFY addresses the limitations of GRANDPA finality for certain use -cases, such as bridges to chains like Ethereum, by providing a more lightweight and efficient -finality solution. +headers, is too expensive. In BEEFY, all honest validators sign on a GRANDPA finalized block. This +reduces the efforts on the light client side, as tracking forks, GRANDPA justifications, etc., is no +longer necessary. Moreover, BEEFY utilizes Merkle Mountain Ranges (MMR) as an efficient data +structure for storing and transmitting block headers and signatures to light clients and the ECDSA +signature schemes (more efficiently verifiable on EVM). Light clients now only have to check if the +block has a super-majority of BEEFY votes by validators. -BEEFY operates on top of GRANDPA, utilizing a consensus extension and a light client protocol. This -allows for smaller consensus justifications and efficient communication between nodes. It utilizes -Merkle Mountain Ranges (MMR) as an efficient data structure for storing and transmitting block -headers and signatures to light clients. Payload, signed commitment, and witness data are essential -for verifying finality proofs. +Overall, BEEFY addresses the limitations of GRANDPA finality for bridges to chains like Ethereum by +providing a more lightweight and efficient finality solution. -Overall, BEEFY aims to enhance the efficiency and reliability of cross-chain communication within -the {{ polkadot: Polkadot :polkadot }}{{ kusama: Kusama :kusama }} ecosystem by providing a -lightweight finality solution compatible with a variety of target chains. - -For additional implementation details, see +For additional implementation details about BEEFY, see [the Polkadot Specification](https://spec.polkadot.network/#sect-grandpa-beefy). ## Resources diff --git a/docs/learn/learn-hyperbridge.md b/docs/learn/learn-hyperbridge.md index b5c8699c0fae..42587bac5795 100644 --- a/docs/learn/learn-hyperbridge.md +++ b/docs/learn/learn-hyperbridge.md @@ -122,24 +122,19 @@ For example, Consensus Proofs in a proof of stake system are given as the signat block header in the chain from a supermajority (two-thirds plus one) subset of the full authority set. -## Learn More +## Resources -The information provided here is subject to change; keep up to date using the following resources: +To learn more about Hyperbridge, see the resources below. - [Introducing Hyperbridge: An Interoperability Coprocessor](https://blog.polytope.technology/introducing-hyperbridge-interoperability-coprocessor) - Article by Seun Lanlege, Polytope Lab founder. +- [Hyperbridge: The New Interoperability Coprocessor on Polkadot](https://medium.com/simplystaking/hyperbridge-the-new-interoperability-coprocessor-on-polkadot-b532ae622d8e) - + Article by Erik from Simply Staking - [Digital Services as State Machines](https://polkadot-blockchain-academy.github.io/pba-book/blockchain-contracts/services-as-state-machines/page.html) - Lecture about state machine from Polkadot Blockchain Academy -- [Polkadot Wiki - Bridges](https://wiki.polkadot.network/docs/learn-bridges) - Learn about bridges - in Polkadot -- [Polkadot Wiki - Parachain](https://wiki.polkadot.network/docs/learn-parachains) - Learn about - parachain in Polkadot - [Hyperbridge Source Code](https://github.com/polytope-labs/hyperbridge) - Public codebase repository of hyperbridge. - [Interoperable State Machine Protocol (ISMP) Book](https://ismp.polytope.technology/) - Guidebook of the ISMP - [The Puzzle of Blockchain Interoperability](https://twitter.com/stakenode_dev/status/1744653040764817675) -- [RFC-1: Agile Coretime](https://github.com/polkadot-fellows/RFCs/blob/6f29561a4747bbfd95307ce75cd949dfff359e39/text/0001-agile-coretime.md) - - Agile periodic-sale-based model for assigning Coretime on the Polkadot Ubiquitous Computer. - [ISMP, The Endgame for Parachain Interoperability | Sub0 2023](https://www.youtube.com/watch?v=MCOAwooWecs) -- [Research Summary: PlonK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge](https://www.smartcontractresearch.org/t/research-summary-plonk-permutations-over-lagrange-bases-for-oecumenical-noninteractive-arguments-of-knowledge/382) diff --git a/docs/learn/learn-parachains.md b/docs/learn/learn-parachains.md index abcc39413e18..c269ed64f702 100644 --- a/docs/learn/learn-parachains.md +++ b/docs/learn/learn-parachains.md @@ -366,11 +366,11 @@ networks that can quickly gossip the message across the networks. Due to the necessary latency in sending crosschain messages, some parachains plan to become _hubs_ for an entire industry (see the [Asset Hub](./learn-assets.md) and -[Bridge Hub](./learn-bridge-hub.md)). For example, many DeFi applications could take advantage of a -property known as _composability_ which means that functions of one application can be -synergistically composed with others to create new applications. One example of this includes flash -loans, which borrow funds to execute some on-chain logic as long as the loan is repaid at the end of -the transaction. +[Bridge Hub](./learn-system-chains.md#bridge-hub)). For example, many DeFi applications could take +advantage of a property known as _composability_ which means that functions of one application can +be synergistically composed with others to create new applications. One example of this includes +flash loans, which borrow funds to execute some on-chain logic as long as the loan is repaid at the +end of the transaction. An issue with crosschain latency means that composability property weakens among parachains compared to a single blockchain. **This implication is common to all sharded blockchain designs, including diff --git a/docs/learn/learn-snowbridge.md b/docs/learn/learn-snowbridge.md index 9893c5689d83..fa48414d7782 100644 --- a/docs/learn/learn-snowbridge.md +++ b/docs/learn/learn-snowbridge.md @@ -7,36 +7,86 @@ keywords: [Bridge, XCM, Bridge Hub, Snowbridge, Snowfork] slug: ../learn-snowbridge --- -Snowbridge by [Snowfork](https://snowfork.com/) is a general-purpose, trustless bridge between -Polkadot and Ethereum. It utilizes the [Bridge Hub system parachain](./learn-bridge-hub.md) to -establish a connection to its relayers, allowing for permissionless messaging between Ethereum and -Polkadot. +:::info Using Snowbridge -## Trustlessness in Snowbridge +Snowbridge can be accessed through [the web app](https://app.snowbridge.network/), where you may +track [processing times of transactions](https://app.snowbridge.network/status), +[recent transfers](https://app.snowbridge.network/history), and other information about the bridge's +overall status. -Trustlessness here is defined in the sense that the users do not need to trust any particular -individuals or organizations, but rather only the mathematics, code, cryptography, and protocol. An -example of a system which implies a high level of trust **trust** would be that of a bridge which is -controlled via a multi-signature scheme, wherein you must trust the cosignatories. +::: -Basic assumptions are always needed in principle when defining a trustless system, as a completely -trustless setup cannot always be guaranteed. +Snowbridge by [Snowfork](https://snowfork.com/) is a general-purpose, trustless bridge between +Polkadot and Ethereum. It utilizes the +[Bridge Hub system parachain](./learn-system-chains.md#bridge-hub) to establish a connection to its +relayers, allowing for permissionless and trustless messaging between Ethereum and Polkadot. -With Snowbridge, a sender can always run a +With Snowbridge, a sender can (but does not need to) run a [relayer](https://docs.snowbridge.network/architecture/relayers) to ensure that their cross-chain -transaction is successful. - -## Applications +transaction is successful. A sender is a user using relayers provided by others. Snowbridge currently supports [two-way token transfers](https://docs.snowbridge.network/applications/token-transfers) between Ethereum and Polkadot parachain. -## Accessing & Using Snowbridge +## Random-sampling BEEFY -Snowbridge can be accessed through [the web app](https://app.snowbridge.network/), where you may -track [processing times of transactions,](https://app.snowbridge.network/status), -[recent transfers](https://app.snowbridge.network/history), and other information about the bridge's -overall status. +A trustless bridge always has a **prover** (needs to compute the proof), a **verifier** (asks the +prover to compute the proof and verifies it), and relayers to relay messages. Snowbridge prover uses +[BEEFY](./learn-consensus.md#bridging-beefy), a novel bridge protocol drastically reducing +operational costs without compromising security. + +Even with simplifications ushered in by BEEFY, a smart contract updating Polkadot's state on +Ethereum has to perform 201 signature checks for every update since there are ~300 validators on +Polkadot. This remains expensive (gas costs), especially as the validator set grows. The solution is +random-sampling BEEFY that leverages +[the RANDAO randomness beacon](https://eth2book.info/capella/part2/building_blocks/randomness/) as +follows: + +- **Commit:** Relayer submits a state commitment of a recently finalized block on Polkadot and + claims to have a super-majority of validator’s signatures to the light client deployed on + Ethereum. It also provides one validator signature backing the commitment, which can be slashed if + needed. +- **Challenge:** Light client queries on-chain randomness (RANDAO) to subsample `m` (~25) signatures + from the list Relayer’s claimed list. +- **Response:** Relayer responds by sharing exactly those `m` signatures that were randomly sampled + which the light client then verifies. If everything checks out, the finalized block is accepted. + +The number of signature checks needed is significantly reduced and independent of the validator set +size, making the protocol more efficient. The number of subsampled signatures, `m,` is the parameter +that trades off security and efficiency (i.e., **security parameter**). The value of this parameter +is derived using crypto-economic arguments. + +## Snowbridge Crypto-economic Security + +If up to a third of the validators are malicious, the chance that all `m` signatures subsampled are +from these bad actors is `(1/2)^m` (exponentially low). Any validator who supports a malicious +commitment [faces severe penalties](./learn-offenses.md). The expected value of an attack `E(A)` is: + +``` +E(A) = p * V + (1 - p)*(-S) +``` + +Where `V` is the value of attack (bounded by market capitalization), `S` is the validator slashable +stake, and `p` is the probability of a successful attack. + +### Snowbridge Assumptions + +Snowbridge relies on two major assumptions: + +- The crypto-economic assumption that an adversary is rational, i.e., an attack is launched only if + the expected value of an attack is positive. Hence, we derive our security parameter `m` by + ensuring the expected value of an attack is negative, i.e., `E(A) < 0`. + +- RANDAO unpredictability. The Web3 Foundation research team performed a thorough analysis of RANDAO + bias and extended the state-of-the-art in analysing the last-revealer attack on RANDAO. Assuming + 1/3rd of Ethereum validators are malicious, the effect of such bias is mitigated by proportionally + increasing the security parameter. + +## Resources -To create transfers, you may visit the [transfer page.](https://app.snowbridge.network/) +- Medium article + ["Random Sampling BEEFY: Pillaring the trust-less Snowbridge"](https://medium.com/@bhargav_22496/18a43a2cba9b) + by Bhargav Bhatt at Web3 Foundation +- [Snowbridge GitHub repository](https://github.com/Snowfork/snowbridge) +- Web3 Foundation Research Repository diff --git a/docs/learn/learn-system-chains.md b/docs/learn/learn-system-chains.md index 1afc060b0c08..8f325e9ac96c 100644 --- a/docs/learn/learn-system-chains.md +++ b/docs/learn/learn-system-chains.md @@ -10,6 +10,13 @@ slug: ../learn-system-chains import RPC from "./../../components/RPC-Connection"; import Tabs from "@theme/Tabs"; import TabItem from "@theme/TabItem"; +The primary functionality of the Relay chain is to secure the parachains and facilitate secure +communication between them. All other functionalities like asset transfers, governance, identities +and bridging (a potentially resource intensive task) can benefit from operating separately on system +chains. System chains are responsible for delegating functionality away from the relay chain for +peformance reasons, taking advantage of the inherent parallelization the architecture of Polkadot +provides. + ## Overview System parachains are those that contain core Polkadot protocol features, but in parachains rather @@ -79,15 +86,21 @@ Some of these collectives are the important roles in the future of network stewardship and decentralized governance. Networks themselves can act as collectives and express their legislative voices as single opinions -within other networks. This is achieved with the assistance from a [bridge hub](#bridge-hubs). +within other networks. This is achieved with the assistance from a [bridge hub](#bridge-hub). -### Bridge Hubs +### Bridge Hub Before Polkadot and Kusama supported their first parachains, the only way to design a bridge was to put the logic onto the Relay Chain itself. Since both networks now support parachains, it makes sense to have a parachain on each network dedicated to bridges. This is because of the execution isolation provided by parachains. +The Bridge Hub system parachain operates on the relay chain, and is responsible for faciliating +bridges to the wider Web3 space. It contains the required bridge +[pallets](../general/glossary.md#pallet) in its runtime, which enable trustless bridging with other +blockchain networks like Polkadot, Kusama and Ethereum. The Bridge Hub uses the native token of the +relay chain. + See the [Bridges page](learn-bridges.md) for information on the latest bridge projects. ### People Chain diff --git a/kusama-guide/docusaurus.config.js b/kusama-guide/docusaurus.config.js index d2268f915a64..51b4ac03f13d 100644 --- a/kusama-guide/docusaurus.config.js +++ b/kusama-guide/docusaurus.config.js @@ -129,6 +129,10 @@ module.exports = { to: '/docs/learn-transactions', from: ['/docs/learn-transaction-fees'] }, + { + to: '/docs/learn-system-chains', + from: ['/docs/learn-bridge-hub'] + }, ], createRedirects: function (existingPath) { if (existingPath.startsWith('/docs/')) { diff --git a/kusama-guide/sidebars.js b/kusama-guide/sidebars.js index d2bf3f66ed8e..675063178aef 100644 --- a/kusama-guide/sidebars.js +++ b/kusama-guide/sidebars.js @@ -471,7 +471,6 @@ module.exports = { id: "learn/learn-bridges", }, items: [ - "learn/learn-bridge-hub", "learn/learn-dot-ksm-bridge", "learn/learn-hyperbridge", ], diff --git a/polkadot-wiki/docusaurus.config.js b/polkadot-wiki/docusaurus.config.js index 194e29b123f0..710cbd53bfc0 100644 --- a/polkadot-wiki/docusaurus.config.js +++ b/polkadot-wiki/docusaurus.config.js @@ -217,6 +217,10 @@ module.exports = { to: '/docs/learn-guides-ledger', from: ['/docs/learn-guides-assets-ledger'] }, + { + to: '/docs/learn-system-chains', + from: ['/docs/learn-bridge-hub'] + }, ], createRedirects: function (existingPath) { if (existingPath.startsWith("/docs/")) { diff --git a/polkadot-wiki/sidebars.js b/polkadot-wiki/sidebars.js index 2acfe4ea1a92..15f6be97e0f2 100644 --- a/polkadot-wiki/sidebars.js +++ b/polkadot-wiki/sidebars.js @@ -545,10 +545,9 @@ module.exports = { id: "learn/learn-bridges", }, items: [ - "learn/learn-bridge-hub", - "learn/learn-dot-ksm-bridge", "learn/learn-snowbridge", "learn/learn-hyperbridge", + "learn/learn-dot-ksm-bridge", ], }, {