Skip to content

Files

Latest commit

967829f · Jan 14, 2025

History

History
This branch is 24 commits behind consensus-shipyard/ipc:main.

fendermint

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
Aug 26, 2024
Nov 27, 2024
Dec 17, 2024
Feb 26, 2024
Nov 15, 2024
Dec 20, 2024
Sep 24, 2024
Aug 26, 2024
Sep 24, 2024
Jan 14, 2025
Apr 17, 2024
Jan 14, 2025
Mar 4, 2024
Nov 22, 2024
Jun 10, 2024

Fendermint

Fendermint is an effort to implement IPC with Tendermint Core. There is a preliminary roadmap that lays out the tasks towards implementing subnets that run IPLD and FVM under the Filecoin rootnet, sharing components with the Lotus/Eudico based implementation.

Prerequisites

  • Install the basic requirements for IPC (see README)

Quick Start

Docs

Please have a look in the docs to see an overview of the project, how to run the components, and previous demos.

IPC

Fendermint is built with support for IPC by design. If you are looking to deploy the infrastructure Fendermint-based IPC subnet, refer to the IPC main repo, or have a look at the IPC infrastructure docs.

Testing

The following command runs unit and integration tests:

make test

while the next command builds docker images and runs an end-to-end test using the SimpleCoin and the ethers examples:

make e2e

IPC Solidity Actors

We generate Rust bindings for the Solidity actors we need to invoke from the contracts folder, some of which are deployed during the genesis process. The bindings live in contracts/binding/, and are generated automatically during the build, or with the following command:

make gen

To run it, you will have to install forge.

The list of contracts for which we generate Rust bindings are in build.rs and needs to be maintained by hand, for example if a new "diamond facet" is added to a contract, it has to be added here. Diamond facets also have to be added manually in ipc.rs where the contracts which need to be deployed during genesis are described. These facets cannot be divined from the ABI description, so they have to be maintained explicitly.

To test whether the genesis process works, we can run the following unit test:

cargo test --release -p fendermint_vm_interpreter load_genesis

Docker Build

The tests above build the images as a dependency, but you can build them any time with the following command:

make docker-build

See the docker docs for more details about the build.

Pre-built Docker Image

The CI build publishes a Docker image to Github Container Registry upon a successful build on the main branch. This is the same image as the one used in the End-to-End tests; it contains the built-in actor bundle and IPC Solidity actors, ready to be deployed during genesis.

The image can be pulled with the following command:

docker pull ghcr.io/consensus-shipyard/fendermint:latest

Configuration

The settings contains the configuration options for the fendermint application, for which the defaults are in the config directory. The options crate contains CLI parameters only; out of these only the run and the eth commands use the configuration settings.

fendermint can be configured using either a configuration file, or using environmnet variables.

Config files

The default configuration is in default.toml. This file is copied into the fendermint docker image and should not be edited, so that any further releases can provide any new keys with default values necessary for the application to start; instead the operator can provide further partial configuration files to override the defaults.

The Settings::config method expects the following files in a configuration directory:

  • default.toml with the settings for the keys that have meaningful default values
  • <mode>.toml is an optional file correponding to the --mode CLI option (by default dev); these are files that could be checked into Github e.g. to have values for production or test environments
  • local.toml is also optional with potential overrides specific to the developer's machine

An example of this override is the test.toml file which contains keys that do not have meaningful defaults, for the purpose of testing the parsing logic.

Config directory

The location of the configuration directory is determined by Options::config_dir in the following way: The optional --config-dir CLI parameter can be used to set it directly. If it's missing, the default is the config directory under the --home-dir CLI parameter, which by default is ~/.fendermint. The FM_CONFIG_DIR and FM_HOME_DIR env vars are also recognised.

The --config-dir can be used in combination with --home-dir and the pre-build docker image to:

  1. set --home-dir to a custom mounted volume where the data files can persist
  2. set --config-dir to /fendermint/config, which is where the runner.Dockerfile places the default.toml file
  3. mount any custom config files next to default.toml in the container

This way the default.toml that the image comes with is always active. Without setting --config-dir the operator would have to put it in the mounted --home-dir.

Alternatively individual paths for the relative directories inside the config can be mounted, e.g. /fendermint/data, /fendermint/snapshots, etc.

Environment Variables

Every setting in the config file can be overridden by an environment variable using the FM_ prefix and __ path separator.

For example if the TOML file has a setting such as this:

[abci]
[abci.listen]
host = "127.0.0.1

Then the corresponding environment variable would be FM_ABCI__LISTEN__HOST=0.0.0.0. Basically every . becomes __. If a field name contains _ that stays as it is, e.g. FM_RESOLVER__DISCOVERY__STATIC_ADDRESSES.