CometBFT는 높이마다 proposer가 블록을 제안하고 검증자가 prevote와 precommit을 보냅니다. 같은 라운드에서 특정 블록에 +2/3 prevote가 모이면 검증자는 그 블록을 잠그고 precommit할 수 있으며, +2/3 precommit이 모이면 커밋됩니다. 제안이 없거나 유효하지 않으면 nil 투표와 timeout 뒤 다음 라운드로 넘어갑니다. lock은 지연 중 서로 다른 블록을 쉽게 확정하지 못하게 하는 안전 장치입니다.
height와 round를 먼저 나눈다
height는 다음 블록 위치이고 round는 그 높이에서 합의를 시도한 횟수입니다. 네트워크 지연이나 proposer 장애가 있으면 같은 height에서 round 0, 1, 2로 넘어갈 수 있습니다. round 증가를 체인 재구성이나 블록 높이 증가로 읽으면 안 됩니다. 각 round에는 proposer와 시간 제한이 새로 정해집니다.
propose 단계에서 지정 proposer는 블록과 가능한 경우 이전 라운드의 다수 증거를 제시합니다. 검증자는 proposal의 기본 유효성과 애플리케이션 검사를 거친 뒤 prevote합니다. 유효한 제안을 제때 받지 못했거나 조건을 충족하지 않으면 nil에 prevote할 수 있습니다. nil은 서버가 아무 메시지도 보내지 않았다는 뜻이 아니라 특정 블록에 동의하지 않는 명시적 투표입니다.
라운드는 실패 횟수표가 아니라 같은 높이에서 안전한 제안을 다시 모으는 합의의 시간축이다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- height와 round를 먼저 나눈다
height는 다음 블록 위치이고 round는 그 높이에서 합의를 시도한 횟수입니다.
- prevote와 precommit은 질문이 다르다
prevote는 이 라운드에서 어떤 제안을 지지할 수 있는지 드러냅니다.
- lock은 서로 다른 라운드를 연결한다
검증자가 한 round에서 블록을 lock하면 다음 round의 새 제안을 무조건 따라가지 않습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
prevote와 precommit은 질문이 다르다
prevote는 이 라운드에서 어떤 제안을 지지할 수 있는지 드러냅니다. 특정 block ID에 voting power +2/3를 넘는 prevote, 즉 polka가 형성되면 검증자는 조건에 따라 그 블록을 lock하고 precommit합니다. +2/3가 어느 블록에도 모이지 않으면 nil precommit과 timeout을 거쳐 다음 round로 진행할 수 있습니다.
precommit은 커밋 가능성에 더 가까운 단계입니다. 같은 block ID에 +2/3 precommit이 모이면 노드는 해당 블록을 commit하고 다음 height로 이동합니다. 2/3라는 숫자를 검증자 계정 수로 세면 안 됩니다. 100개 검증자 중 40개가 큰 voting power를 가지면 계정 수 소수여도 결과에 큰 비중을 차지할 수 있습니다.
| 단계 | 핵심 입력 | 가능한 결과 |
|---|---|---|
| propose | proposer의 블록·POL | 제안 수신 또는 timeout |
| prevote | 유효 제안·현재 lock | block ID 또는 nil 투표 |
| precommit | +2/3 prevote 증거 | block lock·nil precommit |
| commit | +2/3 precommit | 블록 확정 후 다음 height |
lock은 서로 다른 라운드를 연결한다
검증자가 한 round에서 블록을 lock하면 다음 round의 새 제안을 무조건 따라가지 않습니다. 더 높은 round에서 적절한 +2/3 prevote 증거를 관측하는 등 잠금 해제 조건이 있어야 합니다. 이 기억 장치가 없다면 지연된 검증자 집단이 서로 다른 제안을 각각 확정할 위험이 커집니다.
validBlock과 validRound는 proposer가 이전 round에서 다수 prevote를 얻었던 블록을 다시 제안하는 데 사용됩니다. proposal의 POLRound를 통해 다른 검증자는 새 제안이 과거 증거와 어떻게 연결되는지 판단합니다. lock은 영원한 정지가 아니라 다수 증거를 따라 안전하게 이동하기 위한 제약입니다.
- 로그를 height·round·step 세 축으로 정렬한다
- 투표 수가 아니라 validator voting power 합계를 계산한다
- block ID와 nil prevote·precommit을 별도 집계한다
- lockedRound·validRound·proposal POLRound의 선후 관계를 확인한다
정지와 안전 실패를 같은 말로 부르지 않는다
+2/3 precommit이 모이지 않으면 해당 round에서 커밋이 늦어지지만 곧바로 상충 블록이 확정됐다는 뜻은 아닙니다. 네트워크 분할, 많은 오프라인 voting power, 느린 proposal 전파는 진행성을 해칠 수 있습니다. 반대로 Byzantine 검증자가 중복 투표를 보내는 행동은 evidence와 처벌 경로의 대상이 될 수 있습니다.
장애 분석에서는 consensus round duration, proposal 수신, prevote·precommit power, peer 연결을 함께 봅니다. timeout을 짧게 낮추면 정상 지연에서도 round 전환이 늘 수 있고, 너무 길면 장애 회복이 늦어집니다. 체인별 설정과 실제 지연 분포 없이 보편적 최적값을 제시할 수 없습니다.
탐색기 결과보다 합의 로그가 더 많은 것을 말한다
탐색기는 최종 height와 block hash를 보여 주지만 그 전에 몇 round가 있었고 어떤 nil 투표가 오갔는지 생략할 수 있습니다. 블록 시간이 길어진 원인을 찾으려면 CometBFT consensus logs와 RPC consensus_state, validator set을 같은 높이에서 대조해야 합니다. 애플리케이션 처리 지연과 합의 메시지 지연도 구분합니다.
정확한 설명은 제안, 두 투표, 잠금, 커밋을 순서대로 놓습니다. +2/3 prevote는 즉시 블록 커밋과 같지 않고, +2/3 precommit이 커밋 조건입니다. 다음 round의 새 proposal은 이전 lock을 지우는 명령이 아닙니다. 이 세 경계를 지키면 정상적인 round 전환을 포크 사고로 과장하지 않게 됩니다. 서로 다른 합의의 라운드 구조를 비교할 때는 Sui Mysticeti 전환처럼 과거 엔진과 현재 엔진을 시기별로 분리해야 용어를 잘못 이식하지 않습니다.
자주 묻는 질문
+2/3는 검증자 인원수인가요?
아닙니다. CometBFT 합의의 임계값은 validator voting power 합계를 기준으로 합니다.
+2/3 prevote가 모이면 블록이 바로 커밋되나요?
아닙니다. lock과 precommit 단계가 이어지고 같은 블록에 +2/3 precommit이 모여야 커밋됩니다.
nil 투표는 검증자가 오프라인이라는 뜻인가요?
항상 그렇지 않습니다. 유효한 제안을 받지 못했거나 잠금 조건 때문에 특정 블록을 지지하지 않는 명시적 투표일 수 있습니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
