EIP-6110: Validator Deposits on Chain

[refcell]

Description

EIP-6110 includes validator deposits in the execution layer, removing deposit voting from the consensus layer.

From @protolambda:

Can consider an upgrade deposit-tx, with same sender as the pre-determined example tx, to ensure the contract is deployed.
The contract is the same, but effectively no-op, not affecting the block.

References

• Pectra Devnet 5 EIP List
• Proto's list of Pectra EIPs
• Pectra support on the OP Stack tracking issue: OP Stack: Support Pectra (Isthmus) optimism#12435

[protolambda]

IMO we should not use an upgrade-tx. We have done this for contracts that are expected to work with op-stack, like the beacon-block-roots accumulator. But the beacon deposit contract, as well as other pectra-requests-generating contracts, are not expected to work. We should ignore them. It's much more safe to just change the request generation to not include requests of type X (see EIPs) than to try and change the bytecode to something that happens to not insert it. Especially since some of these pectra contracts can be deployed permissionlessly ahead of the op-stack upgrade, and we don't want to modify bytecode.

[emhane]

are changes required to op-node @protolambda ?

[protolambda]

@emhane no op-node changes required for this one. Although, for the more generic requests-handling, it would be good to make the op-node abort block-building if the engine-API ever returns a block with a non-empty requests list. To ensure we don't accidentally build the block if the EL / block-builder API has some bug.

And this then also means to not deploy an upgrade-tx for this contract. See above comment.
Just a tiny EL diff, by not putting this type of request in the block if it's an op-stack chain, regardless of what happens in the EVM.