---
title: "Proof of History: 기록 순서, Tick, Slot 및 합의 경계"
description: "역사 증명은 Solana의 순차 해시 체인 시계입니다. 이를 통해 생산자의 기록된 주문 및 계산 수를 확인할 수 있지만 벽시계 시간, 공정한 거래 도착 순서, 포크 선택 또는 최종성을 독립적으로 증명하지는 않습니다."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Proof of History: 기록 순서, Tick, Slot 및 합의 경계
> 프로토콜 분석을 위한 교육 자료일 뿐 투자, 검증자 운영, 성능 또는 보안 조언이 아닙니다. Proof of History 매개변수, 클라이언트 동작, 리더 일정, 투표, 포크 선택 및 확인 규칙은 네트워크와 소프트웨어 버전에 따라 달라질 수 있습니다.
## 직접적인 답변
역사 증명(PoH)은 Solana의 암호화 시계 및 원장 순서 데이터 구조입니다. 생산자는 각 출력이 이전 출력에 종속되도록 해시 함수를 반복적으로 적용하고, 주기적으로 개수와 상태를 기록하고, 트랜잭션에서 파생된 데이터를 체인에 혼합합니다. 검증자는 이러한 전환을 다시 계산하고 해당 특정 체인에 기록된 순서를 확인할 수 있습니다.
PoH는 독립형 합의 알고리즘이 아닙니다. 이는 정식 포크를 선택하거나, 지분 가중 계약을 제공하거나, 블록을 확정하거나, 특정 상용 시간에 거래가 네트워크에 도달했음을 증명하지 않습니다. Solana는 시계를 예정된 리더, 거래 실행, 검증자 투표, 포크 선택 및 Tower BFT 스타일 잠금과 결합합니다. 두 개의 포크에는 각각 내부적으로 유효한 PoH 시퀀스가 포함될 수 있습니다. 합의 규칙은 네트워크가 따르는 기록을 결정합니다.
이 보장의 범위는 제한적입니다. 항목이 상태 h2 뒤에 데이터 d를 커밋했다면 그 커밋 없이는 후속 상태 h3 = H(h2 || d)를 계산할 수 없습니다. 이는 생성자가 h3 계산 전에 d를 알고 있었고 후속 출력에 대한 기록 위치가 고정됐음을 보여 줍니다. 각 검증자의 수신 시점, 리더가 도착 순서대로 포함했는지, d가 실제 외부 사건을 나타내는지, 해당 항목이 정식 기록이 됐는지는 증명하지 않습니다.
이전 해시가 존재할 때까지 다음 입력을 알 수 없으므로 생성은 순차적입니다. 게시된 경계 상태를 통해 검증자는 별도의 경계 세그먼트를 병렬로 재생할 수 있지만 집계 해시 작업은 그대로 유지됩니다. 이러한 이유로 PoH는 종종 검증 가능한 지연 기능과 비교되는 반면, Solana의 자체 Tower BFT 설명에서는 해당 용어를 느슨하게 사용한다고 부릅니다. 공식 VDF에는 일반적으로 순차적 평가에 비해 검증이 효율적인 평가 및 검증 인터페이스가 있습니다.
## 역사 증명 분석 방법
1. **네트워크와 소프트웨어 전제를 고정합니다.** 네트워크, 제네시스 해시, 슬롯, 에포크, Agave 또는 다른 클라이언트 버전과 관찰 시점을 기록합니다. hashes_per_tick, ticks_per_slot, ns_per_slot의 실제 적용 값을 확인하고 이전 문서나 다른 클러스터의 상수를 가져오지 마십시오.
2. **해시 체인을 재구성합니다.** 신뢰할 수 있는 이전 상태에서 시작하여 각 항목의 num_hashes, 결과 해시 및 트랜잭션 목록을 확인합니다. Agave의 항목 구현에서 항목 식별자는 이전 항목에 따라 달라지며, 트랜잭션이 있는 경우 해당 서명에서 파생된 해시에 따라 달라집니다.
3. **진드기와 슬롯 배치를 확인합니다.** 틱 항목, 예상 해시 수, 틱 높이 및 최대 틱 높이를 은행 및 레코더 규칙과 비교하여 확인하세요. 레코더는 구성된 ticks_per_slot를 사용하여 틱 높이를 슬롯에 매핑합니다. 슬롯은 프로토콜 간격이며 외부 시계의 독립적인 증거가 아닙니다.
4. **도착과 포함을 구별하십시오.** 약속은 입력이 해당 시퀀스에 삽입된 이후에 알려졌음을 증명합니다. 하한을 요구하려면 이전 PoH 상태에 대한 서명된 역참조를 식별하십시오. 어느 경계도 글로벌 최초 공개 순서, 멤풀 공정성 또는 신뢰할 수 있는 UTC 타임스탬프를 증명하지 못합니다.
5. **검증과 생성을 분리합니다.** 하나의 종속성 체인에서 순차 생산을 측정한 다음 인증된 세그먼트 경계와 사용 가능한 코어를 사용하여 재생을 측정합니다. 단순히 검증이 "빠르다"고 말하는 대신 총 해시, 중요 경로 대기 시간, 집계 검증 작업 및 경계 데이터 가정을 보고합니다.
6. **합의 경로를 추적합니다.** 예정된 리더, 은행 상태, 투표, 잠금, 포크 선택 규칙, 루팅 또는 최종 상태 및 약속 수준을 식별합니다. 유효한 PoH 체인은 여전히 손실되는 포크에 속할 수 있으며, 더 길어 보이는 카운터 자체는 합의 인증서가 아닙니다.
7. **적대적 및 작전적 사례를 강조합니다.** 테스트 리더 모호함, 트랜잭션 누락 및 재정렬, 건너뛴 슬롯, 파티션, 더 빠르거나 잘못 보정된 하드웨어, 유효하지 않은 틱 수, 지연된 재생, 원장 비가용성, 클라이언트 발산 및 상관된 운영자 또는 인프라 제어.
검토 결과는 시퀀스 유효성, 구성된 프로토콜 시간, 합의 상태 및 외부 시간이라는 네 가지 주장을 구별해야 합니다. 신뢰할 수 있는 시작 해시 및 원장 데이터, 다시 계산된 해시, 확인된 투표 또는 약속 증거, 로컬 시계 또는 타사 서비스에서 얻은 관찰을 명시합니다.
## 실제 사례
### 1. 데이터 삽입으로 기록된 위치 수정
h1 = H(h0)를 고려한 다음 h2 = H(h1)를 고려하십시오. 생산자는 거래에서 파생된 약정 d를 삽입하고 h3 = H(h2 || d)를 계산한 다음 h4 = H(h3)를 계산합니다. 동일한 작업을 재생하는 사람은 누구나 기록된 체인이 h2와 h3 사이에서 d를 커밋하고 h4가 결과에 따라 달라지는 것을 확인할 수 있습니다.
상한 설명은 좁습니다. 생산자는 h3를 계산하기 전에 d를 알고 있었습니다. 서명된 트랜잭션 자체가 h1를 참조하는 경우 검증자는 서명 및 출처 확인을 거쳐 해당 트랜잭션이 이전 상태를 알고 난 후에 형성되었음을 보여줄 수도 있습니다. 이러한 역참조가 없으면 PoH만으로는 하한을 제공하지 않습니다. 두 경우 모두 다른 노드가 처음으로 트랜잭션을 수신한 시기를 증명하지 못합니다.
### 2. 세그먼트 재생은 작업 집계가 아닌 대기 시간을 줄입니다.
기록된 간격에 1,000,000개의 해시가 포함되어 있고 인증된 체크포인트가 이를 100,000개의 해시로 구성된 10개 세그먼트로 나눈다고 가정합니다. 코어가 충분하면 10개의 세그먼트를 동시에 재생할 수 있으므로 벽시계 확인 대기 시간은 한 세그먼트의 지속 시간과 오버헤드에 가까워질 수 있습니다.
검증자는 전체적으로 여전히 1,000,000개의 해시를 실행합니다. 체크포인트는 독립적인 시작 상태를 노출하지만 체인을 간결한 증명으로 바꾸지는 않습니다. 성능은 하드웨어, 스케줄링, 메모리 이동 및 경계에 대한 신뢰도에 따라 달라집니다. 이것이 병렬 PoH 재생이 모든 공식 VDF 구성의 효율적인 검증 알고리즘으로 자동 설명되어서는 안되는 이유입니다.
### 3. 틱 및 슬롯 연산은 구성에 따라 다릅니다.
hashes_per_tick = 100,000 및 ticks_per_slot = 8를 사용한 예시적인 구성을 가정합니다. 완전히 해시된 슬롯에는 구성된 각 간격 이후의 틱 경계와 함께 100,000 * 8 = 800,000 해시가 포함됩니다. 매개변수 중 하나를 변경하면 매핑이 변경됩니다. 이 예시는 현재 메인넷 상수가 아닙니다.
Agave는 이 단순한 곱셈으로 표현되지 않는 해시 개수 설정도 지원합니다. 검토자는 Bank의 실제 필드를 확인하고 클라이언트 규칙에 따라 항목을 검증해야 합니다. 슬롯이나 개수를 초로 환산하려면 암호 검증뿐 아니라 목표 시간 보정과 실제 실행 관찰도 필요합니다.
### 4. 기록 순서는 도착 순서나 최종성과 다릅니다
트랜잭션 A가 트랜잭션 B보다 먼저 리더에 도달했지만 리더가 B를 300,000 근처에 기록하고 A를 450,000 근처에 기록했다고 가정합니다. 유효한 PoH는 생성된 시퀀스에서 B가 A보다 앞에 있음을 증명합니다. B가 먼저 도착했는지, 명령이 공정했는지, 다른 리더가 동일한 명령을 준수했는지는 증명되지 않습니다.
이제 파티션이 각각 유효한 시퀀스를 갖는 포크 X와 포크 Y를 생성한다고 가정합니다. PoH 검증은 두 포크 모두에서 잘못된 형식의 항목을 거부할 수 있지만 X 또는 Y를 선택하지는 않습니다. 리더 일정, 지분 가중 투표, 잠금, 포크 선택 및 요청된 약속 수준이 합의 결과를 결정합니다. 애플리케이션은 확인 또는 최종 증거를 PoH 카운트로 대체해서는 안 됩니다.
## 위험 및 검토 실패
### 암호화 및 타이밍 오류
- PoH를 신뢰할 수 있는 벽시계로 호출하거나 독립적으로 해시 카운트를 요청하면 UTC 타임스탬프가 증명됩니다.
- 트랜잭션 포함은 네트워크 전체의 수신 시간, 처음 본 순서 또는 외부 데이터의 진실성을 입증합니다.
- 순차적 생성을 가정하면 생산자가 알려진 데이터를 삽입할 시기를 보류, 생략 또는 선택하는 것을 방지할 수 있습니다.
- 충돌 저항만을 하드웨어 속도, 보정 드리프트 또는 구현 차이에 대한 완전한 한계로 간주합니다.
- 병렬 세그먼트 재생을 작업이 전혀 필요하지 않거나 집계 해시를 계산하지 않고 간결한 증명으로 설명합니다.
- 비교되는 구성, 증명 인터페이스 및 검증 가정을 명시하지 않고 PoH를 공식 VDF로 호출합니다.
- 출처를 인증하지 않고 체크포인트 경계, 이전 해시 또는 다운로드된 원장 세그먼트를 신뢰합니다.
### 합의 및 프로토콜 오류
- PoH 합의, 지분 증명, Tower BFT, 리더 선택, 포크 선택 및 최종성을 동일한 메커니즘이라고 부릅니다.
- 가장 높은 수의 유효한 시퀀스를 가정하면 투표 및 포크 선택 상태를 조사하지 않고 정식이어야 합니다.
- 요청된 커밋 의미 체계를 확인하지 않고 로컬로 재생된 항목을 확인, 루팅 또는 종료된 항목으로 처리합니다.
- 과거 hashes_per_tick, ticks_per_slot 또는 슬롯 시간을 현재도 보편적으로 유효한 상수로 사용합니다.
- 순서를 재구성할 때 건너뛴 슬롯, 리더 회전, 파티션, 모호함, 클라이언트 버전 차이를 무시합니다.
- 마치 하나의 인증된 시퀀스에 속한 것처럼 관련되지 않은 포크 또는 시작 상태의 개수를 비교합니다.
- 트랜잭션의 최근 블록해시가 프로토콜 유효성 컨텍스트가 아닌 벽시계 타임스탬프일 뿐이라고 가정합니다.
### 운영, 성능 및 제어 오류
- 실행, 서명 확인, 재생, 대역폭 및 저장 공간을 무시하고 해시 생성만 벤치마킹합니다.
- CPU, I/O 및 메모리 경합에서 관찰된 검증인 따라잡기와 이론적 세그먼트 병렬성을 동일시합니다.
- 진드기 검증 실패, 기록 중단, 뱅킹 지연, 원장 공백, 스냅샷 신뢰 및 손상된 상태를 무시합니다.
- 클라이언트, 호스팅, 네트워킹, 리더 인프라 또는 제어가 공유될 때 검증인 ID를 독립적인 것으로 계산합니다.
- 더 빠른 하드웨어가 네트워크 대기 시간, 패킷 손실, 검열, 서비스 거부 또는 지분 집중 위험을 제거한다고 가정합니다.
- 서비스 수준 보장으로 대상 슬롯 기간, 처리량 추정 또는 이전 벤치마크를 제시합니다.
## 일반적인 오해
- **PoH는 Solana의 완전한 합의 알고리즘입니다.** PoH는 검증 가능한 기록 시퀀스를 제공합니다. 검증인 투표, 잠금, 포크 선택 및 기타 합의 규칙은 네트워크에 따른 기록을 결정합니다.
- **PoH는 모든 거래의 정확한 실제 시간을 증명합니다.** 인증된 시퀀스 내에서 종속성과 개수를 증명합니다. 해당 시퀀스를 상용시로 매핑하려면 구성과 외부 관찰이 필요합니다.
- **PoH는 공정한 거래 순서를 보장합니다.** 리더는 프로토콜과 자원 제약 안에서 입력을 선택, 지연, 재정렬 또는 생략할 수 있습니다. PoH가 감사 가능하게 만드는 것은 그 결과 기록된 순서입니다.
- **PoH는 또 다른 이름의 작업증명 채굴입니다.** 둘 다 해싱을 사용하지만 PoH의 핵심 역할은 순차 시계이며, 승리한 작업이 체인을 선택하는 개방형 병렬 경주가 아닙니다.
- **유효한 PoH 시퀀스는 최종입니다.** 경쟁 포크는 각각 내부적으로 유효할 수 있습니다. 확인과 최종성을 위해서는 네트워크의 합의 증거가 필요합니다.
## 관련 주제
- [합의 메커니즘](/ko/crypto/consensus-mechanism/)
- [지분 증명](/ko/crypto/proof-of-stake/)
- [검증인](/ko/crypto/validator/)
- [포크 선택 규칙](/ko/crypto/fork-choice-rule/)
- [블록타임](/ko/crypto/block-time/)
## 출처
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST(액세스됨: 2026-08-19)
- [Solana: A New Architecture for a High Performance Blockchain](https://solana.com/solana-whitepaper.pdf) - Solana(액세스됨: 2026-08-19)
- [Tower BFT: Solana's High Performance Implementation of PBFT](https://solana.com/news/tower-bft--solana-s-high-performance-implementation-of-pbft) - Solana(액세스됨: 2026-08-19)
- [Agave Entry Module](https://github.com/anza-xyz/agave/blob/master/entry/src/entry.rs) - Anza(액세스됨: 2026-08-19)
- [Agave Proof-of-History Recorder](https://github.com/anza-xyz/agave/blob/master/poh/src/poh_recorder.rs) - Anza(액세스됨: 2026-08-19)
- [Agave Bank Runtime](https://github.com/anza-xyz/agave/blob/master/runtime/src/bank.rs) - Anza(액세스됨: 2026-08-19)
- [Transaction Confirmation and Expiration](https://solana.com/developers/cookbook/transactions/confirmation) - Solana(액세스됨: 2026-08-19)
- [Verifiable Delay Functions](https://eprint.iacr.org/2018/601) - IACR 암호화 ePrint 아카이브(액세스: 2026-08-19)
Source: https://wiki.fcontext.com/ko/crypto/proof-of-history/index.mdx