Question: What happens if the block proposer at the `POW_RECEIPT_ROOT_VOTING_PERIOD` boundary puts a bad receipt root? Does this give too much power to that block proposer?
* Separated out proposer from validators
* Update 0_beacon-chain.md
* Update specs/core/0_beacon-chain.md
Co-Authored-By: vbuterin <v@buterin.com>
* Update specs/core/0_beacon-chain.md
Co-Authored-By: vbuterin <v@buterin.com>
* get_proposer -> get_beacon_proposer, block -> slot
* Move proposer sig to the end of a block
* Update specs/core/0_beacon-chain.md
Co-Authored-By: vbuterin <v@buterin.com>
* sig -> signature
* add type hints for get_beacon_proposer
Also adjusted constants to keep interest rates and the quadratic leak period the same.
Also, did some simplifications of the cycle calculation procedure. Make the decision to remove automatic registration of a validator as a proposer when they join, because that can just happen on its own due to the reshuffling procedure.
Moves the procedure for handling specials into the per-block processing loop. Cleans up the specification for handling them to be more unambiguous, and changes the formats to be more readable and simpler to implement.
* 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
Justin
vbuterin
Hsiao-Wei Wang
4000D
Terence Tsao
Danny Ryan
Ben Edgington