dv8silencer / chaind

chaind

chaind is a process that reads information from an Ethereum 2 beacon node and stores it in a database for reporting and analysis.

Table of Contents

• Install
  • Binaries
  • Docker
  • Source
• Usage
• Maintainers
• Contribute
• License

Install

Binaries

Binaries for the latest version of chaind can be obtained from the releases page.

Docker

You can obtain the latest version of chaind using docker with:

docker pull wealdtech/chaind

Source

chaind is a standard Go binary which can be installed with:

go get github.com/wealdtech/chaind

Usage

Data gathers four pieces of information from the beacon node, broken down by the modules that obtain the information:

• Proposer duties The proposer duties module provides information on the validator expected to propose a beacon block at a given slot.
• Beacon committees The beacon committees module provides information on the validators expected to attest to a beacon block at a given slot;
• Validators The validators module provides information on the current statue of validators. It can also obtain information on the validators' balances and effective balances at a given epoch; and
• Blocks The blocks module provides information on blocks proposed for each slot. This includes:
  • the block structure
  • attestations
  • proposer slashings
  • attester slashings
  • voluntary exits

Requirements to run chaind

Database

At current the only supported backend is PostgreSQL. Once you have a PostgreSQL instance you will need to create a user and database that chaind can use, for example run the following commands as the PostgreSQL superuser (postgres on most linux installations):

# This command creates a user named 'chain' and will prompt for a password.
createuser chain -P
# This command creates a database named 'chain' owned by the 'chain' user.
createdb -E UTF8 --owner=chain chain
# This sets up the database schema
psql -h localhost -U chain chain <schema.sql

Beacon node

chaind supports Lighthouse, Prysm and Teku beacon nodes. Note that not all beacon nodes support all calls at current. For best support, run a Teku node synced from genesis with the data-storage-mode set to archive (see the Teku documentation for more details on how to set this value).

Configuring chaind

The minimal requirements for chaind are references to the database and beacon node, for example:

chaind --chaindb.url=postgres://chain:secret@localhost:5432 --eth2client.address=localhost:5051

Here, chaindb.url is the URL of a local PostgreSQL database with pasword 'secret' and 'eth2client.address' is the address of a supported beacon client node (gRPC for Prysm, HTTP for Teku and Lighthouse).

chaind allows additional configuration for itself and its modules. It takes configuration from the command line, environment variables or a configuration file, but for the purposes of explaining the configuration options the configuration file is used. This should be in the home directory and called .chaind.yml.

# log-level is the base log level of the process.
# 'info' should be a suitable log level, unless detailed information is
# reqiured in which case 'debug' or 'trace' can be used.
log-level: info
# log-file specifies that log output should go to a file.  If this is not
# present log output will be to stderr.
log-file: /var/log/chaind.log
chaindb:
  # url is the URL of the PostgreSQL database.
  url: postgres://chain:secret@localhost:5432
# eth2client contains configuration for the Ethereum 2 client.
eth2client:
  # log-level is the log level of the specific module.
  log-level: debug
  # address is the address of the beacon node.
  address: localhost:5051
# blocks contains configuration for obtaining block-related information.
blocks:
  # enable states if this module will be operational.
  enable: true
  # address is a separate connection for this module.  If not present then
  # chaind will use the eth2client connection.
  address: localhost:5051
# validators contains configuration for obtaining validator-related information.
validators:
  enable: true
  # balances contains configuration for obtaining validator balances.  This is
  # a separate configuration flag for two reasons.  First, it can take a long
  # time to retrieve this information.  Second, the information can be
  # derived from the data obtained by the other modules.
  balances:
    enable: false
# beacon-committees contains configuration for obtaining beacon committee-related
# information.
beacon-committees:
  enable: true
# proposer-duties contains configuration for obtaining proposer duty-related
# information.
proposer-duties:
  enable: true

Maintainers

Jim McDonald: @mcdee.

Contribute

Contributions welcome. Please check out the issues.

License

Apache-2.0 © 2020 Weald Technology Trading.