change to block-root anchor of shard blob

specs/sharding/beacon-chain.md

@@ -38,7 +38,6 @@
     - [`compute_updated_gasprice`](#compute_updated_gasprice)
     - [`compute_committee_source_epoch`](#compute_committee_source_epoch)
   - [Beacon state accessors](#beacon-state-accessors)
-    - [`get_state_root_at_slot`](#get_state_root_at_slot)
     - [Updated `get_committee_count_per_slot`](#updated-get_committee_count_per_slot)
     - [`get_active_shard_count`](#get_active_shard_count)
     - [`get_shard_committee`](#get_shard_committee)
@@ -204,8 +203,8 @@ class ShardBlobBodySummary(Container):
     degree_proof: BLSCommitment
     # Hash-tree-root as summary of the data field
     data_root: Root
-    # State of the Beacon Chain, right before the slot processing of shard_blob.slot
-    parent_state_root: Root
+    # Latest block root of the Beacon Chain, before shard_blob.slot
+    beacon_block_root: Root
 ```
 
 ### `ShardBlobHeader`
@@ -324,17 +323,6 @@ def compute_committee_source_epoch(epoch: Epoch, period: uint64) -> Epoch:
 
 ### Beacon state accessors
 
-#### `get_state_root_at_slot`
-
-```python
-def get_state_root_at_slot(state: BeaconState, slot: Slot) -> Root:
-    """
-    Return the state root at a recent ``slot``.
-    """
-    assert slot < state.slot <= slot + SLOTS_PER_HISTORICAL_ROOT
-    return state.state_roots[slot % SLOTS_PER_HISTORICAL_ROOT]
-```
-
 #### Updated `get_committee_count_per_slot`
 
 ```python
@@ -569,9 +557,9 @@ def process_shard_header(state: BeaconState,
     assert header_epoch in [get_previous_epoch(state), get_current_epoch(state)]
     # Verify that the shard is active
     assert header.shard < get_active_shard_count(state, header_epoch)
-    # Verify that the state root matches,
-    # to ensure the header will only be included in this specific beacon-chain sub-tree.
-    assert header.parent_state_root == get_state_root_at_slot(state, header.slot-1)
+    # Verify that the block root matches,
+    # to ensure the header will only be included in this specific Beacon Chain sub-tree.
+    assert header.beacon_block_root == get_block_root_at_slot(state, header.slot - 1)
     # Verify proposer
     assert header.proposer_index == get_shard_proposer_index(state, header.slot, header.shard)
     # Verify signature

specs/sharding/p2p-interface.md

@@ -41,8 +41,8 @@ class ShardBlobBody(Container):
     degree_proof: BLSCommitment
     # The actual data. Should match the commitment and degree proof.
     data: List[BLSPoint, POINTS_PER_SAMPLE * MAX_SAMPLES_PER_BLOCK]
-    # State of the Beacon Chain, right before the slot processing of shard_blob.slot
-    parent_state_root: Root
+    # Latest block root of the Beacon Chain, before shard_blob.slot
+    beacon_block_root: Root
 ```
 
 The user MUST always verify the commitments in the `body` are valid for the `data` in the `body`.
@@ -99,7 +99,7 @@ The following validations MUST pass before forwarding the `signed_blob` (with in
 - _[REJECT]_ The `blob.body.data` MUST NOT contain any point `p >= MODULUS`. Although it is a `uint256`, not the full 256 bit range is valid.
 - _[REJECT]_ The proposer signature, `signed_blob.signature`, is valid with respect to the `proposer_index` pubkey.
 - _[REJECT]_ The blob is proposed by the expected `proposer_index` for the blob's slot
-  in the context of the current shuffling (defined by `blob.body.parent_state_root`/`slot`).
+  in the context of the current shuffling (defined by `blob.body.beacon_block_root`/`slot`).
   If the `proposer_index` cannot immediately be verified against the expected shuffling,
   the block MAY be queued for later processing while proposers for the blob's branch are calculated --
   in such a case _do not_ `REJECT`, instead `IGNORE` this message.
@@ -118,7 +118,7 @@ The following validations MUST pass before forwarding the `signed_shard_header`
 - _[IGNORE]_ The header is the first header with valid signature received for the `(header.proposer_index, header.slot, header.shard)` combination.
 - _[REJECT]_ The proposer signature, `signed_shard_header.signature`, is valid with respect to the `proposer_index` pubkey.
 - _[REJECT]_ The header is proposed by the expected `proposer_index` for the block's slot
-  in the context of the current shuffling (defined by `header.body_summary.parent_state_root`/`slot`).
+  in the context of the current shuffling (defined by `header.body_summary.beacon_block_root`/`slot`).
   If the `proposer_index` cannot immediately be verified against the expected shuffling,
   the block MAY be queued for later processing while proposers for the block's branch are calculated --
   in such a case _do not_ `REJECT`, instead `IGNORE` this message.