Preliminary Findings: Get Blobs Optimization in Prysm and Geth

Setup

  • CL: Prysm branch
  • EL: Geth branch
  • Network:
    • Download: ~93.44 Mbps
    • Upload: ~89.5 Mbps
  • Hardware:
    • Intel® Coreâ„¢ i5-1340P
    • 32GB RAM, 4TB M.2 NVMe
  • Data Period: Oct 11 to Oct 14

This post summarizes the preliminary findings from running the "get blobs" optimization with Prysm and Geth. Please note that these results are based on a few days of data, and the majority of the network has not yet adopted this feature.

Expected Improvements from Get Blobs Optimization

With the "get blobs" optimization, two main improvements are expected:

  1. Faster block imports: Nodes should be able to import blocks more quickly.
  2. Bandwidth savings: Nodes may retrieve blob sidecars from EL instead of receiving them over the wire, reducing bandwidth usage.

Blob Retrieval Hit Rate

The first area of interest is the hit rate: how often blob sidecars are retrieved from the EL before arriving via gossip. As shown below, the hit rate is decent, with a significant portion of blob sidecars being successfully retrieved from the EL.

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

Additionally, between Oct 11 (11:40 AM) and Oct 14 (08:06 AM), 19,187 blob sidecars were retrieved. This translates to a recovery rate of one blob sidecar per slot.

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

Query: blob_recovered_from_el_count

Improvement in Block Import Speed

The most noticeable improvement was seen in block import speed. In Prysm, DA wait time (the time a node waits for blob sidecars to arrive before importing blocks) was significantly reduced. Between Oct 11 and Oct 14, we observed a reduction in DA wait times, giving nodes an extra 100-500ms of processing time per save.

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

Query: rate(da_waited_time_milliseconds_sum[30s]) / rate(da_waited_time_milliseconds_count[30s])

Reduction in P2P Blob Sidecar Deliveries

Another improvement was the reduction in the frequency of blob sidecar objects delivered via P2P gossip. Although the reduction was observed, the exact bandwidth savings could not be quantified.

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

Query: sum(rate(p2p_pubsub_deliver_total{topic=~"/eth2/6a95a1a9/blob_sidecar_[0-5]/ssz_snappy"}[30s]))

Bandwidth Savings: A More Controlled Setup

The node mentioned above was subscribed to all 64 attestation subnets, making it difficult to isolate bandwidth savings pre- and post-optimization. To verify network savings, we set up two beacon nodes on the same instance, with one running the latest develop branch and the other running the "get blobs" branch. Neither node subscribed to most attestation subnets.

The comparison showed that with the "get blobs" optimization:

  • Download bandwidth was reduced. (green)
  • Upload bandwidth was increased. (yellow)

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

Query:
(rate(network_bytes_in{process="beacon-chain.30872"}[1h]) - ignoring(process) rate(network_bytes_in{process="beacon-chain.10886"}[1h])) / 1024
(rate(network_bytes_out{process="beacon-chain.30872"}[1h]) - ignoring(process) rate(network_bytes_out{process="beacon-chain.10886"}[1h])) / 1024

This was expected because the following asymmetric at play:

  • If a node retrieves blobs faster than others, it will broadcast more blobs (fewer IDONTWANT messages received) but download fewer blobs (IDONTWANT sent earlier).
  • If a node retrieves blobs later than others, it will broadcast fewer blobs (more IDONTWANT messages received) but download more blobs over the wire.

Next Steps

To achieve more substantial bandwidth reductions, the following changes should occur:

  1. More nodes should adopt the "get blobs" optimization, especially key actors like staking pools and exchanges.
  2. Relayers should stop broadcasting blob sidecars before broadcasting blocks.
  3. Local proposer nodes should broadcast the block first, then the blob sidecars.

As more nodes adopt this behavior, the benefits of the optimization will become more pronounced.

Conclusion

  • The "get blobs" optimization shows a good hit rate, with one blob sidecar retrieved per slot (33% of the target allocation).
  • There is a clear improvement in block import speed
  • P2P blob sidecar deliveries have been reduced, though we cannot yet quantify the exact bandwidth savings.
  • While download bandwidth has been reduced, upload bandwidth has increased due to the current asymmetry in network behavior.