v0.1 · independent measurement
alpenglow-watch
솔라나 메인넷 확정(finality) 독립 실측 — 알펜글로우 활성화 D+1 (2026-10-22, 서울 관측)
0 slots
processed−finalized 슬롯 갭 · 50/50 샘플 (p50 = max = 0)
구 TowerBFT: ~32슬롯 = 6.4초
≤ ~160ms
confirmed→finalized 상한 p50 (RTT 145ms 포함)
60/60 트랜잭션이 첫 폴링에서 이미 확정
0.85–1.36s
최신 finalized 블록 나이 p50 (프로바이더별)
blockTime 1초 해상도 + 프로바이더 지연 포함
60 / 60
memo 프로그램 프로브 트랜잭션 · 퍼블릭 RPC 2개
지갑·비용 없이 순수 관측
프로바이더별 상세
| provider | n | 첫폴링 확정 | disc→fin p50 | p95 | RTT | 간격 p→f | 블록나이 p50/max |
|---|
| api.mainnet-beta.solana.com | 30 | 100% | 158ms | 405ms | 145ms | 0 / 0 slots | 0.85 / 1.33s |
| solana-rpc.publicnode.com | 30 | 100% | 269ms | 505ms | 259ms | 0 / 0 slots | 1.36 / 2.34s |
쟁점: 발표 150ms vs 재단 대시보드 6.6초
- 활성화 당일 재단 대시보드는 6.6초를 표시했다(보도 확인). 우리가 D+1에 측정한 착지 후 확정 깊이는 0슬롯 — 50/50 전 샘플. 두 숫자는 서로 다른 것을 잰다: 제출→착지(맴풀·리더 대기) vs 착지→확정. 알펜글로우가 바꾼 건 후자다.
- 우리 상한 측정에서 disc→final p50(158ms) ≈ RTT(145ms). 프로바이더가 "confirmed 응답"을 주는 시점엔 이미 확정돼 있었다는 뜻 — 착지 후 확정은 측정 해상도 아래(~수십 ms).
- 결론: 착지 이후 관점에서 확정은 사실상 즉각. 남은 지연은 제출→착지 구간이며, 이건 지갑을 쓰는 후속 측정(v0.2)의 몫.
방법론
- 프로브: memo 프로그램(MemoSq4g…) 최신 트랜잭션을 commitment confirmed로 발견 → getSignatureStatuses를 120ms 간격으로 finalized 관측까지 폴링. 지갑·비용 불필요.
- 체인 지표: getSlot processed/confirmed/finalized 동시 삼중 쿼리(25회×2), getBlock(finalized) blockTime 나이(25회×2).
- 모든 호출은 curl 경유(관측 환경의 TLS 프록시·지문 차단 회피). RTT 기준선은 getBlockHeight 8회 중앙값.
- 측정창: 2026-10-22 07:12–07:14 UTC · 관측지: 서울(KR) · 프로바이더는 각자 리전에서 응답.
한계 (솔직하게)
① 상계측정(upper-bound): confirmed→finalized 정확값이 아니라 "≤"이다. 60/60이 첫 폴링에서 확정이라 정확값은 해상도(약 150–400ms) 아래. ② RPC 뷰 측정: 프로바이더가 보고하는 확정 시점이며 검증인 직접 관측이 아니다. ③ blockTime은 1초 해상도. ④ 단일 관측지(서울)·2 프로바이더 — 지역 비교는 VPS 배포(v0.3) 후. ⑤ 제출→착지 지연 미측정(지갑 필요, v0.2 계획).