Ethereum Core Devs Meeting 131 Agenda

[timbeiko]

Meeting Info

• February 4, 2022, 14:00 UTC
• Duration: 90 minutes
• Youtube Stream: https://youtu.be/_kt-r4J8PJc
• Zoom: To be shared on #allcoredevs Discord server shortly before the call

Agenda

• Merge Updates
  • Kintsugi 🍵 office hours
    • Incident report
  • Kiln 🔥🧱 Meta Spec
    • Testing for v1
    • Additions for v2
      • Authentication for engine api execution-apis#167
      • Engine API: add engine_exchangeTransitionConfigurationV1 execution-apis#172
  • Post-Merge testnets #460
• Shanghai Planning #450
  • Move to CFI?
    • Proposal to add EIP-3540 to Shanghai #329
    • Proposal to add EIP-3670 to Shanghai #360
    • Proposal to add EIP-3860 to Shanghai #388
    • Proposal to add EIP-3855 to Shanghai #387
    • Proposal to add EIP-4200 to Shanghai #462
    • Proposal to add EIP-2315 (Simple Subroutines) and EIP-4200 (Static Relative Jumps) into Shanghai. #469
    • Proposal to add EIP-4750 to Shanghai #471
    • Proposal to include EIP-3074 in Shanghai #394
    • EIP-4488 vs. blob-carrying transactions
• Executable EL spec overview
• Merge Community Call #3 #465

[axic]

I'd propose #387 and #462 for CFI too.

[SamWilsn]

I'd like to throw an item for ethereum/execution-specs on there, just to talk about the project and get some feedback.

[gcolvin]

Also for CFI:
EIP-2315 (Simple Subroutines)
EIP-3779 (Safer Control Flow)

[mkalinin]

A couple of Engine API things to discuss:

• Expose entire eth_ namespace vs a subset of eth_ methods at the Engine API port
• Engine API: add getPayloadBodies method execution-apis#146

[lightclient]

We'd like to propose EIP-3074 for CFI.

ducks

[axic]

As discussed around last ACD, we've slowly pushed the last EOF-related EIP, which introduces function sections and could deprecate dynamic jumps entirely. I'd like to propose it for CFI: #471.

[timbeiko]

@gcolvin @axic @lightclient added all your suggestions to the agenda 👍

That said, I think there's a "meta" Shanghai discussion to have before diving deep into all these proposals. On the last call (and quickly after on discord), there seemed to be strong consensus about moving forward with the 3 original EOF EIPs (3540, 3670, 3860), and that was main motivation to include them for consideration on the call.

There are a lot of EIPs considered for Shanghai, and we realistically can't do everything, so I think we need to think hard about what we prioritize and how we make sure to not pre-commit to too many things when The Merge is still a WIP. This large set of competing EIPs is what prompted the original discussion and I think it's important we get the big picture right before making too many decisions.

[dankrad]

As discussed previously on ACD 125 (#401), we want to introduce the statelessness gas cost changes and deactivation of SELFDESTRUCT in Shanghai, to get applications to adapt to the new conditions as early as possible. So I'd like to discuss these three EIPs for inclusion in Shanghai:

• EIP-4758: Deactivate selfdestruct EIPs#4758 (Deactivate SELFDESTRUCT)
• EIP-4760: SELFDESTRUCT bomb EIPs#4760 (SELFDESTRUCT bomb, alternative to 4758)
• EIP-4762: Statelessness gas cost changes EIPs#4762 (Statelessness gas cost changes)

[vbuterin]

Continuing the discussion on pre-sharding calldata cost relief, here is a proposal to bring in "blob-carrying transactions" that contain data inaccessible to EVM execution, in the same format as what we will ultimately use for sharding.

Simple version (easier to implement, but leaves more work for later): https://notes.ethereum.org/@vbuterin/blob_transactions_simple

More complex version (harder to implement, but leaves a very easy transition for sharding): https://notes.ethereum.org/@vbuterin/blob_transactions

If it can be realistically included in Shanghai, this is a potential replacement for EIP 4488. If it cannot, then I still strongly favor EIP 4488 in Shanghai (if not sooner) and then implementing this EIP a few months later.

[parithosh]

I'd like to mention the Kintsugi incident report documented here: https://notes.ethereum.org/@ExXcnR0-SJGthjz1dwkA1A/BkkdHWXTY

afaik no discussion is needed on the topic during ACD, but it would be good to mention it for posterity.

[apolynya]

Continuing the discussion on pre-sharding calldata cost relief, here is a proposal to bring in "blob-carrying transactions" that contain data inaccessible to EVM execution, in the same format as what we will ultimately use for sharding.

Simple version (easier to implement, but leaves more work for later): https://notes.ethereum.org/@vbuterin/blob_transactions_simple

More complex version (harder to implement, but leaves a very easy transition for sharding): https://notes.ethereum.org/@vbuterin/blob_transactions

If it can be realistically included in Shanghai, this is a potential replacement for EIP 4488. If it cannot, then I still strongly favor EIP 4488 in Shanghai (if not sooner) and then implementing this EIP a few months later.

This is great! Can the new transaction format be used for verification of ZKR batches? If not, and the proofs need to be on the execution layer, EIP-4488 still has its place.

Consider the most active ZKR today, dYdX: ~80% of costs are batch verification costs, and only ~20% is transaction data. Brendan from Polygon Zero estimates 4488 can drop their verification costs from to <250K gas, and Bobbin estimates Polygon Miden's STARK verification to drop from 5M to <1M gas. In the same thread, Liron from StarkWare notes that this will reduce dYdX gas costs to sub-100 gas (~500 gas today; only making transaction data cheaper it'll still be around ~400 gas).

Besides that, EIP-4488 is definitely still simpler. All of this to say: I don't think EIP-4488 should be replaced; rather it should be implemented as soon as possible (IMO it's an emergency that justifies own fork between The Merge & Shanghai - and by this time I'd expect rollups to be more mature too), with the blob transactions rolled out later. EIP-4488 may continue to benefit ZK rollups even after there's dedicated space for transaction data. It'd also make sense to have EIP-4488 first, and then directly go to the more complex version that's more easily forward compatible with danksharding (though I don't understand the technical differences between the simpler version).

[holgerd77]

costs from to <250K gas

@apolynya could you add this first from number? Still missing.

[tkstanczak]

shall we split the Merge All Core Devs and EIP All Core Devs so they can work in parallel with separate teams and decision makers? (sounds like the former Consensus and Execution split but with Consensus team bringing EL devs who work on the Merge)