ERC-6551: NFT가 지갑을 소유하는 방법

NFT(Non-fungible Token)는 정적인 수집품에서 자산을 소유하고, 거래를 실행하며, 탈중앙화 애플리케이션과 상호 작용할 수 있는 프로그래밍 가능한 신원으로 진화하고 있습니다. ERC-6551(토큰 바운드 계정, TBA라고도 함)은 각 NFT에 자체 스마트 계정을 부여하여 이를 가능하게 하는 표준입니다. 이 글에서는 ERC-6551이 어떻게 작동하는지, 왜 중요한지, 보안 및 사용자 경험(UX) 측면에서 고려해야 할 사항은 무엇인지, 그리고 빌더와 사용자를 위한 실제 참조 자료를 제공합니다.

ERC-6551이란 무엇인가? (한 문장 요약)

ERC-6551은 스마트 계약 지갑을 ERC-721 NFT에 바인딩하는 레지스트리 및 계정 인터페이스를 정의하여, NFT가 인간 소유자와 독립적으로 토큰, NFT 및 권한을 보유하고 거래를 실행할 수 있도록 지원합니다. 동시에 제어권은 자동으로 해당 NFT의 현재 소유자를 따릅니다. 자세한 내용은 공식 EIP의 사양을 참조하십시오: EIP-6551: Token Bound Accounts.

구성 요소

• ERC-721 NFT: ERC-6551은 이더리움 및 EVM 체인의 표준 NFT인 ERC-721을 위해 설계되었습니다. ERC-721의 소유권 의미에 대한 복습이 필요하다면 이더리움 문서를 참조하십시오: ERC-721 Non‑Fungible Token Standard.
• 레지스트리: 단일 레지스트리 계약은 createAccount 및 account 함수를 노출하여 주어진 NFT(chainId, tokenContract, tokenId)에 대한 TBA의 주소를 배포하거나 계산합니다. CREATE2를 통해 결정론적 주소를 사용하므로, TBA는 배포되기 전에 미리 알 수 있습니다. 참조: EIP‑1014 (CREATE2).
• 계정: TBA는 ERC-6551 계정 인터페이스(예: executeCall, owner, isValidSignature)를 구현하는 스마트 지갑 계약입니다. ERC-20 토큰, 다른 NFT 및 메타데이터를 보유할 수 있습니다. 제어 확인은 현재 NFT 소유자에게 전달됩니다.

개발자 개요 및 예제: TokenBound documentation. 쉽게 이해할 수 있는 입문 자료로 Alchemy의 개요: What is ERC‑6551?와 thirdweb의 설명: ERC‑6551: Token Bound Accounts를 참조하십시오.

NFT가 지갑을 소유하는 방법 (메커니즘)

1. 주소 파생: TBA 주소는 chainId, NFT 계약, tokenId, 구현 계약, salt 및 CREATE2를 통해 결정론적으로 파생됩니다. 계정을 배포하지 않고도 주소를 계산할 수 있습니다.
2. 계정 배포: 필요할 때 레지스트리가 계정을 배포합니다. 이제 NFT의 신원은 스마트 계약 지갑을 갖게 됩니다.
3. 제어 흐름: 계정의 owner() 함수는 NFT의 현재 소유자를 읽습니다. NFT가 전송되면 TBA의 제어권은 자동으로 새로운 소유자를 따릅니다. 키나 서명을 이동할 필요가 없습니다.
4. 실행: 소유자(또는 허용된 운영자)는 executeCall을 트리거하여 DeFi와 상호 작용하거나, 자산을 민팅하거나, 인간의 외부 소유 계정(EOA) 대신 TBA 신원에서 권한을 관리할 수 있습니다.
5. 구성 가능성: TBA 자체는 ERC-20 토큰, 다른 ERC-721 토큰 및 온체인 권한을 보유할 수 있습니다. NFT는 자산과 기능의 자체 포함 "캡슐"이 됩니다.

왜 중요한가?

• 구성 가능한 아바타: 게임 캐릭터 NFT는 장비 NFT, 물약(ERC-20) 및 업적을 소유할 수 있습니다. 캐릭터를 거래하면 기본 토큰뿐만 아니라 전체 장비 세트가 함께 거래됩니다. 예제 아키텍처: TokenBound documentation.
• 이동 가능한 신원: 단일 NFT는 지갑 기록, 평판 배지 및 직접 소유하는 액세스 자격 증명을 가진 크로스-dApp 신원을 나타낼 수 있습니다.
• 유동적인 번들: 크리에이터는 단일 NFT를 전송하여 자산 컬렉션을 판매할 수 있습니다. 구매자는 TBA에 보유된 전체 재고를 받게 됩니다.
• 더 안전한 위임: 개인 EOA에서 위임하는 대신, 제어된 범위를 가진 NFT의 TBA에서 액세스를 위임할 수 있습니다.
• 계정 추상화 시너지: TBA는 세션 키 및 페이마스터와 같은 고급 흐름과 호환되는 스마트 계정으로 구현될 수 있습니다. 배경 정보는 EIP‑4337: Account Abstraction을 참조하십시오.

현재 생태계 신호

• 표준화: ERC-6551은 참조 레지스트리 및 계정 인터페이스와 함께 승인된 EIP로, 일관된 프로젝트 간 지원을 가능하게 합니다. 사양: EIP‑6551.
• 라이브러리 및 도구: TokenBound의 SDK와 레지스트리 주소는 dApp에 TBA 통합을 더 쉽게 만듭니다. 문서: TokenBound documentation.
• 개발자 교육: 주요 개발자 플랫폼은 이제 ERC-6551에 대한 가이드 및 템플릿을 제공하며, 이는 채택 및 실험 증가를 나타냅니다. 참조: Alchemy overview 및 thirdweb explainer.

대부분의 표준과 마찬가지로 지갑 및 마켓플레이스의 UI 지원은 체인 및 프로젝트에 따라 다릅니다. 2025년까지 게임, 소셜 프로토콜 및 NFT 인프라 제공업체가 네이티브 TBA 상호 작용을 추가함에 따라 지속적인 발전이 예상됩니다.

핵심 UX 패턴

• 인벤토리 NFT: 플레이어가 게임 내에서 획득한 아이템을 캐릭터의 TBA가 소유하도록 합니다. 캐릭터를 리스팅하면 전체 인벤토리가 전송됩니다.
• 권한 사전 설정: 개인 EOA에서의 글로벌 승인 대신, 원활한 게임 플레이 또는 소셜 액션을 위해 TBA에 세션 키 또는 범위가 지정된 위임자를 저장합니다.
• 점진적 공개: UI에서는 dApp과 상호 작용할 때 "NFT가 소유함"을 주요 행위자로 표시하여 사용자의 EOA와 NFT의 TBA 간의 혼란을 최소화합니다.
• 이동 가능한 번들: 안전과 유용성의 균형을 맞추기 위해 크리에이터가 정의한 정책으로 "콘텐츠와 함께 전송" 또는 "전송 시 콘텐츠 삭제"를 활성화합니다.

보안 모델 및 모범 사례

TBA는 구성 가능성을 향상시키지만 새로운 운영 위험을 초래합니다. 다음을 고려하십시오:

• 승인 이월: TBA에 미해결 승인(ERC-20 허용 또는 NFT 승인)이 있는 경우, NFT를 전송하면 해당 승인이 구매자에게 전달됩니다. 악의적인 지출자가 승인된 경우 위험할 수 있습니다. 더 안전한 패턴:
  • 전송 시 또는 판매 리스팅 시 허용 사항을 명확히 합니다.
  • 무제한 승인 대신 지출 한도를 사용합니다.
  • 전송 전 UI에 허용 경고를 표시합니다.
• 소유권 확인: 실행 시점에 현재 ERC-721 소유자에 대해 owner() 함수가 일관되게 적용되는지 확인합니다. 사양에 정의된 인터페이스를 따르십시오: EIP‑6551.
• 재현 공격 및 서명 범위: TBA가 오프체인 서명(isValidSignature)을 지원하는 경우, 체인 및 계약 간의 재현 공격을 방지합니다. 도메인 분리된 EIP-712 구조를 사용합니다.
• 업그레이드 가능성 위험: 업그레이드 가능한 TBA를 사용하는 경우, 관리자 및 업그레이드 로직을 보호합니다. 최소화되고 감사된 구현을 선호합니다.
• 복구 및 보호자: 소비자 사용 사례의 경우 TBA 수준 또는 제어 소유자 계정을 통해 백업 흐름(예: 소셜 복구)을 고려합니다.
• 마켓플레이스 조정: 콘텐츠가 가치에 중대한 영향을 미치는 경우, 마켓플레이스는 TBA 보유량 및 승인을 반영해야 합니다. 빌더는 인덱서를 통해 TBA 인벤토리를 노출할 수 있습니다.

구현 지침 및 보안 참고 사항은 공식 문서부터 시작하십시오: TokenBound documentation.

개발자 빠른 시작 (개념적)

• 레지스트리의 account 함수를 사용하여 주어진 NFT에 대한 TBA 주소를 계산합니다(결정론적, 배포 불필요).
• TBA가 처음으로 작동해야 할 때 createAccount를 통해 배포합니다.
• 다음을 위한 사용자 흐름을 구현합니다:
  • TBA 주소로 ERC-20 및 ERC-721 토큰을 보냅니다.
  • dApp 작업을 위해 TBA에서 범위가 지정된 운영자에게 승인을 부여합니다.
  • TBA의 executeCall을 통해 dApp 호출을 실행합니다.
• 선택 사항: 가스 후원 및 세션 키를 위해 계정 추상화 기능을 사용합니다. 배경: EIP‑4337.

멀티체인 및 가스 고려 사항

• 체인별 계정: 체인 A의 동일한 NFT와 체인 B의 브릿징된 표현은 서로 다른 TBA를 갖게 됩니다. UI에 체인 컨텍스트를 레이블링하여 크로스체인 혼란을 피하십시오.
• 가스 경제: TBA는 스마트 계정이므로, 배포 및 실행 비용이 간단한 EOA보다 가스 비용이 더 많이 듭니다. 적절한 경우 페이마스터 또는 메타 트랜잭션을 사용하여 사용자에게 가스를 추상화합니다. 후원 트랜잭션 패턴은 EIP‑4337을 참조하십시오.
• 사전 계산: CREATE2의 결정론 덕분에 dApp은 배포 전에 TBA 주소를 참조하고 미리 자금을 지원하거나 허용 사항을 설정할 수 있습니다. 참조: EIP‑1014.

ERC-6551을 사용해야 하는 경우

NFT 자체가 행위자 또는 자산 컨테이너 역할을 해야 하는 경우 TBA를 사용하십시오:

• 게임 신원 및 장비 구성
• 자격 증명 및 할당량이 있는 멤버십 NFT
• 크리에이터 번들 및 큐레이션된 컬렉션
• 평판 배지가 있는 소셜 신원

거래하거나 추가 자산을 보유할 필요가 없는 단순한 수집품의 경우, 또는 사용자 복잡성이 이점을 능가하는 경우에는 TBA 사용을 피하십시오.

OneKey가 NFT 소유 지갑에 어떻게 적용되는가?

궁극적으로 TBA를 제어하는 것은 기본 NFT를 소유한 계정의 보안에 달려 있습니다. EOA가 침해되면 NFT, 따라서 TBA의 제어권도 위험에 처하게 됩니다. 하드웨어 지갑은 개인 키를 오프라인으로 유지하여 이를 완화하는 데 도움이 됩니다.

OneKey는 강력한 보안과 오픈 소스 투명성을 유지하면서 멀티체인, 고빈도 Web3 사용을 위해 설계되었습니다. ERC-6551 흐름의 경우 OneKey는 다음을 수행할 수 있습니다:

• NFT를 소유하고 전송하는 EOA를 안전하게 보호하여 TBA 제어가 사용자의 손에 있도록 합니다.
• TBA를 통합하는 dApp을 위해 EIP-712 메시지 및 스마트 계정 트랜잭션을 깔끔하게 서명합니다.
• TBA가 체인별로 존재하므로 중요한 이더리움 및 EVM 생태계 전반에 걸쳐 일관되고 멀티체인 환경을 제공합니다.

NFT를 온체인 인벤토리 및 승인을 가진 활성 신원으로 사용하려는 경우, 하드웨어 지갑인 OneKey에 소유권을 고정하면 핫 월렛 침해로 인한 TBA 제어권 탈취 가능성을 줄일 수 있습니다.

결론

ERC-6551은 NFT를 자체 지갑을 가진 1급 온체인 행위자로 전환하여, 구성 가능한 게임 캐릭터, 이동 가능한 신원 번들, 그리고 더 안전하고 범위가 지정된 위임을 가능하게 합니다. 이 표준의 레지스트리 및 계정 인터페이스는 빌더가 TBA 지원을 쉽게 추가할 수 있도록 하는 동시에 사용자는 NFT에서 더 풍부한 유틸리티를 얻을 수 있습니다. 2025년에 채택이 증가함에 따라 승인, 마켓플레이스 UX 및 계정 추상화 통합에 주의를 기울이십시오.

안전하게 참여하려면, TBA의 기반이 되는 NFT를 제어하는 강력한 하드웨어 지갑을 사용하십시오. OneKey는 이 새로운 프론티어를 탐색하는 동안 NFT 소유 지갑을 안전하게 유지하는 보안과 사용성의 조합을 제공합니다.