EPF Dev Update #11

Project links

• Project: EIP-4844 Consensus Client
• Design: Builder API for Blobs

Summary for week 12 (2023/1/16 - 2023/1/23)

• I implemented the builder updates (lighthouse#3808) in Lighthouse last week, and started looking at adding tests this week
• While working on the tests, I realised the TestingBuilder utility uses types from the ethereum-consensus and mev-rs libraries, and both need to be updated for Capella and Deneb, so I went down that :
  • Add Capella types and presets ethereum-consensus#168
  • Add Deneb (EIP-4844) types and presets ethereum-consensus#170
  • Currently working on adding Capella & Deneb types to the mev-rs library
• I started looking into this backfill sync issue in lighthouse, which addresses a resources issue by rate-limiting backfill sync. I've pushed my WIP branch here which I'll continue to work on. More details below.
• Continue to address feedback on my outstanding PRs, more details below.

Lighthouse: rate limit historical block backfill

While waiting for my other PRs to get reviewed, I got interested and started looking into this historical backfill sync issue: lighthouse#3212

Backfill sync for a node happens if a node is initially setup using checkpoint sync - which is siginicantly faster than syncing from genesis, because it syncs from a recent finalized checkpoint. After the forward sync completes, the beacon node then starts the "backfill sync" to download the previous blocks prior to the checkpoint.

Right now the "backfill sync" process is not rate limited, and some user have reported nodes becoming overwhelmed during the sync. To address this issue, @michaelsproul propose to rate-limit the backfill process. See more details in the issue.

@paulhaunder was very kind to offer some help and provided an excellent writeup here, which explains the components involved and provided a proposed solution the problem.

To help with my understanding, I created the below diagram based on @paulhauner's notes, comparing backfill processing with / without rate-limiting

I've created an draft implementation, and will continue with improving and testing it next week. WIP branch can be found here for anyone interested: https://github.com/jimmygchen/lighthouse/pull/4

Updates to outstanding PRs

• Builder updates for Blobs (EIP-4844) lighthouse#3808:
  • initial implementation pushed last week, needs to be tested, currently waiting for mev-rs type updates
• Add and update types for Capella builder-specs#60
  • addressed some review feedback and seems to be on track
• Add and update types for EIP-4844/Deneb builder-specs#61
  • the discussion for whether the bump up the submitBlindedBlock endpoint to v2 continued in the R&D discord 4844-testing channel.
  • I created a diagram to illustrate the builder block proposal flow in my last update here
  • replaced all EIP-4844 references with Deneb, which is the new fork name decided during a call earlier this week
• Add getBlobsSidecar endpoint beacon-APIs#286
  • addressed some review feedback, there are still ongoing discussions on the endpoint path