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 60 Agenda #95

Closed
lrettig opened this issue Apr 19, 2019 · 14 comments
Closed

Ethereum Core Devs Meeting 60 Agenda #95

lrettig opened this issue Apr 19, 2019 · 14 comments

Comments

@lrettig
Copy link
Contributor

lrettig commented Apr 19, 2019

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

shemnon commented Apr 24, 2019

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

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

cdetrio commented Apr 26, 2019

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?

@bmann
Copy link

bmann commented Apr 26, 2019

+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.

@Souptacular
Copy link
Contributor

Updated agenda with comments.

@winsvega
Copy link

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.

@AlexeyAkhunov
Copy link
Contributor

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

holiman commented Apr 26, 2019

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

@Matthalp-zz
Copy link

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.

@FrankSzendzielarz
Copy link
Member

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

axic commented Apr 26, 2019

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.

@axic
Copy link
Member

axic commented Apr 26, 2019

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

lrettig commented Apr 27, 2019

Closing in favor of #97

@shamatar
Copy link

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

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