ERC-7007 Verifiable AI-Generated Content Token
Final · NFTs & multi-token · created 2023-05-10
An ERC-721 extension standard that makes it possible to verify on the blockchain that content created by AI, such as an image or video, was generated by a specific model from a specific input (prompt).
Why it is needed
When AI-generated content is sold as an NFT, problems arise if there is no way to confirm that the content was really generated with the claimed model and prompt. Anyone could bring similar output and claim it as their own, and content made from the same prompt could be minted more than once. Authors of AI models also worry that once they publish a model anyone can use it, and its monetary value disappears. This standard lets the generation process of content be verified onchain using zero-knowledge machine learning (zkML) or optimistic machine learning (opML), so that every pairing of prompt and output is securely confirmed. The original text explains that this makes it possible to build a revenue sharing structure for sales of AI-generated content NFTs, and lets model authors share their models without worrying about a loss of value.
What to implement
function tokenId(bytes calldata prompt) external view returns (uint256): Returns the token ID that corresponds to a prompt. It belongs to the Enumerable extension.function prompt(uint256 tokenId) external view returns (string calldata): Returns the prompt that corresponds to a token ID. It belongs to the Enumerable extension.
In depth
Required interfaces and tokenId design
A conforming contract MUST implement all of the IERC7007, ERC-721 and ERC-165 interfaces. The ERC-165 identifier of IERC7007 is 0x702c55a6. In this standard the tokenId is indexed by the prompt, specifically the hash of the prompt is used as the tokenId. Because the same prompt corresponds to the same content under the same model seed, this design prevents the same prompt from being minted twice and preserves the uniqueness of each NFT.
How addAigcData behaves, and the difference between zkML and opML
addAigcData is the function that binds a prompt and aigcData to a tokenId, and its arguments are designed generically to allow various minting implementations. With zkML, it must be checked at the time of addAigcData that verify returns true. With opML, on the other hand, it can be called before finalization. The original text gives the reason: zkML, where generating proofs is hard, usually deals with simple model inference so that a proof can be produced in an acceptable time, whereas opML handles large model inference but needs a longer verification time to reach a similar level of security, so delaying minting until finalization may not be the best choice.
Meaning of verify and its return condition
verify is the interface that enforces the correctness of aigcData, and it is defined as a view function to reduce gas cost. In both zkML and opML, it must return true only when aigcData has been finalized. In zkML, it must verify the supplied proof (zero-knowledge proof). In opML, it must check whether the challenge period has ended and whether aigcData is the latest state updated after finalization. In opML, the proof may be empty.
Enumeration extension and update extension
Both extensions are OPTIONAL. The enumeration extension IERC7007Enumerable (ERC-165 identifier 0xfa1a557a) exposes the full mapping between tokenId and prompt so that it can be browsed. The update extension IERC7007Updatable (identifier 0x3f37dce2) provides an update function and an Update event for opML cases where the contents of aigcData may change during the challenge period. The function is named update rather than finalize because a challenge rarely succeeds in practice, so it does not need to be called for every tokenId, which saves gas.
Metadata JSON schema
The reference metadata schema defines four fields in addition to the name, description and image of existing NFT metadata. prompt is the prompt that generated this NFT, aigc_type is the content type such as image, video or audio, aigc_data is the URI pointing to the generated asset, and proof_type indicates whether the proof method is validity (zkML) or fraud (opML).
Recommendations for model publication and commitment verification
This standard does not prescribe the step of publishing the machine learning model itself, but it recommends publishing a commitment of the model to Ethereum separately before actually calling addAigcData. The choice of commitment scheme is up to the issuer of the AIGC NFT project, and this commitment must be checked within the verify function implementation. Because the standard extends ERC-721 with a new interface, it is backwards compatible with existing ERC-721.
Things to watch out for
- Front-running risk: During minting, someone else can watch the prompt and front-run it to claim it first. Implementers should include front-running prevention techniques such as a timelock or commit-reveal so that prompt claiming is fair and safe.
- Data changes during the challenge period: In opML, aigcData can change during the challenge period because of disputes or updates. An update to aigcData should be treated as an important state change that follows the same security and verification procedures as the initial mint, and indexers should always check whether an Update event has occurred.