검증자 업데이트가 ‘필수’인지 판단하려면 새 합의 규칙이나 상태 이전이 적용되는 정확한 블록 높이, 지원 실행 파일의 버전과 체크섬, 거버넌스 계획을 확인해야 합니다. 권고 수준의 보안 패치와 높이에 맞춰 바뀌는 합의 업그레이드는 운영 결과가 다릅니다. 업데이트하지 않은 노드가 그냥 멈추는지, 옛 규칙으로 다른 블록에 서명할 수 있는지, 감금(jail)·슬래싱·보상 누락 조건이 무엇인지 체인 문서에서 확인해야 합니다.
필수라는 말의 기술적 조건을 찾는다
새 실행 파일이 활성화 높이에서 바뀐 블록 유효성 규칙이나 결정적인 상태 이전을 실행한다면, 검증자는 같은 로직을 같은 높이에 적용해야 합니다. Cosmos EVM 업그레이드 핸들러 문서는 모든 검증자가 같은 높이에서 같은 업그레이드 로직을 실행해야 하며, 버전이 어긋나거나 핸들러가 빠지면 합의 실패의 원인이 될 수 있다고 설명합니다.
성능 개선이나 RPC 수정처럼 합의에 영향을 주지 않는 배포는 권고일 수 있습니다. 반대로 공지에 필수라는 말이 없어도 옛 클라이언트가 새 블록을 거부한다면 사실상 필수입니다. 배포 노트의 합의 변경 사항, 프로토콜 버전, 업그레이드 계획 이름과 높이를 확인합니다.
필수 여부는 문구가 얼마나 강한지가 아니라, 활성화 높이에서 옛 노드가 같은 블록을 유효하다고 판단하는지로 정해집니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 필수라는 말의 기술적 조건을 찾는다
새 실행 파일이 활성화 높이에서 바뀐 블록 유효성 규칙이나 결정적인 상태 이전을 실행한다면, 검증자는 같은 로직을 같은 높이에 적용해야 합니다.
- 달력 시각보다 block height를 기준으로 준비한다
블록 생성 간격으로 추정해 표시한 시각은 네트워크 속도에 따라 앞뒤로 움직입니다.
- 바이너리 출처와 재현성을 확인한다
공식 저장소의 배포본과 서명된 태그, 빌드 안내를 확인하고 실행 파일 체크섬을 두 경로에서 대조합니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
달력 시각보다 block height를 기준으로 준비한다
블록 생성 간격으로 추정해 표시한 시각은 네트워크 속도에 따라 앞뒤로 움직입니다. 공지의 활성화 높이를 기준으로 현재 높이와 평균 블록 간격을 지켜보고, 운영 인력의 대기 시간은 넉넉히 잡습니다. 협정 세계시(UTC)와 현지 시각을 함께 적되 실행 신호로 고정 시각을 쓰지 않습니다.
Ethereum Constantinople 연기 공지는 예정 블록 7,080,000 이전에 노드 운영자·거래소·채굴자·지갑 서비스가 새 버전으로 업데이트하라고 안내했고, 이후 보안 위험 때문에 포크를 미뤘습니다. 예정 높이가 발표됐다는 것과 실제 활성화는 별개이므로 후속 공지를 확인해야 합니다.
| 필드 | 확인값 | 운영 의미 |
|---|---|---|
| 계획 | 이름·거버넌스 ID | 실행 대상 |
| 높이 | 정확한 블록 | 전환 신호 |
| 실행 파일 | 버전·커밋·체크섬 | 같은 코드인지 확인 |
| 대비책 | 중지·되돌리기 절차 | 실패 대응 |
| 제재 | 감금·슬래싱 조건 | 서명기 위험 |
바이너리 출처와 재현성을 확인한다
공식 저장소의 배포본과 서명된 태그, 빌드 안내를 확인하고 실행 파일 체크섬을 두 경로에서 대조합니다. 파일 이름이 같아도 내용이 바뀔 수 있으니 내려받은 파일의 실제 해시를 기록합니다. 컨테이너 이미지는 태그 대신 다이제스트로 고정하고, 이미지 안의 실행 파일 버전도 조회합니다.
Cosmovisor 같은 자동화 도구는 정해진 계획에 따라 실행 파일 교체를 도울 뿐, 파일의 신뢰성과 상태 이전의 안전까지 보증하지는 않습니다. 내려받을 주소, 권한, 데이터 디렉터리, 재시작 명령을 시험용 노드에서 먼저 돌려 봅니다. 검증자 개인 키는 빌드 서버나 배포 압축 파일에 넣지 않습니다.
업데이트 순서는 이중 서명을 막아야 한다
서명 중인 검증자 키를 두 대의 장비가 동시에 쓰지 않도록 프로세스 종료와 서명기 연결을 하나하나 확인합니다. 센트리 노드와 RPC 노드를 먼저 올려 피어·조회·상태 이전을 살펴보고, 검증자는 유지보수 계획에 따라 전환합니다. 원격 서명기가 체인 ID와 높이를 잘못 읽지 않는지도 봅니다.
업그레이드 높이에서 옛 노드가 비정상 종료로 멈추도록 설계된 체인이라면, 다시 켜기 전에 로그와 애플리케이션 해시를 보존합니다. 자동 재시작이 옛 실행 파일을 계속 띄우면 복구가 늦어집니다. 반대로 임의로 버전을 낮추거나 데이터를 지우면 상태 손상이 커질 수 있으니 공식 복구 절차를 따릅니다.
- 거버넌스 계획과 활성화 높이를 확인합니다
- 실행 파일의 버전·커밋·체크섬을 기록합니다
- 스냅샷·데이터 백업을 실제로 복원할 수 있는지 점검합니다
- 서명기 두 개가 동시에 켜지지 않게 합니다
- 업그레이드 뒤 앱 해시·피어·제안·투표를 확인합니다
미업데이트 영향은 chain별로 다르다
어떤 체인은 업그레이드 높이에서 일부러 멈추고, 운영자가 새 실행 파일을 설치할 때까지 기다립니다. 다른 체인에서는 옛 노드가 새 규칙의 블록을 무효로 보고 소수 포크에 남을 수 있습니다. 투표 누락은 보상 감소나 가동 중단에 따른 감금으로 이어질 수 있지만, 슬래싱 기준과 측정 구간은 네트워크 매개변수를 확인해야 합니다.
공지에 ‘보상 손실 가능’이라고만 쓰지 말고 어느 높이부터 어떤 지표로 계산하는지 밝혀야 합니다. 검증자 말고도 전체 노드·인덱서·릴레이어·거래소가 API나 거래 인코딩 변화의 영향을 받을 수 있으므로 대상별 구성표가 필요합니다.
완료 선언은 chain 진행과 참여를 보여 준다
새 실행 파일 프로세스가 떠 있다는 것만으로 업그레이드가 성공한 것은 아닙니다. 활성화 블록의 해시와 AppHash, 뒤이은 여러 블록의 확정, 검증자 참여율과 누락 블록, 거버넌스 계획 적용 여부 조회를 확인합니다. 여러 클라이언트와 제공자의 높이가 같은지도 대조합니다.
후속 공지는 권고 버전이 다시 바뀌었는지, 알려진 문제가 무엇인지 갱신합니다. 긴급 패치가 나오면 처음 공지의 다운로드 링크만 조용히 바꾸지 말고, 새 버전·체크섬·영향받는 노드를 따로 기록합니다. 운영자는 실제 전환 시각과 검증 명령 결과를 변경 기록에 남깁니다.
자주 묻는 질문
권고 버전을 쓰지 않으면 바로 slash되나요?
그렇다고 단정할 수는 없습니다. 합의 호환성과 네트워크의 가동 중단·이중 서명 제재 조건을 확인합니다.
업그레이드 예정 시각에 맞춰 재시작하면 되나요?
실행 기준은 보통 블록 높이입니다. 예상 시각은 바뀔 수 있으니 실시간 높이를 지켜봅니다.
Cosmovisor를 쓰면 바이너리 검증이 필요 없나요?
아닙니다. 자동 교체 도구와 실행 파일의 출처·체크섬·상태 이전 안전성 검증은 별개입니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
