ERC-7930 상호운용 주소 (Interoperable Addresses)
Review · 이름·메타데이터 · 2025-02-02 작성
주소와 그 주소가 속한 체인 정보를 하나의 바이너리 값으로 묶어 표현하는 형식을 정의합니다. 이더리움뿐 아니라 솔라나 같은 다른 체인의 주소도 같은 틀에 담을 수 있습니다.
왜 필요한가
이더리움 메인넷에서 쓰는 주소 형식(ERC-55)은 다른 많은 블록체인도 똑같이 씁니다. 그런데 이 형식에는 그 주소를 어느 체인에서 쓰려는 것인지에 대한 정보가 전혀 없어서 같은 주소가 여러 체인에 존재할 수 있고 그만큼 모호함과 운영상 위험이 생깁니다. 그 결과 각 프로토콜은 주소와 체인을 묶어 표현하는 방법을 저마다 임시방편으로 만들어 왔습니다. 보통은 별도 필드를 두거나 프로토콜마다 다른 관례를 쓰는 식입니다. 이런 파편화는 프로토콜 간 상호운용을 어렵게 하고 도구를 복잡하게 만들며 인프라 수준에서 표기 불일치를 낳습니다. 기존의 텍스트 기반 표준(CAIP-10)도 있지만 문자열은 체인 위 컨트랙트에서 저장하고 다루기에 비효율적이고 체인 참조 길이가 32자로 제한되어 일부 체인을 손실 없이 표현하지 못합니다. 이 제안은 체인 식별 정보와 주소를 하나로 묶은, 확장 가능한 바이너리 표준 형식으로 이 문제를 풉니다.
심층 설명
바이너리 구조: 6개 필드
상호운용 주소는 Version, ChainType, ChainReferenceLength, ChainReference, AddressLength, Address의 순서로 이어지는 바이너리 값입니다. Version은 2바이트이고 이 명세(버전 1)에서는 빅엔디언으로 0x0001이어야 합니다. ChainType은 CASA 네임스페이스에 대응하는 2바이트 값으로, 뒤에 오는 ChainReference와 Address를 어떻게 해석하고 표시할지 결정합니다. ChainReferenceLength는 ChainReference의 바이트 길이를 담는 1바이트 정수이고 ChainReference는 체인을 가리키는 가변 길이 바이너리 값입니다. AddressLength는 Address의 바이트 길이를 담는 1바이트 정수이고 Address는 직렬화된 주소의 가변 길이 바이너리 인코딩입니다. 길이를 앞에 붙이는 구조라 임의 길이의 데이터를 담을 수 있습니다.
직렬화 규칙은 CAIP-350이 정의
이 표준 자체는 봉투(envelope) 구조만 정하고 봉투 안 데이터의 해석과 직렬화 규칙은 동반 표준인 CAIP-350이 정합니다. CAIP-350은 체인 유형별 프로필을 제공하며 특정 네임스페이스 안에서 ChainReference의 직렬화는 그 네임스페이스의 CAIP-350 프로필에 정의된 알고리즘을 따라야 합니다. Address의 직렬화도 해당 ChainType의 CAIP-350 프로필 규칙을 따라야 합니다. 체인 프로필은 체인 중립 표준 연합(Chain-Agnostic Standards Alliance, CASA)이 관리합니다. 이렇게 네임스페이스별 규칙을 밖으로 분리했기 때문에 새 체인 유형을 지원하려면 프로필만 추가하면 되고 형식 자체는 바꿀 필요가 없습니다.
길이가 0인 필드와 체인 식별자
ChainReferenceLength는 0일 수 있으며 이 경우 상호운용 주소에 체인 참조를 포함해서는 안 됩니다. 예를 들어 특정 체인을 지정하지 않은 EVM 주소를 표현할 수 있습니다. AddressLength도 0일 수 있는데, 이때 그 값은 주소가 아니라 체인 자체를 가리키는 체인 식별자(Chain Identifier)가 되며 주소를 포함해서는 안 됩니다. 단 ChainReferenceLength가 0이면 AddressLength는 0이어서는 안 됩니다. 두 필드의 길이 0을 허용한 이유는 하나의 통일된 표준으로 여러 용도를 처리하게 하기 위해서입니다. 호환되는 아무 체인에서나 쓸 주소를 표현하거나, 체인 그 자체만 표현하는 일이 모두 가능합니다.
예시로 보는 인코딩
이더리움 메인넷 주소 0xd8dA6bF26964aF9D7eEd9e03E53415D37aA96045를 담으면 0x00010000010114d8da6bf26964af9d7eed9e03e53415d37aa96045가 됩니다. Version 0x0001, ChainType 0x0000, ChainReferenceLength 1, ChainReference 1, AddressLength 20(0x14), 그 뒤에 20바이트 주소가 이어집니다. 솔라나 메인넷은 ChainType 0x0002에 32바이트 ChainReference와 32바이트 Address를 씁니다. 체인 참조를 생략한 EVM 주소는 0x000100000014로 시작하고 솔라나 메인넷 체인 식별자는 AddressLength가 0으로 끝납니다. 화면에 직접 표시해야 한다면 소문자 16진수 문자열로 표시하는 것이 권장됩니다.
버전 규칙과 하위 호환
Version 필드는 2바이트이고 미래 버전은 별도 ERC로 표준화하는 것이 권장됩니다. 미래 버전은 이 명세의 상호운용 주소 형식으로 쉽게 변환할 수 있어야 하고 이 명세의 파싱 규칙과 하위 호환되지 않는 형식이라면 버전 필드의 최상위 비트를 1로 설정해야 합니다. 또한 주소, 체인, 또는 둘 다를 정의할 수 있어야 하며 필드를 추가할 수는 있지만 버전 1 상호운용 주소를 비트 단위로 정확히 재구성하는 데 필요한 데이터를 바꾸거나 빼서는 안 됩니다. CAIP 네임스페이스의 일부만 표현하는 버전도 허용됩니다.
기존 표준과의 비교
CAIP-10은 특정 체인 위 주소를 나타내는 텍스트 형식 표준이지만 대상 주소의 직렬화와 정규화 규칙을 정하지 않고 각 체인의 고유 주소 형식을 안다고 가정합니다. 또 문자열은 체인 위에 데이터를 저장하기에 비효율적이라 컨트랙트 안에서 쓰기에 알맞지 않습니다. CAIP-10이 의존하는 CAIP-2는 체인 참조를 32자로 제한하는데, 예를 들어 솔라나는 base58btc로 인코딩한 제네시스 블록해시의 앞 32자를 쓰기 때문에 체인을 유일하게 결정하는 표현이 아닙니다. 이 표준은 바이너리 형식으로 이런 한계를 피하고 사람이 읽는 표현이 필요한 경우를 위해서는 ERC-7828 같은 별도 표준을 둡니다. 기존 표준들은 쉽게 확장할 수 없어서 이런 기능을 덧붙일 수 없었고 그래서 확장 가능한 새 형식을 만들었습니다.
아직 검토 단계인 제안
이 제안의 상태는 Review입니다. 아직 확정되지 않은 단계이므로 내용이 바뀔 수 있습니다.
쓸 때 주의할 점
- 주소의 정규성이 늘 보장되지는 않습니다: 이 표준은 여러 체인의 주소를 표준적으로 가리키는 기반을 목표로 하지만 현실에서는 그 보장이 샐 수 있습니다. 어떤 체인 네임스페이스는 주소의 정규성을 보장할 수 없는 직렬화 방식을 정의할 수 있고 한 네트워크에 유효한 CAIP-2 식별자가 두 개 존재할 수도 있습니다.
- 매핑 키로 쓰기 전에 프로필을 검토해야 합니다: 주소를 컨트랙트 매핑이나 키-값 저장소의 키처럼 정규성이 필요한 용도로 쓰는 구현자는, 해당 체인 네임스페이스의 CAIP-350 프로필을 꼼꼼히 검토해 정규성이 깨질 가능성(프로필의 Extra Considerations 절에 적혀 있어야 합니다)과 이미 지원 중인 다른 네임스페이스와의 충돌 가능성을 확인하는 것이 권장됩니다.