ERC-7930 상호운용 주소: 체인까지 함께 담는 주소 표준

똑같은 0x 주소가 이더리움, 베이스, 옵티미즘을 비롯한 여러 EVM 네트워크에서 모두 유효해 보일 수 있어요. 주소 문자는 계정을 알려 주지만 어느 체인으로 보내야 하는지는 알려 주지 않습니다. **ERC-7930 상호운용 주소(Interoperable Address)**는 이 두 정보를 하나로 묶어 소프트웨어가 함께 전달하게 해요. 블록체인 인프라에 필요한 실용적인 표준이지만, 주소 주인의 신원을 확인하거나 송금을 되돌려 주는 장치는 아닙니다.

이 글에서는 바이너리 형식, 사람이 읽는 ERC-7828 형식, 개발 활용처와 남는 위험을 살펴볼게요. 검토 중인 기술 표준을 설명하며 투자 전략을 제시하지 않습니다.

Important

2026년 9월 30일 현재 공식 페이지에서 ERC-7930과 ERC-7828은 모두 검토(Review) 상태예요. 동료 검토 중이므로 내용이 바뀔 수 있습니다. 통합하거나 자산을 전송하기 전에 최신 명세와 지갑 지원 여부를 확인하세요.

ERC-7930은 어떤 문제를 풀까요?

일반적인 이더리움 주소는 20바이트 계정을 식별합니다. 이더리움 메인넷인지, L2인지, 테스트넷인지, 다른 EVM 호환 체인인지는 담지 않아요. 지갑·브릿지·인텐트 시스템이 여러 네트워크를 다룰수록 이 모호함의 영향이 커집니다.

국가명이 빠진 도로명 주소를 떠올려 보세요. 동네 안에서는 모두 같은 지역을 전제로 하니 배달될 수 있습니다. 국경을 넘으면 같은 글자만으로 목적지가 완성되지 않아요. ERC-7930은 목적지 계정과 네트워크를 하나의 기계 판독 봉투에 넣습니다.

ERC-7930 공식 명세가 제시하는 핵심 목적은 다음과 같아요.

체인 식별자와 원시 주소를 하나로 묶기
스마트 컨트랙트·메시지·인텐트 페이로드에 쓰기 좋은 압축 형식 제공
네임스페이스별 프로필을 통해 비 EVM 체인까지 지원
명시적인 버전 필드로 미래 형식 확장

화면 표시에만 필요한 기능은 아닙니다. 이더리움 재단의 2026년 프로토콜 우선순위는 상호운용성(Interoperability)을 사용자 경험의 핵심 과제로 제시하고, 진전된 표준으로 ERC-7930과 ERC-7828을 언급해요. 공통 주소 객체가 있으면 지갑과 크로스체인 시스템이 저마다 다른 체인 + 주소 규칙을 만들 필요가 줄어듭니다.

바이너리 봉투는 어떻게 구성될까요?

버전 1은 길이 정보가 붙은 여섯 필드의 바이트 열입니다.

필드	역할
`Version`	봉투 버전을 나타내는 2바이트, 버전 1은 `0x0001`
`ChainType`	등록된 체인 네임스페이스를 고르는 2바이트
`ChainReferenceLength`	체인 참조의 길이를 나타내는 1바이트
`ChainReference`	특정 체인의 직렬화된 식별자
`AddressLength`	주소 길이를 나타내는 1바이트
`Address`	해당 네임스페이스 규칙으로 인코딩한 계정 바이트

길이 접두부(Length Prefix)는 운송 상자 안의 칸마다 크기를 표시하는 것과 비슷해요. 파서는 각 가변 길이 값이 어디서 끝나는지 알 수 있습니다. 모든 블록체인 주소가 EVM처럼 20바이트라고 가정할 필요가 없어요.

EVM의 eip155 네임스페이스에서 CAIP-350 프로필은 체인 타입으로 0x0000을 사용합니다. 체인 ID는 필요한 최소 길이의 빅엔디언(Big-Endian) 정수로, 주소는 원래 바이트로 직렬화해요. 그래서 이더리움 메인넷의 체인 참조는 0x01, 옵티미즘은 0x0a입니다.

공식 ERC의 이더리움 메인넷 예시는 다음처럼 나눠 볼 수 있어요.

0x0001 0000 01 01 14 d8da6bf26964af9d7eed9e03e53415d37aa96045
   │     │   │  │  │                    │
 버전   타입 길이 체인 길이               주소

공백과 설명은 이해를 위해 넣은 것이고 실제 페이로드는 이어진 바이트입니다. Address 길이가 0이면 계정 없이 체인 자체만 나타낼 수 있어요. 체인 참조 길이가 0이면 체인을 지정하지 않은 주소가 되지만, 앱이 이를 임의의 특정 네트워크로 해석해서는 안 됩니다.

ERC-7930과 ERC-7828: 기계용과 사람용의 차이

바이너리는 컨트랙트와 프로토콜에 효율적이지만 사람이 읽기 어렵습니다. ERC-7828 상호운용 이름(Interoperable Name)은 다음 사용자용 형식을 제안해요.

<주소>@<체인>#<체크섬>

공식 예시에는 원시 주소와 @eip155:1 조합, alice.eth@ethereum 같은 ENS 이름, 비 EVM 체인 참조가 들어 있습니다. 주소 자리에는 체인의 원래 주소나 ENS 이름을 쓸 수 있어요. 체인 자리는 CAIP-350 표현이나 on.eth ENS 네임스페이스에서 조회하는 사람이 읽기 쉬운 라벨을 사용할 수 있습니다.

선택 사항인 8자리 체크섬(Checksum)은 버전 필드를 제외한 표준 바이너리 구성요소에서 계산해요. ERC-7828은 원시 주소에 체크섬을 권장하지만 ENS 이름에는 붙이지 않도록 안내합니다. 이 체크섬은 체인과 주소 조합의 무결성을 검사할 뿐 수신자의 신원을 인증하지 않아요.

역할을 나누면 간단합니다.

ERC-7930: 소프트웨어가 쓰는 압축된 표준 봉투
ERC-7828: 화면 표시와 공유에 쓰는 읽기 쉬운 이름
CAIP-350 프로필: 각 체인 계열의 체인 참조와 주소 직렬화 규칙

이는 EIP-55 체크섬 주소와 달라요. EIP-55는 하나의 EVM 주소에 대소문자 오타 감지 신호를 넣지만 네트워크는 인코딩하지 않습니다. ERC-7930은 네트워크 맥락을 명시적으로 담습니다.

상호운용 주소는 어디에 쓰일까요?

크로스체인 인텐트와 메시징

도착 가능한 체인이 여러 개인데 주문에 “이 주소로 보내라”만 적혀 있으면 정보가 부족해요. 체인 인식 수신자는 크로스체인 인텐트와 메시지 형식에 일관된 목적지 객체를 제공합니다. 현재 ERC-7683 명세도 체인별 주소 표현에 ERC-7930을 사용해요.

지갑의 보내기·받기 흐름

지원 지갑은 하나의 값을 해석해 목적 네트워크를 선택하거나 검증하고, 최종 확인 화면에 계정과 체인을 함께 보여 줄 수 있습니다. 지갑이 체인 맥락을 버리지 않고 끝까지 보존해야만 잘못된 네트워크 전송을 줄이는 데 도움이 돼요.

컨트랙트·레지스트리·API

프로토콜은 프로젝트마다 다른 두 필드 대신 하나의 바이트 필드를 받을 수 있습니다. 현재 OpenZeppelin Contracts 유틸리티 문서는 버전 1 상호운용 주소를 만들고 해석하는 함수를 제공해요. 재사용 라이브러리를 활용하면 직접 인코딩할 때 생기는 차이를 줄일 수 있습니다.

비 EVM 상호운용성

이 봉투는 모든 계정을 20바이트라고 가정하지 않아요. 다른 체인 계열도 네임스페이스 프로필로 직렬화 규칙을 정의할 수 있습니다. EVM 체인 ID 목록보다 범용적이지만, 각 프로필을 정확히 검증해야 한다는 책임도 생겨요.

보안 위험과 한계

검토 상태와 구현 차이

발행일 기준 두 제안 모두 최종 표준이 아닙니다. SDK·데모·예전 해설이 서로 다른 개정본을 구현할 수 있어요. 지원하는 명세 버전을 고정하고 공식 테스트 벡터로 검증하며, 인코딩 값을 장기 식별자로 쓰기 전에 마이그레이션 계획을 세워야 합니다.

체인 맥락은 수신자 신원이 아니에요

상호운용 주소는 “이 체인의 이 계정”을 모호하지 않게 표현할 수 있습니다. 그 계정이 의도한 사람의 것인지, 컨트랙트가 안전한지, 악성코드가 전체 값을 다른 유효한 값으로 바꿨는지는 알려 주지 못해요.

정규화 규칙은 네임스페이스마다 달라요

ERC-7930은 표준 주소 표현도 현실에서는 불완전한 추상화가 될 수 있다고 경고합니다. 어떤 네임스페이스는 여러 유효 표현을 허용하거나 식별자 충돌 가능성이 있을 수 있어요. 바이트를 데이터베이스 키나 컨트랙트 매핑 키로 쓰는 개발자는 보편적인 유일성을 가정하지 말고 각 CAIP-350 프로필을 검토해야 합니다.

리졸버와 라벨 신뢰

사람이 읽는 ERC-7828 체인 라벨은 ENS 조회에 의존합니다. 앱은 라벨을 조회하지 못하거나, 결과가 충돌하거나, 예상과 다르게 바뀌었을 때 명확히 중단해야 해요. 친숙한 이름만 보여 주지 말고 인가 직전에 조회된 표준 체인도 표시해야 합니다.

호환성 공백

지갑이나 앱이 표준을 지원하지 않으면 값을 거부하거나 체인 정보를 잘못 다룰 수 있어요. 일반 계정 주소만 받는 입력창에 ERC-7930 바이트 문자열을 붙여 넣지 마세요. 명시적인 지원 여부를 먼저 확인해야 합니다.

체크섬의 역할은 좁아요

ERC-7828 체크섬은 체인과 주소 조합의 손상이나 불일치를 찾는 데 도움을 줍니다. 유효한 체크섬도 프론트엔드, 리졸버, 계정 소유자, 토큰, 컨트랙트, 거래 결과를 보증하지 않아요.

실전 통합 체크리스트

개발자라면 다음을 확인하세요.

현재 ERC 상태를 확인하고 지원할 개정본을 문서화합니다.
선언된 길이로 파싱하고, 잘린 데이터·남는 데이터·잘못된 형식을 거부해요.
ChainType에 맞는 CAIP-350 프로필을 지원하는지 검사합니다.
동일성 비교나 키 사용 전 체인 고유 규칙으로 정규화하세요.
API·저장소·서명·표시 전 과정에서 체인 맥락을 보존합니다.
인가 직전에 조회된 체인과 전체 수신 주소를 보여 주세요.
체크섬·네임스페이스 프로필·체인 라벨을 검증할 수 없으면 중단합니다.
EVM과 비 EVM 벡터, 길이 0인 경우, 미지원 버전, 악성 입력을 테스트해요.

사용자라면 다음을 확인해 보세요.

지갑이 해당 형식을 명시적으로 지원하는지 확인합니다.
전체 수신 주소, 체인, 자산, 금액, 행동을 각각 점검해요.
읽기 쉬운 라벨은 편의 기능으로 보고 실제 조회된 네트워크를 확인합니다.
독립적으로 신뢰할 수 있는 출처에서 목적지를 얻으세요.
실수의 영향이 큰 송금이라면 잃어도 감당할 수 있는 소액 테스트를 고려합니다.

자주 묻는 질문(FAQ)

ERC-7930은 새로운 지갑 주소인가요?

아니요. 기존 목적지 주소와 체인 정보를 하나로 묶는 봉투입니다. 기초 계정은 바뀌지 않아요.

잘못된 체인으로 보내는 일을 막아 주나요?

지원 소프트웨어가 실수를 감지하거나 피하는 데 필요한 맥락을 제공합니다. 보호 효과는 채택과 올바른 구현에 달려 있어요. 미지원 소프트웨어가 체인 필드를 보존한다고 가정하면 안 됩니다.

이더리움과 EVM 체인에서만 쓸 수 있나요?

아니요. 네임스페이스와 길이 접두부 구조로 다른 체인 계열도 CAIP-350 프로필을 통해 지원할 수 있습니다. 각 네임스페이스 규칙을 정확히 구현하고 검토해야 해요.

사람이 원시 바이너리 문자열을 공유해도 되나요?

가능하지만 명세는 주로 기계 판독 맥락을 목표로 합니다. ERC-7828이 주소와 체인을 함께 보여 주는 사람용 형식을 제공해요.

ERC-7930과 ERC-7828은 최종 표준인가요?

아니요. 2026년 9월 30일 현재 두 공식 제안 페이지 모두 검토(Review) 상태입니다. 최종(Final)이 되기 전까지 예시와 API가 바뀔 수 있다고 봐야 해요.

기억하기 쉬운 핵심

ERC-7930은 라벨이 붙은 운송 상자와 같아요. 계정 바이트와 이를 해석할 체인을 함께 담습니다. ERC-7828은 그 상자 바깥에 붙이는 사람이 읽기 쉬운 배송 라벨이에요. 둘은 제각각인 멀티체인 주소 관행을 공통 기계 계층과 화면 계층으로 바꾸려 합니다.

중요한 인프라이지만 안전 배송 보증서는 아닙니다. 앱은 엄격한 파싱, 최신 네임스페이스 프로필, 투명한 조회, 최종 주소·체인 확인을 구현해야 해요. 사용자도 독립된 출처로 목적지를 다시 확인해야 합니다.

이 글은 교육 목적이며 투자 조언이 아닙니다. 크립토 송금은 되돌리기 어려울 수 있고 디지털 자산은 큰 폭으로 변동하거나 전액 손실될 수 있어요. 최신 1차 문서를 확인하고, 잃어도 되는 금액만 사용하며 스스로 조사하세요(DYOR). NFA.