[AHM] ah-next + multi-block-staking #7358
Draft
+26,169
−6,184
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
… set (#7318) This regression was introduced with some of the recent PRs. Regression fixed and test added. --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
The link to Polkachu is not working
…n the pre dispatch is zero. (#7327) Related #6772 For an extrinsic, in the post dispatch info, the actual weight is only used to reclaim unused weight. If the actual weight is more than the pre dispatch weight, then the extrinsic is using the minimum, e.g., the weight used registered in pre dispatch. In parachain-system pallet one call is `set_validation_data`. This call is returning an actual weight, but the pre-dispatch weight is 0. This PR fix the disregard of actual weight of `set_validation_data` by registering it manually.
…vent` and `assert_has_event` (#7142) Without track caller the error message of the assert points to the `assert_last_event` function, which is not useful. ``` thread 'tests::set_metadata_works' panicked at /home/gui/Developpement/polkadot-sdk/substrate/frame/system/src/lib.rs:2034:9: assertion `left == right` failed: expected event RuntimeEvent::Referenda(Event::MetadataSet { index: 0, hash: 0xbb30a42c1e62f0afda5f0a4e8a562f7a13a24cea00ee81917b86b89e801314aa }) is not equal to the last event RuntimeEvent::Referenda(Event::MetadataSet { index: 1, hash: 0xbb30a42c1e62f0afda5f0a4e8a562f7a13a24cea00ee81917b86b89e801314aa }) left: RuntimeEvent::Referenda(Event::MetadataSet { index: 1, hash: 0xbb30a42c1e62f0afda5f0a4e8a562f7a13a24cea00ee81917b86b89e801314aa }) right: RuntimeEvent::Referenda(Event::MetadataSet { index: 0, hash: 0xbb30a42c1e62f0afda5f0a4e8a562f7a13a24cea00ee81917b86b89e801314aa }) ``` With the track caller the error message points to the caller, showing the source of the error: ``` thread 'tests::set_metadata_works' panicked at substrate/frame/referenda/src/tests.rs:639:9: assertion `left == right` failed: expected event RuntimeEvent::Referenda(Event::MetadataSet { index: 0, hash: 0xbb30a42c1e62f0afda5f0a4e8a562f7a13a24cea00ee81917b86b89e801314aa }) is not equal to the last event RuntimeEvent::Referenda(Event::MetadataSet { index: 1, hash: 0xbb30a42c1e62f0afda5f0a4e8a562f7a13a24cea00ee81917b86b89e801314aa }) left: RuntimeEvent::Referenda(Event::MetadataSet { index: 1, hash: 0xbb30a42c1e62f0afda5f0a4e8a562f7a13a24cea00ee81917b86b89e801314aa }) right: RuntimeEvent::Referenda(Event::MetadataSet { index: 0, hash: 0xbb30a42c1e62f0afda5f0a4e8a562f7a13a24cea00ee81917b86b89e801314aa }) ``` I also improved the error message to include a warning when checking events on block number zero.
…rd-compatible) (#7344) Revert #7011 and replace it with a backward-compatible solution suitable for backporting to a release branch. ### Review notes It's easier to review this PR per commit: the first commit is just a revert, so it's enough to review only the second one, which is almost a one-liner. --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
closes #5978 --------- Co-authored-by: command-bot <> Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com>
…mni Node compatibility (#6529) # Description This PR adds development chain specs for the minimal and parachain templates. [#6334](#6334) ## Integration This PR adds development chain specs for the minimal and para chain template runtimes, ensuring synchronization with runtime code. It updates zombienet-omni-node.toml, zombinet.toml files to include valid chain spec paths, simplifying configuration for zombienet in the parachain and minimal template. ## Review Notes 1. Overview of Changes: - Added development chain specs for use in the minimal and parachain template. - Updated zombienet-omni-node.toml and zombinet.toml files in the minimal and parachain templates to include paths to the new dev chain specs. 2. Integration Guidance: **NB: Follow the templates' READMEs from the polkadot-SDK master branch. Please build the binaries and runtimes based on the polkadot-SDK master branch.** - Ensure you have set up your runtimes `parachain-template-runtime` and `minimal-template-runtime` - Ensure you have installed the nodes required ie `parachain-template-node` and `minimal-template-node` - Set up [Zombinet](https://paritytech.github.io/zombienet/intro.html) - For running the parachains, you will need to install the polkadot `cargo install --path polkadot` remember from the polkadot-SDK master branch. - Inside the template folders minimal or parachain, run the command to start with `Zombienet with Omni Node`, `Zombienet with minimal-template-node` or `Zombienet with parachain-template-node` *Include your leftover TODOs, if any, here.* * [ ] Test the syncing of chain specs with runtime's code. --------- Signed-off-by: EleisonC <ckalule7@gmail.com> Co-authored-by: Iulian Barbu <14218860+iulianbarbu@users.noreply.github.com> Co-authored-by: Alexander Samusev <41779041+alvicsam@users.noreply.github.com>
#Description Migrated polkadot-runtime-parachains slots benchmarking to the new benchmarking syntax v2. This is part of #6202 --------- Co-authored-by: Giuseppe Re <giuseppe.re@parity.io> Co-authored-by: seemantaggarwal <32275622+seemantaggarwal@users.noreply.github.com> Co-authored-by: Bastian Köcher <git@kchr.de>
Resolves (partially): #7148 (see _Problem 1 - `ShouldExecute` tuple implementation and `Deny` filter tuple_) This PR changes the behavior of `DenyThenTry` from the pattern `DenyIfAllMatch` to `DenyIfAnyMatch` for the tuple. I would expect the latter is the right behavior so make the fix in place, but we can also add a dedicated Impl with the legacy one untouched. ## TODO - [x] add unit-test for `DenyReserveTransferToRelayChain` - [x] add test and investigate/check `DenyThenTry` as discussed [here](#6838 (comment)) and update documentation if needed --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com> Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com> Co-authored-by: command-bot <> Co-authored-by: Clara van Staden <claravanstaden64@gmail.com> Co-authored-by: Adrian Catangiu <adrian@parity.io>
…aling (#6983) On top of #6757 Fixes #6858 by bumping the `PARENT_SEARCH_DEPTH` constant to a larger value (30) and adds a zombienet-sdk test that exercises the 12-core scenario. This is a node-side limit that restricts the number of allowed pending availability candidates when choosing the parent parablock during authoring. This limit is rather redundant, as the parachain runtime already restricts the unincluded segment length to the configured value in the [FixedVelocityConsensusHook](https://github.com/paritytech/polkadot-sdk/blob/88d900afbff7ebe600dfe5e3ee9f87fe52c93d1f/cumulus/pallets/aura-ext/src/consensus_hook.rs#L35) (which ideally should be equal to this `PARENT_SEARCH_DEPTH`). For 12 cores, a value of 24 should be enough, but I bumped it to 30 to have some extra buffer. There are two other potential ways of fixing this: - remove this constant altogether, as the parachain runtime already makes those guarantees. Chose not to do this, as it can't hurt to have an extra safeguard - set this value to be equal to the uninlcuded segment size. This value however is not exposed to the node-side and would require a new runtime API, which seems overkill for a redundant check. --------- Co-authored-by: Javier Viola <javier@parity.io>
This PR changes how we call runtime API methods with more than 6 arguments: They are no longer spilled to the stack but packed into registers instead. Pointers are 32 bit wide so we can pack two of them into a single 64 bit register. Since we mostly pass pointers, this technique effectively increases the number of arguments we can pass using the available registers. To make this work for `instantiate` too we now pass the code hash and the call data in the same buffer, akin to how the `create` family opcodes work in the EVM. The code hash is fixed in size, implying the start of the constructor call data. --------- Signed-off-by: xermicus <cyrill@parity.io> Signed-off-by: Cyrill Leutwiler <bigcyrill@hotmail.com> Co-authored-by: command-bot <> Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Alexander Theißen <alex.theissen@me.com>
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
14 tasks
|
All GitHub workflows were cancelled due to failure one of the required jobs. |
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.