In Ethereum, you can upload your program to the blockchain and it will be executed on the network nodes. This program is called a Smart Contract. The ability to execute smart contracts is the main feature of Ethereum. And the cryptocurrency of the same name is not a value in itself, it is needed in order to provide settlements within the system.

It is very convenient that since our currency is also on the blockchain, then smart contracts can track transfers themselves and process these transfers.

One of the most frequent tasks of smart contracts turned out to be the maintenance of operations with certain conventional units of value - tokens. In a sense, a token is just an entry in the smart contract table. This table records how many tokens belong to which ETH wallet, and the transfer of tokens is simply the execution of a function in a smart contract that overwrites the data in the ownership table. Token creation - adding a new record to this table.

A token is inseparable from a smart contract. It is not some kind of unit that exists by itself, it exists only within the system that serves it.

You have probably already met these designations: ERC-20, ERC-721, ERC-1155. Behind these letters are standards for smart contracts. They set requirements for smart contracts that serve tokens. These requirements describe what functions must be in a smart contract in order for third-party applications - for example, exchanges such as OpenSea - to work with all tokens in the same way.

And besides this, they just provide storage of information about which tokens belong to whom. We will consider the most common standard for non-fungible (unique) tokens - ERC-721. A token of this format is also only an entry in the smart contract table. But the token itself only describes the ownership, so where then is the media data (image, audio file or video fragment)? At the moment, there are several different approaches to storing metadata.

It is very expensive to store large amounts of data on the Ethereum blockchain. Even if you just want to store the name and, for example, the vector of characteristics of your "NFT sword" on the blockchain, it will cost you additional hundreds of dollars at the time of the release of this sword. And every change in its characteristics (if you improve it, for example), will also need to be made to the blockchain, and, therefore, pay for gas.

And storage of large media is not only expensive, but also inconvenient.

Therefore, for the first method, the blockchain, in the overwhelming case, stores only the address (URL) - a link to the developer's site, where you can find information about the token (metadata) and media. It is much cheaper. What could go wrong? Because of this situation, the token and the media are loosely coupled with each other. The token itself (record of ownership) is stored on the blockchain, while the metadata and media are stored somewhere else. The site user can change the metadata in their own interests. He may lose control of the site and the images may disappear. Yes, you will have a token, and it can still be of value, for example, work as a pass to a certain club of owners. Still, it will be impossible to prove that this particular token was associated with a specific media.

You can improve this approach a little and use a special distributed service that is somewhat similar to torrents - IPFS. Already many serious projects use IPFS to store metadata and media for their tokens. IPFS stands for InterPlanetary File System. Basically, it is a file system spread over many computers. When you upload a file or image to IPFS, you get a hash of that object. This hash will determine the address at which the object in IPFS can be accessed.

But IPFS is not perfect, as its architecture doesn't reward nodes for storing files in any way. Therefore, formally, the safety and eternal availability of your object in IPFS is not guaranteed. That is where the concept of decentralization is being violated.

You can take it one step further. There are a number of services that can store images, financially encouraging users to distribute files, such as Arweave. Most often, this is another blockchain (blockweave) specialized for storing large files. A rotten apple in the barrel of eternal and accessible storage - potential moderation and censorship of content. In addition, if the network ceases to be "fashionable" and the number of its users drops dramatically, it will essentially be indistinguishable from the closure of the image hosting - you will not get the desired image in a reasonable amount of time.

The most reliable way of storing metadata is the OnChain storage method - when the smart contract function itself gives you a picture. This is much more expensive, it imposes strict requirements on the developers of the contract - they usually need to use several approaches to compress information, tricky transformations - all these tricks in order to fit data into the limited requirements of the blockchain. But this is more than pays off with one hundred percent reliability and durability of metadata - they will remain unchanged as long as the blockchain itself exists.

Technically, you just need the tokenURL() function of the smart contract to return a file that can be interpreted as a json-file with metadata. One of the parameters of this metadata can be a base64 snapshot of the file, instead of a link to the file. How to make such a file is not a description for one article, but in short, arrays of numbers are saved in advance that describe some parameters of the generated image, and then, during the execution of the function, these parameters are expanded into a finished image. The simplest is to use the SVG format, which offers a declarative textual description that is easier to program than the binary format for the more common format such as JPEG or GIF.