ERC-7053 Interoperable digital media index (Interoperable Digital Media Indexing)
Final · Names & metadata · created 2023-05-22
An indexing standard that attaches a content identifier (CID) derived from the content to each digital media file and records it on-chain through a Commit event, so that the history of the media can be found and verified across multiple contracts and EVM-compatible chains.
Why it is needed
Digital media files make up a large share of the internet, but there is no universal, interoperable identifier that points to the content. Because each system records the same media in a different way, information becomes fragmented and it becomes complicated to find the metadata, storage location and provenance of a given piece of media. As the volume of digital media keeps growing, this problem becomes steadily more serious. This standard combines a decentralized content identifier (CID) with a Commit event to define how digital media is indexed in the same way across EVM-compatible networks. Users can see the full history of a piece of media from the time it was created to the present, which increases transparency, and any digital media system can index and search content information through a common interface.
What to implement
event Commit(address indexed recorder, string indexed assetCid, string commitData);: An event emitted when a new commit is created. It carries the address of the committing account, the content identifier of the asset, and the data attached to the commit.function commit(string memory assetCid, string memory commitData) public returns (uint256 blockNumber);: Registers a commit for an asset. It emits a Commit event, records the commit block number in the log for the given assetCid, and then returns that block number.
In depth
Scope of the standard
This standard defines an interoperable indexing method for organizing and searching digital media information across multiple smart contracts and EVM-compatible blockchains. Its purpose is to link all data about the same digital content together so that storage locations and key information are easier to find, and to help track and verify data across contracts and chains. It creates a common interface that any digital media system can use, so that each system indexes and searches its own content in a standard way.
Content identifier requirements
In this standard, a content identifier is a content address created by passing the contents of digital media through a cryptographic hash function. A unique content identifier MUST be created for each file before the indexing process begins. This identifier must match the content identifier used in decentralized storage, and a single identifier must give access to the media's metadata, media information and the content file itself. Files with identical content produce the same identifier wherever it is computed, so this identifier acts as a common key that links records of the same content across systems.
The commit function and the Commit event
The commit function takes two strings, assetCid and commitData. assetCid is the content identifier of the asset being committed, and commitData is the data attached to that commit. When called, it emits a Commit event, records the block number at which the commit occurred in the recordLogs mapping for the given assetCid, and then returns that block number. The Commit event carries recorder, the address of the account that made the commit, assetCid, the content identifier of the asset, and commitData, the commit data. recorder and assetCid are declared as indexed.
Why use a CID
The original text describes the benefits of adopting CIDs in two points. The first is stronger data integrity. A CID is a cryptographic hash of the content, so uniqueness is guaranteed and forgery can be prevented, and given the content you can derive the CID and look up the information linked to it. The second is data portability. Thanks to CIDs, moving digital media content to another system requires no re-encoding or protocol reconfiguration. For example, even an NFT created before the Commit event existed can be indexed with a consistent identification method by converting the file that its tokenURI points to in the same way.
Reference implementation CommitRegister
The reference implementation, the CommitRegister contract, has a public mapping named commitLogs (string to uint array). The commit function emits a Commit event, then appends block.number to commitLogs[assetCid] and returns that value. The getCommits function returns the list of block numbers recorded for a given assetCid, so following these numbers shows which commits happened to that media and when. The implementation is written to import OpenZeppelin's ECDSA and Initializable and to include an initialize function.
Things to watch out for
- Input validation: Because the commit function accepts string arguments, inputs should be validated to avoid injection attacks. Such attacks are less common in smart contracts than in traditional web development, but they still call for care.
- Data integrity is not verified: The commit function assumes that the CID is correct and points to the right data. This standard does not verify the content behind the CID or the commit data, and that responsibility lies with the user or the implementing application.
- Missed events and ordering: Systems that rely on receiving Commit events to track changes must be prepared for events to be missed or arrive out of order during network congestion or reorganization.
- Security audit recommended before deployment: Implementers should review the security aspects for their own use case and deployment environment, and it is strongly recommended to perform a comprehensive security audit before deploying to a live network.