Add ERC-7921: Data Asset NFT

ERCS/erc-7921.md

@@ -0,0 +1,135 @@
+---
+eip: 7921
+title: Data Asset NFT
+description: Bring Data Assets to NFTs and ensure the integrity of data asset NFTs through storage proof
+author: Allen Dong (@Allen2730), Lonika Zhang ([email protected]), Steven He ([email protected])
+discussions-to: https://ethereum-magicians.org/t/erc-7921-data-asset-nft/21881
+status: Draft
+type: Standards Track
+category: ERC
+created: 2024-11-29
+requires: 165, 721
+---
+
+## Abstract
+
+This proposal is an extension of [ERC-721](./erc-721.md). This proposal introduces a new role, Reader, who is granted by the Owner and allows multiple Readers for a single NFT. Additionally, this proposal extends the metadata interface of ERC-721, requiring that metadata should include at least a commitment, size, expire, and uploader's address. This proposal also proposes a storage proof mechanism to ensure the correctness of metadata information.
+
+## Motivation
+
+ERC-721 proposed the NFTs to represent the ownership of digital or physical assets. Currently, the NFT metadata is considered the NFT content, and its scarcity determines the value of the NFT. NFT owners can convert the content value of NFTs into revenue by transferring the ownership of NFTs. However, due to the high transaction fees, storage costs, and other expenses, NFTs are currently only able to represent the ownership of high-value assets, which limits the range of assets that NFTs can represent. This is especially true for data assets, where the content value of data assets varies greatly.
+
+Furthermore, to reduce storage costs, the NFT content is generally stored off-chain (IPFS, S3) or cross-chain storage (Arweave), and the link of NFT content is saved on-chain. Off-chain users can access the NFT content by visiting the link. However, on-chain contracts can not access the link to determine the status of the data, such as data loss, data tampering, or data expiration. These situations can lead to the data deviating from its actual value, but the NFT still exists on the chain, and the underlying copyright is still being sold in the market.
+
+This proposal introduces Data Asset NFTs, which solve the dilemma of on-chain data assets by combining a modular data layer--DA (Data Availability).
+
+## Specification
+
+### Terms
+
+In this proposal, we divide data assets into three parts:
+
+- Storage Metadata: Includes commitment, size, expire, and uploader's address. Stored and maintained by storage contracts on the blockchain.
+- Permission Metadata: Includes information on ownership and reading rights, as well as which addresses can modify this information. Stored and maintained by permission contracts on the blockchain.
+- Data Content: Data uploaded by users to the storage system. Data content is stored in off-chain storage nodes.
+
+The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
+
+### Every compliant data permission contract must implement the Interface
+
+The data permission contract is an extension of ERC-721, adding the reader role, where a single data asset can correspond to multiple readers.
+
+```solidity
+interface IERC3130 is IERC721 {
+    event UpdateReader(uint256 indexed tokenId, address indexed reader, bool valiad);
+    
+    function setReader(uint256 tokenId, address reader, bool valiad) external;
+    
+    function isReader(uint256 tokenId, address reader) external view returns (bool);
+    
+    function commitByTokenId(uint256 tokenId) external view returns (bytes);
+    
+    function sizeByTokenId(uint256 tokenId) external view returns (uint256);
+    
+    function expireByTokenId(uint256 tokenId) external view returns (uint64);
+}
+```
+
+The metadata schema for Data Asset NFTs is as follows:
+
+```json
+{
+  "title": "Data Asset Metadata",
+  "type": "object",
+  "properties": {
+    "name": {
+      "type": "string",
+      "description": "Identifies the asset to which this NFT represents"
+    },
+    "description": {
+      "type": "string",
+      "description": "Describes the asset to which this NFT represents"
+    },
+    "commit": {
+      "type": "string",
+      "description": "A commit pointing to the data resource"
+    },
+    "size": {
+        "type": "integer",
+        "description": "The size of the data resource"
+    },
+    "expire": {
+        "type": "integer",
+        "description": "The expire time of the data resource",
+    }
+  }
+}
+```
+
+The Reader role should not involve changes in permissions, meaning that Readers cannot call functions such as Transfer, Approve, and SetReader.
+
+When Alice calls the Transfer function to transfer one of Alice's Data Asset NFTs to Bob:
+
+- The owner address is set to Bob's address;
+- The approved address is set to 0.
+- However, all readers are retained.
+
+### Extension: Storage Contract
+
+This proposal extends the metadata information of NFTs. Metadata information is uploaded by users and requires relevant certificates, which can be the storage node's signature on the NFT's metadata information. This proposal specify that the NFT metadata should at least include commitment, size, expire, and uploader's address.
+
+The implementer of this proposal selects a trusted storage system and a trusted modular data layer DA, or deploys the modular storage layer DA themselves.
+
+When the Owner or Approved Operator calls the transfer, approve, or setReader functions, they must additionally check whether the current time `block.timestamp` is greater than the expiration time `expire` before making the call. If the current time `block.timestamp` is less than the expiration time `expire`, then proceed with subsequent operations; if the current time `block.timestamp` is greater than the expiration time `expire`, then interrupt subsequent operations and return an exception message.
+
+### Extension: Storage Proof
+
+This proposal uses storage proof to prove the availability of data content, thereby proving the correctness of NFT metadata, especially the `expire` of the NFT.
+
+This proposal does not limit the proof scheme used, but recommends the use of KZG polynomial commitment technology. KZG polynomial commitment technology can generate two generator elements $g_1$ and $g_2$ during initialization. It also generates a corresponding commitment C based on the data contentand uploads it as the unique identifier of the data when uploading metadata. When generating proof, the verifier generates a random number $z$, and the prover generates proof $P=(y, π)$ based on the data content and random number $z$, verifying $e(π, yg_1-zg_2) = e(C - y*g_1, g_2)$.
+
+In addition, KZG polynomial commitment technology can aggregate multiple proofs into a single proof, and two-step verification can verify the correctness of all proofs, including summing all commitments to get the aggregated commitment $C_n$, and verifying the aggregated proof $P_n=(y_n, π_n)$ by verifying $e(π_n, y_ng_1-zg_2) = e(C_n - y_n*g_1, g_2)$.
+
+To avoid long proof generation times, random sampling can be used to randomly select data to be challenged. Therefore, the contract needs to provide a secure pseudo-random number generation function for randomly selecting challenged data, which can also be used as the random number $z$ for KZG.
+
+During the verification process, summing all commitments to get the aggregated commitment requires a large amount of gas fees. This proposal recommends using optimistic proof, which assumes that the aggregated commitment is correct and only verifies $e(π_n, y_ng_1-zg_2) = e(C_n - y_n*g_1, g_2)$ during verification. After verifying the aggregated proof, the availability of the data cannot be proven, so a certain period of challenging is required. During the challenging period, anyone can challenge the commitment proof $C_n$. If the challenge is successful, the challenger gets a reward and the prover is punished; if the challenge fails, the challenger is punished and the prover gets additional benefits.
+
+## Rationale
+
+![arc](../assets/erc-7921/erc-architect.png)
+
+The biggest challenge for data asset NFTs is the visibility but inaccessibility of data content: after establishing access control permissions for NFT data content, i.e., accessing data content requires certain access permissions, how can users without data access permissions ensure that the data content exists when obtaining access permissions? To prevent users from making incorrect operations unknowingly, it is necessary to upload information about the data content to the chain, specifically, the expire of the data content should be uploaded to the chain. Users can access the expire of the data content to judge whether their NFT is valid and make corresponding decisions.
+
+Although storage nodes promise to consistently save data within the expire time, in an untrusted environment, storage nodes may delete data content within the expire time. Therefore, storage nodes need to regularly submit storage proof within the expire time to ensure the correctness of the expire time. This ensures that users in an untrusted environment can obtain basic information about resources that are restricted from access.
+
+## Backwards Compatibility
+
+This proposal combines the existing 721 extension and is backward compatible with the ERC-721 standard.
+
+## Security Considerations
+
+The security of Data Asset NFTs depends not only on the blockchain but also on the modular data layer DA. Therefore, the implementer of this proposal needs to carefully select the modular data layer DA.
+
+## Copyright
+
+Copyright and related rights waived via CC0.