Hi @hyeonleee,
Thanks for your interest in our study.
We have repeated the evaluation 100 days after the Fuska hard fork to gain a bit more of statistical confidence in our results. Here is what we found:
The observations from 100 days after the Fusaka hard fork provide a materially clearer picture of the network’s behavior under blob-carrying workloads, particularly regarding block production reliability and throughput utilization.
First, the disappearance of the previously observed correlation between a high blob count and increased probability of missing the subsequent slot is a strong indication that the bottlenecks identified in the pre-Fusaka regime have been effectively mitigated. Apparently, one of the CL clients was experiencing database issues due to high blob counts. Previously, large blob payloads introduced measurable strain on proposer duties—likely due to a combination of data propagation latency, execution/validation overhead, and builder-proposer coordination inefficiencies. The fact that this updated data shows a uniform probability of missing a block regardless of blob count suggests that these constraints have been alleviated. In practical terms, this points to improvements in the client-side handling of blob verification and inclusion. The system now appears to have reached a regime where blob-related load is no longer a first-order factor in proposer performance.
However, while reliability under load has improved, the second observation highlights a more structural limitation: the network is still operating far below its intended blob throughput capacity. The persistently low mean number of blobs per slot indicates that demand for blob space—or the effective supply pipeline feeding it—is insufficient to stress the system. This is critical because many of the protocol’s scaling assumptions, particularly those related to data availability sampling and blob fee markets, are predicated on sustained high utilization. In the absence of such conditions, the system is effectively being evaluated in a low-load regime, which is not representative of its target operating envelope.
This mismatch has important implications for performance characterization. Systems that behave robustly under low or moderate load can exhibit qualitatively different dynamics when pushed toward saturation. For example, latency distributions, mempool dynamics, fee market stability, and builder competition can all shift nonlinearly as utilization increases. The absence of missed-slot correlation with blob count under current conditions is reassuring, but it does not guarantee similar behavior when the blob count approaches protocol limits over extended periods. In particular, second-order effects—such as network congestion, cross-client heterogeneity, and builder centralization pressures—may only emerge under sustained high throughput.
In summary, the post-Fusaka data presents a mixed but informative outcome. On one hand, the removal of blob-induced proposer instability is a significant success, indicating that the protocol and client implementations have matured to handle large data payloads without compromising block production. On the other hand, the continued underutilization of blob capacity means that the network has not yet been tested in the regime it was designed for. As a result, while current observations confirm robustness under present conditions, they leave open critical questions about behavior under sustained high throughput—questions that can only be answered once demand scales to match the protocol’s intended capacity.