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 63 Agenda #102

Closed
lrettig opened this issue May 24, 2019 · 20 comments

Comments

Projects
None yet
@lrettig
Copy link
Member

commented May 24, 2019

Ethereum Core Devs Meeting 63 Agenda

Agenda

  1. Review previous decisions made and action items
  2. EIPs
    a) EIP 1962: EIP 1679: Hardfork Meta: Istanbul
    See also the dependency map by James Hancock
    b) EIP 1872: Ethereum Network Upgrade Windows
    c) EIP 1109: PRECOMPILEDCALL opcode (Remove CALL costs for precompiled contracts)
    d) EIP 695 (Felix Thing)
  3. Working Group Updates
  4. Testing Updates
  5. 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
  6. EWASM & Research Updates (only if they are posted in the comments below)
@shamatar

This comment has been minimized.

Copy link

commented May 29, 2019

Following Gitter discussion about introduction of various EIPs, I can present the progress and rationale of EIP1962 on one of the next calls

@shemnon

This comment has been minimized.

Copy link
Contributor

commented May 29, 2019

Can we have a second discussion on the calendaring of network upgrade windows? EIP-1872 - This impacts the scheduling of this and future network upgrades, so I think some consensus if it is a good idea or not would be helpful.

@carver

This comment has been minimized.

Copy link

commented May 29, 2019

Can we have a second discussion on the calendaring of network upgrade windows? EIP-1872 - This impacts the scheduling of this and future network upgrades, so I think some consensus if it is a good idea or not would be helpful.

We talked about this for a while, if I remember correctly, and didn't get any meaningful opposition. Do we really need to re-hash it?

Side note: the 1872 eth-magicians link is busted:

Oops! That page doesn’t exist or is private.

@shemnon

This comment has been minimized.

Copy link
Contributor

commented May 30, 2019

What I was going to do was move it into last call but I wanted to make sure that all concerned parties were on-board with the notion. Hudson briefly mentioned the idea of pulling the deployment of Istanbul up a few weeks, which indicates to me it's not a widely accepted notion yet. A short "bring out your objections" and "this is what it means" discussion followed by a movement into last call so it gets accepted was what I had in mind for it.

@carver

This comment has been minimized.

Copy link

commented May 31, 2019

Fair enough. Reviewing it in the context of a shifted devcon makes sense. 👍

@lrettig

This comment has been minimized.

Copy link
Member Author

commented Jun 1, 2019

Heads up that this call overlaps with the “Scaling Ethereum” event happening in Toronto — it looks like on Friday the event will cover layer one stuff so some folks including the Ewasm team may be unable to join the core devs call. Not sure if anyone else is impacted. Event schedule is here: https://medium.com/scaling-ethereum/scaling-ethereum-workshop-agenda-b4e1b1046790.

@and-it-gets-everywhere

This comment has been minimized.

Copy link

commented Jun 2, 2019

For those interested in how the proposed EIPs for Istanbul interact, check out the wiki:

https://en.ethereum.wiki/roadmap/istanbul

If you would like to see a particular EIP get through, there will be an opportunity to talk through the EIPs on a theme-by-theme basis on gitter during the week. Check out the wiki for which day your EIP is in the spotlight.

The aim is to be able to clarify any issues and coordinate conflicting EIPs ahead of meeting 63!

@MadeofTin

This comment has been minimized.

Copy link

commented Jun 3, 2019

I talked with Jordi Baylina. He wants to Discuss EIP-1109 on ACDs this Friday. Can we add him on the schedule?

@fjl

This comment has been minimized.

Copy link

commented Jun 11, 2019

I'd like to get consensus about a minor RPC spec change regarding transaction R, S signature values.
Clients currently encode these as QUANTITY, but the spec says DATA. We found this inconsistency because go-ethereum's ethclient didn't cooperate with ganache, which returns them as DATA.

The spec should change because these values are numbers everywhere.

@fjl

This comment has been minimized.

Copy link

commented Jun 11, 2019

Somewhat related: EIP-695 (eth_chainId RPC method) should be formally Accepted. Parity has it, Infura has it, Geth will have it in v1.9.0.

@carver

This comment has been minimized.

Copy link

commented Jun 11, 2019

The spec should change because these values are numbers everywhere.

👍 for updating the spec to consider r and s as a QUANTITY. Rationale:

  • They are encoded as integers in transactions (rather than as 32-byte fields)
  • The natural representation of each is an integer, based on the math that they are derived from
  • They are already implemented as QUANTITY in major clients
@timbeiko

This comment has been minimized.

Copy link

commented Jun 17, 2019

FYI the roadmap link is broken because the wiki was updated. The new one should be https://eth.wiki/roadmap/istanbul

@shamatar

This comment has been minimized.

Copy link

commented Jun 18, 2019

I'd participate in a dev call this Friday (21st), but due to partially overlapping flight can the part of discussion regarding EIP1962 moved to the beginning of the call?

@holgerd77

This comment has been minimized.

Copy link

commented Jun 19, 2019

Some Istanbul related news from the EthereumJS team: we have now our first TypeScript based release v4 out (as beta).

This release starts the integration process of Istanbul. The hardfork option is now enabled (not active) and we did some first implementation of the draft EIP-1108 on alt_bn128 gas cost reductions to get a start (which might also serve as a reference implementation if desired, we also have added some basic tests, should otherwise be well tested on the update of the official test suite).

All credits here go to @s1na for his fabulous work. 😄

@Souptacular

This comment has been minimized.

Copy link
Member

commented Jun 21, 2019

I'd participate in a dev call this Friday (21st), but due to partially overlapping flight can the part of discussion regarding EIP1962 moved to the beginning of the call?

Yes it can!

@Souptacular

This comment has been minimized.

Copy link
Member

commented Jun 21, 2019

I believe I have addressed all of the above issues by adding the to the agenda.

@MadeofTin

This comment has been minimized.

Copy link

commented Jun 21, 2019

Add a quick update on Blake2B by Matt Luongo please

@shamatar

This comment has been minimized.

Copy link

commented Jun 21, 2019

Totally messed up with a time, 2pm UTC is one hour later on my local and I’ll not be able to participate too. I hope Kobi Gurkan will join the call, he is working on a python implementation.

On my side and progress I can add the following:

  • everything that was in scope for an original EIP is implemented and now will undergo testing and gas schedule metering
  • fuzzy testing is desired, but I’m not sure that it will be done on a code before August
  • performance of Rust implementation is better than current BN precompile if one neglects a one-time cost of some precomputations. Most likely pairings prices will be like high base price for a call that covers some precomputations and final exponentiation, with quite small additions per points pair
    -ABI is drafted
  • scope is also extended to support additions, multiplications and multiexps in G2 for pairing friendly curves
  • set of curves will be BLS12, BN, MNT4/6 and Cocks-Pinch generated ones (Ate pairings) for k=6 for now
  • I make Rust implementation, most likely python one will be also available for a cross-check. Sage scripts are most likely to be made too. There is no-one yet who expressed a will to make a Go/C++ one
  • Difficulty/Performance of Go implementation is questionable with no genetics
  • C++ is “trivial”
  • Rust code will be computable as a single file library
  • I didn’t look into problem of CGo yet, but looks like there are assembly tricks to overcome an inefficiency
  • If I’ve missed something please post questions to Gitter chat
@tvanepps

This comment has been minimized.

Copy link

commented Jun 21, 2019

@Souptacular maybe we can consider moving the next Call time as a test? to accommodate Nick and other time zones

@lrettig

This comment has been minimized.

Copy link
Member Author

commented Jun 25, 2019

Closing in favor of #107

@lrettig lrettig closed this Jun 25, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.