Ethereum 2.0 Specifications

Go to file

Justin 6c824ffee4 Remove placeholders Remove all custody and VDF placeholders (56 lines less!). A few notes on the placeholder fields and logic: * All placeholder fields were dummy fields that can easily be restored in the phase 1 hard fork. * One special case to the above is `custody_bit_0_validator_indices` in `SlashableVoteData` which was renamed to `validator_indices`. Renaming it back is not a spec change because SSZ field names are [no longer part of the spec](`a9328157a8 (diff-8d8fe480a35579c7be2f976d9b321216)`). * The placeholder logic was written using generalised functions (e.g. `bls_verify_multiple` vs `bls_verify`, and `indices(slashable_vote_data)` vs `slashable_vote_data.validator_indices`). This generality was unnecessary because it was not triggered when all custody bits were 0. This means we can simplify the logic without being inconsistent with phase 1. Rationale: * Keep phase 0 (likely far harder to deliver than phase 1) as clean as possible * Focus on upgrade paths and incremental releases * Custody is still under research—keep the design space open	2019-01-22 20:45:30 +00:00
specs	Remove placeholders	2019-01-22 20:45:30 +00:00
README.md	Fix link	2019-01-17 18:39:58 +01:00

Remove all custody and VDF placeholders (56 lines less!). A few notes on the placeholder fields and logic:

* All placeholder fields were dummy fields that can easily be restored in the phase 1 hard fork.
* One special case to the above is `custody_bit_0_validator_indices` in `SlashableVoteData` which was renamed to `validator_indices`. Renaming it back is *not* a spec change because SSZ field names are [no longer part of the spec](a9328157a8 (diff-8d8fe480a35579c7be2f976d9b321216)).
* The placeholder logic was written using generalised functions (e.g. `bls_verify_multiple` vs `bls_verify`, and `indices(slashable_vote_data)` vs `slashable_vote_data.validator_indices`). This generality was unnecessary because it was not triggered when all custody bits were 0. This means we can simplify the logic without being inconsistent with phase 1.

Rationale:

* Keep phase 0 (likely far harder to deliver than phase 1) as clean as possible
* Focus on upgrade paths and incremental releases
* Custody is still under research—keep the design space open

2019-01-22 20:45:30 +00:00

specs Remove placeholders 2019-01-22 20:45:30 +00:00

README.md Fix link 2019-01-17 18:39:58 +01:00

README.md

Ethereum 2.0 Specifications

To learn more about sharding and eth2.0/Serenity, see the sharding FAQ and the research compendium.

This repo hosts the current eth2.0 specifications. Discussions about design rationale and proposed changes can be brought up and discussed as issues. Solidified, agreed upon changes to spec can be made through pull requests.

Specs

Core specifications for eth2.0 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:

Accompanying documents can be found in specs and include

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)