Skip to content

rpc/validator: implement PayloadAttestationData and SubmitPayloadAttestation gRPC endpoints#16487

Merged
terencechain merged 4 commits into
developfrom
payload-att-server
Mar 7, 2026
Merged

rpc/validator: implement PayloadAttestationData and SubmitPayloadAttestation gRPC endpoints#16487
terencechain merged 4 commits into
developfrom
payload-att-server

Conversation

@terencechain

Copy link
Copy Markdown
Collaborator
  • This PR adds the payload attestation prototype flow.
  • On the proto side it introduces PayloadAttestationDataRequest and two RPC methods on BeaconNodeValidator: PayloadAttestationData and SubmitPayloadAttestation.
  • The ForkchoiceFetcher interface is extended with HighestReceivedBlockRoot() [32]byte, which returns the beacon block root at the highest received slot and is used to determine which block PTC members attest to, and HasFullNode([32]byte) bool, which indicates whether a full payload node exists for a given root and determines the PayloadPresent field in the response.
  • The RPC server implementation lives in beacon-chain/rpc/prysm/v1alpha1/validator/payload_attestation.go. PayloadAttestationData validates the current slot, checks sync status, and returns attestation data using the forkchoice helpers, while SubmitPayloadAttestation validates the request, broadcasts it over P2P, applies it locally through ReceivePayloadAttestationMessage, and inserts it into the payload attestation pool. Wiring adds PayloadAttestationPool and PayloadAttestationReceiver to Server, rpc.Config, and BeaconNode, with the pool instantiated in node.New().
  • Both RPCs are marked deprecated = true since this prototype will eventually move to the beacon REST API.

@james-prysm

Copy link
Copy Markdown
Contributor

nil pointer error on TestSubmitPayloadAttestation_OK

"payload attestation data is only available for current slot: requested %d, current %d", slot, currentSlot)
}

highestReceivedSlot := vs.ForkchoiceFetcher.HighestReceivedBlockSlot()

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

There's 3 consencutive fork choice calls here, is this safe to assume they will be aligned or is there a potential change between any of these?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Yes, i think the risk is very small such that dont worth the refactor

BeaconBlockRoot: root[:],
Slot: slot,
PayloadPresent: payloadPresent,
BlobDataAvailable: payloadPresent,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

is this always the case or is this a todoitem to update when da paths are mapped out

return nil, status.Errorf(codes.InvalidArgument,
"payload attestations are not supported before Gloas fork (slot %d)", msg.Data.Slot)
}
if vs.SyncChecker.Syncing() {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

nit , this is usually the first check

Introduces the payload timeliness committee (PTC) attestation pool.
The pool aggregates PayloadAttestationMessages by PayloadAttestationData
(keyed by SSZ hash tree root), maintains aggregation bitvectors, and
exposes PendingPayloadAttestations for proposer block construction.
…n gRPC endpoints

Implements the beacon node gRPC server side of PTC (Payload Timeliness
Committee) attestation flow:

- PayloadAttestationData: returns current-slot attestation data using
  HighestReceivedBlockRoot and HasFullNode from forkchoice
- SubmitPayloadAttestation: validates, broadcasts, applies locally via
  ReceivePayloadAttestationMessage, and inserts into the payload
  attestation pool

Also adds HighestReceivedBlockRoot and HasFullNode to the
ForkchoiceFetcher interface with corresponding Service implementations,
wires PayloadAttestationPool and PayloadAttestationReceiver through the
RPC service config and node, and extends the proto with
PayloadAttestationDataRequest and the two new service RPCs.

@james-prysm james-prysm left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

did a second pass seems ok, my feedback was added.

@terencechain terencechain enabled auto-merge March 7, 2026 04:04
@terencechain terencechain added this pull request to the merge queue Mar 7, 2026
Merged via the queue into develop with commit 7a4bea0 Mar 7, 2026
19 checks passed
@terencechain terencechain deleted the payload-att-server branch March 7, 2026 05:05
@github-project-automation github-project-automation Bot moved this from Unassigned to Done in Gloas Mar 7, 2026
syjn99 pushed a commit to syjn99/prysm that referenced this pull request Mar 13, 2026
…station gRPC endpoints (OffchainLabs#16487)

- This PR adds the payload attestation prototype flow. 
- On the proto side it introduces `PayloadAttestationDataRequest` and
two RPC methods on `BeaconNodeValidator`: `PayloadAttestationData` and
`SubmitPayloadAttestation`.
- The `ForkchoiceFetcher` interface is extended with
`HighestReceivedBlockRoot() [32]byte`, which returns the beacon block
root at the highest received slot and is used to determine which block
PTC members attest to, and `HasFullNode([32]byte) bool`, which indicates
whether a full payload node exists for a given root and determines the
`PayloadPresent` field in the response.
- The RPC server implementation lives in
`beacon-chain/rpc/prysm/v1alpha1/validator/payload_attestation.go`.
`PayloadAttestationData` validates the current slot, checks sync status,
and returns attestation data using the forkchoice helpers, while
`SubmitPayloadAttestation` validates the request, broadcasts it over
P2P, applies it locally through `ReceivePayloadAttestationMessage`, and
inserts it into the payload attestation pool. Wiring adds
`PayloadAttestationPool` and `PayloadAttestationReceiver` to `Server`,
`rpc.Config`, and `BeaconNode`, with the pool instantiated in
`node.New()`.
- Both RPCs are marked `deprecated = true` since this prototype will
eventually move to the beacon REST API.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants