mirror of https://github.com/ethereum/consensus-specs.git synced 2026-02-02 16:05:00 -05:00

Go to file

Justin 1b0b2f21cc First pass cleanup of bls_verify.md

Misc cleanups:

* (typo) `highflag` => `highflag1`
* (typo) `lowflag = x = 0` => `lowflag == x == 0`
* Add structure and table of contents
* Describe more notation in words (e.g. `i`)
* Make sure flags are 1-bit
* Clarify and polish presentation

Example notation cleanups:

* `G1` => `id_G1` (to avoid confusing with the group G1)
* `field_modulus` => `q` (avoid using two names for same thing)
* `BLSVerify` => `bls_verify` (respect notation for functions in main document)
* `sig` => `signature` (avoid abbreviations as in main document)

TODO:

* Potentially describe `FQ2`, `b2`, `is_on_curve`, `multiply` in words
* Make the naming changes around `bls_verify` in the main document
* Fix any bugs introduced by the cleanup

2018-12-09 14:21:34 +00:00

specs

First pass cleanup of bls_verify.md

2018-12-09 14:21:34 +00:00

README.md

Update README.md (#176 )

2018-11-26 16:57:01 -06:00

README.md

Ethereum 2.0 Specifications

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:

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)