See also #818.
===
* Replace custody challenge game with JABS
Replace the existing proof of custody game with a new game ("Justin's Awesome Bit Sum" or JABS) that works as follows:
* The data `D` is split up into 512-byte chunks `D[0] .... D[n-1]`, and use a mix function `mix(subkey, data) -> {0,1}` (currently the first bit of the hash of `subkey+data`). We calculate `M[i] = (mix(D[0]) + ... + mix(D[i-1])) % 2`, and set the custody bit to `M[n-1]`
* Anyone can challenge by providing the full `M` where `M[n-1]` is not equal to the custody bit
* Anyone can respond to a challenge by providing a specific position in `M` along with a branch of the data where `M[i-1] ^ mix(D[i]) != M[i]`
The maximum size of data is now `2**6` epochs * `2**6` blocks * `2**14` bytes = `2**26` bytes, so assuming 512-byte mix chunks the maximum mix size is `2**17` bits or `2**14` bytes. The average mix size is `2**8` bytes.
* Persistent committee size per slot target 128 max 256
Cuts down the cost of verifying a shard chain and aggregating signatures for a shard chain, and also makes the shard chain signatures more usable by light clients for verification as they would only need to keep track of a max 256-sized committee.
* 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
Danny Ryan
Dankrad Feist
Justin Drake
JSON
Alex Stokes
Chih Cheng Liang
vbuterin
NIC Lin
Hsiao-Wei Wang
terence tsao
chainsafe