Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

https://github.com/rmrk-team/rmrk-substrate

[WIP] RMRK Substrate pallets
https://github.com/rmrk-team/rmrk-substrate

blockchain polkadot rust substrate

Last synced: 3 months ago
JSON representation

[WIP] RMRK Substrate pallets

Lists

README 

        
# RMRK Substrate



[![No Maintenance Intended](http://unmaintained.tech/badge.svg)](http://unmaintained.tech/)



> **Warning**: No stability and security guarantees. Not production ready.



Additional documentation [https://rmrk-team.github.io/rmrk-substrate](https://rmrk-team.github.io/rmrk-substrate)



### Rust Setup



First, complete the [basic Rust setup instructions](./rust-setup.md).



### Run



Use Rust's native `cargo` command to build and launch the template node:



```sh

cargo run --release -- --dev --tmp

```



### Build



The `cargo run` command will perform an initial build. Use the following command to build the node

without launching it:



```sh

cargo build --release

```



### RPC



The RMRK RPC description can be found in [RPC docs](https://rmrk-team.github.io/rmrk-substrate/#/rpc)



The RPC is declared in the `rmrk-rpc` crate.



The Runtime implements the RPC API in the `runtime/src/lib.rs` inside the `impl_runtime_apis` macro.

The node exposes the RPC interface described in the `rpc.md`. The RPC interface implementation passes each RPC call to the RMRK runtime API. The RPC interface declaration and implementation can be found in the file `node/src/rpc.rs`.



### Integration Tests



The Integration Tests are located in the `tests/src` directory. They use the RPC interface to fetch data from the node.



- All transactions used in the tests are located in `tests/src/util/tx.ts`.

- All "fetch" functions like `getNft` are located in `tests/src/util/fetch.ts`. Here you can see an example of the RPC interface usage.

- All "helper" functions are located in `tests/src/util/helpers.ts`.

- Type augmentation located in `tests/src/interfaces`, **autogenerated**, a lot of lines of code :)



##### How to start the tests



```console

# (In the rmrk-substrate directory)



# Run the node

cargo run --release -- --dev --tmp



# (In another terminal)

# Start the tests

cd tests && yarn test

```



Instead of running all the tests at once, you can run a separate test if you like.

For instance, you can type `yarn testSendNft` to run the `tests/src/sendNft.test.ts` test.



All the tests have the following name pattern: `.test.ts`. To run a separate test you can type the following: `yarn test`



### Embedded Docs



Once the project has been built, the following command can be used to explore all parameters and

subcommands:



```sh

./target/release/rmrk-substrate -h

```



## Run



The provided `cargo run` command will launch a temporary node and its state will be discarded after

you terminate the process. After the project has been built, there are other ways to launch the

node.



### Single-Node Development Chain



This command will start the single-node development chain with persistent state:



```bash

./target/release/rmrk-substrate --dev

```



Purge the development chain's state:



```bash

./target/release/rmrk-substrate purge-chain --dev

```



Start the development chain with detailed logging:



```bash

RUST_BACKTRACE=1 ./target/release/rmrk-substrate -ldebug --dev

```



### Connect with Polkadot-JS Apps Front-end



Once the node template is running locally, you can connect it with **Polkadot-JS Apps** front-end

to interact with your chain. [Click

here](https://polkadot.js.org/apps/#/explorer?rpc=ws://localhost:9944) connecting the Apps to your

local node template.



### Node



A blockchain node is an application that allows users to participate in a blockchain network.

Substrate-based blockchain nodes expose a number of capabilities:



- Networking: Substrate nodes use the [`libp2p`](https://libp2p.io/) networking stack to allow the

  nodes in the network to communicate with one another.

- Consensus: Blockchains must have a way to come to

  [consensus](https://docs.substrate.io/v3/advanced/consensus) on the state of the

  network. Substrate makes it possible to supply custom consensus engines and also ships with

  several consensus mechanisms that have been built on top of

  [Web3 Foundation research](https://research.web3.foundation/en/latest/polkadot/NPoS/index.html).

- RPC Server: A remote procedure call (RPC) server is used to interact with Substrate nodes.



There are several files in the `node` directory - take special note of the following:



- [`chain_spec.rs`](./node/src/chain_spec.rs): A

  [chain specification](https://docs.substrate.io/v3/runtime/chain-specs) is a

  source code file that defines a Substrate chain's initial (genesis) state. Chain specifications

  are useful for development and testing, and critical when architecting the launch of a

  production chain. Take note of the `development_config` and `testnet_genesis` functions, which

  are used to define the genesis state for the local development chain configuration. These

  functions identify some

  [well-known accounts](https://docs.substrate.io/v3/tools/subkey#well-known-keys)

  and use them to configure the blockchain's initial state.

- [`service.rs`](./node/src/service.rs): This file defines the node implementation. Take note of

  the libraries that this file imports and the names of the functions it invokes. In particular,

  there are references to consensus-related topics, such as the

  [longest chain rule](https://docs.substrate.io/v3/advanced/consensus#longest-chain-rule),

  the [Aura](https://docs.substrate.io/v3/advanced/consensus#aura) block authoring

  mechanism and the

  [GRANDPA](https://docs.substrate.io/v3/advanced/consensus#grandpa) finality

  gadget.



After the node has been [built](#build), refer to the embedded documentation to learn more about the

capabilities and configuration parameters that it exposes:



```shell

./target/release/rmrk-substrate --help

```



### Runtime



In Substrate, the terms

"[runtime](https://docs.substrate.io/v3/getting-started/glossary#runtime)" and

"[state transition function](https://docs.substrate.io/v3/getting-started/glossary#state-transition-function-stf)"

are analogous - they refer to the core logic of the blockchain that is responsible for validating

blocks and executing the state changes they define. The Substrate project in this repository uses

the [FRAME](https://docs.substrate.io/v3/runtime/frame) framework to construct a

blockchain runtime. FRAME allows runtime developers to declare domain-specific logic in modules

called "pallets". At the heart of FRAME is a helpful

[macro language](https://docs.substrate.io/v3/runtime/macros) that makes it easy to

create pallets and flexibly compose them to create blockchains that can address

[a variety of needs](https://www.substrate.io/substrate-users/).



Review the [FRAME runtime implementation](./runtime/src/lib.rs) included in this template and note

the following:



- This file configures several pallets to include in the runtime. Each pallet configuration is

  defined by a code block that begins with `impl $PALLET_NAME::Config for Runtime`.

- The pallets are composed into a single runtime by way of the

  [`construct_runtime!`](https://crates.parity.io/frame_support/macro.construct_runtime.html)

  macro, which is part of the core

  [FRAME Support](https://docs.substrate.io/v3/runtime/frame#support-crate)

  library.



### Pallets



The runtime in this project is constructed using many FRAME pallets that ship with the

[core Substrate repository](https://github.com/paritytech/substrate/tree/master/frame) and a

template pallet that is [defined in the `pallets`](./pallets/template/src/lib.rs) directory.



A FRAME pallet is compromised of a number of blockchain primitives:



- Storage: FRAME defines a rich set of powerful

  [storage abstractions](https://docs.substrate.io/v3/runtime/storage) that makes

  it easy to use Substrate's efficient key-value database to manage the evolving state of a

  blockchain.

- Dispatchables: FRAME pallets define special types of functions that can be invoked (dispatched)

  from outside of the runtime in order to update its state.

- Events: Substrate uses [events and errors](https://docs.substrate.io/v3/runtime/events-and-errors)

  to notify users of important changes in the runtime.

- Errors: When a dispatchable fails, it returns an error.

- Config: The `Config` configuration interface is used to define the types and parameters upon

  which a FRAME pallet depends.