체인 ID는 지갑과 서명이 어느 네트워크를 겨냥하는지 가려 주는 핵심 값입니다. 변경 공지에는 이전·새 체인 ID, 제네시스 해시, 전환 블록 높이와 시각, RPC·탐색기, 기본 자산, 주소 연속성이 분명히 적혀 있어야 합니다. 이미 서명한 거래가 새 네트워크에서도 유효한지, EIP-155 서명 영역에 새 ID가 들어가는지 확인하고, 대기 중인 거래를 무작정 다시 보내지 않습니다.
이름보다 서명에 들어가는 식별자를 봅니다
EVM 주소는 같은 개인키에서 여러 네트워크에 똑같이 나타날 수 있습니다. 화면의 네트워크 이름이나 티커만 바뀌어도 주소는 같아 보이니 엉뚱한 체인으로 보내기 쉽습니다. JSON-RPC의 eth_chainId, 제네시스 블록 해시, 기본 통화, 탐색기를 함께 확인합니다.
EIP-155는 거래 서명에 체인 ID를 넣어, 한 네트워크에서 서명한 거래가 다른 네트워크에서 재사용(replay)되는 위험을 줄입니다. Geth 1.10 설명에 따르면 DAO 포크 뒤 체인 ID가 도입되면서 Ethereum과 Ethereum Classic, 테스트넷의 서명이 구분됐습니다. 이 보호는 지갑과 거래 유형이 올바른 ID를 실제로 서명에 넣을 때만 작동합니다.
같은 주소가 보인다고 같은 원장, 같은 서명 영역이라는 뜻은 아니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 이름보다 서명에 들어가는 식별자를 봅니다
EVM 주소는 같은 개인키에서 여러 네트워크에 똑같이 나타날 수 있습니다.
- 체인 ID를 바꾸는 방식부터 구분합니다
기존 체인이 특정 높이부터 새 ID를 쓰는지, 상태를 내보낸 뒤 새 제네시스로 다시 시작하는지, 이전 체인과 나란히 존재하는 포크인지에 따라 자산·논스·기록이 달라집니다.
- 지갑 설정은 RPC 주소보다 더 꼼꼼히 확인합니다
사용자가 직접 네트워크를 추가할 때, RPC가 돌려준 체인 ID와 입력값이 다르면 지갑이 경고하는지 확인합니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
체인 ID를 바꾸는 방식부터 구분합니다
기존 체인이 특정 높이부터 새 ID를 쓰는지, 상태를 내보낸 뒤 새 제네시스로 다시 시작하는지, 이전 체인과 나란히 존재하는 포크인지에 따라 자산·논스·기록이 달라집니다. Cosmos의 상태 내보내기·가져오기 문서를 보면, 제로 높이(zero-height) 내보내기와 이전 과정에서 새 체인 ID와 제네시스 시각을 지정할 수 있습니다.
IBC 설계 문서는 체인 ID 변경을 리비전(revision)과 높이로 표현하는 업그레이드 문제로 다룹니다. 릴레이어와 라이트 클라이언트에는 문자열 하나를 바꾸는 것으로 끝나지 않고, 새로 신뢰할 합의 상태와 업그레이드 증명이 필요할 수 있습니다. 공지는 검증자뿐 아니라 지갑, 거래소, 브리지, 릴레이어의 전환 상태를 각각 보여 줘야 합니다.
| 항목 | 이전 값 | 새 값·증거 |
|---|---|---|
| 체인 ID | 지갑·RPC 응답 | eth_chainId·설정 파일 |
| 제네시스 | 블록 0 해시 | 새 제네시스 파일·해시 |
| 활성화 | 마지막 이전 체인 높이 | 새 체인 첫 높이·시각 |
| 상태 | 잔액·논스 | 이전 작업 결과 |
| 연결 서비스 | RPC·브리지·IBC | 지원 완료 상태 |
지갑 설정은 RPC 주소보다 더 꼼꼼히 확인합니다
사용자가 직접 네트워크를 추가할 때, RPC가 돌려준 체인 ID와 입력값이 다르면 지갑이 경고하는지 확인합니다. 새 RPC 주소가 이전 ID를 돌려주거나 부하 분산기 뒤에서 노드가 섞이면, 거래가 거절되거나 엉뚱한 네트워크 상태가 보일 수 있습니다. 서로 독립된 두 접속 지점에서 체인 ID와 제네시스 해시를 비교합니다.
네트워크 이름, 심볼, 탐색기 주소는 화면에 보이는 정보일 뿐이라 공격자가 흉내 낼 수 있습니다. 새 값과 활성화 시점은 공식 저장소와 거버넌스·릴리스 공지에서 확인합니다. 기존 사용자 정의 네트워크를 슬쩍 고치기보다, 이전 항목을 분명히 비활성화하고 새 항목을 추가하는 편이 혼동이 적습니다.
기존 서명과 대기 거래를 분류합니다
이전 체인 ID가 들어간 EIP-155 거래는 정상 구현이라면 다른 ID에서 유효하지 않아야 합니다. 하지만 보호가 없는 구형 거래, 애플리케이션 메시지, permit·구조화 데이터 서명, 체인 간 주문은 저마다 다른 서명 영역 규칙을 쓸 수 있습니다. 서명 내용의 chainId, verifyingContract, 논스, 마감 시각을 확인합니다.
전환 직전에 대기하던 거래가 이전 체인에 포함됐는지부터 봅니다. 새 체인에서 같은 일을 하려면 이전된 논스와 잔액, 대상 계약 주소와 코드가 같은지 검증한 뒤 새 ID로 다시 서명합니다. 원시 거래를 양쪽 RPC에 그대로 보내 보는 식으로 시험하지 않습니다.
- 이전·새 체인 ID와 제네시스 해시를 기록합니다
- 전환 높이와 상태 내보내기 기준을 확인합니다
- 지갑·RPC·탐색기 값을 서로 다른 경로에서 맞춰 봅니다
- 대기 거래 해시와 논스를 양쪽 상태에서 확인합니다
- permit·메시지의 서명 영역과 검증 계약을 점검합니다
계약 주소가 같아도 코드와 권한은 다를 수 있습니다
상태를 그대로 옮기면 계약 주소와 저장소가 유지될 수 있습니다. 하지만 새 제네시스 구성이나 선택적 이전에서는 달라질 수 있습니다. 주소가 같다는 이유만으로 토큰과 브리지 계약을 믿지 않습니다. 실행 바이트코드 해시, 프록시 구현 계약, 관리자·소유자, 주요 잔액을 비교합니다.
이전 체인과 새 체인이 함께 돌아가면 같은 심볼의 기본 자산과 토큰이 서로 다른 경제권에 존재하게 됩니다. 거래소 입금 네트워크와 브리지 공식 경로가 새 체인을 지원하는지 확인합니다. 지원하지 않는 네트워크로 보낸 자산을 되찾을 수 있다고 체인 ID 변경 공지만으로 약속해서는 안 됩니다.
서비스별 준비 상태를 표로 공개합니다
검증자가 새 체인을 띄웠다고 지갑·RPC·탐색기·오라클·브리지·거래소가 모두 준비된 것은 아니다. 서비스마다 지원 버전, 전환 높이, 읽기·쓰기 상태를 표로 갱신합니다. 읽기만 되는 RPC를 거래 제출 가능으로 표시하지 않습니다.
개발자는 설정에 숫자를 직접 박아 넣은 곳, 서명 영역 캐시, 데이터베이스 키, 모니터링 라벨을 찾아봅니다. 테스트 환경에서 잘못된 체인 요청이 분명히 실패하는지, 이전에 서명한 데이터가 거절되는지 확인합니다. 체인 ID가 다른 체인과 겹치지 않는지도 공개 등록부와 운영 범위에서 확인합니다.
완료 뒤 이전 네트워크의 상태도 설명합니다
전환 완료 공지에는 새 제네시스 해시, 첫 확정 블록, 검증자 참여율, 대표적인 상태 조회 결과가 들어가야 합니다. 이전 체인이 멈췄는지 계속 운영되는지, RPC가 읽기 전용으로 남는지, 탐색기 기록을 언제까지 보존하는지도 알립니다. ‘마이그레이션 완료(migration complete)’라는 말만으로는 이전 접속 지점을 어떻게 처리하는지 알 수 없습니다.
이용자는 지갑의 네트워크 표시를 확인하고, 소액 시험 거래를 보내기 전에 받는 쪽 서비스가 새 체인을 지원하는지 확인합니다. 애플리케이션은 chainChanged 이벤트만 믿지 말고 중요한 동작 직전에 eth_chainId와 계약 코드를 다시 검사합니다. 서명 팝업에 뜬 네트워크가 예상과 다르면 취소합니다.
자주 묻는 질문
체인 ID가 바뀌어도 주소는 같은가요?
같은 키의 EVM 주소는 같을 수 있습니다. 그러나 잔액·논스·계약과 경제적 자산은 네트워크마다 다릅니다.
기존에 서명한 거래를 새 RPC에 보내도 되나요?
다시 쓰지 않습니다. 포함 여부와 논스를 확인하고 새 체인 ID와 계약 상태에 맞춰 새로 서명합니다.
RPC 주소만 바꾸면 이전 작업이 끝나나요?
아니다. 체인 ID·제네시스, 지갑·탐색기·브리지·거래소, 서명 영역을 함께 확인합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
