Prysm Updates Q1’23

Hi Friends, welcome to a brand new installment of the Prysm project’s development updates series. We’ll provide quarterly updates on what is going on in the protocol layer world and what we have been working hard on. Without further delay, let’s go!

Withdrawal / Capella

The hottest topic in the Ethereum protocol right now is shipping withdrawals. Withdrawals will be included in the upcoming Shapella (execution layer’s Shanghai + consensus layer’s Capella) network upgrade. The scope of withdrawals includes both full and partial withdrawals:

• Full withdrawals: Full withdrawals mean withdrawing your validator’s entire balance. Firstly you have to sign and submit a voluntary exit object on the beacon chain. Once the object has been processed, within a few epochs depending on the size of a queue, the amount will be minted to a specified Ethereum address and can be spent immediately. Your validator will exit and stop validating on the chain.
• Partial withdrawals: Partial withdrawals mean withdrawing any earnings that are above your validator’s 32 ETH base balance. That is, if your validator has a balance of 33.3 ETH, you can withdraw 1.3 ETH from it while continuing to validate. To activate partial withdrawals for your validator, you must sign and submit a type of message known as a BLSToExecutionChange object on the beacon chain. Once the object has been processed in a block, the amount will be minted to your specified Ethereum address and can be spent immediately. Your validator will continue to validate on the chain as expected. Partial withdrawals do not have to go through the potentially long exit queue that full withdrawals require.

Interested? The following sections will cover the what, when, and how.

When withdrawal in Prysm?

Good news! We have implemented and reviewed all the core functionality for withdrawal in our default branch on Github. For anyone that wants to run a Capella-compatible node, the `develop` branch would work just fine. Meanwhile, we are carefully designing how to handle edge cases like broadcasting BLSToExecutionChange messages before and around the fork. We also want to extend a CLI tool provided by Prysm, known as prysmctl, to provide a nicer user experience for stakers wanting to submit withdrawal requests to the network. The latest `develop` branch in Prysm repository should be fully Capella/withdrawal capable. As we prepare for more future testnets, we’ll be tagging them under specific versions and providing binaries and docker images.

What else is in the Capella hard fork?

On the consensus layer, besides withdrawals, there are non-user-facing changes, such as changing the beacon state’s historical accumulator to a more extensible format, enabling faster backward block sync when a node syncs using a weak subjectivity checkpoint. This makes it easier for checkpoint sync to backfill historical data, which improves the user experience.

On the execution layer, besides withdrawal Ethereum Improvement Proposals (EIPs), there are other EIPs, in which you may be interested. You can read more about them here:

• EIP-6122 : Forkid checks based on timestamps
• EIP-4895 : Withdrawals
• EIP-3651: Warm COINBASE
• EIP-3855 : PUSH0
• EIP-3860 : Limit/meter initcode

When is the Capella hard fork happening?

A good sign that a mainnet launch is imminent is that almost all client teams are performing much better in development networks and are ready for public-facing test network launches. Devnet3 (which had all the latest spec changes) has run smoothly with all the client pairs, and validator exits have been tested on it. Devnets 4,5, and 6 — as well as a Mainnet shadow fork — were launched during an interop meeting the last week of January. These devnets tested changes of validator credentials using mainnet-sized validator lists. We also had a shadow fork on Sepolia testnet with Devnet3 configs, which went great. You can anticipate testnets like Goerli and Sepolia to be scheduled in the next few weeks. Withdrawals will most likely ship this spring (North hemisphere).

Please note that the discrepancy on the timeline, at the time of writing may differ from the time of release. As of Feb 1st. Zhejiang public testnet has started, and it is finalizing. All the toolings are on here, and anyone can participate in testing withdrawal.

What can I do to help?

We need all the help we can get, and we appreciate any community contributions. The most helpful action stakers can take at the moment is to try out withdrawals on testnets, including both partial and full withdrawals. The more client implementations you try, the better. Find a bug? Submit a bug report on your client’s Github issue. Keep an eye out for when withdrawals on Sepolia and Goerli are enabled, as that’s when true public testing will begin. The user experience for sending voluntary exits or BLSToExecutionChange messages is essential, and it’s important that we do an outstanding job at that. If there’s anything you don’t like during the process, please send feedback. Most importantly, the user experience and safety of using command-line tools such as the Ethereum Staking CLI is paramount for this upgrade to go smoothly. Last but not least, write your own documentation and share it with others. Talk to other validators and developers about what worked and didn’t work, and be critical of how we can make this process easier for you.

What can I do to learn more about withdrawal?

You are at the right place! There are tons of good resources out there. We recommend the FAQ, which outlines and answers the popular questions. We also recommend following other client updates. As we get closer, they will have more information. Meanwhile, keep an eye out for all the development calls to keep track of the latest update and release schedules. Also, take a look at Vitalik’s annotated spec, which was recently updated to Capella edition.

EIP-4844 / The Ethereum scalability upgrade: Deneb

Another hot topic in the Ethereum protocol land is proto-danksharding aka EIP-4844. It introduces a new kind of Ethereum transaction which enables “blobs” of data to be persisted in the beacon chain for a short period of time. The blobs data gas will be cheaper than CALLDATA gas due to expiry, blobs are pruned after ~2 weeks, while CALLDATA is stored forever. Rollups are the main beneficiary of this due to the decrease in cost for posting compressed data onto the chain, and rollups currently are the best trustless scaling solutions. The end goal for EIP-4844 is to help facilitate a broader ecosystem move to rollups.

Where are we now?

We successfully launched an EIP-4844 devnet during the interop week. (Jan 23 — Jan 27). We got almost all client teams to participate in the devnet. Clients participated in all combinations. We ran into some syncing issues early on, but client devs got most fixed in the end. During the interop week, we got to work on blob spamming tools, and use it which resulted in EL clients discovered bugs. One of the todo from interop week was to work on more stressful blobs spamming environments across an extended period.

Underpinning the security of these blob transactions is a novel cryptographic primitive known as KZG commitment. New cryptographic libraries have been written from scratch to this end and their progress is ramping up to have them production ready in the coming weeks. A fair amount of library bugs were fixed during interop week. The KZG library is also switching go-kzg to Gnark for the backend, given that Gnark will be audited. The audit will happen in a month and a half and the unit test framework is currently getting implemented.

On the execution layer side, the design of blob transaction mempool is getting more mature. Peter released a design doc that covered some well thoughts and corner cases. There are plenty of implementation details, and luckily different execution layer teams can work differently. In addition, there are several open questions, such as zero-blob compatibility and replay strategy which remains to be discussed.

On the consensus layer side, block and blob coupling or decoupling remain the biggest unknown headed towards interop week. Finally, that was settled, there was a rough consensus to decouple blocks and blobs for the gossip net. We want to propagate blobs as efficiently as nodes were seeing message size correlate with network propagation in Goerli’s big block experiment. Decoupling enables nodes to operate more efficiently and gives more optionality for the clients to optimize for bandwidth. The hashing for blob transactions was also discussed. Given there’s the interplay between RLP & SSZ, which requires a broader discussion. The goal is to move EL to SSZ entirely, and hashing blobs are coupled with this decision.

What is next?

From the execution layer’s perspective, the biggest hurdle is blob transaction mempool design. From the consensus layer’s perspective, the biggest hurdle is the decoupling of block and blob, which requires new spec changes and client implementations. As for the KZG library, comprehensive testing and auditing are next. Steady progress is happening from all angles. We are on track to finalize the consensus spec in a few weeks and start a new devnet based on the finalized version of the spec.

Special shoutout: KZG ceremony

KZG ceremony is ongoing until March 13th. If you haven’t participated, please do so! Your participation has a meaningful impact beyond the technical output of the ceremony itself and the scaling mechanism it enables. This is a rare opportunity to get to be part of history. To learn more about KZG ceremony, read here. To participate in the KZG ceremony, go here!

That’s it for our Q1’23 update. Stay tuned for upcoming withdrawal testnets and more exciting stuff from the Ethereum and Arbitrum ecosystems!

-Prysm team