Skip to content

Latest commit

 

History

History
99 lines (64 loc) · 5.12 KB

prague.md

File metadata and controls

99 lines (64 loc) · 5.12 KB

Engine API -- Prague

Engine API changes introduced in Prague.

This specification is based on and extends Engine API - Cancun specification.

Table of contents

Methods

engine_newPayloadV4

Method parameter list is extended with executionRequests.

Request

  • method: engine_newPayloadV4
  • params:
    1. executionPayload: ExecutionPayloadV3.
    2. expectedBlobVersionedHashes: Array of DATA, 32 Bytes - Array of expected blob versioned hashes to validate.
    3. parentBeaconBlockRoot: DATA, 32 Bytes - Root of the parent beacon block.
    4. executionRequests: Array of DATA - List of execution layer triggered requests. Each list element is the corresponding request type's request_data as defined by EIP-7685. Elements of the list MUST be ordered by request_type in ascending order.

NOTE: Each element of executionRequests is the SSZ serialization of the corresponding field of ExecutionRequests defined in the consensus-specs, such that the 0th element is the first field of that container, 1st element is the second field, and so on.

Response

Refer to the response for engine_newPayloadV3.

Specification

This method follows the same specification as engine_newPayloadV3 with the following changes:

  1. Client software MUST return -38005: Unsupported fork error if the timestamp of the payload does not fall within the time frame of the Prague fork.

  2. Given the executionRequests, client software MUST compute the execution requests commitment and incorporate it into the blockHash validation process. That is, if the computed commitment does not match the corresponding commitment in the execution layer block header, the call MUST return {status: INVALID, latestValidHash: null, validationError: errorMessage | null}.

engine_getPayloadV4

The response of this method is extended with the executionRequests field.

Request

  • method: engine_getPayloadV4
  • params:
    1. payloadId: DATA, 8 Bytes - Identifier of the payload build process
  • timeout: 1s

Response

  • result: object
    • executionPayload: ExecutionPayloadV3
    • blockValue : QUANTITY, 256 Bits - The expected value to be received by the feeRecipient in wei
    • blobsBundle: 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.

NOTE: Each element of executionRequests is the SSZ serialization of the corresponding field of ExecutionRequests defined in the consensus-specs, such that the 0th element is the first field of that container, 1st element is the second field, and so on.

Specification

This method follows the same specification as engine_getPayloadV3 with the following changes:

  1. Client software MUST return -38005: Unsupported fork error if the timestamp of the built payload does not fall within the time frame of the Prague fork.

  2. The call MUST return executionRequests list representing execution layer triggered requests obtained from the executionPayload transaction execution. Each element of the list corresponds to the request type's request_data as defined by EIP-7685. Elements of the list MUST be ordered by request_type in ascending order.

Update the methods of previous forks

This document defines how Prague payload should be handled by the Cancun API.

For the following methods:

a validation MUST be added:

  1. Client software MUST return -38005: Unsupported fork error if the timestamp of payload or payloadAttributes greater or equal to the Prague activation timestamp.