search

ethereum / pm

Project Management: Meeting notes and agenda items
Other
1.57k stars 320 forks source link

Execution Layer Meeting 196 #1143

Closed timbeiko closed 3 days ago

timbeiko commented 2 weeks ago

Meeting Info

Agenda

lightclient commented 1 week ago

@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: https://github.com/ethereum/EIPs/pull/8854

fjl commented 1 week ago

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.

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 commented 1 week ago

I'd like to discuss https://github.com/ethereum/EIPs/pull/8865 (Update EIP-7702: consistent signature validity checks)

timbeiko commented 6 days ago

Added @lightclient @fjl @yperbasis, thanks!

pk910 commented 4 days ago

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 commented 4 days ago

Sharing Reth's (Aug 30) opinion about https://github.com/ethereum/EIPs/pull/8846 from the R&D discord:

Screenshot 2024-09-11 at 8 48 26 AM

MaxResnick commented 4 days ago

Would like some time to discuss this EIP https://github.com/ethereum/EIPs/pull/8849

timbeiko commented 4 days ago

@MaxResnick we'll cover it as part of https://github.com/ethereum/EIPs/pull/8846 :+1:

abcoathup commented 3 days ago

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 commented 3 days ago

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 commented 3 days ago

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 commented 3 days ago

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. :grin:

MarekM25 commented 3 days ago

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 commented 3 days ago

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).

timbeiko commented 3 days ago

@etan-status can you add this to the agenda for the next ACDC? ty!

timbeiko commented 3 days ago

Closed in favor of https://github.com/ethereum/pm/issues/1153

akashkshirsagar31 commented 3 days ago

Podcast (audio only) - https://open.spotify.com/episode/75myQLPk7S5NkAPsBVlvkq?si=gw-m6yLHRzyC1HHAO61gcw