---
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.
# 블록체인 완결성: 증거, 가정, 결제 계층
> 프로토콜 교육용 분석이다. 'confirmed', 'safe', 'committed', 'finalized' 같은 표시는 해당 체인, 규칙, 증거, 장애 가정, 계층, 애플리케이션 정책과 함께 해석해야 의미가 있다.
## 핵심 답변
완결성은 블록, 체크포인트, 상태 커밋처럼 수락된 결정이 명시된 안전성 가정을 위반하거나 예외적 복구 절차를 실행하지 않는 한 대체되지 않는다는 프로토콜별 보장이다. 거래 바이트의 물리적 속성도 아니고 단순히 “거래가 성공했다”는 뜻도 아니다. 완결성 주장은 객체, 네트워크, 프로토콜 버전, 증거, 장애 및 시간 모델, 신뢰하는 시작점, 관찰자를 밝혀야 한다.
유효성, 정규성, 완결성은 서로 다르다. 유효한 블록은 상태 전이와 권한 규칙을 충족한다. 포크 선택은 유효 후보 중 현재 정규 헤드를 고른다. 완결화는 커밋 인증서나 완결된 체크포인트 같은 추가 조건을 그 헤드의 조상에 적용한다. 거래가 나중에 포크 선택에서 탈락하는 유효 블록에서 성공할 수 있고, 헤드가 정규이지만 미완결일 수 있으며, 원본 체인에서 완결된 사건도 브리지, 거래소, 애플리케이션에서 실패할 수 있다.
작업증명은 보통 명시적 완결 비트가 아닌 확률적 결제를 제공한다. 블록 위에 유효 누적 작업이 쌓일수록 주어진 해시 파워와 네트워크 가정 아래 대체 가능성은 낮아지고 비용은 커진다. BFT형 프로토콜은 조건부 결정론적 완결성을 제공할 수 있다. 유효한 커밋 인증서 뒤에는 결함 투표 가중치가 증명된 한계보다 작다면 충돌하는 두 결정을 모두 커밋할 수 없다. 지분증명 완결성은 충돌 투표로 슬래시 가능한 지분을 식별하므로 책임 추적형 또는 경제적이라고도 한다. 이 표현들은 서로 다른 증거를 가리키며 바꿔 쓸 수 없다.
어떤 프로토콜도 역사를 절대적으로 불변하게 만들지는 못한다. 대규모 키 탈취, 장애 한계 위반, 클라이언트 버그, 구현이 수락한 무효 상태 전이, 거버넌스 개입, 사회적 복구는 모델 경계를 넘을 수 있다. 따라서 “완결됨”은 “이 가정에서 프로토콜의 일반 재구성 경로로 이 결정을 대체할 수 없음”을 뜻해야 하며, 예외적 복구와 그 권한은 별도로 기록해야 한다.
## 완결성 분석 방법
1. **객체와 범위를 특정한다.** 거래, 블록, 체크포인트, 상태 루트, 크로스체인 메시지, 출금 중 무엇인지 정하고 체인, 네트워크, 계층, 버전, 높이 또는 슬롯, 블록 해시, 신뢰 체크포인트를 기록한다.
2. **상태보다 유효성을 먼저 검증한다.** 관련 상태 전이와 조상 관계를 재실행하거나 다른 방법으로 검증한다. 실제 규칙에서 정족수, 작업 점수, UI 배지는 무효 객체를 완결할 수 없다.
3. **헤드 선택과 완결화를 분리한다.** 포크 선택과 현재 정규 경로를 재구성하고 프로토콜의 완결 또는 커밋된 조상을 찾는다. 관찰됨, 확인됨, 정당화됨, 안전함, 커밋됨, 완결됨 중 무엇인지 기록한다.
4. **증거를 재현한다.** 작업증명은 헤더, 목표, 대상 블록 위 누적 chainwork를 검증한다. 투표 프로토콜은 서명자 자격, 가중치 스냅샷, 메시지 도메인, 소스와 타깃, 높이, 라운드, 정족수 부등식, 서명, 잠금, 인증서 조상 관계를 검증한다.
5. **안전성과 활성 가정을 명시한다.** 비잔틴 또는 오프라인 가중치, 동기성, 지연, 이중 투표, 키 탈취, 클라이언트 상관관계, 구성원 변경, 슬래싱 가능성, 완결화 정지 시 동작을 밝힌다. 정지는 안전성을 지키면서 활성을 잃을 수 있다.
6. **모든 결제 계층을 연결한다.** 시퀀서 접수, L2 실행, 데이터 게시, L1 포함, L1 완결, 증명 또는 분쟁 완료, 브리지 메시지 실행, 거래소 입금, 앱 동작을 추적한다. 다른 계층의 비슷한 명칭이 같은 조건을 뜻하지는 않는다.
7. **앱 정책을 정하고 감시한다.** 가치와 결과에 따라 수용 가능한 증거를 정의하고 독립 노드를 조회하며 재구성과 충돌 완결성 경보를 처리한다. 가정이 무너지면 되돌릴 수 없는 후속 조치를 멈추고 복구 승인자를 기록한다.
확인 수는 관찰값이지 보편적 완결성 규칙이 아니다. Bitcoin Core에서 블록의 `confirmations`는 현재 활성 체인 내 위치에 따라 달라지고 `chainwork`는 누적 기대 작업량을 기록한다. Ethereum의 LMD-GHOST 헤드 선택과 Casper FFG 체크포인트 정당화 및 완결화는 별도 상태 전이다. CometBFT의 커밋에는 같은 높이와 라운드의 같은 블록에 투표권 3분의 2 초과가 precommit해야 한다. 각 상태는 해당 프로토콜 안에서 해석해야 한다.
## 계산 예시
### 1. 확률적 작업증명 결제
Bitcoin 백서는 해시 파워 비중이 `q=0.10`인 공격자가 정직한 체인에 `z=6`만큼 뒤진 뒤 따라잡는 상황을 모델링한다. 독립 해시 시행과 푸아송 가정 아래 계산한 추격 확률은 다음과 같다.
`P=0.0002428 = 0.02428%`
작지만 0은 아니며 보편적인 “6회 확인 보장”도 아니다. 실제 정책은 거래 가치, 관측 chainwork, 해시 파워 집중, 이클립스나 네트워크 분할 위험, 수수료 유인, 공격자 비중이 일정하다는 모델 가정의 신뢰성까지 고려해야 한다.
### 2. Ethereum 정당화와 완결화
총 활성 유효 잔액이 `100`인 단순 연속 체크포인트 경로를 보자. 정당화된 `C_0`에서 타깃 `C_1`로 연결하는 `67/100` 투표는 3분의 2 이상 문턱을 충족해 `C_1`을 정당화한다. 이후 `C_1`에서 직계 자식 `C_2`로 가는 적격 `67/100` 링크는 적용되는 Casper FFG 규칙에 따라 `C_1`을 완결할 수 있다.
헤드는 `C_2`보다 멀리 진행해도 새 부분은 미완결일 수 있다. 잔액 `34`가 오프라인이면 `66`만 남아 포크 선택과 블록 생성이 계속되더라도 즉시 완결화는 멈춘다. 4 epoch를 넘게 완결성이 없으면 Ethereum의 inactivity leak가 불참을 벌하기 시작해 활성 초다수가 결국 완결성을 회복할 수 있게 한다.
### 3. CometBFT 안전성과 활성
총 투표권이 `100`이고 같은 높이와 라운드의 같은 블록에 `>2/3` precommit이 있어야 커밋한다고 하자. 정수 투표권 `67`이면 커밋된다. 67인 커밋 집합 둘은 적어도 `67 + 67 - 100 = 34` 가중치에서 겹친다. 비잔틴 가중치가 3분의 1 미만이고 정직한 검증자가 잠금 규칙을 따르면 충돌 커밋 둘은 성립할 수 없다.
가중치 `34`를 사용할 수 없으면 `66`만 투표하므로 커밋이 형성되지 않는다. 완결화가 멈춰도 안전성은 유지될 수 있다. “충돌하는 완결 블록이 없음”과 “새 블록이 계속 완결됨”은 별도 보장이다.
### 4. OP Stack 상태와 출금 시계
OP Stack 시퀀서는 L2 블록을 먼저 `unsafe`로 공개할 수 있다. 현재 정규 L1 체인 데이터에서 블록을 완전히 도출할 수 있으면 롤업 노드는 `safe`로 표시할 수 있다. 대응 L1 입력이 L1 완결성 신호를 받으면 도출된 L2 블록은 `finalized`가 될 수 있다.
이 상태는 완결된 입력으로부터의 도출에 관한 것이다. 옵티미스틱 롤업 출력이나 L2에서 L1으로의 출금에는 별도 증명과 분쟁 절차가 있으며 challenge 조건을 충족한 뒤에만 “finalized”라는 말을 쓸 수도 있다. 시퀀서 확인, L1 데이터 포함, L1 합의 완결성, 출금 실행을 하나의 시각으로 합치는 앱은 가치를 너무 일찍 풀 수 있다.
## 위험과 검토 실패
### 정의와 증거
- 성공한 실행, 영수증, 확인, 체크포인트, UI 배지를 모두 “완결”이라고 부른다.
- 체인, 네트워크, 버전, 객체 해시, 높이 또는 슬롯, 계층, 관찰자를 생략한다.
- 현재 포크 선택 헤드를 완결 조상으로 보거나 완결화가 최신 헤드를 선택한다고 가정한다.
- 조상, 목표, 작업, 투표, 인증서를 검증하지 않고 블록 수나 경과 시간만 센다.
- 증거와 장애 모델이 다른 프로토콜 사이에서 “2회 확인”이나 “10분 완결”을 비교한다.
- 서명자 자격, 가중치, 도메인, 소스, 타깃, 높이, 라운드 없이 서명만 검증한다.
- 경제 비용, 슬래시 가능한 증거, 실제 벌칙 집행을 같은 보장으로 취급한다.
- 확률 위험을 0이라 하거나 조건부 결정론적 안전성을 무조건적 불가역성이라 한다.
### 프로토콜 및 운영 장애
- 증명된 비잔틴 한계를 넘거나 활성에 필요한 온라인 가중치를 잃거나 네트워크 분할을 숨긴다.
- 구현끼리 유효성, 포크 선택, 체크포인트 전이, 정족수 반올림, 인증서 조상이 다르다.
- 오래되거나 재전송되거나 다른 네트워크의 투표, 커밋, 체크포인트, 약한 주관성 데이터를 받는다.
- 명목상 분리된 신원 뒤에 키, 지분, 해시 파워, 클라이언트, 릴레이, 클라우드, RPC 관점을 집중한다.
- inactivity leak, timeout, view change가 즉시 비용 없이 진행을 되살린다고 가정한다.
- 완결 지연, 충돌 인증서, 깊은 재구성, 이중 투표, 완결 루트 불일치에 경보하지 않는다.
- 권한, 조정, 클라이언트 배포, 영향받는 보장을 기록하지 않고 비상 거버넌스나 사회적 복구를 쓴다.
### 계층과 애플리케이션 불일치
- 시퀀서 포함을 L2 안전성, L1 게시, L1 완결성, 증명 수락, 출금 완료 모두로 취급한다.
- 원본 사건과 브리지 자체 검증 경로가 정책을 충족하기 전에 브리지 자산을 푼다.
- 독립 대조 없이 한 RPC 제공자의 상태로 입금을 반영하거나 불가역 거래를 실행한다.
- 체인 완결성이 오라클 사실, 계약 정확성, 데이터 가용성, 거래소 지급 능력, 법적 결제를 보장한다고 본다.
- 모든 가치, 상대방, 공격 유인, 복구 비용에 고정 확인 문턱 하나를 쓴다.
## 흔한 오해
- **성공한 거래는 완결됐다.** 실행 성공은 한 후보 역사 안의 상태 전이만 설명하며 정규성과 완결성에는 추가 증거가 필요하다.
- **작업증명은 확인이 늘면 위험이 정확히 0이 된다.** 모델 확률은 크게 줄 수 있지만 가정에 의존하며 논리적으로 불가능해지지는 않는다.
- **3분의 2는 언제나 완결성을 뜻한다.** 부등식, 메시지 유형, 가중치, 높이, 라운드, 소스-타깃 관계, 잠금 규칙은 프로토콜마다 다르다.
- **완결성은 네트워크가 계속 진행함을 보장한다.** 참여나 연결 부족으로 새 완결화가 멈춰도 안전성은 유지될 수 있다.
- **L1 완결성이 모든 L2 또는 브리지 동작을 끝낸다.** 데이터 도출, 유효성 또는 사기 증명, challenge 기간, 목적지 실행에는 별도 시계와 장애 경로가 있다.
## 관련 주제
- [블록 확인](/ko/crypto/block-confirmation/)
- [체인 재구성](/ko/crypto/chain-reorg/)
- [합의 메커니즘](/ko/crypto/consensus-mechanism/)
- [포크 선택 규칙](/ko/crypto/fork-choice-rule/)
- [약한 주관성](/ko/crypto/weak-subjectivity/)
## 출처
- [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 Core RPC: getblockheader](https://developer.bitcoin.org/reference/rpc/getblockheader.html) - Bitcoin Project (확인: 2026-08-19)
- [Ethereum Proof-of-Stake Consensus](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (확인: 2026-08-19)
- [Ethereum Consensus Specifications: Beacon Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (확인: 2026-08-19)
- [Ethereum Proof-of-Stake Rewards and Penalties](https://ethereum.org/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/) - Ethereum.org (확인: 2026-08-19)
- [CometBFT Byzantine Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (확인: 2026-08-19)
- [OP Stack Derivation Specification](https://specs.optimism.io/protocol/derivation.html) - Optimism (확인: 2026-08-19)
Source: https://wiki.fcontext.com/ko/crypto/finality/index.mdx