Cosmos 애플리케이션이 블록 처리 과정에서 validator update를 반환해도 같은 블록의 합의를 소급해 바꾸지는 않습니다. 현재 CometBFT ABCI++ 요구사항에서 높이 H의 FinalizeBlock 응답으로 반환된 update는 H+2 블록부터 효력이 생깁니다. 따라서 ‘staking 상태가 바뀐 높이’, ‘ABCI update가 반환된 높이’, ‘새 voting power가 실제 합의에 사용된 높이’를 분리해 확인해야 합니다.
같은 블록을 소급해 다시 투표하지 않는다
검증자 세트는 각 height의 proposer 선택과 투표권 합계를 결정합니다. 애플리케이션이 블록을 실행한 결과 새 validator public key와 power를 반환해도 이미 그 블록을 제안하고 precommit한 집합은 바뀌지 않습니다. 현재 CometBFT ABCI++ 요구사항에서는 높이 H의 FinalizeBlock update가 H+2 블록부터 효력을 냅니다.
Cosmos SDK의 staking end-block 처리와 ABCI의 validator updates는 애플리케이션 층이고, CometBFT의 Validators·NextValidators는 합의 엔진 층입니다. 체인 버전과 ABCI 규격에 따라 메서드 이름은 달라질 수 있으므로 특정 함수명보다 반환 높이와 적용 높이를 기록하는 편이 안전합니다.
검증자 변경은 블록 실행의 결과이며, 그 블록 합의의 원인이 될 수 없다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 같은 블록을 소급해 다시 투표하지 않는다
검증자 세트는 각 height의 proposer 선택과 투표권 합계를 결정합니다.
- 세 높이를 표에 따로 놓는다
운영자가 ‘h에서 위임이 바뀌었다’고 말할 때 transaction 포함 높이, staking 모듈이 power 변화를 계산한 높이, CometBFT가 새 set을 사용하는 높이가 섞일 수 있습니다.
- power 0과 key 교체를 단순 감소로 읽지 않는다
ABCI validator update에서 power 0은 일반적으로 해당 키를 세트에서 제거하는 의미입니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
세 높이를 표에 따로 놓는다
운영자가 ‘h에서 위임이 바뀌었다’고 말할 때 transaction 포함 높이, staking 모듈이 power 변화를 계산한 높이, CometBFT가 새 set을 사용하는 높이가 섞일 수 있습니다. unbonding이나 epoch 기반 선정을 쓰는 체인은 추가 지연 규칙도 가질 수 있습니다. 일반 ABCI 설명만으로 특정 체인의 즉시 반영을 단정하면 안 됩니다.
감사할 때는 h-1, h, h+1의 validators 응답과 commit을 연속 조회합니다. update의 public key 인코딩과 power 0 삭제 의미를 확인하고 중복 키가 없는지 봅니다. proposer가 바뀌지 않았다는 사실만으로 update 실패라고 판단할 수 없습니다. proposer priority는 voting power와 별도 누적 규칙을 갖습니다.
| 기록 | 질문 | 증거 |
|---|---|---|
| staking 상태 | 위임·bond 상태가 언제 변했나 | 애플리케이션 이벤트·상태 |
| ABCI update | 어느 블록 결과로 power를 반환했나 | FinalizeBlock/EndBlock 응답 |
| validator set | 어느 height 합의에 사용됐나 | validators RPC |
| commit | 실제로 누가 얼마의 power로 서명했나 | block commit signatures |
power 0과 key 교체를 단순 감소로 읽지 않는다
ABCI validator update에서 power 0은 일반적으로 해당 키를 세트에서 제거하는 의미입니다. 동일 운영자가 키를 교체하면 기존 키 제거와 새 키 추가가 함께 보일 수 있습니다. 두 줄을 독립 검증자 감소·증가로 세면 활성 수와 운영 주체를 잘못 집계합니다.
public key 유형과 바이트 표현도 일치시켜야 합니다. 화면의 운영자 주소, consensus address, account address는 서로 다른 인코딩일 수 있습니다. 주소 문자열이 다르다는 이유로 별개 검증자라고 결론 내리지 말고 키 변환 규칙과 온체인 매핑을 확인합니다.
- 변경 transaction·이벤트의 포함 height를 저장한다
- 해당 height의 ABCI validator updates를 public key 기준으로 정규화한다
- 전후 validators RPC에서 voting power와 total을 비교한다
- 다음 commit의 서명 집합을 새 set 기준으로 검산한다
세트 변경은 임계값도 바꾼다
+2/3 조건은 고정 코인 수가 아니라 해당 height validator set의 total voting power를 기준으로 계산됩니다. 큰 power가 추가·제거되면 같은 서명자 집합도 다음 height에서 다른 비율이 됩니다. 모니터링은 validator 수뿐 아니라 total과 개별 power를 함께 저장해야 합니다.
대규모 변경은 안전성과 진행성에 영향을 줄 수 있어 애플리케이션 자체가 한 블록 변화량을 제한하기도 합니다. 그 제한은 CometBFT 일반 규칙이 아니라 체인별 staking·거버넌스 규칙일 수 있습니다. 문서와 실제 파라미터를 확인하지 않고 공통 상한으로 표현하지 않습니다.
현재·다음 세트를 이름 그대로 읽는다
노드 내부 상태나 디버그 출력에는 current validators와 next validators가 함께 나타날 수 있습니다. next를 이미 현재 합의 권한이라고 부르면 한 높이 앞서 해석하게 됩니다. 반대로 explorer 캐시가 늦으면 실제 적용 뒤에도 과거 power가 보일 수 있습니다. RPC height를 명시해 같은 시점 자료를 대조합니다.
결론은 간단합니다. 변경 요청, 앱 계산, 엔진 적용, 실제 commit을 네 칸으로 나누면 시차가 보입니다. 이 구조는 검증자 추가가 실패했는지, 표시만 늦는지, 다음 높이에 정상 적용됐는지를 구분하는 가장 재현 가능한 방법입니다.
자주 묻는 질문
검증자 등록 transaction이 들어간 블록에 새 검증자가 서명하나요?
그 블록의 합의 세트는 실행 결과보다 먼저 정해졌으므로 소급 서명하지 않습니다. 현재 CometBFT ABCI++ 기준 H에서 반환된 update는 H+2부터 효력이 생기며 체인 버전과 RPC로 확인해야 합니다.
validator 수만 비교하면 변경을 확인할 수 있나요?
아닙니다. power 변경과 키 교체는 수가 같아도 발생하므로 public key와 voting power를 비교해야 합니다.
proposer가 그대로면 update가 실패한 것인가요?
아닙니다. proposer priority 규칙 때문에 set 변경과 즉시 proposer 교체는 같은 사건이 아닙니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
