ERC-7593: NFT synthetic evidence

,

eip: 7593
title: NFT synthetic evidence
description: Based on the ERC-721 and combines multiple pieces of evidence generated on the blockchain to create a synthetic evidence.
author: Pin Yang Chen (@YangIsCoding) allanustw@gmail.com
discussions-to: ERC-7593: NFT synthetic evidence
status: Draft
type: Standards Track
category: ERC
created: 2023-12-29
requires: 721

Abstract

We are looking to establish a proof on Ethereum based on ERC-721, which demonstrates certain digital asset permissions. The holder of these permissions can use a new function, share(), to share this proof. After using share(), the original NFT owner does not lose their permissions. The shared party will receive a new NFT token with a TokenID incremented by 1, but all other parameters remain the same. Therefore, I would like to propose a new Ethereum proposal to develop such a function.

Specification

The Standard defines a set of operations for minting, sharing, and managing NFTs that represent reports generated. Each report NFT MUST contain metadata detailing the report’s name, the starting time point of the report, and the ending time point of the report, following the structure defined in the IERC_7593 interface. The minting function SHALL create a new NFT and assign it a unique token ID, ensuring each report is technically distinct. Although the content (metadata) of each report may be the same, when the share() function is used to share a report, the system will copy the report’s metadata to the target address, and the newly minted NFT will have a new, incremented token ID, thus maintaining the uniqueness of each NFT. Sharing of report NFTs SHALL be facilitated through a dedicated function, allowing transfer to specified addresses while maintaining traceability. Implementations of this standard MUST be compliant with the ERC-721 protocol to ensure interoperability across different platform. This specification RECOMMENDS implementing additional security measures to prevent unauthorized access and modifications to the report NFTs.

This interface is designed to unify Block Evidence Standard for Enhanced Data Integrity and Verifiability. We have designed a blockchain evidence format that is tamper-proof, privacy-preserving, selectively authorized, and shareable. This format is based on the ERC-721 standard and combines multiple pieces of evidence generated on the blockchain to create a synthetic evidence standard.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

interface IERC_ISUNCLOUD {

     struct Report {
        string name;
        uint256 startTime;
        uint256 endTime;
    }

    event ReportNFTMinted(address indexed recipient,uint256 indexed newItemId, int256 indexed _ispublic,string reportName, uint256 startTime, uint256 endTime , address creator);
    event Approval(address indexed owner, address indexed approved, uint256 indexed tokenId);
    event ApprovalForAll(address indexed owner, address indexed operator, bool approved);
    event Transfer(address indexed from, address indexed to, uint256 indexed tokenId);
    event ReportNFTShared(address indexed from, address indexed to, uint256 indexed tokenId);


    error ERC721InvalidOwner(address owner);
    error ERC721InvalidReceiver(address receiver);
    error ERC721InvalidSender(address sender);
    error ERC721IncorrectOwner(address owner, uint256 tokenId, address previousOwner);
    error ERC721InvalidApprover(address approver);
    error ERC721NonexistentToken(uint256 tokenId);
    error ERC721InvalidOperator(address operator);
    error ERC721InsufficientApproval(address spender, uint256 tokenId);

    //Info: (20231229 - Yang){ supportsInterface(bytes4 interfaceId) is a function that is based on ERC165.}
    //Info: (20231229 - Yang){ Checks if the contract supports a specific interface.}
    function supportsInterface(bytes4 interfaceId) external view returns (bool);

    //Info: (20231229 - Yang){ the following functions are based on by ERC721.}
    //Info: (20231229 - Yang){ Returns the name of the token.}
    function name() external view returns (string memory);
    //Info: (20231229 - Yang){ Returns the symbol of the token, usually a shorter version of the name.}
    function symbol() external view returns (string memory);
    //Info: (20231229 - Yang){ Returns the number of tokens owned by a given address.}
    function balanceOf(address tokenOwner) external view returns (uint256);
    //Info: (20231229 - Yang){ Returns the URI for a given token ID, usually pointing to a JSON file containing the token's metadata.}
    function tokenURI(uint256 tokenId) external view returns (string memory);
    //Info: (20231229 - Yang){ Safely transfers a token from one address to another.}
    function safeTransferFrom(address from, address to, uint256 tokenId) external;
    //Info: (20231229 - Yang){ Safely transfers a token from one address to another, and includes an additional data parameter}
    function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory data) external;
    //Info: (20231229 - Yang){ Returns the owner address of a given token ID.}
    function ownerOf(uint256 tokenId) external view returns (address);
    //Info: (20231229 - Yang){ Returns the owner address of the contract.}
    function owner() external view returns (address);
    //Info: (20231229 - Yang){ Approves a given address to manage a specific token ID.}
    function approve(address to, uint256 tokenId) external;

    //Info: (20231229 - Yang){ The following functions are created originally by isuncloud.}
    //Info: (20231229 - Yang){ Shares a report by minting a new token for a specified wallet address.}
    function share(uint256 tokenId, address targetWallet) external returns (uint256);
    //Info: (20231229 - Yang){ Returns the report data for a given token ID.}
    function getReportData(uint256 tokenId) external view returns (Report memory);
    //Info: (20231229 - Yang){ Returns the latest token ID.}
    function getLatestTokenID() external view returns (uint256);
    //Info: (20231229 - Yang){ Mints a new report NFT and assigns it to the specified recipient.}
    function mintReportNFT(address recipient, uint256 startTime, uint256 endTime, string memory reportName,int256 _ispublic) external returns (uint256);


}

Rationale

The rationale Report NFT Standard is to leverage the unique capabilities of blockchain technology, specifically NFTs, to enhance the security, authenticity, and traceability of audit reports. By encoding these reports as NFTs, each document is given a distinct, immutable identity on the blockchain, ensuring its authenticity and preventing tampering. The ability to share these NFTs securely through a dedicated function addresses the need for controlled yet flexible distribution of sensitive audit information. Adhering to the ERC-721 standard ensures interoperability across various platforms, making the system versatile and accessible. This approach represents a significant advancement in maintaining the integrity and trustworthiness of audit documents in the renewable energy sector.

Taking the accounting system as an example (though it can also be applied to legal, medical data, and other fields), each transaction recorded on the blockchain can be considered as a piece of small evidence. The reports generated from these transactions after calculations represent larger evidence. When we want to consolidate these pieces of small evidence into a larger one for the purpose of controlling access, we need a mechanism to accomplish this. This larger evidence is minted in the form of an NFT, and only the person who owns this NFT can view the content of the entire report. Such a mechanism can be utilized in various fields, making this standard capable of facilitating such functionality.

Security Considerations

In considering the security aspects of the Report NFT Standard, it’s crucial to address potential risks associated with the handling and storage of sensitive audit report data on the blockchain. The immutable nature of NFTs ensures that once a report is minted, its content cannot be altered, which is vital for maintaining the integrity of the audit information. However, this also means that any errors in the report prior to minting become permanent. Furthermore, smart contract vulnerabilities must be rigorously tested and mitigated to prevent exploits that could lead to unauthorized access or manipulation of NFTs. Adequate measures for access control and authentication are essential to ensure that only authorized parties can mint, share, or transfer report NFTs. The implementation should also consider privacy concerns, as blockchain transactions are typically public, which could lead to unintended exposure of sensitive information.

Copyright

Copyright and related rights waived via CC0.

PR here
Please follow this pr to get the latest version ; )

1 Like

Hey Yang:

I like the idea here, but what I don’t understand is why this has to be specified in public – could this just be a smart contract you use for one project and standardize it later when there are, say, two similar products that would gain from cross-interoperability? I recommend a “## Rationale” section that doesn’t just explain the rational for this thing existing, but also the rational for it being standardized now as an EIP.

2 Likes

Dear bumblefudge:

Thank you for your suggestion! I’ll work on that.

Dear bumblefudge:

Taking the accounting system as an example (though it can also be applied to legal, medical data, and other fields), each transaction recorded on the blockchain can be considered as a piece of small evidence. The reports generated from these transactions after calculations represent larger evidence. When we want to consolidate these pieces of small evidence into a larger one for the purpose of controlling access, we need a mechanism to accomplish this. This larger evidence is minted in the form of an NFT, and only the person who owns this NFT can view the content of the entire report. Such a mechanism can be utilized in various fields, making this standard capable of facilitating such functionality.

I added a paragraph mentioned above. once again, thank you for your suggestion.

1 Like