ERC-7528 네이티브 자산 ETH 주소 규약 (ETH (Native Asset) Address Convention)

Final · 토큰 · 2023-10-03 작성

ETH를 ERC-20 토큰처럼 다루는 자리에서 ETH를 가리키는 주소로 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee를 쓰기로 정한 규약입니다. ETH와 ERC-20을 이벤트 형식 하나로 기록할 수 있습니다.

왜 필요한가

ETH는 양이 같으면 서로 바꿔 쓸 수 있는 가치 단위라서 ERC-20 토큰과 비슷하게 움직입니다. 그래서 프로토콜은 ERC-20용 표준 인터페이스를 만들고 ETH 처리도 그 구현을 최대한 닮게 만들려고 합니다. 어떤 프로토콜은 ERC-20 규격을 맞추려고 래핑된 ETH(Wrapped ETH, WETH)를 쓰고 어떤 프로토콜은 가스 비용 때문에, 또는 유동성 스테이킹 토큰(Liquid Staking Token, LST)처럼 ETH 자체가 꼭 필요해서 네이티브 ETH를 씁니다. 이때 ETH 경우와 ERC-20 경우에 서로 다른 이벤트를 만들면 데이터가 갈라지고 블록체인 밖에서 데이터를 읽는 인프라는 두 형식을 따로 붙여야 합니다. ETH가 ERC-20처럼 쓰이는 자리에서 ETH를 가리키는 주소가 하나로 정해져 있으면 두 경우를 이벤트 형식 하나로 처리할 수 있습니다.

심층 설명

적용 범위

이 표준은 주소로 ERC-20 토큰을 식별하는 스마트 컨트랙트 시스템의 모든 구성 요소에 적용됩니다. 단, 그 시스템이 어떤 경우에는 ERC-20 토큰 대신 네이티브 ETH를 쓰는 상황이어야 합니다. 원문은 이 맥락에서 '토큰(Token)'이라는 말을 ETH 또는 ERC-20을 모두 가리키는 뜻으로 씁니다. 적용 대상에는 주소 필드가 ETH나 ERC-20 토큰을 나타내는 이벤트와, ERC-4626 금고의 asset 필드 같은 구분자가 모두 포함됩니다. 네이티브 자산이 ETH가 아닌 다른 EVM 체인에도 같은 규약을 일반화해 적용합니다.

ETH일 때는 반드시 0xeeee... 주소

ERC-20 주소가 들어가는 필드나 이벤트에서 실제 토큰이 ETH라면, 그 주소 필드는 반드시(MUST) 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee를 반환해야 합니다. 이 주소는 20바이트 전부가 0xee로 채워진 값입니다. 프로토콜과 블록체인 밖 데이터 인프라는 ERC-20 맥락에서 이 주소가 나오면 언제나 ETH를 뜻한다는 공통 이해를 바탕으로 맞춰 움직일 수 있습니다.

래핑된 ETH는 제외

WETH9처럼 프로토콜에 내장되지 않은(non-enshrined) 래핑 ERC-20 버전의 ETH가 토큰일 때는 반드시(MUST) 그 토큰 자체의 컨트랙트 주소를 써야 하고 0xeeee... 주소를 써서는 안 됩니다(MUST NOT). 즉 이 규약의 주소는 네이티브 ETH만을 가리키며 ETH를 ERC-20으로 감싼 토큰은 일반 ERC-20 토큰과 똑같이 자기 주소로 구분합니다. 원문은 이더리움 메인넷의 WETH9 주소로 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2를 예로 듭니다.

체크섬 표기

원문은 적절한 경우(where appropriate) 이 주소를 체크섬 형태로 적도록 합니다. EIP-55 체크섬을 적용한 표기는 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE입니다. 소문자로만 쓴 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee와 체크섬 표기는 대소문자만 다를 뿐 같은 주소를 가리킵니다. 사람이 읽는 문서나 화면에는 체크섬 표기를, 비교 로직에서는 두 표기를 같은 주소로 다루면 됩니다.

다른 주소 대신 0xeeee...를 고른 이유

같은 용도의 기존 구현 가운데 다수는 0x0, 0x1, 0xe 같은 주소를 씁니다. 앞쪽 바이트가 0이라 가스를 아낄 수 있기 때문입니다. 그러나 이런 주소들은 모두 프리컴파일(precompile, EVM에 내장된 특수 컨트랙트) 주소와 겹칠 수 있고 ETH를 나타내는 식별자로서 눈에 덜 띕니다. 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee는 현재 가장 많이 쓰이고 구별이 뚜렷하며 어떤 프리컴파일과도 겹치지 않습니다. 원문은 이 장점이 다른 대안의 가스 절감 효과보다 크다고 판단합니다.

ERC-4626 유동성 스테이킹 토큰 사용 사례

원문이 의도한 사용 사례 하나는 ETH를 asset으로 쓰는 ERC-4626 호환 유동성 스테이킹 토큰(LST)입니다. ERC-4626은 토큰화된 금고(vault)의 표준인데, 기초 자산을 ERC-20 주소로 가리키는 asset 필드가 있습니다. 이 필드에 0xeeee... 주소를 넣으면 ETH를 기초 자산으로 하는 금고도 ERC-4626 형식 안에 들어옵니다. 원문은 이렇게 하면 ERC-4626의 장점과 도구를 LST와 이를 연동하는 프로토콜까지 넓힐 수 있다고 설명합니다.

호환성과 상태

원문은 다른 표준과 알려진 호환성 문제가 없다고 밝힙니다. 이 표준은 새 함수나 이벤트를 정의하지 않고 주소 값 하나에 대한 약속만 정하므로, 기존 ERC-20 인터페이스나 ERC-4626 인터페이스를 바꾸지 않습니다. 상태는 Final이며 2023년 10월 3일에 만들어졌고 작성자는 Joey Santoro입니다. 이 표준은 ERC-20, EIP-55, ERC-4626을 전제(requires)로 합니다.

쓸 때 주의할 점

ERC 원문 · ← ERCs