ethereum/pm

Ethereum Core Devs Meeting 68 Agenda

timbeiko opened this issue · 16 comments

timbeiko commented

Ethereum Core Devs Meeting 68 Agenda

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
  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 commented

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

gumb0 commented

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

  • 👍1
axic commented

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)

  • 👍4
Daft-Wullie commented

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

shamatar commented

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
  • 👍2
sorpaas commented

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

sorpaas commented

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 (ethereum/EIPs#2200 (comment)).
timbeiko commented

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

holiman commented

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

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

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

holiman commented

Some numbers relating to SLOAD and LOG topics

750 for a log with 1 topic. 800 for SLOAD means 1550 (plus some gas per byte in log data)
1125 for log with 2 topics, with one SLOAD becomes 1925 (plus some gas per byte in log data)
2300 for log with 3 topics and one SLOAD

timbeiko commented

Closed in favor of #121