ERC-6551의 특징과 사례

katekim

Published in

Decipher Media ｜디사이퍼 미디어

23 min readJul 16, 2023

서울대학교 블록체인 학회 디사이퍼(Decipher)에서 ‘ERC-6551’ 표준을 주제로 Weekly Session에서 발표한 내용입니다. 이 글은 ERC-6551의 특징과 활용가능성에 대해 다루고 있습니다.

Author: 김경은(@katekim815), 낭만적 인본주의자(@Romantic_Humanist)

Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)

Reviewed By Decipher Media Team

1. ERC-6551 이란?

1–1.등장배경

ERC-6551이란, 쉽게 말해 NFT를 강화하는 기능이다. 기존의 NFT는 단순한 객체로서 존재했다. ERC-721은 해당 데이터를 “고유한” 데이터로 지정하는 역할을 했다. 그 덕에 NFT는 Non-Fungible 한 속성을 가졌다.

초기 NFT 시장에서는 해당 기능만으로 충분했다. 디지털 세상에서 자신이 가진 데이터(PFP, 아트 등)가 유일한 것임을 입증할 수 있었기 때문이다. 하지만 NFT가 정말로 가치가 있는 것인가 하는 의구심이 생겨나기 시작했고, 현재 NFT는 “유틸리티”를 강요받고 있는 상황이다.

이에 블루칩 프로젝트들은 NFT에 물약을 먹여 새로운 NFT로 바꾸거나 (MAYC), NFT를 가지고 있으면 특정 Token 혹은 Sub NFT를 에어드랍 하는 등의 방식을 사용했다. 하지만 이는 블록체인 기술을 활용한 것이 아니었다. 특정인이 해당 NFT를 가지고 있다는 Snapshot을 찍고, 이를 기반으로 새로운 NFT를 생성하거나, Token Air Drop한 것이다.

블록체인 Native한 것이 아니기 때문에, 인터페이스 단을 해킹하거나, Snapshot 기능을 해킹할 수 있었다. 만약 해킹이 있었다면, NFT를 보유하지 않은 악의적인 사용자가 새로운 NFT를 민팅하거나, Air Drop을 받을 수 있었다. 즉 NFT의 유틸리티가 완전히 구현된 것으로 볼 수 없다. 이러한 한계점을 해결하기 위해서 나온 기능이 ERC-6551 표준이다.

1–2.디지털 아이덴티티의 이동

ERC-6551을 통해 Metamask 지갑에서 NFT(PFP)로 디지털 아이덴티티(Identity)가 이동했다고 볼 수 있을 것이다. NFT, 그중에서도 PFP가 등장하기 전에 사람들은 metamask 월렛주소를 통해서 자신을 드러냈다. 하지만 이더리움 지갑안에 담을 수 있는 디지털 자산 (ETH, ERC-20기반 토큰, 다양한 프로젝트의 NFT, PAOP 등)이 많아지면서, 컨셉 별 혹은 프로젝트별로 더 세분화된 아이덴티티를 보여주고자하는 니즈가 생겼다.

특히 NFT PFP를 트위터 프로필 등 SNS에서 사용하기 시작하면서, PFP에 자신의 자아를 투영하기 시작했다. NFT 그 자체에 역사를 쌓아, 자신의 자아를 투영하고자 하는 니즈가 생긴 것이다.

1–3. 기술 개요

ERC-6551은 Token Bound Account를 생성하는 기능이다. 쉽게 말해, NFT가 자신의 ‘지갑’을 가질 수 있는 것이다. NFT 역시 ERC-721 혹은 ERC-1155 표준을 따르는 Token이다. Token들이 자신의 지갑을 가지는 것이 ERC-6551의 핵심 기능이다. Token Bound Account는 이제부터 TBA라는 약자로 표현할 것이다

NFT가 자신의 ‘지갑’을 가질 경우, NFT가 ERC-20, ERC-721, ERC-1155를 가질 수 있다. 해당 기능을 예시로 들면 다음과 같다.

A 라는 NFT를 생성할 때, A NFT는 자신의 지갑을 가지고, 그 지갑 안에는 ERC-20 a Token이 보관되어 있다.
NFT가 거래될 때, 구매자는 A라는 NFT와 ERC-20 a Token을 통째로 거래할 수 있다.
NFT 프로젝트가 특정 ERC-20 Token을 에어드랍 한다고 하면, A NFT Account가 ERC-20 Token을 생성할 수 있는 기능을 추가할 수 있다. 즉 소유만 확인하는 Snapshot이 아닌, Fully On-Chain 방식으로 Air Drop을 받을 수 있는 것이다

2.ERC-6551 기술 특징

시간이 지날 수록 다양한 NFT의 쓰임이 나옴에 따라 ERC-998, ERC-1155, ERC-5606등 NFT를 다양하게 활용하기 위한 이더리움 표준이 등장했다. ERC-6551은 ERC-721, ERC-1155와 같은 토큰 타입은 아니며, 정확히는 토큰이 에셋(asset)을 가질 수 있는 권한을 갖는 컨트랙트를 의미한다.

이전에 등장했던 ERC-998, ERC-1155, ERC-5606 등이 NFT를 발행하면서 토큰 하나에 ERC-20, NFT등을 담았다면, ERC-6551은 토큰내의 각 Asset을 따로 보낼 수 있도록 구현한 것이다.

ERC-998, ERC-1155, ERC-5606는 하나의 토큰내에 저장된 에셋 전체가 토큰을 전송함에 따라 함께 이동한다. ERC-6551의 경우에는 NFT가 하나의 지갑 역할을 하여 토큰 내의 에셋 각각 전송이 가능하다.

NFT프로젝트를 진행하게되면 로드맵대로 실현되기도 하지만, 다른 기업과 콜라보레이션으로 이벤트를 할 경우, 오프라인 행사를 할 경우들이 생긴다. 즉 NFT의 사진,성질을 변하게 만들어야 하는 것 이다. 이 경우 통상적으로 사용하는 방식은 NFT 보유를 스냅샷으로 확인하고, 블록체인이 아닌 웹 단에서 새로운 사진,성질을 담은 PFP를 생성하는 것이었다. 하지만 ERC-6551은 PFP NFT에 TBA를 생성해 아이템(귀걸이, 목걸이, 뱃지 등)을 추가로 민팅하고, 이를 온체인으로 확인하고 반영할 수 있다.

2–1.ERC-6551 표준 특성

ERC-6551은 이미 발행된 ERC-721의 특성을 변경할 필요가 없으며 , NFT가 갖는 권한을 TBA(Token Bound Account)도 동일하게 가진다.

이미 기 발행된 NFT (BAYC, Azuki 등)들이 상당한 가치를 가지고 있기 때문에, ERC-721 규격을 바꾸거나, TBA가 ERC-721과 다른 형태라면 시장에 큰 혼란을 가져올 수 있다. 하지만 ERC-6551은 현상황에 혼란을 주지 않고, 추가적인 기능을 만들었다.

ERC-6551 구현을 위해 필요한 구성요소는 아래 두가지이다.

A permissionless registry: 토큰 바인딩 계정 배포를 위한 권한없는 레지스트리
A standard interface: 토큰 바운드 계정 구현을 위한 표준 인터페이스

첫째로 **비허가형 레지스트리(A permissionless registy)**를 살펴보자.

레지스트리는 토큰 바인딩 계정을 활용하고자 하는 프로젝트를 위한 단일 진입점 역할을 하며, 레지스트리 컨트랙트는 그 권한이 없고 불변하며 소유자가 없다.

예제 컨트랙트를 살펴보면 아래와 같다.

pragma solidity ^0.8.13;

import "openzeppelin-contracts/utils/Create2.sol";

contract ERC6551Registry is IERC6551Registry {
    error InitializationFailed();

    function createAccount(
        address implementation,
        uint256 chainId,
        address tokenContract,
        uint256 tokenId,
        uint256 salt,
        bytes calldata initData
    ) external returns (address) {
        bytes memory code = _creationCode(implementation, chainId, tokenContract, tokenId, salt);

        address _account = Create2.computeAddress(
            bytes32(salt),
            keccak256(code)
        );

        if (_account.code.length != 0) return _account;

        _account = Create2.deploy(0, bytes32(salt), code);

        if (initData.length != 0) {
            (bool success, ) = _account.call(initData);
            if (!success) revert InitializationFailed();
        }

        emit AccountCreated(
            _account,
            implementation,
            chainId,
            tokenContract,
            tokenId,
            salt
        );

        return _account;
    }

    function account(
        address implementation,
        uint256 chainId,
        address tokenContract,
        uint256 tokenId,
        uint256 salt
    ) external view returns (address) {
        bytes32 bytecodeHash = keccak256(
            _creationCode(implementation, chainId, tokenContract, tokenId, salt)
        );

        return Create2.computeAddress(bytes32(salt), bytecodeHash);
    }

    function _creationCode(
        address implementation_,
        uint256 chainId_,
        address tokenContract_,
        uint256 tokenId_,
        uint256 salt_
    ) internal pure returns (bytes memory) {
        return
            abi.encodePacked(
                hex"3d60ad80600a3d3981f3363d3d373d3d3d363d73",
                implementation_,
                hex"5af43d82803e903d91602b57fd5bf3",
                abi.encode(salt_, chainId_, tokenContract_, tokenId_)
            );
    }
}

Account 함수 에서는 ERC-721에서 기본으로 확인 할 수 있는 ChainID, TokenContract, TokenId를 가져오는 역할을 한다. 구현 주소가 주어진 ERC-721 토큰에 대한 TBA를 계산하기 위한 읽기 전용 함수이다.

CreateAccount 함수는, 구현 주소(implementation address)가 주어진 ERC-721 토큰에 대한 TBA를 배포한다.

레지스트리는 각각의 ERC-721토큰이 정해질 수 있도록 create2 opcode를 사용해서 모든 TBA를 배포해야며, ERC-721토큰의 계정주소는 구현주소, 토큰 컨트랙트주소, 토큰ID, EIP-155체인ID 및 salt의 고유조합에서 파생되어야 한다.

다음으로 ERC-6551 표준은 **표준 인터페이스 (A standard interface)**를 사용하였다.

인터페이스는 ERC-165 인터페이스를 구현해야하며, ERC-1271 서명 유효성 검사를 구현해야한다. 이를 통해 레지스트리에서 생성된 TBA 제어 권한이 해당 NFT소유자에게 위임되어 소유자가 TBA 사용이 가능해진다.

초기 ERC-6551을 제안한 팀은 ERC-721의 고유성을 어카운트로도 반영하고자 하였다. ERC-721이 대체 불가능한 고유한 속성을 가지고 있기 때문에, TBA도 식별자를 두어 하나만 생성할 수 있는 방법을 고려하였다.

그러나 이더리움은 스마트 컨트랙트를 배포하는 데 허가가 필요하지 않은 비허가성(permissionless) 성질을 가지고 있기 때문에 TBA를 하나로 제한하는 것은 불가능하다. 따라서 ERC-721 토큰은 레지스트리 컨트랙트 갯수만큼의 TBA를 추가로 가질 수 있다.

추가로 ERC-4337 Account Abstraction 과 비교를하자면,

ERC-4337이 EOA(External Owned Account)와 CA(Contract Address)를 추상화 한 표준이라면, ERC-6551은 NFT를 추상화한 것이다.

4337의 경우에는 컨트랙트가 트랜젝션을 일으켜야 하기 때문에 구현이 어렵지만, 6551은 NFT를 소유하고 있는 지갑에서 에셋을 전송할 수 있는 권한을 가지고 있기 때문에 (EOA가 트랜젝션을 일으킬 수 있기 때문에) 구현이 어렵지 않다.

물론 ERC-6551에 ERC-4337표준을 대입하여 NFT 컨트랙트가 트랜잭션을 일으킬 수 있도록 활용도 가능하다.

2–2.ERC-6551 적용 프로젝트 (SAPIENZ)

실제 ERC-6551이 적용된 프로젝트를 통해 그 쓰임을 알아보자. 이는 투자 권유가 아니며, 이해를 돕기 위한 예시이다. (https://opensea.io/collection/sapienz)

SAPIENZ 프로젝트는 2097년 뉴욕을 배경으로하며, 뉴욕의 창의적인 기업가를 PFP화한 프로젝트이다. 15000개의 토큰(SAPIENZ)를 발행하며 FEED, HOOD 등의 아이템을 추가로 민팅하여 PFP에 담을 수 있다. 오픈씨(Opensea)에서는 ERC-6551표준을 지원하기 때문에 PFP안에 TBA주소도 함께 보여지며, TBA내에 NFT홀더가 가지고 있는 에셋도 볼 수 있다.

원래라면, 지갑에 각각 존재해야 하는 NFT가 NFT TBA내에 존재하는 것이다. 그리고 Sapienz는 해당 특성을 반영해, NFT PFP 사진을 변형한다.

TBA내의 에셋들은 다른 TBA에 전송, 스왑 과 같은 다양한 온체인 내 활동이 가능하다. 이러한 트랜잭션은 기본 블록체인 네트워크에서 검증되고 실행되기 때문에 온체인 특성을 유지할 수 있게 된다. 또한 TBA를 생성하면 각각의 NFT마다 ENS(Ethereum Name Service)도 가질 수 있기 때문에 고유성도 나타낼 수 있다.

다만, 프로젝트내에서 ERC-6551을 활용해 TBA를 생성할 수 있는 페이지는 추가로 제공해주어야 한다. 사용자는 페이지에서 월렛을 연결 해 토큰바운딩 어카운트를 생성하고 동일한 권한을 위임할 수 있도록 승인을 해야한다.

3.ERC-6551 활용 가능성

3–1.Gas Fee의 절약

특정 NFT를 벌크로 묶어서 산다거나, NFT를 판매할 때 해당 게임에서 사용되는 물약, 아이템을 묶어서 판다던가, Air Drop을 할 때 일부 트랜잭션을 생략하는 방식으로 Gas Fee를 절약할 수 있다. 예시는 다음과 같다

NFT를 살 때는, 개별 NFT마다 Transaction이 일어나야 한다. 하지만 NFT TBA에 해당 NFT Collection이 들어가 있다면, 한번의 Transaction으로 모든 NFT를 살 수 있다
게임 아이템 역시 마찬가지이다. 캐릭터, 물약, 아이템을 다 따로 사는 것이 아니라, 이를 캐릭터 NFT TBA안에 넣고, 한번에 거래를 처리할 수 있다
여러개의 NFT, 여러 종의 Erc-20 Token을 이체할 때, 하나의 NFT Account에 넣어서 한번에 처리할 수 있다

3–2.보안의 향상

글의 초입에서 말했던 다양한 Air Drop을 완벽히 온체인 방식으로 할 수 있기 때문에 보안이 향상될 수 있다.

NFT를 판매하는 시점에, ERC-20 토큰을 내재한 채로 판매를 해서 Air Drop을 할 수 있다
NFT를 보유한 홀더가 아닌, NFT TBA에 NFT, ERC-20 토큰을 에어드랍 할 수 있다. 별도의 스냅샷이 필요하지 않다

한편 일반적인 인식과 달리 지갑 Drain 가능성을 낮출 수는 없다. TBA가 Dapp을 호출해 컨트랙트를 발생시킨다고 하더라도, 사실상 컨트랙트의 실행 주체는 TBA를 보유한 지갑이다. TBA는 EOA가 아니기 때문에, Dapp과 직접적으로 상호작용 할 수 없다. 지갑이 상호 작용을 하지만, Ethscan상 상호작용을 한 주소가 TBA로 나오는 것이다.

3–3.Interactive NFT

온체인으로 상호 작용 가능한 NFT를 만들 수 있다. NFT TBA에 ERC-20 Token, ERC-721 NFT가 들어있을 경우 새로운 형태로 표현되거나, 강화하는 식으로 만들 수 있다.

기존 Blockchain RPG 게임에서는, 캐릭터 NFT, 아이템 NFT가 따로 존재했다면, 캐릭터 NFT TBA에 아이템을 넣을 수 있다. 이를 통해 캐릭터 NFT의 성능이 좋아지는 것을 쉽고, 안전하게 구현할 수 있다.

이 외에도, NFT TBA에 특정 파츠 (헤어, 엑세서리)를 넣을 경우 이를 표현해 NFT가 변화하는 상호 작용을 넣을 수 있다. 이는 추후 PFP에서 유용하게 쓰일 수 있다. 단, 이는 비판 받을 여지가 있다. 이는 추후 설명하도록 하겠다.

3–4.NFT On-Chain Identity

3–4–1. Loyalty Program 강화

기존의 Air Drop은 “NFT를 홀딩하고 있으면” 주어지는 형식이었다. NFT 홀더에게 몇 가지 미션을 강제할 수는 있었지만, 기본적으로 NFT와 홀더간의 유대감이 낮았다. 하지만 NFT TBA가 있을 경우, 위조 불가능한 “온체인 기록”이 NFT에 쌓이게 된다. 이를 활용해 Loyalty Program을 강화할 수 있다.

예를 들자면 다음과 같다.

NFT 홀더는 특정 행사 (IRL, 온라인 밋업 등)에 참여해서 Poap를 받을 수 있다
특정 Poap를 가진 NFT 홀더만이 Air Drop 혹은 Early Access에 참여 가능하다
단순히 NFT를 홀딩하는 것이 아니라, 실제 행사에 참여하고 기여한 개인만이 이권을 얻을 수 있다
이를 기반으로 Holder들의 Loyalty를 제고하고, 새로운 사업을 진행할 수 있는 가능성이 생긴다

3–4–2. NFT Credit의 창출 가능성

이처럼 NFT 자체에 온체인 데이터가 남을 경우 Credit이 발생할 가능성이 있다. 일부 NFT 홀더는 자신의 NFT에 자신의 자아를 투영한다. NFT과 강한 유착 관계가 형성된다. 기존에는 이를 측정할 지표가 “NFT 홀딩 기간” 정도 밖에 없었다면, NFT TBA 덕에 다양한 지표를 만들 수 있는 가능성이 생긴다.

NFT를 들고 행사에 참여해서 얼마나 많은 Poap 등을 받았는가?
NFT를 활용한 온체인 활동에 얼마나 많이 참여 했는가?
NFT TBA에 있는 온체인 데이터를 정제해, 소유자가 NFT에 대해 가지는 애착을 수치화 한다
해당 NFT를 버리지 않을 것이라는 가정하에, 담보 대출이 가능하다. 이 때, 해당 담보의 가치는 시장 가치가 아닌, 자체적으로 만든 지표에 의해 산출된다
가령 인터넷 쇼핑몰에서 정기적으로 분유, 기저귀를 구매하는 사용자는 가정/자식이 있을 확률이 높고, 이들은 연체하지 않을 가능성이 높기 때문에 더 낮은 금리에, 더 많은 금액을 빌려줄 수 있다
NFT TBA에 더 많은 Poap, TBA를 활용한 다양한 트랜잭션을 일으킨 사람은 NFT에 대한 애정이 있고/자아가 투영된 사람으로 이를 담보로 받을 경우 이들은 상환을 할 것이라는 가설을 세울 수 있다

물론 이는 가설일 뿐이다. 하지만 자신이 키운 게임 아이디, SNS에 애착을 가지는 유저들은 이미 Web2 세상에도 많다. 하지만 NFT는 “키우는”느낌이 없었고, 키운다고 한들 “기록”이 남지 않았다. 하지만 ERC-6551의 도입 이후, TBA에 Poap, Tx Record가 쌓일 경우 “기록”이 남고, 애착이 형성될 가능성이 생긴다.

홀더들이 해당 NFT를 버리지 않을 것이라는 가정이 생기고, 이를 수치화할 수 있는 지표를 개발하면 — 온체인 신용이 탄생할 수 있다. 해당 NFT를 홀딩 하고 있는 홀더 (지갑) 혹은 NFT 그 자체가 시간이 쌓인 자산이 되고, 이를 기반으로 ‘신용’을 창출해 유동성을 늘릴 수 있다. 물론, 다시 한번 말하지만 이는 어디까지나 가능성일 뿐이다.

이 외에 기타 가능성으로 “Air Drop 계정 판매”가 있을 수 있다. 최근 많은 프로젝트들이 Account가 많은 Transaction을 발생시켰을 때 더 많은 Air Drop 을 하는 경우가 늘어나고 있다. 이 때 Air Drop을 소위 숙제로 부르며 다계정 작업을 하는 사람이 많아지고 있다. 일부 개인은, 숙제를 하는 것이 힘들다며 하지 않고, 숙제를 한 Account를 사고 싶어하는 Needs가 있다. 하지만 지갑 생성시 Private Key를 생성자가 보유하기 때문에 계정 거래가 어려운 상황이다. 이러한 상황에서 NFT TBA로 숙제를 하고, 해당 NFT를 판매한다면 안전하게 “Air Drop” 계정 판매가 가능하다. 단, Air Drop 테마가 언제 끝날지 모르기 때문에, 해당 가능성은 별도로 적지 않았다.

4.ERC-6551 활용 가능성 오해

일부 아티클을 보면 ERC-6551을 활용해 다음과 같은 혁신이 발생할 수 있다고 주장한다. 해당 주장은 틀렸거나 / 설령 구현한다고 한들 효용이 없는 것들이다.

4–1.컨텐츠 독점 열람 권한

NFT를 판매할 당시, TBA에 해당 컨텐츠를 넣어서 판매한다고 한들 독점적 권한을 줄 수 없다. TBA안에 있는 NFT를 재판매할 수 있기 때문이다.

또한 해당 기능은 ERC-6551로만 구현 가능한 것이 아니다. 오히려 NFT 홀더임을 인증하고 — Discord, Web Site에 입장하는 것은 어려운 일이 아니다. 굳이 NFT가 아니더라도, Web2 적으로 인증 방식을 만드는 것이 더 효율적이다. 이는 이미 쉽게 구현할 수 있는 것으로 ERC-6551만의 혁신으로 보기 어렵다.

4–2. STO 및 RWA

NFT TBA에 다양한 정보를 넣어, Real World Asset을 거래할 수 있고, 이를 STO화 할 수 있다고 주장한다.

해당 주장은 이론적으론 가능하지만. 효용이 없다. ERC-6551을 사용해, TBA에 계약서 및 RWA 정보를 넣을 수는 있다. 하지만 RWA, STO의 가장 큰 이슈는 “근간이 되는 현실 세계 자산이 어떻게 Token과 매칭 되느냐” 하는 것이다. 이는 오프체인에서 STO/RWA 토큰 관리자가 풀어야 할 문제다.

특정 STO가 해당 자산의 수익을 청구할 권한이 있음을 보증하는 주체는 STO의 발행 주체, 관리자이다. 이는 ERC-6551로 풀 수 있는 문제가 아니다. 오히려 리걸 이슈에 가깝다.

4–3. Crowd Funding

크라우드 펀딩 역시 마찬가지로, 해당 영역의 문제는 블록체인에 있는 것이 아니다. 따라서 ERC-6551이 해결책이라고 볼 수 없다.

A가 블록체인을 통해 돈을 모으고, 이를 일정 기간 동안 락업하고 사업을 진행한 다음 가져간다고 가정하자. 이 경우 가장 큰 문제는 “A가 실제로 사업은 이행하지 않고, 락업 기간을 기다렸다가 돈을 인출하는 경우”이다. 해당 문제는 ERC-6551로 풀 수 없는 문제이다

4–4.기타

이 외에도, 투표, 공급망 관리 등에도 ERC-6551이 쓰일 수 있다고 주장한다. ERC-6551을 사용할 순 있겠으나, 미비한 정도의 효용일 것이며 해당 문제는 ERC-6551만이 해결할 수 있는 문제가 아니다. 오히려 ERC-6551을 사용함으로서 문제가 더 복잡해 질 가능성이 있다.

5.ERC 6551에 대한 비판

5–1. Interactive NFT에 대한 비판

ERC-6551을 차용해 만든 ERC-6551 NFT의 가장 큰 문제는 “스스로가 중앙화된 Asset”임을 증명한다는 것 이다.

캐릭터 NFT TBA에 아이템 NFT를 넣을 경우, 해당 캐릭터의 외관이 변화하고/강화되는 것은 해당 캐릭터 NFT를 중앙화된 DB에서 관리함을 의미한다. NFT TBA를 읽고, 특정 NFT를 Attribute화 해서 자체적인 DB에서 이를 반영하는 것이기 때문이다.

이 경우, ERC-6551이 편하다고 한들, “중앙화된 DB에 관리할 것이면, 왜 NFT화 시켰냐”라는 비판에 직면할 수 있다.

이는 비단 게임 뿐만 아니라, Interactive 요소를 넣은 NFT들이 모두 직면할 수 있는 문제이다. 해당 비판에 직면하지 않기 위해서는, On-Chain Native한 Interactive Contents를 마련해야 한다

물론 이는 대부분의 NFT가 Meta Data를 따로 관리하기 때문에 이미 겪고 있는 문제이다. 대부분의 시장 참여자는 프로젝트가 DB를 관리하는 것에 합의한 상태이다. 따라서 추후 문제가 되지 않을 수도 있다.

하지만, ERC-6551을 활용하겠다는 명목 하에 자체적인 DB를 만들고, 이를 악의적으로 변형하거나, 게임사가 이용자로부터 더 많은 돈을 벌기 위해 악의적 밸런스 패치를 진행한다면 ERC-6551은 비판에 직면할 가능성이 있다

5–2. Scam/Drain 위험성

거래 과정에서 TBA에 있는 자산이 악용될 수 있다. 예시로 들면 다음과 같다

Alice가 NFT에 TBA만들어서 10ETH예치
Bob이 11ETH에 NFT산다고 offer
Alice가 10ETH를 TBA에서 인출한 후 NFT판매 offer 수락
NFT는 Bob에게 갔지만 TBA에는 아무것도 없음

이를 해결하기 위해서 NFT 거래시 해당 TBA를 락업해야 한다.

또한 유저 입장에서는 TBA 컨트랙트에 Drain 기능이 있는지 추가로 확인해야 한다. NFT 프로젝트가 배포시, Registy에 TBA의 전송 권한을 자신들이 소유한 채 배포할 수 있다. 이 경우 NFT 프로젝트가 TBA에 있는 NFT, Token을 Drain할 수 있다. 따라서 유저들은 Drain을 한번 더 확인해야하는 불편함이 있다.

6.결론

ERC-6551은 비약적인 UX 개선이 있던 ERC-4337, Deflationary Model로 변한 이더리움 2.0 업데이트와는 성격이 다르다. 분명 ERC-721의 성능을 개선할 수 있는 업데이트는 맞지만 비약적인 발전이 있는 것은 아니다. 레지스트리 컨트랙트의 코드를 보더라도 NFT에 주소를 생성하는 것이 이전의 ERC표준들을 활용하면 충분히 구현 가능하기 때문이다.

다만, 계정(Account) 의 활용 측면에서는 그 의의가 있다. 이더리움에서 어카운트는 온체인 데이터 활용의 시작점으로 볼 수 있다. 이더리움 네트워크 내에서 이루어지는 트렌잭션이 많아질수록 기능에 따라 월렛을 구분하여 관리하여 편의성을 증진시킬 수 있기 때문이다. 어카운트를 다루는 논의는 시간이 지날 수록 많이 이루어질 것으로 본다. 단, 계정을 이용하는 유저들이 많아야 ERC표준들이 그 쓰임이 있을 것이다.

사업적으로 보았을 때, ERC-6551이 새로운 가능성을 열어준 것은 맞지만, 획기적인 것이냐 하면 여전히 의문이다. NFT On-Chain History가 쌓여 새로운 Loyalty Model, 애착 형성, NFT 신용 탄생의 가능성이 열리긴 했지만 현실적으로 해당 사업이 가능할지, 추진한다고 한들 얼마나 사업성이 있을지는 의문이다.

또한 Interactive NFT에 대한 비판에서 확인했듯, 게임에서 아이템들 업그레이드 하는 것을 굳이 온체인으로 해야할 필요가 있을까? 라는 생각이 들었다. Fully On-Chain한 컨텐츠/사업을 개발하지 못한다면 ERC-6551은 큰 빛을 보지 못할 가능성이 있다고 생각한다.

이제 막 ERC-6551이 도입되었고, 아직까지 해당 기술의 가치를 논하기에는 너무 이른 시점인 것은 맞다.

빌더 입장에서 해당 솔루션을 어떻게 쓸 것일지 아이데이션을 해보고 있지만 쉽지 않다. 특히 On-Chain Native하게 어떻게 새로운 컨텐츠, 유틸리티를 만들어 낼 것인지 더 많은 고민이 필요하다고 판단했다.