Files
pezkuwi-subxt/polkadot/bridges
Andrew Jones 4c7539cab5 Companion for #8615: enrich metadata with type information (#3336)
* Use beefy branch with scale-info

* Add patches

* Sprinkle some TypeInfo derives

* Add some TypeInfo deriv

* Cargo.lock

* Derive TypeInfo and skip type params for Xcm types

* Cargo.lock

* Fix up scale_info bounds attributes

* Fix up dependencies

* Use my own beefy-primitives branch

* Bump BEEFY

* Update patches

* Add some scale-info dependencies and TypeInfo derives

* More TypeInfo decoration

* Update scale-info

* Some TypeInfos and remove more Event pallet::metadata

* Moar TypeInfos

* TypeInfos galore, fix up metadata runtime API

* TypeInfo

* TypeInfos, update other runtime metadata APIs

* Fix up Kusama, comment out some `usize` QueueSize parameter types

* Remove local diener patches

* Cargo.lock

* Cargo.lock

* Update to scale-info crates.io release

* Update primitive-types branch

* Update pallet-beefy to use custom branch

* Update other parity-common deps

* Update parity-common patches

* bump a bunch of deps in parity-common

* Remove parity-common patches

* Bump finality-grandpa version

* Cargo.lock

* Update scale-info to 0.9.1

* Add recursion_limit for runtime-parachains

* Add some scale_info attributes

* Cargo.lock

* Revert finality-grandpa bump

* Cargo.lock, scale-info update

* cargo update

* Make sure using patched version of finality-grandpa

* Use patched scale-info

* Update to scale-info 0.10.0

* Update finality-grandpa

* Cargo.lock

* Update beefy deps

* Update beefy deps again

* Add scale-info dependency

* Remove deprecated pallet::metadata attributes.

* Add some missing scale-info deps and derives

* Use some variant struct call syntax

* Add missing TypeInfo impl

* Add some more TypeInfo impls

* Convert some call enum struct variant constructors

* More scale-info deps and derives

* Call enum struct variants

* TypeInfo derives

* Call enum variant structs

* scale-info deps and derives

* Call enum variant struct constructors

* Use beefy-primitives scale-info feature

* Use grandpa-bridge-gadget master branch

* Remove finality-grandpa patch

* Add missing scale_info dependency and derive

* Fix up some call variant constructors

* Add missing scale_info dependency

* Fix some test errors

* More TypeInfo derives

* More call variant structs

* Call variant structs in tests

* Cargo.lock

* Fmt

* Fix more call struct variants

* Another call struct variant

* add scale-info/std features explicitly

* More call struct variants

* Add missing scale-info dependency

* Fmt

* review: activate scale-info/std where missing

* Remove some duplicate std feature activation

* review: add scale_info bounds() attr

* More call variant structs

* Remove recursion limit

* Update beefy-primitives

* Update beefy-primitives

* Fix simnet call variant struct errors

* Fmt

* cargo update -p beefy-primitives

* Add some missing TypeInfo derives

* Fix some call variants

* Fix some call variant underscores

* Cargo.lock

* Cargo.lock

* Add missing TypeInfo derive

* Add some more missing TypeInfo derives

* Even more missing TypeInfo derives

* Add TypeInfo derives to new xcm types

* Fmt

* Cargo.lock

* Add missing TypeInfo impls

* Cargo.lock

* More missing TypeInfos

* Fixes

* Cargo.lock

* Cargo.lock

* Add TypeInfo impls to xcm v2

* Update to scale-info 1.0

* Update finality-grandpa 0.14.4, patch for now

* Update beefy

* Remove patched finality-grandpa

* Add TypeInfo impl to Outcome

* Fixes

* Call variant struct

* Call variant struct

* Fix test

* Add TypeInfo impl

* Cargo.lock

* Cargo.lock

* Cargo.lock

* git checkout master Cargo.lock

* update Substrate

* Add missing scale-info features for beefy-primitives

* Fmt

* Remove check for now

* Update beefy-primitives, removes scale-info feature

* Update beefy-primitives again

Co-authored-by: adoerr <0xad@gmx.net>
Co-authored-by: Andronik Ordian <write@reusable.software>
Co-authored-by: thiolliere <gui.thiolliere@gmail.com>
Co-authored-by: parity-processbot <>
Co-authored-by: Bastian Köcher <info@kchr.de>
2021-09-15 15:38:45 -05:00
..
2021-07-14 19:22:58 +02:00

Parity Bridges Common

This is a collection of components for building bridges.

These components include Substrate pallets for syncing headers, passing arbitrary messages, as well as libraries for building relayers to provide cross-chain communication capabilities.

Three bridge nodes are also available. The nodes can be used to run test networks which bridge other Substrate chains or Ethereum Proof-of-Authority chains.

🚧 The bridges are currently under construction - a hardhat is recommended beyond this point 🚧

Contents

Installation

To get up and running you need both stable and nightly Rust. Rust nightly is used to build the Web Assembly (WASM) runtime for the node. You can configure the WASM support as so:

rustup install nightly
rustup target add wasm32-unknown-unknown --toolchain nightly

Once this is configured you can build and test the repo as follows:

git clone https://github.com/paritytech/parity-bridges-common.git
cd parity-bridges-common
cargo build --all
cargo test --all

If you need more information about setting up your development environment Substrate's Getting Started page is a good resource.

High-Level Architecture

This repo has support for bridging foreign chains together using a combination of Substrate pallets and external processes called relayers. A bridge chain is one that is able to follow the consensus of a foreign chain independently. For example, consider the case below where we want to bridge two Substrate based chains.

+---------------+                 +---------------+
|               |                 |               |
|     Rialto    |                 |    Millau     |
|               |                 |               |
+-------+-------+                 +-------+-------+
        ^                                 ^
        |       +---------------+         |
        |       |               |         |
        +-----> | Bridge Relay  | <-------+
                |               |
                +---------------+

The Millau chain must be able to accept Rialto headers and verify their integrity. It does this by using a runtime module designed to track GRANDPA finality. Since two blockchains can't interact directly they need an external service, called a relayer, to communicate. The relayer will subscribe to new Rialto headers via RPC and submit them to the Millau chain for verification.

Take a look at Bridge High Level Documentation for more in-depth description of the bridge interaction.

Project Layout

Here's an overview of how the project is laid out. The main bits are the node, which is the actual "blockchain", the modules which are used to build the blockchain's logic (a.k.a the runtime) and the relays which are used to pass messages between chains.

├── bin             // Node and Runtime for the various Substrate chains
│  └── ...
├── deployments     // Useful tools for deploying test networks
│  └──  ...
├── diagrams        // Pretty pictures of the project architecture
│  └──  ...
├── modules         // Substrate Runtime Modules (a.k.a Pallets)
│  ├── ethereum     // Ethereum PoA Header Sync Module
│  ├── grandpa      // On-Chain GRANDPA Light Client
│  ├── messages     // Cross Chain Message Passing
│  ├── dispatch     // Target Chain Message Execution
│  └──  ...
├── primitives      // Code shared between modules, runtimes, and relays
│  └──  ...
├── relays          // Application for sending headers and messages between chains
│  └──  ...
└── scripts         // Useful development and maintenance scripts

Running the Bridge

To run the Bridge you need to be able to connect the bridge relay node to the RPC interface of nodes on each side of the bridge (source and target chain).

There are 3 ways to run the bridge, described below:

  • building & running from source,
  • building or using Docker images for each individual component,
  • running a Docker Compose setup (recommended).

Using the Source

First you'll need to build the bridge nodes and relay. This can be done as follows:

# In `parity-bridges-common` folder
cargo build -p rialto-bridge-node
cargo build -p millau-bridge-node
cargo build -p substrate-relay

Running

To run a simple dev network you'll can use the scripts located in the deployments/local-scripts folder. Since the relayer connects to both Substrate chains it must be run last.

# In `parity-bridges-common` folder
./deployments/local-scripts/run-rialto-node.sh
./deployments/local-scripts/run-millau-node.sh
./deployments/local-scripts/relay-millau-to-rialto.sh

At this point you should see the relayer submitting headers from the Millau Substrate chain to the Rialto Substrate chain.

Local Docker Setup

To get up and running quickly you can use published Docker images for the bridge nodes and relayer. The images are published on Docker Hub.

To run the dev network we first run the two bridge nodes:

docker run -p 30333:30333 -p 9933:9933 -p 9944:9944 \
           -it paritytech/rialto-bridge-node --dev --tmp \
           --rpc-cors=all --unsafe-rpc-external --unsafe-ws-external

docker run -p 30334:30333 -p 9934:9933 -p 9945:9944 \
           -it paritytech/millau-bridge-node --dev --tmp \
           --rpc-cors=all --unsafe-rpc-external --unsafe-ws-external

Notice that the docker run command will accept all the normal Substrate flags. For local development you should at minimum run with the --dev flag or else no blocks will be produced.

Then we need to initialize and run the relayer:

docker run --network=host -it \
        paritytech/substrate-relay init-bridge RialtoToMillau \
        --target-host localhost \
        --target-port 9945 \
        --source-host localhost \
        --source-port 9944 \
        --target-signer //Alice

docker run --network=host -it \
        paritytech/substrate-relay relay-headers RialtoToMillau \
        --target-host localhost \
        --target-port 9945 \
        --source-host localhost \
        --source-port 9944 \
        --target-signer //Bob \

You should now see the relayer submitting headers from the Millau chain to the Rialto chain.

If you don't want to use the published Docker images you can build images yourself. You can do this by running the following commands at the top level of the repository.

# In `parity-bridges-common` folder
docker build . -t local/rialto-bridge-node --build-arg PROJECT=rialto-bridge-node
docker build . -t local/millau-bridge-node --build-arg PROJECT=millau-bridge-node
docker build . -t local/substrate-relay --build-arg PROJECT=substrate-relay

Note: Building the node images will take a long time, so make sure you have some coffee handy.

Once you have the images built you can use them in the previous commands by replacing paritytech/<component_name> with local/<component_name> everywhere.

Full Network Docker Compose Setup

For a more sophisticated deployment which includes bidirectional header sync, message passing, monitoring dashboards, etc. see the Deployments README.

How to send a message

A straightforward way to interact with and test the bridge is sending messages. This is explained in the send message document.

Community

Main hangout for the community is Element (formerly Riot). Element is a chat server like, for example, Discord. Most discussions around Polkadot and Substrate happen in various Element "rooms" (channels). So, joining Element might be a good idea, anyway.

If you are interested in information exchange and development of Polkadot related bridges please feel free to join the Polkadot Bridges Element channel.

The Substrate Technical Element channel is most suited for discussions regarding Substrate itself.