Ethereum Core Devs Meeting 71 Agenda

[Souptacular]

Ethereum Core Devs Meeting 71 Agenda

• Meeting Date/Time: Friday 20 September 2019, 14:00 UTC
• Meeting Duration 1.5 hours
• YouTube Live Stream
• Istanbul Meta EIP
• Istanbul EIP Implementation Tracker by @holiman

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
   • Call 70
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]

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]

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]

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]

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]

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]

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?

[mhluongo]

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

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]

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. :)

[fubuloubu]

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

[fubuloubu]

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

[shemnon]

@ifdefelse statement on Suggestion 1
https://gitter.im/ethereum-cat-herders/ProgPoW-review?at=5d82a0d2a38dae3a6377c6c8
original tweet storm
https://twitter.com/IfDefElse_/status/1174480889532698624

[timbeiko]

Closed in favor of #129