Another @ethereum #AllCoreDevs wrapped up this morning. Deep dives into The Merge & Shanghai, one of my favorite calls in a while π Def recommend the full recording as the signal/noise ratio was very high. If you don't have 90 mins, here's a recap!
https://twitter.com/TimBeiko/status/1484618403436396546
@ethereum First on the call, we went over @parithosh_j's report of the bugs found on Kintsugi: notes.ethereum.org/@ExXcnR0-SJGthβ¦
We've covered these issues on previous calls, and fixed them in the latest spec, Kiln, but the report gives a great overview of what happened and the impacts it had π
We've covered these issues on previous calls, and fixed them in the latest spec, Kiln, but the report gives a great overview of what happened and the impacts it had π
@ethereum @parithosh_j There's even an FAQ section that covers impacts on validators, merge timelines, and best practices for dealing with non-finalization. 
@ethereum @parithosh_j Next up on the call, we covered the newest merge testnet spec: Kiln π₯𧱠hackmd.io/@n0ble/kiln-spβ¦
@ethereum @parithosh_j The main changes in Kiln address the issues we found on Kintsugi: fixes for Optimistic Sync on the CL side, changing the semantics (and name) of `executePayload` to better handle re-orgs, and other smaller changes.
@ethereum @parithosh_j Clients have started implementing the changes, and @vdWijden & @lightclients are already working on new test vectors for the changes πͺπ»
@ethereum @parithosh_j @vdWijden @lightclients Two more changes will be added to the Kiln spec next week to make it feature-complete: an authorization mechanism between the EL/CL nodes and a check between EL/CL to ensure both clients are merge-compatible. The PRs:
github.com/ethereum/execuβ¦
github.com/ethereum/execuβ¦
github.com/ethereum/execuβ¦
github.com/ethereum/execuβ¦
@ethereum @parithosh_j @vdWijden @lightclients Late next week, we're hoping to stand up the first round of Kiln devnets with clients who are ready. In the weeks after, we'll run through it a few more times before having a final release, which we expect to be long-lived.
@ethereum @parithosh_j @vdWijden @lightclients π¨ Applications, Tools, Infra Providers, consider Kiln a dress rehearsal before testnets! π¨
If nothing major goes wrong, Kiln is the latest testnet we will deploy before forking the existing ones (Goerli, Ropsten, etc.). Now's the time to make sure things work as expected!
If nothing major goes wrong, Kiln is the latest testnet we will deploy before forking the existing ones (Goerli, Ropsten, etc.). Now's the time to make sure things work as expected!
@ethereum @parithosh_j @vdWijden @lightclients On that note, the next topic was how to handle tesnets post-merge. We didn't dwell on this too long, but @peter_szilagyi's recent take seems broadly right:
https://twitter.com/peter_szilagyi/status/1484548996169408512
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi TL;DR: Goerli seems most "future-proof" right now, if you are deploying applications, and Ropsten/Rinkeby the likeliest to be shut down close to the merge. Again, this is the time to start migrating if you are using Ropsten/Rinkeby.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi We then discussed Shanghai π¨π³ On the last ACD there was a soft consensus to want to mark a few EVM-related EIPs as "considered for inclusion" for it. This roughly means "we'll deploy them on devnets and if nothing changes or goes wrong, they'll likely be in the next fork"
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi Sensing that the Shanghai gates were open, hoards of EIP champions came in with their proposals on today's call π
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi Because we are still very early in the process (the merge isn't done yet!), I wanted to be sure we didn't preemptively commit to things before even having started the work, precluding us from doing other, potentially more important, things we just didn't discuss yet.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi So we went over each of the proposals, and I made sure to highlight the stuff that no one had put on the agenda explicitly, and then discussed what the highest priorities were. Recommend the livestream for all the nuance, but I'll summarize below.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi First, @alexberegszaszi explained the various EVM EIPs he and his team proposed, along with their impact/rationale. First, EIP-3860 simply limits the size of INITCODE. It's a small change which adds gas metering to execution which otherwise wasn't charged.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi Another small change is EIP-3855. It adds a PUSH0 opcode which, as you can imagine, pushes 0 onto the execution stack. This is a simple feature which is useful to many use cases where you need to provide 0-padded inputs to the EVM.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi Then, we covered two proposals central to EVM improvements: EIPs 3540 & 3670. 3540 introduces EVM Object Formats, which we set the groundwork for in the London upgrade. This enables the addition of multiple EVM "versions", introducing new features without breaking contracts.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi "How do we upgrade the EVM without breaking everything that's already deployed on it?" has been an applied research question on Ethereum for *years* and @alexberegszaszi & his team have finally come up with a design which everyone is very happy with!
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi Here's an @EthMagicians thread with some history on the topic, if you want to go down a rabbithole π³ ethereum-magicians.org/t/ethereum-accβ¦
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians The companion EIP that @alexberegszaszi presented was EIP-3670, which introduces code validation for EOF contracts. This makes it easier to reason about bytecode and can lead to more efficient EVM implementations.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians Alex had two more EIPs, both of which leverage 3540: EIP 4200, which introduces static relative jumps in the EVM, and EIP 4750, which introduces function selection in 3540-compatible contracts' bytecode.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians Finally in the EVM bucket, @greg_colvin had two EIPs he discussed: 2315, which introduces subroutines and was previously slated for inclusion before being removed late in the upgrade process, and 3779, which adds safer control flow in the EVM.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin Next on the list was @lightclients with EIP-3074. He shared that some minor changes have been considered to the EIP, but broadly the proposal stays the same.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin There were questions about how this differed from the recent account abstraction via the mempool EIP (4337). TL;DR: 3074 helps with existing EOAs, while 4337 is mostly useful for new accounts. @nethermindeth has a longer post on this: medium.com/nethermind-ethβ¦
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth One thing to note about 4337 is that it does not require consensus changes, and hence can be adopted independently of the network upgrade process.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth After @lightclients, @VitalikButerin had two proposals he shared about how we could reduce transaction costs on rollups. Both introduce a new transaction type which contains a blob of data, a bit like a "mini chunk of shard data".
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin The first approach makes only the minimum amount of changes for this to be supported by EL clients: notes.ethereum.org/@vbuterin/blobβ¦
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin The second approach builds on the first, and adds more "plumbing" work to get us closer to something that will be compatible with full sharding: notes.ethereum.org/@vbuterin/blobβ¦
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin If neither of these can make it in, he said he would really want to see a CALLDATA cost reduction, such as EIP-4488, so we can at least provide short term relief for L2 fees.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda, @adietrichs and a few others said they might try and prototype the blob-data transactions proposals during @EthereumDenver to get a feel for the complexity!
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver After Vitalik, @dankrad had a few proposals which could help lay the groundwork for statelessness. Two of them involve neutering SELFDESTRUCT, which is incompatible with the state tree format we want to move to for stateless.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad The first is straightforward: simply deactivate the opcode: github.com/ethereum/EIPs/β¦
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad The second, based on the premise that "no one pays attention to the roadmap until it's on mainnet", would introduce a sort of difficulty bomb for the opcode's gas cost: github.com/ethereum/EIPs/β¦
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad This would exponentially increase the cost of the operation, so people would notice that their contracts are becoming more expensive to use, and have more time to migrate once the EIP is live on mainnet.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad His last proposal is to update some gas costs to already follow a post-Verkle Trie pricing scheme, so application developers can understand how things change in a stateless world. Highly recommend looking at this now to start getting an idea: github.com/ethereum/EIPs/β¦
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad And that was it for EIP proposals! We did cover a few more. First, @dannyryan mentioned that an EIP for Beacon Chain withdrawals is coming π and gave an overview of how the mechanism is expected to work on the call.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan Then, I highlighted a few other EIPs which didn't have champions on the call to advocate for them:
- EIP-2537: adds a BLS precompile;
- EIP-1153: adds a transient storage opcode, useful for many applications to reduce gas costs;
...
- EIP-2537: adds a BLS precompile;
- EIP-1153: adds a transient storage opcode, useful for many applications to reduce gas costs;
...
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan - EIP-2935: highlighted by @tkstanczak, which could reduce STARK application costs.
And there are a few more proposed beyond that too! See the current list here: github.com/ethereum/pm/isβ¦
And there are a few more proposed beyond that too! See the current list here: github.com/ethereum/pm/isβ¦
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak So... that was quite the list! Again, recommend watching the call for the full overview. Great descriptions of all the potential things coming to Ethereum!
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak Then, I asked client teams what they felt were the highest priorities across everything we discussed. Two things clearly emerged: the first subset of EVM EIPs and the transaction data cost reductions.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak Beacon Chain withdrawals are obviously very important too, but there isn't a spec for them yet.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak So, we decided to move the first set of EVM EIPs to CFI for Shanghai. Specifically, the core EOF EIPs, 3540 and 3670, along with the two small improvements, 3855 and 3860. A spec for Shanghai is now available here: github.com/ethereum/execuβ¦
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak For the blob-transaction proposals, we will prototype them in the next few weeks/months to get a better feel about their implementation complexity, and will discuss on further calls.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak That was a *ton* of EIP to get through (which, back in the day, could have taken us a few months...!) and tbh it was pretty impressive we got to such clear agreement on priorities so quickly. Definitely the highlight of my week!
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak It might not look like it, but we even had 10 minutes to spare after all this at the end of the call! @_SamWilsn_ presented some work that he and his team have been doing to create an executable spec for Ethereum's consensus layer.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak @_SamWilsn_ To give some background, currently, the Ethereum EL spec is an awkward combination of "YellowPaper and a bunch of EIPs applied to it".
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak @_SamWilsn_ Not only is the YP very hard to parse, it also means that complex EIPs are awkward to specify because you sometimes need to "implement" large parts of Ethereum in it to specify what changes.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak @_SamWilsn_ In contrast to this, the beacon chain was built from the start with an executable spec: a code-based specification, which actually runs (albeit very slowly) but is still optimized for readability.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak @_SamWilsn_ This means that changes can be specified with a PR to the spec, and that tests can be automatically generated from it. So, months ago, @_SamWilsn_ and other took on the ambitious task of creating such a spec for the EL, and they've made great progress!
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak @_SamWilsn_ Sam presented the highlights on the call, but you can check it out here: ethereum.github.io/execution-specβ¦
While it's not up to mainnet yet, a few hard forks have already been implemented in it.
While it's not up to mainnet yet, a few hard forks have already been implemented in it.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak @_SamWilsn_ I mean... how cool is this? You can even see the diffs across forks!
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak @_SamWilsn_ This also lays the path to harmonize the upgrade process across the EL + CL! Currently, EL is EIPs only and CL is spec only.
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak @_SamWilsn_ With an executable spec on the EL we could get the best of both worlds: english design, rationale, security consideration in EIPs, with memorable numbers, and implementations directly in executable specs π€―
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak @_SamWilsn_ In case you couldn't tell, I'm very excited about this! It's the type of behind-the-scenes foundational work which has ripple effects across both the technical and social/governance layer, and it's awesome to see it taking shape π
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak @_SamWilsn_ Last on the agenda, we shared the Merge community call scheduled for next week, Friday 14:00 UTC: github.com/ethereum/pm/isβ¦
If you are an application, tooling or infra dev who has questions about The Merge, this is the place to come ask them! See you there ππ»
If you are an application, tooling or infra dev who has questions about The Merge, this is the place to come ask them! See you there ππ»
@ethereum @parithosh_j @vdWijden @lightclients @peter_szilagyi @alexberegszaszi @EthMagicians @greg_colvin @nethermindeth @VitalikButerin @protolambda @adietrichs @EthereumDenver @dankrad @dannyryan @tkstanczak @_SamWilsn_ PS: if you've made it here, thanks for bearing with me on this mega-thread! Longest one in a while...! Next ACD is Feb 18th, 14:00 UTC π
Oops, I meant "execution layer" in this tweet!
h/t @terencechain @_SamWilsn_
https://twitter.com/TimBeiko/status/1489725506391986176
h/t @terencechain @_SamWilsn_
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
γ
