ethereum/pm

Ethereum Core Devs Meeting 60 Agenda

lrettig opened this issue · 14 comments

lrettig commented

Ethereum Core Devs Meeting 60 Agenda

Agenda

  1. Review previous decisions made and action items
  2. Roadmap
  3. Roadmap post Istanbul (@shemmon)
  4. EIPs
    a) Refer to Roadmap link for list
    b) Please add more EIPs to the agenda
  5. Proposal of a formal process of selection of EIPs for hardforks: GitHub EIP Draft, EthMagicians
  6. Overview of Recent Berlin Meetings (click here for overview)
  7. Working Group Updates
    a) State Fees
    b) EWasm
    c) Pruning/Sync (ETH V64 Call for Proposals & Stopgaps for cleaning up discovery peers pre-Discovery v5)
    d) Simulation
    e) New ones?
  8. ProgPoW Audit Update
  9. Would the major clients be satisfied with a single cross-platform C/C++ library for precompiles? Or should EIP champions look for native language libraries when implementing prototypes and opening PRs for clients? (@cdetrio)
  10. Testing Updates
  11. Best way to timebox items?
  12. 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) Nethereum
  13. EWASM & Research Updates (only if they are posted in the comments below)
shemnon commented

Can I get some time to gauge opinions in post Istanbul fork timing? Get a feel if we want a 3, 4, 6, 9, or 12 month cadence? Either as a part of item 2 or item 4f

poojaranjan commented

  1. Roadmap and Istanbul milestone (may be added for reference.)

  2. a) Refer to Roadmap link for list or Istanbul Hardfork EIPs
    b) Please add more EIPs to the agenda or at ECH issue - ref. here and here.

cdetrio commented

In discussions around new proposed precompiles (EIP-1829, EIP-1962), it was suggested that a highly-optimized C/C++ library of crypto functions could be useful as a cross-client implementation for new precompiles. It is well-known that the major clients (geth, parity, etc.) prefer to use libraries written in their native language (go for geth, rust for parity), but there are some exceptions (e.g. libsecp256k1 is a C library used by geth).

Would the major clients be satisfied with a single cross-platform C/C++ library for precompiles? Or should EIP champions look for native language libraries when implementing prototypes and opening PRs for clients?

  • 👍5
bmann commented

+1 on @cdetrio’s question

CoreDevsBerlin overview of all discussions & slides https://en.ethereum.wiki/eth1/coredevsberlin

Summary of ETH1x Working Groups, Infrastructure needs etc. https://en.ethereum.wiki/eth1 - Alexey has more to add ;)

Feedback thread & potential next meeting in late July, including link to summary follow up email https://ethereum-magicians.org/t/coredevs-eth1x-istanbul-meeting-july-poll-feedback/3197

That July meeting would be post major client implementations / pre testnet, and also roughly 9 months before an April 2020 hardfork that has yet to be agreed to if we do Istanbul +6 months.

None of this necessarily needs discussion, just reference & announcement. Feedback on desire for a late July meeting welcomed.

  • 👍2
Souptacular commented

Updated agenda with comments.

winsvega commented

Testing updates: retesteth is ready for integration with any volunteer client.

Looking to hire more people to help with the test development. Exchange experience with other test framework development. (Zak Cole)

Will focus on testeth optimization now.

  • 👍1
  • 🎉2
AlexeyAkhunov commented

Update on the working groups (though I am planning to attend the call):
So far we have 6 working groups, listed here: https://en.ethereum.wiki/eth1

  1. State Rent
  2. Finality Gadget (not formed yet, but expecting very soon)
  3. Generalised precompile for Elliptic Curve arithmetics and pairings (not announced yet, but de-facto active)
  4. eWasm
  5. EVM evolution (not announced yet, but de-facto active)
  6. Fee Market change

Two Working groups that were previously "tracked" are not tracked anymore:

  1. Chain pruning. It has been de-facto inactive. We would like to re-connect with the Swarm team next month to discover if it is possible to re-form this group together with the Swarm team.
  2. Emulation/Simulation. We had presentation from Vanessa at Standford, and Zak at Berlin meeting, which was cool. However, it is not currently clear how to proceed here. More discussions and clarification needed if we were to bring this group back.

Another Working Group is required around Consensus Tests (the work Dmitry is currently doing), but it is not clear yet how this group would be structured, because it is unique in the sense that it addresses a cross-cutting concern, rather than focuses on a specific set of changes in Ethereum.

Regarding Turbo-Geth, still mostly using it for the Stateless Clients prototyping (now "Shades of Statefulness"). But there are plans to move some of the code into another client to allow a larger team to work on it.

holiman commented

@cdetrio I'll paste some comments here from the team, at least Peter won't make it to the meeting, not sure about Felix.

Felix Lange (@fjl):

I'd be happy about it if: it's a C lib with no external dependencies and easy single-file build

Péter Szilágyi (@karalabe):

Crossing Go -> C is expensive
about 20x of a single function call in Go
The Go crypto primitives (cloudflare and co) are blazing fast, because they do low level calls in ASM (because Go is too slow in the tight loop of a crypto lib)
i.e. I'm skeptical, lets see some numbers first
Google's bn256 vs. Cloudflare's AFAIK is just that they moved the function calls into ASM too, and that's an order of magnitude difference

Go is pretty strong on crypto libs though. Are we sure these are not already implemented by someone ? Google/Cloudflare?

  • 👍1
Matthalp-zz commented

I will be attending the meeting to listen but unable to speak.

ETH V64 was presented at the 1.X meeting without much commentary. After touching base with and getting updates on the sync progress, I think it's best to wait until these mature before locking anything in. I will aim to get EIP drafts out before the next Core Devs call and continue to track sync progress.

  • 👍1
FrankSzendzielarz commented

Just a quick note to the client list that the .NET implementation is Nethermind whereas Nethereum is a toolkit for .NET devs to connect to Ethereum networks.

axic commented

Some EIPs I'd like to propose for Istanbul:

Would be nice to be considered:

I also have a few other EIPs being drafted I'd like to propose, but they are not ready yet.

  • 👍1
axic commented

Created a dedicated Istanbul thread https://ethereum-magicians.org/t/hardfork-meta-istanbul-discussion/3207

And added it as the discussions-to URL for the hardfork meta: ethereum/EIPs#1969

I couldn’t find an already existing dedicated thread on the forum for this purpose, but please let me know if I’ve missed one. There are at least 3 threads on organising meetings and another 3 discussing the process of hard forks.

lrettig commented

Closing in favor of #97

shamatar commented

@holiman

Felix Lange (@fjl):

I'd be happy about it if: it's a C lib with no external dependencies and easy single-file build

I'm implementing a Rust library that can be built into single static library with a simple header file and 1 function.

Péter Szilágyi (@karalabe):

Crossing Go -> C is expensive
about 20x of a single function call in Go
The Go crypto primitives (cloudflare and co) are blazing fast, because they do low level calls in ASM (because Go is too slow in the tight loop of a crypto lib)
i.e. I'm skeptical, lets see some numbers first
Google's bn256 vs. Cloudflare's AFAIK is just that they moved the function calls into ASM too, and that's an order of magnitude difference
Go is pretty strong on crypto libs though. Are we sure these are not already implemented by someone ? Google/Cloudflare?

Yes, I'm aware of this problem and there are two options for this:

  • Sacrifice the efficiency
  • There is a trick of making Go to call external C library without such overhead using some assembly.

Benchmarks will show if overhead is comparable to execution time or not, but in the worst case the second approach can be taken.