* 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>
* Add docs
* update link to template
* Add more info
* Try mkdocs
* Create docs.yml
* Update docs.yml
* update
* update
* update
* Try mkdocs
* Add "B: Make it executable for pytest and test generator" section
* Use mkdocs-material
* Use `mkdocs-awesome-pages-plugin` to create custom specs order
* Add toc permalink
* Update site_url
* Add .pages files for navigations. Update highlight style
* Dark theme
* Fix list indent
While the light client sync protocol currently provides access to the
latest `BeaconBlockHeader`, obtaining the matching execution data needs
workarounds such as downloading the full block.
Having ready access to the EL state root simplifies use cases that need
a way to cross-check `eth_getProof` responses against LC data.
Access to `block_hash` unlocks scenarios where a CL light client drives
an EL without `engine_newPayload`. As of Altair, only the CL beacon
block root is available, but the EL block hash is needed for engine API.
Other fields in the `ExecutionPayloadHeader` such as `logs_bloom` may
allow light client applications to monitor blocks for local interest,
e.g. for transfers affecting a certain wallet. This enables to download
only the few relevant blocks instead of every single one.
A new `LightClientStore` is proposed into the Capella spec that may be
used to sync LC data that includes execution data. Existing pre-Capella
LC data will remain as is, but can be locally upgraded before feeding it
into the new `LightClientStore` so that light clients do not need to run
a potentially expensive fork transition at a specific time. This enables
the `LightClientStore` to be upgraded at a use case dependent timing at
any time before Capella hits. Smart contract and embedded deployments
benefit from reduced code size and do not need synchronization with the
beacon chain clock to perform the Capella fork.
- Implement all the required glue code to make things executable
- Implement a dummy KZG trusted setup
Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
Parithosh Jayanthi
Hsiao-Wei Wang
dapplion
Danny Ryan
dankrad
Paul Harris
Etan Kissling
Parithosh Jayanthi
George Kadianakis
Justin Traglia
protolambda
Alex Stokes