---
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.
# 비잔틴 장애 허용: 안전성, 활성, 정족수
> 프로토콜 분석을 위한 교육 자료일 뿐입니다. BFT 명칭이나 정족수 임계값만으로 안전성, 활성, 올바른 실행, 탈중앙화, 최종성 또는 자산 안전이 입증되지는 않습니다.
## 직접 답변
비잔틴 장애 허용(BFT)은 명시된 장애 모델과 네트워크 모델 아래 특정 분산 프로토콜이 갖는 속성이다. 일부 참여자가 중단되거나, 메시지를 보내지 않거나, 상대마다 모순된 메시지를 보내거나, 그 밖의 임의 행동을 해도 선언된 보장을 지킨다. BFT는 하나의 알고리즘이 아니며 모든 네트워크 분할 중 모든 서비스가 계속 가용하다는 뜻도 아니다.
보장은 구분해야 한다. `safety`(안전성)는 정직한 참여자가 서로 충돌하는 값을 결정하지 않는다는 뜻이고, `liveness`(활성)는 적격 입력이 결국 결정으로 이어질 수 있다는 뜻이며, `validity`(유효성)는 결정할 수 있는 값을 제한한다. 통신이나 정직한 투표력이 부족할 때 안전성을 지키려고 멈추는 프로토콜도 있다. 합의가 올바르다고 해서 애플리케이션 코드, 거래 유효성 규칙, 브리지, 키 또는 거버넌스까지 올바른 것은 아니다.
인증된 부분 동기 BFT 프로토콜의 흔한 부류에서는 `n=3f+1`개 복제본이 최대 `f`개의 비잔틴 복제본을 허용하고 커밋 인증서에 `q=2f+1`표를 쓴다. 익숙한 “장애는 3분의 1 미만”, “정족수는 3분의 2 초과”라는 표현은 이 모델에서 나온다. 동기 프로토콜, 무작위 비동기 프로토콜, 충돌 장애 프로토콜, 작업증명 체인 및 다른 BFT 구성은 전제와 임계값이 다를 수 있다.
지분 가중 시스템의 임계값은 프로토콜이 정의한 투표력을 가리키며 검증자 수, 주소 수, 사람 수 또는 독립 운영자 수와 반드시 같지 않다. 비율을 적용하기 전에 정확한 프로토콜 버전, 가중치 스냅샷, 결정 유형, 네트워크 전제, 정족수 비교 연산자(`>` 또는 `>=`), 장애 행동을 밝혀야 한다.
## 작동 방식
1. **결정 대상을 정의한다.** 노드가 거래 순서를 정하는지, 블록을 커밋하는지, 체크포인트를 최종화하는지, 리더를 선출하는지, 상태 전이를 승인하는지, 포크를 선택하는지 확인한다. 이 결정들은 서로 바꿔 쓸 수 없다.
2. **시스템과 공격자 모델을 명시한다.** 구성원 자격, 인증, 권한 변경, 투표 가중치, 적응형 장악, 키 침해, 이중 투표, 충돌 장애, 메시지 손실, 검열, 서비스 거부, 장애의 상관 가능성을 기록한다.
3. **네트워크 모델을 명시한다.** 동기, 부분 동기, 비동기를 구분한다. 부분 동기에서는 알 수 없는 전역 안정화 시점 이후에만 무엇이 보장되는지와 타임아웃 조정 방식을 확인한다.
4. **정족수 규칙을 도출한다.** 프로토콜의 정확한 임계값과 잠금 또는 투표 규칙을 사용한다. 고전적인 `n=3f+1` 조건에서 두 `2f+1` 정족수는 적어도 `f+1`개의 복제본에서 겹친다. 비잔틴 복제본이 최대 `f`개라면 교집합에는 정직한 복제본이 있다.
5. **모든 단계와 인증서를 추적한다.** 제안, 투표, 잠금, 뷰 또는 라운드 변경, 커밋, 포크 선택과 복구 규칙을 검증한다. 노드가 높이, 라운드, 값, 부모, 도메인, 구성원 시기와 선행 인증서를 검증할 때만 서명된 초다수에 의미가 있다.
6. **안전성과 활성 증거를 분리한다.** 모든 관련 시점에서 어떤 충돌 결정이 배제되는지 증명한 뒤, 통신과 정직한 참여 전제가 성립하면 진행이 재개되는지 시험한다. 타임아웃은 스케줄링 도구이지 침묵한 피어가 악의적이라는 증거가 아니다.
7. **구현과 운영을 검증한다.** 증명 모델에 맞춰 클라이언트 다양성, 키 보관, 서명기 장애 조치, 재전송 방지, 상태 동기화, 증거 처리, 구성원 변경, 모니터링, 애플리케이션 확인 정책과 사고 복구를 점검한다.
FLP 결과는 완전 비동기 모델에서 단 하나의 프로세스라도 충돌할 가능성이 있으면 결정적 합의 프로토콜이 종료를 보장할 수 없다고 말한다. 안전성이 불가능하다거나 분산 합의가 전혀 작동할 수 없다는 뜻은 아니다. 부분 동기성, 무작위성, 장애 감지기, 경제적 전제 또는 약한 보장은 그 특정 불가능 조건을 바꾸는 서로 다른 방법이다.
## 계산 예시
### 1. 동일 가중치 복제본 네 개
`n=4`, `f=1`, `q=3`이라고 하자. 세 표 집합 두 개는 적어도 `3+3-4=2`개 복제본에서 겹친다. 비잔틴 복제본이 최대 하나이므로 교집합에는 정직한 복제본이 적어도 하나 있다. 프로토콜의 정직한 노드 규칙이 관련 높이와 라운드 이력에서 충돌 값에 투표하지 못하게 하면 충돌하는 커밋 인증서 두 개가 함께 만들어질 수 없다.
복제본 두 개가 오프라인이면 `2`표만 남아 `q=3` 인증서를 만들지 못한다. 이는 활성 장애이지 자동으로 안전성 장애가 되는 것은 아니다. 안전하게 설계된 프로토콜은 로컬에서 임계값을 낮추지 않고 기다린다.
### 2. 동일 가중치 복제본 일곱 개
`n=7`, `f=2`, `q=5`라고 하자. 두 정족수는 적어도 `5+5-7=3=f+1`개 복제본에서 겹친다. 비잔틴 복제본이 최대 `2`개이므로 교집합에는 정직한 복제본이 있다. 비잔틴 복제본 두 개만으로는 다섯 표 인증서를 만들 수 없지만, 세 개가 오프라인이거나 투표를 보류하면 `4`표만 남아 진행을 막을 수 있다.
임계값 계산은 필요조건이지만 충분조건은 아니다. 정직한 구현이 잘못된 높이의 표를 받고, 구성원 집합을 재사용하고, 잠금 규칙을 어기거나, 침해된 키로 서명하면 증명의 전제가 배포 시스템과 맞지 않는다.
### 3. 가중 투표력
검증자 가중치가 `40`, `30`, `20`, `10`, 합계 `100`이고, 인증서가 엄격히 `2/3` 초과, 여기서는 최소 `67`을 요구한다고 하자. `40+30=70` 연합은 인증서를 만들 수 있지만 `30+20+10=60`은 네 검증자 중 셋이어도 만들 수 없다. 가중치 `40`인 검증자가 오프라인이면 `60`만 남아 최종성이 멈춘다.
최소 `67`인 집합 두 개는 적어도 `67+67-100=34`에서 겹친다. 따라서 충돌 인증서는 최소 `34` 가중치가 두 집합에 모두 참여했거나 다른 프로토콜 전제가 실패했음을 뜻한다. 일부 프로토콜에서는 3분의 1을 약간 넘는 이중 투표만으로 안전성을 깨뜨릴 수 있으므로 “공격에는 3분의 2가 필요하다”는 보편적 최저선이 아니다.
### 4. 부분 동기성과 타임아웃
복제본 네 개가 라운드 타임아웃으로 `1 s`, `2 s`, `4 s`, `8 s`를 차례로 쓴다고 하자. 알 수 없는 안정화 시점 전에는 메시지가 매번 현재 타임아웃 뒤에 도착해 결정 없이 라운드가 바뀔 수 있다. 네트워크 안정 후 지연이 `3 s` 미만이면 `4 s` 이후 라운드에서 다른 전제도 충족되는 한 정직한 제안자와 정족수가 메시지를 교환하고 진행할 시간이 생긴다.
이 숫자는 결국 진행하는 모습을 설명할 뿐 보편적 타임아웃 공식이 아니다. 너무 짧으면 불필요한 뷰 변경이 생기고 너무 길면 복구 지연이 늘어난다. 안전성은 안정화 전에 올바른 지연 상한을 맞히는 데 의존해서는 안 된다.
## 위험과 검토 실패
### 모델과 증명
- 프로토콜, 버전, 결정, 장애 모델, 네트워크 모델, 구성원 규칙, 임계값을 밝히지 않고 “BFT”라고만 한다.
- 다른 전제로 증명된 프로토콜을 포함한 모든 분산원장에 `n=3f+1` 또는 3분의 1 비율을 적용한다.
- 안전성, 활성, 유효성, 가용성, 일관성, 최종성, 포크 선택과 거래 정확성을 같은 뜻으로 취급한다.
- 결정적, 완전 비동기, 종료 보장이라는 조건을 유지하지 않은 채 FLP가 합의를 불가능하게 만들었다고 주장한다.
- 프로토콜이 지분, 위임 가중치, 위원회, 에포크 또는 다른 자원을 세는데 노드나 주소를 센다.
- “3분의 2”를 모호하게 반올림하거나 구현이 `>`, `>=`, 정수 가중치, 어느 분모 스냅샷을 쓰는지 무시한다.
- 정족수 크기만 확인하고 교집합, 잠금, 인증서, 뷰 변경, 재구성 및 상태 이전을 확인하지 않는다.
- 증명 없이 모델이 적응형 장악, 키 도난, 상관 장애, 서비스 거부 또는 장거리 이력까지 다룬다고 가정한다.
### 구현과 운영
- 체인, 도메인, 높이, 라운드, 값, 부모, 구성원 시기와 메시지 유형에 묶이지 않은 서명을 받는다.
- 오래된 표나 인증서를 라운드, 높이, 포크, 네트워크, 업그레이드 또는 검증자 집합 변경을 넘어 재전송한다.
- 이중 서명, 잠금 후퇴, 안전하지 않은 서명기 장애 조치 또는 활성 복제본 둘의 동일 검증자 신원 공유를 허용한다.
- 타임아웃 만료를 악의의 증거로 보고 로컬 시계만으로 안전성에 중요한 결정을 내린다.
- 공통 클라이언트, 클라우드, 지역, 네트워크, 하드웨어, 키 관리 또는 운영자가 만드는 상관 장애를 무시한다.
- 슬래싱이 장애를 예방하고 활성을 복구하며 확정된 애플리케이션 동작을 되돌리고 모든 피해자를 보상한다고 가정한다.
- 정상 작동만 시험하고 분할, 지연과 순서 변경, 이중 투표, 제안자 장애, 재시작과 구성원 변경을 시험하지 않는다.
### 애플리케이션과 거버넌스
- 결정적 실행과 상태 전이 검증 없이 합의로 커밋된 값을 유효한 애플리케이션 상태로 취급한다.
- 애플리케이션이 요구하는 정확한 최종성 조건 전에 입금을 반영하고 브리지 자산을 발행하거나 거래를 결제한다.
- 키 침해, 소프트웨어 장애 또는 거버넌스 개입 후의 사회적 비가역성과 프로토콜 최종성을 같게 본다.
- 다른 사용자의 블록이 계속 최종화된다는 이유로 검열과 포함 지연을 무시한다.
- BFT 명칭이나 광고된 검증자 수에서 탈중앙화, 자산 안전, 토큰 가치 또는 법적 집행 가능성을 추론한다.
## 흔한 오해
- **BFT라면 네트워크는 절대 멈추지 않는다.** 많은 BFT 프로토콜은 장애가 너무 많거나 네트워크가 분할될 때 안전성을 지키려고 의도적으로 활성을 포기한다.
- **정직한 참여자가 51%를 넘으면 항상 충분하다.** 임계값은 프로토콜에 따라 다르며 고전적인 부분 동기 BFT는 진행에 관련 투표력의 3분의 2 초과를 흔히 요구한다.
- **안전성을 깨려면 공격자가 항상 3분의 2를 가져야 한다.** 3분의 2는 혼자 인증서를 만들 수 있지만, 흔한 정족수 설계의 충돌 초다수 인증서 둘은 3분의 1을 조금 넘는 이중 투표를 드러낼 수 있다.
- **검증자 주소를 늘리면 자동으로 장애 허용이 좋아진다.** 공동 소유, 위임 가중치, 클라이언트, 인프라, 키와 장애 영역이 독립 장애 능력을 결정한다.
- **슬래싱이 BFT 증명이다.** 슬래싱은 일부 PoS 시스템의 경제적 대응이며, 안전성은 규칙과 전제에서 나오고 벌칙은 외부 결과를 되돌리지 않는다.
## 관련 주제
- [비잔틴 장군 문제](/ko/crypto/byzantine-generals-problem/)
- [합의 메커니즘](/ko/crypto/consensus-mechanism/)
- [최종성](/ko/crypto/finality/)
- [지분증명](/ko/crypto/proof-of-stake/)
- [검증자](/ko/crypto/validator/)
## 출처
- [The Byzantine Generals Problem](https://lamport.azurewebsites.net/pubs/byz.pdf) - ACM Transactions on Programming Languages and Systems(접속일: 2026-08-18)
- [Impossibility of Distributed Consensus with One Faulty Process](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf) - Journal of the ACM(접속일: 2026-08-18)
- [Consensus in the Presence of Partial Synchrony](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) - Journal of the ACM(접속일: 2026-08-18)
- [Practical Byzantine Fault Tolerance](https://pmg.csail.mit.edu/papers/osdi99.pdf) - USENIX OSDI(접속일: 2026-08-18)
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT(접속일: 2026-08-18)
- [HotStuff: BFT Consensus with Linearity and Responsiveness](https://arxiv.org/abs/1803.05069) - arXiv(접속일: 2026-08-18)
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org(접속일: 2026-08-18)
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST(접속일: 2026-08-18)
Source: https://wiki.fcontext.com/ko/crypto/byzantine-fault-tolerance/index.mdx