ethereum/pm

Ethereum Core Devs Meeting 56 Agenda

Souptacular opened this issue ยท 10 comments

Ethereum Core Devs Meeting 56 Agenda

Agenda

  1. Roadmap
    a) Constantinople Success!
    b) ProgPoW Audit
    c) Istanbul Hardfork Roadmap
  2. Subroutines and Static Jumps for the EVM - Magician's Thread
  3. Reject EIP-1355
  4. Working Group Updates
    a) State Fees
    b) EWasm
    c) Pruning/Sync
    d) Simulation
    e) Appetite for future in person meetings?
  5. Testing Updates (time allowing)
  6. Client Updates (time allowing)
    a) Geth
    b) Parity Ethereum
    c) Aleth/eth
    d) Trinity/PyEVM
    e) EthereumJS
    f) EthereumJ/Harmony
    g) Pantheon
    h) Turbo Geth
    i) Nimbus
    j) Mana/Exthereum
    k) Mantis
    l) Nethereum
  7. Research Updates (time allowing)

Reject EIP-1355: ethereum/EIPs#1785. Again, but this time I will attend the meeting.

@Souptacular Just a heads up to be announced, Hudson. We are discussing Subroutines and Static Jumps for the EVM on a Magician's thread. Participation most welcome. Depending on how the discussion goes I'm wanting to be through Last Call in time for our March 29 meeting.

axic commented

When will Petersburg go live on Rinkeby?

It is still set at block "9999999" in geth, while the network is at ~3954000.

Tests byzantium to Constantinople at 5 is updated to have both Constantinople and ConstantinopleFix enabled

Also any test cases that fail not because of hive must be fixed to have a consensus between clients.

Tests like dybamic account overwrite
And CodecopyZero

axic commented

Proposing EIP1352 and EIP1380 for Istanbul.

Proposing EIP1285 for discussion, especially in the light of SSTORE-reentrancy issues discovered for Constantinople.

Before we dive into the EIPs for Instanbul, I suggest we try to address some issues with how we deal with the proposed changes, and what are our priorities.
I proposed to look at these things:

  1. Introduce higher standards for EIPs - they require Proof Of Concept implementation + pre-generated test cases (so that that testing is not an afterthought as usual)
  2. Revisit the assumption that we need to bundle a lot of updates into one big release instead of making smaller releases more frequently. I heard before on this call that coordination costs are too high to afford smaller releases - but are they really?
  3. Appoint dedicated reviewers (not necessary from the people who are regularly attending the call) for changes rather than wait for someone on the call to look into the changes
  4. Do we need to create a deluge of EIPs for Instanbul now or do we spend some time on discussing what the most important changes are?

@Souptacular - @iikirilov from the web3j team are going to be joining the call today - is it too late to add an update from us to the agenda? If not, please can we be added on future calls?

This was my leaf-sync prototype code (last few commits): https://github.com/karalabe/go-ethereum/tree/state-leaf-sync. I'm mostly happy with it, the Achilles heel is huge contracts, which I haven't found a solution yet for.

@axic 2 weeks after the next stable release :) I.e. we can set any block number, we just need a release for it first.

Closing for #83