Skip to content
  1. Jan 22, 2024
  3. Jan 20, 2024
  5. Jan 18, 2024
  7. Jan 16, 2024
  9. Jan 15, 2024
  11. Jan 13, 2024
  13. Jan 10, 2024
  15. Jan 09, 2024
  17. Jan 08, 2024
  19. Jan 07, 2024
  21. Jan 04, 2024
  23. Dec 20, 2023
  25. Dec 18, 2023
  27. Dec 13, 2023
  29. Dec 11, 2023
  31. Dec 08, 2023
    • Sam Johnson's avatar
      Tasks: general system for recognizing and executing service work (#1343) · ac3f14d2
      Sam Johnson authored 
      `polkadot-sdk` version of original tasks PR located here:
https://github.com/paritytech/substrate/pull/14329

Fixes #206

## Status
- [x] Generic `Task` trait
- [x] `RuntimeTask` aggregated enum, compatible with
`construct_runtime!`
- [x] Casting between `Task` and `RuntimeTask` without needing `dyn` or
`Box`
- [x] Tasks Example pallet
- [x] Runtime tests for Tasks example pallet
- [x] Parsing for task-related macros
- [x] Retrofit parsing to make macros optional
- [x] Expansion for task-related macros
- [x] Adds support for args in tasks
- [x] Retrofit tasks example pallet to use macros instead of manual
syntax
- [x] Weights
- [x] Cleanup
- [x] UI tests
- [x] Docs

## Target Syntax
Adapted from
https://github.com/paritytech/polkadot-sdk/issues/206#issue-1865172283



```rust
// NOTE: this enum is optional and is auto-generated by the other macros if not present
#[pallet::task]
pub enum Task<T: Config> {
    AddNumberIntoTotal {
        i: u32,
    }
}

/// Some running total.
#[pallet::storage]
pub(super) type Total<T: Config<I>, I: 'static = ()> =
StorageValue<_, (u32, u32), ValueQuery>;

/// Numbers to be added into the total.
#[pallet::storage]
pub(super) type Numbers<T: Config<I>, I: 'static = ()> =
StorageMap<_, Twox64Concat, u32, u32, OptionQuery>;

#[pallet::tasks_experimental]
impl<T: Config<I>, I: 'static> Pallet<T, I> {
	/// Add a pair of numbers into the totals and remove them.
	#[pallet::task_list(Numbers::<T, I>::iter_keys())]
	#[pallet::task_condition(|i| Numbers::<T, I>::contains_key(i))]
	#[pallet::task_index(0)]
	pub fn add_number_into_total(i: u32) -> DispatchResult {
		let v = Numbers::<T, I>::take(i).ok_or(Error::<T, I>::NotFound)?;
		Total::<T, I>::mutate(|(total_keys, total_values)| {
			*total_keys += i;
			*total_values += v;
		});
		Ok(())
	}
}
```

---------

Co-authored-by: default avatarNikhil Gupta <[email protected]>
Co-authored-by: default avatarkianenigma <[email protected]>
Co-authored-by: Nikhil Gupta <>
Co-authored-by: default avatarGavin Wood <[email protected]>
Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
Co-authored-by: default avatargupnik <[email protected]>
      ac3f14d2
  33. Dec 07, 2023
  35. Dec 01, 2023
  37. Nov 30, 2023
  39. Nov 29, 2023
  41. Nov 28, 2023
  43. Nov 27, 2023
    • Koute's avatar
      Build the standard library crates when building the runtimes (#2217) · 2610450a
      Koute authored 
      Our executor currently only supports the WASM MVP feature set, however
nowadays when compiling WASM the Rust compiler has more features enabled
by default.

We do set the `-C target-cpu=mvp` flag to make sure that *our* code gets
compiled in a way that is compatible with our executor, however this
doesn't affect Rust's standard library crates (`std`, `core` and
`alloc`) which are by default precompiled and still can make use of
these extra features.

So in this PR we force the compiler to also compile the standard library
crates for us to make sure that they also only use the MVP features.

I've added the `WASM_BUILD_STD` environment variable which can be used
to disable this behavior if set to `0`.

Unfortunately this *will* slow down the compile times when building
runtimes, but there isn't much that we can do about that.

Fixes https://github.com/paritytech/polkadot-sdk/issues/1755



---------

Co-authored-by: default avatarBastian Köcher <[email protected]>
      2610450a
  45. Nov 23, 2023
  47. Nov 19, 2023
  49. Nov 13, 2023
  51. Nov 06, 2023
  53. Nov 03, 2023
    • Bastian Köcher's avatar
      `sc-block-builder`: Remove `BlockBuilderProvider` (#2099) · ca5f1056
      Bastian Köcher authored 
      The `BlockBuilderProvider` was a trait that was defined in
`sc-block-builder`. The trait was implemented for `Client`. This
basically meant that you needed to import `sc-block-builder` any way to
have access to the block builder. So, this trait was not providing any
real value. This pull request is removing the said trait. Instead of the
trait it introduces a builder for creating a `BlockBuilder`. The builder
currently has the quite fabulous name `BlockBuilderBuilder` (I'm open to
any better name 😅

). The rest of the pull request is about
replacing the old trait with the new builder.

# Downstream code changes

If you used `new_block` or `new_block_at` before you now need to switch
it over to the new `BlockBuilderBuilder` pattern:

```rust
// `new` requires a type that implements `CallApiAt`. 
let mut block_builder = BlockBuilderBuilder::new(client)
                // Then you need to specify the hash of the parent block the block will be build on top of
		.on_parent_block(at)
                // The block builder also needs the block number of the parent block. 
                // Here it is fetched from the given `client` using the `HeaderBackend`
                // However, there also exists `with_parent_block_number` for directly passing the number
		.fetch_parent_block_number(client)
		.unwrap()
                // Enable proof recording if required. This call is optional.
		.enable_proof_recording()
                // Pass the digests. This call is optional.
                .with_inherent_digests(digests)
		.build()
		.expect("Creates new block builder");
```

---------

Co-authored-by: default avatarSebastian Kunert <[email protected]>
Co-authored-by: command-bot <>
      ca5f1056
  55. Oct 29, 2023
  57. Oct 25, 2023
    • Oliver Tale-Yazdi's avatar
      Sort the benchmarks before listing them (#2026) · c86b6336
      Oliver Tale-Yazdi authored 
      

Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      c86b6336
    • Liam Aharon's avatar
      Small optimisation to `--profile dev` wasm builds (#1851) · ff3a3bca
      Liam Aharon authored 
      `wasm-builder` was adjusted to default to building wasm blobs in
`release` mode even when cargo is in `debug` because `debug` wasm is too
slow.

A side effect of this was `.compact` and `.compact.compressed` getting
built when the dev is running build in `debug`, adding ~5s to the build
time of every wasm runtime.

I think it's reasonable to assume if the dev is running `debug` build
they want to optimise speed and do not care about the size of the wasm
binary. Compacting a blob has negligible impact on its actual
performance.

In this PR, I adjusted the behavior of the wasm builder so it does not
produce `.compact` or `.compact.compressed` wasm when the user is
running in `debug`. The builder will continue to produce the bloaty wasm
in release mode unless it is overriden with an env var.

As suggested by @koute in review, also refactored the
`maybe_compact_wasm_and_copy_blobs` into multiple funuctions, and
renamed things to better support RISC-V in the future.

---

There is no `T-runtime` label so @KiChjang

 told me to put `T1-FRAME` :)

---------

Co-authored-by: default avatarKoute <[email protected]>
      ff3a3bca
  59. Oct 24, 2023
  61. Oct 23, 2023
    • aj3n's avatar
      wasm-builder: manually set CARGO_TARGET_DIR (#1951) · 38c3c625
      aj3n authored 
      ✄
-----------------------------------------------------------------------------

Thank you for your Pull Request! 🙏 Please make sure it follows the
contribution guidelines outlined in
[this
document](https://github.com/paritytech/polkadot-sdk/blob/master/docs/CONTRIBUTING.md)
and fill
out the sections below. Once you're ready to submit your PR for review,
please
delete this section and leave only the text under the "Description"
heading.

# Description

*Please include a summary of the changes and the related issue. Please
also include relevant motivation and context,
including:*

- What does this PR do?

make 'substrate-wasm-builder' manually set 'CARGO_TARGET_DIR' to
'$project_dir/target' while building instead of unset
'CARGO_TARGET_DIR';

- Why are these changes needed?

If you using this in the `build.rs` with following content in your
`~/.cargo/config.toml':

    [build]
    target-dir = "target"

the build process will stuck because of dead lock -- two `cargo build`
on same target directory in the same time.
There is already an attempt to avoid such dead lock by unset the
`CARGO_TARGET_DIR`, but for users with config above in his build
enviroment (like me), this workaround won't work.

- How were these changes implemented and what do they affect?

Instead of unset 'CARGO_TARGET_DIR', we set 'CARGO_TARGET_DIR' to
'$project/target/', which is already assumed to be true by rest of the
code.

*Use [Github semantic

linking](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)
to address any open issues this PR relates to or closes.*

Fixes # (issue number, *if applicable*)

Closes # (issue number, *if applicable*)

# Checklist

- [x] My PR includes a detailed description as outlined in the
"Description" section above
- [ ] My PR follows the [labeling requirements](CONTRIBUTING.md#Process)
of this project (at minimum one label for `T`
  required)
- [ ] I have made corresponding changes to the documentation (if
applicable)
- [ ] I have added tests that prove my fix is effective or that my
feature works (if applicable)

You can remove the "Checklist" section once all have been checked. Thank
you for your contribution!

✄
-----------------------------------------------------------------------------

I have built my project with this fix, there's still some warnings with
`build.target-dir` set but the building process won't hang.
I haven't found related issue in this repo. But I did find one issue
[here](https://github.com/substrate-developer-hub/substrate-node-template/issues/116).
      38c3c625
  63. Oct 20, 2023
    • Bastian Köcher's avatar
      `xcm`: Change `TypeInfo::path` to not include `staging` (#1948) · f3bf5c1a
      Bastian Köcher authored 
      The `xcm` crate was renamed to `staging-xcm` to be able to publish it to
crates.io as someone as squatted `xcm`. The problem with this rename is
that the `TypeInfo` includes the crate name which ultimately lands in
the metadata. The metadata is consumed by downstream users like
`polkadot-js` or people building on top of `polkadot-js`. These people
are using the entire `path` to find the type in the type registry. Thus,
their code would break as the type path would now be [`staging_xcm`,
`VersionedXcm`] instead of [`xcm`, `VersionedXcm`]. This pull request
fixes this by renaming the path segment `staging_xcm` to `xcm`.

This requires: https://github.com/paritytech/scale-info/pull/197



---------

Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      f3bf5c1a
  65. Oct 11, 2023
  67. Oct 10, 2023
    • Liam Aharon's avatar
      remote-ext: fix state download stall on slow connections and reduce memory usage (#1295) · 55f35442
      Liam Aharon authored 
      Original PR https://github.com/paritytech/substrate/pull/14746

---

## Fixing stall

### Introduction
I experienced an apparent stall downloading state from
`https://rococo-try-runtime-node.parity-chains.parity.io:443` which was
having networking difficulties only responding to my JSONRPC requests
with 50-200KB/s of bandwidth.

This PR fixes the issue causing the stall, and generally improves
performance remote-ext when it downloads state by greatly reducing the
chances of a timeout occuring.

### Description
Introduces a new `REQUEST_DURATION_TARGET` constant and modifies
`get_storage_data_dynamic_batch_size` to

- Increase or decrease the batch size of the next request depending on
whether the elapsed time of the last request was gt or lt the target
- Reset the batch size to 1 if the request times out

This fixes an issue on slow connections that can otherwise cause
multiple timeouts and a stalled download when:

1. The batch size increases rapidly as remote-ext downloads keys with
small associated storage values
2. remote-ext tries to process a large series of subsequent keys all
with extremely large associated storage values (Rococo has a series of
keys 1-5MB large)
3. The huge storage values download for 5 minutes until the request
times out
4. The partially downloaded keys are thrown out and remote-ext tries
again with a smaller batch size, but the batch size is still far too
large and takes 5 minutes to be reduced again
5. The download will be essentially stalled for many hours while the
above step cycles


After this PR, the request size will

- Not grow as large to begin with, as it is regulated downwards as the
request duration exceeds the target
- Drop immediately to 1 if the request times out. A timeout indicates
the keys next in line to download have extremely large storage values
compared to previously downloaded keys, and we need to reset the batch
size to figure out what our new ideal batch size is. By not resetting
down to 1, we risk the next request timing out again.

## Reducing memory

As suggested by @bkchr, I adjusted `get_storage_data_dynamic_batch_size`
from being recursive to a loop which allows removing a bunch of clones
that were chewing through a lot of memory. I noticed actually it was
using up to 50GB swap previously when downloading Polkadot keys on a
slow connection, because it needed to recurse and clone a lot.

After this change it uses only ~1.5GB memory.
      55f35442
  69. Oct 05, 2023