Smart NFT - A Component for Intent-Centric

Abstract

Smart NFT is the fusion of Smart Contract and NFT. An NFT with the logic of a Smart Contract can be executed, enabling on-chain interactions. Transitioning from an NFT to a Smart NFT is akin to going from a regular landline telephone to a smartphone, opening up broader and more intelligent possibilities for NFTs.

Motivation

Ethereum introduces smart contracts revolutionized the blockchain and paved the way for the flourishing ecosystem of decentralized applications (dApps). Also, the concept of non-fungible tokens (NFTs) was introduced through ERC-721, offering a paradigm for ownership verification.

However, smart contracts still present significant barriers for most users, and NFTs have largely been limited to repetitive explorations within Art, Gaming, and Real-World Assets realm.

The widespread adoption of smart contracts and the functional applications of NFTs still face substantial challenges. Here are some facts that emerges from this contradiction:

1. The strong desire for both intelligence and usability has led users to sacrifice security (sharing their private key with BOTs)
2. For individual developers, the process of turning functionalities into market-ready products is hindered by a lack of sufficient resources.
3. In the context of a “Code is Law” philosophy, there is a lack of on-chain infrastructure for securely transferring ownership of smart contracts/code.

Usability with Security

IA-NFT acts as a key of a smart contract. With no private key, no risk of private key leakage.

IA-NFT as Native On-chain Asset

For years, NFT stands for the ownership of a picture, a piece of artwork, a game item, a real-world asset. All these backed assets are in fact not crypto native. IA-NFT verify the ownership of a piece of code or a smart contract.

Interaction Abstraction for the Intent Abstraction

The on-chain interaction can be abstract to many functional module IA-NFTs and thus make the Interaction process more effective. Users can focus more on their intent rather than how to operate cross different dApps.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Overview

The following section will define the interface specifications for three main objects: Smart-NFT, Smart-Manager, Intent-Proxy, and establish the interaction relationships between three primary roles (developer, verifier, user) and these objects.

Smart-NFT Interface

Before sending a registration request to Smart-Manager, developers should implement the following two core interfaces in Smart-NFT.

• execute: This function MUST contain only one parameter of the “bytes” type, which encapsulates the required parameters for a specific Smart-NFT. Additionally, MUST call validatePermission during the implementation to determine if this call is legitimate.

• validatePermission: This function is used to query the Smart-Manager to determine whether the Smart-NFT has been successfully verified and is callable by the caller.

interface ISmartNFT {
  function execute(bytes memory data) external payable returns (bool);

  function validatePermission() external view returns (bool);
}

Smart-Manager Interface

The Smart-Manager interface defines 5 possible states for Smart-NFTs:：

• UNREGISTERED: Refers to Smart-NFTs that have not been registered with the Smart-Manager.
• DEREGISTERED: Denotes Smart-NFTs that were previously registered but have been removed or deregistered from the Smart-Manager.
• UNVERIFIED: Signifies Smart-NFTs that have been registered with the Smart-Manager but have not yet undergone the verification process.
• VERIFIED: Represents Smart-NFTs that have been registered with the Smart-Manager and have successfully passed the verification process, indicating they are safe to use.
• DENIED: Refers to Smart-NFTs that have been registered but failed the verification process, indicating they should not be used as they may pose security risks.

Smart-Manager should be implemented with the following thress core interfaces.

• register: Developers can initiate a registration request for a Smart-NFT through this interface and provide the Smart-NFT’s creation code. Upon successful request, the Smart-NFT MUST be marked as UNVERIFIED.

• auditTo: Should only let trusted verifiers use this interface to audit a Smart-NFT to change its status to Verified or Denied.

• isAccessible: This interface is used to ascertain whether a user can use a specific Smart-NFT. The determination MUST involves considering both the ownership of the corresponding tokenId NFT and whether the Smart-NFT has been successfully verified.

• verificationStatusOf: The function MUST returns the current verification stage of the specified Smart-NFT.

Additionally, the implementation of Smart-Manager SHOULD inherit from ERC-1155.

interface ISmartManager {
  enum VerificationStatus {
      UNREGISTERED,
      DEREGISTERED,
      UNVERIFIED,
      VERIFIED,
      DENIED
  }

  function register(
      bytes calldata creationCode,
      uint256 totalSupply
  ) external returns (uint256 tokenId, address implAddr);

  function auditTo(uint256 tokenId, bool isValid) external returns (bool);

  function isAccessible(
      address caller,
      uint256 tokenId
  ) external view returns (bool);

  function verificationStatusOf(
      uint256 tokenId
  ) external view returns (VerificationStatus);
}

Intent-Proxy Interface

Intent-Proxy interface defines an Action struct:

Intent-Proxy should be implemented with executeIntent.

• executeIntent: Users can achieve batch use of specified Smart-NFTs by calling this interface and providing an array of desired actions.

interface IIntentProxy {
  struct Action {
      uint256 tokenId;
      bytes executeParam;
  }

  function executeIntent(
      Action[] calldata actions
  ) external payable returns (bool);
}

Rationale

Why using ERC-1155

In the technical implementation aspect, we chose to use ERC-1155 as the main contract for NFTs due to the consideration of increasing the reusability of Smart-NFTs. The reason for this choice is that both ERC-721 and ERC-1155 are based on the concept of “token IDs” that point to NFTs. The key difference is that ERC-1155 introduces the concept of “shares,” meaning that having at least one share gives you the right to use the functionality of that Smart-NFT. This concept can be likened to owning multiple smartphones of the same model, where owning several smartphones doesn’t grant you additional features; you can only use the features of each individual device.

Another reason for directly using ERC-1155 instead of defining a new NFT standard is the seamless integration of Smart-NFT transaction behavior into the existing market. This approach benefits both developers and users, as it simplifies the adoption of Smart-NFTs into the current ecosystem.

Verifier

In this protocol, Verifiers play a crucial role, responsible for auditing and verifying Smart-NFT code. However, decentralized Verifiers face some highly challenging issues, with one of the primary concerns being the specialized expertise required for their role, which is not easily accessible to the general population.

First, let’s clarify the responsibilities of Verifiers, which include assessing the security, functionality, and compliance of smart contract code. This work demands professional programming skills, blockchain technology knowledge, and contract expertise. Verifiers must ensure the absence of vulnerabilities in the code.

Secondly, decentralized Verifiers encounter challenges related to authority and credibility. In a centralized model, we can trust a specific auditing organization or expert to perform this task. However, in a decentralized environment, it becomes difficult to determine the expertise and integrity of Verifiers. This could potentially lead to incorrect audits and might even be abused to undermine overall stability and reliability.

Lastly, achieving decentralized Verifiers also requires addressing coordination and management issues. In a centralized model, the responsibilities of managing and supervising Verifiers are relatively straightforward. However, in a decentralized environment, coordinating the work of various Verifiers and ensuring consistency in their audits across different contracts and code become significant challenges.

Copyright infringement issue

Code plagiarism has always been a topic of concern, but often, such discussions seem unnecessary. We present two key points: first, overly simple code has no value, making discussions about plagiarism irrelevant. Secondly, when code is complex enough or creative, legal protection can be obtained through open-source licenses (OSI).

The first point is that for overly simple code, plagiarism is almost meaningless. For example, consider a very basic “Hello World” program. Such code is so simple that almost anyone can independently create it. Discussing plagiarism of such code is a waste of time and resources because it lacks sufficient innovation or value and does not require legal protection.

The second point is that when code is complex enough or creative, open-source licenses (OSI) provide legal protection for software developers. Open-source licenses are a way for developers to share their code and specify terms of use. For example, the GNU General Public License (GPL) and the Massachusetts Institute of Technology (MIT) license are common open-source licenses that ensure the original code’s creators can retain their intellectual property rights while allowing others to use and modify the code. This approach protects complex and valuable code while promoting innovation and sharing.

Backwards Compatibility

This proposal aims to ensure the highest possible compatibility with the existing ERC-1155 protocol. All functionalities present in ERC-1155, including ERC-165 detection and Smart-NFT support, are retained. This encompasses compatibility with current NFT trading platforms.

For all Smart-NFTs, this proposla only mandates the provision of the execute function. This means that existing proxy contracts need to focus solely on this interface, making integration of Smart-NFTs more straightforward and streamlined.

Reference Implementation

See https://github.com/TsengMJ/EIP-7513_Example

Security Considerations

Malicious Validator

All activities involving human intervention inherently carry the risk of malicious behavior. In this protocol, during the verification phase of Smart-NFTs, external validators provide guarantees. However, this structure raises concerns about the possibility of malicious validators intentionally endorsing Malicious Smart-NFTs. To mitigate this risk, it’s necessary to implement stricter validation mechanisms, filtering of validators, punitive measures, or even more stringent consensus standards.

Unexpected Verification Error

Apart from the issue of Malicious Validators, there’s the possibility of missed detection during the verification phase due to factors like overly complex Smart-NFT implementations or vulnerabilities in the Solidity compiler. This issue can only be addressed by employing additional tools to assist in contract auditing or by implementing multiple validator audits for the auditTo interface to reduce the likelihood of its occurrence.

Copyright

Copyright and related rights waived via CC0.