Technology, Tutorials, for Developer, Tool support, Industry

ERC6551 토큰 바운드 계정이 NFT 혁신을 주도하는 방법

#Blockchain #Klaytn #Technology

들어가며

지난 몇 년 동안 우리는 대체 불가능한 토큰(NFT)이 고유한 디지털 아이템을 온체인에서 소유하고 표현하는 방식을 어떻게 변화시켰는지 지켜보았습니다. 이 기간 동안 NFT는 폭넓게 채택되었습니다. 또한 다양한 주체들(NFT 프로젝트, 크리에이터, 트레이더)이 적극적으로 참여했고, 지금도 ERC721을 기반으로 한 이 차세대 큰 흐름에 참여하고 있는 시대를 경험하고 있습니다. 

다양한 팀들이 NFT의 다양한 가능성을 고려하여 게임 생태계와 메타버스에서 블루칩 프로젝트를 구축했습니다. Cryptokitties, Bored Apes, Azuki, Doodles, NBA TopShot등 다양한 NFT 프로젝트가 등장했으며, 이는 한편으로는 사람들이 NFT를 수집하는 행위로 널리 알려진 JPEG를 사고팔고 거래하는 투기적 트렌드를 크게 조장했습니다.

그런데, NFT는 단순히 수집하는 것 이상의 의미가 있어야 하지 않을까요? 이것이 바로 ERC6551 토큰 바운드 계정(Token Bound Account, TBA)이 등장하는 이유입니다. 이는 단일 NFT가 자체 지갑이나 계정에 연결되는 새로운 패러다임을 열어줍니다. TBA를 통해 NFT는 정적인 성격에서 살아있는 생명체, 즉 외부에서 소유한 계정처럼 디앱과 상호작용하고, 사물을 소유하고, 상태를 변경할 수 있는 온체인 신원으로 변모합니다.

이번 아티클에서는 TBA가 무엇이며, 내부적으로 어떻게 작동하는지 살펴보겠습니다. 그런 다음 ERC6551의 다양한 사용 사례를 살펴보고 토큰 바운드 계정을 생성하는 과정을 살펴보겠습니다. 마지막으로 ERC-6551의 미래에 대해 살펴보겠습니다.

ERC6551: 대체 불가능한 토큰 바운드 계정이란?

ERC6551 표준은 Benny Giang, Steve Jang, 그리고 Jayden Windle이 이끄는 온체인 제품 스튜디오인 Future Primitive가 제안한 획기적인 표준입니다. 이 표준은 대체 불가능한 토큰 바운드 계정(TBA)이라는 새로운 개념을 제시하며, 지금까지 존재했거나 앞으로 생성될 모든 대체 불가능한 토큰에 스마트 콘트랙트 계정을 연결하여 NFT의 기능을 혁신합니다. NFT가 자산을 소유하고, 트랜잭션을 실행하고, 디앱과 상호작용할 수 있는 외부 소유 계정(Externally Owned Account, EOA)의 권한을 갖는다고 상상해 보세요. 이것이 바로 TBA가 열어주는 가능성입니다.

토큰 바운드 어카운트는 토큰(NFT)이 토큰(NFT)에 바인딩된 계정이 아닌 다른 계정에 영구적으로 바인딩된다는 점에서 Soul Bound Token (SBT)과 완전히 반대되는 개념입니다. 하지만 ERC6551은 궁극적으로 토큰 바운드 계정으로 전환되어 수집품이나 투기적 목적(매매)으로 사용되는 것을 넘어 온체인 디지털 신원이 됩니다. 이제 TBA를 통해 NFT는 계정과 관련된 자산과 트랜잭션을 완전히 제어할 수 있는 온체인 존재가 됩니다.

ERC721에서 ERC6551에 이르는 새로운 디지털 시대의 정점에 서 있는 지금, 이 표준이 NFT를 혁신하고 블록체인 기반 디지털 자산의 매력적인 새로운 사용 사례를 여는 세상을 상상해 볼 수 있습니다. 또한, 혁신적인 솔루션인 TBA는 ERC721과 완벽하게 하위 호환됩니다. 즉, 기존 NFT를 크게 변경하지 않고도 ERC-6551로 전환할 수 있습니다.

ERC-6551 내부 살펴보기: 운영 메커니즘

앞서 언급했듯이, TBA는 설계상 모든 NFT에 대해 새로운 스마트 콘트랙트 지갑을 생성하여 온체인 에이전트가 됩니다. 그렇긴 하지만, 이 NFT를 소유한 계정이 해당 자산을 제어하고 TBA를 통해 온체인 작업을 실행할 수 있다는 점에 유의하는 것이 중요합니다.

이것이 어떻게 가능할까요?

우선, ERC6551의 운영 시스템은 크게 두 부분으로 나눌 수 있습니다. 

Source

레지스트리(Registry)

레지스트리는 모든 토큰 바운드 계정의 생성 지점 역할을 합니다. 이를 위해 레지스트리에는 createAcount와 account이라는 두 가지 주요 함수가 있습니다. account함수는 구현 주소가 주어진 NFT에 대한 TBA 배포를 전담합니다. account 함수는 구현 주소가 주어진 NFT에 대한 토큰 바운드 계정 주소를 계산합니다. 

생성 계정 함수를 사용해 TBA를 생성하면 바이트코드에 불변의 상수 데이터가 추가된  ERC1167 Minimal Proxy Contract (MPC)로 배포된다는 점에 유의해야 합니다. MPC는 두 가지 이유로 TBA에 유용합니다:

  • 가스 비용 절감: NFT 콘트랙트를 반복적으로 배포하는 대신 콘트랙트 클론을 사용하면 가스 비용을 절약할 수 있습니다.
  • 노력 감소: MPC를 사용하면 프록시 컨트랙트를 한 번만 배포하면 됩니다. 새 인스턴스를 배포할 때마다 프록시에 동일한 로직이지만 새로운 데이터를 지정하기만 하면 됩니다.

토큰 바운드 계정 인터페이스

계정 인터페이스는 토큰 바운드 계정에 연결된 핵심 기능에 매우 중요하며, 다음을 구현합니다:

  • 수신 기능: TBA가 Ether를 받을 수 있도록 허용합니다.
  • 실행 기능: 이 기능을 통해 TBA는 NFT 소유자를 대신해 임의의 호출을 실행할 수 있습니다. 또한, 이 기능은 추가 작업을 지원하거나 서명자의 특정 작업 실행 능력을 제한할 수 있습니다. 이는 TBA에 대한 무단 액세스를 방지하는 데 도움이 되므로 보안을 위해 중요합니다.

토큰 바운드 계정의 실제 사용: 실제 사용 사례

이제 대체 불가능한 토큰이 KLAY, ETH, ERC20, ERC721, ERC1155와 같은 자산을 소유하고 온체인 작업을 실행할 수 있게 되었으니, 그 가능성은 무궁무진합니다. 따라서 TBA는 Web3 생태계에서 획기적이고 혁신적인 솔루션의 속도를 높일 것입니다. 다음은 ERC6551 대체 불가능한 토큰 바운드 계정의 실제 사용 사례 예시입니다.

  • 게임:  이제 게임 내 대체불가토큰 캐릭터는 TBA를 통해 게임을 탐험하면서 다양한 게임 액세서리를 수집할 수 있습니다. 이를 통해 각 게임 캐릭터는 게임 내 액세서리를 수집하고 보는 데 사용되는 배낭과 인벤토리처럼 기능할 수 있습니다. 게임 내 TBA는 탈중앙화된 게임 인벤토리를 촉진하는 데에도 도움이 될 수 있습니다. 그 외에도 게임 내 NFT 캐릭터는 게임 내에서 자율적으로 액션을 수행할 수 있게 될 것입니다.
  • 자율적인 온체인 신원: TBA를 통해 디지털 자산은 안전하고 투명한 방식으로 서비스와 자율적으로 상호작용할 수 있는 온체인 에이전트가 될 수 있습니다. 다중 서명의 서명자가 될 수도 있고, ENS 하위 도메인을 소유할 수도 있으며, 제안에 투표할 수도 있습니다.
  • DAO와 커뮤니티 구축: 대부분의 DAO와 커뮤니티는 누가 커뮤니티 활동에 가장 많이 참여했는지 항상 주시하고 있습니다. 이를 위해 대부분의 DAO와 커뮤니티는 멤버십 카드와 커뮤니티 경험을 소울 바인딩 토큰으로 표현하는데, 이는 나름의 제한이 있습니다. 예를 들어, 멤버십 카드를 판매하고도 다른 커뮤니티가 시간이 지나면서 모은 돈의 일부를 유지할 수 있습니다. 그러나 ERC6551을 통해 이제 DAO와 커뮤니티는 멤버십 카드를 TBA로 표현할 수 있으며, 이를 통해 평판과 DAO 지위를 하나의 NFT:TBA로 수집하고 보유할 수 있게 됩니다.
  • 탈중앙화 소셜 및 메시징: 앞서 언급했듯, TBA는 NFT를 일상 생활에 통합할 수 있는 새로운 가능성을 열어줍니다. TBA는 소셜 앱에서 신원 확인을 강화하는 데 사용될 수 있으며, 이는 진정한 참여를 증명하는 것을 의미합니다. 또한, TBA는 탈중앙화된 소셜 플랫폼에서 콘텐츠 제작자를 위한 소액 결제를 촉진할 수 있으며, 사용자는 TBA를 통해 콘텐츠 제작자에게 팁을 주거나 결제할 수 있습니다.

토큰 바운드 계정(TBA) 만들기 및 배포하기

TBA의 운영 메커니즘을 알고 난 후에는, 코드가 실제로 어떻게 작동하는지 살펴보는 것이 중요합니다. 이 섹션에서는 토큰 바운드 계정을 만드는 데 필요한 필수 단계를 살펴보겠습니다.

사전 요구사항

1. Remix IDE & Metamask 
– 이 튜토리얼에서는 Remix IDE를 사용하여 스마트 컨트랙트를 컴파일하고 배포하겠습니다. 그러나 선호하는 코드 편집기에서  Hardhat이나 다른 솔리디티 스마트 컨트랙트 개발 프레임워크를 사용하여 동일한 작업을 수행할 수 있습니다.

2. Faucets 와 Testnet Tokens
– MetaMask 지갑이 Baobab에 연결되어 있는지 확인합니다. 올바른 네트워크에 연결한 후 Klay Faucet에서 테스트 KLAY를 받습니다. 

1단계: Legacy ERC721 NFT 민팅하기

토큰 바운드 계정은 앞서 설명한 것처럼 스마트 콘트랙트 지갑 역할을 하는 NFT입니다. 따라서 토큰 바운드 계정을 생성하려면 고유한 ERC 721 NFT가 필요합니다. 이 단계에서는 Remix IDE의 Klaytn-contracts 라이브러리에서 생성된 레거시 ERC 721 NFT를 배포하고 발행하겠습니다. 

다음은 ERC-721 토큰 컨트랙트의 작동 예시입니다. 

solidity

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.7;

import "@klaytn/contracts/token/ERC721/ERC721.sol";

contract ERC6551BasicNft is ERC721 {

    string public constant TOKEN_URI = "ipfs://bafybeig37ioir76s7mg5oobetncojcm3c3hxasyd4rvid4jqhy4gkaheg4/?filename=0-PUG.json";

    uint256 private s_tokenCounter;

    event Minted(uint256 indexed tokenId);

    constructor() ERC721("ERC6551BasicNft", "EBN") {

        s_tokenCounter = 0;

    }

    function mintNft() public {

        _safeMint(msg.sender, s_tokenCounter);

        emit Minted(s_tokenCounter);

        s_tokenCounter = s_tokenCounter + 1;

    }

    function tokenURI(uint256 tokenId) public view override returns (string memory) {

        require(_exists(tokenId), "ERC721Metadata: URI query for nonexistent token");

        return TOKEN_URI;

    }

    function getTokenCounter() public view returns (uint256) {

        return s_tokenCounter;

    }

}

이 컨트랙트를 배포하고 발행하려면 Remix IDE로 이동합니다. 

Remix IDE

  1. Remix IDE의 파일 탐색기 탭에서 컨트랙트 폴더로 이동합니다.
  2. 컨트랙트 폴더에 ERC6551BasicNFT.sol이라는 새 파일을 생성합니다.
  3. 솔리디티 컴파일러 탭에서 Compile contract을 클릭합니다.
  4. 플러그인을 설치한 후 왼쪽의 Klaytn tab을 클릭합니다.
  5. Environment > Injected Provider – MetaMask를 선택합니다.
  6. Contract에서 컨트랙트를 선택합니다. 예) ERC6551BasicNFT.sol.
  7. Deploy를 클릭합니다.
  8. 컨트랙트가 배포되면 Deployed Contract Tab에서 컨트랙트 인터페이스를 확장하고 mintNft 버튼을 클릭합니다.

성공적으로 민팅이 완료되면, OpenSea에서 NFT를 확인하여 채굴을 확인할 수 있습니다.

2단계: 레지스트리 생성 및 배포

이미 언급한 바와 같이, 레지스트리 컨트랙트는 ERC 6551 토큰 바운드 계정의 기반이 되며, ERC 721 NFT에 지갑을 생성하고 연결하는 역할만 담당합니다. 이 섹션에서는 레지스트리 컨트랙트를 배포하고 핵심 기능인 createAccount와 account를 구현해 보겠습니다. 

  1. 지정된 매개변수가 주어졌을 때 TBA 주소를 미리 계산하는 `account` 함수
  2. ‘createAccount` 함수는 지정된 매개변수가 있는 스마트 월렛을 배포하여 TBA를 생성

TBA 주소를 도출하기 위해 ‘Create2’ 함수를 사용하여 다음과 같은 고유 파라미터를 해시합니다: TBA 구현 주소, 토큰(ERC721) 컨트랙트 주소, 토큰 ID, 체인 ID, 솔트입니다.

또한 아래 코드의 `_creationCode` 함수는 제공된 파라미터를 사용하여 스마트 지갑의 바이트코드를 생성합니다. createAccount` 함수는 새로 생성된 TBA에 대한 관련 정보가 포함된 `AccountCreated` 이벤트를 전송합니다.

다음은 레지스트리 컨트랙트의 스니펫입니다.

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.0;

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

import "./interfaces/IERC6551Registry.sol";

library ERC6551BytecodeLib {

    function getCreationCode(

        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_)

            );

    }

}

contract ERC6551Registry is IERC6551Registry {

    error AccountCreationFailed();

    function createAccount(

        address implementation,

        uint256 chainId,

        address tokenContract,

        uint256 tokenId,

        uint256 salt,

        bytes calldata initData

    ) external returns (address) {

        bytes memory code = ERC6551BytecodeLib.getCreationCode(

            implementation,

            chainId,

            tokenContract,

            tokenId,

            salt

        );

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

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

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

        assembly {

            _account := create2(0, add(code, 0x20), mload(code), salt)

        }

        if (_account == address(0)) revert AccountCreationFailed();

        if (initData.length != 0) {

            (bool success, bytes memory result) = _account.call(initData);

            if (!success) {

                assembly {

                    revert(add(result, 32), mload(result))

                }

            }

        }

        return _account;

    }

    function account(

        address implementation,

        uint256 chainId,

        address tokenContract,

        uint256 tokenId,

        uint256 salt

    ) external view returns (address) {

        bytes32 bytecodeHash = keccak256(

            ERC6551BytecodeLib.getCreationCode(

                implementation,

                chainId,

                tokenContract,

                tokenId,

                salt

            )

        );

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

    }

}

이 컨트랙트를 배포하려면 Remix IDE로 이동합니다. 

Remix IDE

  1. Remix IDE의 파일 탐색기 탭에서 컨트랙트 폴더로 이동합니다.
  2. 컨트랙트 폴더에 ERC6551Registry.sol이라는 새 파일을 생성합니다.
  3. 솔리디티 컴파일러 탭에서 Compile contract을 클릭합니다.
  4. 플러그인을 설치한 후 왼쪽의 Klaytn tab을 클릭합니다.
  5. Environment > Injected Provider – MetaMask를 선택합니다.
  6. Contract에서 컨트랙트를 선택합니다. 예: ERC6551Registry.sol.
  7. Deploy를 클릭합니다.

3단계: 토큰 바운드 계정 구현 배포

TBA를 생성하려면 이전 섹션에서 언급한 것처럼 고유 파라미터인 구현 주소를 전달해야 합니다. 이 컨트랙트는 NFT에 클레이를 받고 트랜잭션을 실행하는 기능으로 구성된 지갑 기능을 제공하여 자산의 잠재력을 최대한 발휘할 수 있게 해줍니다. 간단히 말해, 토큰 바운드 계정의 기능은 이 컨트랙트에 의해 활성화됩니다.

다음은 토큰 바운드 계정 구현 컨트랙트의 일부입니다. 

solidity

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.0;

import "@openzeppelin/contracts/utils/introspection/IERC165.sol";

import "@openzeppelin/contracts/token/ERC721/IERC721.sol";

import "@openzeppelin/contracts/interfaces/IERC1271.sol";

import "@openzeppelin/contracts/utils/cryptography/SignatureChecker.sol";

import "./interfaces/IERC6551Account.sol";

import "./interfaces/IERC6551Executable.sol";

contract ExampleERC6551Account is IERC165, IERC1271, IERC6551Account, IERC6551Executable {

    uint256 public state;

    receive() external payable {}

    function execute(

        address to,

        uint256 value,

        bytes calldata data,

        uint256 operation

    ) external payable returns (bytes memory result) {

        require(_isValidSigner(msg.sender), "Invalid signer");

        require(operation == 0, "Only call operations are supported");

        ++state;

        bool success;

        (success, result) = to.call{value: value}(data);

        if (!success) {

            assembly {

                revert(add(result, 32), mload(result))

            }

        }

    }

    function isValidSigner(address signer, bytes calldata) external view returns (bytes4) {

        if (_isValidSigner(signer)) {

            return IERC6551Account.isValidSigner.selector;

        }

        return bytes4(0);

    }

    function isValidSignature(bytes32 hash, bytes memory signature)

        external

        view

        returns (bytes4 magicValue)

    {

        bool isValid = SignatureChecker.isValidSignatureNow(owner(), hash, signature);

        if (isValid) {

            return IERC1271.isValidSignature.selector;

        }

        return "";

    }

    function supportsInterface(bytes4 interfaceId) external pure returns (bool) {

        return (interfaceId == type(IERC165).interfaceId ||

            interfaceId == type(IERC6551Account).interfaceId ||

            interfaceId == type(IERC6551Executable).interfaceId);

    }

    function token()

        public

        view

        returns (

            uint256,

            address,

            uint256

        )

    {

        bytes memory footer = new bytes(0x60);

        assembly {

            extcodecopy(address(), add(footer, 0x20), 0x4d, 0x60)

        }

        return abi.decode(footer, (uint256, address, uint256));

    }

    function owner() public view returns (address) {

        (uint256 chainId, address tokenContract, uint256 tokenId) = token();

        if (chainId != block.chainid) return address(0);

        return IERC721(tokenContract).ownerOf(tokenId);

    }

    function _isValidSigner(address signer) internal view returns (bool) {

        return signer == owner();

    }

}

이 컨트랙트를 배포하려면 Remix IDE로 이동합니다. 

Remix IDE

  1. Remix IDE의 파일 탐색기 탭에서 contract 폴더로 이동합니다.
  2. 컨트랙트 폴더에 예제 ExampleERC6551Account.sol이라는 새 파일을 생성합니다.
  3. Solidity Compiler 탭에서 Compile contract을 클릭합니다.
  4. 플러그인을 설치한 후 왼쪽의 Klaytn tab을 클릭합니다.
  5. Environment > Injected Provider – MetaMask를 선택합니다.
  6. Contract에서 컨트랙트를 선택합니다. 예) ExampleERC6551Account.sol
  7. Deploy를 클릭합니다.
  8. 새로 만든 컨트랙트의 주소를 복사합니다. 참고: 이 주소는 createAccount 및 계정 함수를 호출하는 동안 레지스트리 컨트랙트에서 구현 주소로 전달됩니다. 

4단계: 토큰 바운드 계정 주소 계산 및 배포하기

이 섹션에서는 토큰 바인딩 계정 주소를 미리 계산하고 최종적으로 배포할 것입니다. 다음 단계를 통해 살펴보겠습니다.

레지스트리 컨트랙트에서 `account` 함수 호출하기

  1. Remix IDE의 Deployed Contracts 탭에서 배포된 레지스트리 컨트랙트를 확장합니다.
  2. 계정` 함수를 클릭하고 다음 인수를 전달합니다:
    • Implementation address: 위의 세 번째 단계에서 배포한 ExampleERC6551Account.sol의 주소입니다.
    • chainId: Baobab의 경우 1001
    • tokenContract: 첫 번째 단계에서 배포한 ERC721의 주소입니다.
    • tokenId: 이 NFT의 경우 0
    • salt: 0 
  3. 모든 인수를 입력한 후 call을 클릭하여 토큰 바운드 계정 주소를 미리 계산합니다.

레지스트리 컨트랙트에서 createAccount 함수 실행하기

  1. Remix IDE의 Deployed Contracts 탭에서 배포된 레지스트리 컨트랙트를 확장합니다.
  2. createAccount 함수를 클릭하고 다음 인수를 전달합니다.
  • Implementation address: 위의 세 번째 단계에서 배포한 ExampleERC6551Account.sol의 주소입니다.
  • chainId: 바오밥의 경우 1001
  • tokenContract: 첫 번째 단계에서 배포한 ERC721의 주소입니다.
  • tokenId: 이 NFT의 경우 0
  • salt: 0 
  • initData: 이 경우 빈 배열 []

3. 모든 인수를 입력한 후 transact을 클릭하여 토큰 바운드 계정을 배포합니다.

TBA를 성공적으로 배포한 후, 새로 생성한 토큰 바운드 계정으로 NFT, 새로운 토큰(ERC-20, ERC-1155 등)을 에어드롭하고 클레이를 전송할 수 있습니다. 또한, Klaytnscope와 같은 블록 탐색기에서 트랜잭션 내역을 볼 수 있습니다. 

토큰 바운드 계정/지갑 인스턴스화하기

레지스트리가 새로운 TBA를 생성하기 위해 ‘createAccount’ 메서드를 사용할 때마다 계정 구현 주소를 제공해야 한다는 것을 기억하시나요? 그 이유는 토큰 바운드 계정 프록시가 IERC6551Account 인터페이스를 구현하는 컨트랙트에 실행을 위임해야 하기 때문입니다. 위에서 계산한 TBA 주소가 주어지면, IERC6551Account 인터페이스를 구현하는 컨트랙트(예: ExampleERC6551Account.sol)를 사용하여 토큰 바운드 계정을 인스턴스화할 수 있습니다.

  • Remix IDE에서 예시ERC6551Account 컨트랙트 파일을 클릭합니다.
  • 솔리디티 컴파일러 탭에서 Compile contract을 클릭합니다.
  • Contract에서 컨트랙트를 선택합니다. 예: ExampleERC6551Account.sol
  • TBA 컨트랙트 인터페이스를 로드하려면 At Address 필드에 주소를 붙여넣고 At Address 버튼을 클릭합니다.
  • 이제 Deployed Contracts 탭에 토큰 바운드 계정 인스턴스가 표시됩니다.

TBA 배포를 검증하려면 1단계에서 발행한 레거시 ERC721 NFT의 소유자가 토큰 바운드 계정의 소유자이어야 합니다. 즉, 레거시 NFT의 소유자가 토큰 바운드 계정도 제어한다는 뜻입니다.

ERC6551의 미래

ERC6551 토큰 바운드 계정의 탄생은 디지털 소유권과 출처를 재구상하여 혁신적인 솔루션과 우량 프로젝트를 위한 기반을 마련하고자 합니다. 이 표준은 게임, 대체 불가능한 토큰 프로젝트, DAO, 부동산 등에 유용할 뿐만 아니라 향후 놀라운 기능을 강화할 수 있을 것입니다. 이러한 미래의 사용 사례 중 하나는 메타버스와 게임 플랫폼에서 네트워크 플레이어블 캐릭터(network playable characters, NPC)의 탄생입니다. 이러한 NPC의 유일한 목적은 원래 비어 있던 메타버스를 채우고 온체인 액션을 수행하는 것입니다. 이 개념은 기존 게임 시스템에서 NPC(non-playing characters)가 작동하는 방식에서 착안한 것입니다. TBA를 통해 상상할 수 있는 또 다른 놀라운 기능은 인공 지능이 ERC6551 토큰 바운드 계정과 병합되는 것입니다. 인공지능 모델과 LLM이 TBA와 통합되면, 여러분은 NFT나 NPC가 자율적으로 온체인 작업을 수행하도록 프로그래밍할 수 있습니다. 이를 기반으로 우리는 ERC6551 토큰 바운드 계정과 함께 무한한 가능성의 미래를 상상해볼 수 있습니다. 

결론

끊임없이 성장하는 블록체인 기술 분야에서 ERC6551 토큰 바운드 계정은 새로운 패러다임을 제시할 것입니다. 이 표준의 구현은 사용 사례의 유입을 열어 NFT의 유용성과 채택을 향상시킵니다. 새로운 프리미티브인 ERC 6551은 아직 초기 단계이며, 관련 도구와 인프라가 점진적으로 개발되고 있습니다. 따라서 비즈니스 운영자, 개발자, 탈중앙화 마켓플레이스, 암호화폐 애호가들은 이 제안서에 명시된 보안 고려 사항을 살펴볼 것을 권장합니다.

ERC-6551 표준은 이더리움 가상머신(Ethereum Virtual Machine, EVM)과 호환되며, 이는 클레이튼을 포함한 EVM 호환 체인에서 작동할 수 있다는 의미입니다. 하지만 게임 플랫폼, 대체 불가능한 토큰 마켓플레이스, 서비스형 지갑 플랫폼, 대출 솔루션, RWA 토큰화 등 Web3 솔루션을 구축할 계획이라면 지금이 바로 ERC6551 대체 불가능한 토큰 바운드 계정의 가능성을 활용하여 Klaytn에서 다음 유니콘을 만들어야 할 때입니다. 이 튜토리얼의 예제에 대한 전체 소스 코드는 이 Github 저장소에서 찾을 수 있습니다. 

*Author Info.

Peter Ayo. P
Developer Advocate of Klaytn Foundation
Twitter l LinkedIn

관련 아티클

목록으로