ERC-6734 L2 토큰 목록 표준 (L2 Token List)

Review · 이름·메타데이터 · 2023-03-20 작성

여러 체인(레이어 1, 레이어 2, 사이드체인)에 걸쳐 같은 토큰을 혼동 없이 식별할 수 있는 공통 토큰 목록(JSON) 형식을 정의합니다. 토큰이 어느 체인에서 발행됐고 원본이 무엇인지 목록만 보고 알 수 있게 합니다.

왜 필요한가

이더리움 생태계에는 메인넷(레이어 1) 외에도 레이어 2, 사이드체인처럼 여러 체인이 있습니다. 토큰을 다리(브리지)로 다른 체인에 옮기면 그 체인에 토큰의 새 표현이 만들어지는데, 어느 것이 정식 토큰인지에 대한 합의 방법이 없습니다. 지금은 아비트럼과 옵티미즘 같은 레이어 2가 저마다 다른 확장 필드를 붙인 자체 토큰 목록을 관리하고 정식 여부도 토큰 이름과 심볼 조합에 기대어 판단합니다. 또 기존 목록은 토큰이 지나갈 수 있는 특정 브리지 정보를 함께 담고 있지만 그 브리지만 쓸 수 있는 것이 아니므로 토큰 목록과 브리지 정보는 분리되어야 합니다. 이런 상태로는 서로 다른 체인에 있는 토큰을 시스템에서 일관되게 다루기 어렵습니다. 그래서 이 표준은 체인을 가로질러 토큰을 하나로 식별하고 용도를 분명히 할 수 있는 공통 목록 형식을 제시합니다.

심층 설명

목록 최상위 필수 필드 [R1]

정식 토큰 목록에는 type, tokenListId, name, createdAt, updatedAt, versions, tokens 7개 데이터 요소가 반드시 있어야 합니다. tokenListId는 이 목록이 공개된 위치를 가리키는 RFC 3986 형식의 해석 가능한 URI이고 versions는 major, minor, patch 정수를 담은 버전 배열입니다. createdAt과 updatedAt은 목록의 생성·갱신 시점을 적습니다. logoURI, keywords 같은 나머지 스키마 필드도 포함하는 것이 권장 사항입니다([D1]). 스키마는 additionalProperties를 false로 두어 정의되지 않은 속성을 허용하지 않습니다.

토큰 항목 필수 필드 [R2]

tokens 배열의 각 항목은 최소한 chainId, chainURI, tokenId, tokenType, address, name, symbol, decimals, createdAt, updatedAt을 담아야 합니다. chainURI는 토큰이 발행된 체인의 제네시스 블록을 가리키는 해석 가능한 URI이고 tokenId는 토큰 배포 트랜잭션이나 토큰과 발행자를 식별하는 DID 같은 URI입니다. tokenType은 ["fungible","transferable"]처럼 토큰 성격을 배열로 적습니다. 선택 필드로는 genesisBlockHash(제네시스 블록 해시), tokenIssuerId와 tokenIssuerName(발행자), standard(토큰 표준 설명 URI), addressType, addressAlg(CREATE2 같은 주소 생성 알고리즘), tokenDesc, logoURI 등이 있습니다.

extensions로 원본 체인 밝히기

목록 항목이 토큰의 원래 발행 체인이 아닌 다른 체인 위의 토큰을 가리킬 때는 extensions를 씁니다. extensions를 쓰면 rootChainId(원본 체인 번호), rootChainURI(원본 체인 제네시스 블록 URI), rootAddress(원본 토큰 컨트랙트 주소) 세 필드를 반드시 채워야 합니다. 기존 아비트럼과 옵티미즘 목록이 확장 필드에 특정 브리지의 주소를 넣던 것과 달리, 이 표준은 브리지와 경로 목록의 표준화를 별도 문서로 분리하고 토큰의 출신 정보만 기록하게 합니다.

URI와 chainId 규칙 [R3][R4]

스키마 설명에서 URI로 지정된 모든 속성은 RFC 3986의 의미론을 따라야 합니다([R3]). chainId는 EIP-155 표준의 요구 사항, 곧 해당 체인에서 트랜잭션 재사용(리플레이) 방지가 성립하도록 하는 값이어야 합니다([R4]). 재사용 방지가 보장되려면 chainId가 유일해야 하지만 유일성을 보장하는 방법 자체는 이 문서의 범위 밖입니다. 두 요구 모두 기존 암호 라이브러리와 공개 도구로 검증할 수 있다고 원문은 설명합니다.

humanReadableTokenSymbol 규칙

사람이 읽기 쉬운 토큰 심볼 필드는 선택 사항입니다([O1]). 다만 이 필드를 쓰기로 했다면 tokenSymbol과 chainId를 이 순서대로 하이픈으로 이어 붙여 만들어야 합니다([CR2]>[O1]). 원문 예시로 tokenSymbol이 ETH이고 chainId가 1이면 humanReadableTokenSymbol은 ETH-1이 됩니다. 스키마 예시에는 MATIC-137도 있습니다. 이렇게 하면 토큰이 발행됐거나 옮겨진 체인이 심볼 표기에 함께 드러납니다.

JSON-LD와 DID 기반 설계

이 스키마는 JSON-LD 컨텍스트 파일과 함께 쓰면 JSON-LD 스키마로 활용할 수 있고 각 필드의 $comment에 schema.org 용어를 연결해 용어의 뜻과 쓰임을 분명히 합니다. W3C DID(탈중앙 식별자)와 W3C 검증 가능 자격 증명(Verifiable Credential) 같은 자기주권 신원 프레임워크와 쉽게 통합되도록 설계되어 토큰 발행자 같은 주체를 여러 체인에 걸쳐 식별할 때 상호운용이 가능합니다. 구현자는 JSON-LD, DID, 검증 가능 자격 증명을 둘러싼 기존 도구를 그대로 쓸 수 있습니다.

적합성 레벨과 입증

구현의 적합성은 세 단계로 나뉩니다. Level 1은 모든 MUST 요구를, Level 2는 MUST와 SHOULD 요구를, Level 3은 조건부 MUST·SHOULD가 딸린 MAY까지 모든 요구를 충족하고 이를 테스트 리포트로 입증해야 합니다. 적합성을 주장할 때는 각 요구에 대해 수행한 테스트 절차를 기술하는 것이 권장되고([D2]), Level 2 이상을 주장하려면 해당 레벨 요구마다 테스트 절차 기술이 필수입니다([R5]). 모든 요구를 검증할 표준화된 테스트 픽스처 세트는 아직 정의되지 않았고 표준의 다음 버전에서 공개될 예정입니다.

제안 진행 상태

이 문서는 OASIS가 관리하는 EEA 커뮤니티 프로젝트의 L2 워킹그룹이 작성했고 2023년 3월 20일 만들어졌습니다. 현재 검토(Review) 상태의 제안이므로 내용이 아직 바뀔 수 있습니다. 토큰 자체를 정의하는 표준과 브리지·경로 목록의 표준화는 이 문서의 범위 밖이며 브리지 목록은 별도 문서에서 다룰 예정입니다.

쓸 때 주의할 점

ERC 원문 · ← ERCs