EIP-8025 by frisitano · Pull Request #735 · ethereum/execution-apis

frisitano · 2026-01-15T23:28:13Z

Introduces the API for the proof engine.

kevaundray · 2026-01-16T01:39:32Z

src/engine/openrpc/methods/proof.yaml

+- name: engine_requestProofsV1
+  summary: Requests proof generation for a new payload request


Checking, do we still need this if the proofs are pushed to the CL versus the CL requesting proofs from the proof engine?

I think it makes sense to keep it. The CL should instruct the proof engine what blocks to generate proofs for. It requires consensus layer context to determine when a proof is required by that nodes builder. I think the flow is pretty clean if you look at the first diagram in this PR (prover replaced by builder in the future) ethereum/consensus-specs#4828. What do you think?

Ah I see, I think I merged some of the prover related responsibilities into zkboost -- but perhaps it doesn't matter

jsign · 2026-01-16T16:39:20Z

src/engine/eip8025.md

+
+The fields are encoded as follows:
+
+- `newPayloadRequestRoot`: `DATA`, 32 Bytes - Root of the `NewPayloadRequest` being proven.


Do we need to be more explicit what root means in this context?
I think might be okay as it is if usually "root" means CL and "hash" means EL as Jihoon mentioned some days ago.

Yes, I think it is ok because a similar pattern and explanation is used for other constructs in the repo, e.g.:

3. `parentBeaconBlockRoot`: `DATA`, 32 Bytes - Root of the parent beacon block.

jsign · 2026-01-16T16:40:48Z

src/engine/eip8025.md

+This structure contains the header fields of an execution payload (without transactions):
+
+- `parentHash`: `DATA`, 32 Bytes
+- `feeRecipient`: `DATA`, 20 Bytes
+- `stateRoot`: `DATA`, 32 Bytes
+- `receiptsRoot`: `DATA`, 32 Bytes
+- `logsBloom`: `DATA`, 256 Bytes
+- `prevRandao`: `DATA`, 32 Bytes
+- `blockNumber`: `QUANTITY`, 64 Bits
+- `gasLimit`: `QUANTITY`, 64 Bits
+- `gasUsed`: `QUANTITY`, 64 Bits
+- `timestamp`: `QUANTITY`, 64 Bits
+- `extraData`: `DATA`, 0 to 32 Bytes
+- `baseFeePerGas`: `QUANTITY`, 256 Bits
+- `blockHash`: `DATA`, 32 Bytes
+- `transactionsRoot`: `DATA`, 32 Bytes
+- `withdrawalsRoot`: `DATA`, 32 Bytes
+- `blobGasUsed`: `QUANTITY`, 64 Bits
+- `excessBlobGas`: `QUANTITY`, 64 Bits


Does this definition has to be aware of forks, thus some fields being optional?

I think the standard in this repo is that the types should be versioned, and each version contains the appropriate fields for the fork. This means the current V1 struct is aligned with Osaka.

src/engine/eip8025.md

jsign · 2026-01-16T16:46:10Z

src/engine/eip8025.md

+
+#### Response
+
+* result: [`ProofStatusV1`](#proofstatusv1) - The verification result.


Maybe a nit, but for this engine_verifyNewPayloadRequestHeaderV1 we should technically name the return type ProofsStatusV1 instead of ProofStatusV1?

Since technically we are checking a proofs policy, no?

Not sure it is worth changing tbh -- just surfacing thought.

I think it is fine to use the same return type ProofStatusV1 for both engine_verifyNewPayloadRequestHeaderV1 and engine_verifyExecutionProofV1 and have slightly different interpretations. This is analogous to how PayloadStatusV* is used as the return type for both engine_newPayload* and engine_forkchoiceUpdated*.

jsign · 2026-01-16T16:46:34Z

src/engine/eip8025.md

+  2. `versionedHashes`: `Array of DATA`, 32 Bytes each - Array of blob versioned hashes.
+  3. `parentBeaconBlockRoot`: `DATA`, 32 Bytes - Root of the parent beacon block.
+  4. `proofAttributes`: [`ProofAttributesV1`](#proofAttributesv1) - Attributes specifying which proofs to generate.
+* timeout: 1s


Is this TBD?

Good catch, I added a note - *Note*: The timeouts are not definitive.

frisitano · 2026-01-18T23:57:40Z

src/engine/eip8025.md

+  1. `executionPayload`: [`ExecutionPayloadV3`](./cancun.md#executionpayloadv3) - The execution payload to generate proofs for.
+  2. `versionedHashes`: `Array of DATA`, 32 Bytes each - Array of blob versioned hashes.
+  3. `parentBeaconBlockRoot`: `DATA`, 32 Bytes - Root of the parent beacon block.
+  4. `proofAttributes`: [`ProofAttributesV1`](#proofAttributesv1) - Attributes specifying which proofs to generate.


Do we need to add execution requests here?

Yep, could be named request_bytes or similar (use same name as CL specs).

I propose we remain internally consistent in the execution APi specs? For example, executionRequests is used here:

execution-apis/src/engine/prague.md

Lines 66 to 74 in 11517b4

#### Response

* result: `object`

- `executionPayload`: [`ExecutionPayloadV3`](./cancun.md#executionpayloadv3)

- `blockValue` : `QUANTITY`, 256 Bits - The expected value to be received by the `feeRecipient` in wei

- `blobsBundle`: [`BlobsBundleV1`](#BlobsBundleV1) - Bundle with data corresponding to blob transactions included into `executionPayload`

- `shouldOverrideBuilder` : `BOOLEAN` - Suggestion from the execution layer to use this `executionPayload` instead of an externally provided one

- `executionRequests`: `Array of DATA` - Execution layer triggered requests obtained from the `executionPayload` transaction execution.

* error: code and message set in case an exception happens while getting the payload.

eip8025

b91e866

frisitano mentioned this pull request Jan 15, 2026

EIP-8025 ethereum/beacon-APIs#569

Open

frisitano marked this pull request as ready for review January 15, 2026 23:35

frisitano mentioned this pull request Jan 15, 2026

Refactor EIP-8025 specs ethereum/consensus-specs#4828

Merged

kevaundray reviewed Jan 16, 2026

View reviewed changes

jsign reviewed Jan 16, 2026

View reviewed changes

frisitano added 2 commits January 17, 2026 17:11

address PR comments

200652c

address PR comments

5be8584

frisitano commented Jan 18, 2026

View reviewed changes

add execution requests

f99e724

		- name: engine_requestProofsV1
		summary: Requests proof generation for a new payload request


		The fields are encoded as follows:

		- `newPayloadRequestRoot`: `DATA`, 32 Bytes - Root of the `NewPayloadRequest` being proven.


		#### Response

		* result: [`ProofStatusV1`](#proofstatusv1) - The verification result.

	#### Response

	* result: `object`
	- `executionPayload`: [`ExecutionPayloadV3`](./cancun.md#executionpayloadv3)
	- `blockValue` : `QUANTITY`, 256 Bits - The expected value to be received by the `feeRecipient` in wei
	- `blobsBundle`: [`BlobsBundleV1`](#BlobsBundleV1) - Bundle with data corresponding to blob transactions included into `executionPayload`
	- `shouldOverrideBuilder` : `BOOLEAN` - Suggestion from the execution layer to use this `executionPayload` instead of an externally provided one
	- `executionRequests`: `Array of DATA` - Execution layer triggered requests obtained from the `executionPayload` transaction execution.
	* error: code and message set in case an exception happens while getting the payload.

Conversation

frisitano commented Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

frisitano Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

frisitano Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jsign Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

frisitano commented Jan 15, 2026 •

edited

Loading

frisitano Jan 23, 2026 •

edited

Loading

frisitano Jan 23, 2026 •

edited

Loading

jsign Jan 22, 2026 •

edited

Loading