Closed timbeiko closed 3 months ago
One EIP that I want to consider consider for Pectra or the Verkle fork:
https://github.com/ethereum/EIPs/pull/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.
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
Then it would be great having a discussion about including it into Pectra or not.
The tldr is of my recent analysis is:
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: https://github.com/ethereum/go-ethereum/pull/29040
And in the execution-specs here: https://github.com/ethereum/execution-specs/pull/897
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.
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 |
@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. 🙂
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 -
Oppose -
Neutral -
Could we take a minute to poll the room for what to do about ORIGIN? Three main options:
Alias ORIGIN to SENDER (EIP-7645) - Elegant and final, but with slight backwards compatibility breakage.
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.)
Handle ORIGIN piecemeal in AA solutions - Kick the can down the road and let each AA spec handle ORIGIN individually.
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 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)
And here's a doc on updating EIP-7002 to handle EL-init'd consolidations, if anyone wants to review ahead of time:
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.
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).
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.
HI
Nethermind's opinion about Pectra hardfork below:
Favor:
Neutral (weak yes):
Against:
No opinion yet:
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:
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.
Thanks everyone, I've added everything to the agenda, as well as the issuance update which we couldn't get to last call.
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 | :red_circle: | Scope too large, and no impact study for its interaction with verkle |
2537: BLS-12 functions | :white_check_mark: | |
2935: historical hashes | :white_check_mark: | |
3068: BN256 HashToCurve | :red_circle: | The adoption of BLS means we should not encourage dapps to keep using older curves |
3074: AUTH and AUTHCALL opcodes | :white_check_mark: | |
5806: Delegate transaction | :small_orange_diamond: | |
5920: PAY opcode | :red_circle: | Implementation in EELS has revealed a lot of corner cases |
6404: SSZ Transactions Root | :red_circle: | No satisfactory SSZ library at this time |
6465: SSZ Withdrawals Root | :red_circle: | No satisfactory SSZ library at this time |
6466: SSZ Receipts Root | :red_circle: | No satisfactory SSZ library at this time |
6493: SSZ Transaction Signature Scheme | :red_circle: | No satisfactory SSZ library at this time |
6913: SETCODE instruction | :red_circle: | Insecure |
6914: Reuse validator indices | :small_orange_diamond: | |
7212: secp256r1 Curve Support | :small_orange_diamond: | |
7377: Migration Transaction | :red_circle: | |
7545: Verkle precompile | :red_circle: | Champion no longer wishes to pursue this for Prague |
7547: Inclusion Lists | :red_circle: | Not specified enough |
7553: Separated Payer Transaction | :red_circle: | |
7557: Block-level Warming | :red_circle: | |
7594: PeerDAS | :small_orange_diamond: | |
7609: TLOAD/TSTORE pricing | :small_orange_diamond: | |
7623: Increase calldata cost | :small_orange_diamond: | |
7664: Access-Key opcode | :red_circle: | |
7667: hash functions gas cost | :red_circle: |
@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
@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.
Closed in favor of https://github.com/ethereum/pm/issues/1016
Meeting Info
#allcoredevs
Discord channel shortly before the callAgenda
ORIGIN
changes