-
Notifications
You must be signed in to change notification settings - Fork 330
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
90 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,90 @@ | ||
--- | ||
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: https://ethereum-magicians.org/t/add-erc-erc-8017/17986 | ||
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](./eip-721.md), 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, [EIP-8017](./eip-8017.md), 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_8017 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](./eip-721.md) protocol to ensure interoperability across different platform. This specification RECOMMENDS implementing additional security measures to prevent unauthorized access and modifications to the report NFTs. | ||
|
||
To realize the following interface, you have to implement the ReportNFT smart contract. | ||
|
||
```solidity | ||
// SPDX-License-Identifier: MIT | ||
pragma solidity ^0.8.0; | ||
interface IERC_8017 { | ||
struct Report { | ||
string name; | ||
uint256 startTime; | ||
uint256 endTime; | ||
} | ||
event ReportNFTMinted(address indexed recipient, uint256 indexed newItemId, string reportName, uint256 startTime, uint256 endTime); | ||
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.} | ||
//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) 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](./eip-721.md) 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. | ||
|
||
## 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](../LICENSE.md). |