[AHM] ah-next + multi-block-staking #7358
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
…into gpestana/epm-mb
Closes #216. This PR allows pallets to define a `view_functions` impl like so: ```rust #[pallet::view_functions] impl<T: Config> Pallet<T> where T::AccountId: From<SomeType1> + SomeAssociation1, { /// Query value no args. pub fn get_value() -> Option<u32> { SomeValue::<T>::get() } /// Query value with args. pub fn get_value_with_arg(key: u32) -> Option<u32> { SomeMap::<T>::get(key) } } ``` ### `QueryId` Each view function is uniquely identified by a `QueryId`, which for this implementation is generated by: ```twox_128(pallet_name) ++ twox_128("fn_name(fnarg_types) -> return_ty")``` The prefix `twox_128(pallet_name)` is the same as the storage prefix for pallets and take into account multiple instances of the same pallet. The suffix is generated from the fn type signature so is guaranteed to be unique for that pallet impl. For one of the view fns in the example above it would be `twox_128("get_value_with_arg(u32) -> Option<u32>")`. It is a known limitation that only the type names themselves are taken into account: in the case of type aliases the signature may have the same underlying types but a different id; for generics the concrete types may be different but the signatures will remain the same. The existing Runtime `Call` dispatchables are addressed by their concatenated indices `pallet_index ++ call_index`, and the dispatching is handled by the SCALE decoding of the `RuntimeCallEnum::PalletVariant(PalletCallEnum::dispatchable_variant(payload))`. For `view_functions` the runtime/pallet generated enum structure is replaced by implementing the `DispatchQuery` trait on the outer (runtime) scope, dispatching to a pallet based on the id prefix, and the inner (pallet) scope dispatching to the specific function based on the id suffix. Future implementations could also modify/extend this scheme and routing to pallet agnostic queries. ### Executing externally These view functions can be executed externally via the system runtime api: ```rust pub trait ViewFunctionsApi<QueryId, Query, QueryResult, Error> where QueryId: codec::Codec, Query: codec::Codec, QueryResult: codec::Codec, Error: codec::Codec, { /// Execute a view function query. fn execute_query(query_id: QueryId, query: Query) -> Result<QueryResult, Error>; } ``` ### `XCQ` Currently there is work going on by @xlc to implement [`XCQ`](https://github.com/open-web3-stack/XCQ/) which may eventually supersede this work. It may be that we still need the fixed function local query dispatching in addition to XCQ, in the same way that we have chain specific runtime dispatchables and XCM. I have kept this in mind and the high level query API is agnostic to the underlying query dispatch and execution. I am just providing the implementation for the `view_function` definition. ### Metadata Currently I am utilizing the `custom` section of the frame metadata, to avoid modifying the official metadata format until this is standardized. ### vs `runtime_api` There are similarities with `runtime_apis`, some differences being: - queries can be defined directly on pallets, so no need for boilerplate declarations and implementations - no versioning, the `QueryId` will change if the signature changes. - possibility for queries to be executed from smart contracts (see below) ### Calling from contracts Future work would be to add `weight` annotations to the view function queries, and a host function to `pallet_contracts` to allow executing these queries from contracts. ### TODO - [x] Consistent naming (view functions pallet impl, queries, high level api?) - [ ] End to end tests via `runtime_api` - [ ] UI tests - [x] Mertadata tests - [ ] Docs --------- Co-authored-by: kianenigma <kian@parity.io> Co-authored-by: James Wilson <james@jsdw.me> Co-authored-by: Giuseppe Re <giuseppe.re@parity.io> Co-authored-by: Guillaume Thiolliere <guillaume.thiolliere@parity.io>
…dot-sdk into kiz-ah-next
…dot-sdk into kiz-ah-next
26 tasks
…dot-sdk into kiz-ah-next
seadanda
approved these changes
Feb 3, 2025
|
All GitHub workflows were cancelled due to failure one of the required jobs. |
github-merge-queue bot
pushed a commit
that referenced
this pull request
Feb 15, 2025
## Multi Block Election Pallet This PR adds the first iteration of the multi-block staking pallet. From this point onwards, the staking and its election provider pallets are being customized to work in AssetHub. While usage in solo-chains is still possible, it is not longer the main focus of this pallet. For a safer usage, please fork and user an older version of this pallet. --- ## Replaces - [x] #6034 - [x] #5272 ## Related PRs: - [x] #7483 - [ ] #7357 - [ ] #7424 - [ ] paritytech/polkadot-staking-miner#955 This branch can be periodically merged into #7358 -> #6996 ## TODOs: - [x] rebase to master - Benchmarking for staking critical path - [x] snapshot - [x] election result - Benchmarking for EPMB critical path - [x] snapshot - [x] verification - [x] submission - [x] unsigned submission - [ ] election results fetching - [ ] Fix deletion weights. Either of - [ ] Garbage collector + lazy removal of all paged storage items - [ ] Confirm that deletion is small PoV footprint. - [ ] Move election prediction to be push based. @tdimitrov - [ ] integrity checks for bounds - [ ] Properly benchmark this as a part of CI -- for now I will remove them as they are too slow - [x] add try-state to all pallets - [x] Staking to allow genesis dev accounts to be created internally - [x] Decouple miner config so @niklasad1 can work on the miner 72841b7 - [x] duplicate snapshot page reported by @niklasad1 - [ ] #6520 or equivalent -- during snapshot, `VoterList` must be locked - [ ] Move target snapshot to a separate block --------- Co-authored-by: Gonçalo Pestana <g6pestana@gmail.com> Co-authored-by: Ankan <10196091+Ank4n@users.noreply.github.com> Co-authored-by: command-bot <> Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com> Co-authored-by: Giuseppe Re <giuseppe.re@parity.io> Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
clangenb
pushed a commit
to clangenb/polkadot-sdk
that referenced
this pull request
Feb 19, 2025
## Multi Block Election Pallet This PR adds the first iteration of the multi-block staking pallet. From this point onwards, the staking and its election provider pallets are being customized to work in AssetHub. While usage in solo-chains is still possible, it is not longer the main focus of this pallet. For a safer usage, please fork and user an older version of this pallet. --- ## Replaces - [x] paritytech#6034 - [x] paritytech#5272 ## Related PRs: - [x] paritytech#7483 - [ ] paritytech#7357 - [ ] paritytech#7424 - [ ] paritytech/polkadot-staking-miner#955 This branch can be periodically merged into paritytech#7358 -> paritytech#6996 ## TODOs: - [x] rebase to master - Benchmarking for staking critical path - [x] snapshot - [x] election result - Benchmarking for EPMB critical path - [x] snapshot - [x] verification - [x] submission - [x] unsigned submission - [ ] election results fetching - [ ] Fix deletion weights. Either of - [ ] Garbage collector + lazy removal of all paged storage items - [ ] Confirm that deletion is small PoV footprint. - [ ] Move election prediction to be push based. @tdimitrov - [ ] integrity checks for bounds - [ ] Properly benchmark this as a part of CI -- for now I will remove them as they are too slow - [x] add try-state to all pallets - [x] Staking to allow genesis dev accounts to be created internally - [x] Decouple miner config so @niklasad1 can work on the miner 72841b7 - [x] duplicate snapshot page reported by @niklasad1 - [ ] paritytech#6520 or equivalent -- during snapshot, `VoterList` must be locked - [ ] Move target snapshot to a separate block --------- Co-authored-by: Gonçalo Pestana <g6pestana@gmail.com> Co-authored-by: Ankan <10196091+Ank4n@users.noreply.github.com> Co-authored-by: command-bot <> Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com> Co-authored-by: Giuseppe Re <giuseppe.re@parity.io> Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
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.
pulls #7282 into ah-next.
Please see only changes in ah-next runtime.