Benjamin Kampmann
c78c2892a4
* mark template and utils as non-publish * switch to development version for testing * activate unleash check * maybe if I disable all rules... * Fix isolated compilation of `max-encoded-len-derive` with `syn` error[E0369]: binary operation `==` cannot be applied to type `syn::Path` --> src/lib.rs:88:29 | 88 | .filter(|attr| attr.path == parse_quote!(max_encoded_len_crate)) | --------- ^^ ----------------------------------- _ | | | syn::Path error: aborting due to previous error For more information about this error, try `rustc --explain E0369`. Error: could not compile `max-encoded-len-derive` * WIP: bump changes crates since v3 tag to next breaking cargo unleash version bump-breaking --changed-since v3.0.0 cargo unleash version set-pre dev --changed-since v3.0.0 FIXME: Don't modify crates that are not yet released, e.g. `max-encoded-len-derive` * Update lockfile * WIP: Bump sp-transaction-pool as well * WIP: Bump sp-offchain as well * WIP: Bump frame-system-rpc-runtime-api as well * WIP: Bump sp-authority-discovery as well * Manually deactivate dev-deps before `cargo unleash check` Otherwise we run into `Cycle detected` error. * Bump sp-consensus-slots * Add missing Cargo.lock change * Bump sp-consensus-vrf as well * Bump sp-keyring as well * Bump sp-consensus-pow as well * Try to speed up the `unleash-check` job Previously, the job took 106 minutes - let's see if explicitly specifying a `CARGO_TARGET_DIR` will help * fixup: Ensure the temp target dir exists for unleash check * Bump pallet-transaction-payment-rpc-runtime-api as well Needed for Polkadot * Bump pallet-transaction-payment-rpc as well Needed for Polkadot * Try updating crates after patching in the Polkadot CI job * Use another approach to update patched Substrate crates * Try to update all sp-core versions in Polkadot CI job * Simplify sp-core version checking * Apply another shellcheck lint * Just do the simplest thing I guess * Welp don't do --offline then * Clean up `unleash-check` job triggers Co-authored-by: Denis Pisarev <denis.pisarev@parity.io> * Fix a note in unleash-check cache step * Add a note about temporary optimization in cargo-unleash * Pin a newer version of cargo-unleash Co-authored-by: Igor Matuszewski <xanewok@gmail.com> Co-authored-by: Denis Pisarev <denis.pisarev@parity.io>
Contract Module
The Contract module provides functionality for the runtime to deploy and execute WebAssembly smart-contracts.
Overview
This module extends accounts based on the Currency trait to have smart-contract functionality. It can
be used with other modules that implement accounts based on Currency. These "smart-contract accounts"
have the ability to instantiate smart-contracts and make calls to other contract and non-contract accounts.
The smart-contract code is stored once in a code_cache, and later retrievable via its code_hash.
This means that multiple smart-contracts can be instantiated from the same code_cache, without replicating
the code each time.
When a smart-contract is called, its associated code is retrieved via the code hash and gets executed. This call can alter the storage entries of the smart-contract account, instantiate new smart-contracts, or call other smart-contracts.
Finally, when an account is reaped, its associated code and storage of the smart-contract account will also be deleted.
Gas
Senders must specify a gas limit with every call, as all instructions invoked by the smart-contract require gas. Unused gas is refunded after the call, regardless of the execution outcome.
If the gas limit is reached, then all calls and state changes (including balance transfers) are only reverted at the current call's contract level. For example, if contract A calls B and B runs out of gas mid-call, then all of B's calls are reverted. Assuming correct error handling by contract A, A's other calls and state changes still persist.
One gas is equivalent to one weight which is defined as one picosecond of execution time on the runtime's reference machine.
Notable Scenarios
Contract call failures are not always cascading. When failures occur in a sub-call, they do not "bubble up", and the call will only revert at the specific contract level. For example, if contract A calls contract B, and B fails, A can decide how to handle that failure, either proceeding or reverting A's changes.
Interface
Dispatchable functions
Those are documented in the reference documentation.
Usage
This module executes WebAssembly smart contracts. These can potentially be written in any language
that compiles to web assembly. However, using a language that specifically targets this module
will make things a lot easier. One such language is ink
which is an eDSL that enables
writing WebAssembly based smart contracts in the Rust programming language.
Debugging
Contracts can emit messages to the client when called as RPC through the seal_debug_message
API. This is exposed in ink! via
ink_env::debug_println().
Those messages are gathered into an internal buffer and send to the RPC client. It is up the the individual client if and how those messages are presented to the user.
This buffer is also printed as a debug message. In order to see these messages on the node
console the log level for the runtime::contracts target needs to be raised to at least
the debug level. However, those messages are easy to overlook because of the noise generated
by block production. A good starting point for observing them on the console is using this
command line in the root directory of the substrate repository:
cargo run --release -- --dev --tmp -lerror,runtime::contracts=debug
This raises the log level of runtime::contracts to debug and all other targets
to error in order to prevent them from spamming the console.
--dev: Use a dev chain spec
--tmp: Use temporary storage for chain data (the chain state is deleted on exit)
Unstable Interfaces
Driven by the desire to have an iterative approach in developing new contract interfaces this pallet contains the concept of an unstable interface. Akin to the rust nightly compiler it allows us to add new interfaces but mark them as unstable so that contract languages can experiment with them and give feedback before we stabilize those.
In order to access interfaces marked as __unstable__ in runtime.rs one need to compile
this crate with the unstable-interface feature enabled. It should be obvious that any
live runtime should never be compiled with this feature: In addition to be subject to
change or removal those interfaces do not have proper weights associated with them and
are therefore considered unsafe.
The substrate runtime exposes this feature as contracts-unstable-interface. Example
commandline for running the substrate node with unstable contracts interfaces:
cargo run --release --features contracts-unstable-interface -- --dev
New interfaces are generally added as unstable and might go through several iterations before they are promoted to a stable interface.
License: Apache-2.0