ethereum/pm

Ethereum Core Devs Meeting 83 Agenda

timbeiko opened this issue · 21 comments

timbeiko commented

Ethereum Core Devs Meeting 83 Agenda

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 commented

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.

  • 👍1
adlerjohn commented

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
  • 👍1
  • ❤️1
gcolvin commented

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

adlerjohn commented

@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 commented

@adlerjohn are you able to attend the call Friday?

shamatar commented

EIP2537 was reworked and may be considered final.

  • 👍1
AlexeyAkhunov commented

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

  • 👍2
adlerjohn commented

@Souptacular Yes I can.

  • 👍1
AlexeyAkhunov commented

@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

  • 👍1
tvanepps commented

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

  • 👍1
  • 😄1
MadeofTin commented

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

Cc: Jason carver

  • 👍1
MadeofTin commented

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

  • 👍2
shamatar commented

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.

  • 👍3
shamatar commented

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 commented

@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 commented

@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 commented

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 commented

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 commented

Here are the meeting notes,
#161

  • 🎉1
Souptacular commented

Closing in favor of #162.