status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

clarify how to handle unavailable data outside of the prune window

This commit is contained in:
djrtwo 2022-12-19 10:15:18 -07:00
parent 302f54bfca
commit 4be8f7d669
2 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
specs/eip4844/beacon-chain.md
View File

@ -164,15 +164,16 @@ def validate_blobs_sidecar(slot: Slot,
#### `is_data_available`
The implementation of `is_data_available` is meant to change with later sharding upgrades.
The implementation of `is_data_available` will become more sophisticated during later sharding upgrades.
Initially, it requires every verifying actor to retrieve the matching `BlobsSidecar`,
and validate the sidecar with `validate_blobs_sidecar`.
The block MUST NOT be considered valid until a valid `BlobsSidecar` has been downloaded.
The block MUST NOT be considered valid until a valid `BlobsSidecar` has been downloaded. Blocks that have been previously validated as available SHOULD be considered available even if the associated `BlobsSidecar` has subsequently been pruned.
```python
def is_data_available(slot: Slot, beacon_block_root: Root, blob_kzg_commitments: Sequence[KZGCommitment]) -> bool:
# `retrieve_blobs_sidecar` is implementation dependent, raises an exception if not available.
# `retrieve_blobs_sidecar` is implementation and context dependent, raises an exception if not available.
# Note: the p2p network does not guarantee sidecar retrieval outside of `MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS`
sidecar = retrieve_blobs_sidecar(slot, beacon_block_root)
# For testing, `retrieve_blobs_sidecar` returns "TEST".

2
specs/eip4844/p2p-interface.md
View File

@ -219,7 +219,7 @@ may not be available beyond the initial distribution via gossip.
Before consuming the next response chunk, the response reader SHOULD verify the blobs sidecar is well-formatted and
correct w.r.t. the expected KZG commitments through `validate_blobs_sidecar`.
`BlobsSidecarsByRange` is primarily used to sync blobs that may have been missed on gossip.
`BlobsSidecarsByRange` is primarily used to sync blobs that may have been missed on gossip and to sync within the `MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS` window.
The request MUST be encoded as an SSZ-container.