Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fixes KILTprotocol/ticket#2550. **This PR will merge the changes into the `aa/dip` branch, which will be the base branch for all the future DIP improvements until we reach a version that we can merge into `develop` and deploy on some testnets in the Peregrine runtime.** ## Base structure for DIP This PR contains the following components: * A pallet to send identity information to one or more destinations (DIP sender) * A pallet to receive such identity information from a source (DIP receiver) * A support crate that contains common (versioned) types, in future also traits and auxiliary functions, if needed * A template project consisting of 1. a template runtime for the dip-sender, with its node counterpart, 2. a template runtime for the dip-receiver, with its node counterpart, 3. an example XCM integration test using [XCM emulator](https://github.com/shaunxw/xcm-simulator) (not simulator) which connects the two template runtimes with a local Rococo relay chain. ### Design The current version assumes that anyone on the sender chain can dispatch identity information on some target chain (with which there exists an open HRMP channel). Ultimately, all the fees for dispatching the message and process it on the receiver side will be paid by the extrinsic submitter on the target chain. Right now, the submitter only pays for the extrinsic dispatch on the source chain, and the chain itself uses its own balance (liked to its sovereign account) on the target chain to pay for the `Transact` execution. The `Transact` operation that interacts with the `dip-receiver` pallet on the target chain has an `OriginKind::Native`, so that there is no way for any user on the source chain to dispatch such messages. Right now, the basic structure and the templates use defaults for everything, from proof generation to proof verification. One step at the time, all these defaults will be replaced with the actual features. Nevertheless, for two chains that have the same concept of `Identifier` and `AccountId`, it is already possible to demo the complete e2e flow. For the sake of our demonstration, the flow would go as follow, **assuming that both the source and target chains are registered as parachain on the same relaychain**: 1. The source chain requests to open an HRMP channel with the target chain 2. The target chain accepts the request and the channel is open 3. The target chain issues some funds (enough to cover the demo use case) to the sender chain's sovereign account 4. A user on the source chain creates a DID with a single authentication key 5. The same user (but could be anyone else), calls the extrinsic on the `dip-sender` pallet to send the merkle root of the DID to the target chain, paying for the dispatch fee 6. The source chain sends the information to the target chain 7. The user calls the `dispatch_as` extrinsic of the `dip-receiver` pallet which is deployed on the target chain, providing a merkle proof of their DID document + details on the source chain. For now this check always returns true. 8. Inside, the `dispatch_as` has a nested call which is dispatched with the new `DipOrigin`, which pallets can now use if they expect extrinsics to be DID-authorized. ## What's coming I created tickets for each of the next steps, under the DIP milestone. The tickets will take care of: * Adding benchmarks and weights * Introducing proper error handling * Introducing proper DID signature verificaiton on the target template chain (right now it's just a default behaviour) * Introducing proper merkle proof generation (I tested that it works, but removed those pieces from this PR for the ease of understanding) * Introducing proper merkle proof verification (same as above) * Adding an emergency brake in the sender pallet to stop dispatching messages to a specific destination, e.g., if the sender sovereign account on the destination chain does not have any more or if the `Transact` encoding would fail * Adding support for metadata beyond the simple DID details, e.g., proof expiration time, etc. * Replacing user-provided weights and assets with per-chain configurations stored in the sender pallet * More comments (I can work on this first if the code as it is it's too hard to follow) * Adding support for version negotiation. There is a basic concept of versioning right now, but it can and should be expanded and improved. * More unit and integration tests. Probably more tickets will come out of this work, and will be tracked separately in the same or in future milestones. ## How to test A basic integration test of the two template runtimes is present in the `dip-templates-xcm-tests` crate, inside the `dip-template/runtimes/xcm-tests`. It can be run as usual with `cargo test -p dip-templates-xcm-tests`.
- Loading branch information
