검증자 필수 업데이트 공지, 권고 버전과 마감 블록 확인하기

검증자 업데이트가 ‘필수’인지 판단하려면 새 consensus rule이나 state migration이 적용되는 정확한 block height, 지원 binary version과 checksum, governance plan을 확인한다. 권고 보안 패치와 높이 기반 합의 업그레이드는 운영 결과가 다르다. 미업데이트 node가 단순 offline이 되는지, 옛 rule로 다른 block을 서명할 수 있는지, jail·slashing·reward 누락 조건이 무엇인지 chain 문서에서 확인해야 한다.

필수라는 말의 기술적 조건을 찾는다

새 binary가 activation height에서 달라진 block validity rule이나 deterministic migration을 실행하면 validator는 같은 logic을 같은 높이에 적용해야 한다. Cosmos EVM upgrade handler 문서는 모든 validator가 같은 height에서 같은 upgrade logic을 실행해야 하며, version 불일치나 handler 누락은 consensus failure 원인이 될 수 있다고 설명한다.

성능 개선·RPC 수정처럼 consensus에 영향을 주지 않는 release는 권고일 수 있다. 반대로 공지에 mandatory라고 쓰지 않아도 old client가 새 block을 거부하면 사실상 필수다. release note의 consensus change, protocol version, upgrade plan 이름과 height를 확인한다.

필수 여부는 문구의 강도가 아니라 활성화 높이에서 옛 노드가 같은 블록을 유효하다고 판단하는지로 결정된다.

JOBCOIN 해설

VISUAL GUIDE뉴스·공시를 확인하는 세 가지 기준

1. 01
   필수라는 말의 기술적 조건을 찾는다

   새 binary가 activation height에서 달라진 block validity rule이나 deterministic migration을 실행하면 validator는 같은 logic을 같은 높이에 적용해야 한다.

2. 02
   달력 시각보다 block height를 기준으로 준비한다

   block time 추정으로 표시한 시각은 network 속도에 따라 앞뒤로 움직인다.

3. 03
   바이너리 출처와 재현성을 확인한다

   공식 repository release와 signed tag, build instruction을 확인하고 binary checksum을 두 채널에서 대조한다.

AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

달력 시각보다 block height를 기준으로 준비한다

block time 추정으로 표시한 시각은 network 속도에 따라 앞뒤로 움직인다. 공지의 activation height를 기준으로 현재 height와 평균 block time을 관찰하고, 운영 인력 대기 시간은 넉넉히 잡는다. UTC와 현지 시각을 함께 쓰되 실행 trigger로 고정 시각을 사용하지 않는다.

Ethereum Constantinople 연기 공지는 예정 block 7,080,000 전에 node operator·exchange·miner·wallet service가 새 version으로 업데이트하도록 안내했고, 보안 위험 때문에 fork를 연기했다. 예정 높이가 발표됐다는 사실과 실제 activation은 다르며 후속 공지를 확인해야 한다.

바이너리 출처와 재현성을 확인한다

공식 repository release와 signed tag, build instruction을 확인하고 binary checksum을 두 채널에서 대조한다. 파일 이름이 같아도 교체될 수 있으므로 내려받은 실제 hash를 기록한다. container image는 tag 대신 digest를 고정하고 image 내부 binary version도 조회한다.

Cosmovisor 같은 자동 도구는 정해진 plan에서 binary 교체를 도울 뿐 파일의 신뢰성과 migration 안전을 자동 보증하지 않는다. download URL, 권한, data directory와 restart command를 staging node에서 시험한다. validator private key는 build host나 배포 archive에 포함하지 않는다.

업데이트 순서는 이중 서명을 막아야 한다

active signer가 두 machine에서 동시에 같은 validator key를 사용하지 않도록 process 종료와 signer 연결을 명시적으로 확인한다. sentry·RPC node를 먼저 올려 peer·query·migration을 보고, validator는 유지보수 계획에 따라 전환한다. remote signer가 chain ID와 height를 잘못 인식하지 않는지 본다.

업그레이드 height에서 old node가 panic으로 멈추는 설계라면 재시작 전 log와 application hash를 보존한다. 자동 restart가 old binary를 반복 실행하면 복구가 늦어진다. 반대로 임의 downgrade나 data 삭제는 state 손상을 키울 수 있으므로 공식 recovery 절차를 따른다.

• governance plan과 activation height를 확인한다
• binary version·commit·checksum을 기록한다
• snapshot·data backup의 복원 가능성을 점검한다
• 동시에 두 signer가 켜지지 않게 한다
• upgrade 뒤 app hash·peer·proposal·vote를 확인한다

미업데이트 영향은 chain별로 다르다

일부 chain은 upgrade height에서 명시적으로 halt해 operator가 새 binary를 설치할 때까지 기다린다. 다른 chain은 old node가 새 rule block을 invalid로 보고 minority fork에 남을 수 있다. missed vote는 reward 감소·downtime jail로 이어질 수 있지만 slash threshold와 window는 network parameter를 확인해야 한다.

공지에 ‘보상 손실 가능’이라고만 쓰지 말고 어느 height부터 어떤 metric으로 계산하는지 제시한다. validator 외 full node·indexer·relayer·exchange도 API나 transaction encoding 변화의 영향을 받을 수 있어 대상 구성표가 필요하다.

완료 선언은 chain 진행과 참여를 보여 준다

새 binary process가 떠 있다는 사실만으로 upgrade 성공은 아니다. activation block의 hash·AppHash, 다음 여러 block의 finality, validator participation과 missed block, governance plan applied query를 확인한다. 여러 client·provider의 height가 같은지 대조한다.

후속 공지는 권고 version이 다시 바뀌었는지와 알려진 문제를 갱신한다. emergency patch가 나오면 처음 공지의 download 링크만 조용히 바꾸지 말고 새 version·checksum·영향 node를 별도 기록한다. 운영자는 실제 전환 시각과 검증 명령 결과를 change log에 남긴다.

자주 묻는 질문