Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • nodes/rust/duniter-v2s
  • llaq/lc-core-substrate
  • pini-gh/duniter-v2s
  • vincentux/duniter-v2s
  • mildred/duniter-v2s
  • d0p1/duniter-v2s
  • bgallois/duniter-v2s
  • Nicolas80/duniter-v2s
8 results
Show changes
Commits on Source (376)
Showing
with 12736 additions and 6525 deletions
[alias]
cucumber = "test -p duniter-end2end-tests --test cucumber_tests --"
tu = "test --workspace --exclude duniter-end2end-tests"
xtask = "run --package xtask --"
[alias]
sanity-gdev = "test -Zgit=shallow-deps -p duniter-live-tests --test sanity_gdev -- --nocapture"
tu = "test -Zgit=shallow-deps --workspace --exclude duniter-end2end-tests --exclude duniter-live-tests --features constant-fees" # Unit tests with constant-fees
tf = "test -Zgit=shallow-deps --workspace --exclude duniter-end2end-tests --exclude duniter-live-tests test_fee" # Custom fee model tests
# `te` and `cucumber` are synonyms
te = "test -p duniter-end2end-tests --test cucumber_tests --features constant-fees --"
cucumber-build = "build -Zgit=shallow-deps --features constant-fees"
cucumber = "test -Zgit=shallow-deps -p duniter-end2end-tests --test cucumber_tests --"
ta = "test -Zgit=shallow-deps --workspace --exclude duniter-live-tests --features constant-fees"
tb = "test -Zgit=shallow-deps --features runtime-benchmarks -p"
rbp = "run -Zgit=shallow-deps --release --features runtime-benchmarks -- benchmark pallet --chain=dev --steps=50 --repeat=20 --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=. --pallet"
xtask = "run -Zgit=shallow-deps --package xtask --"
cucumber-node = "run -Zgit=shallow-deps -- --chain=gdev_dev --execution=Native --sealing=manual --force-authoring --rpc-cors=all --tmp --rpc-port 9944 --alice --features constant-fees"
......@@ -4,4 +4,6 @@
.vscode
docker/Dockerfile
docker-compose.yml
target
arm-build/
**/target/
build/
This project is tracked on our hosted gitlab server at:
https://git.duniter.org/nodes/rust/duniter-v2s
The current github repository is a simple clone taken up to date at each push on the main gitlab repository.
All contributions should be performed on the main gitlab repository.
Pull requests and issues must be created on the main gitlab repository.
Please note that all issues must be opened at https://git.duniter.org/nodes/rust/duniter-v2s/issues/new?issue
If you open issue here, it will be closed.
Thank you for your understanding.
This project is tracked on our hosted gitlab server at: https://git.duniter.org/nodes/rust/duniter-v2s
The current github repository is a simple clone taken up to date at each push on the main gitlab repository.
All contributions should be performed on the main gitlab repository.
Pull requests proposed on github will be closed.
Thank you for your understanding.
# Initial disclaimer
This project is tracked on our hosted gitlab server at:
https://git.duniter.org/nodes/rust/duniter-v2s
The current github repository is a simple clone taken up to date at each push on the main gitlab repository.
All contributions should be performed on the main gitlab repository.
Pull requests and issues must be created on the main gitlab repository.
# Original README.md
name: Check Set-Up & Build
# Controls when the action will run.
on:
# Triggers the workflow on push or pull request events but only for the master branch
push:
branches: [ master ]
pull_request:
branches: [ master ]
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
check:
# The type of runner that the job will run on
runs-on: ubuntu-20.04
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2
- name: Set-Up
run: sudo apt install -y cmake pkg-config libssl-dev git build-essential clang libclang-dev curl
- name: Install Rustup
run: |
curl https://sh.rustup.rs -sSf | sh -s -- -y
source ~/.cargo/env
rustup default stable
rustup update nightly
rustup update stable
rustup target add wasm32-unknown-unknown --toolchain nightly
- name: Check Build
run: |
SKIP_WASM_BUILD=1 cargo check --release
- name: Check Build for Benchmarking
run: >
pushd node &&
cargo check --features=runtime-benchmarks --release
......@@ -15,7 +15,8 @@
# node modules
**/node_modules/**
# build folder
# build folders
arm-build
build
# Temporary files
......
This diff is collapsed.
---
name: Ask a Question
about: Ask a question about this template.
about: Ask a question about duniter-v2s.
title: ""
labels: question
assignees: ""
......
---
name: Report a Bug
about: Report a problem with this template.
about: Report a problem with duniter-v2s.
title: ""
labels: bug
assignees: ""
......@@ -8,9 +8,7 @@ assignees: ""
**Description**
_Tell us what happened. In particular, be specific about any changes you made to this template.
Ideally, provide a link to your project's GitHub repository. Please note that we are not able to
support all conceivable changes to this template project, but the more information you are able to
_Tell us what happened. Please elaborate, the more information you are able to
provide the more equipped we will be to help._
**Steps to Reproduce**
......@@ -33,7 +31,7 @@ _Describe the environment in which you encountered this bug. Use the list below
and add additional information if you think it's relevant._
- Operating system:
- Template version/tag:
- Git commit/tag:
- Rust version (run `rustup show`):
**Logs, Errors or Screenshots**
......
---
name: Suggest a Feature
about: Suggest a new feature or an improvement to an existing feature for this template.
about: Suggest a new feature or an improvement to an existing feature for duniter-v2s.
title: ""
labels: enhancement
assignees: ""
......@@ -9,8 +9,8 @@ assignees: ""
**Motivation**
_Describe the need or frustration that motivated you to make this suggestion. Please note that the
goal of this project is to provide a general-purpose template project, so please take care when
suggesting features that may be specific to a particular use case._
goal of this project is to bring the Ğ1 blockchain itself, so please take care when
suggesting features that may not concern the Ğ1 currency._
**Suggested Solution**
......
......@@ -29,7 +29,7 @@ USER duniter
# check if executable works in this container
RUN /usr/local/bin/duniter --version
EXPOSE 30333 9933 9944
EXPOSE 30333 9944
VOLUME ["/duniter"]
ENTRYPOINT ["/usr/local/bin/duniter"]
......@@ -9,7 +9,12 @@
"request": "launch",
"name": "Debug unit tests in library 'duniter'",
"cargo": {
"args": ["test", "--no-run", "--lib", "--package=duniter"],
"args": [
"test",
"--no-run",
"--lib",
"--package=duniter"
],
"filter": {
"name": "duniter",
"kind": "lib"
......@@ -23,13 +28,20 @@
"request": "launch",
"name": "Debug executable 'duniter'",
"cargo": {
"args": ["build"],
"args": [
"build"
],
"filter": {
"name": "duniter",
"kind": "bin"
}
},
"args": ["--tmp", "--dev", "--execution", "Native"],
"args": [
"--tmp",
"--dev",
"--execution",
"Native"
],
"cwd": "${workspaceFolder}"
},
{
......@@ -37,7 +49,12 @@
"request": "launch",
"name": "Debug unit tests in executable 'duniter'",
"cargo": {
"args": ["test", "--no-run", "--bin=duniter", "--package=duniter"],
"args": [
"test",
"--no-run",
"--bin=duniter",
"--package=duniter"
],
"filter": {
"name": "duniter",
"kind": "bin"
......@@ -51,7 +68,12 @@
"request": "launch",
"name": "Debug unit tests in library 'gdev-runtime'",
"cargo": {
"args": ["test", "--no-run", "--lib", "--package=gdev-runtime"],
"args": [
"test",
"--no-run",
"--lib",
"--package=gdev-runtime"
],
"filter": {
"name": "gdev-runtime",
"kind": "lib"
......@@ -65,7 +87,12 @@
"request": "launch",
"name": "Debug unit tests in library 'pallet-certification'",
"cargo": {
"args": ["test", "--no-run", "--lib", "--package=pallet-certification"],
"args": [
"test",
"--no-run",
"--lib",
"--package=pallet-certification"
],
"filter": {
"name": "pallet-certification",
"kind": "lib"
......@@ -78,29 +105,15 @@
"type": "lldb",
"request": "launch",
"name": "Debug unit tests in library 'pallet-identity'",
"cargo": {
"args": ["test", "--no-run", "--lib", "--package=pallet-identity"],
"filter": {
"name": "pallet-identity",
"kind": "lib"
}
},
"args": [],
"cwd": "${workspaceFolder}"
},
{
"type": "lldb",
"request": "launch",
"name": "Debug unit tests in library 'pallet-ud-accounts-storage'",
"cargo": {
"args": [
"test",
"--no-run",
"--lib",
"--package=pallet-ud-accounts-storage"
"--package=pallet-identity"
],
"filter": {
"name": "pallet-ud-accounts-storage",
"name": "pallet-identity",
"kind": "lib"
}
},
......@@ -127,4 +140,4 @@
"cwd": "${workspaceFolder}"
}
]
}
}
\ No newline at end of file
{
"editor.formatOnSave": true,
"editor.rulers": [100],
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"editor.rulers": [
100
],
"[json]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
"editor.defaultFormatter": "vscode.json-language-features"
},
"[yaml]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
......@@ -18,5 +14,6 @@
"port_p2p": 19931,
"port_rpc": 19932,
"port_ws": 19933
}
}
},
"rust-analyzer.showUnlinkedFileNotification": false
}
\ No newline at end of file
# Contributing
Before contributing, please make sure that your development environment is properly configured by following this tutorial :
Before contributing, please make sure that your development environment is properly configured by following this tutorial:
[Setting up your development environment]
Sign-ups on our gitlab are disabled. If you would like to contribute, please ask for its creation on [the technical forum].
Sign-ups on our gitlab are disabled. If you would like to contribute, please ask for an account on [the technical forum].
When contributing to this repository, please first discuss the change you wish to make via issue or
via [the technical forum] before making a change.
......@@ -13,40 +13,38 @@ Please note we have a specific workflow, please follow it in all your interactio
## Developer documentation
Please read [Developer documentation] before contribute.
Please read [Developer documentation] before contributing.
## Workflow
- If there is an unassigned issue about the thing you want to contribute to, assign the issue to yourself.
- Create a branch based on `master` and prefixed with your nickname. Give your branch a short name indicating the subject.
- Create an MR from your branch to `master`.
- Never contribute to a branch of ahother contributor! If the contributor make a `git rebase` your commit will be lost !
- Create an MR from your branch to `master`. Prefix the title with `Draft: ` until it's ready to be merged.
- If the MR is related to an issue, mention the issue in the description using the `#42` syntax.
- Never push to a branch of another contributor! If the contributor makes a `git rebase` your commit will be lost!
- Before you push your commit:
- Apply formatters (rustfmt and prettier) and linter (clippy)
- Document your code.
- Document your code
- Apply the [project's git conventions]
## Merge Process
1. Ensure you rebased your branch on the latest `master` commit to avoid any merge conflicts.
2. Ensure that you respect the [commit naming conventions].
3. Ensure that all automated tests pass with the `npm test` command.
4. Update the documentation with details of changes to the interface, this includes new environment
variables, exposed ports, useful file locations and container parameters.
5. Push your branch on the gitlab and create a merge request. Briefly explain the purpose of your contribution in the description of the merge request.
6. Tag a Duniter reviewer so they will review your contribution. If you still have no news after several weeks, tag another reviewer or/and talk about your contribution on [the technical forum].
1. Ensure that you respect the [commit naming conventions].
1. Ensure that all automated tests pass with the `cargo test` command.
1. Ensure that the code is well formatted `cargo fmt` and complies with the good practices `cargo clippy`. If you have been working on tests, check everything with `cargo clippy --all --tests`.
1. Update the documentation with details of changes to the interface, this includes new environment variables, exposed ports, useful file locations and container parameters.
1. Push your branch on the gitlab and create a merge request. Briefly explain the purpose of your contribution in the description of the merge request.
1. Mark the MR as ready (or remove the `Draft: ` prefix) only when you think it can be reviewed or merged.
1. Assign a Duniter reviewer so they will review your contribution. If you still have no news after several weeks, ask explicitly for a review, or tag another reviewer or/and talk about your contribution on [the technical forum].
## List of Duniter's reviewers
- @librelois
- @HugoTrentesaux
- @tuxmain
[commit naming conventions]: ./docs/dev/git-conventions.md#naming-commits
[Developer documentation]: ./docs/dev/index.md
[Developer documentation]: ./docs/dev/
[project's git conventions]: ./docs/dev/git-conventions.md
[Setting up your development environment]: ./docs/setup.md
[Setting up your development environment]: ./docs/dev/setup.md
[the technical forum]: https://forum.duniter.org
This diff is collapsed.
This diff is collapsed.
# Duniter v2s
A rewriting of duniter based on [Substrate](https://www.substrate.io/) framework.
duniter-v2s is under active development, only a test network called "ĞDev" is deployed.
🆙 A rewriting of [Duniter v1](https://duniter.org) in the [Substrate](https://www.substrate.io/) framework.
⚠️ Duniter-v2s is under active development.
🚧 A test network called "ĞDev" is deployed, allowing to test wallets and indexers.
<div align="center">
<img alt="logov2" src="https://duniter.fr/img/duniterv2.svg" width="128" height="128"/>
</div>
## Documentation
Multiple documentation sources are available depending on the level of detail you need.
- Full technical Rust doc (auto-generated with `cargo xtask gen-doc`) : https://doc-duniter-org.ipns.pagu.re/duniter/
- User and client developer doc (official website) : https://duniter.org/wiki/duniter-v2/
- Internal documentation (within git repository), see table of contents below : [./doc](./doc)
### Internal documentation TOC
- [README](./README.md) (this file)
- [Use](#use)
- [Contribute](#contribute)
- [License](#license)
- [docs](./docs/) internal documentation
- [api](./docs/api/) API
- [manual](./docs/api/manual.md) manage account and identities
- [runtime-calls](./docs/api/runtime-calls.md) the calls you can submit through the RPC API
- [runtime-errors](./docs/api/runtime-errors.md) the errors you can get submitting a call
- [runtime-events](./docs/api/runtime-events.md) the events you can get submitting a call
- [dev](./docs/dev/) developer documentation
- [beginner-walkthrough](./docs/dev/beginner-walkthrough.md)
- [git-conventions](./docs/dev/git-conventions.md)
- [pallet_conventions](./docs/dev/pallet_conventions.md)
- [launch-a-live-network](./docs/dev/launch-a-live-network.md)
- [setup](./docs/dev/setup.md)
- [compilation features](./docs/dev/compilation.md)
- [verify-runtime-code](./docs/dev/verify-runtime-code.md)
- [weights-benchmarking](./docs/dev/weights-benchmarking.md)
- [upgrade-substrate](./docs/dev/upgrade-substrate.md)
- [replay-block](./docs/test/replay-block.md)
- [user](./docs/user/) user documentation
- [autocompletion](./docs/user/autocompletion.md)
- [debian installation](./docs/user/installation_debian.md)
- [distance](./docs/user/distance.md)
- [fees](./docs/user/fees.md)
- [packaging](./docs/packaging/) packaging
- [build-for-arm](./docs/packaging/build-for-arm.md) build for ARM architecture
- [build-debian](./docs/packaging/build-deb.md) build a native Debian package
- [docker](./docker/) docker-related documentation
- [end2end-tests](./end2end-tests/) automated end to end tests written with cucumber
- [live-tests](./live-tests/) sanity checks to test the storage of a live chain
## Use
......@@ -10,65 +59,41 @@ duniter-v2s is under active development, only a test network called "ĞDev" is d
The easiest way is to use the docker image.
Minimal command to deploy a **temporary** mirror peer:
Minimal command to deploy a temporary mirror peer:
```docker
docker run -it -p9944:9944 -e DUNITER_CHAIN_NAME=gdev duniter/duniter-v2s:v0.1.0 --tmp --execution=Wasm
docker run -it -p9944:9944 -e DUNITER_CHAIN_NAME=gdev duniter/duniter-v2s-gdev-800:latest
```
To go further, read [How to deploy a permanent mirror node on ĞDev network](./docs/user/mirror.md).
To go further, read [How to deploy a permanent mirror node on ĞDev network 🔗](https://duniter.org/wiki/duniter-v2/#run-a-mirror-node).
### Create your local blockchain
It can be useful to deploy your local blockchain, for instance to have a controled environement
to develop/test an application that interact with the blockchain.
It can be useful to deploy your local blockchain, for instance to have a controlled environment to develop/test an application that interacts with the blockchain.
```docker
docker run -it -p9944:9944 duniter/duniter-v2s:v0.1.0 --tmp
docker run -it -p9944:9944 duniter/duniter-v2s-gdev-800:latest
```
Or use the `docker-compose.yml` at the root of this repository.
Or use the [`docker-compose.yml`](./docker-compose.yml) at the root of this repository.
#### Control when your local blockchain should produce blocks
By default, your local blockchain produce a new block every 6 seconds, which is not practical in some cases.
You can decide when to produce blocks with the cli option `--sealing`, , there are 2 possible modes:
* `--sealing=instant`: produce a block immediately upon receiving a transaction into the transaction pool
* `--sealing=manual`: produce a block upon receiving an RPC request (method `engine_createBlock`).
### Autocompletion
By default, your local blockchain produces a new block every 6 seconds, which is not practical in some cases.
See [autocompletion](./docs/user/autocompletion.md).
You can decide when to produce blocks with the cli option `--sealing` which has two modes:
## Test
- `--sealing=instant`: produce a block immediately upon receiving a transaction into the transaction pool
- `--sealing=manual`: produce a block upon receiving an RPC request (method `engine_createBlock`).
### Test a specific commit
### Shell autocompletion
At each commit on master, an image with the tag `debug-sha-********` is published, where `********`
corresponds to the first 8 hash characters of the commit.
Usage:
```docker
docker run -it -p9944:9944 --name duniter-v2s duniter/duniter-v2s:debug-sha-b836f1a6
```
Then open `https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944` in a browser.
Enable detailed logging:
```docker
docker run -it -p9944:9944 --name duniter-v2s \
-e RUST_LOG=debug \
-e RUST_BACKTRACE=1 \
-lruntime=debug \
duniter/duniter-v2s:debug-sha-b836f1a6
```
See [autocompletion](./docs/user/autocompletion.md) to generate shell autocompletion for duniter commands.
## Contribute
If you are beginner in Rust and need a well guided tutorial, follow the [beginner walkthrough](./docs/dev/beginner-walkthrough.md).
Before any contribution, please read carefully the [CONTRIBUTING](./CONTRIBUTING.md) file and our [git conventions](./docs/dev/git-conventions.md).
### Setup your dev environment
......@@ -77,7 +102,7 @@ First, complete the [basic setup instructions](./docs/dev/setup.md).
### Build
NOTE: You must first follow the instructions in the [Setup] section (#setup).
NOTE: You must first follow the instructions in the [Setup](#setup-your-dev-environment) section.
Use the following command to build the node without launching it:
......@@ -90,20 +115,11 @@ cargo build
Use Rust's native `cargo` command to build and launch the node:
```sh
cargo run -- --dev --tmp
cargo run -- --dev
```
This will deploy a local blockchain with test accounts (Alice, Bob, etc) in the genesis.
## Single-Node Development Chain
This command will start the single-node development chain with persistent state:
```bash
./target/debug/duniter --dev --tmp
```
Then open `https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944` in a browser.
Open `https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944` to watch and interact with your node.
Start the development chain with detailed logging:
......@@ -111,134 +127,24 @@ Start the development chain with detailed logging:
RUST_LOG=debug RUST_BACKTRACE=1 ./target/debug/duniter -lruntime=debug --dev
```
## Multi-Node Local Testnet
If you want to see the multi-node consensus algorithm in action, refer to
[our Start a Private Network tutorial](https://substrate.dev/docs/en/tutorials/start-a-private-network/).
### Purge previous lacal testnet
## License
```
./target/debug/duniter purge-chain --base-path /tmp/alice --chain local
./target/debug/duniter purge-chain --base-path /tmp/bob --chain local
See [LICENSE](./LICENSE)
```
CopyLeft 2021-2023 Axiom-Team
### Start Alice's node
Some parts borrowed from Polkadot (Parity Technologies (UK) Ltd.)
```bash
./target/debug/duniter \
--base-path /tmp/alice \
--chain local \
--alice \
--port 30333 \
--ws-port 9945 \
--rpc-port 9933 \
--node-key 0000000000000000000000000000000000000000000000000000000000000001 \
--validator
```
Duniter-v2S is free software: you can redistribute it and/or modify
it under the terms of the **GNU Affero General Public License** as published by
the Free Software Foundation, **version 3** of the License.
### Start Bob's node
Duniter-v2S is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Affero General Public License for more details.
```bash
./target/debug/duniter \
--base-path /tmp/bob \
--chain local \
--bob \
--port 30334 \
--ws-port 9946 \
--rpc-port 9934 \
--validator \
--bootnodes /ip4/127.0.0.1/tcp/30333/p2p/12D3KooWEyoppNCUx8Yx66oV9fJnriXwCcXwDDUA2kj6vnc6iDEp
You should have received a copy of the GNU Affero General Public License
along with Duniter-v2S. If not, see <https://www.gnu.org/licenses/>.
```
## Project Structure
A Substrate project such as this consists of a number of components that are spread across a few
directories.
### 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://substrate.dev/docs/en/knowledgebase/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://substrate.dev/docs/en/knowledgebase/integrate/chain-spec) 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_chain_spec` 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://substrate.dev/docs/en/knowledgebase/integrate/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://substrate.dev/docs/en/knowledgebase/advanced/consensus#longest-chain-rule),
the [Babe](https://substrate.dev/docs/en/knowledgebase/advanced/consensus#babe) block authoring
mechanism and the
[GRANDPA](https://substrate.dev/docs/en/knowledgebase/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/debug/duniter --help
```
### Runtime
In Substrate, the terms
"[runtime](https://substrate.dev/docs/en/knowledgebase/getting-started/glossary#runtime)" and
"[state transition function](https://substrate.dev/docs/en/knowledgebase/getting-started/glossary#stf-state-transition-function)"
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://substrate.dev/docs/en/knowledgebase/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://substrate.dev/docs/en/knowledgebase/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://substrate.dev/docs/en/knowledgebase/runtime/frame#support-library)
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://substrate.dev/docs/en/knowledgebase/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](https://substrate.dev/docs/en/knowledgebase/runtime/events) 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.