---
# System prepended metadata

title: Week 15

---

# Week 14 and 15

Finally my university mid-semsters exams are over. More than a week got spent on ML and Systems programming :)

Now, I am back to benchmarking. Here are some more results : 

### Confirmed Block Reorgs
No confirmed block reorgs were observed in either initial sync or steady state during the sampled window.

Steady (in-sync) :
![Screenshot 2025-09-28 at 5.49.22 PM](https://hackmd.io/_uploads/rJICPiIngx.png)
Initial Sync :
![Screenshot 2025-09-28 at 5.49.47 PM](https://hackmd.io/_uploads/SJ0yuoLheg.png)

### Head→confirmed slot-gap distribution

Median gap started high (~24–25 slots), then decayed to ~0 as the node caught up. So, on start/catch‑up the confirmed root lags the head by ~previous-epoch distance, then converges; in steady state the gap stays near-zero, indicating rapid advancement of the confirmed root toward the head.

![Screenshot 2025-09-28 at 5.52.54 PM](https://hackmd.io/_uploads/BJtoOoLhex.png)

![Screenshot 2025-09-28 at 5.52.29 PM](https://hackmd.io/_uploads/BJe5OoI2xx.png)

![Screenshot 2025-09-28 at 5.51.46 PM](https://hackmd.io/_uploads/SJHvdi8heg.png)

### Restart Analysis
Total restart rate :

![Screenshot 2025-09-28 at 5.43.19 PM](https://hackmd.io/_uploads/HkjDUi82xx.png)

Restart ratio - reorg vs stale :

“reorg” restart rate is 0; “stale” restarts showed transient bursts and then dropped to ~0. So, most probably the restarts we’re seeing are stale-only and confined to catch‑up windows; in steady state restarts are negligible and no reorg-caused restarts occurred.

Stale :
![Screenshot 2025-09-28 at 5.55.11 PM](https://hackmd.io/_uploads/SyMVtoU3eg.png)

Reorg :
![Screenshot 2025-09-28 at 5.55.32 PM](https://hackmd.io/_uploads/rJdrYiI3xx.png)

Restart frequency per hour :

![Screenshot 2025-09-28 at 5.45.35 PM](https://hackmd.io/_uploads/BkGevoLhlg.png)

![Screenshot 2025-09-28 at 6.15.00 PM](https://hackmd.io/_uploads/BJwR6sI2ge.png)

### Tailcase Analysis

Total tail rate :
![Screenshot 2025-09-28 at 5.47.42 PM](https://hackmd.io/_uploads/B1bdvsU2xx.png)

![Screenshot 2025-09-28 at 5.58.26 PM](https://hackmd.io/_uploads/SyHlqoIhll.png)

By delay bucket :
![Screenshot 2025-09-28 at 5.58.42 PM](https://hackmd.io/_uploads/BkH-9iL2ll.png)

Epoch Boundary :
![Screenshot 2025-09-28 at 5.59.43 PM](https://hackmd.io/_uploads/B1mS5jL2gg.png)

Mid Epoch :
![Screenshot 2025-09-28 at 5.59.58 PM](https://hackmd.io/_uploads/HyWL5s82gg.png)

![Screenshot 2025-09-28 at 6.00.57 PM](https://hackmd.io/_uploads/rJht9iUnxe.png)

Slot form latency :
![Screenshot 2025-09-28 at 6.01.12 PM](https://hackmd.io/_uploads/B10c9sL2xe.png)

![Screenshot 2025-09-28 at 6.01.38 PM](https://hackmd.io/_uploads/rJUh5oI3eg.png)

Total tail rate appears in a short window and then vanishes. The matrix by (epoch_boundary, delay_bucket) only shows epoch_boundary="false" lines; boundary share query returned empty (0). So the tails observed were mid‑epoch, not at epoch boundaries; likely due to late attestations/temporary participation dips during catch‑up. After steady state, tails disappear and slot-form latency stabilizes (median ≈ 0.5–1; plot shows ~0.5).

### Mapping confirmed block ↔ confirmation slot

From the logs I saw :
* All confirmations in this slice are 1-slot except one tail case (2 slots).
* One confirmation happened exactly at an epoch boundary (epoch_boundary=true).
* No confirmed reorgs visible; safe head flips are the expected per-slot O(1) updates.

| block_root | creation_slot | confirmation_slot | delay_slots | epoch_boundary |
|------------|---------------|-------------------|-------------|----------------|
| 0x8748b3ef9a73bed5… | 8610740 | 8610741 | 1 | false |
| 0x46574b473f6581fc… | 8610741 | 8610743 | 2 | false |
| 0x14325a13d619bc5e… | 8610742 | 8610743 | 1 | false |
| 0x0445453a5cdb9953… | 8610743 | 8610744 | 1 | false |
| 0x34fd483b78831253… | 8610744 | 8610745 | 1 | false |
| 0x3a96b824c1960548… | 8610746 | 8610747 | 1 | false |
| 0x3c6fd07ab797b904… | 8610747 | 8610748 | 1 | false |
| 0x411228c90ab0230a… | 8610749 | 8610750 | 1 | false |
| 0x22dc6317699dbdea… | 8610750 | 8610751 | 1 | false |
| 0x7ccabf45e91590c7… | 8610751 | 8610752 | 1 | true |
| 0xff4b3ed5ec22c06f… | 8610752 | 8610753 | 1 | false |
| 0x7f41a1bbd5a43deb… | 8610753 | 8610754 | 1 | false |
| 0xb374b8f9284a20ee… | 8610754 | 8610755 | 1 | false |
| 0xa4b4ac5b562a62eb… | 8610755 | 8610756 | 1 | false |
| 0xb8aa04561cf71543… | 8610756 | 8610757 | 1 | false |
| 0x14a2598c80dcde7b… | 8610757 | 8610758 | 1 | false |
| 0xc3cf23beb02af101… | 8610758 | 8610759 | 1 | false |

The takeaways would be : 
* Delay distribution - median = 1 slot; only one observed 2-slot tail (0x46574b47… at 8610741→8610743), consistent with our p95 target
* Epoch-boundary - observed at 8610751→8610752 (0x7ccabf45…), but still 1-slot.
* Head synchrony - head_slot matched creation_slot at confirm time in all lines shown; no evidence of slow confirmations beyond 2 slots.
* Safe-head churn - alternating “safe head updated (O(1))” is expected each slot as we advance confirmed root and then re-check after find_head; not a reorg signal by itself.