Skip to content
  1. Apr 22, 2024
  2. Apr 02, 2024
  3. Mar 26, 2024
    • Dcompoze's avatar
      Fix spelling mistakes across the whole repository (#3808) · 002d9260
      Dcompoze authored
      **Update:** Pushed additional changes based on the review comments.
      
      **This pull request fixes various spelling mistakes in this
      repository.**
      
      Most of the changes are contained in the first **3** commits:
      
      - `Fix spelling mistakes in comments and docs`
      
      - `Fix spelling mistakes in test names`
      
      - `Fix spelling mistakes in error messages, panic messages, logs and
      tracing`
      
      Other source code spelling mistakes are separated into individual
      commits for easier reviewing:
      
      - `Fix the spelling of 'authority'`
      
      - `Fix the spelling of 'REASONABLE_HEADERS_IN_JUSTIFICATION_ANCESTRY'`
      
      - `Fix the spelling of 'prev_enqueud_messages'`
      
      - `Fix the spelling of 'endpoint'`
      
      - `Fix the spelling of 'children'`
      
      - `Fix the spelling of 'PenpalSiblingSovereignAccount'`
      
      - `Fix the spelling of 'PenpalSudoAccount'`
      
      - `Fix the spelling of 'insufficient'`
      
      - `Fix the spelling of 'PalletXcmExtrinsicsBenchmark'`
      
      - `Fix the spelling of 'subtracted'`
      
      - `Fix the spelling of 'CandidatePendingAvailability'`
      
      - `Fix the spelling of 'exclusive'`
      
      - `Fix the spelling of 'until'`
      
      - `Fix the spelling of 'discriminator'`
      
      - `Fix the spelling of 'nonexistent'`
      
      - `Fix the spelling of 'subsystem'`
      
      - `Fix the spelling of 'indices'`
      
      - `Fix the spelling of 'committed'`
      
      - `Fix the spelling of 'topology'`
      
      - `Fix the spelling of 'response'`
      
      - `Fix the spelling of 'beneficiary'`
      
      - `Fix the spelling of 'formatted'`
      
      - `Fix the spelling of 'UNKNOWN_PROOF_REQUEST'`
      
      - `Fix the spelling of 'succeeded'`
      
      - `Fix the spelling of 'reopened'`
      
      - `Fix the spelling of 'proposer'`
      
      - `Fix the spelling of 'InstantiationNonce'`
      
      - `Fix the spelling of 'depositor'`
      
      - `Fix the spelling of 'expiration'`
      
      - `Fix the spelling of 'phantom'`
      
      - `Fix the spelling of 'AggregatedKeyValue'`
      
      - `Fix the spelling of 'randomness'`
      
      - `Fix the spelling of 'defendant'`
      
      - `Fix the spelling of 'AquaticMammal'`
      
      - `Fix the spelling of 'transactions'`
      
      - `Fix the spelling of 'PassingTracingSubscriber'`
      
      - `Fix the spelling of 'TxSignaturePayload'`
      
      - `Fix the spelling of 'versioning'`
      
      - `Fix the spelling of 'descendant'`
      
      - `Fix the spelling of 'overridden'`
      
      - `Fix the spelling of 'network'`
      
      Let me know if this structure is adequate.
      
      **Note:** The usage of the words `Merkle`, `Merkelize`, `Merklization`,
      `Merkelization`, `Merkleization`, is somewhat inconsistent but I left it
      as it is.
      
      ~~**Note:** In some places the term `Receival` is used to refer to
      message reception, IMO `Reception` is the correct word here, but I left
      it as it is.~~
      
      ~~**Note:** In some places the term `Overlayed` is used instead of the
      more acceptable version `Overlaid` but I also left it as it is.~~
      
      ~~**Note:** In some places the term `Applyable` is used instead of the
      correct version `Applicable` but I also left it as it is.~~
      
      **Note:** Some usage of British vs American english e.g. `judgement` vs
      `judgment`, `initialise` vs `initialize`, `optimise` vs `optimize` etc.
      are both present in different places, but I suppose that's
      understandable given the number of contributors.
      
      ~~**Note:** There is a spelling mistake in `.github/CODEOWNERS` but it
      triggers errors in CI when I make changes to it, so I left it as it
      is.~~
      002d9260
  4. Mar 12, 2024
    • Koute's avatar
      Add a PolkaVM-based executor (#3458) · b0f34e4b
      Koute authored
      This PR adds a new PolkaVM-based executor to Substrate.
      
      - The executor can now be used to actually run a PolkaVM-based runtime,
      and successfully produces blocks.
      - The executor is always compiled-in, but is disabled by default.
      - The `SUBSTRATE_ENABLE_POLKAVM` environment variable must be set to `1`
      to enable the executor, in which case the node will accept both WASM and
      PolkaVM program blobs (otherwise it'll default to WASM-only). This is
      deliberately undocumented and not explicitly exposed anywhere (e.g. in
      the command line arguments, or in the API) to disincentivize anyone from
      enabling it in production. If/when we'll move this into production usage
      I'll remove the environment variable and do it "properly".
      - I did not use our legacy runtime allocator for the PolkaVM executor,
      so currently every allocation inside of the runtime will leak guest
      memory until that particular instance is destroyed. The idea here is
      that I will work on the https://github.com/polkadot-fellows/RFCs/pull/4
      which will remove the need for the legacy allocator under WASM, and that
      will also allow us to use a proper non-leaking allocator under PolkaVM.
      - I also did some minor cleanups of the WASM executor and deleted some
      dead code.
      
      No prdocs included since this is not intended to be an end-user feature,
      but an unofficial experiment, and shouldn't affect any current
      production user. Once this is production-ready a full Polkadot
      Fellowship RFC will be necessary anyway.
      b0f34e4b
  5. Feb 28, 2024
  6. Feb 22, 2024
    • Koute's avatar
      Fix `wasm-builder` not exiting if compilation fails (#3439) · 82208280
      Koute authored
      This PR fixes a subtle bug in `wasm-builder` first introduced in
      https://github.com/paritytech/polkadot-sdk/pull/1851 (sorry, my bad! I
      should have caught this during review) where the status code of the
      `cargo` subprocess is not properly checked, which results in builds
      silently succeeding when they shouldn't (that is: if we successfully
      build a runtime blob, and then modify the code so that it won't compile,
      and recompile it again, then the build will succeed and silently use the
      *old* blob).
      
      cc @athei This is the bug you were seeing.
      
      [edit]Also fixes a similar PolkaVM-specific bug where I accidentally
      used the wrong comparison operator.[/edit]
      82208280
  7. Feb 06, 2024
    • Koute's avatar
      Build more runtimes targeting PolkaVM (#3209) · 402b64ca
      Koute authored
      This PR improves compatibility with RISC-V and PolkaVM, allowing more
      runtimes to successfully compile.
      
      In particular, it makes the following changes:
      
      - The `sp-mmr-primitives` and `sp-consensus-beefy` crates
      unconditionally required an `std`-only dependency; now they only require
      those dependencies when the `std` feature is actually enabled. (Our
      RISC-V target is, unlike WASM, a true `no_std` target where you can't
      accidentally use stuff from `std` anymore.)
      - One of our dependencies (the `bitvec` trace) uses a crate called
      `radium` which doesn't compile under RISC-V due to incomplete
      autodetection logic in their `build.rs` file. The good news is that this
      is already fixed in the newest upstream version of `radium`, and the
      newest version of `bitvec` uses it. The bad news is that the newest
      version of `bitvec` is not currently released on crates.io, so we can't
      use it. I've [created an
      issue](https://github.com/ferrilab/ferrilab/issues/5) asking for a new
      release, but in the meantime I forked the currently used `radium` 0.7,
      [fixed the faulty
      logic](https://github.com/paritytech/radium-0.7-fork/commit/ed66c8a294b138c67f93499644051d97d4c7fbda)
      and used cargo's patching capabilities to use it for the RISC-V runtime
      builds. This might be a little hacky, but it is the least intrusive way
      to fix the problem, doesn't affect WASM builds at all, and we can
      trivially remove it once a new `bitvec` is released.
      - The new runtimes are added to the CI to make sure their compilation
      doesn't break.
      402b64ca
  8. Feb 03, 2024
    • Koute's avatar
      Initial support for building RISC-V runtimes targeting PolkaVM (#3179) · e349fc9e
      Koute authored
      This PR adds initial support for building RISC-V runtimes targeting
      PolkaVM.
      
      - Setting the `SUBSTRATE_RUNTIME_TARGET=riscv` environment variable will
      now build a RISC-V runtime instead of a WASM runtime.
      - This only adds support for *building* runtimes; running them will need
      a PolkaVM-based executor, which I will add in a future PR.
      - Only building the minimal runtime is supported (building the Polkadot
      runtime doesn't work *yet* due to one of the dependencies).
      - The builder now sets a `substrate_runtime` cfg flag when building the
      runtimes, with the idea being that instead of doing `#[cfg(not(feature =
      "std"))]` or `#[cfg(target_arch = "wasm32")]` to detect that we're
      building a runtime you'll do `#[cfg(substrate_runtime)]`. (Switching the
      whole codebase to use this will be done in a future PR; I deliberately
      didn't do this here to keep this PR minimal and reviewable.)
      - Further renaming of things (e.g. types, environment variables and proc
      macro attributes having "wasm" in their name) to be target-agnostic will
      also be done in a future refactoring PR (while keeping backwards
      compatibility where it makes sense; I don't intend to break anyone's
      workflow or create unnecessary churn).
      - This PR also fixes two bugs in the `wasm-builder` crate:
      * The `RUSTC` environment variable is now removed when invoking the
      compiler. This prevents the toolchain version from being overridden when
      called from a `build.rs` script.
      * When parsing the `rustup toolchain list` output the `(default)` is now
      properly stripped and not treated as part of the version.
      - I've also added a minimal CI job that makes sure this doesn't break in
      the future. (cc @paritytech/ci)
      
      cc @athei
      
      
      
      ------
      
      Also, just a fun little tidbit: quickly comparing the size of the built
      runtimes it seems that the PolkaVM runtime is slightly smaller than the
      WASM one. (`production` build, with the `names` section substracted from
      the WASM's size to keep things fair, since for the PolkaVM runtime we're
      currently stripping out everything)
      
      - `.wasm`: 625505 bytes
      - `.wasm` (after wasm-opt -O3): 563205 bytes
      - `.wasm` (after wasm-opt -Os): 562987 bytes
      - `.wasm` (after wasm-opt -Oz): 536852 bytes
      - `.polkavm`: ~~580338 bytes~~ 550476 bytes (after enabling extra target
      features; I'll add those in another PR once we have an executor working)
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      e349fc9e
  9. Jan 26, 2024
  10. Jan 16, 2024
  11. Jan 13, 2024
  12. Jan 08, 2024
  13. Dec 13, 2023
  14. Nov 28, 2023
  15. 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
  16. Nov 13, 2023
  17. Oct 25, 2023
    • 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
  18. Oct 24, 2023
  19. 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
  20. Sep 13, 2023
  21. Sep 04, 2023
    • Chevdor's avatar
      Markdown linter (#1309) · a30092ab
      Chevdor authored
      
      
      * Add markdown linting
      
      - add linter default rules
      - adapt rules to current code
      - fix the code for linting to pass
      - add CI check
      
      fix #1243
      
      * Fix markdown for Substrate
      * Fix tooling install
      * Fix workflow
      * Add documentation
      * Remove trailing spaces
      * Update .github/.markdownlint.yaml
      
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      * Fix mangled markdown/lists
      * Fix captalization issues on known words
      a30092ab
  22. Aug 29, 2023
  23. Aug 25, 2023
  24. Aug 16, 2023
  25. Jul 17, 2023
  26. Jul 03, 2023
  27. Jun 29, 2023
  28. May 28, 2023
    • Bastian Köcher's avatar
      wasm-builder: Enforce `runtime_version` wasm section (#14228) · 6947b334
      Bastian Köcher authored
      * wasm-builder: Enforce `runtime_version` wasm section
      
      This pr changes the `wasm-builder` to enforce the `runtime_version` wasm section. This wasm section
      is being created by the `sp_version::runtime_version` attribute macro. This attribute macro now
      exists since quite some time and `runtime_version` also is the only way for parachains to support
      reading the `RuntimeVersion` from the runtime.
      
      \# Disabling the check
      
      By default the `WasmBuilder` will now check for this wasm section and if not found, exit with an
      error. However, there are situations where you may want to disable this check (like for tests). In
      this case there exists the `disable_runtime_version_section_check` function.
      
      ```
      WasmBuilder::new()
         ...
         ...
         ...
         .disable_runtime_version_section_check()
         .build()
      ```
      
      By using this method you get back the old behavior.
      
      * Review comment
      
      * Fix
      
      * Fix issue with `enum-as-inner`
      6947b334
  29. May 05, 2023
  30. Apr 14, 2023
  31. Apr 13, 2023
  32. Apr 03, 2023
  33. Mar 30, 2023
  34. Mar 29, 2023
    • Bastian Köcher's avatar
      Support stable rust for compiling the runtime (#13580) · d338e9a1
      Bastian Köcher authored
      * Support stable rust for compiling the runtime
      
      This pull request brings support for compiling the runtime with stable Rust. This requires at least
      rust 1.68.0 to work on stable. The code is written in a way that it is backwards compatible and
      should automatically work when someone compiles with 1.68.0+ stable.
      
      * We always support nightlies!
      
      * 🤦
      
      
      
      * Sort by version
      
      * Review feedback
      
      * Review feedback
      
      * Fix version parsing
      
      * Apply suggestions from code review
      
      Co-authored-by: default avatarKoute <[email protected]>
      
      ---------
      
      Co-authored-by: default avatarKoute <[email protected]>
      d338e9a1
  35. Feb 21, 2023
    • Vivek Pandya's avatar
      Remove years from copyright notes. (#13415) · bc53b9a0
      Vivek Pandya authored
      * Change copyright year to 2023 from 2022
      
      * Fix incorrect update of copyright year
      
      * Remove years from copy right header
      
      * Fix remaining files
      
      * Fix typo in a header and remove update-copyright.sh
      bc53b9a0
  36. Feb 06, 2023
  37. Jan 24, 2023
  38. Jan 06, 2023
  39. Dec 13, 2022
    • Bastian Köcher's avatar
      Fixup some wrong dependencies (#12899) · c0c8d630
      Bastian Köcher authored
      * Fixup some wrong dependencies
      
      Dev dependencies should not appear in the feature list. If features are required, they should be
      directly enabled for the `dev-dependency`.
      
      * More fixups
      
      * Fix fix
      
      * Remove deprecated feature
      
      * Make all work properly and nice!!
      
      * FMT
      
      * Fix formatting
      c0c8d630