---
title: "나카모토 합의: 유효성, 체인워크, 확인, 체인 재구성"
description: "나카모토 합의는 각 노드가 독립적으로 집행하는 유효성 규칙, 허가 없는 작업증명 블록 생성, 전파, 누적 작업량이 가장 큰 유효 체인 선택을 결합한다. 로컬 관측, 체인워크, 확인, 재구성, 공통 접두부 가정, 인센티브, 네트워크 공격을 분리해 분석한다."
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.
# 나카모토 합의: 유효성, 체인워크, 확인, 체인 재구성
> 교육 참고용이며 투자 조언이 아닙니다. 투자로 인해 손실이 발생할 수 있습니다.
## 직접 답변
나카모토 합의는 노드가 합의 유효성 규칙을 독립적으로 집행하고, 허가된 구성원 명단 없이 작업증명 생산자가 블록을 연장하며, 블록이 P2P 네트워크로 전파되고, 각 노드가 누적 작업증명이 가장 큰 유효 분기를 선택하는 Bitcoin 방식의 절차다. 이는 노드가 관측한 상태에서 프로토콜상 유효한 거래를 순서화하지만, 무효 거래를 유효하게 만들거나 원장 밖의 사실을 판정하거나 즉시 결정론적 최종성을 만들지는 않는다.
유효성 검사가 체인 선택보다 먼저다. 헤더, 작업증명, 거래, 스크립트, 이미 사용된 출력, coinbase 금액 또는 블록 한도가 무효인 분기는 주장하는 높이나 작업량과 무관하게 거부된다. 노드 규칙을 통과하고 데이터가 제공된 분기 사이에서는 블록 수가 아니라 누적 체인워크가 활성 체인을 정한다. 따라서 “가장 긴 체인”은 작업증명 투입이 가장 많은 유효 체인을 가리키는 비공식 약칭이다.
활성 팁은 잠정적이다. 경쟁하는 유효 블록 때문에 연결이 양호한 정직한 노드도 잠시 서로 다른 로컬 관측을 가질 수 있다. 추가 작업이 보통 포크를 해소하며 노드는 체인 재구성에서 한 분기를 끊고 다른 분기를 연결할 수 있다. 거래 확인 수는 관측자의 현재 활성 체인 안에서 깊이를 나타낸다. 명시한 해시레이트와 네트워크 모형에서 깊이가 늘면 추격 확률이 낮아질 수 있지만 보편적으로 최종적인 확인 수는 없다.
이 용어는 해싱만 뜻하지 않는다. 보안 논증은 블록과 거래 유효성, P2P 전파, 최다 작업 유효 체인의 정직한 채택, 충분한 정직 측 유효 채굴력, 경제적 행동, 사용자가 의도한 네트워크와 소프트웨어를 독립적으로 관측하는 능력에도 의존한다. 공통 접두부, 체인 성장, 체인 품질은 명시된 모형 안에서만 증명되는 형식적 속성이며, 배포된 모든 작업증명 체인의 무조건적 사실이 아니다.
## 나카모토 합의 분석 방법
1. **신원과 관측 범위를 고정한다.** `chain`, `network`, `genesis hash`, `client version`, 합의 규칙 집합, 체크포인트 또는 assume-valid 설정, 관측자, 피어, 시각을 기록한다. `bestblockhash`, `height`, `chainwork`를 보존한다. 메시지가 전파되는 동안 두 노드는 정직하게 서로 다른 팁을 보고할 수 있다.
2. **작업량 비교 전에 검증한다.** 헤더 연결, 타임스탬프 제약, 디코딩한 목표, 작업증명, Merkle 및 witness 커밋먼트, 거래, 스크립트, UTXO 지출, coinbase, 블록 자원 한도를 확인한다. `invalid` 분기는 더 높은 높이나 작업량을 주장해도 후보 자격을 얻지 못한다.
3. **관측한 블록 트리를 재구성한다.** 이전 블록 해시로 각 후보를 알려진 조상에 연결하고 완전한 블록과 헤더만 있는 데이터를 구분한다. `active`, `valid-fork`, `valid-headers`, `headers-only`, `invalid` 상태를 `getchaintips` 같은 인터페이스로 대조하며, 보이는 모든 팁을 유효 경쟁 체인이라 부르지 않는다.
4. **누적 작업량을 다시 계산한다.** 각 헤더의 `nBits` 목표를 디코딩하고 구현의 정수 규칙에 따라, 개념적으로 `work = floor(2^256 / (target + 1))`인 작업량을 계산한다. 조상 경로를 따라 합산하고 공통 조상부터 유효 분기를 비교한다. 높이, 추정 해시 수, 풀 이름은 체인워크를 대신하지 못한다.
5. **선택과 재구성을 추적한다.** 노드의 최다 작업 후보 선택, 작업량이 같을 때의 로컬 순서와 도착 상태를 재현한다. 더 나은 유효 분기가 나타나면 포크 지점을 찾고, 기존 접미부를 끊고, 새 접미부를 연결하고, `UTXO set`을 갱신한 뒤 `mempool` 및 애플리케이션 기록과 거래를 대조한다.
6. **위험 기반 확인 정책을 정한다.** 현재 활성 체인의 블록에만 `confirmations = tip_height - block_height + 1`을 계산한다. 위험 금액, 가역성, 공격자 점유율, 전파, eclipse 노출, 관측된 stale 비율, 확인 깊이, 대응 계획을 명시한다. 6회 확인은 관행이지 프로토콜 최종성 임계값이 아니다.
7. **전체 보안 논증을 스트레스 테스트한다.** 분할, 지연, 블록 은닉, selfish mining, eclipse 공격, 풀과 하드웨어 집중, 급격한 해시레이트 변화, 수수료와 보조금 인센티브, 클라이언트 불일치, 깊은 재구성, 복구 정책을 시험한다. 공통 접두부, 체인 성장, 체인 품질, 지속성, 활성성에 대한 결론은 인용한 모형의 가정 안에서만 적용한다.
결과물은 특정 관측자가 어느 유효 이력을 현재 선택하며 그 이유가 무엇인지 재현 가능한 설명이어야 한다. 합의 규칙은 후보 자격을 정하고, 작업증명은 대체 이력 비용을 높이며, 전파는 작업을 다른 노드에 알리고, 포크 선택은 현재 이력을 고르며, 확인 정책은 애플리케이션의 행동 시점을 정한다. 이를 모두 “네트워크 승인”이라는 한 표현으로 합치면 실패할 수 있는 조건이 가려진다.
## 계산 예시
### 1. 무효한 작업은 승리하지 못한다
분기 A가 `valid_A = false`와 `chainwork_A = 1,200 units`를 보고하고 분기 B가 `valid_B = true`와 `chainwork_B = 1,000 units`를 가진다고 하자. 노드는 A를 거부하고 B를 선택한다. 작업량은 자격 있는 후보 사이에서만 비교되며, 작업증명은 과도한 coinbase, 무효 서명 또는 이중 지출을 허가할 수 없다.
한 관측자가 A의 헤더만 갖고 다른 관측자가 완전한 블록 데이터를 가진 경우 다운로드와 검증이 끝날 때까지 상태가 다를 수 있다. 헤더가 유효한 분기는 모든 거래와 상태 전이가 완전히 검증됐다는 증거가 아니다.
### 2. 높이는 누적 작업량이 아니다
목표가 달라지는 단순 예에서 분기 C가 블록당 100 작업 단위인 블록 6개를 추가하면 `6 * 100 = 600 units`다. 분기 D가 블록당 130 단위인 블록 5개를 추가하면 `5 * 130 = 650 units`다. 둘 다 유효하고 시작 작업량이 같다면 D는 한 블록 짧아도 최다 작업 분기다.
유효한 두 팁이 정확히 `650 units`라면 같은 작업량이 모든 노드에 즉시 같은 팁을 강제하지 않는다. 도착 순서와 로컬 구현 상태는 다음 유효 블록이 한 분기를 더 무겁게 만들 때까지 다를 수 있다. 일시적인 동률 관측을 결정론적 전역 최종성이라고 설명해서는 안 된다.
### 3. 확인은 제거될 수 있다
거래가 높이 `100` 블록에 포함되고 활성 팁이 높이 `105`라면 확인 수는 `tip_height - block_height + 1 = 105 - 100 + 1 = 6 confirmations`다. 다른 유효 분기가 높이 99 다음에서 갈라져 이 거래 없이 높이 106에서 최다 작업 분기가 됐다고 하자. 재구성은 기존 블록 `100 through 105`를 끊는다. 거래는 활성 체인의 6회 확인을 잃고 mempool로 돌아가거나 다른 지출과 충돌하거나 계속 포함되지 않을 수 있다.
애플리케이션은 숫자 6만 저장하지 말고 블록 해시와 조상 관계를 대조해야 한다. 거래소 입금, 인도한 상품, 브리지 메시지, 파생상품 결제는 원천 체인 이력이 바뀔 수 있어도 경제적으로 되돌릴 수 없을 수 있다.
### 4. 추격 확률은 모형에 의존한다
Bitcoin 백서의 예시 모형에서 공격자 해시 비율을 `q = 0.10`, 정직 측 비율을 `p = 0.90`, 정직 체인의 선두를 `z = 6`이라 하자. Poisson 근사는 `lambda = z * (q / p) = 0.6666667`과 `P(catch up) = 0.0002428027 = 0.02428027%`를 준다. 같은 깊이에서 `q = 0.30`이면 결과는 `P(catch up) = 0.1321111687 = 13.21111687%`로 상승한다.
이 수치는 현재 Bitcoin의 보장이 아니다. 계산은 안정적이고 독립적인 해시 시도와 모형의 경쟁 조건을 가정하며 eclipse 격리, 전파 우위, selfish 전략, 가격과 대여 반응, 구현 버그, 애플리케이션 대응을 제외한다. 정책은 모형을 공개하고 6회 확인만 인용하지 말고 더 나쁜 조건을 시험해야 한다.
## 위험과 검토 실패
### 프로토콜 및 측정 오류
- 헤더, 블록 본문, 조상을 독립 검증하기 전에 작업량을 비교한다.
- 누적 체인워크를 계산하지 않고 가장 높거나 먼저 본 분기를 승자라 한다.
- 블록 수, 명목 해시레이트, 풀 점유율, 탐색기 표시를 체인워크 대용으로 쓴다.
- mainnet, testnet, signet, 포크, 클라이언트 버전, 체크포인트, genesis 신원을 혼합한다.
- 헤더만 있거나 데이터가 없거나 낙관적인 상태를 완전히 검증된 이력으로 취급한다.
- 목표 디코딩, 정수 작업량 산술, 이전 해시 연결 또는 공통 조상을 무시한다.
- 해시, 높이, 시각, 피어 맥락 없이 하나의 RPC나 탐색기를 전역 관측으로 본다.
### 네트워크, 인센티브 및 통제 오류
- 전파가 즉시 이뤄지고 모든 노드의 거래와 블록 도착 순서가 같다고 가정한다.
- 작업량 동률을 일시적 로컬 관측이 아니라 하나의 전역 결정 상태로 취급한다.
- stale 블록, 지연, 은닉, selfish mining, 전파 우위를 무시한다.
- 풀 이름에서 독립 채굴자를, 풀 점유율에서 실제 하드웨어 소유권을 추론한다.
- 풀, 펌웨어, 제조사, 호스팅, 에너지, 지역, 네트워크 집중을 무시한다.
- 보상이 모든 참여자에게 정직한 연장이 언제나 최적이라는 증거라고 본다.
- eclipse, partition, Sybil, 피어 오염, 서비스 거부, 시간 조작 노출을 누락한다.
### 결제 및 보안 오류
- 확인을 프로토콜 최종성이라 부르거나 6회 확인은 제거될 수 없다고 약속한다.
- 모든 금액, 상대방, 가역성, 위협 모형에 같은 확인 수를 적용한다.
- 백서 확률 예시를 현재 측정된 공격 확률로 바꾼다.
- 다수 해시 파워가 서명을 위조하고 임의 코인을 빼앗거나 무효 인플레이션을 승인할 수 있다고 말한다.
- 소수 해시 파워는 수익성 있는 이탈이나 어떤 재구성 또는 검열도 할 수 없다고 말한다.
- 현재 최다 작업 팁을 올바른 외부 사실, 법적 소유권 또는 애플리케이션 결제와 동일시한다.
## 흔한 오해
- **가장 긴 체인은 언제나 블록 수가 가장 많다.** Bitcoin 노드는 누적 작업량이 가장 큰 유효 체인을 선택하며 목표가 다르면 높이만으로는 부족하다.
- **채굴자가 어떤 프로토콜 규칙이 유효한지 정한다.** 채굴자는 블록을 제안하고 각 풀 노드는 설정된 합의 규칙을 독립적으로 집행한다.
- **6회 확인은 절대적 최종성을 만든다.** 6은 애플리케이션 관행이며 재구성 확률은 모형, 깊이, 공격자, 전파, 관측 무결성에 달려 있다.
- **51% 공격자는 누구의 코인이든 쓸 수 있다.** 해시 파워는 재구성, 이중 지출, 검열 전략을 지원할 수 있지만 다른 사용자의 개인키 서명을 제공하거나 변경되지 않은 풀 노드가 무효 인플레이션을 받게 하지는 못한다.
- **총 해시레이트가 높으면 탈중앙화와 안전성이 증명된다.** 실효 통제, 네트워크 가시성, 하드웨어 접근, 풀 조정, 클라이언트 다양성, 인센티브, 공격 기간도 중요하다.
## 관련 주제
- [작업증명](/ko/crypto/proof-of-work/)
- [포크 선택 규칙](/ko/crypto/fork-choice-rule/)
- [블록 확인](/ko/crypto/block-confirmation/)
- [체인 재구성](/ko/crypto/chain-reorg/)
- [Selfish mining](/ko/crypto/selfish-mining/)
## 출처
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (접근일: 2026-08-19)
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (접근일: 2026-08-19)
- [Bitcoin Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Project (접근일: 2026-08-19)
- [Bitcoin Core RPC: getchaintips](https://developer.bitcoin.org/reference/rpc/getchaintips.html) - Bitcoin Project (접근일: 2026-08-19)
- [Bitcoin Core: validation.cpp](https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp) - Bitcoin Core (접근일: 2026-08-19)
- [The Bitcoin Backbone Protocol: Analysis and Applications](https://eprint.iacr.org/2014/765) - IACR Cryptology ePrint Archive (접근일: 2026-08-19)
- [Majority Is Not Enough: Bitcoin Mining Is Vulnerable](https://www.cs.cornell.edu/~ie53/publications/btcProcArXiv.pdf) - Cornell University (접근일: 2026-08-19)
- [Eclipse Attacks on Bitcoin's Peer-to-Peer Network](https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/heilman) - USENIX Association (접근일: 2026-08-19)
Source: https://wiki.fcontext.com/ko/crypto/nakamoto-consensus/index.mdx