코스모스 애플리케이션이 블록을 처리하면서 검증자 변경분(validator update)을 돌려줘도 같은 블록의 합의를 거슬러 바꾸지는 않습니다. 현재 CometBFT ABCI++ 요구사항에서는 높이 H의 FinalizeBlock 응답으로 돌려준 변경분이 H+2 블록부터 효력을 냅니다. 그래서 ‘스테이킹 상태가 바뀐 높이’, ‘ABCI 변경분이 반환된 높이’, ‘새 투표권이 실제 합의에 쓰인 높이’를 나눠 확인해야 합니다.
같은 블록을 거슬러 다시 투표하지 않습니다
검증자 세트는 높이마다 블록 제안자(proposer) 선택과 투표권 합계를 정합니다. 애플리케이션이 블록을 실행한 결과로 새 검증자 공개키와 투표권을 돌려줘도 이미 그 블록을 제안하고 최종 투표(precommit)한 집합은 바뀌지 않습니다. 현재 CometBFT ABCI++ 요구사항에서는 높이 H의 FinalizeBlock 변경분이 H+2 블록부터 효력을 냅니다.
코스모스 SDK의 스테이킹 블록 끝 처리와 ABCI의 검증자 변경분은 애플리케이션 층에 속하고, CometBFT의 Validators·NextValidators는 합의 엔진 층에 속합니다. 체인 버전과 ABCI 규격에 따라 메서드 이름은 달라질 수 있으니 특정 함수 이름보다 반환 높이와 적용 높이를 기록하는 편이 안전합니다.
검증자 변경은 블록 실행의 결과이며, 그 블록 합의의 원인이 될 수 없습니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 같은 블록을 거슬러 다시 투표하지 않습니다
검증자 세트는 높이마다 블록 제안자(proposer) 선택과 투표권 합계를 정합니다.
- 세 높이를 표에 따로 놓습니다
운영자가 ‘h에서 위임이 바뀌었다’고 말할 때는 거래가 포함된 높이, 스테이킹 모듈이 투표권 변화를 계산한 높이, CometBFT가 새 세트를 쓰기 시작한 높이가 섞여 있을 수 있습니다.
- 투표권 0과 키 교체를 단순 감소로 읽지 않습니다
ABCI 검증자 변경분에서 투표권 0은 보통 해당 키를 세트에서 뺀다는 뜻입니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
세 높이를 표에 따로 놓습니다
운영자가 ‘h에서 위임이 바뀌었다’고 말할 때는 거래가 포함된 높이, 스테이킹 모듈이 투표권 변화를 계산한 높이, CometBFT가 새 세트를 쓰기 시작한 높이가 섞여 있을 수 있습니다. 언본딩이나 에폭 단위 선정을 쓰는 체인에는 지연 규칙이 더 붙기도 합니다. 일반적인 ABCI 설명만 보고 특정 체인에서 곧바로 반영된다고 단정하면 안 됩니다.
감사할 때는 h-1, h, h+1의 validators 응답과 커밋을 이어서 조회합니다. 변경분의 공개키 인코딩과 투표권 0이 삭제를 뜻하는지 확인하고, 중복 키가 없는지도 봅니다. 제안자가 바뀌지 않았다는 사실만으로 변경이 실패했다고 판단할 수는 없습니다. 제안자 우선순위는 투표권과 별개로 쌓이는 규칙을 따릅니다.
| 기록 | 질문 | 증거 |
|---|---|---|
| 스테이킹 상태 | 위임·본딩 상태가 언제 바뀌었나 | 애플리케이션 이벤트·상태 |
| ABCI 변경분 | 어느 블록 결과로 투표권을 돌려줬나 | FinalizeBlock/EndBlock 응답 |
| 검증자 세트 | 어느 높이의 합의에 쓰였나 | validators RPC |
| 커밋 | 실제로 누가 얼마의 투표권으로 서명했나 | 블록 커밋 서명 |
투표권 0과 키 교체를 단순 감소로 읽지 않습니다
ABCI 검증자 변경분에서 투표권 0은 보통 해당 키를 세트에서 뺀다는 뜻입니다. 같은 운영자가 키를 바꾸면 기존 키 제거와 새 키 추가가 함께 보일 수 있습니다. 이 두 줄을 서로 다른 검증자의 감소와 증가로 세면 활성 검증자 수와 운영 주체를 잘못 집계하게 됩니다.
공개키 유형과 바이트 표현도 맞춰야 합니다. 화면에 보이는 운영자 주소, 합의용 주소, 계정 주소는 서로 다른 인코딩일 수 있습니다. 주소 문자열이 다르다는 이유만으로 별개의 검증자라고 결론 내리지 말고 키 변환 규칙과 온체인 매핑을 확인합니다.
- 변경 거래·이벤트가 포함된 높이를 저장합니다
- 그 높이의 ABCI 검증자 변경분을 공개키 기준으로 정리합니다
- 앞뒤 validators RPC에서 투표권과 합계를 비교합니다
- 다음 커밋의 서명 집합을 새 세트 기준으로 검산합니다
세트가 바뀌면 임계값도 바뀝니다
+2/3 조건은 정해진 코인 수가 아니라 해당 높이 검증자 세트의 전체 투표권을 기준으로 계산합니다. 큰 투표권이 더해지거나 빠지면 같은 서명자 집합이라도 다음 높이에서는 비율이 달라집니다. 모니터링에서는 검증자 수뿐 아니라 전체 투표권과 개별 투표권을 함께 저장해야 합니다.
대규모 변경은 안전성과 진행성에 영향을 줄 수 있어 애플리케이션이 한 블록의 변화량을 직접 제한하기도 합니다. 그 제한은 CometBFT의 일반 규칙이 아니라 체인마다 다른 스테이킹·거버넌스 규칙일 수 있습니다. 문서와 실제 파라미터를 확인하지 않고 공통 상한처럼 말하지 않습니다.
현재 세트와 다음 세트를 이름 그대로 읽습니다
노드 내부 상태나 디버그 출력에는 현재 검증자와 다음 검증자가 함께 나올 수 있습니다. 다음 세트를 이미 현재 합의 권한이라고 부르면 한 높이 앞서 해석하는 셈입니다. 반대로 탐색기 캐시가 늦으면 실제로 적용된 뒤에도 예전 투표권이 보일 수 있습니다. RPC 조회 높이를 명시해 같은 시점의 자료끼리 대조합니다.
결론은 간단합니다. 변경 요청, 앱 계산, 엔진 적용, 실제 커밋을 네 칸으로 나누면 시차가 보입니다. 이 구조는 검증자 추가가 실패했는지, 표시만 늦은지, 다음 높이에 정상 적용됐는지를 가려내는 가장 재현하기 쉬운 방법입니다.
자주 묻는 질문
검증자 등록 거래가 들어간 블록에 새 검증자가 서명하나요?
그 블록의 합의 세트는 실행 결과보다 먼저 정해졌으므로 거슬러 서명하지 않습니다. 현재 CometBFT ABCI++ 기준으로 H에서 돌려준 변경분은 H+2부터 효력이 생기며, 체인 버전과 RPC로 확인해야 합니다.
검증자 수만 비교하면 변경을 확인할 수 있나요?
아닙니다. 투표권 변경과 키 교체는 수가 같아도 일어나므로 공개키와 투표권을 비교해야 합니다.
제안자가 그대로면 변경이 실패한 것인가요?
아닙니다. 제안자 우선순위 규칙 때문에 세트 변경과 즉각적인 제안자 교체는 같은 사건이 아닙니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
