Thread by @TimBeiko

We had our last @ethereum #AllCoreDevs of 2021 today 📆! This was IMO one of the most interesting calls of the year, and recommend people interested in the tradeoffs of Ethereum governance watch the entire thing 🎥

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

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

@ethereum First on the call, we discussed the Arrow Glacier upgrade from yesterday. Things went smoothly! Two miners, @HuobiGlobal and @OKEx hadn't upgraded. Now, it seems they have, as they've mined blocks on the main chain:

Huobi: etherscan.io/block/13777482
OKEx: etherscan.io/block/13776941

@ethereum @HuobiGlobal @OKEx Then, we discussed progress on the Kintsugi 🍵 merge devnets. The 4th devnet, devnet-3, was launched this week. While there was chaos at first, it's now stable and even @vdWijden's fuzzer didn't take it down!

@ethereum @HuobiGlobal @OKEx @vdWijden There were also some issues around CL clients proposing empty blocks right after the merge that we'll be looking into. That said, we're still on track to have a longer lived devnet out next week! It will stay up throughout the holidays to give people/teams time to experiment!

@ethereum @HuobiGlobal @OKEx @vdWijden Once it's live, we'll also attempt to shadow-fork Goerli and replay transactions from that testnet on it 👻

@ethereum @HuobiGlobal @OKEx @vdWijden Keep an eye out for announcement late next week / early the one after!

@ethereum @HuobiGlobal @OKEx @vdWijden Devnets aside, it seems the main things to get done for the merge are finalizing the spec + implementations for optimistic sync, resolving some fork-choice rule issues for competing terminal PoW blocks, adding a EL <> CL authentication mechanism, and a lot of testing!

@ethereum @HuobiGlobal @OKEx @vdWijden There's also a small addition to the engine API that's been proposed by @mkalinin2: a getPayloadBodies method, which is analogous to today's getBlockBody call: github.com/ethereum/execu…

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 Then, we discussed EIP-4488. For some background, I wrote about it last week: tim.mirror.xyz/3pbg3_DnCqF10F…

TL;DR: it proposes to reduce rollup txn costs, at the cost of more chain history growth. It was proposed to potentially deploy this change before The Merge.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 Again, this is the part of the call I strongly recommend people watch for the full context/deliberations. This will only be a brief summary. Starts at ~18 min in the recording 👀

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 First, on the previous ACD, we had discussed how 4488 could make creating an optimal block more complicated because it makes block creation go from a 1-D (gas) to 2-D (gas, calldata cap) optimization problem.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs looked at whether you could keep similar efficiency with small changes to the current txn pool sorting algorithms, and it seems you can. His full writeup is available here: hackmd.io/@adietrichs/44…

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs He compares three approaches: a naive strategy, a "backlog" one, and an optimal one:

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs He finds that, with a calldata stipend of >164 bytes, the backlog strategy, which is simple to implement, gives blocks that are >99% as profitable as an optimal sort. This means 4488 wouldn't put block producers who use "out of the box" algorithms at a significant disadvantage.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs That said, there were objections to the EIP beyond that. The @go_ethereum team took time to articulate theirs in writing: notes.ethereum.org/EH_xVCD8SnaLCE…

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum We didn't cover them in the exact order on the call (which, once more, I urge you to watch!), but I'll summarize the various discussion points as they appear in the doc.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum First, there were concerns about the second-order effects of having transactions with a lot of CALLDATA having to compete with rollups: it's unclear how it would impact the cost of contract deployments, for example.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum Second, the EIP would increase the rate at which Ethereum's historical data grows. It does not try and hide this, and says something like EIP-4444 should be implemented to address this. That said, 4444 is not trivial to implement and is still in early stages of development.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum Third, there are some concerns that rollups today aren't fully trustless: most of them have a small operator set, and/or haven't activated fraud proofs. There's a desire to want to see rollups be more robust before their usage is subsidized further.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum We discussed all of these on the call, and it's worth noting some quick counterarguments.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum For the CALLDATA "competition", it's worth noting that if blocks do become full of rollup settlement txns, this will happen too, but in a more extreme way because we don't have a CALLDATA stipend today.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum For the increase in chain history, it's worth noting that something like 4444 will need to happen 🔜 regardless. Also, with the move to PoS, guarantees about historical data are also going to start to change.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum For the issue of rollups not being ready, it's worth noting that the EIP doesn't mean all traffic automatically moves to rollup, but just helps create additional capacity for it.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum After discussing the EIP itself, we moved to the scheduling of it: while it's clear that fees on Ethereum today are a major issue, the move to proof of stake is also hugely significant, as well as being something we'd already committed to prioritizing.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum On the previous ACD, it was mentioned that 4488 could be done without delaying The Merge, but two teams agreed that if we did it, it would likely push back The Merge by ~1 month at least.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum So, given the lack of overwhealming desire to do this before The Merge, and the need to address more technical issues, we decided to stick with our current plan and prioritize the transition to PoS.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum That said, everyone agreed that 4488 (and 4444!) are important and we should prioritize working on them as soon as possible. Also, that we should involve the broader community into these discussions about what should come first.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum Specifically, there may be a case to push for 4488/4444 aggressively before enabling beacon chain withdrawals, post-merge. Similarly, we could push towards a simple sharding implementation (e.g. step 2 here: notes.ethereum.org/@vbuterin/data…).

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum Client teams, and AllCoreDevs, are best suited to discuss the technical tradeoffs of proposals, but for things like "sharding/4488 vs. withdrawals", it isn't necessarily the group with the most insights into what the community wants.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum In the next few weeks/months, as the work on The Merge wraps up, we'll start discussing the various options for what to prioritize after The Merge. A list of (most) proposed things is available here: github.com/ethereum/pm/is…

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum Lastly, with the call nearing completion, we briefly touched on the subject of historical data guarantees post-merge. 4444 covers this a bit, but over time, it's unsustainable for every node to serve the entire Ethereum history over the p2p network.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum PoS already takes a small step in that direction with weak subjectivity checkpoints, but in general the idea that a node can get any historical data from its peer beyond a certain time won't be sustainable long term.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum To transition away from this (e.g. with EIP-4444), we need to develop better mechanisms for historical data retrieval + distribution, but it will also require some applications to change the assumptions they make about always being able to access that data.

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum This seems like the next "big conversation" we'll need to have once we've moved to proof of stake! If you are an application developer, it's worth starting to think about how things change if you can't get historical data over p2p (but can import it from another source) 🧠

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum And that was it! Last call of 2021 wrapped up. One final comment I made at the end was that this call was a really good instance of civil disagreements on ACD and it was nice to see everyone be respectful despite their strong opinions 😁

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum That's it for me - expect an announcement for the Kintsugi devnet 🔜, and see you at the next ACD, on Jan 7th, 2022, 14:00 UTC 👋🏻

@ethereum @HuobiGlobal @OKEx @vdWijden @mkalinin2 @adietrichs @go_ethereum People saying the second tweet in the thread is broken for them. Here's what it was:

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