Skip to content
Snippets Groups Projects
Select Git revision
  • 6523
  • 6630
  • 6532
  • 8089
  • gh-readonly-queue/master/pr-8020-82827221b774e24b98cd7f2306c1f2c1ea281c40 protected
  • 8053
  • 6336
  • 7703
  • 8080
  • 8081
  • 6515
  • 7986
  • 8083
  • 7980
  • 7567
  • gh-readonly-queue/master/pr-8063-d243659ece7b700a78af415f71f1b05094d30839 protected
  • master default protected
  • 8087
  • 8085
  • 8020
20 results
Search by author
  • Any Author
  • Aaro Altonen Aaro Altonen altonen
  • Administrator Administrator Admin0
  • Alexander Alexander alvicsam
  • Alexander Kalankhodzhaev Alexander Kalankhodzhaev kalaninja
  • Alexander Theißen Alexander Theißen athei
  • Alexandra Alexandra a13xndra
  • Alin Dima Alin Dima alindima
  • Andrew Jones Andrew Jones ascjones
  • André Silva André Silva andresilva
  • Anthony Lazam Anthony Lazam lazam
  • Anton Anton melekes
  • Anton Vilhelm Ásgeirsson Anton Vilhelm Ásgeirsson antonva
  • Arsham Teymouri Arsham Teymouri ArshamTeymouri
  • Artyom Bakhtin Artyom Bakhtin bakhtin
  • Bernardo A. Rodrigues Bernardo A. Rodrigues bernardoaraujor
  • Bradley Olson Bradley Olson BradleyOlson64
  • Branislav Kontur Branislav Kontur bkontur
  • Bulat Saifullin Bulat Saifullin BulatSaif
  • Chevdor Chevdor chevdor
  • Chris Kerr Chris Kerr piffle-rack
20 authors
  1. Jan 28, 2025
    • kianenigma's avatar
      tests pass again · deb7daa4
      kianenigma authored
      Unverified
      deb7daa4
    • kianenigma's avatar
      master.into() · cd52ab25
      kianenigma authored
      Unverified
      cd52ab25
    • Andrew Jones's avatar
      Implement pallet view function queries (#4722) · 0b8d7441
      Andrew Jones authored 
      
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: default avatarkianenigma <kian@parity.io>
Co-authored-by: default avatarJames Wilson <james@jsdw.me>
Co-authored-by: default avatarGiuseppe Re <giuseppe.re@parity.io>
Co-authored-by: default avatarGuillaume Thiolliere <guillaume.thiolliere@parity.io>
      Unverified
      0b8d7441
    • xermicus's avatar
      [pallet-revive] pack exceeding syscall arguments into registers (#7319) · 4302f74f
      xermicus authored 
      
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: default avatarxermicus <cyrill@parity.io>
Signed-off-by: default avatarCyrill Leutwiler <bigcyrill@hotmail.com>
Co-authored-by: command-bot <>
Co-authored-by: default avatarcmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: default avatarAlexander Theißen <alex.theissen@me.com>
      Unverified
      4302f74f
    • Alin Dima's avatar
      cumulus: bump PARENT_SEARCH_DEPTH and add test for 12-core elastic scaling (#6983) · e6aad5b0
      Alin Dima authored 
      On top of https://github.com/paritytech/polkadot-sdk/pull/6757

Fixes https://github.com/paritytech/polkadot-sdk/issues/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/88d900af

/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: default avatarJavier Viola <javier@parity.io>
      Unverified
      e6aad5b0
  3. Jan 27, 2025
  5. Jan 26, 2025
  7. Jan 25, 2025
    • thiolliere's avatar
      Improve debugging by using `#[track_caller]` in system `assert_last_event` and... · 17ae0627
      thiolliere authored 
      Improve debugging by using `#[track_caller]` in system `assert_last_event` 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.
      Unverified
      17ae0627
    • thiolliere's avatar
      `set_validation_data` register weight manually, do not use refund when the pre... · 682f8cd2
      thiolliere authored 
      `set_validation_data` register weight manually, do not use refund when the pre dispatch is zero. (#7327)

Related https://github.com/paritytech/polkadot-sdk/issues/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.
      Unverified
      682f8cd2
  9. Jan 24, 2025
  11. Jan 23, 2025
  13. Jan 22, 2025
    • FereMouSiopi's avatar
      Migrate `pallet-insecure-randomness-collective-flip` to umbrella crate (#6738) · 89b02284
      FereMouSiopi authored 
      
Part of https://github.com/paritytech/polkadot-sdk/issues/6504

---------

Co-authored-by: command-bot <>
Co-authored-by: default avatarBastian Köcher <git@kchr.de>
      Unverified
      89b02284
    • Alexandru Vasile's avatar
      net/libp2p: Enforce outbound request-response timeout limits (#7222) · fd64a1e7
      Alexandru Vasile authored 
      This PR enforces that outbound requests are finished within the
specified protocol timeout.

The stable2412 version running libp2p 0.52.4 contains a bug which does
not track request timeouts properly:
- https://github.com/libp2p/rust-libp2p/pull/5429

The issue has been detected while submitting libp2p -> litep2p requests
in kusama. This aims to check that pending outbound requests have not
timedout. Although the issue has been fixed in libp2p, there might be
other cases where this may happen. For example:
- https://github.com/libp2p/rust-libp2p/pull/5417

For more context see:
https://github.com/paritytech/polkadot-sdk/issues/7076#issuecomment-2596085096


1. Ideally, the force-timeout mechanism in this PR should never be
triggered in production. However, origin/stable2412 occasionally
encounters this issue. When this happens, 2 warnings may be generated:
- one warning introduced by this PR wrt force timeout terminating the
request
- possible one warning when the libp2p decides (if at all) to provide
the response back to substrate (as mentioned by @alexggh
[here](https://github.com/paritytech/polkadot-sdk/pull/7222/files#diff-052aeaf79fef3d9a18c2cfd67006aa306b8d52e848509d9077a6a0f2eb856af7L769)
and
[here](https://github.com/paritytech/polkadot-sdk/pull/7222/files#diff-052aeaf79fef3d9a18c2cfd67006aa306b8d52e848509d9077a6a0f2eb856af7L842)

2. This implementation does not propagate to the substrate service the
`RequestFinished { error: .. }`. That event is only used internally by
substrate to increment metrics. However, we don't have the peer
information available to propagate the event properly when we
force-timeout the request. Considering this should most likely not
happen in production (origin/master) and that we'll be able to extract
information by warnings, I would say this is a good tradeoff for code
simplicity:


https://github.com/paritytech/polkadot-sdk/blob/06e3b5c6

/substrate/client/network/src/service.rs#L1543


### Testing

Added a new test to ensure the timeout is reached properly, even if
libp2p does not produce a response in due time.

I've also transitioned the tests to using `tokio::test` due to a
limitation of
[CI](https://github.com/paritytech/polkadot-sdk/actions/runs/12832055737/job/35784043867)

```
--- TRY 1 STDERR:        sc-network request_responses::tests::max_response_size_exceeded ---
thread 'request_responses::tests::max_response_size_exceeded' panicked at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.40.0/src/time/interval.rs:139:26:
there is no reactor running, must be called from the context of a Tokio 1.x runtime
```



cc @paritytech/networking

---------

Signed-off-by: default avatarAlexandru Vasile <alexandru.vasile@parity.io>
Co-authored-by: default avatarBastian Köcher <git@kchr.de>
      Unverified
      fd64a1e7