Ethereum Core Devs Meeting 68 Agenda

[timbeiko]

Ethereum Core Devs Meeting 68 Agenda

• Meeting Date/Time: Thursday 15 August 2019, 22:00 UTC
• Meeting Duration 1.5 hours
• YouTube Live Stream
• Istanbul Meta EIP

Agenda

1. Istanbul EIPs
   • Client implementation updates for Accepted and Tentatively Accepted
   • Moving Istanbul EIPs from Tentative to Final
   • Benchmarks for gas repricing EIPs
2. Conformance Testing
3. Testnet Upgrade & Istanbul Next Steps
   • Block for September 4th Testnet Fork
   • Splitting Istanbul into two forks
4. Hard fork naming
5. Review previous decisions made and action items
   • Call 67
6. Working Group Updates
7. Testing Updates
8. 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) Pantheon
   h) Turbo Geth
   i) Nimbus
   j) web3j
   k) Mana/Exthereum
   l) Mantis
   m) Nethermind
9. EWASM & Research Updates (only if they are posted in the comments below)

[karalabe]

Here's the Istanbul tracker for Geth: ethereum/go-ethereum#19919

[timbeiko]

Here is the one for Pantheon: https://pegasys1.atlassian.net/browse/PAN-2756

[gumb0]

Here's the one for aleth ethereum/aleth#5716

[axic]

I'd like to bring up hardfork naming as an agenda point. It seems that the fork after Istanbul is already being planned during these calls and I think it would make sense naming that fork and avoiding referring to them as "istanbul part 1 and part 2" (or "phase 1 and phase 2").

Here on Ethereum Magicians I proposed to go with Devcon city names.

Having thought about this today, I think this is a reasonable suggestion:

1. It is unlikely that anytime soon we run out of names.
2. It removes the risk of bike shedding names for many forks to come.

Expanding on 1):

• If we end up upgrading every 12(+) months (which seems to be the case so far), then we'll never run out of names to chose from.
• If we end up upgrading every 6 months (which is the hope of many), then we'll run out of names in >5 years. Plenty of time to come up with a new naming scheme in time.
• If we end up upgrading every 3 months (which I think is unfeasible unless a major shift occurs in how forks are deployed), then we'll run out of names in 21 months after Istanbul, assuming 7 upgrades were deployed. I'd call this a bit unrealistic.

The above of course assumes that Devcons continue to take place every year. In the unlikely case that Devcons won't be organized in the future, there would be still plenty of time (as shown above) to agree on a new naming scheme.

(Perhaps a bit prematurely, but I did create meta file named Berlin back in May: EIP-2070)

[carver]

Tracking for Trinity: https://github.com/ethereum/py-evm/milestone/11

[Daft-Wullie]

Small typo, the title of the Youtube Livestream incorrectly indicates the meeting as happening on the 2nd of August.

[shamatar]

Short update on 1962:

• Merged updated ABI spec reflecting separate precompile addresses for different operations
• First part of gas schedule is posted. Recalculating the rest, but it's much easier now
• Some changes happened in Rust implementation and another run of fuzzy-tester will happen after Rust implementation is considered final

[sorpaas]

Tracking issue for Parity: openethereum/parity-ethereum#10770

[sorpaas]

Unfortunately 2200 UTC is too late for me to join.

• Regarding client update for Parity, we have EIP-1702 and ProgPoW merged, and a draft PR of EIP-1962. We also have EIP-1283's part of EIP-2200, and have a pending-reopen PR of EIP-1706's part of EIP-2200.
• Regarding EIP-2200, my opinion is that we can only do it for Istanbul if we keep it as EIP-1283+1706 ("reject below 2300"). If we go with other proposed routes, then we don't have time to carry out security audit. That is, I agree with what @karalabe said on this comment (EIP-2200: Structured Definitions for Net Gas Metering EIPs#2200 (comment)).

[timbeiko]

@Daft-Wullie thanks for the catch -- updated!

[holiman]

@sorpaas and @karalabe and @chfast (well, everyone really) -- the reject below 2300 could be changed into reject below 1600, since 700 will be spent on CALL (if re-entrancy is what we fear). Do we want to use that, or leave that particular optimization aside?

[chfast]

@holiman I have considered the option of lowering the required gas for SSTORE from 2300 to 1600 (i.e. stipend - call cost). I'm not sure this gives us a lot because the particular number is less important than the fact we introduce a weird behavior. But on theoretical level it depends on the interpretation what "calls with stipend only are safe" mean.

• if "reentry is not possible" we can go with 1600,
• if "the callee cannot change its state" then 2300 should stay.

In case of 1600, it should be defined as stipend_gas - call_gas so we don't have to update the spec in case we'd lake to change the call_gas in future.

Personally, I don't have strong preferences. 2300 is slightly simpler and safer, 1600 is more user friendly because chance of this exception to happen in practice is lower.

[holiman]

I'm fine with keeping 2300, if nothing else than because most people have focused on the re-entrancy aspect, and I'm not sure we've fully vetted potential security problems arising from breaking "the callee cannot change its state". So if we're doing EIP-2200 now, I agree with 2300

[tkstanczak]

NethermindEth/nethermind#771