feat: DIP v1 features #494
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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`.
Fixes KILTprotocol/ticket#2557 and fixes KILTprotocol/ticket#2556. This PR builds on top of the shell PR, and adds support for Merkle proof for DID documents. ## Merkle proof structure A DID merkle proof is, at the core, an order set of (key, value) pairs, on which proof-of-inclusion and proof-of-non-inclusion can be performed. This PR generates and validates merkle proofs where leaves are of two types: - a DID key reference leave, whose key is the tuple (key ID, key relationship) and the value is an empty tuple - a DID key details leave, whose key is the key ID and the value is the key details For each key reference leaf with a given key ID, the proof also has to contain a key details leaf whose key is the key ID. Multiple reference leaves can reference the same key details leaf, optimising the storage size. ## New runtime APIs There is a new runtime API which the DIP sender would expose, and that allows anyone to generate a merkle proof for a given DID identifier and set of key IDs. The result contains the merkle root (which must match what other chains have stored in their `pallet-dip-receiver` map), and a merkle proof, which includes blinded values and a set of key reference and key details leaves for the keys identified by the provided key IDs. ## How to test The setup flow is similar to that of #489. Specifically: - Set up the local Rococo network onboarding the sender and receiver chains with para IDs 2_000 and 2_001 respectively - Open an HRMP channel from sender 2_000 to receiver 2_001 - Create a DID on the sender chain, e.g., using the [kilt-did-utilities](https://github.com/KILTprotocol/kilt-did-utilities) tool  - Push the identity of the DID to the receiver chain via the `pallet-dip-sender` extrinsic  - Call the runtime API to generate a proof for the created DID with some keys revealed  - Use the generated proof to dispatch an extrinsic on the receiving chain ### How to use the runtime API with polkadot apps There is currently no support for the new runtime API in the public polkadot apps instance. To use the runtime APIs from UI, please use [our fork from the aa/dip-sender-template branch](https://github.com/KILTprotocol/polkadot-apps/tree/aa/dip-sender-template), by running `yarn && yarn build && yarn start`, then connecting to the sender node WS socket. For runtime augmentation within a Node script, please use our [SDK repo from the aa/dip-merkle-proof branch](https://github.com/KILTprotocol/sdk-js/tree/aa/dip-merkle-proof).
Fixes KILTprotocol/ticket#2587. This PR adds a new trait `DipCallOriginFilter` that exposes a `fn check_proof(call: Call, proof: Self::Proof) -> Result<Self::Success, Self::Error>` function, called by the runtime to verify if a call can be dispatched with the provided proof or not.
Fixes KILTprotocol/ticket#2588, based on top of #502. Won't be reviewed as it is merely a renaming PR. Will merge onto `aa/dip` once #502 gets reviewed and merged.
Fixes KILTprotocol/ticket#2553. The main changes are: * Removed half-baked versioning support, to re-introduce a proper one once versioning and version negotiation will be tackeld * Moved most of the logic from the `runtime-common` crate to a new `kilt-dip-support` crate, after making all the types generic over all the runtime configurations * Updated the `pallet-dip-consumer` pallet to have a bunch more details, more info below * Updated the XCM-simulator based tests ## Updates to the `dip-support` crate The `dip-support` does not contain any versioned types anymore. Support for versioning was half-baked and has been removed. Proper thought around versioning and version negotiation will happen in the (short) future. ## New `kilt-dip-support` crate The new `kilt-dip-support` crate contains types and traits that are not generic over ANY DIP deployment, but that can be used by every consumer that relies on the KILT chain as their provider. Hence, types are opinionated towards the way KILT implements the DIP protocol, but generic over the runtime configuration. The most relevant types are `MerkleProofAndDidSignatureVerifier`, exported from the root, `DidMerkleProofVerifier`, exported from the `merkle` module, and `DidSignatureAndCallVerifier`, exported from the `did` module. When they are chained together, they allow a user to submit a Merkle proof revealing parts of their DID Document, and to use one of the revealed keys to sign a specifically-crafted payload which provides authenticity guarantees of the DID subject. The default verification logic for the DID signature is the following: 1. Verify that the block number specified in the signature is no older than `SIGNATURE_VALIDITY` blocks, as specified by the runtime 2. Verify that the signature can be verified over the encoded tuple formed by `(call, identity_details, submitter_address, block_number, genesis_hash, signed_extra)`, where `signed_extra` can be anything more that the runtime might require be included in the signature. 3. Verify that one of the keys revealed in the Merkle proof can be used to verify the provided signature 4. [OPTIONAL] If the type variant which also performs authorization checks on the call itself is used, i.e., the `DidSignatureAndCallVerifier` type, then the verification will also include checking whether the used verification relationship can be used to dispatch the specified call or not, as we do ourselves in our did pallet within the `submit_did_call`, but in a more generic way. The verification logic for Merkle proofs has remained unchanged, and it can now be chained with the DID verification logic. ## Refreshed `pallet-dip-consumer` The pallet has been updated so that now the `dispatch_as` extrinsic takes a generic `Proof` instead of an `IdentityProof`, and internally performs the following checks: 1. Verify the origin is a signed origin (as before) 2. Verify that the call passes a preliminary filter, before any heavy computation is executed on the provided proof, via the `DipCallOriginFilter` type. This step will typically immediately filter out any calls that cannot be called with a Dip origin regardless of the content of the proof. 3. Retrieves the identity details from storage, if they exist 4. Delegate everything to the `ProofVerifier`, which has a mutable reference to the details fetched at step 3, in case they need to update some values that will be written to storage (e.g., the nonce) 5. The maybe mutated details are written back into storage 6. The call is dispatched with the new `DipOrigin`, which carries the additional information as returned by the `ProofVerifier`. In the demo runtime, this will be the set of keys revealed as part of the Merkle proof, that have been verified, parsed, and used for verifying the DID signature provided as part of the proof. The pallet logic is very simple, and most of the (complex) logic lies in the types that have been exposed as part of the `kilt-dip-support` crate. This makes the pallet easier to understand, and more generic to be used in different contexts potentially for different identity providers as well, where each provider might require users to provide a different identity proof. ## Minor changes Other things have been updated to reflect the relocation of some files into the new `kilt-dip-support` crate. ## How to test 1. Build [this version](KILTprotocol/sdk-js#751) of the SDK 2. Clone and `yarn install && yarn build` [this version](https://github.com/KILTprotocol/polkadot-apps/pull/8) of the PolkadotJS apps 3. Copy-paste the `@kiltprotocol/type-definitions` output into the root `node_modules` folder of the PolkadotJS apps 4. Follow the steps to set up the HRMP channels, create the DIDs, and push the identity commitment from provider to consumer 5. Use [this version](KILTprotocol/kilt-did-utilities#14) of the kilt-did-utilities CLI tool to generate a valid DIP DID signature. 6. Enjoy ☀️☀️☀️
Identity information should be entirely under the control of the DID subject. Until now, it was not the case as anyone could have called the `commit_identity` extrinsic for any DID subject. This PR changes the origin check for the `commit_identity` extrinsic of provider pallet from `EnsureSigned` to a configurable origin check. The XCM integration tests have also been updated to use the `EitherOfDiverse<EnsureRoot<AccountId>, EnsureDidOrigin<DidIdentifier, AccountId>>;` implementation. Now, except for cases where democracy decides to do this operation, the DID subject has to agree to it by signing the operation, which will then be dispatched via the `submit_did_call` extrinsic of the DID pallet. The feature that any account can pay for the fees still applies, as that is the same also for DID-signed extrinsics.
Fixes KILTprotocol/ticket#2566. This PR changes the way XCM fees are handled for DIP. Before, the provider parachain sovereign account on the consumer chain was paying for the XCM fees, while now it is the sovereign account of the user that triggered the operation on the provider chain, to also pay for the fees on the receiver chain in whatever asset specified in the extrinsic. With XCM v3, it's not possible for a parachain to charge an interior location (e.g., with a `DescendOrigin` instruction), hence a new barrier and a new origin converter have been introduced, which are supposed to be used together to implement the feeing model DIP has envisioned. ## Relevant changes ### Reworked `XcmRouterIdentityDispatcher` The `XcmRouterIdentityDispatcher` type used to be part of the `pallet-dip-provider` pallet. Because it is really specific to KILT, it has been moved into the `kilt-dip-support` crate. Additionally, the router now packages the DIP XCM program with the following instructions: 1. `ExpectOrigin` with the provider parachain origin, making sure the same XCM message cannot be sent by regular users via the XCM pallet. 2. `DescendOrigin` with a new `AccountId32` representing the dispatcher account ID on the provider chain. 3. `WithdrawAsset` with the `MultiAsset` specified in the `commit_identity` extrinsic in the `pallet-dip-provider` pallet 4. `BuyExecution` with the max `Weight` specified in the `commit_identity` extrinsic in the `pallet-dip-provider` pallet 5. `Transact` with `OriginKind::Native` and the same weight limit as above 6. `RefundSurplus` 7. `DepositAsset` with any remaining assets in the holding registry back to the dispatcher's account on the consumer chain In the demo runtimes and tests, the `Account32Hash` location converter has been used to convert the account ID information coming from the `X2` junction containing the sibling provider parachain and the disptacher account. ### Configurable origin for the `pallet_dip_provider::commit_identity` extrinsic The `CommitOrigin` origin was already configurable, but now its `Success` result is required to implement the `SubmitterInfo` trait, which returns the `AccountId` of the tx submitter, so that the information can be used to compose the XCM message that will be sent to destination (specifically it is included in the `DescendOrigin` and `DepositAsset` instructions). The trait has been implemented for the `AccountId32` type, which is returned by the `EnsureSigned` origin check (which could be used for tests), and for the `DidRawOrigin` type, which is returned by the `EnsureDidOrigin` origin check (which has been used in the demo runtimes). ### The `AllowParachainProviderAsSubaccount` barrier For DIP to implement the feeing model devised here, where the user pays for the fees on both chain, a new barrier + origin converter must be integrated into the XCM configuration. The `AllowParachainProviderAsSubaccount` barrier verifies that 1. the origin of the XCM is a parachain with an ID that is returned by the `ProviderParaId` generic type, and 2. the order of the instructions in the XCM program matches exactly what is expected in the DIP flow. If either the origin or the set of instructions is different, the barrier will return an error. To extend existing barrier, there are two additional types: `OkOrElseCheckForParachainProvider` which tries to match the incoming XCM message against the new `AllowParachainProviderAsSubaccount` barrier if none of the previous barriers have succeeded (explicit approval), and `ErrOrElseCheckForParachainProvider` which tries to match the XCM message against the new barrier only if none of the previous barriers have failed (explicit rejection). ### The `AccountIdJunctionAsParachain` origin converter Since there is no way to convert an `X2` junction of parachain + sub-account, the `AccountIdJunctionAsParachain` does just that. It takes the `X2` junction of a *sibling* parachain + sub-account, if the parachain matches the ID given by the `ProviderParaId` type, and converts it into a `ParachainOrigin`. **The origin converter and the barrier are meant to be used together, otherwise configuring only one or the other opens the way to security issues on the consumer chain!**
Fixes KILTprotocol/ticket#2730. This PR introduces a new way of doing cross-chain identity bridging for the same consensus system: state proofs. Few points make this solution better than the previous XCM-based approach: 1. No need to anchor the commitment to each destination via XCM. The commitment happens once on the provider chain and can be used everywhere else. 2. No need to establish HRMP channels between the provider and the relying party chain. 3. No outdated information. State proofs guarantee that always the latest value of the commitment is used by the relying party. Of course the identity info can still change without the commitment be updated, but this is easily solvable by batching the commitment update together with the operations where the identity bits change. Few TODOs are present, and they will be addressed in next PRs. ## Main changes * The overarching `MerkleProofAndDidSignatureVerifier` has been renamed to `DipSiblingProviderStateProofVerifier`, with a bunch of additional generics to make it agnostic over who the provider is, and also who the relaychain is (e.g., Polkadot, Kusama, Rococo). * The `process_identity_action` has been completely removed from the `pallet-dip-consumer` pallet, since XCM is not required anymore * Identity commitments are now stored on the **provider** chain rather than the relying party chain. * The `commit_identity` extrinsic also only has the identifier now, without the need to specify `destination`, `asset` and `weight` since an identity commitment is now usable everywhere by design. * A new pallet `pallet-relay-store` which is meant to be used in conjunction with the `pallet-dip-consumer` and that stores the last N relay chain state roots, against which state proofs can be verified. Relay chain state roots are stored in the `on_finalize`, before they are cleaned by the `on_finalize` of the `cumulus-pallet-parachain-system`. ### Additions from the relaychain PR (#553) * A new `ChildParachainDipStateProof` and `DipChildProviderStateProofVerifier` to be deployed on the relaychain to start accepting DIP operations * `SiblingParachainHeadProofVerifier` renamed to `ParachainHeadProofVerifier` * `KiltDipCommitmentsForDipProviderPallet` does not exist anymore, and it's been replaced by `ProviderParachainStateInfoViaProviderPallet`, which depends on the provider `Runtime` enum * A new `HistoricalBlockRegistry` trait to be implemented by the relaychain to provide historic block hashes against which DIP proofs can be verified * The `postit` pallet has been ported over from the Decoded demo branch, and used instead of the lookup pallet to showcase DIP capabilities ## How to switch - Remove all the XCM-related pallets from both provider and consumer runtime templates - Add the `pallet-relay-store` pallet to the consumer runtime template, and configure all traits as needed
Fixes KILTprotocol/ticket#2552, by both removing all occurrences of `.expect()` and `.unwrap()` and replacing them with `Internal` errors, and by introducing error enums. The logic is that for both the provider and the consumer, a generic error is bubbled up from the runtime, and because of the constraints imposed by Substrate, the error reason is encoded as a `u16`, where each "class" of error is namespaced with a 255 value increment. A snippet of this is shown below: ```rust fn from( value: DipSiblingProviderStateProofVerifierError< ParachainHeadMerkleProofVerificationError, IdentityCommitmentMerkleProofVerificationError, DipProofVerificationError, DidSignatureVerificationError >, ) -> Self { match value { DipSiblingProviderStateProofVerifierError::ParachainHeadMerkleProofVerificationError(error) => { error.into() } DipSiblingProviderStateProofVerifierError::IdentityCommitmentMerkleProofVerificationError(error) => { u8::MAX as u16 + error.into() as u16 } DipSiblingProviderStateProofVerifierError::DipProofVerificationError(error) => { u8::MAX as u16 * 2 + error.into() as u16 } DipSiblingProviderStateProofVerifierError::DidSignatureVerificationError(error) => { u8::MAX as u16 * 3 + error.into() as u16 } } } ``` The specific reason for the error can then be retrieved and decoded directly from the Polkadot Apps interface, as the example below shows, where the first byte `01` indicates the enum variant index, the second byte is the varint encoding of the SCALE-encoded u16, and the third and forth bytes `e000` represent the `u16` error reason. This can be decoded as decimal, where each value has a one-to-one link to a specific error from the runtime. <img width="554" src="https://github.com/KILTprotocol/kilt-node/assets/6704504/f0985e17-7f3e-49f5-818c-6a7bc1ae1530"> The pallet consumer expects any other implementation of the DIP consumer protocol to expose the proof verification error reason as a `u16`, but of course developers are free to not give any meaning to it and treat everything as a generic `InvalidProof` error.
Fixes KILTprotocol/ticket#2971 on top of #572. This PR adds support for versioning, by introducing support for the following: 1. [PROVIDER PALLET] Generate an identity commitment for a specific version 2. [PROVIDER PALLET] Delete a previously-created identity commitment of a specific version 3. [PROVIDER RUNTIME API] Generate a DIP proof for a specific version 4. [CONSUMER] Add `Versioned*` types for DIP verifiers and DIP proofs running on both a sibling parachain or the parent relaychain
Fixes KILTprotocol/ticket#2983. Add a generic pallet to store deposits, as well as a hooking mechanism to both the existing provider pallet (to allow runtimes that take deposits to take deposits, or to do any other operation), and to the new deposit pallet, which allows other pallets to clean up storage if a storage is reclaimed back by its owner (e.g., an identity commitment is removed). Tests will follow in a separate PR, when time allows for them 😁 The whole DIP branch won't be merged on `develop` before tests are written, so it's not a risk. The logic has been tested by spinning up a local network and trying to commit an identity (which takes a deposit), remove the commitment (which frees up the deposit), re-commit the identity, reclaim the deposit (which removes the commitment). - [x] Implement logic for deposit removal hooks - [x] Test - [x] Review
Fixes KILTprotocol/ticket#2974 and based on top of #574. This is my take at trying to improve the DX of integrating DIP components. The following is a list of the main changes introduced by this PR: - Definitions of traits that are only ever used and useful inside a pallet have been changed to take a generic `Runtime` type that must implement the pallet config, reducing the clutter when implementing them - Additional bounds have been added to the associated types of those traits, so that they don't need to be specified in the pallet config so that we can have trait bounds of those types. So basically what used to be the trait bounds on the pallet config, is not a trait bound on the trait return type. I think this is also the "Rusty" way to go. - The generic consumer types exported in `kilt-dip-support` crate have been renamed with the `Generic` prefix, because I introduced two new types, starting with `Kilt`, that make it easier to integrate any KILT runtime as an identity provider, with the downside of having to depend on the whole runtime definition, but there's also ways around that (e.g., by having an intermediate crate that only implements the required `Config` traits). Example 1 below shows the change. - Better re-exports (feedback is welcome on this one). For instance, for types that implement a basic version of a pallet's trait definition, the type is exported directly from the pallet crate root, while the trait is still namespaced behind the `mod traits`. Example 2 below. - Change of the origin check for the `pallet_dip_consumer::dispatch_as` extrinsic from `ensure_signed` to a generic `T::DispatchOriginCheck::ensure_origin`, as long as the `DispatchOriginCheck` returns an `AccountId` upon successful verification. ## Example 1: old vs new way of integrating a consumer into a runtime where KILT is a provider ### Old ```rust pub type ProofVerifier = VersionedDipSiblingProviderStateProofVerifier< RelayStateRootsViaRelayStorePallet<Runtime>, ConstU32<2_000>, ProviderParachainStateInfoViaProviderPallet<ProviderRuntime>, AccountId, BlakeTwo256, KeyIdOf<ProviderRuntime>, ProviderAccountId, Web3Name, LinkableAccountId, 10, 10, u128, // Signatures are valid for 50 blocks FrameSystemDidSignatureContext<Runtime, 50>, DipCallFilter, >; ``` ### New (100% equivalent to the old one) ```rust pub type ProofVerifier = KiltVersionedSiblingProviderVerifier< ProviderRuntime, // KILT runtime definition ConstU32<2_000>, RelayStateRootsViaRelayStorePallet<Runtime>, // Local runtime definition BlakeTwo256, DipCallFilter, 10, 10, 50, >; ``` ## Example 2: example of type implementing a pallet's trait with a basic implementation For the trait ```rust pub trait IdentityCommitmentGenerator<Runtime> where Runtime: Config, Runtime::IdentityProvider: IdentityProvider<Runtime>, { type Error: Into<u16>; type Output: Clone + Eq + Debug + TypeInfo + FullCodec + MaxEncodedLen; fn generate_commitment( identifier: &Runtime::Identifier, identity: &IdentityOf<Runtime>, version: IdentityCommitmentVersion, ) -> Result<Self::Output, Self::Error>; } ``` a basic implementation (mostly useful for tests) is provided ```rust pub struct DefaultIdentityCommitmentGenerator<Output>(PhantomData<Output>); impl<Runtime, Output> IdentityCommitmentGenerator<Runtime> for DefaultIdentityCommitmentGenerator<Output> where Runtime: Config, Output: Default + Clone + Eq + Debug + TypeInfo + FullCodec + MaxEncodedLen, { type Error = u16; type Output = Output; fn generate_commitment( _identifier: &Runtime::Identifier, _identity: &IdentityOf<Runtime>, _version: IdentityCommitmentVersion, ) -> Result<Self::Output, Self::Error> { Ok(Output::default()) } } ``` The pallet's crate will then export the trait with `pub mod traits`, while the type is re-exported directly _also_ from the root with `pub use traits::DefaultIdentityCommitmentGenerator`.
Ensuring the origin is a DID origin for the implementor of the provider pallet might not be enough. They need to check that the origin indeed matches the identifier being acted upon. Replacing `EnsureOrigin` with `EnsureOriginWithArg` gives access to that information. Tests will ALL be implemented in a different PR 😄
|
@weichweich I opened a new PR with more improvements addressing most (but not all) of the open comments here: #592. It probably needs a review before being merged. I will start working on a new PR on top of that to add the DIP provider components to Peregrine. |
|
I'm compiling Docker images based on the HEAD of #592. Will run integration tests from the DIP-SDK repo to make sure nothing is broken, then will go ahead and merge this (once #592 is merged onto this), leaving unresolved comments open so that we can go back at them later on. Tracking ticket: https://github.com/KILTprotocol/ticket/issues/3054. |
|
DIP-SDK integration tests (on local machine with Docker image |
Addresses most of the outstanding comments in #494. Which ones have been addressed are specified in that PR.
Based on top of #494. Mirrors the behaviour in the provider template, with the following differences: 1. The deposit is calculated taking into account the actual length of an identity commitment. 2. The key that is stored in the pallet deposit storage is an enum, which allows more keys to be added in the future
Partially fixes KILTprotocol/ticket#3051. Needed for easier DIP-SDK integration tests. Binaries will have to be compiled and exported in a different PR.
|
@Ad96el please remember to update the weights for the Peregrine runtime for both the |
Ad96el
approved these changes
Dec 13, 2023
webguru9178
pushed a commit
to webguru9178/kilt-node
that referenced
this pull request
Jan 8, 2024
Feature branch for everything DIP. It will collect other PRs until we are happy with the features, and will add the DIP to some of our runtimes and merge this into `develop`. ## WIP Checklist for the open tasks for v1 - [x] Basic structure -> KILTprotocol/kilt-node#489 - [x] Merkleization of DID Documents -> KILTprotocol/kilt-node#492 - [x] `RuntimeCall` verification logic -> KILTprotocol/kilt-node#502 - [x] DID signature verification -> KILTprotocol/kilt-node#516 - [x] Add support for linked accounts and web3name -> KILTprotocol/kilt-node#525 - [x] Configurable origin for `commit_identity` -> KILTprotocol/kilt-node#526 - [x] Proper fee management -> KILTprotocol/kilt-node#528 - [x] Update to Polkadot 0.9.43 -> KILTprotocol/kilt-node@c18a6ce - [x] Replace XCM with state proofs -> KILTprotocol/kilt-node#543 - [x] Add support for relaychain consumer -> KILTprotocol/kilt-node#553 (part of KILTprotocol/kilt-node#543) - [x] Proper error handling -> KILTprotocol/kilt-node#572 - [x] Add support for versioning -> KILTprotocol/kilt-node#573 - [x] Take deposits for identity commitments -> KILTprotocol/kilt-node#574 - [x] Expose common definitions usable by consumers -> KILTprotocol/kilt-node#577 - [x] Change ensure_signed! to configurable origin also for the `dispatch_as` function -> KILTprotocol/kilt-node#577 - [x] Proper benchmarking and weights -> KILTprotocol/kilt-node#585 - [x] Comments and docs -> KILTprotocol/kilt-node#584 - [x] Revert Dockerfile changes in KILTprotocol/kilt-node#587 - [x] [OPTIONAL] Add support for Zombienet -> KILTprotocol/kilt-node#587 - [x] [OPTIONAL] Add chain spec loading from file for template runtimes -> KILTprotocol/kilt-node#587 - [x] Big, final review -> KILTprotocol/kilt-node#494 (review) - [x] Improvements n.1 PR -> KILTprotocol/kilt-node#591 - [x] Improvements n.2 PR -> KILTprotocol/kilt-node#592 - [x] Add to Peregrine runtime -> KILTprotocol/kilt-node#594 - [ ] Deploy on Peregrine - [ ] Unit tests - [ ] Add to Spiritnet runtime - [ ] Deploy on Spiritnet - [ ] [OPTIONAL] Move DIP-related stuff into its own repo --------- Co-authored-by: Adel Golghalyani <[email protected]> Co-authored-by: Chris Chinchilla <[email protected]> Co-authored-by: Albrecht <[email protected]>
Merged
Ad96el
added a commit
that referenced
this pull request
Feb 7, 2024
Feature branch for everything DIP. It will collect other PRs until we are happy with the features, and will add the DIP to some of our runtimes and merge this into `develop`. ## WIP Checklist for the open tasks for v1 - [x] Basic structure -> #489 - [x] Merkleization of DID Documents -> #492 - [x] `RuntimeCall` verification logic -> #502 - [x] DID signature verification -> #516 - [x] Add support for linked accounts and web3name -> #525 - [x] Configurable origin for `commit_identity` -> #526 - [x] Proper fee management -> #528 - [x] Update to Polkadot 0.9.43 -> c18a6ce - [x] Replace XCM with state proofs -> #543 - [x] Add support for relaychain consumer -> #553 (part of #543) - [x] Proper error handling -> #572 - [x] Add support for versioning -> #573 - [x] Take deposits for identity commitments -> #574 - [x] Expose common definitions usable by consumers -> #577 - [x] Change ensure_signed! to configurable origin also for the `dispatch_as` function -> #577 - [x] Proper benchmarking and weights -> #585 - [x] Comments and docs -> #584 - [x] Revert Dockerfile changes in #587 - [x] [OPTIONAL] Add support for Zombienet -> #587 - [x] [OPTIONAL] Add chain spec loading from file for template runtimes -> #587 - [x] Big, final review -> #494 (review) - [x] Improvements n.1 PR -> #591 - [x] Improvements n.2 PR -> #592 - [x] Add to Peregrine runtime -> #594 - [ ] Deploy on Peregrine - [ ] Unit tests - [ ] Add to Spiritnet runtime - [ ] Deploy on Spiritnet - [ ] [OPTIONAL] Move DIP-related stuff into its own repo --------- Co-authored-by: Adel Golghalyani <[email protected]> Co-authored-by: Chris Chinchilla <[email protected]> Co-authored-by: Albrecht <[email protected]>
ntn-x2
added a commit
that referenced
this pull request
Feb 22, 2024
Fixes KILTprotocol/ticket#3054. It also contains a **breaking change** for cross-chain DID signature verifications. The signature now has a `valid_until` field, as discussed in #494 (comment). Besides that, other changes include: * A new set of types representing different stages of a cross-chain DIP proof, during the verification process. Everything starts with either a `RelayDipDidProof` or a `ParachainDipDidProof` and ends, if the whole verification flow succeeds, with a `DipVerifiedInfo`. * A generic `verify_storage_value_proof` that is used to verify a single storage element with a storage proof. * The `KiltVersionedParachainVerifier` now also depends on the relaychain runtime, which removes the need for some traits that provided just type definitions, such as `RelayChainStorageInfo` and `RelayChainStateInfo`. * Errors conversions into `u8` now start from `1` instead of `0`, for disambiguating between an error returning `u8::MAX` and another case returning `u8::MAX + 0`. * Refactoring of the different modules. **No unit tests or benchmarks yet, but this code should make it easier to do all of those**.
Ad96el
added a commit
that referenced
this pull request
Apr 2, 2024
Feature branch for everything DIP. It will collect other PRs until we are happy with the features, and will add the DIP to some of our runtimes and merge this into `develop`. ## WIP Checklist for the open tasks for v1 - [x] Basic structure -> #489 - [x] Merkleization of DID Documents -> #492 - [x] `RuntimeCall` verification logic -> #502 - [x] DID signature verification -> #516 - [x] Add support for linked accounts and web3name -> #525 - [x] Configurable origin for `commit_identity` -> #526 - [x] Proper fee management -> #528 - [x] Update to Polkadot 0.9.43 -> c18a6ce - [x] Replace XCM with state proofs -> #543 - [x] Add support for relaychain consumer -> #553 (part of #543) - [x] Proper error handling -> #572 - [x] Add support for versioning -> #573 - [x] Take deposits for identity commitments -> #574 - [x] Expose common definitions usable by consumers -> #577 - [x] Change ensure_signed! to configurable origin also for the `dispatch_as` function -> #577 - [x] Proper benchmarking and weights -> #585 - [x] Comments and docs -> #584 - [x] Revert Dockerfile changes in #587 - [x] [OPTIONAL] Add support for Zombienet -> #587 - [x] [OPTIONAL] Add chain spec loading from file for template runtimes -> #587 - [x] Big, final review -> #494 (review) - [x] Improvements n.1 PR -> #591 - [x] Improvements n.2 PR -> #592 - [x] Add to Peregrine runtime -> #594 - [ ] Deploy on Peregrine - [ ] Unit tests - [ ] Add to Spiritnet runtime - [ ] Deploy on Spiritnet - [ ] [OPTIONAL] Move DIP-related stuff into its own repo --------- Co-authored-by: Adel Golghalyani <[email protected]> Co-authored-by: Chris Chinchilla <[email protected]> Co-authored-by: Albrecht <[email protected]>
Ad96el
pushed a commit
that referenced
this pull request
Apr 2, 2024
Fixes KILTprotocol/ticket#3054. It also contains a **breaking change** for cross-chain DID signature verifications. The signature now has a `valid_until` field, as discussed in #494 (comment). Besides that, other changes include: * A new set of types representing different stages of a cross-chain DIP proof, during the verification process. Everything starts with either a `RelayDipDidProof` or a `ParachainDipDidProof` and ends, if the whole verification flow succeeds, with a `DipVerifiedInfo`. * A generic `verify_storage_value_proof` that is used to verify a single storage element with a storage proof. * The `KiltVersionedParachainVerifier` now also depends on the relaychain runtime, which removes the need for some traits that provided just type definitions, such as `RelayChainStorageInfo` and `RelayChainStateInfo`. * Errors conversions into `u8` now start from `1` instead of `0`, for disambiguating between an error returning `u8::MAX` and another case returning `u8::MAX + 0`. * Refactoring of the different modules. **No unit tests or benchmarks yet, but this code should make it easier to do all of those**.
ntn-x2
added a commit
that referenced
this pull request
Apr 4, 2024
Fixes KILTprotocol/ticket#3054. It also contains a **breaking change** for cross-chain DID signature verifications. The signature now has a `valid_until` field, as discussed in #494 (comment). Besides that, other changes include: * A new set of types representing different stages of a cross-chain DIP proof, during the verification process. Everything starts with either a `RelayDipDidProof` or a `ParachainDipDidProof` and ends, if the whole verification flow succeeds, with a `DipVerifiedInfo`. * A generic `verify_storage_value_proof` that is used to verify a single storage element with a storage proof. * The `KiltVersionedParachainVerifier` now also depends on the relaychain runtime, which removes the need for some traits that provided just type definitions, such as `RelayChainStorageInfo` and `RelayChainStateInfo`. * Errors conversions into `u8` now start from `1` instead of `0`, for disambiguating between an error returning `u8::MAX` and another case returning `u8::MAX + 0`. * Refactoring of the different modules. **No unit tests or benchmarks yet, but this code should make it easier to do all of those**.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Feature branch for everything DIP. It will collect other PRs until we are happy with the features, and will add the DIP to some of our runtimes and merge this into
develop.WIP Checklist for the open tasks for v1
RuntimeCallverification logic -> feat: add DID key verification relationship logic #502commit_identity-> feat: configurable origin check for 'commit_identity' #526dispatch_asfunction -> chore: improve DX #577