Skip to content

Commit

Permalink
Update README.md to include updated design principles (#133)
Browse files Browse the repository at this point in the history
* Update README.md to include updated design principles

* typo
  • Loading branch information
coax1d authored Mar 11, 2024
1 parent 367c0e3 commit a994956
Showing 1 changed file with 19 additions and 43 deletions.
62 changes: 19 additions & 43 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,81 +8,57 @@ In a scenario where `ParaA` wants to send a message to `ParaB` (`ParaA -> ParaB`
- Better understand an efficient implementations of different XCMP approaches(proof sizes, overall onchain benchmarking, code complexity)
- Achieve consensus on an XCMP design and approach to put forward to the community (By showing pros and cons of a few different approaches)

### Prototypes for two approaches which are the following:
1. Msgs are unordered and no guranteed delivery(Use MMR approach here)
2. Msgs are ordered (Use msg hash chain)
## Approach

## Approach 1
### The proofs which are constructed via a Relayer involve a 4 tiered authenticated datastructure using 2 Binary Merkle Trees and 2 MMRs.

### Data Structure Format and Flow
### ChannelMessageMmr
- This is one of many MMRs which XCMP messages are stored into. There is a single XCMP message per block so each index can be thought of as the message contents for a particular block.

ParaA MSGab -> Message MMR -> MMR root -> XCMP trie -> XCMP trie root -> Parachain State trie -> Parachain state root -> Relay state trie -> Relay Root
### XCMPChannelBinaryMerkleTree Contents

Q:
Does each MMR peak get added to the XCMP trie? Or just each MMR Root(after bagging peaks). What else can be stored in the XCMP trie?
- MMRab root, MMRac root, etc.: Each receipient which a sender has an open channel with has a dedicated `ChannelMessageMmr`.
This each one of these `ChannelMessageMmrRoots` are bundled up into a Binary Merkle Tree whos root is put into the `Digest` of each Parachains BlockHeader

### Beefy MMR

### XCMPChannel Trie Contents
- Every Leaf of the Beefy Mmr contains a committment every `parachains block header` in the form of a `BinaryMerkleRoot`

- MMRab root, MMRac root, etc.: Each parachains XCMP channel's MMR root.
### Combining

### XCMPTrie
- This contains every Parachain's XCMPChannelTrieRoot
By combining these 4 tiers of Merkle structures together we have a proof which from a single message commitment on some parachain sender `X` we can compare it against another parachain receiver `Y`. This requires a latest Beefy Root (Which lives on the Polkadot Relaychain) to be inserted into each parachains state for proof verification.

### Insert Diagram of 4 tiered merkle structure

### Flow of Messages

#### ParaA(Sender):

- Sends an XCM message as usual.
- Adds the message as a leaf into one of its message XcmpChannelMmrs.
- The message MMR root (or all peaks?) gets stored inside the XCMP dedicated trie.
- Adds the message as a leaf into one of its message XcmpChannelMessageMmrs.
- The message MMR root gets stored inside the XCMPChannelBinaryMerkleTree.

#### Relayer (Having full nodes of `ParaA`, `ParaB`, Relaychain):

1. **Detection of Destination**:
- `Relayer` module detects a message from `ParaA` to `ParaB` is sent.

2. **Proof Construction**:
- Constructs the proof as `ParaA proof` = (messages + mmr membership proof).
- Constructs 4 tiered MerkleProof

3. **Proof Submission**:
- Submits proof to `ParaB`'s XCMP extrinsic labeled `submit_xcmp_proof(leaves, channel_id)`.
- Submits proof to `ParaB`'s XCMP extrinsic labeled `submit_xcmp_proof(proof, channel_id)`.

#### ParaB(Receiver):

1. **Proof Verification**:
- Because the receiver can track the XCMPChannelTrieRoot changes on the Relaychain the verifier stores the latest XcmpChannelMmr roots in its state
Because a parachain can have multiple Channels it stores the particular XcmpChannelMmrRoots indexed by a `channel_id`
- When the Relayer submits a proof of a particular of some particular messages the receiving chain can check those messages(leaves of the mmr) against its current
XcmpChannelMmrRoot for the particular `channel_id`

```rust

pub struct RelayerProof {
message_proof: Proof<H256>,
channel_id: u64,
}

```
**Proof Verification**:
- Because receipient has the Beefy Mmr Root(The top of the Merkle Path) it can unravel the proof and compare against this root.

#### Incentivization of Relayer:

1. Any parachain that opens a channel with another parachain could potentially run relayer nodes.
2. The XCM message sender provides a percentage fee to the relayer.


### ParaB:

#### verify_xcmp_message(RelayerProof)`

- verifies MMR nodes against mmr_roots
- verifies Relay merkle nodes against relay root
- If verification successful accepts XCM message and sends up the stack to XcmExecutor, XcmRouter?

- **Open questions:
Where does message go from here? (Check UMP/DMP/HRMP code)


# Building:

#### Clone
Expand Down

0 comments on commit a994956

Please sign in to comment.