v1.20.4-bl.2 긴급 업그레이드

이번 긴급 업그레이드가 진행된 이유Injective와 관련이 없는 거래소인 BitGet이 침해 사실을 보고하고 자금 회수 지원을 요청했습니다. 해당 자금 중 일부는 다른 주요 체인과 함께 Injective와도 상호작용했을 가능성이 있습니다. 이 패치는 공격자가 BitGet의 영향받은 자금을 이동하지 못하도록 온체인 차단 목록(blocklist)을 도입했습니다. 이는 BitGet의 자금 회수를 돕고 더 넓은 생태계를 지원하기 위한 일회성 긴급 조치였습니다. 초기 배포와 조율은 검증자를 중심으로 이루어졌으며, 차단 조치가 완료되기 전에 공격자가 이를 알아차리지 못하도록 공개 커뮤니케이션은 제한되었습니다.거래소 및 기타 노드 운영자들도 업그레이드가 필요하다는 사실에 대해 충분한 사전 공지나 명확한 지침을 받지 못했음을 인지하고 있습니다. 이로 인해 발생한 혼란에 대해 사과드립니다. 이번 예외적인 대응은 일반적인 조율된 업그레이드 절차를 대체하지 않습니다.10월 7일, 차단된 주소와 관련된 트랜잭션으로 인해 패치된 노드와 패치되지 않은 노드 간의 차이가 드러났습니다. 네트워크가 계속 블록을 생성하는 동안 패치되지 않은 노드에서는 AppHash 불일치가 발생했습니다. 센트리, RPC 노드, 거래소 인프라를 포함한 모든 메인넷 노드는 반드시 이 패치를 실행해야 합니다.

요약

v1.20.4-bl.2는 **Injective 메인넷(injective-1)**을 위한 v1.20.4 릴리스 라인의 긴급 패치입니다. 합의 차단 목록은 블록 184,950,000에서 활성화되었으며, 해당 블록은 이미 지났습니다. 지금 바로 업그레이드하세요. 이 패치에는 예정된 체인 중단, 거버넌스 업그레이드 핸들러, 상태 마이그레이션이 없습니다. 체인 중단을 기다리거나 새 --halt-height를 설정하지 마세요.

노드 상태	필요한 조치
패치되지 않은 바이너리를 실행 중이며 10월 7일 AppHash 불일치로 중지됨	노드를 중지하고, 상태를 백업한 후, 기존 바이너리를 사용하여 한 블록 롤백한 다음, 패치를 설치하고 재시작합니다.
패치되지 않은 바이너리를 실행 중이며 불일치가 발생하지 않음	노드를 중지하고, 상태를 백업한 후, 패치를 설치하고 재시작합니다. 롤백은 건너뜁니다.
이미 `v1.20.4-bl.2`를 실행 중이며 정상적으로 동기화 중	롤백이나 재설치가 필요하지 않습니다. 운영 중인 모든 센트리, RPC 및 기타 노드도 패치되었는지 확인하세요.

이 지침은 검증자, 센트리, 풀 노드, 공개 및 비공개 RPC/브로드캐스트 노드, 그리고 거래소, 익스플로러 및 기타 통합 서비스를 위한 노드에 적용됩니다.

1. 릴리스 선택 및 확인

바이너리 아카이브 또는 Docker 이미지 중 하나를 선택하세요. Docker 운영자는 아카이브 다운로드를 건너뛰고 이미지를 바로 사용할 수 있습니다.

옵션 A: 바이너리 아카이브

공식 릴리스 매니페스트에 호스팅된 바이너리 목록이 있습니다. 사용 중인 플랫폼에 맞는 아카이브를 다운로드하세요:

플랫폼	다운로드
Linux AMD64	injective-v1.20.4-bl.2-linux-amd64.zip
macOS Apple Silicon	injective-v1.20.4-bl.2-darwin-arm64.zip
SHA-256 체크섬	SHA256SUMS.zip.txt

Linux AMD64의 경우, 실행 중인 바이너리를 교체하지 않도록 별도의 스테이징 디렉터리에 다운로드하세요:

mkdir -p ~/injective-v1.20.4-bl.2
cd ~/injective-v1.20.4-bl.2
curl -fLO https://storage.googleapis.com/injective-chain-releases/v1.20.4-bl.2/injective-v1.20.4-bl.2-linux-amd64.zip
echo '81f49009d1652fe8688bf6662c6d4d42ad65d7039207fd77ec2a161050973df2  injective-v1.20.4-bl.2-linux-amd64.zip' | sha256sum -c -

체크섬 결과가 OK인 경우에만 계속 진행하세요. 그런 다음 아카이브의 압축을 풉니다:

unzip injective-v1.20.4-bl.2-linux-amd64.zip

macOS의 경우 shasum -a 256을 사용하여 아카이브를 체크섬 파일의 해당 항목과 비교하세요.

옵션 B: Docker 이미지

최초 릴리스에서는 패치가 다음 Docker 이미지로 배포되었습니다:

injectivelabs/injective-core:v1.20.4-bl.2

노드 데이터를 마운트하지 않은 상태에서 이미지를 풀하고 바이너리를 확인하세요:

docker pull injectivelabs/injective-core:v1.20.4-bl.2
docker run --rm injectivelabs/injective-core:v1.20.4-bl.2 injectived version

최초 릴리스에서 AMD64에 대해 기록된 출력은 다음과 같습니다:

Version v1.20.4-bl.2 (1ffa252)
Compiled at 20260928-0409 using Go go1.26.8 (amd64)

기존 컨테이너 배포를 사용하여 아래의 중지, 백업, 복구, 재시작 단계를 계속 진행하세요. 이전 이미지는 계속 보관해 두세요. 영향받은 노드는 패치로 전환하기 전에 해당 이미지로 롤백을 완료해야 합니다. Docker 이미지에는 런타임 라이브러리가 포함되어 있으므로, 컨테이너 운영자는 호스트에 아카이브의 libwasmvm을 설치할 필요가 없습니다.

2. 노드 중지 및 상태 백업

기존 서비스 관리자 또는 컨테이너 배포를 통해 노드를 중지하세요. 복구 중에 자동으로 재시작되지 않도록 슈퍼바이저도 함께 중지하세요. 노드의 데이터 디렉터리에 접근하는 injectived 프로세스가 없는지 확인하세요. 계속 진행하기 전에 노드 구성, 키, 데이터를 백업하세요. 필요한 롤백이 완료될 때까지 기존 바이너리를 보관해 두세요. 아래 명령은 기본 홈 디렉터리인 ~/.injectived를 가정합니다. 다른 경로를 사용하는 경우 구성된 --home 경로를 사용하세요. Docker Compose 예시: 일반 배포와 동일한 Compose 파일 및 환경을 사용하여 기존 Compose 프로젝트에서 명령을 실행하세요. node_service를 실제 서비스 이름으로, container_node_home을 컨테이너 내부의 기존 홈 경로로 설정하세요. 아래 값은 예시입니다. 이 홈이 기존 바인드 마운트 또는 명명된 볼륨으로 지원되는지 확인한 후 서비스를 중지하세요:

node_service=injectived
container_node_home=/root/.injectived
docker compose stop "$node_service"

종료 후 마운트된 노드 홈을 백업하세요. 아래 Compose 명령을 위해 이 변수들을 계속 설정된 상태로 유지하세요. 일반 Docker 또는 다른 오케스트레이터를 사용하는 경우, 해당 배포를 통해 기존 노드 컨테이너를 중지하고 마운트와 설정을 보존하세요.

검증자: 노드가 완전히 중지된 후, ~/.injectived/data/priv_validator_state.json을 데이터 디렉터리 외부에 별도로 백업하세요. 롤백 또는 스냅샷 복구 과정에서 이 서명 상태를 정확히 그대로 보존하고, 재시작하기 전에 복원하세요. 원격 서명자(remote signer)의 경우 기존 서명자 절차에 따라 서명 상태를 보존하세요. 서명 상태를 절대 초기화하지 말고, 동일한 검증자 키로 두 개의 인스턴스를 실행하지 마세요.

3. 영향받은 노드 복구 (필요한 경우)

노드에서 10월 7일 AppHash 불일치가 발생한 경우에만 이 단계를 수행하세요. 보고된 오류는 다음과 같습니다:

panic: Precommit step; +2/3 prevoted for an invalid block: wrong Block.Header.AppHash.

아카이벌 노드 또는 대용량 데이터베이스를 보유한 노드의 경우, 롤백을 시도하기 전에 지원팀에 문의하여 복구 방법을 확인하세요. 적절한 스냅샷을 복원하는 것이 더 나을 수 있습니다. 노드가 중지된 상태에서, 패치를 설치하기 전에 불일치가 발생했을 때 실행 중이던 것과 동일한 바이너리 버전을 사용하세요:

injectived rollback --hard -n 1 --home ~/.injectived

이 한 블록 롤백 후 바이너리를 업그레이드하는 방법은 사고 대응 중에 테스트되었습니다. 셸의 PATH에 있는 다른 injectived가 아니라, 서비스 구성에서 사용하는 실제 실행 파일을 사용하세요.

Cosmovisor: 기존 $DAEMON_HOME/cosmovisor/current/bin/injectived를 사용하여 롤백을 실행하고, --home은 해당 노드의 홈 디렉터리를 가리키도록 지정하세요.
컨테이너: 이전 이미지와 동일한 데이터 볼륨, 노드 홈, 사용자 권한을 사용하여 일회성 명령으로 롤백을 실행하세요. 이 과정 내내 일반 노드 컨테이너는 중지된 상태로 유지하세요.

Docker Compose의 경우, 롤백이 성공할 때까지 서비스의 image를 영향받은 노드가 사용하던 정확한 이전 이미지로 유지하세요. 백업을 완료한 후, 위의 호스트 롤백 명령 대신 다음을 실행하세요:

docker compose run --rm --no-deps --pull never --entrypoint injectived \
  "$node_service" rollback --hard -n 1 --home "$container_node_home"

이 명령은 서비스에 구성된 마운트, 환경, 사용자를 재사용합니다. 이 예시는 이미지에서 injectived를 직접 사용할 수 있다고 가정합니다. 배포에서 사용자 지정 래퍼를 사용하는 경우 필요한 초기화 과정을 유지하세요. 바이너리를 교체하기 전에 롤백이 성공적으로 완료될 때까지 기다리세요. 사고 복구 지침에서는 약 10초에서 1분 정도 소요될 것으로 예상하지만, 대용량 또는 아카이벌 데이터베이스는 훨씬 더 오래 걸릴 수 있습니다. 명령이 실패하거나 불일치가 지속되더라도 추가 블록을 반복적으로 롤백하지 마세요. 노드를 중지된 상태로 유지하고 버전, 블록 높이, 로그와 함께 지원팀에 문의하세요. 롤백을 사용할 수 없거나 실패한 경우, Chain Portal 또는 Injective 지원 담당자를 통해 적절한 스냅샷을 확보하세요. 블록 186,223,485 이전의 스냅샷은 패치된 바이너리로 재생할 수 있습니다. 검증자 서명 상태를 보존하고 스냅샷 복구 절차를 따르세요.

4. 패치 설치

필요한 롤백이 완료되면 다음을 수행하세요:

바이너리 배포: 서비스에서 사용하는 injectived 실행 파일을 확인된 아카이브의 실행 파일로 교체하세요. 번들로 제공되는 libwasmvm 라이브러리를 배포에서 사용하는 라이브러리 위치에 설치하고, 서비스의 소유권과 권한을 유지하세요.
Cosmovisor: $DAEMON_HOME/cosmovisor/current/bin의 injectived를 교체하고, 번들 라이브러리를 서비스가 로드하는 위치에 배치하세요. 이 패치에는 업그레이드 핸들러가 없으므로, 새 upgrades 디렉터리에 배치해도 자동으로 활성화되지 않습니다.
컨테이너: 데이터 볼륨, 구성, 사용자, 시작 플래그를 유지한 채 기존 배포를 injectivelabs/injective-core:v1.20.4-bl.2로 업데이트하세요.

Docker Compose의 경우, 노드 서비스의 image 값(또는 이를 제공하는 환경 변수)만 injectivelabs/injective-core:v1.20.4-bl.2로 변경하세요. 노드가 중지된 상태에서 구성된 이미지를 풀하고 확인하세요:

docker compose pull "$node_service"
docker compose run --rm --no-deps --entrypoint injectived "$node_service" version

시작하기 전에, 서비스에서 사용할 정확한 실행 파일 또는 이미지에 대해 version을 실행하여 다음을 확인하세요:

Version v1.20.4-bl.2 (1ffa252)

선택 사항: 로컬 멤풀 차단 목록

합의 차단 목록은 패치된 바이너리에 내장되어 있으며 별도의 구성이 필요하지 않습니다. 다음 app.toml 항목은 로컬 트랜잭션 수락 필터링을 추가하는 선택 사항이며, 바이너리 업그레이드를 대체하지 않습니다. 이 기능을 활성화하려면 ~/.injectived/config/app.toml의 최상위 수준, 즉 [api]와 같은 TOML 섹션 헤더보다 앞에 다음 항목을 추가하세요:

mempool-blocked-signers = ["inj134wrp6mctpq4czhw6rghekt3js3ac7c4s8ya3d"]

키가 이미 존재하는 경우, 키를 중복하거나 다른 구성된 주소를 제거하지 않고 업데이트하세요. 유효하지 않은 주소가 있으면 노드가 시작되지 않습니다.

5. 재시작 및 확인

검증자는 재시작하기 전에 노드 중지 후 생성한 서명 상태 백업을 복원하고 확인해야 합니다. 기존 서비스 관리자 또는 컨테이너 배포를 통해 노드를 시작하세요. Docker Compose의 경우, 새 이미지로 서비스를 다시 생성한 다음 실행 중인 컨테이너 내부의 바이너리를 확인하고 로그를 검사하세요:

docker compose up -d --no-deps "$node_service"
docker compose exec "$node_service" injectived version
docker compose logs --tail 100 "$node_service"

이미지 변경 사항을 적용하려면 up을 사용하세요. 이전 컨테이너를 재시작하는 것만으로는 이미지가 교체되지 않습니다. 일반 Docker 또는 다른 오케스트레이터의 경우, 기존 마운트, 포트, 환경, 사용자, 시작 인수를 사용하여 패치된 이미지로 중지된 노드 컨테이너를 다시 생성하세요. 노드의 데이터와 검증자 키를 사용하는 인스턴스는 하나만 유지하세요. 로그에서 정상적으로 시작되었는지 확인하고 AppHash 불일치가 더 이상 나타나지 않는지 확인하세요. 노드의 로컬 RPC 엔드포인트를 쿼리하세요(필요한 경우 주소를 조정하세요):

curl -fsS http://localhost:26657/status \
  | jq '.result | {network: .node_info.network, latest_block_height: .sync_info.latest_block_height, catching_up: .sync_info.catching_up}'

다음을 확인하세요:

네트워크가 injective-1입니다.
연속적으로 확인할 때마다 블록 높이가 증가하고 네트워크를 따라잡습니다.
동기화가 완료되면 catching_up이 false가 됩니다.
검증자는 서명을 재개하고, 거래소/RPC 운영자는 다운스트림 서비스가 최신 블록을 수신하는지 확인합니다.

검증에 참여하지 않는 센트리 및 RPC 노드를 포함하여 운영 중인 모든 노드에 대해 업그레이드를 반복하세요.

지원

복구에 실패한 경우, 노드를 중지된 상태로 유지하고 바이너리 버전, 마지막으로 처리된 블록 높이, 데이터베이스 백엔드, 관련 오류 로그를 기존 Injective 조율 담당자 또는 Discord의 팀에 공유하세요. 개인 키나 서명자 자격 증명은 공유하지 마세요.

​요약

​1. 릴리스 선택 및 확인

​옵션 A: 바이너리 아카이브

​옵션 B: Docker 이미지

​2. 노드 중지 및 상태 백업

​3. 영향받은 노드 복구 (필요한 경우)

​4. 패치 설치

​선택 사항: 로컬 멤풀 차단 목록

​5. 재시작 및 확인

​지원

요약