ethereum/pm

Ethereum Core Devs Meeting 73 Agenda

timbeiko opened this issue · 6 comments

timbeiko commented

Ethereum Core Devs Meeting 73 Agenda

Agenda

  1. Istanbul
    • Testnet Status Updates
    • Mainnet Block
  2. EIP-2124
  3. Berlin
    • Process & scheduling discussions
    • Ice Age
    • Tentatively Accepted EIPs
  4. Testing updates
  5. Review previous decisions made and action items
  6. Client Updates (only if they are posted in the comments below)
    a) Geth
    b) Parity Ethereum
    c) Aleth/eth
    d) Trinity/PyEVM
    e) EthereumJS
    f) EthereumJ/Harmony
    g) Besu
    h) Turbo Geth
    i) Nimbus
    m) Nethermind
  7. Research Updates (only if they are posted in the comments below)
timbeiko commented

For Berlin, I think what’s important is figuring out is this:

  1. When is Istanbul going live on mainnet?
  2. Based on that, do we want the next fork to be closed or open to new EIPs? In other words, is anything except the already "Tentatively Accepted" EIPs being considered?
  3. Based on both of those, do we want to move to either a Train Station or EIP-Centric model?

From my perspective, I see two likely ways this can go:

  1. Istanbul live before EOY, another small fork around April without new EIPs (basically EIP-1962, and maybe ProgPow or other "Tentatively Accepted" EIPs), and then we can aim for an October “whatever’s ready” HF.
  2. Istanbul early 2020, and an open HF mid-2020 (6 months later), where we add not only the Tentatively Accepted Berlin EIPs that make it to Accepted, but also other EIPs (i.e. the first bits of 1559).

There is also the option of moving straight to EIP-Centric forking after Istanbul. Personally, I find this a bit fast, given our previous cadence. I would rather see us getting good at doing progressively shorter forks (i.e. 1 year -> 6 months -> 3 months) over a period of time, rather than going straight to very short upgrades after only having 1+ year cycles.

holiman commented

basically EIP-1962

IMO, Eip-1962 is not ready. 1962. I missed the ACD where it was 'tentatively accepted', and I don't understand how that happened. It contains a huge chunk of text, mostly opaque to non-cryptographers. Things like:

In the case of limited set of curve the following set is proposed as a minimal:

BN254 curve from the current version of Ethereum
BN curve from DIZK with 2^32 roots of unity

An even more detailed spec is available though, here. It's huge. You can skip towards the end, General notices for implementation, where they acknowledge that it's not feasible to expect consensus among clients:

"Garbage in - garbase out". While any valid implementation will give the same results on the same valid input parameters (that define a legitimate curve), caller can supply random values that would pass the ABI checks and gas estimations, but be meaningless in a sense of operations performed. Such input is called "garbage". It's not immediately clean whether or not different implementations will return the same output in this case. This is important for consensus between different implementations and there are two ways to resolve this issue:

If I understand correctly, they recommend using one reference client, which, if we were to implement this, I might actually think is the only sane approach. BUT , doing so will force the same library to always be included in every future fork, also 2.0 execution environments (possibly ported to wasm at that time).

Adding 1962 is basically adding a whole new virtual machine for cryptographic operations, and a huge chunk of code that (I'm guessing) none of the current maintainers of ethereum clients can meaningfully debug nor make sense of.

  • 👍1
timbeiko commented

Thanks for sharing! I only mentioned that EIP given it seemed to have some consensus last time we discussed, but clearly that's not the case. If not enough of the "Tentatively Accepted" from Berlin actually move to Accepted, then it does not make much sense to have Berlin be shortly after Istanbul with just those EIPs.

In that case, we should probably just make Berlin another "regular" hard fork.

poojaranjan commented

Upgrade in Ethereum is for improving performance and to solve existing issues. So, EIP is the heart of upgrades. But again having a timeline bound could add value.

IMO how about a hybrid model incorporating EIP Centric + EIP 1872 + Train model (ref: https://medium.com/@timbeiko/train-planes-network-upgrades-6edfc9f6b7dd)
Key points that could be considered:

  • Target for a biannual upgrade with no fixed month depending on EIP readiness
  • When we've at least 3 major(that can bring substantial change) EIPs ready, then come to the timeline part.
  • Get schedule ready for next upgrade - Finalizing EIPs (EIPs for open discussion to be included in next upgrade) -> Client implementation (be generous while considering time for implementation) -> Testnet date (Consider EIP 1872 for date selection ) -> Mainnet upgrade (consider EIP 1872 and 6-8 weeks gap for mainnet upgrade)

I am not sure if we've any such model if not could be considered for discussion.

If we want a dry run of hybrid model with Berlin upgrade, we have

  • EIPs ready -> Proceed to select EIPs (based on adding value and not based on readiness ( because assumption: EIPs considered for this step is already accepted)
  • Analysing data from previous upgrades, HF coordinator can create a schedule for Berlin. Of course, date can be a little here and there but block number can be hard-locked, assuming everything goes good.
pizzarob commented

Hey looks like I'm a little late here. Is it possible to discuss ethereum/EIPs#2310 during the next meeting?

timbeiko commented

Closed in favor of #134