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.

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

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

Open
wants to merge 5 commits into
base: dev
Choose a base branch
from

Conversation

etan-status
Copy link
Contributor

Currently, documentation does not state what determines the ForkDigest for BlobSidecar. It makes most sense to use the corresponding slot as that one determines the ForkDigest of the corresponding beacon block.

Furthermore, add "and later" remarks so that ELECTRA_FORK_VERSION is also associated with the deneb.BlobSidecar type.

This is in line with how light-client/p2p-interface.md is done.

Currently, documentation does not state what determines the `ForkDigest`
for `BlobSidecar`. It makes most sense to use the corresponding slot as
that one determines the `ForkDigest` of the corresponding beacon block.

Furthermore, add "and later" remarks so that `ELECTRA_FORK_VERSION` is
also associated with the `deneb.BlobSidecar` type.

This is in line with how `light-client/p2p-interface.md` is done.
Comment on lines 190 to 199
The gossip `ForkDigest`-context 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` |

Copy link
Member

Choose a reason for hiding this comment

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

The ForkDigest-context thing is only for Req/Resp, not GossipSub topics. GossipSub has nothing to do with it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

Let's call it ForkDigestValue then.

@ppopth
Copy link
Member

ppopth commented Jul 24, 2024

Furthermore, add "and later" remarks so that ELECTRA_FORK_VERSION is also associated with the deneb.BlobSidecar type.

This is in line with how light-client/p2p-interface.md is done.

This is new to the spec (except light-client), but, given that BlobSidecar is not changed, I think that makes sense.

@@ -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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Likewise, it's inconsistent inside the same document. Overall, [0] seems to be more.. "dominant" throughout the codebase, for these table annotations.

Copy link
Member

Choose a reason for hiding this comment

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

Agreed. It shouldn't really matter either way, it's only used to tell pyspec not to parse the table.

Copy link
Member

@jtraglia jtraglia left a comment

Choose a reason for hiding this comment

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

Looks good to me, thank you!

@jtraglia
Copy link
Member

Will merge after @ppopth and/or @hwwhww also approves.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants