To learn more about proof-of-stake and sharding, see the PoS documentation, sharding documentation and the research compendium.

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 spec can be made through pull requests.

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.

• SimpleSerialize (SSZ) spec
• Merkle proof formats
• General test format

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

• Beacon APIs
• Engine APIs
• Beacon Metrics

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

• to minimize complexity, even at the cost of some losses in efficiency
• to remain live through major network partitions and when very large portions of nodes go offline
• to select all components such that they are either quantum secure or can be easily swapped out for quantum secure counterparts when available
• to utilize crypto and design techniques that allow for a large participation of validators in total and per unit time
• to allow for a typical consumer laptop with O(C) resources to process/validate O(1) shards (including any system level validation such as the beacon chain)

• Design Rationale
• Phase 0 Onboarding Document
• Combining GHOST and Casper paper

Documentation on the different components used during spec writing can be found here:

• YAML Test Generators
• Executable Python Spec, with Py-tests

Ethereum Consensus Specs

Conformance tests built from the executable python spec are available in the Ethereum Proof-of-Stake Consensus Spec Tests repo. Compressed tarballs are available in releases.