forked from ethereum/ERCs
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Update ERC-7007: Move to Review (ethereum#209)
* Update erc-7007.md to add opML compatibility (#1) * Update erc-7007.md to add opML compatibility * Update erc-7007.md param name * Create IOpmlLib.sol * Update and rename ERC7007.sol to ERC7007_zkml.sol * Update IOpmlLib.sol * Update IOpmlLib.sol * Update IOpmlLib.sol * Create ERC7007_opml.sol * Update ERC7007_opml.sol * Update IOpmlLib.sol * feat: update implementation to include owner address * feat: update authorship, added Updatable extension, update metadata with `proof_type` * fix: full term before abbreviation * feat: Update ERC7007 contracts and add IERC7007Updatable interface * feat: Add rationale and security considerations * feat: `update` function to use `verify` in `require` statement * misc: capitalization * xhyu patch 1 (#2) * misc: improve abstract & motivation * fix: Spec intro & Model Publication wording * fix: Rewrite part of motivation * corrected some small typos * rewrote the last two paragraphs in Motivation --------- Co-authored-by: drCathieSo.eth <[email protected]> * fix: proposal reference and header * fix: file references * Update erc-7007.md: Fix wordings (#4) * Update erc-7007.md: Fix wordings * update license * Update description and motivation -> rationale --------- Co-authored-by: drCathieSo.eth <[email protected]> * Add workflow (#5) * Add workflow diagram * Add workflow description * Apply suggestions from code review Co-authored-by: Sam Wilson <[email protected]> * Update erc-7007.md * Fix uppercase keywords * Update erc-7007.md --------- Co-authored-by: 李婷婷 Lee Ting Ting <[email protected]> Co-authored-by: xhyumiracle <[email protected]> Co-authored-by: Sam Wilson <[email protected]>
- Loading branch information
4 people
authored
Mar 5, 2024
1 parent
29cf2b0
commit 479ad98
Showing
13 changed files
with
407 additions
and
54 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 |
|---|---|---|
| @@ -1,10 +1,10 @@ | ||
| --- | ||
| eip: 7007 | ||
| title: Zero-Knowledge AI-Generated Content Token | ||
| description: An ERC-721 extension interface for zkML based AIGC-NFTs. | ||
| author: Cathie So (@socathie), Xiaohang Yu (@xhyumiracle), Huaizhe Xu (@HuaizheXu), Kartin <[email protected]> | ||
| title: Verifiable AI-Generated Content Token | ||
| description: An ERC-721 extension for verifiable AI-generated content tokens using Zero-Knowledge and Optimistic Machine Learning techniques | ||
| author: Cathie So (@socathie), Xiaohang Yu (@xhyumiracle), Conway (@0x1cc), Lee Ting Ting (@tina1998612), Kartin <[email protected]> | ||
| discussions-to: https://ethereum-magicians.org/t/eip-7007-zkml-aigc-nfts-an-erc-721-extension-interface-for-zkml-based-aigc-nfts/14216 | ||
| status: Draft | ||
| status: Review | ||
| type: Standards Track | ||
| category: ERC | ||
| created: 2023-05-10 | ||
|
|
@@ -13,23 +13,39 @@ requires: 165, 721 | |
|
|
||
| ## Abstract | ||
|
|
||
| The Zero-Knowledge Machine Lerning (zkML) AI-Generated Content (AIGC) non-fungible token (NFT) standard is an extension of the [ERC-721](./eip-721.md) token standard for AIGC. It proposes a set of interfaces for basic interactions and enumerable interactions for AIGC-NFTs. The standard includes a new mint event and a JSON schema for AIGC-NFT metadata. Additionally, it incorporates zkML capabilities to enable verification of AIGC-NFT ownership. In this standard, the `tokenId` is indexed by the `prompt`. | ||
| The verifiable AI-generated content (AIGC) non-fungible token (NFT) standard is an extension of the [ERC-721](./eip-721.md) token standard for AIGC. It proposes a set of interfaces for basic interactions and enumerable interactions for AIGC-NFTs. The standard includes a `mint` and `verify` function interface, a new `Mint` event, optional `Enumerable` and `Updatable` extensions, and a JSON schema for AIGC-NFT metadata. Additionally, it incorporates Zero-Knowledge Machine Learning (zkML) and Optimistic Machine Learning (opML) capabilities to enable verification of AIGC data correctness. In this standard, the `tokenId` is indexed by the `prompt`. | ||
|
|
||
| ## Motivation | ||
|
|
||
| The zkML AIGC-NFTs standard aims to extend the existing [ERC-721](./eip-721.md) token standard to accommodate the unique requirements of AI-Generated Content NFTs representing models in a collection. This standard provides interfaces to use zkML to verify whether or not the AIGC data for an NFT is generated from a certain ML model with certain input (prompt). The proposed interfaces allow for additional functionality related to minting, verifying, and enumerating AIGC-NFTs. Additionally, the metadata schema provides a structured format for storing information related to AIGC-NFTs, such as the prompt used to generate the content and the proof of ownership. | ||
| The verifiable AIGC-NFT standard aims to extend the existing [ERC-721](./eip-721.md) token standard to accommodate the unique requirements of AI-generated content NFTs representing models in a collection. This standard provides interfaces to use zkML or opML to verify whether or not the AIGC data for an NFT is generated from a certain ML model with a certain input (prompt). The proposed interfaces allow for additional functionality related to minting, verifying, and enumerating AIGC-NFTs. Additionally, the metadata schema provides a structured format for storing information related to AIGC-NFTs, such as the prompt used to generate the content and the proof of ownership. | ||
|
|
||
| With this standard, model owners can publish their trained model and its ZKP verifier to Ethereum. Any user can claim an input (prompt) and publish the inference task, any node that maintains the model and the proving circuit can perform the inference and proving, then submit the output of inference and the ZK proof for the inference trace into the verifier that is deployed by the model owner. The user that initiates the inference task will own the output for the inference of that model and input (prompt). | ||
| This standard supports two primary types of proofs: validity proofs and fraud proofs. In practice, zkML and opML are commonly employed as the prevailing instances for these types of proofs. Developers can choose their preferred ones. | ||
|
|
||
| In the zkML scenario, this standard enables model owners to publish their trained model and its ZKP verifier to Ethereum. Any user can claim an input (prompt) and publish the inference task. Any node that maintains the model and the proving circuit can perform the inference and proving, and submit the output of inference and the ZK proof for the inference trace to the verifier. The user that initiates the inference task will own the output for the inference of that model and input (prompt). | ||
|
|
||
| In the opML scenario, this standard enables model owners to publish their trained model to Ethereum. Any user can claim an input (prompt) and publish the inference task. Any node that maintains the model can perform the inference and submit the inference output. Other nodes can challenge this result within a predefined challenge period. At the end of the challenge period, the user can verify that they own the output for the inference of that model and prompt. | ||
|
|
||
| This capability is especially beneficial for AI model authors and AI content creators seeking to capitalize on their creations. With this standard, every input prompt and its resulting content can be securely verified on the blockchain. This opens up opportunities for implementing revenue-sharing mechanisms for all AI-generated content (AIGC) NFT sales. AI model authors can now share their models without concerns that open-sourcing will diminish their financial value. | ||
|
|
||
| An example workflow of a zkML AIGC NFT project compliant with this proposal is as follows: | ||
|
|
||
|  | ||
|
|
||
| There are 4 components in this workflow: | ||
| * ML model - contains weights of a pre-trained model; given an inference input, generates the output | ||
| * zkML prover - given an inference task with input and output, generates a ZK proof | ||
| * AIGC-NFT smart contract - contract compliant with this proposal, with full [ERC-721](./eip-721.md) functionalities | ||
| * Verifier smart contract - implements a `verify` function, given an inference task and its ZK proof, returns the verification result as a boolean | ||
|
|
||
| ## Specification | ||
|
|
||
| The keywords "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. | ||
|
|
||
| **Every compliant contract must implement the [ERC-7007](./eip-7007.md), [ERC-721](./eip-721.md), and [ERC-165](./eip-165.md) interfaces.** | ||
| **Every compliant contract must implement the `IERC7007`, [`ERC721`](./eip-721.md), and [`ERC165`](./eip-165.md) interfaces.** | ||
|
|
||
| The zkML AIGC-NFTs standard includes the following interfaces: | ||
| The verifiable AIGC-NFT standard includes the following interfaces: | ||
|
|
||
| `IERC7007`: Defines a mint event and a mint function for minting AIGC-NFTs. It also includes a verify function to check the validity of a combination of prompt and proof using zkML techniques. | ||
| `IERC7007`: Defines a `mint` function and a `Mint` event for minting AIGC-NFTs. Defines a `verify` function to check the validity of the combination of prompt and aigcData using zkML/opML techniques. | ||
|
|
||
| ```solidity | ||
| pragma solidity ^0.8.18; | ||
|
|
@@ -43,15 +59,16 @@ interface IERC7007 is IERC165, IERC721 { | |
| * @dev Emitted when `tokenId` token is minted. | ||
| */ | ||
| event Mint( | ||
| address indexed to, | ||
| uint256 indexed tokenId, | ||
| bytes indexed prompt, | ||
| bytes indexed aigcData, | ||
| bytes aigcData, | ||
| string uri, | ||
| bytes proof | ||
| ); | ||
| /** | ||
| * @dev Mint token at `tokenId` given `prompt`, `aigcData`, `uri` and `proof`. | ||
| * @dev Mint token at `tokenId` given `to`, `prompt`, `aigcData`, `uri`, and `proof`. `proof` means that we input the ZK proof when using zkML and byte zero when using opML as the verification method. | ||
| * | ||
| * Requirements: | ||
| * - `tokenId` must not exist.' | ||
|
|
@@ -61,14 +78,15 @@ interface IERC7007 is IERC165, IERC721 { | |
| * - `proof` should not include `aigcData` to save gas. | ||
| */ | ||
| function mint( | ||
| address to, | ||
| bytes calldata prompt, | ||
| bytes calldata aigcData, | ||
| string calldata uri, | ||
| bytes calldata proof | ||
| ) external returns (uint256 tokenId); | ||
| /** | ||
| * @dev Verify the `prompt`, `aigcData` and `proof`. | ||
| * @dev Verify the `prompt`, `aigcData`, and `proof`. | ||
| */ | ||
| function verify( | ||
| bytes calldata prompt, | ||
|
|
@@ -78,7 +96,7 @@ interface IERC7007 is IERC165, IERC721 { | |
| } | ||
| ``` | ||
|
|
||
| Optional Extension: Enumerable | ||
| ### Optional Extension: Enumerable | ||
|
|
||
| The **enumeration extension** is OPTIONAL for [ERC-7007](./eip-7007.md) smart contracts. This allows your contract to publish its full list of mapping between `tokenId` and `prompt` and make them discoverable. | ||
|
|
||
|
|
@@ -102,7 +120,39 @@ interface IERC7007Enumerable is IERC7007 { | |
| } | ||
| ``` | ||
|
|
||
| ERC-7007 Metadata JSON Schema for reference | ||
| ### Optional Extension: Updatable | ||
|
|
||
| The **updatable extension** is OPTIONAL for [ERC-7007](./eip-7007.md) smart contracts. This allows your contract to update a token's `aigcData` in the case of opML, where `aigcData` content might change over the challenge period. | ||
|
|
||
| ```solidity | ||
| pragma solidity ^0.8.18; | ||
| /** | ||
| * @title ERC7007 Token Standard, optional updatable extension | ||
| */ | ||
| interface IERC7007Updatable is IERC7007 { | ||
| /** | ||
| * @dev Update the `aigcData` of `prompt`. | ||
| */ | ||
| function update( | ||
| bytes calldata prompt, | ||
| bytes calldata aigcData, | ||
| string calldata uri | ||
| ) external; | ||
| /** | ||
| * @dev Emitted when `tokenId` token is updated. | ||
| */ | ||
| event Update( | ||
| uint256 indexed tokenId, | ||
| bytes indexed prompt, | ||
| bytes indexed aigcData, | ||
| string uri | ||
| ); | ||
| } | ||
| ``` | ||
|
|
||
| ### ERC-7007 Metadata JSON Schema for reference | ||
|
|
||
| ```json | ||
| { | ||
|
|
@@ -121,7 +171,6 @@ ERC-7007 Metadata JSON Schema for reference | |
| "type": "string", | ||
| "description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive." | ||
| }, | ||
|
|
||
| "prompt": { | ||
| "type": "string", | ||
| "description": "Identifies the prompt from which this AIGC NFT generated" | ||
|
|
@@ -133,14 +182,40 @@ ERC-7007 Metadata JSON Schema for reference | |
| "aigc_data": { | ||
| "type": "string", | ||
| "description": "A URI pointing to a resource with mime type image/* representing the asset to which this AIGC NFT represents." | ||
| }, | ||
| "proof_type": { | ||
| "type": "string", | ||
| "description": "validity (zkML) or fraud (opML)" | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| ### ML Model Publication | ||
|
|
||
| While this standard does not describe the Machine Learning model publication stage, it is natural and recommended to publish the commitment of the Model to Ethereum separately, before any actual `mint` actions. The model commitment schema choice lies on the AIGC-NFT project issuer party. The commitment should be checked inside the implementation of the `verify` function. | ||
|
|
||
| ## Rationale | ||
|
|
||
| TBD | ||
| ### Unique Token Identification | ||
|
|
||
| This specification sets the `tokenId` to be the hash of its corresponding `prompt`, creating a deterministic and collision-resistant way to associate tokens with their unique content generation parameters. This design decision ensures that the same prompt (which corresponds to the same AI-generated content under the same model seed) cannot be minted more than once, thereby preventing duplication and preserving the uniqueness of each NFT within the ecosystem. | ||
|
|
||
| ### Generalization to Different Proof Types | ||
|
|
||
| This specification accommodates two proof types: validity proofs for zkML and fraud proofs for opML. Function arguments in `mint` and `verify` are designed for generality, allowing for compatibility with both proof systems. Moreover, the specification includes an updatable extension that specifically serves the requirements of opML. | ||
|
|
||
| ### `verify` interface | ||
|
|
||
| We specify a `verify` interface to enforce the correctness of `aigcData`. It is defined as a view function to reduce gas cost. `verify` should return true if and only if `aigcData` is finalized in both zkML and opML. In zkML, it must verify the ZK proof, i.e. `proof`; in opML, it must make sure that the challenging period is finalized, and that the `aigcData` is up-to-date, i.e. has been updated after finalization. Additionally, `proof` can be *empty* in opML. | ||
|
|
||
| ### `mint` interface | ||
|
|
||
| We specify a `mint` interface to bind the prompt and `aigcData` with `tokenId`. Notably, it acts differently in zkML and opML cases. In zkML, `mint` should make sure `verify` returns `true`. While in opML, it can be called before finalization. The consideration here is that, limited by the proving difficulty, zkML usually targets simple model inference tasks in practice, making it possible to provide a proof within an acceptable time frame. On the other hand, opML enables large model inference tasks, with a cost of longer confirmation time to achieve the approximate same security level. Mint until opML finalization may not be the best practice considering the existing optimistic protocols. | ||
|
|
||
| ### Naming Choice on `update` | ||
|
|
||
| We adopt "update" over "finalize" because a successful challenge happens rarely in practice. Using `update` could avoid calling it for every `tokenId` and save gas. | ||
|
|
||
| ## Backwards Compatibility | ||
|
|
||
|
|
@@ -152,12 +227,18 @@ The reference implementation includes sample implementations of the [ERC-7007](. | |
|
|
||
| ## Reference Implementation | ||
|
|
||
| * [ERC-7007](../assets/eip-7007/contracts/ERC7007.sol) | ||
| * ERC-7007 for [zkML](../assets/eip-7007/contracts/ERC7007Zkml.sol) and [opML](../assets/eip-7007/contracts/ERC7007Opml.sol) | ||
| * [ERC-7007 Enumerable Extension](../assets/eip-7007/contracts/ERC7007Enumerable.sol) | ||
|
|
||
| ## Security Considerations | ||
|
|
||
| Needs discussion. | ||
| ### Frontrunning Risk | ||
|
|
||
| To address the risk of frontrunning, where an actor could potentially observe and preemptively claim a prompt during the minting process, implementers of this proposal must incorporate a secure prompt-claiming mechanism. Implementations could include time-locks, commit-reveal schemes, or other anti-frontrunning techniques to ensure equitable and secured claim processes for AIGC-NFTs. | ||
|
|
||
| ### AIGC Data Change During Challenge Period | ||
|
|
||
| In the opML scenario, it is important to consider that the `aigcData` might change during the challenge period due to disputes or updates. The updatable extension defined here provides a way to handle these updates. Implementations must ensure that updates to `aigcData` are treated as critical state changes that require adherence to the same security and validation protocols as the initial minting process. Indexers should always check for any `Update` event emission. | ||
|
|
||
| ## Copyright | ||
|
|
||
|
|
||
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
Oops, something went wrong.