솔라나 Proof of History는 합의가 아니라 시계다: 검증자가 순서를 확인하는 법

Proof of History(PoH)는 검증자들이 동의하는 투표 규칙 그 자체가 아니라, 순차 해시 계산에 사건을 삽입해 특정 데이터가 앞선 사건 뒤에 존재했고 일정 계산 시간이 지났음을 확인하게 하는 암호학적 시계입니다. 리더는 PoH 시퀀스에 거래 묶음과 tick을 기록하고 다른 검증자는 이를 병렬적으로 검증할 수 있습니다. 어느 분기를 채택하고 되돌리기 어렵게 만들지는 지분 가중 투표와 Tower BFT lockout이 담당하므로, 유효한 PoH 기록만 있다고 거래가 최종 확정된 것은 아닙니다.

PoH가 답하는 질문은 ‘무엇이 먼저였는가’다

분산된 검증자는 서로의 벽시계를 그대로 신뢰할 수 없습니다. 네트워크 지연 때문에 A 거래를 먼저 받은 노드와 B 거래를 먼저 받은 노드가 생깁니다. Solana 백서는 한 해시의 출력을 다음 SHA-256 입력으로 넣는 연속 계산을 만들고, 중간 상태에 사건의 해시를 결합합니다. 나중 상태가 앞선 상태를 입력으로 거쳤으므로 사건의 상대적 순서를 확인할 수 있습니다.

이 구조가 현실의 초 단위 시간을 완벽히 증명하는 것은 아닙니다. 정해진 횟수의 순차 계산이 진행됐다는 암호학적 증거에 가깝습니다. 공식 용어집도 PoH를 데이터가 증명 생성 전에 존재했고 이전 증명 이후 정밀한 시간이 흘렀음을 보이는 증명 묶음으로 정의합니다. 따라서 ‘오후 3시 1초’라는 외부 시각보다 ledger 안 사건의 순서와 계산 경과를 제공하는 시계로 이해하는 편이 정확합니다.

PoH는 검증자가 무엇에 동의해야 하는지를 정하지 않고, 동의할 사건의 순서를 빠르게 대조할 기준을 제공한다.

JOBCOIN 해설

VISUAL GUIDE블록을 제안하고 검증하는 과정

1. 01
   PoH가 답하는 질문은 ‘무엇이 먼저였는가’다

   분산된 검증자는 서로의 벽시계를 그대로 신뢰할 수 없습니다.

2. 02
   연속 생성과 병렬 검증이 함께 가능한 이유

   PoH 생성자는 해시 0에서 해시 1, 다시 해시 2로 순서대로 계산해야 합니다.

3. 03
   리더는 tick과 거래를 하나의 기록 흐름에 놓는다

   리더는 일정 슬롯 동안 PoH를 생성하면서 tick entry와 거래가 포함된 entry를 ledger에 놓습니다.

AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

연속 생성과 병렬 검증이 함께 가능한 이유

PoH 생성자는 해시 0에서 해시 1, 다시 해시 2로 순서대로 계산해야 합니다. 뒤의 값을 먼저 구할 수 없다는 직렬성이 시간 경과의 기반입니다. 반면 결과와 중간 체크포인트를 받은 검증자는 전체 구간을 여러 조각으로 나눠 각각의 해시 연쇄가 맞는지 병렬 확인할 수 있습니다. 생성보다 검증을 빠르게 분산할 여지가 여기서 생깁니다.

가정 예시로 1,000회 해시마다 체크포인트가 있고 총 10,000회를 확인한다고 하겠습니다. 생성자는 1번부터 10,000번까지 차례로 진행하지만, 검증자는 체크포인트 10개 사이 구간을 여러 코어에 나눌 수 있습니다. 이 숫자는 개념 설명용 가정이며 실제 클러스터 속도나 tick 설정이 아닙니다. 핵심은 순차성의 대상이 생성이고, 검증에는 구간 분할이 가능하다는 비대칭입니다.

리더는 tick과 거래를 하나의 기록 흐름에 놓는다

리더는 일정 슬롯 동안 PoH를 생성하면서 tick entry와 거래가 포함된 entry를 ledger에 놓습니다. 공식 용어집에서 entry id는 앞선 entry의 최종 내용에 대한 해시이며, 해당 entry가 시간 경과 뒤 생성됐고 지정된 거래가 포함됐으며 ledger 내 위치가 어디인지에 대한 증거가 됩니다. 거래가 없는 동안에도 tick이 이어지기 때문에 다음 사건은 앞선 체크포인트와 연결됩니다.

여기서 ‘기록됐다’와 ‘확정됐다’를 나눠야 합니다. 악의적이거나 네트워크에서 고립된 리더도 자신만의 해시 연쇄를 계산할 수 있습니다. 다른 검증자가 거래 실행과 기록을 확인하고 어느 분기에 투표하는 절차를 통과해야 클러스터의 합의된 이력이 됩니다. PoH의 유효성은 필요한 조건이지만 합의의 충분조건이 아닙니다.

• PoH 상태가 앞선 상태와 올바른 해시 연쇄로 연결되는지 확인한다
• entry에 포함된 거래 목록이 entry hash와 일치하는지 대조한다
• 각 거래의 서명, recent blockhash, 계정 상태와 프로그램 실행을 별도로 검사한다
• 검증자 투표가 어느 슬롯과 분기를 가리키는지 지분 가중치로 집계한다
• confirmed·finalized 같은 RPC 상태를 서비스 자체의 입금 확인 정책과 구분한다

Tower BFT의 lockout이 되돌림 비용을 키운다

Solana Foundation의 Tower BFT 설명은 PoH를 합의 이전에 작동하는 공통 시간 원천으로 둡니다. 검증자는 자신이 관측한 분기에 투표하며, 연속 투표가 쌓일수록 이전 투표의 lockout이 늘어납니다. 이전 투표와 충돌하는 분기로 옮기려면 lockout 조건을 만족해야 하므로 오래 지지된 이력을 버리는 비용이 커집니다.

이 때문에 ‘PoH가 빠르니 즉시 최종성’이라는 문장은 두 단계를 섞습니다. PoH가 리더와 검증자 사이의 시간 조정 부담을 줄이는 것과, 충분한 지분 투표가 누적되어 분기가 되돌리기 어려워지는 것은 다른 메커니즘입니다. 특정 거래 상태를 설명할 때는 블록 생성 속도, confirmation status, root 진행을 각각 확인해야 합니다.

탐색기에서 PoH를 직접 봤다고 말하기 어려운 이유

일반 탐색기는 slot, block time, confirmation status, transaction result를 보여 주지만 연속 해시의 모든 중간 계산을 사용자 화면에 펼치지는 않습니다. slot 번호가 증가했다고 해서 모든 slot에 블록이 있는 것도 아니며, block time은 외부 시각 추정치이지 PoH 해시 횟수 자체가 아닙니다. 화면의 시각 정보만으로 PoH 성능이나 합의 안전성을 계산할 수 없습니다.

실무에서는 질문을 좁히는 편이 낫습니다. 거래가 실행됐는지는 status와 error를, 어느 블록에 들어갔는지는 slot을, 되돌림 가능성이 얼마나 줄었는지는 confirmation과 root를 봅니다. 리더 스케줄은 누가 해당 슬롯 생산을 맡았는지 설명하지만 실제 생산 성공까지 보장하지 않습니다. 이 분리는 네트워크 지연과 합의 실패를 잘못 진단하는 일을 줄입니다.

PoH 설명을 검증하는 세 가지 반문

첫째, 설명이 해시 순서와 검증자 투표를 같은 단계라고 말하는지 확인합니다. 둘째, 유효한 연쇄를 곧 canonical chain이라고 단정하는지 봅니다. 셋째, slot 시간이나 초당 거래량 같은 운영 수치를 백서의 설계 목표와 섞는지 확인합니다. 운영 파라미터는 클라이언트 버전과 클러스터 상태에 따라 바뀔 수 있으므로 현재 공식 문서나 RPC를 별도로 확인해야 합니다.

정확한 요약은 다음과 같습니다. PoH는 거래와 tick을 검증 가능한 순서에 배치하는 시계입니다. 거래 유효성은 런타임이 검사하고, 분기 선택과 확정 강도는 검증자 투표가 만듭니다. 세 층 중 하나의 성공을 나머지 둘의 성공으로 확대하지 않으면 솔라나의 빠른 처리 경로와 남는 합의 조건을 함께 볼 수 있습니다.

확인일 현재 공식 Alpenglow 페이지는 Agave 4.3의 Votor가 Tower BFT 투표를 대체할 단계라고 설명하면서 상태를 ‘In development’로 표시합니다. 그러므로 Tower BFT 설명은 기존 합의 구조를 이해하는 근거이고, Votor 제안은 개발 중 전환 상태로 구분해야 합니다. 버전 활성화와 클러스터 적용을 별도 확인하지 않은 채 이미 교체가 완료됐다고 단정하지 않습니다.

자주 묻는 질문