Thread by @TimBeiko

.@ethereum #AllCoreDevs today was packed with Merge & Shanghai updates 👀

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

Recap below 👇🏻

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

@ethereum First on the call, we discussed the latest updates to Kiln: our upcoming merge testnet. @vdWijden has been trying to get all client combinations working and to put together a doc with instructions about how to pair them 📝

@ethereum @vdWijden One thing that wasn't fully aligned yet was client authentication between the EL + CL nodes. We had rough agreement on the call about how to proceed, and will make sure all clients behave similarly. In short, all calls on the auth'd port will require a token.

@ethereum @vdWijden In preparation for Kiln, @parithosh_j launched a fifth devnet earlier this week! The transition hasn't happened on it yet. We expect it by early next week

https://twitter.com/parithosh_j/status/1499351263728779269

@ethereum @vdWijden @parithosh_j Most client teams seem like they will be ready to support Kiln: @nethermindeth, @go_ethereum and @HyperledgerBesu were all on track, with @ErigonEth unsure but hoping they can make it.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth One community request by @vdWijden would be for good tutorials aimed at more novice users to use Kiln! He'd welcome people making more accessible versions of his docs. Here was the Kintsugi one, for example: hackmd.io/dFzKxB3ISWO8ju…

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth Finally, @mkalinin2 is working on a series of small spec updates he expects to release soon. They will be backwards compatible and released under the 2.1 version of the Kiln meta specs. Clients will still be able to connect to the network using the current v2 specs.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 Beyond the consensus-level changes, the next big topic was the JSON RPC APIs. Post-merge, the beacon chain gives us more nuance about the "types" of blocks it sends to the EL, so we can expose that in JSON RPC.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 The obvious first candidate is a `finalised` parameter which can be passed to calls to return the latest finalised block. This can be used instead of PoW confirmations and might simplify life for applications which receive funds and want to avoid re-orgs, like exchanges.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 Similarly, in PoS, once a block has amassed a certain number of attestations, we can be fairly confident it won't re-org. Usually, this takes ~4 seconds to happen. We'd like to expose this in the API as well.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 Side note for those who want to dig into this: @dankrad has a full presentation going in the details: docs.google.com/presentation/d…

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad Given this "safe head" block provides stronger assurances than the current "latest" block, there was debate on the call as to whether we should have "latest" default to "safe head" behind the scenes (and expose the "true" latest block via another flag, e.g. "unsafe").

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad I put up a poll for it, and while all the responses trend towards "safe head", the comments from application devs are near-unanimous towards not doing this and keeping "latest" as is:

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

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad That said, there might be cases where the latest PoS block can be attacked in ways a new PoW block can't, so there's still some debate...! Expect this to be resolved 🔜. After that, the API specs will be updated and clients will add support for the appropriate flags.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad On that note: maintaining specs is something we always struggle to find folks to do. If you think you can help, this is a fairly accessible task that community members can take off client devs' hands 😅 Here's what it looks like: github.com/ethereum/execu…

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad Next up, we discussed a few items for Shanghai. First was a new Beacon Chain withdrawal proposal by @dannyryan and @ralexstokes: EIP-4863 eips.ethereum.org/EIPS/eip-4863

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes This design is nice because it "pushes" withdrawals from the Beacon Chain down into the execution layer. This simplifies the flow, is slightly cheaper for validators, and allows validators to withdraw to an address which doesn't currently have a balance.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes There were some concerns that this design wouldn't work with some 0x01 withdrawal credentials, but an investigation into it suggested things should be alright: notes.ethereum.org/@djrtwo/0x01-p… 🎉

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes The one technical point discussed on the call is whether these withdrawals should happen in a new transaction type, or simply as an operation which clients perform during block processing that isn't exposed via a transaction (like the block reward distribution).

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes There were arguments on both sides, but no super strong consensus. At a higher level, some client devs asked to have a document which described the withdrawal flow in its entirety, across the CL, EL and engine API, to better wrap their heads around it.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes So the next steps will be to put that document together and for client teams to look at the prototype implementation in geth: github.com/ethereum/go-et…

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes Then, @protolambda came on to discuss the latest progress on shard blob transactions: eips.ethereum.org/EIPS/eip-4844

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC posted a good thread today giving context on the effort, recommend reading that first:

https://twitter.com/optimismPBC/status/1499830644783915009

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC TL;DR: this introduces a new txn type which points to data stored on the beacon chain which rollups can use to offer lower fees.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC There were a few technical points that @protolambda mentioned on the agenda: first, how to gossip the actual data that is stored, second, how to encode the data and the interactions between RLP & SSZ encoding, and third, how to best adopt KZG commitments, which are necessary.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC The questions from client teams went in different directions, though 😅 First, there were some questions about the role of the opcodes and precompiles in the EIP. I recommend the livestream for the details.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC Second, there were some questions about how this could affect history growth. On the EL side, it won't change much: the blob shard txns only include a list of hashes in excess of what 1559-style txns have. The bulk of the data is thus stored on the CL side.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC On the CL side, we only guarantee that the data was made available for *some time*, but not forever. Hence, it gets periodically pruned and nodes only need to store a bounded amount at any time.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC This design aims to be maximally compatible with how full sharding will work, and hopefully means that the EL (and applications built on it!) wouldn't require significant changes to adopt the benefits of sharding once it's deployed.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC Finally, we discussed the fact that this design, like sharding, relies on KZG commitments, which require a trusted setup. This would be the first time we introduce such a setup in Ethereum, but other chains have done it, such as ZCash.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC I am no expert on this, but AIUI, the way these setups work is that as long as *a single* participant in the setup is honest, then it is secure. One nice property is that for our use case, we likely would not require participants to have access to significant computing power.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC @dannyryan mentioned that it might even be possible to build a browser-based tool where anyone could generate a proof and contribute to the setup. This means we could have one of the largest seed generation events ever done!

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC While all of this is very exciting, it's a lot of work to get done 😅! One thing we all agreed on was that while we want to push to try and get this done for Shanghai, if it doesn't work, we still need *something* to help lower fees on the network.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC The simple option we considered a few months ago is a CALLDATA cost reduction. While it's not a perfect solution, it would be better than nothing and would reduce L2 fees in Shanghai if shard blob transactions prove too complex or contentious to get done.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC That said, next up we had @willmorriss4 present "one small change" to consider for Shanghai: EIP-3651 eips.ethereum.org/EIPS/eip-3651

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC @willmorriss4 This really is a pretty small change, though, and fixes a sort of "omission" in the Berlin upgrade. In short, in Berlin, EIP-2929 changed gas costs to make it more expensive to access storage items that clients have to fetch on disk.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC @willmorriss4 One thing that was made more expensive was accessing the COINBASE. William argues this is a mistake because when you process a block, you need that value to credit the block reward. Therefore, it should be charged as a "warm" access.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC @willmorriss4 Doing so would reduce fees for calls that make transfers to the COINBASE address, which is frequently used in systems like Flashbots (do they not have a Twitter???)

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC @willmorriss4 This brought up the subject of Shanghai priorities again. At a high level, we already have 3 big priorities: Beacon Chain Withdrawals, lowering fees, and EVM improvements which we've committed to (EIP-3540).

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC @willmorriss4 Beyond that, we've already included two "quick wins": a new opcode which pushes 0 onto the stack, and adding a limit + metering to initcode.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC @willmorriss4 We want to make sure we can keep our focus on the big things, but maintain a balance of small improvements as to not completely halt progress on other fronts. All client teams agreed that EIP-3651 could likely be done without affecting progress on other, larger, items.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC @willmorriss4 So, we moved it to "Considered for Inclusion", alongside the previously agreed to EIPs. This status roughly means that we'll get it implemented, tried on devnets, and if we don't find issues, it should make it to mainnet.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC @willmorriss4 If, for whatever reason, we decided during implementation that it wasn't worth it to do a CFI EIP (either because it's more complex than anticipated, the need for it is no longer as strong, etc.), we can always remove it from the upgrade.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC @willmorriss4 You can find the list of currently CFI'd EIPs for Shanghai here: github.com/ethereum/execu…

Note that no withdrawal or shard blob txn/CALLDATA reduction EIP has been added yet, but we're working with the assumption that some version of each will be.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC @willmorriss4 And, finally, we had @k06a come in and present another EIP: EIP-3978, which proposes to offer gas refunds on some reverted operations.

github.com/ethereum/EIPs/…

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC @willmorriss4 @k06a While everyone agreed this would be nice, the general consensus was against it for a few reasons. First, competing priorities for Shanghai. While the COINBASE EIP was a very small change, this would require implementing (and testing!) multiple price changes, which isn't trivial.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC @willmorriss4 @k06a Second, it seems that a lot of these gas cost issues should be fixed when we transition to using Verkle Tries, as a stepping stone to statelessness. Client devs felt it was a better use of resources to focus on the "big features" for Shanghai and then on stateless.

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC @willmorriss4 @k06a One last thing: we announced a breakout room next Friday to choose a name for the EL client releases for The Merge: github.com/ethereum/pm/is…

If you care about naming and want to discuss it for an hour, this is your moment 😁 I'll be on as a participant, as I have a favorite!

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC @willmorriss4 @k06a Next ACD is scheduled for March 18, 14:00 UTC. A note to North Americans: DST kicks in before, so the call might be at a different local time for you. See you then 👋🏻

@ethereum @vdWijden @parithosh_j @nethermindeth @go_ethereum @HyperledgerBesu @ErigonEth @mkalinin2 @dankrad @dannyryan @ralexstokes @protolambda @optimismPBC @willmorriss4 @k06a Oh, and one final thing! The recordings of the calls are now available on @permacastapp. Thanks to the team for getting it set up! You can find them here: permacast.net/#/podcasts/Dx0…

If you want to help archive the calls, instructions are here: github.com/ethereum/pm/bl…