Skip to content

Commit

Permalink
xhyu patch 1 (#2)
Browse files Browse the repository at this point in the history 
* 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]>
  • Loading branch information
@xhyumiracle @socathie
xhyumiracle and socathie authored Jan 18, 2024
1 parent b6cf474 commit 105be50
Showing 1 changed file with 11 additions and 11 deletions.
22 changes: 11 additions & 11 deletions ERCS/erc-7007.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,23 +8,23 @@ status: Review
type: Standards Track
category: ERC
created: 2023-05-10
updated: 2024-01-16
updated: 2024-01-17
requires: 165, 721
---

## Abstract

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-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 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.

There are two methods of verification for this standard. One is zkML and the other is opML. Developers can choose their preferred verification method.
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, 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).
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, model owners can publish their trained model and the model's final inference state to Ethereum. Any user can challenge the model's final state within a predefined challenge period and submit fraud proof. If there is no dispute within the challenge period. The user can verify that he/she owns 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.

## Specification

Expand All @@ -34,7 +34,7 @@ The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SH

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/opML 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;
Expand Down Expand Up @@ -190,23 +190,23 @@ This specification sets the `tokenId` to be the hash of its corresponding `promp

### 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 verification requirements of opML.
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.
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.
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.

### ML Model Publication

While this standard does not describe the Machine Learning model publication stage. It’s 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.
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.

## Backwards Compatibility

Expand All @@ -225,7 +225,7 @@ The reference implementation includes sample implementations of the [ERC-7007](.

### 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 ERC-7007 must incorporate a secure prompt-claiming mechanism. Implementations could include time-locks, commit-reveal schemes, or other anti-frontrunning techniques to ensure equitable and secure claim processes for AIGC-NFTs.
To address the risk of frontrunning, where an actor could potentially observe and preemptively claim a prompt during the minting process, implementers of ERC-7007 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

Expand Down

0 comments on commit 105be50

Please sign in to comment.