Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ethereum Core Devs Meeting 68 Agenda #119

Closed
timbeiko opened this issue Aug 5, 2019 · 16 comments
Closed

Ethereum Core Devs Meeting 68 Agenda #119

timbeiko opened this issue Aug 5, 2019 · 16 comments

Comments

@timbeiko
Copy link
Collaborator

timbeiko commented Aug 5, 2019

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
Copy link
Member

karalabe commented Aug 7, 2019

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

@timbeiko
Copy link
Collaborator Author

timbeiko commented Aug 7, 2019

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

@gumb0
Copy link
Member

gumb0 commented Aug 7, 2019

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

@axic
Copy link
Member

axic commented Aug 11, 2019

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
Copy link

carver commented Aug 12, 2019

@Daft-Wullie
Copy link

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

@shamatar
Copy link

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
Copy link
Contributor

sorpaas commented Aug 15, 2019

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

@sorpaas
Copy link
Contributor

sorpaas commented Aug 15, 2019

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
Copy link
Collaborator Author

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

@holiman
Copy link

holiman commented Aug 15, 2019

@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
Copy link
Member

chfast commented Aug 15, 2019

@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
Copy link

holiman commented Aug 15, 2019

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
Copy link

@holiman
Copy link

holiman commented Aug 15, 2019

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
Copy link
Collaborator Author

Closed in favor of #121

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests