---
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.
# 합의 메커니즘: 유효성, 포크 선택, 최종성
> 프로토콜 분석을 위한 교육 자료일 뿐입니다. 합의라는 명칭만으로 실제 네트워크의 안전성, 활성, 올바른 구현, 탈중앙화, 최종성, 공정한 순서 또는 자산 안전이 입증되지는 않습니다.
## 직접 답변
합의 메커니즘은 지연, 동시성, 모델이 다루는 장애가 있어도 비장애 복제본이 순서화된 로그나 상태에 대해 서로 양립하는 결정을 내리도록 하는 프로토콜입니다. 블록체인의 완전한 메커니즘에는 제안자 선정, 블록 및 상태 전이 검증, 투표 또는 증명, 포크 선택, 커밋 또는 최종성, 복구, 멤버십 규칙이 포함될 수 있습니다. 이는 단순히 “여러 컴퓨터가 같은 파일을 저장하는 것”도, 투표 임계값이나 채굴, 스테이킹, 인센티브 일정 하나만도 아닙니다.
세 가지 속성을 따로 명시해야 합니다. `safety`(안전성)는 비장애 참여자가 양립할 수 없는 결정을 내리지 못하게 하고, `liveness`(활성)는 지정된 조건에서 유효한 작업이 결국 진행될 수 있음을 뜻하며, `validity`(유효성)는 무엇을 결정할 수 있는지 제한합니다. 프로토콜은 안전성을 유지하면서 중단될 수도 있고, 나중의 재구성을 허용하는 가정 아래 계속 진행할 수도 있습니다. “합의”라는 말만으로는 어떤 보장이 언제 성립하며 클라이언트가 어떤 증거를 신뢰해야 하는지 알 수 없습니다.
트랜잭션 유효성과 정식 기록 선택은 다릅니다. 전체 노드는 현재 규칙을 위반하는 상태 전이를 독립적으로 거부합니다. 각각은 유효한 두 트랜잭션이 같은 입력을 쓴다면 순서 지정 또는 포크 선택이 어느 하나를 정식 기록에 넣을지 정하며, 다수 자원이 둘을 동시에 유효하게 만들 수는 없습니다. 마찬가지로 바이트에 대한 합의는 오라클 사실, 브리지 주장, 애플리케이션 계산 또는 법적 주장이 참임을 증명하지 않습니다.
작업 증명과 지분 증명은 보통 시빌 저항성, 제안 영향력 또는 책임 추적이 가능한 투표 가중치를 제공하지만, 그 이름만으로 완전한 합의 프로토콜이 정의되지는 않습니다. Bitcoin은 작업 증명과 검증 및 누적 작업량 체인 선택을 결합합니다. Ethereum의 Gasper는 지분 가중 증명, LMD-GHOST 포크 선택, Casper FFG 체크포인트 최종성을 결합합니다. CometBFT 같은 라운드 기반 BFT는 서로 다른 메시지, 임계값, 시간 가정과 최종성을 사용합니다. 이들의 백분율은 서로 바꿔 쓸 수 없습니다.
## 분석 방법
1. **결정 대상과 범위를 정합니다.** 복제본이 단일 값, 순서화된 트랜잭션 로그, 각 높이의 블록, 체크포인트 또는 애플리케이션 상태 중 무엇을 결정하는지 밝히고 체인, 네트워크, 계층, 프로토콜 버전과 신뢰 시작점을 식별합니다.
2. **참여자와 영향력을 정의합니다.** 제안자, 투표자, 전체 검증 노드, 라이트 클라이언트와 관찰자를 구분합니다. 신원이 들어오고 나가는 방법, 영향력이 해시 파워, 지분, 동등 멤버십 또는 다른 가중치를 따르는지, 값싼 복제 신원을 무엇으로 막는지 기록합니다.
3. **프로토콜 단계를 분리합니다.** 트랜잭션 및 상태 유효성, 제안 구성, 전파, 투표 또는 증명, 포크 선택, 커밋, 최종성과 복구를 문서화합니다. 유효한 블록도 포크 선택에서 패할 수 있고 정식 헤드도 아직 최종화되지 않았을 수 있습니다.
4. **시스템 모델을 명시합니다.** 인증 채널, 동기 또는 부분 동기, 지연과 타임아웃 가정, 중단 및 비잔틴 장애, 이중 투표, 누락, 적응형 침해, 키 유출, 네트워크 분할, 최대 장애 수 또는 가중치 `f`를 정의합니다.
5. **하나의 결정을 추적합니다.** 제안부터 결정까지 메시지 도메인, 높이, 라운드, 부모, 잠금, 인증서와 로컬 상태를 따라갑니다. 메시지가 늦거나 제안자가 상충 제안을 하거나 라운드가 타임아웃되거나 두 유효 분기가 나타날 때의 처리를 보입니다.
6. **안전성과 활성을 따로 검증합니다.** 정확한 참여자 집합과 가중치 스냅샷으로 정족수 교집합, 체인 성장 또는 다른 증명 조건을 도출합니다. 그런 다음 진행에 충분한 정직한 연결과 참여가 남는지 시험하며 안전 임계값에서 활성을 추론하지 않습니다.
7. **증명을 실제 배포에 대응시킵니다.** 클라이언트 버전, 매개변수 변경, 멤버십 및 지분 집중, 키 보관, 피어 다양성, 빌더나 시퀀서 역할, 체크포인트, 약한 주관성 규칙, 재구성 처리와 애플리케이션 자체 확인 정책을 점검합니다.
FLP는 실제 합의가 불가능하다는 뜻이 아닙니다. 완전 비동기 메시지 전달 모델에서는 중단 장애가 하나뿐이어도 결정적 합의 프로토콜이 종료되지 않는 허용 실행이 존재한다는 결과입니다. 실제 프로토콜은 동기 또는 부분 동기 가정, 무작위 선택, 장애 감지기, 경제적 가정 또는 더 약한 종료 보장을 추가해 유용한 보장을 얻습니다. 이런 추가 조건은 프로토콜 명칭 뒤에 숨기지 말고 명시해야 합니다.
## 계산 예시
### 1. 유효성은 정식 순서가 아닙니다
미사용 출력 `U`의 가치는 1 BTC입니다. 트랜잭션 `T_B`는 이를 Bob에게, `T_C`는 같은 출력을 Carol에게 보냅니다. 같은 부모 상태를 기준으로 두 트랜잭션 모두 올바른 서명과 형식을 가질 수 있지만 유효한 기록은 `U`를 두 번 소비할 수 없습니다.
경쟁하는 유효 블록이 각각 한 트랜잭션을 포함하면 검증은 두 후보 분기를 로컬에 보존하고 포크 선택이 정식 분기를 고릅니다. `T_B`가 선택된 기록에 들어가면 `T_C`는 그 결과 상태와 충돌합니다. 합의가 정한 것은 순서이며, 잘못된 서명을 올바르게 바꾸거나 어느 수취인이 도덕적으로 대금을 받을 권리가 있는지 정한 것이 아닙니다.
### 2. 노드 수가 아니라 누적 작업량
두 유효한 Bitcoin 방식 분기의 누적 작업량 점수가 같은 임의 단위에서 `W_A=240`과 `W_B=235`라고 합시다. 검증 노드는 B를 더 많은 피어에서 먼저 들었더라도 누적 작업량 규칙에 따라 A를 선택합니다. 피어 수는 합의 가중치가 아닙니다.
그 뒤 B가 작업량 10을 추가하고 A는 그대로라면 `W_B=245` 대 `W_A=240`이 되어 노드는 분기를 검증한 후 B로 재구성할 수 있습니다. 이 단순 계산은 작업 증명 확인이 확률적인 이유를 보입니다. 더 깊은 기록은 교체 비용이 점차 커질 뿐, 고정 블록 수에서 논리적으로 되돌릴 수 없게 되는 것이 아닙니다.
### 3. 가중 BFT 정족수와 활성 중단
검증자 총 가중치를 `100`이라 하고 CometBFT 방식 커밋에는 같은 높이와 라운드의 같은 블록에 대한 `>2/3` 프리커밋이 필요하다고 합시다. 정수 가중치 `67`은 조건을 통과합니다. 가중치 67인 두 정족수는 67 + 67 - 100 = 34이므로 최소 `34`에서 겹칩니다. 비잔틴 가중치가 3분의 1 미만이면 교집합에는 프로토콜상 상충 커밋에 서명하지 않을 정직한 가중치가 포함됩니다.
같은 임계값은 활성 경계도 드러냅니다. 가중치 34가 오프라인이면 `66`만 남아 온라인 검증자가 모두 정직해도 커밋을 만들 수 없습니다. 프로토콜은 중단하면서 안전성을 지킬 수 있습니다. 거버넌스 투표나 운영자 수로 빠진 합의 가중치를 대신할 수 없습니다.
### 4. 포크 선택과 체크포인트 최종성은 다릅니다
단순화한 Ethereum Gasper 흐름에서 체크포인트를 `C_0`, `C_1`, 그 직계 자식 `C_2`라고 합시다. 활성 유효 잔액의 `67/100`을 대표하는 투표는 `C_0`에서 `C_1`로 초다수 링크를 만들어 `C_1`을 정당화할 수 있습니다. 뒤이어 `C_1`에서 `C_2`로 적격 링크가 생기면 해당 FFG 규칙 아래 더 이른 체크포인트를 최종화할 수 있습니다.
체크포인트 사이에서는 LMD-GHOST가 검증자의 최신 증명을 사용해 정당화된 체크포인트의 가능한 후손 중 헤드를 고르고, 최종화 체크포인트 제약은 상충 분기를 걸러냅니다. 따라서 헤드 선택, 정당화, 최종화는 관련되지만 서로 다른 상태 전이이며 “67%가 이 블록에 투표했다”는 말만으로는 어느 것도 완전히 설명되지 않습니다.
## 위험과 검토 실패
### 모델과 보장
- 결정, 안전성, 활성, 유효성과 종료 조건을 정의하지 않고 “네트워크가 합의했다”고 말합니다.
- 작업 증명, 지분 증명, 채굴, 스테이킹 또는 투표 비율을 완전한 프로토콜 명세로 취급합니다.
- `51%`, `2/3`, `n=3f+1`을 서로 다른 장애, 시간, 가중치와 최종성 모델에 보편 적용합니다.
- 중단 장애, 비잔틴 행동, 키 도난, 채널 장애, 상관된 소프트웨어와 거버넌스 장악을 혼동합니다.
- FLP를 결정적·완전 비동기·종료 보장이라는 범위의 결과가 아니라 실용 합의 금지로 해석합니다.
- 독립 운영자, 투표 가중치, 클라이언트, 클라우드와 보관을 측정하지 않고 노드나 검증자 키만 셉니다.
- 정식, safe, 정당화, 커밋, 최종화 상태를 서로 바꿔 쓸 수 있다고 가정합니다.
- 복제 합의에서 외부 사실의 정확성, 공정한 순서, 프라이버시, 탈중앙화 또는 자산 가치를 추론합니다.
### 프로토콜과 구현
- 체인, 프로토콜 버전, 높이, 라운드, 부모, 페이로드, 송신자와 멤버십 시기에 결합되지 않은 블록이나 투표를 받습니다.
- 구현마다 상태 전이, 직렬화, 서명 도메인, 포크 선택, 동률 규칙 또는 반올림이 다르게 만듭니다.
- 적격 가중치 스냅샷과 중복 서명자 처리를 재구성하지 않고 정족수 인증서를 검증합니다.
- 포크, 네트워크, 라운드, 업그레이드 또는 검증자 집합 변경을 가로질러 투표, 작업량 또는 인증서를 재생합니다.
- 타임아웃, 뷰 변경 또는 복구 중 잠금, 정당화 체크포인트 또는 최고 인증서를 잘못 갱신합니다.
- 로컬에서 본 헤드나 단일 RPC 제공자의 라벨을 독립적인 네트워크 최종성 증거로 봅니다.
- 정상 경로만 시험하고 지연, 분할, 이중 투표, 무효 제안, 재구성과 복구를 시험하지 않습니다.
### 배포와 애플리케이션
- 해시 파워, 지분, 클라이언트, 릴레이, 빌더, 시퀀서, 클라우드 또는 서명 인프라를 명목상 별개인 신원 뒤에 집중시킵니다.
- 타임아웃이나 블록 간격을 실제 전파 및 검증 시간보다 짧게 설정해 활성을 해치거나 포크를 늘립니다.
- 필요한 원천 체인 및 애플리케이션 최종성 전에 입금을 반영하고 브리지 자산을 발행하거나 되돌릴 수 없는 작업을 실행합니다.
- 슬래싱, 보상 또는 토큰 가격이 언제나 충분하고 현금화 가능한 보안 예산을 만든다고 가정합니다.
- 누가 조정하고 클라이언트가 어느 체인을 설치하며 기존 어떤 보장이 바뀌었는지 인정하지 않은 채 사회적 복구나 거버넌스 개입을 사용합니다.
## 흔한 오해
- **합의와 검증은 같습니다.** 검증은 규칙 위반 데이터를 거부하고, 합의는 각자 로컬에서는 유효할 수 있는 후보 중 양립하는 결정을 고릅니다.
- **노드가 많으면 자동으로 더 안전합니다.** 원시 프로세스 수보다 영향력, 독립성, 토폴로지, 소프트웨어 다양성과 장애 모델이 중요합니다.
- **51% 공격자는 누구의 서명도 위조할 수 있습니다.** 특정 프로토콜에서 다수 자원이 검열이나 재구성을 가능하게 해도 그 자체로 개인 키를 드러내거나 무효 지출을 승인하지는 않습니다.
- **3분의 2는 언제나 최종성을 뜻합니다.** 정확한 부등식, 메시지, 라운드, 가중치 스냅샷, 잠금 규칙과 최종성 조건은 프로토콜별로 다릅니다.
- **빠른 블록은 강한 합의를 증명합니다.** 짧은 간격은 전파 경쟁과 자원 압박을 높일 수 있습니다. 지연은 안전성, 활성, 최종성 가정과 함께 평가해야 합니다.
## 관련 주제
- [비잔틴 장애 허용](/ko/crypto/byzantine-fault-tolerance/)
- [비잔틴 장군 문제](/ko/crypto/byzantine-generals-problem/)
- [최종성](/ko/crypto/finality/)
- [포크 선택 규칙](/ko/crypto/fork-choice-rule/)
- [지분 증명](/ko/crypto/proof-of-stake/)
## 출처
- [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)
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (접근일: 2026-08-19)
- [Ethereum Consensus Specifications: Fork Choice](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/fork-choice.md) - Ethereum Foundation (접근일: 2026-08-19)
- [Impossibility of Distributed Consensus with One Faulty Process](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf) - Journal of the ACM (접근일: 2026-08-19)
- [Consensus in the Presence of Partial Synchrony](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) - Journal of the ACM (접근일: 2026-08-19)
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (접근일: 2026-08-19)
- [HotStuff: BFT Consensus in the Lens of Blockchain](https://arxiv.org/abs/1803.05069) - arXiv (접근일: 2026-08-19)
Source: https://wiki.fcontext.com/ko/crypto/consensus-mechanism/index.mdx