체인 ID는 지갑과 서명이 어느 network를 대상으로 하는지 구분하는 핵심 값이다. 변경 공지에는 old·new chain ID, genesis hash, 전환 height·time, RPC·explorer, native asset와 address continuity를 명시해야 한다. 기존 signed transaction이 새 network에서 유효한지, EIP-155 domain에 새 ID가 포함되는지 확인하고 pending 거래를 무작정 재전송하지 않는다.
이름보다 서명에 들어가는 식별자를 본다
EVM 주소는 같은 private key에서 여러 network에 동일하게 나타날 수 있다. UI의 network 이름이나 ticker만 바뀌어도 address가 같아 보이므로 잘못된 chain에 전송하기 쉽다. JSON-RPC의 eth_chainId, genesis block hash, native currency와 explorer를 함께 확인한다.
EIP-155는 transaction 서명에 chain ID를 포함해 한 network의 signed transaction이 다른 network에서 replay되는 위험을 줄인다. Geth 1.10 설명은 DAO fork 뒤 chain ID가 도입돼 Ethereum과 Ethereum Classic·testnet의 서명을 구분했다고 설명한다. 보호는 wallet과 transaction type이 올바른 ID를 실제로 서명할 때 작동한다.
같은 주소가 보인다는 사실은 같은 원장과 같은 서명 영역이라는 뜻이 아니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 이름보다 서명에 들어가는 식별자를 본다
EVM 주소는 같은 private key에서 여러 network에 동일하게 나타날 수 있다.
- chain ID 변경 방식부터 구분한다
기존 chain이 특정 height 이후 새 ID를 쓰는지, state export 후 새 genesis로 재시작하는지, old chain과 병존하는 fork 인지에 따라 자산·nonce·history가 달라진다.
- 지갑 설정은 RPC URL보다 더 확인한다
사용자가 custom network를 추가할 때 wallet이 RPC 응답 chain ID와 입력값 불일치를 경고하는지 확인한다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
chain ID 변경 방식부터 구분한다
기존 chain이 특정 height 이후 새 ID를 쓰는지, state export 후 새 genesis로 재시작하는지, old chain과 병존하는 fork인지에 따라 자산·nonce·history가 달라진다. Cosmos의 state export/import 문서는 zero-height export와 migrate 과정에서 새 chain ID와 genesis time을 지정할 수 있음을 보여 준다.
IBC 설계 문서는 chain ID 변경을 revision과 height로 표현하는 upgrade 문제를 다룬다. relayer·light client에는 단순 문자열 교체가 아니라 새 trusted consensus state와 upgrade proof가 필요할 수 있다. 공지는 validator뿐 아니라 wallet, exchange, bridge, relayer의 전환 상태를 따로 보여야 한다.
| 항목 | 이전 값 | 새 값·증거 |
|---|---|---|
| Chain ID | wallet·RPC 응답 | eth_chainId·config |
| Genesis | block 0 hash | 새 genesis file·hash |
| Activation | 마지막 old height | 첫 new height·time |
| State | balance·nonce | migration 결과 |
| 연결 서비스 | RPC·bridge·IBC | 지원 완료 상태 |
지갑 설정은 RPC URL보다 더 확인한다
사용자가 custom network를 추가할 때 wallet이 RPC 응답 chain ID와 입력값 불일치를 경고하는지 확인한다. 새 RPC URL이 old ID를 반환하거나 load balancer 뒤 node가 섞이면 transaction이 거절되거나 엉뚱한 network view가 나타날 수 있다. 두 독립 endpoint에서 chain ID와 genesis hash를 비교한다.
network 이름·symbol·explorer URL은 표시 정보라 공격자가 흉내 낼 수 있다. 공식 repository와 governance·release 공지에서 새 값과 activation을 확인한다. 기존 custom network를 조용히 수정하기보다 old entry를 명확히 비활성화하고 새 entry를 추가해 혼동을 줄인다.
기존 서명과 pending 거래를 분류한다
old chain ID가 포함된 EIP-155 transaction은 정상 구현이라면 다른 ID에서 유효하지 않아야 한다. 하지만 legacy unprotected transaction, application message, permit·typed data, cross-chain order는 별도 domain 규칙을 쓸 수 있다. 서명 payload의 chainId, verifyingContract, nonce, deadline을 확인한다.
전환 직전 pending transaction이 old chain에 포함됐는지 먼저 확인한다. 새 chain에서 같은 의도를 실행하려면 migrated nonce와 balance, target contract address·code가 같은지 검증하고 새 ID로 다시 서명한다. raw transaction을 그대로 양쪽 RPC에 보내는 방식으로 시험하지 않는다.
- old·new chain ID와 genesis hash를 기록한다
- 전환 height·state export 기준을 확인한다
- 지갑·RPC·explorer 값을 독립 채널에서 대조한다
- pending hash와 nonce를 양쪽 상태에서 확인한다
- permit·message의 domain과 verifying contract를 점검한다
계약 주소가 같아도 코드와 권한은 다를 수 있다
state를 그대로 이전하면 contract address와 storage가 유지될 수 있지만 새 genesis 구성이나 선택적 migration에서는 달라질 수 있다. address가 같다는 이유로 token과 bridge contract를 신뢰하지 않는다. runtime bytecode hash, proxy implementation, admin·owner와 주요 balance를 비교한다.
old·new chain이 병존하면 같은 symbol의 native asset과 token이 서로 다른 경제권에 존재한다. exchange deposit network와 bridge canonical route가 새 chain을 지원하는지 확인한다. unsupported network로 보낸 자산의 복구 가능성을 chain ID 변경 공지만으로 약속해서는 안 된다.
서비스별 준비 상태를 행렬로 공개한다
validator가 새 chain을 생성했다고 wallet·RPC·explorer·oracle·bridge·exchange가 모두 준비된 것은 아니다. 각 서비스의 지원 version, 전환 height, read·write 상태를 표로 갱신한다. 읽기만 가능한 RPC를 거래 제출 가능으로 표시하지 않는다.
개발자는 configuration에서 숫자를 hard-code한 곳, signature domain cache, database key, monitoring label을 검색한다. test environment에서 wrong-chain 요청이 명확히 실패하는지와 old signed payload가 거절되는지 확인한다. chain ID collision이 없는지도 공개 registry와 운영 범위에서 확인한다.
완료 뒤 old network의 상태도 설명한다
전환 완료 공지는 새 genesis hash, 첫 finalized block, validator participation과 대표 state query를 제시한다. old chain이 halt했는지 계속 운영되는지, RPC가 read-only로 남는지, explorer history 보존 기한을 알린다. ‘migration complete’만으로 old endpoint 처리 방식을 알 수 없다.
이용자는 지갑 network 표시를 확인하고 작은 test transaction 전에 destination service의 새 chain 지원을 확인한다. 애플리케이션은 chainChanged event만 믿지 말고 중요 action 직전에 eth_chainId와 contract code를 다시 검사한다. 서명 팝업에 표시된 network가 예상과 다르면 취소한다.
자주 묻는 질문
chain ID가 바뀌어도 주소는 같은가요?
같은 key의 EVM address는 같을 수 있지만 balance·nonce·contract와 경제적 자산은 network별로 다르다.
기존 signed transaction을 새 RPC에 보내도 되나요?
재사용하지 않는다. 포함 여부와 nonce를 확인하고 새 chain ID·contract 상태에 맞춰 새로 서명한다.
RPC URL만 바꾸면 migration이 끝나나요?
아니다. chain ID·genesis, wallet·explorer·bridge·exchange·signature domain을 함께 확인한다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
