changes required for EIP-7742

[ralexstokes]

see motivation etc here: ethereum/consensus-specs#3800

[g11tech]

lgtm

[g11tech]

actually i think we might need to add baseFeePerBlobGas in beacon's execution header and hence the api field, because the blob gas price can't just be now : minFee* e^(ecessBlobGasg/blobGasPriceUpdateFraction) since blobGasPriceUpdateFraction (for limiting change 1+-1.125 factor) could change block to block.

so we should return to the normal pricing mechanism like basefee, so blobBaseFee = parent.blobBaseFee * e^((blobGasUsed - targetBlobGas)/blockAdjustedTargetFraction))

where blockAdjustedTargetFraction makes sure fee doesn't "change" by 1.125 either direction and is calculated block to block.

so in EL block header, we now remove excessBlobGas and add three fields: baseFeePerBlobGas, targetBlobGas and maxBlobGas (since we don't want this to be a hardfork based setting anymore as well, and don't want to keep a static fraction between target and max for better control over the blob throughput and bandwidth params), and beacon execution header we just add baseFeePerBlobGas

if it makes sense i could update the EIP 7742 with the gas calc changes and introducing the new fields

[siladu]

Updated eth Block schema as well: #601

[ensi321]

Would probably want to rebase this so that targetBlobsPerBlock(targetBlobCount?) is placed after executionRequests in the param of engine_newPayloadV4

[siladu]

Updated eth_ Block schema with targetBlobsPerBlock as well #601

[lightclient]

gotta add execution payload v4 here I think

[ralexstokes]

ty, fixed

[mkalinin]

I don’t think we need a new ExecutionPayload definition, since we have targetBlobsPerBlock passed as a param to newPayloadV4

[ralexstokes]

that's the value coming from the CL, the EL needs a way to capture what is on-chain

the EL's job here is to verify the value in the EL header matches what the CL is sending

[mkalinin]

right, but the treatment of this value looks similar to parentBeaconBlockRoot, i don’t get why the targetBlobsPerBlock should be a part of the payload

[ralexstokes]

if we don't do it this way, we would need to have the CL validate this field in the ExecutionPayload

and I just took a look at how we handle the parent beacon block root, and kind of agree we should do this check there and can skip passing it via the ExecutionPayloadV4 here

let's see if we decide to ship EIP-7742 in pectra and we can make these updates in that case

[ralexstokes]

closing as we decided against Pectra inclusion on ACDC #147

[siladu]

Also reverting the eth_ block schema changes #610