ERC-2309 ERC-721 연속 전송 확장 (ERC-721 Consecutive Transfer Extension)
Final · NFT·멀티토큰 · 2019-10-08 작성
토큰 ID가 연속된 NFT를 한 번에 만들거나 옮기거나 없앨 때, 토큰마다 알림을 내보내는 대신 범위 하나로 묶은 이벤트 하나만 내보낼 수 있게 하는 ERC-721 확장 표준입니다.
왜 필요한가
NFT 표준인 ERC-721은 토큰 소유권이 바뀔 때마다 Transfer 이벤트를 하나씩 내보내도록 정합니다. 효율적인 자료구조를 쓰면 한 트랜잭션에서 수십억 개의 NFT를 만들 수는 있지만 원래 규격대로라면 그만큼의 Transfer 이벤트를 내보내기 위해 수십억 번 반복하는 루프가 필요합니다. 이런 루프는 가스가 바닥나거나 트랜잭션 한도를 넘겨 결국 실행할 수 없습니다. 한편 많은 탈중앙 마켓플레이스와 블록 탐색기는 Transfer 이벤트를 보고 어떤 주소가 어떤 NFT를 갖고 있는지 파악합니다. 즉 이벤트 없이 대량 발행만 하면 이런 플랫폼이 소유권을 추적할 방법이 없습니다. 이 표준은 연속된 토큰 ID 범위 전체를 이벤트 하나로 알리는 공통 방식을 제공해 이 문제를 풉니다.
구현해야 하는 것
event ConsecutiveTransfer(uint256 indexed fromTokenId, uint256 toTokenId, address indexed fromAddress, address indexed toAddress);: 연속된 토큰 ID 범위(fromTokenId부터 toTokenId까지)의 토큰이 fromAddress에서 toAddress로 생성·전송·소각되었음을 한 번에 알리는 이벤트입니다.
심층 설명
이벤트 정의와 인덱스 파라미터
ConsecutiveTransfer(uint256 indexed fromTokenId, uint256 toTokenId, address indexed fromAddress, address indexed toAddress) 하나로 생성·전송·소각을 모두 표현합니다. fromTokenId, fromAddress, toAddress는 반드시 인덱스(indexed) 파라미터여야 하고 toTokenId는 인덱스 파라미터이면 안 됩니다. 솔리디티 이벤트는 인덱스 파라미터를 최대 3개까지 둘 수 있는데, 보통 특정 주소의 소유 이력을 찾는 경우가 많으므로 주소 두 개와 시작 ID를 인덱스로 잡고 toTokenId는 로그의 데이터 부분에서 디코딩해 얻도록 했습니다.
발행·소각 시 0 주소 규칙
토큰을 만들 때는 fromAddress를 0 주소(0x0)로, 태울 때는 toAddress를 0 주소로 설정해야 합니다(MUST). 예시로 단일 발행은 emit ConsecutiveTransfer(1, 1, address(0), toAddress), 10만 개 배치 발행은 emit ConsecutiveTransfer(1, 100000, address(0), toAddress), 배치 소각은 emit ConsecutiveTransfer(1, 100000, from, address(0))처럼 씁니다. 발행·전송·소각을 하나의 이벤트로 합친 데 따른 혼동은 ConsecutiveTransfer 토픽을 확인하고 ERC-165로 해당 컨트랙트가 ERC-721 인터페이스를 지원하는지 검증하면 줄일 수 있습니다.
Transfer 이벤트와의 중복 금지
ConsecutiveTransfer 이벤트를 내보낼 때는 같은 건에 대해 원래의 Transfer 이벤트를 내보내면 안 됩니다(MUST NOT). 이 표준을 구현한 컨트랙트도 단일 토큰 전송에는 기존 Transfer 이벤트를 계속 쓸 수 있지만 같은 트랜잭션에서 두 이벤트를 함께 내보내서는 안 됩니다. 두 이벤트가 겹치면 이벤트로 소유권을 추적하는 플랫폼에 버그와 불필요하게 복잡한 로직이 생기기 때문입니다.
실행 주체와 범위 요건
트랜잭션을 실행하는 주소는 fromTokenId와 toTokenId 범위 안의 모든 토큰을 소유하고 있거나, 소유자를 대신해 행동할 수 있는 승인된 운영자(approved operator)여야 합니다(MUST). 또한 fromTokenId와 toTokenId는 반드시 연속된 토큰 ID 범위여야 합니다. 이 표준은 배치 생성·전송·소각을 어떻게 구현할지는 정하지 않고 그 뒤에 내보내는 이벤트만 표준화합니다. 범위 지정 방식으로 2^256개의 토큰 전송·생성까지 표현할 수 있습니다.
ERC-1155와의 비교
ERC-1155도 2019년에 대량 토큰 문제를 풀기 위해 표준이 되었지만 원문에 따르면 고유한(unique) 토큰을 대량으로 저렴하게 발행하는 데는 부족합니다. ERC-1155는 준대체 가능(semi-fungible) 토큰을 대량 발행할 때는 잘 맞지만 고유 토큰을 대량 발행하면 비용이 매우 커지거나 가스가 바닥납니다. 2309 표준을 쓰면 빈 NFT 수백만 개를 먼저 발행해 두고 각 토큰의 메타데이터를 비용 효율적으로 갱신하는 방식이 가능하다고 원문은 설명합니다.
하위 호환성과 플랫폼 대응
이 확장은 기존 ERC-721 규격을 거의 바꾸지 않지만 기존 Transfer 이벤트만으로 소유권을 색인하는 플랫폼에는 영향이 큽니다. ConsecutiveTransfer 이벤트를 듣지 않으면 그 안에 담긴 소유권 변동을 기록하지 못하기 때문입니다. 이 이벤트를 지원하려는 플랫폼은 기존 Transfer 이벤트와 ConsecutiveTransfer 이벤트를 둘 다 추적하는 것이 가장 좋습니다. 원문에는 이 표준 자체에 직접 관련된 보안 고려 사항은 없다고 적혀 있습니다.