Astar Network is an interoperable blockchain based the Substrate framework and the hub for dApps within the Polkadot Ecosystem. With Astar Network and Shiden Network, people can stake their tokens to a Smart Contract for rewarding projects that provide value to the network.
For contributing to this project, please read our Contribution Guideline.
This section assumes that the developer is running on either macOS or Debian-variant operating system. For Windows, although there are ways to run it, we recommend using WSL or from a virtual machine for stability.
Execute the following command from your terminal to set up the development environment and build the node runtime.
# install Substrate development environment via the automatic script
$ curl https://getsubstrate.io -sSf | bash -s -- --fast
# clone the Git repository
$ git clone --recurse-submodules https://github.com/AstarNetwork/Astar.git
# change current working directory
$ cd Astar
# compile the node
# note: you may encounter some errors if `wasm32-unknown-unknown` is not installed, or if the toolchain channel is outdated
$ cargo build --profile production
# show list of available commands
$ ./target/production/astar-collator --help
# install Nix package manager:
$ curl https://nixos.org/nix/install | sh
# run from root of the project folder (`Astar/` folder)
$ nix-shell -I nixpkgs=channel:nixos-21.05 third-party/nix/shell.nix --run "cargo build --release"
To set up a collator node, you must have a fully synced node with the proper arguments, which can be done with the following command.
# start the Shiden collator node with
$ ./target/release/astar-collator \
--base-path <path to save blocks> \
--name <node display name> \
--port 30333 \
--rpc-port 9944 \
--telemetry-url 'wss://telemetry.polkadot.io/submit/ 0' \
--rpc-cors all \
--collator
Now, you can obtain the node's session key by sending the following RPC payload.
# send `rotate_keys` request
$ curl -H 'Content-Type: application/json' --data '{ "jsonrpc":"2.0", "method":"author_rotateKeys", "id":1 }' localhost:9933
# should return a long string of hex, which is your session key
{"jsonrpc":"2.0","result":"<session key in hex>","id":1}
After this step, you should have a validator node online with a session key for your node. For key management and validator rewards, consult our validator guide online.
Up to the release v5.44.0
, Astar releases contained both the client & the runtime blobs.
In general, each release contained both, with some specific releases (related to fixes) which only released e.g. client or runtime.
Standard semantic versioning approach was used.
Starting with v5.45.0, the release process has been split into separate client and runtime releases, each following distinct versioning schemes:
The client release will continue to follow semantic versioning, continuing where the former approach left off.
E.g. the next expected minor release will be v5.45.0
.
The runtime release will follow a new versioning approach - runtime-XXYY
.
- The
XX
part will be a number of 2 or more digits, starting with 10, and will be incremented by 1 each time a new runtime release is made. E.g.runtime-1000
will be followed byruntime-1100
, which will be followed byruntime-1200
, and so on. This is like a combination of major and minor semver versions. - The
YY
part will always be a 2 digit number, and serves as a patch semver version. E.g. if we haveruntime-1000
and need to release a fix, the new release version will beruntime-1001
.
The runtime crate version will align its major and minor versions with the Rust crate version, while the patch version will always remain 00
. For example, a runtime release for runtime-1100
corresponds to the Rust runtime crate version 11.0.0
. A minor runtime release such as runtime-1101
corresponds to the Rust runtime crate version 11.1.0
.
All dependencies should be listed inside the workspace's root Cargo.toml
file.
This allows us to easily change version of a crate used by the entire repo by modifying the version in a single place.
Right now, if non_std is required, default-features = false
must be set in the root Cargo.toml
file (related to this issue). Otherwise, it will have no effect, causing your compilation to fail.
Also package
imports aren't properly propagated from root to sub-crates, so defining those should be avoided.
Defining features in the root Cargo.toml
is additive with the features defined in concrete crate's Cargo.toml
.
Adding Dependency
- Check if the dependency is already defined in the root
Cargo.toml
- if yes, nothing to do, just take note of the enabled features
- if no, add it (make sure to use
default-features = false
if dependency is used in no_std context)
- Add
new_dependecy = { workspace = true }
to the required crate - In case dependency is defined with
default-features = false
but you need it in std context, addfeatures = ["std"]
to the required crate.