Thread by @TimBeiko

We just wrapped up #AllCoreDevs 127 🦃

Agenda: github.com/ethereum/pm/is…
Stream:

Recap below 👇🏻

https://twitter.com/TimBeiko/status/1459248048714891267

First things first, Arrow Glacier is happening 🔜

If you still haven't, please upgrade your node 🚨

Client versions available here: blog.ethereum.org/2021/11/10/arr…

Next up we had Kintsugi 🍵 upgrades. A lot of progress on the milestones board: notes.ethereum.org/@djrtwo/kintsu…

@vdWijden gave an update on the past two devnets: he broke devnet 0 by creating conflicting "final" PoW blocks which exceeded the terminal total difficulty. Fixes for this are still being worked on, and might include a way for better manual user intervention in such forks.

@vdWijden He also broke devnet 1, due to a bug in Geth which has been fixed. Luckily, @nethermindeth kept the chain going when Geth was down! Now, the two of them, along with Lodestar, Lighthouse, Teku and Prysm are running on the devnet!

@vdWijden @nethermindeth Also, Geth and Teku got Optimistic Sync working on the devnet 😁 You can read more about that here: hackmd.io/Ic7VpkY3SkKGgY…

@vdWijden @nethermindeth Nethermind has been working on their implementation as well, and have a first sync algorithm working. They plan on improving it + doing several refactors to their merge code in the next few weeks.

@vdWijden @nethermindeth Besu has spec implemented and passes tests, but on a separate branch. They are still working on merging things into master.

@vdWijden @nethermindeth Erigon's implementation is moving along. They had a question about some conflicting info w.r.t. mixHash in EIP-3675 vs. 4399. I ran into the same issue writing a blog post this week and had a PR to 3675 to clarify things 😅 github.com/ethereum/EIPs/…

TL;DR: 4399 applied over 3675.

@vdWijden @nethermindeth @parithosh_j, the mastermind behind the devnet devops, has set up a faucet and explorers for devnet1, see:

EL: explorer.merge-devnet-1.wenmerge.dev
CL: …aconchain.merge-devnet-1.wenmerge.dev

@vdWijden @nethermindeth @parithosh_j Lastly, @mkalinin2 had a couple spec issues he wanted to discuss. The first had to do with message ordering in the Engine API. See the context here: github.com/ethereum/execu…

@vdWijden @nethermindeth @parithosh_j @mkalinin2 The second was a proposal to add an engine_getBlockBodies method, which would help with CL-level pruning. EL teams on the call said adding this is trivial, so we agreed to it. CL clients may not use it _right_ at the merge, but they'll have the option to. github.com/ethereum/execu…

@vdWijden @nethermindeth @parithosh_j @mkalinin2 Oops, one more thing about The Merge: we'll have devnets 2 & 3 next week and on Dec 7. Aiming to have a final devnet on Dec 14th which should be on a stable version of the spec! Probably won't be merged in master in all clients, but should be easy to run on a branch w/ a CLI flag

@vdWijden @nethermindeth @parithosh_j @mkalinin2 Next up on the call, and basically up to the end, we had a conversation about lowering the costs of rollups and how that fits in the current Ethereum roadmap. It's worth sharing some context here!

@vdWijden @nethermindeth @parithosh_j @mkalinin2 The cost of rollup txns is a function of the data they post back to the Ethereum mainnet. If a rollup compresses X transactions and pays Y gas fees to commit it to mainnet, the cost of rollup transactions is a function of Y/X.

@vdWijden @nethermindeth @parithosh_j @mkalinin2 To do this, rollups add CALLDATA to their transactions, which is currently priced at 16 gas per byte. If we reduce the CALLDATA cost, then we reduce the cost of rollup transactions. Here's a much longer (& better!) explanation: reddit.com/r/ethfinance/c…

@vdWijden @nethermindeth @parithosh_j @mkalinin2 One challenge is that CALLDATA directly influences the block sizes on Ethereum: it's literally data we add to each transaction. If we lower the gas cost, and keep the same gas limit, we then have bigger blocks, which can be problematic in the short and long term.

@vdWijden @nethermindeth @parithosh_j @mkalinin2 Short term, it increases the worst case block size. If, for example, CALLDATA was 1 gas/byte, with a 30m gas block, you'd get a 30MB block (average right now is <0.1MB). Current "worst case" block with CALLDATA would be 30m gas / 16 gas/byte = ~1.9 MB

@vdWijden @nethermindeth @parithosh_j @mkalinin2 Long term, it increases the size of the Ethereum blockchain. If we go from adding 0.1MB of chaindata per block to even 0.5MB, that's a 5x increase in the rate of chain growth.

@vdWijden @nethermindeth @parithosh_j @mkalinin2 That said, fees on Ethereum are *high* and also aren't trivial on rollups today (~3-4$ for a ETH send on ORs and ~0.25c on ZKRs), so it's worth thinking about the tradeoff more... and people have!

@vdWijden @nethermindeth @parithosh_j @mkalinin2 Two separate weeks were proposed in the past few weeks proposing to reduce the CALLDATA costs: EIP-4488 (github.com/ethereum/EIPs/…) and EIP-4490 (github.com/ethereum/EIPs/…). The latter is a bit simpler, so worth explaining first.

@vdWijden @nethermindeth @parithosh_j @mkalinin2 4490, by @GuthL and @PhABCD, simply proposes to reduce the CALLDATA cost from 16 to 6 gas per byte, a value that was proposed earlier in the context of a migration to Verkle Tries in the future.

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD This would be a "one line change", but comes at the cost of having worst case blocks of 5MB.

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD This is where 4488 (by @VitalikButerin and @adietrichs) comes in: it proposes to lower the cost even lower, from 16 to 3 gas per byte (vs. 6 in 4490), but to add a cap to the amount of CALLDATA in each block, to bound the block size.

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs (One more complexity: 4488 has a concept of "stipend" for non-rollup transactions which use just a bit of CALLDATA and hence "ignores" those, the EIP explains it well!)

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs With this context, there are two questions: which, if any, of these to do, and when? Also, how to deal with the long-term concerns?

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs There was a ton of discussion about this on the call, so I strongly recommend watching the livestream for all the nuance! I'll try and summarize the conclusions.

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs First, we discussed how 4488 would impact block production. It complicates things slightly because it adds a validity check to a block (can't have CALLDATA > limit), and there were some concerns about miners potentially abusing the stipend.

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs Those concerns seem manageable, but we need to think through them more.

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs Second, we discussed the long-term storage implications. We had discussed this at length on the last ACD, with the introduction of EIP-4444: eips.ethereum.org/EIPS/eip-4444

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs Generally, if we are to lower the CALLDATA cost, we need to commit to doing something like 4444 "soon", or in the 1-1.5 year after the cost reduction. The challenge is this, like any change affecting historical data, has a lot of impact on tooling and applications.

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs At the same time, something like 4444 needs to happen regardless if we want to make Ethereum long-term sustainable. With the introduction of finality post-merge, this is a good time to revisit these assumptions!

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs Then, there is the question of "when" we could do this! Over the past few months, we've wanted to keep our focus on the merge to get that out ASAP. That said, it means that any changes "after the merge" would only happen in late 2022. That seems far away...!

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs A few people highlighted that our attendees on ACD are somewhat biased and we don't have "users" show up on the call. If they did, they'd obviously push for this to happen much sooner than that!

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs So, if we want to do this "not after the merge", there is the option of either adding thing alongside the merge, or to do it before. From a technical PoV, everyone agreed separating this from the merge would make both easier to ship.

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs Also, the amount of work here is fairly small: change a gas price, add a validity check and (hardest!) implement a new txn pool sorting algorithm.

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs If we do want to ship this before the merge, though, we need to act fast: the fork would have to hit mainnet in February at the latest, and we only have one more ACD before the end of this year!

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs So we agreed to give it a try and see if it's possible!

Because the work on the client side is minimal and parallelizable to the merge work, we think this _might_ work!

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs Over the next two weeks, we'll try and get prototypes done in most clients (there's already a Geth implementation by the Quilt team: github.com/quilt/go-ether…) and analyze how we could up with better txn pool sorting algorithms.

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs We were basically at time at that point, but that's roughly the next step: see if we can prototype this and, if so, hopefully make a call in the next 1-2 ACD about whether to ship this pre-merge! In parallel, think about the "commitments" we can make w.r.t. EIP-4444.

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs So, to summarize: there is desire to try and do this by most client teams, we don't think it would really delay the merge, but it's also still very much not a certainty.

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs We had two quick announcements at the end of the call. First, the @EthereumFilm team came to shared that they are working on the Ethereum documentary and will probably be reaching out to several folks on ADD in the next couple months 🎥

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs @EthereumFilm Second, we have a second Merge community call next week, Friday 14:00 UTC. More on that here 👇🏻

https://twitter.com/trent_vanepps/status/1463561106811764741

@vdWijden @nethermindeth @parithosh_j @mkalinin2 @GuthL @PhABCD @VitalikButerin @adietrichs @EthereumFilm And that was it! Next call, again, the last of 2021!, is scheduled for December 10th, 14:00 UTC. See you then 👋🏻