허가형 QBFT 합의
Nigo Protocol은 기업용 허가형 네트워크를 위해 QBFT 계열의 즉시 확정성 합의를 제공합니다. 합의 계층은 트랜잭션 실행 결과를 검증자들이 다시 실행하고 합의한 뒤, 확정된 블록과 상태를 원자적으로 커밋합니다.
현재 구현은 Nigo QBFT 프로파일 Revision 1입니다. 메시지 형식, 블록 헤더 표현, 네트워크 전송 규약은 Nigo Protocol의 규격을 따르며 Besu QBFT의 wire format이나 extraData 형식과 호환된다는 의미는 아닙니다.
실행과 합의의 경계
합의는 실행 엔진을 대체하지 않습니다. 모든 검증자는 동일한 입력을 독립적으로 실행해 상태 루트와 영수증 루트를 포함한 제안 결과가 결정론적으로 일치하는지 확인합니다. 실행 결과가 다른 제안은 유효한 블록으로 확정할 수 없습니다.
Revision 1 프로파일
현재 합의 프로파일의 핵심 특성은 다음과 같습니다.
| 항목 | 현재 규칙 |
|---|---|
| 검증자 집합 | 제네시스와 운영 설정에 고정된 정적 집합 |
| 검증자 신원 | secp256k1 키와 20바이트 검증자 ID |
| 제안자 선택 | 블록 높이와 라운드에 따른 결정론적 round-robin |
| 메시지 | PROPOSAL, PREPARE, COMMIT, ROUND_CHANGE |
| 잠금 | prepared certificate에 기반한 라운드 잠금 |
| 커밋 인증서 | 검증자 ID 순으로 정렬된 서명 집합 |
| 장애 복구 | WAL을 이용한 persist-before-broadcast |
| 노드 역할 | validator 또는 observer |
동적 검증자 가입·탈퇴와 온체인 거버넌스는 Revision 1의 활성 기능이 아닙니다. 검증자 집합 변경은 별도의 네트워크 운영 절차와 향후 프로토콜 개정 대상으로 취급해야 합니다.
정족수와 장애 허용
검증자 수를 n이라고 할 때 합의 정족수는 다음과 같습니다.
quorum = ceil(2n / 3)
최대 Byzantine 장애 허용 수 = floor((n - 1) / 3)
예를 들어 검증자가 4개라면 정족수는 3이고, 최대 1개의 Byzantine 장애를 허용합니다. 운영 환경에서는 단순 노드 수뿐 아니라 조직, 리전, 키 보관 경계가 독립적인지도 함께 고려해야 합니다.
정상 라운드
- 해당 높이와 라운드의 제안자가 후보 블록을 제안합니다.
- 검증자는 제안의 서명, 부모 블록, 라운드, 트랜잭션과 실행 결과를 검증합니다.
- 유효한 제안에 대해
PREPARE를 기록하고 전파합니다. - 정족수의
PREPARE를 모으면 prepared 상태로 잠그고COMMIT을 전파합니다. - 정족수의
COMMIT을 모으면 커밋 인증서와 함께 블록을 확정합니다.
확정된 블록은 확률적 확인 횟수를 요구하지 않습니다. 동일 높이에서 서로 다른 두 블록이 정상 검증 규칙 아래 동시에 확정되지 않도록 설계됩니다.
라운드 변경과 잠금
제안자가 응답하지 않거나 유효하지 않은 제안을 보낼 경우 검증자는 타임아웃 후 다음 라운드로 이동합니다. ROUND_CHANGE 메시지는 검증자가 보유한 prepared certificate를 함께 전달할 수 있습니다.
새 라운드의 제안자는 정족수의 라운드 변경 증거를 수집하고, 그 안에 유효한 prepared certificate가 있다면 가장 높은 prepared 라운드의 블록을 제안해야 합니다. 이 잠금 규칙은 라운드가 바뀌어도 이미 형성된 안전성을 보존합니다.
오래된 높이·라운드 메시지, 중복 투표, 잘못된 서명은 거부됩니다. 동일한 검증자가 같은 단계와 라운드에서 서로 다른 블록에 서명하는 equivocation도 탐지 대상입니다.
WAL과 충돌 복구
검증자는 합의 메시지를 네트워크에 전송하기 전에 로컬 write-ahead log(WAL)에 의도를 내구성 있게 기록합니다. 이 persist-before-broadcast 순서는 프로세스가 메시지 전송 직후 중단되더라도 재시작 시 자신의 기존 투표와 잠금을 복구하게 합니다.
복구 시 노드는 대략 다음 상태를 재구성합니다.
- 현재 블록 높이와 라운드
- 이미 전송한 제안 또는 투표
- prepared lock과 인증서
- 수집 중인 커밋 인증서
WAL은 운영 백업을 대신하는 데이터베이스가 아니라, 합의 안전성을 위한 로컬 복구 기록입니다. 블록 저장소 및 상태 저장소와 함께 장애 복구 정책을 설계해야 합니다.
네트워크 허가와 합의 신원
Nigo 네트워크는 mTLS 기반 피어 인증과 합의 메시지 서명을 서로 다른 보안 경계로 취급합니다.
- mTLS는 허가된 노드만 P2P 채널에 접속하도록 제한합니다.
- 검증자 서명은 특정 검증자가 합의 메시지에 책임 있게 서명했음을 증명합니다.
- TLS 인증서를 가진 노드라고 해서 자동으로 검증자가 되는 것은 아닙니다.
- 합의 키를 가진 검증자도 네트워크 접속 정책과 인증서 검증을 통과해야 합니다.
이 분리는 인증서 교체, 노드 접속 차단, 합의 키 보관 같은 운영 절차를 독립적으로 통제할 수 있게 합니다.
Validator와 Observer
| 역할 | 블록 검증 | 합의 투표 | 상태·RPC 제공 |
|---|---|---|---|
| Validator | 수행 | 수행 | 구성에 따라 수행 |
| Observer | 수행 | 수행하지 않음 | 수행 가능 |
Observer는 합의 정족수에 포함되지 않으면서 확정 블록을 검증하고 동기화할 수 있습니다. 조회 RPC, 감사, 인덱싱 같은 읽기 중심 워크로드를 검증자 노드와 분리할 때 적합합니다.
확정과 저장
커밋 인증서가 완성된 블록만 canonical chain에 반영됩니다. 커밋 과정은 다음 데이터를 서로 일관된 단위로 저장해야 합니다.
- 블록 헤더와 본문
- 커밋 인증서
- 트랜잭션 영수증과 로그
- StateCell 및 EVM 상태 변경
- 상태 루트와 관련 인덱스
노드가 중간 단계에서 중단되더라도 재시작 후 부분 커밋을 canonical 상태로 노출해서는 안 됩니다.
따라잡기와 상태 동기화
뒤처진 노드는 신뢰 가능한 피어로부터 확정 블록과 인증서를 받아 연속적으로 검증합니다.
로컬 확정 높이
→ 다음 블록 및 커밋 인증서 요청
→ 부모 연결·정족수 서명 검증
→ 결정론적 실행 또는 검증된 상태 동기화
→ 원자적 커밋
→ 최신 확정 높이까지 반복
동기화 데이터가 잘못되었거나 체인이 연결되지 않으면 fail-closed 해야 하며, 검증하지 않은 원격 상태를 canonical 상태로 승격해서는 안 됩니다.
현재 검증 범위
Revision 1 구현은 정적 검증자 집합을 전제로 다음 영역을 중심으로 검증됩니다.
- 정상 라운드의 제안·prepare·commit 흐름
- 라운드 변경과 prepared lock 보존
- 중복, 오래된 메시지, 잘못된 서명 거부
- 커밋 인증서의 정족수와 결정론적 정렬
- WAL 기반 재시작 복구
- observer 동기화와 확정 블록 검증
운영 전 확인할 경계
프로덕션 적용 시 구현 적합성 시험과 별개로 다음 운영 검증이 필요합니다.
- 장시간 부하에서 메모리, 디스크, WAL 증가 추세
- mTLS 인증서의 무중단 교체와 폐기 절차
- 손상되거나 악의적인 동기화 응답의 정리·재시도 정책
- 합의 키의 HSM 또는 외부 서명 장치 연계
- 조직 및 리전 단위 장애를 고려한 검증자 배치
- 동적 멤버십이 필요한 경우의 별도 프로토콜·거버넌스 설계
이 항목들은 QBFT의 수학적 안전성만으로 자동 해결되지 않습니다. 실제 BXDL 네트워크 출시 기준에는 키 관리, 변경 관리, 모니터링, 백업·복구 런북을 함께 포함해야 합니다.