diff --git a/src/engine/osaka.md b/src/engine/osaka.md index 496b2a1df..31951d48d 100644 --- a/src/engine/osaka.md +++ b/src/engine/osaka.md @@ -55,7 +55,7 @@ The fields are encoded as follows: ### engine_getPayloadV5 -This method is updated in a backward incompatible way. Instead of returning `BlobBundleV1`, it returns `BlobsBundleV2`. +This method is updated in a backward incompatible way. Instead of returning `blobsBundle` as [`BlobsBundleV1`](./cancun.md#blobsbundlev1), it returns [`BlobsBundleV2`](#BlobsBundleV2). #### Request @@ -85,10 +85,10 @@ This method follows the same specification as [`engine_getPayloadV4`](./prague.m 3. The call **MUST** return `blobs` and `proofs` that match the `commitments` list, i.e. 1. `assert len(blobsBundle.commitments) == len(blobsBundle.blobs)` and 2. `assert len(blobsBundle.proofs) == len(blobsBundle.blobs) * CELLS_PER_EXT_BLOB` and - 3. `assert verify_cell_kzg_proof_batch(commitments, cell_indices, cells, blobsBundle.proofs)` (see [EIP-7594 consensus-specs](https://github.com/ethereum/consensus-specs/blob/36d80adb44c21c66379c6207a9578f9b1dcc8a2d/specs/fulu/polynomial-commitments-sampling.md#verify_cell_kzg_proof_batch)) + 3. `assert verify_cell_kzg_proof_batch(commitments, cell_indices, cells, blobsBundle.proofs)` (see [EIP-7594 consensus-specs](https://github.com/ethereum/consensus-specs/blob/master/specs/fulu/polynomial-commitments-sampling.md#verify_cell_kzg_proof_batch)) 1. `commitments` should list each commitment `CELLS_PER_EXT_BLOB` times, repeating it for every cell. In python, `[blobsBundle.commitments[i] for i in range(len(blobsBundle.blobs)) for _ in range(CELLS_PER_EXT_BLOB)]` 2. `cell_indices` should be `[0, ..., CELLS_PER_EXT_BLOB, 0, ..., CELLS_PER_EXT_BLOB, ...]`. In python, `list(range(CELLS_PER_EXT_BLOB)) * len(blobsBundle.blobs)` - 3. `cells` is the list of cells for an extended blob. In python, `[cell for blob in blobsBundle.blobs for cell in compute_cells(blob)]` (see [compute_cells](https://github.com/ethereum/consensus-specs/blob/v1.5.0-beta.3/specs/fulu/polynomial-commitments-sampling.md#compute_cells) in consensus-specs) + 3. `cells` is the list of cells for an extended blob. In python, `[cell for blob in blobsBundle.blobs for cell in compute_cells(blob)]` (see [compute_cells](https://github.com/ethereum/consensus-specs/blob/master/specs/fulu/polynomial-commitments-sampling.md#compute_cells) in consensus-specs) 4. All of the inputs to `verify_cell_kzg_proof_batch` have the same length, `CELLS_PER_EXT_BLOB * len(blobsBundle.blobs)` ### engine_getBlobsV2 diff --git a/src/engine/paris.md b/src/engine/paris.md index a4e3b8bc3..8330f4eb0 100644 --- a/src/engine/paris.md +++ b/src/engine/paris.md @@ -40,7 +40,7 @@ Engine API structures and methods specified for Paris. ### ExecutionPayloadV1 -This structure maps on the [`ExecutionPayload`](https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/beacon-chain.md#ExecutionPayload) structure of the beacon chain spec. The fields are encoded as follows: +This structure maps on the [`ExecutionPayload`](https://github.com/ethereum/consensus-specs/blob/master/specs/bellatrix/beacon-chain.md#executionpayload) structure of the beacon chain spec. The fields are encoded as follows: - `parentHash`: `DATA`, 32 Bytes - `feeRecipient`: `DATA`, 20 Bytes @@ -136,7 +136,7 @@ The payload build process is specified as follows: 3. Client software **SHOULD** start the process of updating the payload. The strategy of this process is implementation dependent. The default strategy is to keep the transaction set up-to-date with the state of local mempool. -4. Client software **SHOULD** stop the updating process when either a call to `engine_getPayload` with the build process's `payloadId` is made or [`SECONDS_PER_SLOT`](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#time-parameters-1) (12s in the Mainnet configuration) have passed since the point in time identified by the `timestamp` parameter. +4. Client software **SHOULD** stop the updating process when either a call to `engine_getPayload` with the build process's `payloadId` is made or [`SLOT_DURATION_MS`](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md#time-parameters-1) (12s in the Mainnet configuration) have passed since the point in time identified by the `timestamp` parameter. 5. Client software **MUST** begin a new build process if given `PayloadAttributes` doesn't match payload attributes of an existing build process. Every new build process **MUST** be uniquely identified by the returned `payloadId` value. diff --git a/src/engine/shanghai.md b/src/engine/shanghai.md index 157376be4..ae92469ed 100644 --- a/src/engine/shanghai.md +++ b/src/engine/shanghai.md @@ -191,7 +191,7 @@ This method follows the same specification as [`engine_getPayloadV1`](./paris.md 1. Client software **MUST** set `withdrawals` field to `null` for bodies of pre-Shanghai blocks. -1. This request maps to [`BeaconBlocksByRoot`](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#beaconblocksbyroot) in the consensus layer `p2p` specification. Callers must be careful to use the execution block hash, instead of the beacon block root. +1. This request maps to [`BeaconBlocksByRoot`](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md#beaconblocksbyroot-v1) in the consensus layer `p2p` specification. Callers must be careful to use the execution block hash, instead of the beacon block root. 1. Callers must consider that syncing execution layer client may not serve any block bodies, including those that were supplied by `engine_newPayload` calls. @@ -228,7 +228,7 @@ This method follows the same specification as [`engine_getPayloadV1`](./paris.md 1. Client software **MUST** set `withdrawals` field to `null` for bodies of pre-Shanghai blocks. -1. This request maps to [`BeaconBlocksByRange`](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#beaconblocksbyrange) in the consensus layer `p2p` specification. +1. This request maps to [`BeaconBlocksByRange`](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md#beaconblocksbyrange-v1) in the consensus layer `p2p` specification. 1. Callers must be careful to not confuse `start` with a slot number, instead mapping the slot to a block number. Callers must also be careful to request non-finalized blocks by hash in order to avoid race conditions around the current view of the canonical chain.