이중서명 증거는 같은 검증자 키가 같은 높이·라운드·투표 유형에서 서로 다른 블록 ID에 서명한 두 투표처럼, 동시에 참일 수 없는 서명 자료로 이뤄집니다. CometBFT는 키·서명·시점·검증자 세트·증거 유효기간을 검증해 블록 증거로 넘기고, 실제 슬래싱(slashing)과 감금(jailing)은 애플리케이션 규칙이 정합니다. 중복 서명처럼 보이는 화면만으로 처벌이 끝났다고 단정할 수 없습니다.
두 표가 함께 유효할 수 없어야 한다
정상적인 재전송은 같은 투표 바이트와 서명을 여러 피어가 관측한 것일 수 있습니다. 이중서명은 같은 검증자 합의 키가 같은 높이·라운드·투표 유형에서 다른 블록 ID에 서명한 경우처럼 충돌이 분명해야 합니다. 사전투표(prevote)와 사전커밋(precommit)이 하나씩 있다고 이중서명이 되는 것은 아닙니다. 두 단계는 정상 합의 절차입니다.
증거를 모으는 쪽은 두 SignedVote의 체인 ID, 검증자 주소, 타임스탬프, 서명, 블록 ID를 그대로 보존해야 합니다. 탐색기 캡처나 로그 한 줄은 단서일 뿐 암호학적 증거 원문을 대신하지 못합니다. 그 키가 당시 검증자 세트에 있었고 해당 투표권을 가졌는지도 검증해야 합니다.
이중서명 증거는 의심스러운 두 화면이 아니라, 같은 합의 위치를 두 갈래로 서명한 검증 가능한 원문입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 두 표가 함께 유효할 수 없어야 한다
정상적인 재전송은 같은 투표 바이트와 서명을 여러 피어가 관측한 것일 수 있습니다.
- 증거 풀에서 블록 포함까지
노드는 유효할 가능성이 있는 증거를 받으면 기본 형식과 합의 상태를 확인해 증거 풀에 보관하고 피어에게 전파합니다.
- 유효기간은 블록과 시간 두 축을 본다
CometBFT 증거 매개변수는 최대 블록 수와 기간 같은 한계를 둡니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
증거 풀에서 블록 포함까지
노드는 유효할 가능성이 있는 증거를 받으면 기본 형식과 합의 상태를 확인해 증거 풀에 보관하고 피어에게 전파합니다. 제안자는 이를 블록의 증거 목록에 넣을 수 있습니다. 블록 검증자는 증거가 중복으로 들어가지 않았는지, 너무 오래되지 않았는지, 당시 검증자 정보와 서명이 맞는지 다시 확인합니다.
증거가 네트워크에 퍼졌다는 사실과 블록에 커밋됐다는 사실은 다릅니다. RPC의 미확정 증거, 블록의 증거 필드, 애플리케이션 이벤트를 단계별로 기록해야 합니다. 멤풀 거래와 증거 풀도 서로 다른 경로이므로, 일반 거래 해시만 찾다가 누락으로 잘못 판단할 수 있습니다.
| 단계 | 확인 자료 | 아직 단정 못 하는 것 |
|---|---|---|
| 관측 | 충돌하는 SignedVote 두 개 | 온체인 포함 |
| CometBFT 검증 | 서명·검증자 세트·유효기간 | 앱 처벌 결과 |
| 블록 포함 | 블록 증거 | 슬래싱 금액 |
| 앱 처리 | 증거·슬래싱 이벤트 | 운영자 의도 |
유효기간은 블록과 시간 두 축을 본다
CometBFT 증거 매개변수는 최대 블록 수와 기간 같은 한계를 둡니다. 오래된 위반은 당시 상태를 계속 보관하고 검증하는 비용 때문에 허용 범위 밖이 될 수 있습니다. 조건 하나만 채우면 된다고 가정하지 말고 체인 설정의 검증 논리를 확인해야 합니다.
노드의 데이터 정리(pruning)와 증거 유효성도 같은 개념이 아닙니다. RPC가 과거 블록을 주지 못한다고 프로토콜상 유효기간이 끝났다고 단정할 수 없고, 자료를 보관했다고 언제까지나 제출할 수 있는 것도 아닙니다. 발견 높이, 위반 높이, 현재 높이, 블록 시간을 함께 남깁니다.
- 두 투표의 원시 바이트·서명·체인 ID를 손대지 않고 보존합니다
- 높이·라운드·유형은 같고 블록 ID만 다른지 비교합니다
- 위반 높이의 검증자 세트와 공개키·투표권을 조회합니다
- 현재 증거 최대 유효기간과 블록 포함·앱 이벤트를 차례로 확인합니다
처벌은 애플리케이션이 결정한다
CometBFT는 비잔틴 행위 증거를 검증해 ABCI로 애플리케이션에 넘깁니다. 하지만 얼마를 깎고 얼마 동안 감금할지는 Cosmos SDK 모듈과 체인 매개변수가 정합니다. 모든 Cosmos 체인이 같은 비율과 영구 퇴출(tombstone) 규칙을 쓴다고 말할 수 없습니다. 거버넌스 업그레이드로 매개변수가 바뀔 수도 있습니다.
운영자 주소와 합의 키를 짝지어 실제 검증자를 식별하고, 증거가 처리된 시점의 매개변수를 써야 합니다. 현재 설정을 과거 사건에 거슬러 적용하거나 다른 체인의 처벌 비율을 가져오면 잘못된 추정이 됩니다. 슬래싱 이벤트와 스테이킹 상태가 실제로 바뀌었는지 확인합니다.
오탐을 줄이는 최소 판정표
첫째, 같은 서명을 두 번 본 것은 중복 전파일 수 있습니다. 둘째, 서로 다른 라운드의 표는 정상적인 라운드 전환일 수 있습니다. 셋째, 사전투표와 사전커밋의 차이는 정상적인 단계 차이입니다. 넷째, 같은 높이·라운드·유형에서 블록 ID가 다른 유효 서명이어야 핵심 충돌 조건에 다가갑니다.
그다음에야 증거 유효기간, 검증자 자격, 서명 검증, 블록 포함, 앱 처벌을 봅니다. 이 순서를 지키면 잠깐의 네트워크 분할이나 로그 중복을 이중서명 사고로 부풀리지 않고, 실제 위반은 재현 가능한 자료로 남길 수 있습니다.
자주 묻는 질문
같은 투표 로그가 두 번 보이면 이중서명인가요?
아닙니다. 같은 메시지가 다시 전파된 것일 수 있으며, 서로 다른 블록 ID에 대한 유효 서명 두 개가 필요합니다.
증거가 노드에 도착하면 바로 슬래싱되나요?
아닙니다. 검증과 블록 포함, 애플리케이션 처리를 거쳐야 하며 처벌 규칙은 체인별입니다.
아주 오래된 이중서명도 제출할 수 있나요?
체인의 증거 최대 유효기간 제한을 채워야 하므로 위반·발견·현재 시점을 확인해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
