Ethereum Core Devs Meeting 83 Agenda

[timbeiko]

Ethereum Core Devs Meeting 83 Agenda

• Meeting Date/Time: Friday 20 March 2020, 14:00 UTC
• Meeting Duration 1.5 hours
• YouTube Live Stream

Agenda

1. Eligibility for Inclusion (EFI) EIP Review
   1. EIP-2537
   2. EIP-1962 fuzzing: See this comment.
   3. EIP-2542
   4. Other (pre-)EIP Proposals
      • Transaction postdata (draft at EIP-2242), a new field in transactions that cannot be read by the EVM
      • Execution over transaction postdata with precompiles (which enables multi-threaded data availability processing)
      • New precompiles for Merkleization and Merkle branch verification
      • Calldata gas cost reduction to 1-2 gas per byte
      • Current transaction hash opcode, which would enable further cost reduction for optimistic rollups
   5. EIP-2046
2. Berlin EIPs
3. Discussion on possible uncle rule changes as part of a larger discussion for time based forks
4. Testing updates
5. Review previous decisions made and action items (if notes available)
6. Ethereum developer survey

Next call: April 3, 2020 14:00 UTC

[forshtat]

Hello. I would like to propose adding to the agenda EIP-2542 (ethereum/EIPs#2542)
This proposes adding 3 new opcodes: TXGASLIMIT, CALLGASLIMIT, TXGASREFUND.
Without these opcodes, meta-transactions are facing some major limitations.

[adlerjohn]

Can we put the following five EIP proposals on the agenda? Thanks.

1. Transaction postdata (draft at EIP-2242), a new field in transactions that cannot be read by the EVM
2. Execution over transaction postdata with precompiles (which enables multi-threaded data availability processing)
3. New precompiles for Merkleization and Merkle branch verification
4. Calldata gas cost reduction to 1-2 gas per byte
5. Current transaction hash opcode, which would enable further cost reduction for optimistic rollups

[gcolvin]

@adlerjohn Do we have EIP numbers for all of these?

[adlerjohn]

@gcolvin No. The latter four require essentially a sanity check from the core devs that they are worth pursuing. IMO they are, and so long as there isn't vehement opposition I can start implementing them. See: https://molochdao.discourse.group/t/mgp-eips-to-improve-rollup-performance/145

[Souptacular]

@adlerjohn are you able to attend the call Friday?

[shamatar]

EIP2537 was reworked and may be considered final.

[AlexeyAkhunov]

If I am able to join, I would like to discuss white-box fuzzing for EIP-1962 and/or similar EIPs. We have some work on-going. I would like to go over high-level idea, challenges and hear thoughts on the suitability of this approach

[adlerjohn]

@Souptacular Yes I can.

[AlexeyAkhunov]

@Giulio2002 will join to discuss the white-box fuzzing of EIP-1952, because he has been doing the work on it: https://github.com/Giulio2002/eip1962-whitebox and https://github.com/Giulio2002/eip1962/tree/master/src/fuzz

[tvanepps]

I'd love to just get a shoutout for the Ethereum Developer Survey (from ETHGlobal)>> https://ethglobal.typeform.com/to/RxHlK8

We're trying to get max participation on this

[MadeofTin]

Discussion on possible uncle rule changes as part of a larger discussion for time based forks.

Cc: Jason carver

[MadeofTin]

I’d like to go through updates on all potential Berlin EIPs.

[shamatar]

Looks like @axic is no longer pushing for EIP2046. I’ve made some tests on cost of invocation of precompiles in OpenEthereum and pricers are cheap (below 1 microsecond) and invocations involve no memory copying (output is written, but users have already paid for it by allocating memory in EVM), so I’d propose to accept it and set CALL to precompile cost to double of what it’s on my machine (35 gas per microsecond), so 70 gas.

[holiman]

Regarding 2046, here's my previous analysis: https://github.com/holiman/goevmlab/tree/master/examples/callPrecompiles#summary .

[shamatar]

I know that there is (or coming soon) a proposal to remeasure “modexp” with huge decrease of the cost, and highly doubt that Blake was measured taking 700 gas into account (as a stateless function that only depends on the input length, it’s not a full hash function), will try to check it explicitly. Keccak256 has fixed cost + price per byte, so one-off costs should have already been taken into account. At least it should be EIFed.

[axic]

@shamatar I'm still hopeful for 2046, but right now working on an analysis to establish cost relationships. That should help us define new values.

[shamatar]

@axic Thank you. I’ll try to move my benchmarks into the separate repo. What I don’t know is how to benchmark the “copy” one cause it’s not that “stateless”.

[holiman]

I’ll try to move my benchmarks into the separate repo. What I don’t know is how to benchmark the “copy” one cause it’s not that “stateless”.

The "copy" is stateless. Memory expansion is outside the scope of the metering (since it's paid separately).

[holiman]

Also, the copy was what I used to benchmark the actual side-effect-free computation-free baseline in the analysis: https://github.com/holiman/goevmlab/tree/master/examples/callPrecompiles#summary . So it's a good baseline to use.

[blackswordsman7]

Here are the meeting notes,
#161

[Souptacular]

Closing in favor of #162.