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
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
vbuterin
Justin
Hsiao-Wei Wang
Jacek Sieka
4000D
Terence Tsao
Danny Ryan
Ben Edgington