---
tags: epf,ethereum
---

# EPF Dev Update #10

Just to add a bit of context to my updates, I'll be sticking my project links here in furture updates.

- [Project: EIP-4844 Consensus Client](https://github.com/eth-protocol-fellows/cohort-three/blob/master/projects/4844-consensus-client.md)
- [Design: Builder API for Blobs](https://hackmd.io/@jimmygchen/B1dLR74Io)

## Update for week 11 (2023/1/9 - 2023/1/16)

- Proposed a new PR to add a `getBlobsSideCar` to **Beacon API** spec ([ethereum/beacon-APIs#286](https://github.com/ethereum/beacon-APIs/pull/286))
- Progressed further with the builder updates for EIP-4844 in **Lighthouse** ([lighthouse/3808](https://github.com/sigp/lighthouse/pull/3808)). More details in below [section](#Lighthouse-Builder-updates-for-EIP-4844).
- There have been active discussions on the oustanding **Beacon API** & **Builder spec** update PRs, hopefully these will be finalised soon:
- [Add and update types for Capella (builder-specs#60)](https://github.com/ethereum/builder-specs/pull/60)
- [Add and update types for EIP-4844 (builder-specs#61)](https://github.com/ethereum/builder-specs/pull/61)
- Next week I plan to continue to work on tests for the builder updates and Beacon API changes I did last week ([Add Beacon API endpoint (/lighthouse) to download blobs by block ID #3830](https://github.com/sigp/lighthouse/pull/3830))

## Lighthouse: Builder updates for EIP-4844

[PR: Builder updates for Blobs (EIP-4844)](https://github.com/sigp/lighthouse/pull/3808)

So I wanted to drop down some notes on this PR because the work turns out to be much bigger than I thought, and it's not even finished yet. I think I've implemented most of the draft spec changes and will start working on tests. As of now, the spec changes haven't been implemented in the builder client ([mev-boost](https://github.com/flashbots/mev-boost)), so all testing will be done against mocks, which will need some updates as well.

Details of changes I've made so far:
- Make [`BuilderBid`](https://github.com/jimmygchen/lighthouse/blob/builder-bid-4844/consensus/types/src/builder_bid.rs#L30) into a [`superstruct`](https://sigp.github.io/superstruct/), so that a new `blob_kzg_commitments` field can be introduced to just the `Eip4844` variant / version of `BuilderBid`. [SuperStruct](https://sigp.github.io/superstruct/) is a Rust library for working with versioned data.
- Make serialization / deserialization work for the `BuilderBid` superstruct. This ended up being a [relatively small change](https://github.com/sigp/lighthouse/pull/3808/files#diff-2bd4b43f16d5cec4a85433b29f13737b73ce734ae12b5a2dd437f605ec1d2f57) but took me a while to figure out how to get this working, as I wasn't familiar with [`serde`](https://serde.rs), a framework for serializing and deserializing Rust data structures.
- In order to verify the serialization/deserializtion works for all `BuilderBid` variants (`Merge`, `Capella`, `Eip4844`), I implemented a few tests [here](https://github.com/sigp/lighthouse/blob/46829ade087a347103cb5e7fd78ae674f6ce4ed9/consensus/types/src/builder_bid.rs#L117-L207). The tests deserialize a predefined JSON input into a `BuilderBid` object, and serialize the object into a JSON string, and then it verifies the output against the original JSON. And it worked \o/
- Implement handling of new field `blob_kzg_commitments` from the Builder [`getHeader`](https://ethereum.github.io/builder-specs/#/Builder/getHeader) endpoint. The `blob_kzg_commitments` is now added to the beacon blocks before validators sign them.
- Implement handling of `BlobsSidecar` received from the Builder [`submitBlindedBlock`](https://ethereum.github.io/builder-specs/#/Builder/submitBlindedBlock) endpoint. The blobs that are recieved, together with the full beacon block is then broadcasted to other beacon nodes.

Next step is to verfiy this all works! :crossed_fingers:

I've created an overview diagram to illustrate the block proposal process with builder flow:

[](https://i.imgur.com/l5GhCuQ.png)