Keith Yeung
3dece311be
Combination of paritytech/polkadot#7005, its addon PR paritytech/polkadot#7585 and its companion paritytech/cumulus#2433. This PR introduces a new XcmFeesToAccount struct which implements the `FeeManager` trait, and assigns this struct as the `FeeManager` in the XCM config for all runtimes. The struct simply deposits all fees handled by the XCM executor to a specified account. In all runtimes, the specified account is configured as the treasury account. XCM __delivery__ fees are now being introduced (unless the root origin is sending a message to a system parachain on behalf of the originating chain). # Note for reviewers Most file changes are tests that had to be modified to account for the new fees. Main changes are in: - cumulus/pallets/xcmp-queue/src/lib.rs <- To make it track the delivery fees exponential factor - polkadot/xcm/xcm-builder/src/fee_handling.rs <- Added. Has the FeeManager implementation - All runtime xcm_config files <- To add the FeeManager to the XCM configuration # Important note After this change, instructions that create and send a new XCM (Query*, Report*, ExportMessage, InitiateReserveWithdraw, InitiateTeleport, DepositReserveAsset, TransferReserveAsset, LockAsset and RequestUnlock) will require the corresponding origin account in the origin register to pay for transport delivery fees, and the onward message will fail to be sent if the origin account does not have the required amount. This delivery fee is on top of what we already collect as tx fees in pallet-xcm and XCM BuyExecution fees! Wallet UIs that want to expose the new delivery fee can do so using the formula: ``` delivery_fee_factor * (base_fee + encoded_msg_len * per_byte_fee) ``` where the delivery fee factor can be obtained from the corresponding pallet based on which transport you are using (UMP, HRMP or bridges), the base fee is a constant, the encoded message length from the message itself and the per byte fee is the same as the configured per byte fee for txs (i.e. `TransactionByteFee`). --------- Co-authored-by: Branislav Kontur <bkontur@gmail.com> Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com> Co-authored-by: Giles Cope <gilescope@gmail.com> Co-authored-by: command-bot <> Co-authored-by: Francisco Aguirre <franciscoaguirreperez@gmail.com> Co-authored-by: Liam Aharon <liam.aharon@hotmail.com> Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Contracts 📝
This is a parachain node for smart contracts; it contains a default configuration of
Substrate's module for smart contracts ‒ the pallet-contracts.
The node is only available on Rococo, a testnet for Polkadot and Kusama parachains.
It has been configured as a common good parachain, as such it uses the Rococo relay
chain's native token ROC instead of defining a token of its own.
See the section Rococo Deployment below for more details.
If you have any questions, it's best to ask in the Substrate StackExchange.
Smart Contracts Development
This node contains Substrate's smart contracts module ‒ the
pallet-contracts.
This pallet takes smart contracts as WebAssembly blobs and defines an API
for everything a smart contract needs (storage access, …).
As long as a programming language compiles to WebAssembly and there exists an implementation
of this API in it, you can write a smart contract for this pallet (and thus for this parachain)
in that language.
This is a list of languages you can currently choose from:
- Parity's ink! for Rust.
- ask! for Assembly Script.
- The Solang compiler for Solidity.
There are also different user interfaces and command-line tools you can use to deploy or interact with contracts:
- Contracts UI ‒ a beginner-friendly UI for smart contract developers.
polkadot-js‒ the go-to expert UI for smart contract developers.cargo-contract‒ a CLI tool, ideal for scripting or your terminal workflow.
If you are looking for a quickstart, we can recommend ink!'s Guided Tutorial for Beginners.
Build & Launch a Node
To run a Contracts node that connects to Rococo
you will need to compile the polkadot-parachain binary:
cargo build --release --locked --bin polkadot-parachain
Once the executable is built, launch the parachain node via:
./target/release/polkadot-parachain --chain contracts-rococo
Refer to the setup instructions to run a local network for development.
Rococo Deployment
We have a live deployment on Rococo ‒ a testnet for Polkadot and Kusama parachains.
You can interact with the network through Polkadot JS Apps, click here for a direct link to the parachain.
This parachain uses the Rococo relay chain's native token ROC instead of defining a token of its own.
Due to this you'll need ROC in order to deploy contracts on this parachain.
As a first step, you should create an account. See here for a detailed guide.
As a second step, you have to get ROC testnet tokens through the Rococo Faucet.
This is a chat room in which you'd need to post the following message:
!drip YOUR_SS_58_ADDRESS:1002
The number 1002 is the id of this parachain on Rococo, by supplying it the faucet will teleport ROC
tokens directly to your account on the parachain.
If everything worked out, the teleported ROC tokens will show up under
the "Accounts" tab.
Once you have ROC you can deploy a contract as you would normally.
If you're unsure about this, our guided tutorial
will clarify that for you in no time.