Skip to content
Ethereum 2.0 Specifications
Python Makefile
Branch: dev
Clone or download
hwwhww Merge pull request #1461 from terencechain/patch-89
Update slot to hour numbers
Latest commit 40cb72e Nov 1, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.circleci make sure new config loader change is working Jul 26, 2019
configs
deposit_contract Deposit contract fixes (#1362) Sep 3, 2019
scripts lint Oct 23, 2019
specs
test_generators [reopen] Eth2 shorthand standardized (#1452) Oct 28, 2019
test_libs fix ruemel.yaml dependency issue Oct 28, 2019
.codespell-whitelist
.gitignore
LICENSE CC0 1.0 Universal for repo Mar 12, 2019
Makefile Merge branch 'dev' into vbuterin-patch-13 Aug 23, 2019
README.md [reopen] Eth2 shorthand standardized (#1452) Oct 28, 2019

README.md

Ethereum 2.0 Specifications

Join the chat at https://discord.gg/hpFs23p Join the chat at https://gitter.im/ethereum/sharding

To learn more about sharding and Ethereum 2.0 (Serenity), see the sharding FAQ and the research compendium.

This repository hosts the current Eth2 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.

Specs

Core specifications for Eth2 client validation can be found in specs/core. These are divided into phases. Each subsequent phase depends upon the prior. The current phases specified are:

Phase 0

Phase 1

Phase 2

Phase 2 is still actively in R&D and does not yet have any formal specifications.

See the Eth2 Phase 2 Wiki for current progress, discussions, and definitions regarding this work.

Accompanying documents can be found in specs and include:

Additional specifications for client implementers

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

Design goals

The following are the broad design goals for Ethereum 2.0:

  • 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)

Useful external resources

For spec contributors

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

You can’t perform that action at this time.