* Proof of custody game, take 2
Unfortunately not simpler than before, but moves challenges outside of the validator records and so keeps validator records constant-size.
* Removed unneeded challenge codes
* Formatting fixes
* Updated phase 1: branch challenges
* Removed unnecessary line
* Added early subkey reveal slashing
* Revealing during the active period is still revealing early
* Added....
* Machinery for publishing old subkeys
* Inability to withdraw until you published all subkeys
* After a validator exits the queue there's still a minimum 1-day delay before they can withdraw (in the future this delay will be used as an opportunity to start a PoC challenge game)
* Update 1_shard-data-chains.md
* formatting
* minor edits
* Added masking scheme for reveals
Secure under the aggregate extraction infeasibility assumption described on pages 11-12 of https://crypto.stanford.edu/~dabo/pubs/papers/aggreg.pdf
* Added rewards going to challengers
* Add ToC and reorg the constant tables
* Remove tags
* fix constant formatting
* normalize domain constants in phase 1
* Update 1_shard-data-chains.md
* Update 1_shard-data-chains.md
* Update 1_shard-data-chains.md
* Added transition logic
* Fix ToC
* Fix ToC
* Adjusted for #615
* Added more helpers
* epoch -> slot
* fix some type hints
* clean up `get_attestation_merkle_depth`
1. Use `+` to concatenate the merkle roots in `hash` function.
2. Fix `pad_to_power_of_2`: padding with `[b'\x00' * SHARD_BLOCK_SIZE]`,
not `[SHARD_BLOCK_SIZE]`.
Adds the crosslink committee to the fork choice rule. This is useful because it means that even if a proposal committee is byzantine and attempts to prevent a crosslink via a "balance attack" (alternating between chain A and chain B being the canonical chain), the crosslink committee can force the equilibrium to flip to one side or the other.
* Add shard blocks, shard data roots and how data is computed into crosslinks
Includes:
* Shard block structure
* Shard block header verification rule
* Shard block fork choice rule
* Shard block body verification rule
* Crosslink verification rule
Possible simplification: require `calc_block_maxbytes` to always output an exact power of two; if we desire the average maxbytes to be smooth, we can simply make it a pseudorandom chose between powers. This reduces some of the padding complexity.
* create separate files for phases (#125)
* create separate files for phases
* fix links
* add shard block pre processing conditions
* cleanup
* remove 'essentially'
* Updated handling for beacon chain skipping slots.
* Handle missing slots more
* modify attestation validity rule for crosslink hash
Hsiao-Wei Wang
Danny Ryan
vbuterin
terence tsao
chainsafe
Chih Cheng Liang