Apply suggestions from code review

Co-authored-by: Danny Ryan <dannyjryan@gmail.com>
Co-authored-by: Jimmy Chen <jchen.tc@gmail.com>
This commit is contained in:
Jacek Sieka 2023-02-16 08:18:52 +01:00 committed by GitHub
parent f0dc126602
commit c39fda19c6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 8 additions and 7 deletions

View File

@ -24,7 +24,7 @@ This is the modification of the fork choice accompanying the Deneb upgrade.
## Helpers
#### `validate_blob_sidecars`
#### `validate_blobs`
```python
def validate_blobs(expected_kzg_commitments: Sequence[KZGCommitment],
@ -47,7 +47,8 @@ The block MUST NOT be considered valid until all valid `Blob`s have been downloa
```python
def is_data_available(beacon_block_root: Root, blob_kzg_commitments: Sequence[KZGCommitment]) -> bool:
# `retrieve_blobs_and_proofs` is implementation and context dependent, raises an exception if not available. It returns all the blobs for the given block root.
# `retrieve_blobs_and_proofs` is implementation and context dependent
# It returns all the blobs for the given block root, and raises an exception if not available
# Note: the p2p network does not guarantee sidecar retrieval outside of `MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS`
blobs, proofs = retrieve_blobs_and_proofs(beacon_block_root)

View File

@ -228,7 +228,7 @@ Requests blob sidecars in the slot range `[start_slot, start_slot + count)`, lea
The response is unsigned, i.e. `BlobSidecarsByRange`, as the signature of the beacon block proposer 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`.
Before consuming the next response chunk, the response reader SHOULD verify the blob sidecar is well-formatted and correct w.r.t. the expected KZG commitments through `validate_blobs`.
`BlobSidecarsByRange` 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.
@ -255,11 +255,11 @@ to be fully compliant with `BlobsSidecarsByRange` requests.
participating in the networking immediately, other peers MAY
disconnect and/or temporarily ban such an un-synced or semi-synced client.
Clients MUST respond with at least the first blobs sidecar that exists in the range, if they have it, and no more than `MAX_REQUEST_BLOB_SIDECARS * MAX_BLOBS_PER_BLOCK` sidecars.
Clients MUST respond with at least the first blob sidecar that exists in the range, if they have it, and no more than `MAX_REQUEST_BLOB_SIDECARS * MAX_BLOBS_PER_BLOCK` sidecars.
The following blobs sidecars, where they exist, MUST be sent in consecutive `(slot, index)` order.
The following blob sidecars, where they exist, MUST be sent in consecutive `(slot, index)` order.
Clients MAY limit the number of blobs sidecars in the response.
Clients MAY limit the number of blob sidecars in the response.
The response MUST contain no more than `count * MAX_BLOBS_PER_BLOCK` blob sidecars.

View File

@ -104,7 +104,7 @@ def get_blob_sidecars(block: BeaconBlock, blobs: Sequence[Blob]) -> Sequence[Blo
```
Then `signed_sidecar = SignedBlobSidecar(message=sidecar, signature=signature)` is constructed and published to the `blob_sidecar_{index}` topics according to its index.
Then for each sidecar, `signed_sidecar = SignedBlobSidecar(message=sidecar, signature=signature)` is constructed and published to the `blob_sidecar_{index}` topics according to its index.
`signature` is obtained from: