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.
With the "get blobs" optimization, two main improvements are expected:
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.
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.
blob_recovered_from_el_count
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.
rate(da_waited_time_milliseconds_sum[30s]) / rate(da_waited_time_milliseconds_count[30s])
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.
sum(rate(p2p_pubsub_deliver_total{topic=~"/eth2/6a95a1a9/blob_sidecar_[0-5]/ssz_snappy"}[30s]))
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:
(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:
IDONTWANT
messages received) but download fewer blobs (IDONTWANT
sent earlier).IDONTWANT
messages received) but download more blobs over the wire.To achieve more substantial bandwidth reductions, the following changes should occur:
As more nodes adopt this behavior, the benefits of the optimization will become more pronounced.