A library for interacting with ethereum consensus data.
This implementation has not been audited for security and is primarily intended for R&D use cases.
If you need a battle-tested implementation (e.g. for consensus-critical work), refer to the Lighthouse implementation.
The ethereum-consensus
crate exposes a series of modules implementing the ethereum consensus specs.
There are a number of top-level modules exposing a variety of supporting types, utilities, etc.
And then a module to drive any state transition in state_transition
.
Specialized logic for each fork can be found in the module with the same name as the fork, e.g. bellatrix
.
Each fork supports a compile-time "preset", with two common presets mainnet
and minimal
provided as a convenience.
These modules can be found under each fork module in the presets
module.
The generic types are exposed but most users will want to access each fork's logic via one of the presets. See Examples for further details.
An important thing to note is that the state_transition
module of each fork (after the phase0
fork) is generated
by a code-generation utility in the spec-gen
crate. This utility specializes each fork based on the prior
Rust module as an input. See the README for that binary to learn further details about operating this utility. The
generated files are checked in so you should not need to use this binary under
most circumstances.
Refer to the code in examples
for the suggested way to use this crate as a user. The intermediate types are laid out
so that you can define your own customizations but you can likely use the defaults.
These crates provide support for the "preset" concept found in the consensus-specs
. The minimal
and mainnet
presets are provided for each fork as hard-coded instances. If you need to support another type of preset, you can make your own using the generic types. Refer to an existing preset, like ethereum_consensus::bellatrix::presets::minimal
, for an example.
These crates also support several popular networks. This generally boils down to specific config, for example ethereum_consensus::configs::goerli::Config
.
To add support for a new network, you can:
- add a new module under
ethereum_consensus::configs
using an existing network as a template - add the network's
genesis_time
and support for aClock
for that network inethereum_consensus::clock
- there are convenience methods on
ethereum_consensus::state_transition::Context
for each network and these should also be updated for the new network
A client for the Ethereum beacon node APIs:
https://ethereum.github.io/beacon-APIs
Refer to the code in examples
for a demonstration on how to use the API client.
This crate generates spec code following the "fork diff" defined in each fork of http://github.com/ethereum/consensus-specs. It is not user-facing.