Skip to content

ethereum/consensus-specs

Repository files navigation

Ethereum Proof-of-Stake Consensus Specifications

Join the chat at https://discord.gg/qGpsxSA testgen

This repository hosts the current Ethereum proof-of-stake specifications. Discussions about design rationale and proposed changes can be brought up and discussed as issues. Solidified, agreed-upon changes to the specifications can be made through pull requests.

Specifications

Core specifications for Ethereum proof-of-stake clients can be found in specs. These are divided into features. Features are researched and developed in parallel, and then consolidated into sequential upgrades when ready.

Stable Specifications

Seq. Code Name Fork Epoch Links
0 Phase0 0 Specs, Tests
1 Altair 74240 Specs, Tests
2 Bellatrix 144896 Specs, Tests
3 Capella 194048 Specs, Tests
4 Deneb 269568 Specs, Tests

In-development Specifications

Seq. Code Name Fork Epoch Links
5 Electra TBD Specs, Tests
6 Fulu TBD Specs, Tests

Accompanying documents

External specifications

Additional specifications and standards outside of requisite client functionality can be found in the following repositories:

Reference tests

Reference tests built from the executable Python spec are available in the Ethereum Proof-of-Stake Consensus Spec Tests repository. Compressed tarballs are available for each release here. Nightly reference tests are available here.

Contributors

Installation and usage

Clone the repository with:

git clone https://github.com/ethereum/consensus-specs.git

Switch to the directory:

cd consensus-specs

View the help output:

make help

Design goals

The following are the broad design goals for the Ethereum proof-of-stake consensus specifications:

  • Minimize complexity, even at the cost of some losses in efficiency.
  • Remain live through major network partitions and when very large portions of nodes go offline.
  • Select components that are quantum secure or easily swappable for quantum-secure alternatives.
  • Utilize crypto and design techniques that allow for a large participation of validators.
  • Minimize hardware requirements such that a consumer laptop can participate.

Useful resources