concordium-node

• 

• 

This repository contains the implementation of the concordium p2p node with its dependencies and auxiliaries. The node is split into two parts

• concordium-consensus is a Haskell package that contains the implementation of the consensus with its dependencies. This includes basic consensus, finalization, scheduler, implementations of block and tree storage, and auxiliaries.
• concordium-node is a Rust package containing a number of executables, the chief among them being concordium-node.rs which is the program that participates in the Concordium network and runs consensus, finalization, and other components. It uses concordium-consensus as a package, either linked dynamically or statically, depending on the build configuration. The main feature added by the concordium-node is the network layer.

The auxiliary packages are the

• collector The collector is a service that queries the node for some information and publishes data to the collector-backend. The collector runs alongside the node.
• collector-backend The collector backend listens for data from the collectors and serves a summary of it. This component is used by the concordium-network-dashboard to display the network overview.
• macos_logger_wrapper provides an interface to the macOS logging interface using os_log_create. This is used by both the node and the collector so that the mac distribution package logs to the system logging service.

Submodules

The concordium-base is a a direct dependency of both concordium-consensus/ and concordium-node. Because concordium-base is also used by other components it is a separate repository brought in as a submodule.

The concordium-grpc-api is a simple repository that defines the external GRPC API of the node. This is in term of the .proto file. Because this is used by other components it is also a small separate repository brought in as a submodule.

Do remember to clone recursively or use git submodule update --init --recursive after cloning this repository, or after changing branches.

Configurations and scripts

• The jenkinsfiles directory contains Jenkins configurations for deployment and testing.
• The scripts directory contains a variety of bash scripts, Dockerfiles, and similar, to build different configurations of the node for testing and deployment.

Building the node

See concordium-node/README.md.

Contributing

To contribute start a new branch starting from main, make changes, and make a merge request. A person familiar with the codebase should be asked to review the changes before they are merged.

Haskell workflow

We typically use stack to build, run, and test the code. In order to build the haskell libraries the rust dependencies must be pre-build, which is done automatically by the cabal setup script.

Code should be formatted using fourmolu version 0.13.1.0 and using the config fourmolu.yaml found in the project root. The CI is setup to ensure the code follows this style.

To check the formatting locally run the following command from the project root:

On unix-like systems:

$ fourmolu --mode check $(git ls-files '*.hs')

To format run the following command from the project root:

On unix-like systems:

$ fourmolu --mode inplace $(git ls-files '*.hs')

Lines should strive to be at most 100 characters, naming and code style should follow the scheme that already exists.

We do not use any linting tool on the CI. Running hlint might uncover common issues.

Rust workflow

We use stable version of rust, 1.73, to compile the code.

The CI is configured to check two things

• the clippy tool is run to check for common mistakes and issues. We try to have no clippy warnings. Sometimes what clippy thinks is not reasonable is necessary, in which case you should explicitly disable the warning on that site (a function or module), such as #[allow(clippy::too_many_arguments)], but that is a method of last resort. Try to resolve the issue in a different way first.

• the rust fmt tool is run to check the formatting. Unfortunately the stable version of the tool is quite outdated, so we use a nightly version, which is updated a few times a year. Thus in order for the CI to pass you will need to install the relevant nightly version, see the rustfmt job in the file .github/workflows/build-test.yaml, look for nightly-...).