Skip to content
Snippets Groups Projects
  1. Dec 03, 2024
  2. Oct 31, 2024
  3. Aug 28, 2024
  4. Aug 23, 2024
    • Alexander Theißen's avatar
      Add initial version of `pallet_revive` (#5293) · 559fa1db
      Alexander Theißen authored
      This is a heavily modified and stripped down version of
      `pallet_contracts`. We decided to fork instead of extend the old pallet.
      Reasons for that are:
      
      - There is no benefit of supporting both on the same pallet as the
      intended payload for the new pallet (recompiled YUL) will be using a
      different ABI.
      - It is much easier since it allows us to remove all the code that was
      necessary to support Wasm and focus fully on running cross compiled YUL
      contracts.
      
      **The code is reviewable but can't be merged because it depends on an
      unreleased version of PolkaVM via git.**
      
      ## Current state
      
      All tests are passing and the code is not quick and dirty but written to
      last. The work is not finished, though. It is included in the
      `kitchensink-runtime` and a node can be built. However, we merge early
      in order to be able to start testing other components as early as
      possible.
      
      Outstanding changes are tracked here and will be merged separately:
      https://github.com/paritytech/polkadot-sdk/issues/5308
      
      ## Syscall Interface
      
      The syscall interface is best explored by generating the docs of this
      crate and looking at the `SyscallDoc` trait. Arguments are passed in
      registers a0-a5 in the order they are listed. If there are more than 6
      arguments (call, instantiate) a pointer to a packed struct of the
      arguments is expected as the only argument. I plan to create variants of
      those syscalls with less arguments specifically for YUL.
      
      Functions are just referenced by their name as ASCII within the PolkaVM
      container. Rather than by a syscall number as it was the case in the
      last implementation.
       
      
      ## Changes vs. `pallet_contracts`
      
      The changes are too numerous to list them all here. This is an
      incomplete list:
      
      - Use PolkaVM instead of wasmi to execute contracts
      - Made Runtime generic over a new `Memory` trait as we can't map memory
      directly on PolkaVM anymore
      - No static verification on code upload. Everything is a determinstic
      runtime failure
      - Removed all migrations and reset the pallet version
      - Removed the nonce storage item and instead use the deployers account
      nonce to generate a unique trie
      - We now bump the deployers account nonce on contract instantiation to
      they are bumped even within a batch transaction
      - Removed the instantiation nonce host function: We should add a new
      `instantiate` variant as a replacement for thos
      - ContractInfoOf of uses the indentity hasher now
      - Remove the determinism feature: User of that feature should switch to
      soft floats
      - The `unstable` attribute has been replaced by a `api_version`
      attribute to declare at which version an API became available
      	- leaving out that attribute makes the API effectively unstable
      - a new `api_version` field on the CodeInfo makes sure that old
      contracts can't access new APIs (necessary due to lack of static
      verification.
      - Added a `behaviour_version` field to CodeInfo that can used if we need
      to introduce breaking changes and keep the old behaviour for existing
      contracts
      - Unified storage vs. transient and fixed vs. variable sized keys all
      into one set of multiplexing host functions
      - Removed all contract observeable limits from the `Config` trait and
      instead hardcode them
      - Removed the Schedule
      - Removed all deprecated host functions
      - Simplify chain extension as preperation for making it a pre-compile
      
      ---------
      
      Co-authored-by: command-bot <>
  5. Aug 07, 2024
  6. Jul 26, 2024
  7. May 24, 2024
    • Oliver Tale-Yazdi's avatar
      Polkadot-SDK Umbrella Crate (#3935) · 1c7a1a58
      Oliver Tale-Yazdi authored
      
      # Umbrella Crate
      
      The Polkadot-SDK "umbrella" is a crate that re-exports all other
      published crates. This makes it
      possible to have a very small `Cargo.toml` file that only has one
      dependency, the umbrella
      crate. This helps with selecting the right combination of crate
      versions, since otherwise 3rd
      party tools are needed to select a compatible set of versions.
      
      ## Features
      
      The umbrella crate supports no-std builds and can therefore be used in
      the runtime and node.
      There are two main features: `runtime` and `node`. The `runtime` feature
      enables all `no-std`
      crates, while the `node` feature enables all `std` crates. It should be
      used like any other
      crate in the repo, with `default-features = false`.
      
      For more fine-grained control, additionally, each crate can be enabled
      selectively. The umbrella
      exposes one feature per dependency. For example, if you only want to use
      the `frame-support`
      crate, you can enable the `frame-support` feature.
      
      The umbrella exposes a few more general features:
      - `tuples-96`: Needs to be enabled for runtimes that have more than 64
      pallets.
      - `serde`: Specifically enable `serde` en/decoding support.
      - `experimental`: Experimental enable experimental features - should not
      yet used in production.
      - `with-tracing`: Enable tracing support.
      - `try-runtime`, `runtime-benchmarks` and `std`: These follow the
      standard conventions.
      - `runtime`: As described above, enable all `no-std` crates.
      - `node`: As described above, enable all `std` crates.
      - There does *not* exist a dedicated docs feature. To generate docs,
      enable the `runtime` and
      `node` feature. For docs.rs the manifest contains specific configuration
      to make it show up
        all re-exports.
      
      There is a specific `zepter` check in place to ensure that the features
      of the umbrella are
      correctly configured. This check is run in CI and locally when running
      `zepter`.
      
      ## Generation
      
      The umbrella crate needs to be updated every time when a new crate is
      added or removed from the
      workspace. It is checked in CI by calling its generation script. The
      generation script is
      located in `./scripts/generate-umbrella.py` and needs dependency
      `cargo_workspace`.
      
      Example: `python3 scripts/generate-umbrella.py --sdk . --version 1.9.0`
      
      ## Usage
      
      > Note: You can see a live example in the `staging-node-cli` and
      `kitchensink-runtime` crates.
      
      The umbrella crate can be added to your runtime crate like this:
      
      `polkadot-sdk = { path = "../../../../umbrella", features = ["runtime"],
      default-features =
      false}`
      
      or for a node:
      
      `polkadot-sdk = { path = "../../../../umbrella", features = ["node"],
      default-features = false
      }`
      
      In the code, it is then possible to bring all dependencies into scope
      via:
      
      `use polkadot_sdk::*;`
      
      ### Known Issues
      
      The only known issue so far is the fact that the `use` statement brings
      the dependencies only
      into the outer module scope - not the global crate scope. For example,
      the following code would
      need to be adjusted:
      
      ```rust
      use polkadot_sdk::*;
      
      mod foo {
         // This does sadly not compile:
         frame_support::parameter_types! { }
      
         // Instead, we need to do this (or add an equivalent `use` statement):
         polkadot_sdk::frame_support::parameter_types! { }
      }
      ```
      
      Apart from this, no issues are known. There could be some bugs with how
      macros locate their own
      re-exports. Please compile issues that arise from using this crate.
      
      ## Dependencies
      
      The umbrella crate re-exports all published crates, with a few
      exceptions:
      - Runtime crates like `rococo-runtime` etc are not exported. This
      otherwise leads to very weird
        compile errors and should not be needed anyway.
      - Example and fuzzing crates are not exported. This is currently
      detected by checking the name
      of the crate for these magic words. In the future, it will utilize
      custom metadata, as it is
        done in the `rococo-runtime` crate.
      - The umbrella crate itself. Should be obvious :)
      
      ## Follow Ups
      - [ ] Re-writing the generator in Rust - the python script is at its
      limit.
      - [ ] Using custom metadata to exclude some crates instead of filtering
      by names.
      - [ ] Finding a way to setting the version properly. Currently its
      locked in the CI script.
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <oliver.tale-yazdi@parity.io>