Skip to content

Commit

Permalink
[testnet] Remove Wococo stuff from BridgeHubRococo/AssetHubRococo (#2300
Browse files Browse the repository at this point in the history 
)

Rococo<>Wococo bridge is replaced by Rococo<Westend bridge, so this PR
removes unneeded code.

- [x] update bridges subtree after
paritytech/parity-bridges-common#2692

---------

Co-authored-by: command-bot <>
Co-authored-by: Svyatoslav Nikolsky <svyatonik@gmail.com>
  • Loading branch information
@bkontur @svyatonik
bkontur and svyatonik authored Nov 15, 2023
1 parent 824b782 commit f4bb17c
Show file tree
Hide file tree
Showing 92 changed files with 962 additions and 6,389 deletions.
66 changes: 0 additions & 66 deletions Cargo.lock
View file

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

5 changes: 0 additions & 5 deletions Cargo.toml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -14,23 +14,18 @@ members = [
"bridges/modules/parachains",
"bridges/modules/relayers",
"bridges/modules/xcm-bridge-hub-router",
"bridges/primitives/chain-asset-hub-kusama",
"bridges/primitives/chain-asset-hub-polkadot",
"bridges/primitives/chain-asset-hub-rococo",
"bridges/primitives/chain-asset-hub-westend",
"bridges/primitives/chain-asset-hub-wococo",
"bridges/primitives/chain-bridge-hub-cumulus",
"bridges/primitives/chain-bridge-hub-kusama",
"bridges/primitives/chain-bridge-hub-polkadot",
"bridges/primitives/chain-bridge-hub-rococo",
"bridges/primitives/chain-bridge-hub-westend",
"bridges/primitives/chain-bridge-hub-wococo",
"bridges/primitives/chain-kusama",
"bridges/primitives/chain-polkadot",
"bridges/primitives/chain-polkadot-bulletin",
"bridges/primitives/chain-rococo",
"bridges/primitives/chain-westend",
"bridges/primitives/chain-wococo",
"bridges/primitives/header-chain",
"bridges/primitives/messages",
"bridges/primitives/parachains",
Expand Down
175 changes: 17 additions & 158 deletions bridges/README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -68,7 +68,7 @@ For example, consider the case below where we want to bridge two Substrate based
```
+---------------+ +---------------+
| | | |
| Rialto | | Millau |
| Rococo | | Westend |
| | | |
+-------+-------+ +-------+-------+
^ ^
Expand All @@ -79,9 +79,9 @@ For example, consider the case below where we want to bridge two Substrate based
+---------------+
```

The Millau chain must be able to accept Rialto headers and verify their integrity. It does this by using a runtime
The Rococo chain must be able to accept Westend 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
called a relayer, to communicate. The relayer will subscribe to new Rococo headers via RPC and submit them to the Westend
chain for verification.

Take a look at [Bridge High Level Documentation](./docs/high-level-overview.md) for more in-depth description of the
Expand All @@ -94,164 +94,23 @@ Here's an overview of how the project is laid out. The main bits are the `bin`,
messages between chains.

```
├── bin // Node and Runtime for the various Substrate chains
│ └── ...
├── deployments // Useful tools for deploying test networks
├── modules // Substrate Runtime Modules (a.k.a Pallets)
│ ├── beefy // On-Chain BEEFY Light Client (in progress)
│ ├── grandpa // On-Chain GRANDPA Light Client
│ ├── messages // Cross Chain Message Passing
│ ├── parachains // On-Chain Parachains Light Client
│ ├── relayers // Relayer Rewards Registry
│ ├── xcm-bridge-hub // Multiple Dynamic Bridges Support
│ ├── xcm-bridge-hub-router // XCM Router that may be used to Connect to XCM Bridge Hub
├── primitives // Code shared between modules, runtimes, and relays
│ └── ...
├── modules // Substrate Runtime Modules (a.k.a Pallets)
│ ├── beefy // On-Chain BEEFY Light Client (in progress)
│ ├── grandpa // On-Chain GRANDPA Light Client
│ ├── messages // Cross Chain Message Passing
│ ├── parachains // On-Chain Parachains Light Client
│ ├── relayers // Relayer rewards registry
├── relays // Application for sending finality proofs and messages between chains
│ └── ...
├── primitives // Code shared between modules, runtimes, and relays
│ └── ...
├── relays // Application for sending finality proofs and messages between chains
│ └── ...
└── scripts // Useful development and maintenance scripts
└── 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 2 ways to run the bridge, described below:

- building & running from source: with this option, you'll be able to run the bridge between two standalone chains that
are running GRANDPA finality gadget to achieve finality;

- running a Docker Compose setup: this is a recommended option, where you'll see bridges with parachains, complex relays
and more.

### Using the Source

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

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

### Running a Dev network

We will launch a dev network to demonstrate how to relay a message between two Substrate based chains (named Rialto and
Millau).

To do this we will need two nodes, two relayers which will relay headers, and two relayers which will relay messages.

#### Running from local scripts

To run a simple dev network you can use the scripts located in the [`deployments/local-scripts`
folder](./deployments/local-scripts).

First, we must run the two Substrate nodes.

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

After the nodes are up we can run the header relayers.

```bash
./deployments/local-scripts/relay-millau-to-rialto.sh
./deployments/local-scripts/relay-rialto-to-millau.sh
```

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

```
# Header Relayer Logs
[Millau_to_Rialto_Sync] [date] DEBUG bridge Going to submit finality proof of Millau header #147 to Rialto
[...] [date] INFO bridge Synced 147 of 147 headers
[...] [date] DEBUG bridge Going to submit finality proof of Millau header #148 to Rialto
[...] [date] INFO bridge Synced 148 of 149 headers
```

Finally, we can run the message relayers.

```bash
./deployments/local-scripts/relay-messages-millau-to-rialto.sh
./deployments/local-scripts/relay-messages-rialto-to-millau.sh
```

You will also see the message lane relayers listening for new messages.

```
# Message Relayer Logs
[Millau_to_Rialto_MessageLane_00000000] [date] DEBUG bridge Asking Millau::ReceivingConfirmationsDelivery about best message nonces
[...] [date] INFO bridge Synced Some(2) of Some(3) nonces in Millau::MessagesDelivery -> Rialto::MessagesDelivery race
[...] [date] DEBUG bridge Asking Millau::MessagesDelivery about message nonces
[...] [date] DEBUG bridge Received best nonces from Millau::ReceivingConfirmationsDelivery: TargetClientNonces {
latest_nonce: 0, nonces_data: () }
[...] [date] DEBUG bridge Asking Millau::ReceivingConfirmationsDelivery about finalized message nonces
[...] [date] DEBUG bridge Received finalized nonces from Millau::ReceivingConfirmationsDelivery: TargetClientNonces {
latest_nonce: 0, nonces_data: () }
[...] [date] DEBUG bridge Received nonces from Millau::MessagesDelivery: SourceClientNonces { new_nonces: {}, confirmed_nonce: Some(0) }
[...] [date] DEBUG bridge Asking Millau node about its state
[...] [date] DEBUG bridge Received state from Millau node: ClientState { best_self: HeaderId(1593, 0xacac***), best_finalized_self:
HeaderId(1590, 0x0be81d...), best_finalized_peer_at_best_self: HeaderId(0, 0xdcdd89...) }
```

To send a message see the ["How to send a message" section](#how-to-send-a-message).

### How to send a message

In this section we'll show you how to quickly send a bridge message. The message is just an encoded XCM `Trap(43)`
message.

```bash
# In `parity-bridges-common` folder
./scripts/send-message-from-millau-rialto.sh
```

After sending a message you will see the following logs showing a message was successfully sent:

```
INFO bridge Sending message to Rialto. Size: 11.
TRACE bridge Sent transaction to Millau node: 0x5e68...
```

And at the Rialto node logs you'll something like this:

```
... runtime::bridge-messages: Received messages: total=1, valid=1. Weight used: Weight(ref_time: 1215065371, proof_size:
48559)/Weight(ref_time: 1215065371, proof_size: 54703).
```

It means that the message has been delivered and dispatched. Message may be dispatched with an error, though - the goal
of our test bridge is to ensure that messages are successfully delivered and all involved components are working.

## Full Network Docker Compose Setup

For a more sophisticated deployment which includes bidirectional header sync, message passing, monitoring dashboards,
etc. see the [Deployments README](./deployments/README.md).

You should note that you can find images for all the bridge components published on [Docker
Hub](https://hub.docker.com/u/paritytech).

To run a Rialto node for example, you can use the following command:

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

## Community

Main hangout for the community is [Element](https://element.io/) (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](https://app.element.io/#/room/#bridges:web3.foundation) Element channel.

The [Substrate Technical](https://app.element.io/#/room/#substrate-technical:matrix.org) Element channel is most suited
for discussions regarding Substrate itself.
Apart from live Rococo <> Westend bridge, you may spin up local networks and test see how it works locally. More
details may be found in
[this document](https://github.com/paritytech/polkadot-sdk/tree/master//cumulus/parachains/runtimes/bridge-hubs/README.md).
Loading

0 comments on commit f4bb17c

Please sign in to comment.