Use `ShardBlock` in `shard_state_transition`
PR feedback
1. Rename `ShardState.data` -> `ShardState.transition_digest`
2. Rename `compute_shard_transition_data` to `compute_shard_transition_digest`
3. Add `assert state.slot > PHASE_1_GENESIS_SLOT` just in case, may move it later
Add `get_post_shard_state` as a pure function wrapper
PR feedback from Danny and some refactor
1. Add stub `PHASE_1_GENESIS_SLOT`
2. Rename `get_updated_gasprice` to `compute_updated_gasprice`
3. Rename `compute_shard_data_roots` to `compute_shard_body_roots`
Apply shard transition for the skipped slots
Refactor `shard_state_transition`
Get `beacon_parent_root` from offset slot
Add more test
Add `verify_shard_block_message`
Add `> 0`
Keep `beacon_parent_block` unchanged in `is_valid_fraud_proof`
Remove some lines
Fix type
Refactor + simplify skipped slot processing
Only store a 32 byte root for every shard block
Rationale: originally, I added shard block chunking (store 4 chunks for every shard block instead of one root) to facilitate construction of data availability roots. However, it turns out that there is an easier technique. Set the width of the data availability rectangle's rows to be 1/4 the max size of a shard block, so each block would fill multiple rows. Then, non-full blocks will generally create lots of zero rows. For example if the block bodies are `31415926535` and `897932` with a max size of 24 bytes, the rows might look like this:
```
31415926
53500000
00000000
89793200
00000000
00000000
```
Zero rows would extend rightward to complete zero rows, and when extending downward we can count the number of zero rows, and reduce the number of extra rows that we make, so we only make a new row for every nonzero row in the original data. This way we get only a close-to-optimal ~4-5x blowup in the data even if the data has zero rows in the middle.
Hsiao-Wei Wang
protolambda
Dankrad Feist
Danny Ryan
vbuterin