Twitter | Search | |
This is the legacy version of twitter.com. We will be shutting it down on 15 December 2020. Please switch to a supported browser or device. You can see a list of supported browsers in our Help Center.
Tim Beiko | timbeiko.eth Feb 21
Replying to @ethereum
There are over 20 comments on the agenda... so I think we'll have a *lot* to cover. This is going to be pretty packed!
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Replying to @ethereum
And we're on! First item was Open RPC because we had to skip it last time due to time, but it seems like no one is on the call to discuss 😕
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Replying to @ethereum @JHancock
Next up are EIPs! We're trying to focus on the EIPs that have a chance to make it for . says there are a few EIPs that seem ready-ish to go in, and that the Eth2 deposit contract will probably require a new BLS precompile.
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Replying to @shemnon
The EIPs that seem ready-ish are: * EIP-2135 (EVM changes) * EIP-1962 (Crypto precopiles) (and the alternative one with only the Eth2 curve) * 's EIP to move to time-based upgrades (can't find the #) * EIP-2515 (Difficulty bomb changes)
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
. and highlight that all of these still require a lot of implementation work. We don't want to end up in a spot where we delay an entire upgrade again because of one EIP lagging behind.
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Replying to @shemnon @mhswende and 3 others
In terms of timeline, we probably want to align with the launch of the Eth2 deposit contract (June? July? ? ?). This way, we can have the new curves working for the deposit contract.
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Replying to @shemnon @mhswende and 3 others
Now discussing 's EVM EIP (). He's giving a TL;DR of the various new opcodes on the call. Worth watching the stream for the full description :-)
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Replying to @shemnon @mhswende and 4 others
. says it would be nice to "hack solidity" to try and benchmark the improvements from the EIPs. It would be nice to confirm that the new EVM subroutines actually make things faster before shipping 😅
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Replying to @shemnon @mhswende and 4 others
It seems like there are no objections to the EIP, as long as we get the solidity benchmarks 👍🏻
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Replying to @shemnon @mhswende and 6 others
Now onto EIP-2456 (which to move from block-based to time-based upgrades). had a concern that going back 1000 blocks to check the timestamp trigger was too much for light clients. posted a proposal to use 10 blocks on :
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Replying to @shemnon @mhswende and 6 others
says he'd like to see some more test work done (i.e. some reference tests, some "fake transitions" before we roll it out on test nets, etc.).
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Replying to @shemnon @mhswende and 9 others
We're going back a bit and confirming whether all the client teams are OK with EIP-2315. asks if the team will support the Berlin hard fork for Open Ethereum/Parity-Ethereum. says they will 👍🏻
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Replying to @shemnon @mhswende and 9 others
So, no objections to EIP-2315. Moving to EFI ✅
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Replying to @shemnon @mhswende and 9 others
For EIP-2456, we want to address the recent comments on EthMagicians before moving it to EFI. Here's the link again: We'll try and get this done in the next two weeks!
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Replying to @shemnon @mhswende and 9 others
Next up, we have EIP-2515, which is meant to address the difficulty bomb. The general idea is to have a block at which the difficulty freezes, and after that the difficulty increases at a constant rate. See the thread:
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
. is going into the details of how the difficulty bomb works and what went wrong calculating when it would go off last time. Worth watching the livestream for the nuance.
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
The crux of the challenge is that the farther away we are from the bomb, the more uncertainty there is in the estimation. This would help make it easy to estimate when the bomb goes off. As an aside now has a nice graph estimator:
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
I had a couple questions about how freezing the difficulty would interact with having more/less miners on the network after the bomb. Martin also had a few questions about why we don't couple the linear increase with the difficulty adjustment. Again ➡️ Livestream for Nuance
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Next EIP is 1962. On the last call we discussed wanting to get experts feedback on it: We have two! Zac from says this EIP would help "future-proof" Ethereum, and make it easier to do rollups and s(t/n)arks
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
In the zoom chat, Duscan from EY's blockchain gives a +1 to what Zac says. Zac also adds that this is a complicated EIP and would require a lot of testing, but there isn't fundamentally new cryptography introduced by this EIP.
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
says he would like to see a thorough review from the Coda/EY teams of the EIP. Aztec seems happy to this. OTOH, is still opposed: he thinks the EIP is too broad, and it's almost like adding a black box VM on Ethereum
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
A few concerns are: * the crypto correctness * the size of the codebases (even if the crypto is right, the implementations may have bugs) * the go implementation had a simple bug fixed only 12 days ago. If this went into production, it could have caused a chain split
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Alex from is going into a lot of details on the call about why the generalized precompile makes sense. It's pretty thorough, so hard to summarize on here (Livestream 😄).
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Tangentially related, here's a quick update from Greg re: the Eth2 Deposit Contract:
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Alex understands the concerns, and asks what would be the chance to get, say, 6-8 specific precompiles rather than the generalized precompile.
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
And we're still discussing this, mostly in "disaster prevention" mode. The implementations are each ~20k lines of code, so the geth team is concerned about "who will fix a consensus bug at 4am if/when it happens?". and say they would 💪🏻
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
More conversation on the time we should take to test this, whether we should have a bug bounty on it, how do we test complex EIPs in general (1559, UNGAS, etc.). Once more, the livestream has (over 20 minutes!) of nuance 😅
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Parity is "slightly against it" due to the complexity.
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
Note: this is the draft BLS-only Eth2 curve "pre-EIP" proposal:
Reply Retweet Like
Tim Beiko | timbeiko.eth Feb 21
On one last note about 1962, Felix from Geth adds that Ethereum has been good about "slowly expanding its complexity" and that we should focus on what are the incremental things we need, implement them, and then go to the next thing.
Reply Retweet Like