Single-Slot Finality and the Signature-Aggregation Bottleneck TODO

Algorithms · Day 60 / 100 · D. Distributed Systems & Consensus (Day 52-68)

Concept

Ethereum's finality currently gets confirmed by accumulating epoch-scale votes over multiple slots, so it takes on the order of several minutes from a block's inclusion to its final confirmation. Single-slot finality (SSF) is a research direction aiming to gather the full validator set's votes within a single slot and finalize that slot's block immediately. The bottleneck lies less in the consensus rule itself than in systems engineering: when the validator count is very large, all signatures have to be collected, aggregated, verified, and propagated within the slot time. BLS signatures can aggregate many signatures into one, but the network propagation through an aggregation tree and the cost of handling the bitfield that records who participated both remain. So the discussion also includes reducing the validator count, hierarchical committee-based aggregation, and replacing aggregate verification with a proof.

Finality latency directly determines the safety threshold for bridge confirmation, exchange deposit crediting, and on-chain settlement, so it flows straight into service design.

Code & Formula

# 싱글슬롯 파이널리티와 서명 집계 병목 — 검증자 수가 늘수록 서명 집계·전파 비용이 커져
# 슬롯 시간 예산을 넘길 수 있음을 간단한 비용 모델로 보여준다.

SLOT_BUDGET_MS = 4000  # 예: 4초 슬롯

def aggregation_cost_ms(n_validators, per_signature_cost_us=2.0, tree_fanout=64):
    """BLS 서명 집계 비용을 흉내: 서명 검증/병합 비용 + 계층적 집계 트리를 통과하는 라운드 수"""
    merge_cost_ms = (n_validators * per_signature_cost_us) / 1000
    import math
    # 위원회 기반 계층적 집계: fanout마다 한 라운드, 각 라운드에 고정 전파 지연이 붙는다
    rounds = max(1, math.ceil(math.log(n_validators, tree_fanout))) if n_validators > 1 else 1
    propagation_ms_per_round = 150
    return merge_cost_ms + rounds * propagation_ms_per_round, rounds

print(f"슬롯 예산: {SLOT_BUDGET_MS}ms\n")
for n_validators in [1_000, 100_000, 1_000_000, 2_000_000]:
    cost_ms, rounds = aggregation_cost_ms(n_validators)
    remaining = SLOT_BUDGET_MS - cost_ms
    status = "여유 있음" if remaining > 0 else "슬롯 예산 초과!"
    print(f"검증자 {n_validators:>9,}명: 집계 비용 ≈ {cost_ms:7.1f}ms "
          f"(전파 {rounds}라운드) -> 잔여 {remaining:7.1f}ms -> {status}")

print("\n완화 방향 비교 (2,000,000 검증자 기준):")
baseline_cost, _ = aggregation_cost_ms(2_000_000, tree_fanout=64)
committee_cost, rounds = aggregation_cost_ms(2_000_000 // 100, tree_fanout=64)  # 위원회로 1/100 축소
print(f"  전체 검증자 직접 집계: {baseline_cost:.1f}ms")
print(f"  위원회(1/100) 기반 집계: {committee_cost:.1f}ms (라운드 {rounds}) "
      f"-> 슬롯 예산 내로 줄어듦: {committee_cost < SLOT_BUDGET_MS}")

docs/code/algorithms/algorithms-60.py

Exercise

Using the beacon chain API, directly measure how long it takes a specific transaction's block to reach justified and then finalized status after inclusion, and compare that against the confirmation threshold your own service uses.

Practical Connection

A prediction market doing on-chain settlement, like Verex, has to decide how many confirmations out to treat a result as final — understanding finality's precise meaning and its actual latency is what lets you balance reorg risk against user wait time.

Where it lands in Jayverse

• Verex: measure real finalized-status latency and set the confirmation threshold from it. Run the exercise on Sepolia/devnet blocks and use the actual inclusion-to-finalized time, not an assumed constant, revisiting it if devnet's chain config or finality model changes.
• Bridge: derive the Anvil-to-Sepolia mint confirmation requirement the same way. A too-low threshold is a reorg risk specifically on the mint side, so measure finality latency before fixing the bridge's confirmation count.
• gitboard: track finalization latency live. Expose inclusion-to-justified-to-finalized timing as a gitboard metric so a chain-config change is visible before it silently shifts Verex's or the Bridge's effective safety margin.

If you study this on a given day, add a note link and a ✅ to this line in the source curriculum (docs/knowledge/dev-100-curriculum.md) and this spot will lead straight to the note body. You can also write directly on this page — but regenerating overwrites it, so it's safer to keep anything you want to save as markdown under docs/algorithms/.

한국어

싱글슬롯 파이널리티와 서명 집계 병목 TODO

Algorithms · Day 60 / 100 · D. 분산시스템·합의 (Day 52–68)

개념

이더리움의 파이널리티는 현재 여러 슬롯에 걸친 에폭 단위 투표 누적으로 확정되므로, 블록이 포함된 뒤 최종 확정까지 수 분 수준의 시간이 걸린다. 싱글슬롯 파이널리티(SSF)는 한 슬롯 안에서 전체 검증자 집합의 투표를 모아 그 슬롯의 블록을 즉시 확정하려는 연구 방향이다. 병목은 합의 규칙 자체보다 시스템 공학 쪽에 있는데, 검증자 수가 매우 많을 때 슬롯 시간 안에 모든 서명을 수집·집계·검증하고 전파해야 하기 때문이다. BLS 서명은 다수를 하나로 집계할 수 있지만, 집계 트리를 통과하는 네트워크 전파와 누가 참여했는지를 나타내는 비트필드 처리 비용이 그대로 남는다. 그래서 검증자 수를 줄이는 방향, 위원회 기반 계층적 집계, 집계 검증을 증명으로 대체하는 접근 등이 함께 논의된다.

파이널리티 지연은 브리지 확정, 거래소 입금 인정, 온체인 정산의 안전 기준을 직접 결정하는 값이라 서비스 설계에 그대로 반영된다.

코드 · 수식

# 싱글슬롯 파이널리티와 서명 집계 병목 — 검증자 수가 늘수록 서명 집계·전파 비용이 커져
# 슬롯 시간 예산을 넘길 수 있음을 간단한 비용 모델로 보여준다.

SLOT_BUDGET_MS = 4000  # 예: 4초 슬롯

def aggregation_cost_ms(n_validators, per_signature_cost_us=2.0, tree_fanout=64):
    """BLS 서명 집계 비용을 흉내: 서명 검증/병합 비용 + 계층적 집계 트리를 통과하는 라운드 수"""
    merge_cost_ms = (n_validators * per_signature_cost_us) / 1000
    import math
    # 위원회 기반 계층적 집계: fanout마다 한 라운드, 각 라운드에 고정 전파 지연이 붙는다
    rounds = max(1, math.ceil(math.log(n_validators, tree_fanout))) if n_validators > 1 else 1
    propagation_ms_per_round = 150
    return merge_cost_ms + rounds * propagation_ms_per_round, rounds

print(f"슬롯 예산: {SLOT_BUDGET_MS}ms\n")
for n_validators in [1_000, 100_000, 1_000_000, 2_000_000]:
    cost_ms, rounds = aggregation_cost_ms(n_validators)
    remaining = SLOT_BUDGET_MS - cost_ms
    status = "여유 있음" if remaining > 0 else "슬롯 예산 초과!"
    print(f"검증자 {n_validators:>9,}명: 집계 비용 ≈ {cost_ms:7.1f}ms "
          f"(전파 {rounds}라운드) -> 잔여 {remaining:7.1f}ms -> {status}")

print("\n완화 방향 비교 (2,000,000 검증자 기준):")
baseline_cost, _ = aggregation_cost_ms(2_000_000, tree_fanout=64)
committee_cost, rounds = aggregation_cost_ms(2_000_000 // 100, tree_fanout=64)  # 위원회로 1/100 축소
print(f"  전체 검증자 직접 집계: {baseline_cost:.1f}ms")
print(f"  위원회(1/100) 기반 집계: {committee_cost:.1f}ms (라운드 {rounds}) "
      f"-> 슬롯 예산 내로 줄어듦: {committee_cost < SLOT_BUDGET_MS}")

docs/code/algorithms/algorithms-60.py

연습

비콘 체인 API로 특정 트랜잭션이 포함된 뒤 그 블록이 justified와 finalized 상태에 도달하기까지 걸린 시간을 직접 측정하고, 자기 서비스가 쓰는 확정 기준과 비교하라.

실무 · Verex 연결

Verex처럼 온체인 정산을 하는 예측시장은 결과 확정을 몇 컨펌 뒤로 볼지 정해야 하는데, 파이널리티의 정확한 의미와 실제 지연을 알아야 재조직 위험과 사용자 대기 시간 사이에서 균형을 잡을 수 있다.

Jayverse에서의 위치

• Verex: 실제 확정 상태 지연시간을 측정해서 확정 임계값을 거기서 도출한다. Sepolia/devnet 블록에 연습을 실행해서 가정한 상수가 아니라 실제 포함부터 확정까지의 시간을 사용한다, devnet의 체인 설정이나 확정 모델이 바뀌면 다시 측정한다.
• Bridge: Anvil-to-Sepolia 발행 확인 요건도 같은 방식으로 도출한다. 너무 낮은 임계값은 특히 발행 쪽에서 리오그 위험이므로, 브리지의 확인 수를 고정하기 전에 확정 지연시간을 측정한다.
• gitboard: 확정 지연시간을 실시간으로 추적한다. 포함부터 justified, finalized까지의 타이밍을 gitboard 지표로 노출해서 체인 설정 변경이 Verex나 Bridge의 실효 안전 마진을 조용히 바꾸기 전에 보이게 한다.

공부한 날 원본 커리큘럼(docs/knowledge/dev-100-curriculum.md)의 이 줄에 노트 링크와 ✅ 를 붙이면, 이 자리는 노트 본문으로 바로 이어집니다. 노트 없이 이 페이지에 바로 적어도 됩니다 — 다만 다시 생성하면 덮어쓰이므로, 남길 글은 docs/algorithms/ 의 마크다운으로 쓰는 편이 안전합니다.