search

ethereum / pm

Project Management: Meeting notes and agenda items
Other
1.59k stars 325 forks source link

Ethereum Core Devs Meeting 73 Agenda #133

Closed timbeiko closed 5 years ago

timbeiko commented 5 years ago

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 5 years ago

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 5 years ago

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.

timbeiko commented 5 years ago

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 5 years ago

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:

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

pizzarob commented 5 years ago

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

timbeiko commented 5 years ago

Closed in favor of https://github.com/ethereum/pm/issues/134