A library for interacting with ethereum consensus objects.

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 this crate called gen-spec. 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:

1. add a new module under ethereum_consensus::configs using an existing network as a template
2. add the network's genesis_time and support for a Clock for that network in ethereum_consensus::clock
3. 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 test following https://github.com/ethereum/consensus-spec-tests. It is not user-facing.

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.