ERC-7634 전송 횟수 제한 NFT (Limited Transfer Count NFT)
Final · NFT·멀티토큰 · 2024-02-22 작성
NFT 한 개마다 전송할 수 있는 횟수의 상한을 정해 두고 그 횟수를 다 쓰면 더 이상 전송하지 못하게 막는 ERC-721 확장 표준입니다.
왜 필요한가
지금의 NFT는 한 번 팔리면 처음 발행한 사람의 손을 떠나 누구에게든 끝없이 되팔 수 있습니다. 그런데 어떤 상황에서는 이런 무제한 전송이 문제가 됩니다. 프리미엄 경매품이나 한정판처럼 희소성이 가치의 핵심인 NFT는 잦은 되팔기에 노출됩니다. 몇 번 쓰면 닳아 없어져야 하는 게임 아이템이나 정해진 횟수만 양도할 수 있어야 하는 멤버십과 라이선스는 표준적인 방법으로 구현하기 어렵습니다. 또 초단타 거래처럼 짧은 시간에 반복되는 적대적 차익거래나, NFT 포지션을 반복해서 다시 스테이킹하며 레버리지를 쌓는 행위를 억제할 간단한 장치도 없습니다. 이 표준은 토큰마다 전송 한도를 정하고 실제 전송 횟수를 세어 한도를 넘는 전송을 막는 공통 인터페이스를 정의해, ERC-721과의 호환성을 지키면서 이런 세밀한 전송 제한을 가능하게 합니다.
구현해야 하는 것
event TransferCountIncreased(uint256 indexed tokenId, uint256 newCount);: 전송이 성공해 해당 토큰의 전송 횟수가 늘어난 뒤에 발생하는 이벤트입니다.event TransferLimitUpdated(uint256 indexed tokenId, uint256 previousLimit, uint256 newLimit);: 토큰의 전송 한도가 설정되거나 바뀔 때 이전 한도와 새 한도를 알리는 이벤트입니다.function transferCountOf(uint256 tokenId) external view returns (uint256);: 해당 토큰이 지금까지 전송된 횟수를 돌려줍니다.function setTransferLimit(uint256 tokenId, uint256 limit) external;: 해당 토큰의 전송 한도를 설정합니다. 소유자나 승인받은 주소가 호출할 수 있습니다.function transferLimitOf(uint256 tokenId) external view returns (uint256);: 해당 토큰에 설정된 전송 한도를 돌려줍니다.
심층 설명
세 가지 핵심 함수
setTransferLimit(tokenId, limit)는 토큰별 전송 한도를 설정하며 소유자나 승인받은 주소가 호출할 수 있습니다. transferLimitOf(tokenId)는 설정된 한도를, transferCountOf(tokenId)는 현재까지의 전송 횟수를 돌려줍니다. 구현체는 이 IERC7634 인터페이스를 반드시(MUST) 제공해야 합니다. 참조 구현에서는 두 조회 함수 모두 존재하지 않는 토큰에 대해 revert합니다.
무엇을 세고 무엇을 안 세는가
한도는 기초 토큰의 네이티브 ERC-721 전송, 즉 from과 to가 모두 영주소(address(0))가 아닌 전송에 반드시(MUST) 적용해야 합니다. 횟수 증가는 네이티브 전송이 성공한 뒤에만 일어나야 하며(SHOULD), 발행(mint)과 소각(burn)은 횟수를 올리면 안 됩니다(MUST NOT). 따라서 토큰을 만들고 없애는 일은 전송 예산을 소모하지 않고 실제 소유자 간 이동만 셉니다.
두 이벤트를 나눈 이유
TransferLimitUpdated는 한도를 정하거나 바꾸는 관리 행위에서, TransferCountIncreased는 실행 중 실제 전송에서 파생되는 상태 변화에서 발생합니다. 두 이벤트를 분리하면 어떤 변화가 관리자의 설정 변경이고 어떤 변화가 전송의 결과인지 로그만 봐도 구분할 수 있습니다. 횟수는 성공한 네이티브 전송 뒤에만 늘어나야 하며 발행과 소각에서는 늘지 않습니다.
참조 구현 패턴
권장 패턴은 OpenZeppelin ERC721의 훅을 오버라이드하는 것입니다. _beforeTokenTransfer에서 from과 to가 모두 영주소가 아닐 때 _transferCounts[tokenId] < _transferLimits[tokenId]를 require로 검사해 한도 도달 시 전송을 막습니다. _afterTokenTransfer에서 횟수를 1 올리고 TransferCountIncreased를 발생시키며 횟수가 한도와 같아지는 순간 _burn(tokenId) 같은 선택적 동작을 실행할 자리를 둡니다. supportsInterface는 type(IERC7634).interfaceId를 인식하도록 ERC-165 지원을 확장합니다.
ERC-721 호환성과 확장 조합
이 표준은 ERC-721과 완전히 호환되며 기존 컨트랙트는 ERC-721 의미를 바꾸지 않고 인터페이스와 훅만 추가해 채택할 수 있습니다. 다른 표준과 조합할 수도 있습니다. ERC-5679 같은 소각 기능과 합치면 전송 한도에 도달한 NFT가 자동으로 소멸하는, 여러 번 보면 사라지는 스냅챗 메시지 같은 동작을 만들 수 있습니다. SBT 표준의 전송 불가 기능과 합치면 정해진 횟수의 거래 뒤 한 소유자에게 영구히 귀속되는 NFT를 만들 수 있습니다.
우회 가능성을 인정한 설계
한도는 기초 토큰의 네이티브 전송에만 적용됩니다. 소유자는 토큰을 래핑 컨트랙트에 넣고 별도의 래퍼 토큰을 전송하는 식으로 우회할 수 있는데, 이를 막으려면 ERC-721 조합성을 깨야 하므로 표준은 이를 막지 않습니다. 즉 이 표준은 뚫리지 않는 보장이 아니라 네이티브 전송 예산이라는 기본 단위를 표준화한 것이며 더 강한 보장이 필요하면 수신자 허용목록이나 횟수를 그대로 이어받는 호환 래퍼 패턴 같은 완화책을 추가할 수 있습니다(MAY).
쓸 때 주의할 점
- 래퍼로 우회할 수 있습니다: 한도는 네이티브 ERC-721 전송에만 적용되므로 소유자가 토큰을 래핑해 래퍼 토큰을 거래하면 제한이 미치지 않습니다. 게임 아이템이 반드시 닳아 없어진다거나 2차 거래가 전체적으로 제한된다는 보장은 없으며 더 강한 보장이 필요하면 수신자 허용목록이나 호환 래퍼 패턴을 추가로 둘 수 있습니다.
- 한도 변경 가능성: 한도를 나중에 바꿔 제한을 무력화하는 일을 막으려면, 한 번 설정한 한도를 불변으로 하거나 줄이는 것만 허용하는 방안을 고려해야 합니다.
- 훅의 가스 비용: 전송 훅 안에 무거운 로직을 넣지 말아야 하며 한도 도달 시 소각 같은 확장 동작도 가스 측면에서 안전하게 유지해야 합니다.