ethereum/pm

Ethereum Core Devs Meeting 71 Agenda

Souptacular opened this issue · 13 comments

Souptacular commented

Ethereum Core Devs Meeting 71 Agenda

Agenda

  1. Istanbul related client updates
  2. Block number for Istanbul testnet
  3. blake2b and Net-metered SSTORE EIP Update
  4. "Ethereum Roadmap 2020: A Community Discussion" @ Devcon5
  5. Both ProgPoW Audits Released
  6. Review previous decisions made and action items
  7. 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
  8. EWASM & Research Updates (only if they are posted in the comments below)
soc1c commented

Ref eth-clients/goerli#60 (comment) openethereum/parity-ethereum#11068 ethereum/go-ethereum#20090

  • Ropsten block 6485846 (Oct 2)
  • Görli block 1561651 (Oct 30)
  • Rinkeby block 5435345 (November)
  • Kovan block 14111141 (December)
holgerd77 commented

Follow-up on the state of EthereumJS implementation from the comment here:

We have now release v4.1.0 of the VM with full-featured Istanbul support (still labeled as beta).

mhluongo commented

blake2b EIP Update

I just opened a simple language update PR for EIP-152 (BLAKE2 precompile) following the outcomes of our discussion from last call.

Note that no client implementer (that I'm aware of) has voiced support for m_len as an additional param, or continued to push past the call for a restriction of the rounds parameter to a lower bound. I'm interpreting the silence as consensus and moving forward, but I'll try to be available on the call in case we need to discuss further!

fubuloubu commented

I'd like to make a note that for EIP-1344, there was a suggestion that the EVM return a 64-bit sized value for the CHAINID opcode, and that suggestion was removed via ethereum/EIPs#2263 (comment) because it was found to be conflicting with some of the other uses of this parameter as described in other EIPs.

If clients had made this update for EIP-1344 at my recommendation, the should revert this change and stick to the current spec of the proposal, which states that the opcode returns a 256-bit value. This does not change how the value is provided in any way, nor should it change the outcome of how it's used since Chain ID is a pre-defined parameter, but it is something to be aware of.

Reviewing the state of client implementations, only Parity and Trinity would be affected by this update.

axic commented

The Istanbul meta EIP lists a couple of EIPs as accepted and hard fork block numbers are already being set, despite many of them are not final and some aren't even merged.

  • EIP-152: on the last ACD call it was discussed this needs updates and clarification (update: some clarifications were added yesterday, though I'm not sure it is to the extent discussed)
  • EIP-1108: still in draft mode. Is this final? Any changes expected?
  • EIP-1344: there are still some discussions on a PR
  • EIP-1884: still in draft mode. Is this final? Any changes expected?
  • EIP-2028: still in draft mode. Is this final? Any changes expected?
  • EIP-2200: still in a PR form with a couple of questions (update: there has been some updates yesterday)
holiman commented

EIP-1884: still in draft mode. Is this final? Any changes expected?

I don't expect any changes. Are EIP-authors expected to PR it into final? I'm not sure about the process. If I make it PR, the auto-merge bot will merge it, is that the "Right Way" to do it?

  • 👀1
mhluongo commented

@Shadowfiend just opened a PR to flip the status on 1108. Happy to see that the mergebot knew not to merge 😊 - what's the process here?

holiman commented

Quick update re fuzz-testing:

For go-evmlab based standard json fuzzing,

  • The blake F-fuzzer has done did 7.6M testcases on parity vs geth.
  • The sstore/sload targeted fuzzer has done 7.1M testcases on parity vs geth

For libfuzzer-based fuzzing, it's not fully functional, as there's been some problems enabling Istanbul identically on both.

Hive is up and running on a new server: https://hivetests.ethdevops.io/ . While in prod, there are still some bugs and snags to iron out, so might be unreliable and have some downtime as we fix things.

dvdplm commented

Reviewing the state of client implementations, only Parity and Trinity would be affected by this update.

@fubuloubu I believe Parity returns U256 as per the original spec. Happy to take a deeper look if you think it's wrong. :)

  • 👍1
fubuloubu commented

@dvdplm glad that's the case! I just quickly purused what implementation PRs were linked and saw u64, but that could be old information!

  • 👍1
fubuloubu commented

@axic the PR in question for EIP-1344 has been closed with no change applied.

timbeiko commented

Closed in favor of #129