Ethereum Core Devs Meeting 63 Agenda
lrettig opened this issue · 20 comments
Ethereum Core Devs Meeting 63 Agenda
- Meeting Date/Time:
Friday 7 June 2019Friday 21 June 2019 at 14:00 UTC - Meeting Duration 1.5 hours
- YouTube Live Stream
- Istanbul Roadmap
Agenda
- Review previous decisions made and action items
- 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) - Working Group Updates
- Testing Updates
- 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 - EWASM & Research Updates (only if they are posted in the comments below)
Following Gitter discussion about introduction of various EIPs, I can present the progress and rationale of EIP1962 on one of the next calls
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.
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.
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.
Fair enough. Reviewing it in the context of a shifted devcon makes sense. 👍
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.
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!
I talked with Jordi Baylina. He wants to Discuss EIP-1109 on ACDs this Friday. Can we add him on the schedule?
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.
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.
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
FYI the roadmap link is broken because the wiki was updated. The new one should be https://eth.wiki/roadmap/istanbul
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?
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. 😄
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!
I believe I have addressed all of the above issues by adding the to the agenda.
Add a quick update on Blake2B by Matt Luongo please
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
@Souptacular maybe we can consider moving the next Call time as a test? to accommodate Nick and other time zones