Execution Layer Meeting 196

[timbeiko]

Meeting Info

• Sep 12, 2024, 14:00-15:30 UTC
• Stream: https://youtube.com/live/A_DuQRICW70
• Zoom: shared on #allcoredevs Discord channel shortly before the call
• Ethereum Protocol Calls Calendar subscription

Agenda

• Pectra
  • devnet-3 updates
  • Encoding changes
    • Update EIP-7685: change requests hash to flat hash EIPs#8854
    • Update EIP-7002: change request to flat encoding EIPs#8855
    • Update EIP-6110: change request to flat encoding EIPs#8856
    • Update EIP-7251: change request to flat encoding EIPs#8857
  • Update EIP-7702: consistent signature validity checks EIPs#8865
  • EIP-2537 MSM precompile pricing (context)
  • EIP additions: Update EIP-7600: Update eip-7600.md EIPs#8846
• Network configuration structure alignment
  • mainnet
  • sepolia
  • holesky

[lightclient]

@fjl made a proposal to EIP-7685 to change the hashing scheme from an MPT to flat keccak256 of the data. Would be good to discuss, I think it makes sense: ethereum/EIPs#8854

[fjl]

Furthermore, we are proposing to simplify the encoding of requests to match the output of the contracts exactly. At the moment, the specs require us to create an intermediate RLP form of these requests, but this encoding is not going to be used by anything. It was just defined like this in order to be similar to encoded transactions.

• Update EIP-7002: change request to flat encoding EIPs#8855
• Update EIP-6110: change request to flat encoding EIPs#8856
• Update EIP-7251: change request to flat encoding EIPs#8857

Changing to a flat encoding removes the need for us to parse contract output in the EL client.

The deposit contract returns event data in Solidity ABI encoding. We cannot change this encoding, but transforming it to a flat encoding mostly means removing ABI padding.

For the newer system contracts in EIP-7002, EIP-7251 we can just forward what they return to the CL directly. The objects in the return output of these contracts are in fact already SSZ-encoded, so the CL will be able to parse them easily.

[yperbasis]

I'd like to discuss ethereum/EIPs#8865 (Update EIP-7702: consistent signature validity checks)

[timbeiko]

Added @lightclient @fjl @yperbasis, thanks!

[pk910]

I'd like to give a small heads up for the network config alignment on the mainnet, sepolia & holesky repositories.
It's just about bringing it to a consistent format for all repositories, but would be great if client teams could take a look and add missing bootnodes operated by them.

Once structures are aligned & EL/CL bootnodes are consistently tracked for all networks,
we'll add some monitoring to blame the offline bootnodes :)

[timbeiko]

Sharing Reth's (Aug 30) opinion about ethereum/EIPs#8846 from the R&D discord:

[MaxResnick]

Would like some time to discuss this EIP ethereum/EIPs#8849

[timbeiko]

@MaxResnick we'll cover it as part of ethereum/EIPs#8846 👍

[abcoathup]

Regards discussion of potential EIP additions to Pectra

If there is potential for a pivot of Fusaka from Verkle, that may change the priority of proposed for inclusion EIPs or even EIPs not yet included in devnets (e.g. EOF, PeerDAS) as they could be considered for Fusaka instead. Reducing the scope/size/risk of Pectra.

[jwasinger]

I would like to discuss EIP-2537. The Geth team is of the opinion that the MSM precompiles should not have a cost model that assumes that the implementation makes use of concurrency.

When we restrict our implementation (gnark) to single-threaded execution, the cost model becomes very underpriced (100% vs the performance of Geth's ecrecover precompile implementation in the worst case for g1).

We want to propose increasing the cost of the MSM precompiles to bring them in line with the performance of the other precompiles. The simplest way to do this is to double each entry in the discount factor table for the MSM cost model. I have posted benchmarks of all the precompiles here ran on two machines. BLS Costs with and without the proposed repricing are presented as well as benchmarks of Geth's ecrecover precompile implementation for context.

[chfast]

I would like to discuss EIP-2537. The Geth team is of the opinion that the MSM precompiles should not have a cost model that assumes that the implementation makes use of concurrency.

When we restrict our implementation (gnark) to single-threaded execution, the cost model becomes very underpriced (100% vs the performance of Geth's ecrecover precompile implementation in the worst case for g1).

We want to propose increasing the cost of the MSM precompiles to bring them in line with the performance of the other precompiles. The simplest way to do this is to double each entry in the discount factor table for the MSM cost model. I have posted benchmarks of all the precompiles here ran on two machines. BLS Costs with and without the proposed repricing are presented as well as benchmarks of Geth's ecrecover precompile implementation for context.

See also https://ethereum-magicians.org/t/eip-2537-bls12-precompile-discussion-thread/4187/76#msms-3

The spec doesn't mention any concurrent execution. If needed, it is definitely not an option for evmone / Silkworm.

[holgerd77]

Some statement from the EF JavaScript team on the proposed EIP additions and EIP changes (not sure if we have someone joining the call today):

CL Request additions (so all under "Encoding changes", requests root -> flat hash, flat encoding (no RLP), signature validity checks):
We are not sure if we have considered all eventual side effects here (e.g. is a flat encoding flexible enough for future request types?), but generally think these changes make sense.

EIP-7623: Increase calldata cost
General support for the idea, no opinion formed if the specific EIP is the optimal way of doing that.

EIP-7742: Uncouple blob count between CL and EL
Supportive.

EIP-7762: Increase MIN_BASE_FEE_PER_BLOB_GAS
Undecided, no consensus.

RIP-7212 (secp256r1 Curve) + SSZ EIPs
For the Pectra HF we think we have reached the tipping point where the complexity of the fork starts to outweight the benefits of having "just one fork", this can already be felt on "getting everyone togehter" on new testnet versions, having all EIPs properly tested (already for the testnets),...

We therefore do not support the addition of any mid-size-or-larger EIPs (RIP-7212 + SSZ EIPs in this category) to the Pectra HF, independent of the usefulness of the respective EIP. In case that there might be a non-Verkle focused HF after Pectra this next HF can then be a candidate to combine these kind of EIPs, judging by experience additional similarly sized EIPs will likely join "naturally" for this fork. 😁

[MarekM25]

Nethermind's View:

EIP-7623: Increase calldata cost
Strongly supportive for inclusion in Pectra.

EIP-7742: Uncouple blob count between CL and EL
Strongly supportive for inclusion in Pectra..

EIP-7762: Increase MIN_BASE_FEE_PER_BLOB_GAS
Not discussed internally.

RIP-7212 (secp256r1 Curve)
Supportive for inclusion in Pectra. We need to verify benchmarks for this precompile and assess gas pricing.

SSZ EIPs
Supportive, but not in Pectra fork.

CL Request additions
We think this change makes sense.

[etan-status]

Note that the SSZ scope has been split up, into CL-only changes (for a more useable EIP-4788 beacon block root for decentralized staking pools: https://stabilitynow.box) and the more involved EL changes (leading to the ability to run a verifying wallet light client: https://fusaka-light.box).

As an author of these EIPs, I agree with EL client teams that the EL changes should be descoped from Pectra CFI (EIP-6404, EIP-6466, EIP-6493, EIP-6465) while the remaining CL changes are fully independent of EL teams and also PeerDAS, and should be temperature checked once more in ACDC around the devnet 5 timing (EIP-7495, EIP-7688). Currently, on the CL devnet, we have working StableContainer implementations from Lighthouse, Lodestar, Nimbus, Teku.

Would be great if the CFI list could be updated to reflect that state (as in, have only the CL changes on it: EIP-7495, EIP-7688).