Introduction

I am Bharath, This is my Week 0 Dev update. I am planning to work on the proposal related to uncoupling blobs from execution payloads. This proposal aims to allow validators to defer more expensive block building like blobs to more specialized builders. This aims to decentralize block building.

High level Summary

This week was spent mostly on researching about EIP-4844 and digging deeper into Ethereum PoS system. I also spent time with the Prysm codebase where I forked the codebase and set it up. Along with that I worked on one issue and identified a couple of other issues which I am currently working on.

At the end of Week 0, I got a very good level understanding of EIP-4844 , the problem statement and got a good sense of the prysm codebase.

Detailed Summary

I looked into the following for my research:

  1. I read the yellow paper to revise my fundamentals in Ethereum

  2. I referred to Ben Edignton's book to understand Ethereum PoS at a deeper level.

  3. To study in great detail about EIP-4844, I referred to the following:

    1. The EIP-4844 official spec which contains great intricacies of the spec
    2. This video by Ben Edignton which contains explanations of EIP-4844 with examples
    3. This video by proto lambda on EIP-4844
    4. This video by Dankrad on EIP-4844
    5. These dev comments in the gEth codebase on blob txpool
    6. Read the prysm code in deneb-integration branch for EIP-4844 lower level details. I am currently writing a document on my understanding of the codebase
  4. To get a much deeper understand of how GEth works post merge at a lower level I worked on the following videos

    1. How Geth works in the context of a PoS blockchain
    2. Walkthrough of how txs are processed in Geth
  5. To get a much deeper understanding of the Engine API and Builder APIs I studied the following resources

    1. This contains well made sequence diagrams of how the engine api works during block proposals https://hackmd.io/@n0ble/HkoYcDDt5
    2. I saw this video on how the builder api is structured. This gave me a really good understanding on the mechanisms of blinded payloads
    3. This post on the MEV-Boost architecture really solidified my understanding on how the builder apis really worked to aid validators in block building and also to build a market for block builders
    4. The original repo which contains the specs had a lot of useful information on the specification of the engine API for EIP-4844
    5. The original repo containing builder api specs
  6. I worked on a PR to make a contribution to prysm. This PR involved refactoring the RPC and Gossip topics of prysm to custom types from plain string types. The aim of this change is to make operations such as topic validation and topic comparison much more robust. This work was cut short because it is a very non trivial task and touches a lot of critical code paths. It also requires a lot of context. As per the suggestion of the prysm devs, I abandoned it for now. But I learnt the following while working on this PR:

    1. How testing works in Prysm: Prysm contains unit tests and integration tests which are run by Bazel. To validate my changes I had to modify tests and make sure that my changes were not breaking any existing test.
    2. I learnt more about how the beacon api is structured into RPC topics which is used by external users to query the Beacon node or perform operations directly with the beacon node(like submitting voluntary exit messages). Gossip API is more for P2P connections like broadcasting a block, sending attestations to get aggregated into a sync commitee etc.
    3. I looked a bit deeper in libp2p while refactoring the gossip topics.
  7. I am currently working on adding a validators upcoming duties and sync comittees as prometheus metrics to prysm

  8. I am also planning to improve prysms unit tests in order to get a better understanding of the project.

Conclusion

I have chosen the project that I am interested to work on which is to uncouple blobs from execution payloads to decentralize block buliding

I have already connected with mentors and have made really good progress in my research.

My next steps are to continue my research and writing documentation contains my thoughts on the project and ideas on moving forward with it.

I also am looking forward to make code contributions to prysm on the side.

Select a repo