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

Add Electra blob sidecars type to support max blobs from EIP-7691 #488

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Add Electra blob sidecars type to support max blobs from EIP-7691 #488

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
2a212b7
Add Electra blob sidecars type to support max blobs from EIP-7691
nflaig Jan 21, 2025
f9a1a00
Eth-Consensus-Version header is required now
nflaig Jan 21, 2025
e4441b3
More conistent formatting
nflaig Jan 21, 2025
eb306b3
Remove some formatting changes to keep diff minimal
nflaig Jan 21, 2025
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
7 changes: 4 additions & 3 deletions apis/beacon/blob_sidecars/blob_sidecars.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,13 +29,12 @@ get:
headers:
Eth-Consensus-Version:
$ref: '../../../beacon-node-oapi.yaml#/components/headers/Eth-Consensus-Version'
required: false
content:
application/json:
schema:
title: GetBlobSidecarsResponse
type: object
required: [data]
required: [version, execution_optimistic, finalized, data]
properties:
version:
type: string
Expand All @@ -46,7 +45,9 @@ get:
finalized:
$ref: "../../../beacon-node-oapi.yaml#/components/schemas/Finalized"
data:
$ref: "../../../beacon-node-oapi.yaml#/components/schemas/Deneb.BlobSidecars"
anyOf:
- $ref: "../../../beacon-node-oapi.yaml#/components/schemas/Deneb.BlobSidecars"
- $ref: "../../../beacon-node-oapi.yaml#/components/schemas/Electra.BlobSidecars"
application/octet-stream:
schema:
description: "SSZ serialized `BlobSidecars` bytes. Use Accept header to choose this response type"
Expand Down
2 changes: 2 additions & 0 deletions beacon-node-oapi.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -427,6 +427,8 @@ components:
$ref: './types/electra/light_client.yaml#/Electra/LightClientFinalityUpdate'
Electra.LightClientOptimisticUpdate:
$ref: './types/electra/light_client.yaml#/Electra/LightClientOptimisticUpdate'
Electra.BlobSidecars:
$ref: './types/electra/blob_sidecar.yaml#/Electra/BlobSidecars'
Node:
$ref: './types/fork_choice.yaml#/Node'
ExtraData:
Expand Down
7 changes: 7 additions & 0 deletions types/electra/blob_sidecar.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
Electra:
BlobSidecars:
type: array
items:
$ref: "../deneb/blob_sidecar.yaml#/Deneb/BlobSidecar"
minItems: 0
maxItems: 9
Copy link
Member

Choose a reason for hiding this comment

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

This API returns JSON, why is it relevant this maxItems value? Even for SSZ, in it's serialized form the max value is not relevant

Copy link
Member Author

Choose a reason for hiding this comment

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

It returns both JSON and SSZ

beacon-APIs/apis/beacon/blob_sidecars/blob_sidecars.yaml

Lines 50 to 52 in aa1be25

application/octet-stream:
schema:
description: "SSZ serialized `BlobSidecars` bytes. Use Accept header to choose this response type"

Even for SSZ, in it's serialized form the max value is not relevant

I quickly mentioned this in discord, we could just use MAX_BLOB_COMMITMENTS_PER_BLOCK which is 4096 as max items which is what we use in Lodestar for the list limit.

Copy link
Contributor

Choose a reason for hiding this comment

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

It seems better to discard invalid data as quickly as possible, and anything past MAX_BLOBS_PER_BLOCK_ELECTRA is invalid. No need to build in capacity in the rest of the system to handle it, either on the client or server end, for theoretical possibilities which even if working in isolation aren't useful as part of a broader system.

Copy link
Member

Choose a reason for hiding this comment

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

You are talking about a consumer of the REST API, not a p2p network with adversarial peers. I think MAX_BLOB_COMMITMENTS_PER_BLOCK is fine and we don't have to deal with forks on this type anymore

Copy link
Contributor

Choose a reason for hiding this comment

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

Unclear that https://ethereum.github.io/beacon-APIs/?urls.primaryName=dev#/Beacon/getBlobSidecars will even be useful/salient in Fulu; the beacon API might end up with a new getColumnSidecars or similar endpoint. A similar discussion has been happening in the req/resp area, where the v3 Fulu-only getBlobsByRange was removed in lieu of keeping only the column one.

Loading