mirror of
https://github.com/status-im/eth2.0-specs.git
synced 2025-02-13 19:16:27 +00:00
241e52a202
* Introduce consensus code for Whisk * polish, simplify, clean up (~100 fewer lines) @asn-d6: As discussed, I fixed a few bugs along the way but likely also introduced some bugs :) * minor cleanups and fixes * simplify is_k_commitment_unique * Update beacon-chain.md * Update beacon-chain.md * Initialize `k` in `get_validator_from_deposit()` * minor cleanups * Update beacon-chain.md * Create beacon-chain.md This PR changes the Whisk tracker format to be of the form `(r * pubkey, r * BLS_GT_GENERATOR)` instead of `(r * k * BLS_G1_GENERATOR, r * BLS_G1_GENERATOR)`. This allows for non-interactive tracker registrations from validator pubkeys, removing ~50 lines the code. It also significantly reduces the amount of state overhead. This PR also removes permutation commitments, though those can be easily readded if deemed necessary. * A couple of fixes to the no-registration simplification @asn-d6: Readded a consistency check for `IsValidWhiskOpeningProof` (involving `pubkey` instead of `k_commitment`). * remove unused helpers * use Mary's suggested tracker * Update beacon-chain.md * Revert G_t element optimization This needs its own ethresearch post, and some additional analysis to see if we can do the shuffle ZKP in the allowed timeframe. This reverts commit 8517acabfc1dbb1a35789e6170b5db0bb2c19c9a. * Implement new shuffling strategy Ditch the Feistel logic and instead have each shuffler pick the row they shuffle using their RANDAO reveal. * Curdleproofs edits * working whisk eth2spec * working whisk dummy test * add more boilerplate set up code * rebase constants * Implement even newer and simplified shuffling strategy This commit further simplifies 0faef30fc131d1b471b63a7f16772eeeef548ef8 by removing the entire squareshuffle. The latest version of https://eprint.iacr.org/2022/560 proposes that each shuffler picks random indices from the entire candidate set instead of organizing validators into a square. * Move to _features * remove dummy test * Run doctoc * Change Whisk's previous fork to Capella instead of Bellatrix. Make linter happier. * Fix lint * Fix pylint * Fix mypy issues * Clean-up get_beacon_proposer_index * Fix doc headers * Fix capella link * Update apply_deposit * Rename process_shuffled_trackers --------- Co-authored-by: George Kadianakis <desnacked@riseup.net> Co-authored-by: Justin <drakefjustin@gmail.com> Co-authored-by: Nalin Bhardwaj <nalinbhardwaj@nibnalin.me> Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
Ethereum Proof-of-Stake Consensus Specifications
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.
Specs
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 | Specs |
|---|---|---|---|
| 0 | Phase0 | 0 |
|
| 1 | Altair | 74240 |
|
| 2 | Bellatrix ("The Merge") |
144896 |
|
| 3 | Capella | 194048 |
In-development Specifications
| Code Name or Topic | Specs | Notes |
|---|---|---|
| Deneb (tentative) | ||
| Sharding (outdated) |
|
|
| Custody Game (outdated) |
|
Dependent on sharding |
| Data Availability Sampling (outdated) |
|
|
| EIP-6110 |
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 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/validateO(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:
Online viewer of the latest release (latest master branch)
Consensus spec tests
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.