Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Document ForkDigest-context for EIP-4844 BlobSidecar in Electra #3850

Open
wants to merge 3 commits into
base: dev
Choose a base branch
from
+34 −19
Open

Document ForkDigest-context for EIP-4844 BlobSidecar in Electra #3850

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
95ddd15
Document `ForkDigest`-context for EIP-4844 `BlobSidecar` in Electra
etan-status Jul 22, 2024
dec28c1
Rename to `ForkDigestValue` for Gossipsub topics
etan-status Jul 24, 2024
c37a28d
Merge branch 'dev' into ef-blobp2p
etan-status Sep 19, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions specs/altair/light-client/p2p-interface.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -71,7 +71,7 @@ For light clients, the following validations MUST additionally pass before forwa

Light clients SHOULD call `process_light_client_finality_update` even if the message is ignored.

The gossip `ForkDigest`-context is determined based on `compute_fork_version(compute_epoch_at_slot(finality_update.attested_header.beacon.slot))`.
The gossip `ForkDigestValue` is determined based on `compute_fork_version(compute_epoch_at_slot(finality_update.attested_header.beacon.slot))`.

Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:

Expand Down Expand Up @@ -99,7 +99,7 @@ For light clients, the following validations MUST additionally pass before forwa

Light clients SHOULD call `process_light_client_optimistic_update` even if the message is ignored.

The gossip `ForkDigest`-context is determined based on `compute_fork_version(compute_epoch_at_slot(optimistic_update.attested_header.beacon.slot))`.
The gossip `ForkDigestValue` is determined based on `compute_fork_version(compute_epoch_at_slot(optimistic_update.attested_header.beacon.slot))`.

Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:

Expand Down
49 changes: 32 additions & 17 deletions specs/deneb/p2p-interface.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -187,6 +187,16 @@ The following validations MUST pass before forwarding the `blob_sidecar` on the
- _[REJECT]_ The sidecar is proposed by the expected `proposer_index` for the block's slot in the context of the current shuffling (defined by `block_header.parent_root`/`block_header.slot`).
If the `proposer_index` cannot immediately be verified against the expected shuffling, the sidecar 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.

The gossip `ForkDigestValue` is determined based on `compute_fork_version(compute_epoch_at_slot(blob_sidecar.signed_block_header.message.slot))`.

Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:

[0]: # (eth2spec: skip)

| `fork_version` | Chunk SSZ type |
|--------------------------------|-------------------------------|
| `DENEB_FORK_VERSION` and later | `deneb.BlobSidecar` |

##### Attestation subnets

###### `beacon_attestation_{subnet_id}`
Expand Down Expand Up @@ -241,7 +251,7 @@ No more than `MAX_REQUEST_BLOCKS_DENEB` may be requested at a time.

Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:

[1]: # (eth2spec: skip)
[0]: # (eth2spec: skip)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit curious when to use [0] and when to use [1] here. cc: @hwwhww


| `fork_version` | Chunk SSZ type |
|--------------------------|-------------------------------|
Expand All @@ -263,14 +273,6 @@ Clients SHOULD NOT respond with blocks that fail the beacon chain state transiti

*[New in Deneb:EIP4844]*

The `<context-bytes>` field is calculated as `context = compute_fork_digest(fork_version, genesis_validators_root)`:

[1]: # (eth2spec: skip)

| `fork_version` | Chunk SSZ type |
|--------------------------|-------------------------------|
| `DENEB_FORK_VERSION` | `deneb.BlobSidecar` |

Request Content:

```
Expand Down Expand Up @@ -309,19 +311,22 @@ Clients SHOULD include a sidecar in the response as soon as it passes the gossip
Clients SHOULD NOT respond with sidecars related to blocks that fail gossip validation rules.
Clients SHOULD NOT respond with sidecars related to blocks that fail the beacon chain state transition

##### BlobSidecarsByRange v1
For each `response_chunk`, a `ForkDigest`-context based on `compute_fork_version(compute_epoch_at_slot(blob_sidecar.signed_block_header.message.slot))` is used to select the fork namespace of the Response type.

**Protocol ID:** `/eth2/beacon_chain/req/blob_sidecars_by_range/1/`
Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:

*[New in Deneb:EIP4844]*
[0]: # (eth2spec: skip)

The `<context-bytes>` field is calculated as `context = compute_fork_digest(fork_version, genesis_validators_root)`:
| `fork_version` | Chunk SSZ type |
|--------------------------------|-------------------------------|
| `DENEB_FORK_VERSION` and later | `deneb.BlobSidecar` |

[1]: # (eth2spec: skip)

| `fork_version` | Chunk SSZ type |
|--------------------------|-------------------------------|
| `DENEB_FORK_VERSION` | `deneb.BlobSidecar` |
##### BlobSidecarsByRange v1

**Protocol ID:** `/eth2/beacon_chain/req/blob_sidecars_by_range/1/`

*[New in Deneb:EIP4844]*

Request Content:
```
Expand Down Expand Up @@ -389,6 +394,16 @@ Clients MUST respond with blob sidecars that are consistent from a single chain

After the initial blob sidecar, clients MAY stop in the process of responding if their fork choice changes the view of the chain in the context of the request.

For each `response_chunk`, a `ForkDigest`-context based on `compute_fork_version(compute_epoch_at_slot(blob_sidecar.signed_block_header.message.slot))` is used to select the fork namespace of the Response type.

Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:

[0]: # (eth2spec: skip)

| `fork_version` | Chunk SSZ type |
|--------------------------------|-------------------------------|
| `DENEB_FORK_VERSION` and later | `deneb.BlobSidecar` |

## Design decision rationale

### Why are blobs relayed as a sidecar, separate from beacon blocks?
Expand Down