changed 2 years ago  
Published Linked with GitHub

EPF Dev Update #11

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
    Image Not Showing Possible Reasons
    • The image file may be corrupted
    • The server hosting the image is unavailable
    • The image path is incorrect
    • The image format is not supported
    Learn More →
    Image Not Showing Possible Reasons
    • The image file may be corrupted
    • The server hosting the image is unavailable
    • The image path is incorrect
    • The image format is not supported
    Learn More →
    :
  • 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

sequenceDiagram
    participant event_rx
    participant BeaconProcessor
    participant backfill_queue
    Title: Existing / Default backfill batch processing
    event_rx->>BeaconProcessor: new backfill batch work
    alt if worker available
        BeaconProcessor->>BeaconProcessor: process backfill batch immediately        
    else no available worker
        BeaconProcessor->>backfill_queue: push to queue
    end
    loop next loop
        alt if worker available
            BeaconProcessor-->>backfill_queue: pop from queue
            BeaconProcessor->>BeaconProcessor: process backfill batch
        end
    end

sequenceDiagram
    participant event_rx
    participant BeaconProcessor
    participant backfill_queue as backfill_queue  (existing) 
    participant backfill_scheduled_q as backfill_scheduled_q  (new)
    participant BackfillScheduler
    Title: backfill batch processing with rate-limiting
    event_rx->>BeaconProcessor: new backfill batch work
    BeaconProcessor->>backfill_scheduled_q: push to a "scheduled" queue
    loop At 6,7,10 seconds of after slot start
        BackfillScheduler-->>backfill_scheduled_q: pop work from queue
        BackfillScheduler->>event_rx: send scheduled backfill batch work
        event_rx->>BeaconProcessor: receive scheduled backfill batch work
    end
        alt if worker available
        BeaconProcessor->>BeaconProcessor: process backfill batch immediately        
    else no available worker
        BeaconProcessor->>backfill_queue: push to queue
    end
    loop next loop
        alt if worker available
            BeaconProcessor-->>backfill_queue: pop from queue
            BeaconProcessor->>BeaconProcessor: process backfill batch
        end
    end

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
Select a repo