This update comes a bit later than I would have liked. A lot has happened since the last one! Here are the highlights:

• Kintsugi was launched: you can now test post-merge Ethereum on it 🍵

• We found a couple issues on the network, leading to refinements in the spec 🐞

• Once clients have those fixes, and a new auth mechanism, another round of devnets will be launched 🚨

• Applications should start testing deployments on Kintsugi now. Its next version, Kiln, will be the dress rehearsal before existing testnets transition 🏗

• We have a community call in a few weeks to discuss all this 📣

• Shanghai is slowly being planned, with a focus on valuable EIPs which had been deprioritized, along with beacon chain withdrawals 🏧

Right before the holidays, the Kintsugi testnet launched. This was the first public, easily accessible, multi-client testnet running post-merge Ethereum!

We learned a lot from it, specifically when we encountered a bug that led to delays in finalization. On January 7th, the fuzzer running on the testnet caused a fork by creating ExecutionPayloads with hashes replaced by their parent's hash, which some clients erroneously marked as valid. Marius, who triggered the issue, had a write up on Twitter: https://twitter.com/vdWijden/status/1479414824794832900

While this bug was fairly easy to fix, it helped us discover other, more subtle, issues, which only happened when the network was in a state with multiple deep forks. Again, Marius has a thread. In short, when consensus clients sent payloads to execution clients across several forks, these would all be executed by default, slowing down clients, triggering unnecessary sync processes and, in the worst cases, causing the node to panic and shut down.

To address this, a change was made to the Engine API specification which loosened the requirements for execution clients when receiving payloads. Instead of processing them by default, the clients can choose to simply store payloads on a non-canonical chain (but must still process those on the main chain).

This change will be included in the next release of the specs. Alongside it, one more significant change will be introduced: an authentication mechanism for execution and consensus clients to use with the Engine API (PR).

The authentication mechanism will prevent users from accidentally exposing their Engine API over the open Internet, which happens periodically with JSON RPC endpoints today. While the worst case for JSON RPC endpoints being exposed is mild (someone spamming your node with requests), if the Engine API is exposed, validators could lose funds. Specifically, an attacker could send VALID responses for invalid payloads or even propose invalid ones on the network, leading to slashings. The authentication ensures that a node's consensus and execution clients are only talking to each other.

Once these changes are implemented in clients, we will launch new short-lived devnets to test implementations and interoperability. As these stabilize, expect a new Kintsugi-style testnet, Kiln, running the latest specs.

For applications, I recommend starting to look at Kintsugi today to ensure that things work as intended. While the merge only has minor changes at the execution layer (listed here), it is worth being sure that tooling, infrastructure, deployment flows, etc. all work smoothly.

That said, Kintsugi will be sunset in the coming weeks, so if you need "weeks" rather than "days" to stage a deployment, waiting for Kiln is recommended. A community call is planned for February 11th to discuss all of this in more detail!

Assuming no major issues are found, Kiln should be the last new testnet before we start looking to fork existing ones! Of course, testing of various kinds will continue throughout the process. Ensuring the network's security along with a smooth transition remains the #1 focus. Onwards!

With the merge work nearing "the beginning of the end", discussions about what to include in the first post-merge upgrade, Shanghai, are beginning. Over the past year or two, most protocol work has centred around large initiatives such as EIP-1559 and the transition to proof of stake.

The intense focus required to ship these massive change has resulted in other, "normal-sized", proposals being deprioritized. A lot of these can bring significant value to Ethereum, and are now being considered for Shanghai. Some notable ones:

• EVM Object Format, which enables versioning of contracts and makes it easier to introduce new functionality into the EVM.

• BLS Precompiles, which provides the EVM with native execution of BLS operations.

• EIP-3074, which provides UX improvements and gas costs savings for end users.

• EIP-4488, which reduces CALLDATA costs, lowering the cost of transacting on rollups.

• EIP-1153, which introduces opcodes for transient storage, that applications can use to lower end user fees.

This isn't an exhaustive list (here's one!), but highlights that there are several valuable things we can do in Shanghai. We now need to think hard about what to prioritize! Specifically, EVM Object Format is slated for discussion about inclusion on the next AllCoreDevs call. If you have any feedback, now is a good time to share it on Ethereum Magicians.

Aside from these proposals, another feature high on the priority list for Shanghai is withdrawals from the beacon chain. While there is no formal EIP yet, it is something that needs to be taken into account when planning he upgrade. Expect more on this as soon as the merge specifications are finalized!

As mentioned, over the next few weeks, you can expect client releases which implement the latest version of the specification. Once these are out, ephemeral devnets will be stood up for testing. Then, the Kiln testnet will launch for an (hopefully!) final round of public testing. Assuming all goes well there, we will begin transitioning existing testnets to proof of stake. A successful transition across all existing testnets is the last step before setting the date for The Merge on mainnet!

In parallel, Shanghai is slowly being planned, with an eye towards longstanding proposals we've wanted to implement for a while but simply didn't have the bandwidth for. Expect a beacon chain withdrawal spec 🔜.

Thanks for reading!