이중서명 증거는 같은 검증자 키가 동일 height·round·vote type에서 서로 다른 block ID에 서명한 두 투표처럼 함께 참일 수 없는 서명 자료로 구성됩니다. CometBFT는 키·서명·시점·validator set·evidence age를 검증해 블록 evidence로 전달하고, 실제 slashing·jailing은 애플리케이션 규칙이 결정합니다. 중복 서명처럼 보이는 화면만으로 처벌 완료를 단정할 수 없습니다.
두 표가 함께 유효할 수 없어야 한다
정상 재전송은 같은 vote bytes와 서명을 여러 peer가 관측한 것일 수 있습니다. 이중서명은 같은 validator consensus key가 같은 height·round·vote type에서 다른 block ID에 서명한 경우처럼 충돌이 명확해야 합니다. prevote와 precommit이 각각 하나씩 있다는 이유만으로 이중서명이 아닙니다. 두 단계는 정상 합의 절차입니다.
증거 수집자는 두 SignedVote의 체인 ID, validator address, timestamp, signature와 block ID를 보존해야 합니다. 탐색기 캡처나 로그 한 줄은 단서일 뿐 암호학적 증거 원문을 대신하지 못합니다. 키가 당시 validator set에 있었고 해당 voting power를 가졌는지도 검증해야 합니다.
이중서명 증거는 의심스러운 두 화면이 아니라 같은 합의 위치를 두 갈래로 서명한 검증 가능한 원문이다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 두 표가 함께 유효할 수 없어야 한다
정상 재전송은 같은 vote bytes와 서명을 여러 peer가 관측한 것일 수 있습니다.
- evidence pool에서 블록 포함까지
노드가 유효 가능성이 있는 evidence를 받으면 기본 형식과 합의 상태를 확인해 evidence pool에 보관하고 peer에 전파합니다.
- 유효기간은 블록과 시간 두 축을 본다
CometBFT evidence 파라미터는 max age num blocks와 duration 같은 한계를 둡니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
evidence pool에서 블록 포함까지
노드가 유효 가능성이 있는 evidence를 받으면 기본 형식과 합의 상태를 확인해 evidence pool에 보관하고 peer에 전파합니다. proposer는 블록의 evidence 목록에 이를 포함할 수 있습니다. 블록 검증자는 evidence가 중복 포함되지 않았는지, 너무 오래되지 않았는지, 당시 validator 정보와 서명이 맞는지 다시 확인합니다.
evidence가 네트워크에 전파됐다는 사실과 블록에 커밋됐다는 사실은 다릅니다. RPC의 unconfirmed evidence, 블록의 evidence 필드, 애플리케이션 이벤트를 단계별로 기록해야 합니다. mempool transaction과 evidence pool도 서로 다른 경로이므로 일반 transaction hash만 찾다가 누락으로 오판할 수 있습니다.
| 단계 | 확인 자료 | 아직 단정 못 하는 것 |
|---|---|---|
| 관측 | 충돌 SignedVote 두 개 | 온체인 포함 |
| CometBFT 검증 | 서명·validator set·age | 앱 처벌 결과 |
| 블록 포함 | block evidence | slash 금액 |
| 앱 처리 | evidence·slashing 이벤트 | 운영자 의도 |
유효기간은 블록과 시간 두 축을 본다
CometBFT evidence 파라미터는 max age num blocks와 duration 같은 한계를 둡니다. 오래된 위반은 당시 상태를 계속 보관·검증하는 비용 때문에 허용 창 밖이 될 수 있습니다. 한 조건만 만족하면 된다고 가정하지 말고 체인 설정의 검증 논리를 확인해야 합니다.
노드 pruning과 evidence 유효성도 같은 개념이 아닙니다. RPC가 과거 블록을 제공하지 못한다고 프로토콜상 age가 끝났다고 단정할 수 없고, 자료를 보관했다고 무기한 제출 가능한 것도 아닙니다. 발견 height, 위반 height, 현재 height, 블록 시간을 함께 남깁니다.
- 두 투표의 raw bytes·signature·chain ID를 변형 없이 보존한다
- height·round·type은 같고 block ID가 다른지 비교한다
- 위반 height의 validator set과 public key·power를 조회한다
- 현재 evidence max age와 블록 포함·앱 이벤트를 순서대로 확인한다
처벌은 애플리케이션이 결정한다
CometBFT는 Byzantine evidence를 검증해 ABCI로 애플리케이션에 전달하지만, 얼마를 slash하고 얼마나 jail할지는 Cosmos SDK 모듈과 체인 파라미터가 정합니다. 모든 Cosmos 체인이 같은 비율과 tombstone 규칙을 쓴다고 말할 수 없습니다. governance 업그레이드로 파라미터가 바뀔 수도 있습니다.
운영자 주소와 consensus key를 매핑해 실제 validator를 식별하고, evidence 처리 시점의 파라미터를 사용해야 합니다. 현재 설정을 과거 사건에 소급 적용하거나 다른 체인의 처벌률을 가져오면 잘못된 추정이 됩니다. slashing event와 staking 상태가 실제로 변했는지 확인합니다.
오탐을 줄이는 최소 판정표
첫째 같은 서명을 두 번 본 것은 중복 전파일 수 있습니다. 둘째 서로 다른 round의 표는 정상 round 전환일 수 있습니다. 셋째 prevote와 precommit의 차이는 정상 단계 차이입니다. 넷째 같은 height·round·type에서 block ID가 다른 유효 서명이어야 핵심 충돌 조건에 접근합니다.
그 다음에야 evidence age, validator membership, 서명 검증, 블록 포함, 앱 처벌을 봅니다. 이 순서를 지키면 잠깐의 네트워크 분할이나 로그 중복을 이중서명 사고로 과장하지 않고, 실제 위반은 재현 가능한 자료로 남길 수 있습니다.
자주 묻는 질문
같은 투표 로그가 두 번 보이면 이중서명인가요?
아닙니다. 동일 메시지 재전파일 수 있으며 서로 다른 block ID에 대한 두 유효 서명이 필요합니다.
evidence가 노드에 도착하면 즉시 slash되나요?
아닙니다. 검증과 블록 포함, 애플리케이션 처리를 거쳐야 하며 처벌 규칙은 체인별입니다.
아주 오래된 이중서명도 제출할 수 있나요?
체인의 evidence max age 제한을 만족해야 하므로 위반·발견·현재 시점을 확인해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
