devnet-5: Update EIP-7685: exclude empty requests data in commitment

[jangko]

No description provided.

[tersec]

getPayloadV4 appears to be missing?

2. The call MUST return executionRequests list representing execution layer triggered requests. Each list element is a requests byte array as defined by EIP-7685. The first byte of each element is the request_type and the remaining bytes are the request_data. Elements of the list MUST be ordered by request_type in ascending order. Elements with empty request_data MUST be excluded from the list.

[jangko]

getPayloadV4 appears to be missing?

nimbus-eth1/nimbus/beacon/api_handler/api_getpayload.nim

Line 69 in 036dd23

proc getPayloadV4*(ben: BeaconEngineRef, id: Bytes8): GetPayloadV4Response =

https://github.com/status-im/nimbus-eth1/blob/036dd23e9b0bba425ad87dbbb0d938f379a26e8e/nimbus/rpc/engine_api.nim#L76C2-L78C1

[tersec]

The ExecutionBundle's representation for the executionRequests is fine (since right now, internally, there are exactly 3 sources):

nimbus-eth1/nimbus/beacon/payload_queue.nim

Lines 34 to 39 in 036dd23

	ExecutionBundle* = object
	payload*: ExecutionPayload
	blockValue*: UInt256
	blobsBundle*: Opt[BlobsBundleV1]
	executionRequests*: Opt[array[3, seq[byte]]]
	targetBlobsPerBlock*: Opt[Quantity]

But when getPayloadV4 (which, I wasn't very clear I guess, obviously it exists, but the EIP-7685 update does not appear to exist for it): gets this, it simply relays the bundle of `executionRequests out from the JSON-RPC endpoint:

nimbus-eth1/nimbus/beacon/api_handler/api_getpayload.nim

Lines 82 to 95 in 036dd23

	if bundle.executionRequests.isNone:
	raise unsupportedFork("getPayloadV4 is missing executionRequests")
	let com = ben.com
	if not com.isPragueOrLater(ethTime bundle.payload.timestamp):
	raise unsupportedFork("bundle timestamp is less than Prague activation")
	GetPayloadV4Response(
	executionPayload: bundle.payload.V3,
	blockValue: bundle.blockValue,
	blobsBundle: bundle.blobsBundle.get,
	shouldOverrideBuilder: false,
	executionRequests: bundle.executionRequests.get,
	)

to be serialized implicitly via the default rules.

But two things are different now:

1. they need to each be prefixed with the request type byte; and
2. the empty one(s) need to be skipped

exactly the same/symmetrically as in newPayloadV4, i.e. newPayloadV4 needs to be able to consume what getPayloadV4 produces.

[jangko]

It start from here in the txpool. I know it's a bit confusing because we don't have dedicated block builder. But until then, we have to use what we have.

nimbus-eth1/nimbus/core/tx_pool/tx_packer.nim

Lines 366 to 374 in 03bef35

	func executionRequests*(pst: var TxPacker): seq[seq[byte]] =
	template append(dst, reqType, reqData) =
	if reqData.len > 0:
	reqData.insert(reqType)
	dst.add(move(reqData))
	result.append(DEPOSIT_REQUEST_TYPE, pst.depositReqs)
	result.append(WITHDRAWAL_REQUEST_TYPE, pst.withdrawalReqs)
	result.append(CONSOLIDATION_REQUEST_TYPE, pst.consolidationReqs)

[tersec]

It start from here in the txpool. I know it's a bit confusing because we don't have dedicated block builder. But until then, we have to use what we have.

nimbus-eth1/nimbus/core/tx_pool/tx_packer.nim

Lines 366 to 374 in 03bef35

	func executionRequests*(pst: var TxPacker): seq[seq[byte]] =
	template append(dst, reqType, reqData) =
	if reqData.len > 0:
	reqData.insert(reqType)
	dst.add(move(reqData))
	result.append(DEPOSIT_REQUEST_TYPE, pst.depositReqs)
	result.append(WITHDRAWAL_REQUEST_TYPE, pst.withdrawalReqs)
	result.append(CONSOLIDATION_REQUEST_TYPE, pst.consolidationReqs)

Oops, indeed