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.

Building From Source

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

Building with Nix

# 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"

Running a Collator Node

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.

Versioning

Historical Versioning (Up to v5.44.0)

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.

New Versioning Approach (From v5.45.0)

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 by runtime-1100, which will be followed by runtime-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 have runtime-1000 and need to release a fix, the new release version will be runtime-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.

Workspace Dependency Handling

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

1. Check if the dependency is already defined in the root Cargo.toml
   1. if yes, nothing to do, just take note of the enabled features
   2. if no, add it (make sure to use default-features = false if dependency is used in no_std context)
2. Add new_dependecy = { workspace = true } to the required crate
3. In case dependency is defined with default-features = false but you need it in std context, add features = ["std"] to the required crate.

Further Reading

• Official Documentation
• Whitepaper
• Whitepaper(JP)
• Substrate Developer Hub
• Substrate Glossary
• Substrate Client Library Documentation
• Astar Network Audit Reports
• Astar Code Documentation