Introduction

This dev update notes down preliminary work and study done to kickstart my journey into protocol development. It involves contributions to Prysm and a writeup on rollups/rollup-centric initiatives. It ends off with my plan ahead for the future.

Prysm's validator client and beacon chain server architecture

Old architecture

When Prysm first started, the team adopted gPRC as the API layer for inter-process communication, represented by the communication between gRPC Client and gRPC server (v1alpha1).

The official beacon API specification was later formalized and Prysm exposed a set of HTTP endpoints by using grpc-gateway to allow other implementations of validator clients to query Prysm's beacon chain server.

There were two main issues with this architecture:

1. Prysm's validator client cannot call into beacon chain servers implemented by other clients due to the lack of HTTP client compatability.
2. There is alot of maintenance burden and complexity for using gRPC gateway.

The team plans to gradually deprecate the gRPC implementation and use HTTP implementation going forward for client interoperability.

New architecture

The work contributed by cohort three resulted in Prysm's validator client to have HTTP client support. This means that anyone using Prysm's validator client can now use the HTTP protocol to query any beacon chain servers, including those implemented by other client teams.

There is still work left to be done to complete the entire migration to HTTP implementation, for example:

1. Replacing the gRPC server implementation with HTTP server implementation, eliminating the need for grpc-gateway
2. Functional/Performance testing to ensure the UX of users are not affected

Expected withdrawals API

To familiarize myself with Prysm, I contributed a PR to implement the expected withdrawals API and was glad that team gave positive feedback for it!

Knowing that the team intends to introduce new beacon API endpoints using the HTTP implementation, I made sure to do that instead of implementing it the usual way via gRPC.

My main takeaways from working on this PR are:

• Familiarizing with the beacon-api specification
  • Having access to this document helps me alot in understanding the requirements of the API. Furthermore, I can follow past conversations made in the GitHub repository for insights of the context and rationale behind exposing this API in the beacon chain server.
• Better understanding of the beacon chain state transition function (BC-STF)
  • The expected withdrawals API is exposed for external block builders that are building blocks for a future slot. As such, I took the opportunity to understand how the BC-STF works on a deeper level, especially the process_slots function that is used to advance the current state to a future state. In the process_slots function, an epoch transition triggered by the process_epoch function will change the result of the expected withdrawals, providing an estimate of what the expected withdrawals are if the proposed slot crosses the epoch boundary.
• Full/Partial withdrawals/Withdrawal Sweep
  • When writing tests to verify that the API is working, I have to dig deeper into how expected withdrawals work, which involves concepts like full withdrawals, partial withdrawals and withdrawal sweep. I find this section of the Eth2 book very helpful to understand these concepts.
• Bazel build/run/test
  • The Prysm team uses the Bazel build system for reasons mentioned here. I spent some time learning how to work with Bazel and learned enough to build, run and test the project using Bazel.
• Setup of EL+CL for live testing
  • To make sure that the new API introduced does not break in unexpected ways, I configured a EL+CL setup using checkpoint/full sync and tested the API using Postman to make sure that everything works as expected.

Resolving arbitrary state root to beacon state object

Prysm's implementation currently only supports up to SLOTS_PER_HISTORICAL_ROOT(8192) states for APIs that take in an arbitary state root.

My next PR involves storing a state root to block root mapping in Prysm's database to support arbitrary state root to beacon state object resolution.

My main takeaways from working on this PR are:

• Further understanding of the BC-STF
  • Working on this PR requires me to have sound understanding of how the state root and block root is derived. Upon looking deeper into the BC-STF, one particular interesting mechanism that caught my attention is how state.latest_block_header.state_root is set to Bytes32() during process_block and updated with the actual state_root value later in the next process_slot call. This logic was introduced to avoid circular dependency when verifying the state transition of the block applied to the current state.
• Next Slot Cache (NSC)
  • Reading Prysm's implementation of the BC-STF, I learned about NSC, which was introduced to allow separation of the process_slot function and process_block function in the BC-STF. This means that the client can run process_slot and process_block separately, independent of the block arrival time. This is useful as late block arrivals would delay the BC-STF process, especially on the beginning of the epoch where epoch processing time is non-negligible.
• Fork Choice Updates (FCU)
  • Blocks that are not ancestors of a finalized checkpoint might get reorged by another branch with a higher fork choice weight. I read how Prysm handles FCU by pruning the states and blocks that are previously stored during the BC-STF.
• BoltDB
  • BoltDB is the database that Prysm uses for reasons mentioned here. I learned how BoltDB works and created CRUD functions to store the state root to block root mapping in the DB.
• exploreDB
  • Prysm has a tool to explore the contents of BoltDB. I learned how the tool works and added a helper function to verify the contents of the new bucket that I introduced to store the state root to block root mapping.

Writeup on rollups and rollup-centric initiatives

Most client teams are preparing for the Cancun-Deneb upgrade now with Proto-Danksharding (EIP-4844) being the key factor to scale Ethereum. To understand the status quo and put myself in the shoes of core developers, I took a stab at writing an article about rollups and rollup-centric initiatives. To satisfy my curiosity, I dug into the code for the various client implementations and attached code snippets to complement what I read.

Writing this article solidified my understanding on the scalability of Ethereum in the past, present and future when Danksharding is completed.

Plan ahead

I am particular interested in PBS and am excited to work on the ePBS Design and Prototyping project proposed by the Prysm team. I am currently doing literature review on ePBS material and connected with mentors to discuss on this project. Stay tuned for the next update!