paritytech · bkontur · Nov 15, 2023 · Nov 13, 2023 · Nov 13, 2023 · Nov 14, 2023
diff --git a/Cargo.lock b/Cargo.lock
diff --git a/Cargo.toml b/Cargo.toml
@@ -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",

diff --git a/bridges/README.md b/bridges/README.md
@@ -68,7 +68,7 @@ For example, consider the case below where we want to bridge two Substrate based
 ```
 +---------------+                 +---------------+
 |               |                 |               |
-|     Rialto    |                 |    Millau     |
+|     Rococo    |                 |    Westend    |
 |               |                 |               |
 +-------+-------+                 +-------+-------+
         ^                                 ^
@@ -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
@@ -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).