Execution Layer Meeting 185 about pm

[gballet]

We couldn't get the full geth team in a call, however this is the statement from @lightclient, @MariusVanDerWijden and me. @karalabe also agrees on all the "nay"s.

EIP	Geth	Reason
EOF	🔴	Scope too large, and no impact study for its interaction with verkle
2537: BLS-12 functions	✅
2935: historical hashes	✅
3068: BN256 HashToCurve	🔴	The adoption of BLS means we should not encourage dapps to keep using older curves
3074: AUTH and AUTHCALL opcodes	✅
5806: Delegate transaction	🔸
5920: PAY opcode	🔴	Implementation in EELS has revealed a lot of corner cases
6404: SSZ Transactions Root	🔴	No satisfactory SSZ library at this time
6465: SSZ Withdrawals Root	🔴	No satisfactory SSZ library at this time
6466: SSZ Receipts Root	🔴	No satisfactory SSZ library at this time
6493: SSZ Transaction Signature Scheme	🔴	No satisfactory SSZ library at this time
6913: SETCODE instruction	🔴	Insecure
6914: Reuse validator indices	🔸
7212: secp256r1 Curve Support	🔸
7377: Migration Transaction	🔴
7545: Verkle precompile	🔴	Champion no longer wishes to pursue this for Prague
7547: Inclusion Lists	🔴	Not specified enough
7553: Separated Payer Transaction	🔴
7557: Block-level Warming	🔴
7594: PeerDAS	🔸
7609: TLOAD/TSTORE pricing	🔸
7623: Increase calldata cost	🔸
7664: Access-Key opcode	🔴
7667: hash functions gas cost	🔴

[yperbasis]

EIPs for Pectra - Erigon’s stand

The members of the Erigon Team have considered the listed EIPs at https://ethereum-magicians.org/t/pectra-network-upgrade-meta-thread/16809. These are EIPs pending consideration for Pectra, over and above the already included EIPs.
The EIPs have been categorized as "Favour", "Neutral", and "Against". The following is a summary of our perspectives on these EIPs:

EIP	Comments
[Favour] EOF	- Speeds up EVM by eliminating the need for the jump destination analysis - Opens the way for potential future improvements such as EVMMAX
[Favour] EIP-3074: AUTH and AUTHCALL opcodes	- A good step towards account abstraction and working around things like sponsored transactions - Better than alternative EIPs in the direction
[Neutral] EIP-2935: Save historical block hashes in state	- Good for light clients - a step towards including ETH protocol within the state - Not urgent - Likely to be modified later to include changes/hacks for Verkle
[Neutral] EIP-7212: Precompile for secp256r1 curve support	- Has applicability for the listed protocols (Apple’s secure enclave, passkeys, android keystore, etc.) and may welcome developers to build efficient apps around them - May not be popular enough yet, viz. a viz Ethereum application
[Neutral] EIP-7547: Inclusion lists	- We do support the idea of having a feature to work around the possible censorship of transactions - Given the practical scenario of proposer-builder separation, this is a welcome step. We also don’t necessarily think that MEV alone can lead to exclusion of transactions
[Against] 5806: Delegate Transaction	- The storage problem could create a bad UX
[Against] 5920: PAY opcode	- This goes against the assumptions of most smart contracts, where something is supposed to be triggered in response to an incoming value transaction
[Against] EIP-6404, EIP-6465, EIP-6466 SSZ-(Transaction /Withdrawals /Receipts root)	- The change in the formats introduces unnecessary additional complexity for the hard fork in terms of data formats, associated tests and many challenges of debugging
[Against] EIP-6913: SETCODE instruction	- Goes against Ethereum’s principles in general - Introduces challenges in UX as it makes it possible to change contracts even beyond known upgrade patterns
[Against] EIP-6914: Reuse validator indices	- Messes up the flow in the code for maintaining the state and indices, especially for historical indices
[Against] EIP-7377: Migration Transaction	- Allowing EOAs to deploy smart contracts onto their accounts is a convoluted task, considering factors like security and upgradeability of general complexities of smart contracts. Potentially dangerous with not many upsides
[Against] EIP-7545: Verkle proof verification precompile	- This should be done in the same upgrade as Verkle (Osaka). Otherwise, it can bind us to a potentially suboptimal early design
[Against] EIP-7609: Decrease base cost of TLOAD/TSTORE	- The updated costs are too low

[shemnon]

Here's a visual scorecard:

https://gist.github.com/shemnon/4b7d759ae62644899307945df5dad047

I recall stting a more recent Reth statement than Jnauary but cannot find it. A Nethermind or Geth statement would be benificial.

[MarekM25]

HI

Nethermind's opinion about Pectra hardfork below:

Favor:

• All currently CFIed EIPs (EIP-7002, EIP-7251, EIP-6110, EIP-2537) besides Inclusion lists.
• EIP-3074: This proposal appears to be the best for account abstraction, step forward in UX.
• EIP-2935: Save historical block hashes in state - makes stateless clients easier
• EIP-7623: Increasing calldata cost is important, especially if considering raising the gas limit.

Neutral (weak yes):

• EOF - please see comment below

Against:

• Inclusion Lists - Inclusion lists complicate transaction reasoning and block validation processes. The complexity of this EIP is high.
• SSZ in Pectra - we like it, but the scope is already big enough.
• and all other EIPs like PAY Opcode, Setcode, Delegate TX

No opinion yet:

• 7667 - Raise gas costs of hash functions - we plan to do a few benchmarks, We think that it might be a good idea.

Our comment about EOF/4444/Verkle Trees
We're neutral about EOF, because we're not against EOF itself and definitely, it adds value, but the previous commitment from clients was to do a small-fork and do Verkle Trees as soon as possible. Adding EOF changes this, we can't think about Pectra as a small fork anymore and we should consider it medium or even large fork. Our EOF implementation is up to the latest spec. However, EOF brings a significant risk of new consensus issues, which is why it requires thorough testing before being shipped. The risk of consensus issues means that we can't rush the testing process, and we have to assume that it will take time. This testing effort could be allocated to EIP-4444 or Verkle Trees instead. On the other hand, if we don't implement EOF now with advanced implementations in all clients, it means that we'll have to wait for a hard fork after Verkle Trees (which could be two years from now).

Another thing to consider is EIP-4444 or Lightclient's proposal. We have a good plan to make full nodes use less disk space, and it would be great to do it before they need more than 2TB. We have about two years to do this, but with Verkle, Pectra, and EOF coming up, we need to think about it.
In short, we believe we have two choices:

1. Implement a medium/large Pectra with EOF. Sacrifice testing capacity for Verkle and EIP-4444 for now. Continue working on Verkle Trees in parallel. Immediately after Pectra, shift focus to reducing disk space and implementing Verkle Trees.
2. Pursue a small Pectra. Work on Verkle in parallel. Delay EOF and release it after the Verkle hard fork. If additional client resources become available, prioritize work on EIP-4444.

Both options work for us, but adding EOF means we need to consider its impact on Verkle and EIP-4444, which could change our original plan for a small fork.

[vbuterin]

One EIP that I want to consider consider for Pectra or the Verkle fork:

ethereum/EIPs#8367

Increasing gas costs of hash functions, to make the EVM more ZK-SNARK-friendly.

Copying over parts of the Motivation section of the EIP:

Blocks that are heavy with hash function executions take much longer to ZK-SNARK prove than average blocks. Today, many layer-2 protocols are using workarounds such as arbitrary limits and centralized sequencer-enforced rules to deal with this issue. These workarounds are often poorly designed and lead to unneeded security and centralization concerns. Additionally, to make L1 ZK-EVMs work, we need to establish very tight bounds on how long it takes to generate a proof.

Verkle trees solve the part of this problem that comes from Keccak hashing in the Merkle Patricia tree (today: worst-case 305 MB of hashing). However, using opcodes, a block can still contain roughly the following amount of hashing:

Hash	Cost per word	Maximum bytes from 30 million gas
KECCAK (opcode)	6	160 million
SHA256 (precompile)	12	80 million
RIPEMD (precompile)	120	8 million
BLAKE2 (precompile)	3 (12 per 128 bytes)	320 million
LOG* (hashing data)	256 (8 per byte)	3.75 million

The EIP raises gas costs of hash operations to put more favorable bounds on this.

[nerolation]

I would like to talk about EIP-7623 and present some (small) updates:
Reduce token cost for non-zero calldata bytes from 17 to 12 (68 gas vs 48 gas) based on

• access list costs (access lists shouldn't become cheaper than calldata)
• impact on on-chain merkle proofs
• impact on certain (post-quantum secure) cryptography when implemented on-chain

Then it would be great having a discussion about including it into Pectra or not.

The tldr is of my recent analysis is:

• 4844 decreased the median EL payload size
• max block size remained the same
• the gap between avg and max increased
• including blobs, blocks can now have a max size of 3.51 MiB
• EIP-7623 decreases it to 1.9 MiB (incl. 6 blobs)
• 3% of transactios are affected by the new floor price (pay 12/48 instead of 4/16 for calldata) -> among those significantly affected are DA users (majority) and, less drastical, users attaching messages to ETH transfers
• those 3% of transactions are executed by 1.4% of all senders

The latest update on the EIP included lowering the token floor from 16 to 12 as it looked like a better compromise between not affecting that many while still achieving a big reduction in max possible block size.

There's a draft implementation by Marius here:
ethereum/go-ethereum#29040

And in the execution-specs here:
ethereum/execution-specs#897

[holgerd77]

@yperbasis Thanks for your guys effort, such a list is really helpful! 👍

Small additional note on EIP-2935:

Likely to be modified later to include changes/hacks for Verkle

This EIP in its latest iteration is actively deployed and tested within the latest Verkle testnet (Kaustinen 5) so there is a good chance that we will get this right without the need for additional post-integration hacks or changes. 🙂

[non-fungible-nelson]

Hi everyone - posting the same as @yperbasis but at a link here to our wiki: https://wiki.hyperledger.org/pages/viewpage.action?pageId=117441571

The details on what and why are at the link above, from the Besu Maintainers.

The high-level favor, neutral, oppose below:

Favor -

• Mega-EOF
• 3074
• Handful of smaller EIPs

Oppose -

• SSZ EIPs
• SETCODE
• Delegate Tx (5806)
• PAY OpCode

Neutral -

• Several of the smaller EIPs, read the Wiki post for full details

[ralexstokes]

And here's a doc on updating EIP-7002 to handle EL-init'd consolidations, if anyone wants to review ahead of time:

https://notes.ethereum.org/@ralexstokes/r1gFJt4xC

[ralexstokes]

I would keep this toward the end and only discuss if we have spare time, but it would be good to do a temperature check on the lift to add EL-initiated consolidations to EIP-7002 to support EIP-7251.

[cyrusadkisson]

Could we take a minute to poll the room for what to do about ORIGIN? Three main options:

1. Alias ORIGIN to SENDER (EIP-7645) - Elegant and final, but with slight backwards compatibility breakage.

2. Ban ORIGIN in EOF (with an eye towards aliasing later) - This ban starts pushing devs to stop using ORIGIN and find better solutions. Since legacy deployment will still be possible along with EOF, this is not a total ban; more like training wheels. EOF working group says this is trivial to implement. This ban has no real downside, but upside is limited, too, since it can be circumvented until legacy deployments are ended and old ORIGIN use will still be out there. (There is no EIP for this ban yet.)

3. Handle ORIGIN piecemeal in AA solutions - Kick the can down the road and let each AA spec handle ORIGIN individually.

[ralexstokes]

I can also give a small update on EIP-2537.

tl;dr: almost certainly going to keep EIP as-is in terms of existing scope. likely going to mandate some checks the precompile implementation should have, which will come with test vectors so you can readily determine if your client is compliant. and expect a final update to the exact gas costs over the coming weeks/months (noting that clients can go ahead w/ implementation following the EIP today)

[emmanuel-awosika]

Here's a visual scorecard:

https://gist.github.com/shemnon/4b7d759ae62644899307945df5dad047

I recall stting a more recent Reth statement than Jnauary but cannot find it. A Nethermind or Geth statement would be benificial.

I made a thread with each client team's position on different proposals. I was thinking "This looks like I good time to include a chart to show how each EIP is doing in terms of support", but never pursued it. The scorecard looks great--I can totally see myself hacking together a visual mind map in future to plot that relationship.

[emmanuel-awosika]

Hi everyone - posting the same as @yperbasis but at a link here to our wiki: https://wiki.hyperledger.org/pages/viewpage.action?pageId=117441571

The details on what and why are at the link above, from the Besu Maintainers.

The high-level favor, neutral, oppose below:

Favor -

• Mega-EOF
• 3074
• Handful of smaller EIPs

Oppose -

• SSZ EIPs
• SETCODE
• Delegate Tx (5806)
• PAY OpCode

Neutral -

• Several of the smaller EIPs, read the Wiki post for full details

Included this list in the thread I have of EIPs preferred/opposed by client teams (see here). Didn't see EIP-7002, EIP-7251, EIP-6110, EIP-2537, EIP-7547, and EIP-7549 in the list, though. I wanted to include those EIPs in the "favor" section since the Prague Meta thread shows they're all included in the meta EIP, but Twitter doesn't allow for editing posts--so I figured I'd confirm first and possibly add it as separate comment (might not be necessary after today's call, though).

[emmanuel-awosika]

Surfacing this comment someone left in response to my thread with blog posts from client teams:

We really need an "EIPs for everyone" website where both client teams and community members can comment and vote (separately) on EIPs. Community members can signal their preferences and client teams can coordinate much easier in a single dashboard. By default dashboard would show only client teams data but it is also valuable to see what app developers thinks with a good moderation.

My response:

I think someone has suggested a central process for community members to "vote" on EIPs in the past, but there were concerns around centralization.

[timbeiko]

Thanks everyone, I've added everything to the agenda, as well as the issuance update which we couldn't get to last call.

[somnathb1]

@yperbasis Thanks for your guys effort, such a list is really helpful! 👍

Small additional note on EIP-2935:

Likely to be modified later to include changes/hacks for Verkle

This EIP in its latest iteration is actively deployed and tested within the latest Verkle testnet (Kaustinen 5) so there is a good chance that we will get this right without the need for additional post-integration hacks or changes. 🙂

From experience, we go for the most extreme case scenario

[charles-cooper]

@yperbasis can you go into more detail? happy to discuss here or on eth magicians.

[Against]
5920: PAY opcode - This goes against the assumptions of most smart contracts, where something is supposed to be triggered in response to an incoming value transaction

selfdestruct can send value, also ERC20 transfers do not trigger smart contracts. also, usually when you send() ether, you provide a low gas stipend, the receiving contract cannot actually do much besides maybe reject it.

[Against]
EIP-7609: Decrease base cost of TLOAD/TSTORE - The updated costs are too low

can you expand? i'm happy to incorporate feedback in the pricing schedule.

[timbeiko]

Closed in favor of #1016