In this post, I’d like to touch on the ERC-721 protocol standard, which is the basis for many “Non-Fungible Tokens” (NFTs) that we see on Ethereum and other blockchains. This will be a technical post, and I’ll assume you’ve already read my previous post on the distributed ledger to better understand the groundwork for some of these ideas.
In the last post, we talked about how tokens can carry value in these networks, such as Alice paying Bob 2.5 tokens. These tokens are also used to pay transaction fees in the network, to ensure a transaction is accepted into the blockchain. These tokens are fungible: interchangeable and replaceable with one another, much like fiat money. You and your friend can swap each other’s $10 bills, and you’ll still end up with the same value. This is different than a non-fungible object, which is an exceedingly fancy way of saying that each object is unique, and not interchangeable. For example, imagine you and your friend have tickets to a concert, but one ticket is seated much closer to the stage than the other!
This is the basic idea of NFTs: they describe tokens that are in some ways unique, and not interchangeable with another.
An interesting property of blockchains is that they enable a form of cryptographic scarcity within the network while also maintaining aspects of decentralization. Imagine concert tickets: these must be maintained by a central authority’s private ledger, to ensure that two tickets cannot share the same code.
In a decentralized system that supports smart contracts and state, we can define an imaginary “Golden Ticket” that can only be held by one wallet address at a time:
contract GoldenTicket {
// Current owner of the unique ticket
public address _owner;
// Allow current owner to transfer ticket to another user
public transfer (address _to) {
if (sender == _owner) {
_owner = _to;
}
}
}
This smart contract code defines the current owner of the ticket (a wallet address), and gives that owner the ability to transfer ownership to a new address. Notice that the contract itself is a non-fungible token. Once deployed, this contract will be associated with a unique addressable hash, such as:
0xb47e3cd837ddf8e4c57f05d70ab865de6e193bbb
Anybody could duplicate the above contract and attempt to replicate it, but the new contract will have a different hash, and therefore be considered a different token. This makes the original ticket extremely difficult to forge within the system, as long as those within the network continue to come to a consensus about the original hash. As the system and its history is public and verifiable, it is trivial to trace the provenance back to the original contract hash, rather than be fooled by a look-alike contract with a different hash.
The addressable hash above (0xb47..) is that of the Crypto Punks contract, which can be seen as a proto-ERC721 NFT.
Something worth recognizing is that ERC-721 (and similar standards, like ERC-1155) are like rough blueprints for developers to build upon. A standard might define method signatures (names, parameters, attributes, and return values), behaviour, intended functionality, and other aspects related to a particular idea or improvement.
This is somewhat similar to the way the web works: the W3C is a “standards body” that publishes specifications and interfaces, and then developers can begin to implement these interfaces in their applications, hopefully as closely to spec as possible. An example of this is PointerEvents, a spec that was designed to unify mouse, touch, stylus, and other input devices in the browser with a simpler JavaScript API. The W3C defined the methods, names, events, and so on, and various browser teams began to implement and develop these features so that web developers could use a single API that would work the same across all devices.
Ethereum aims to be a decentralized network, so there is no singular “standards body” that defines EIPs; instead, these are open to anybody to propose, discuss, and potentially implement if there is enough interest and agreement. Standards proposals also exist in Tezos (known as TZIPs) and other blockchains, but in smaller networks it often is the case that the blockchain developers themselves are the ones mostly publishing and defining these specs.
This brings us to ERC-721, which is not even specific to Ethereum, but can work across any EVM-compatible blockchain, such as Celo. Similar standards have begun to appear on various non-EVM blockchains, such as TZIP-12 (FA2 Token) that defines a spec for these kinds of NFT contracts on Tezos.
There are various functions and events in the spec, but the two important functions look like this:
transferFrom (address _from, address _to, uint256 token_id);
ownerOf (uint256 token_id);
Unlike our GoldenTicket contract, ERC-721 assumes that a single contract may wish to define and distribute many tokens (or “tickets”). Each token is associated with a token_id that defines its uniqueness, and we can use the ownerOf method to query which address currently owns each token.
Note that there is no scarcity limits defined in the spec—tokens can be unlimited—nor is there any mention of what kind of content these contracts must describe or how the metadata should be stored. The spec also does not define how tokens should be created (aka “minted”). These concepts are up to the contract developer to implement, allowing these standards to be used across a variety of applications (property, deeds, collectibles, rewards, art, loans).
For example: the popular Crypto Punks contract (created some time before ERC-721) does not include additional metadata on-chain, but does define on-chain a sha256 image hash, allowing anybody with access to the full-sized PNG texture to verify the traits of each numbered token (gender, accessories, hair style, etc).
Once these protocols have been well established and finalized, developers (building wallets, marketplaces, and other applications) can begin to build around them. This is how some wallets allow users to view and trade NFTs (ERC-721/1155 compatible tokens) that are assigned to their address; despite the fact that none of these ideas are part of the original blockchain design.
Unfortunately, as these blockchains are highly constrained environments, it is not feasible or realistic to “upload” an entire image onto the ledger (it would cost thousands of dollars in transaction fees). This kind of data must be defined and maintained off-chain.
In an attempt to unify different types of NFT-like contracts and the metadata associated with each token, the protocol defines an optional extension that allows you to query the metadata URI of each token_id.
tokenURI(uint256 token_id) returns (string);
This way, each token can be associated with a URI that points to some metadata describing its properties: perhaps the high-resolution PNG of an artwork, a thumbnail image, the unique traits of a procedurally created avatar, or the seat number in a concert stadium.
Typically, the URI will point to a JSON file that adheres to the “ERC721 Metadata JSON Schema” defined in the same spec. This allows for NFT wallets, marketplaces like OpenSea, and other applications to know how to fetch thumbnails, high-resolution images, titles, descriptions, and so on.
{
"title": "Golden Ticket – Seat 32B",
...
}
The last piece of the puzzle is in the media hosting itself. Rather than pointing to a URL on a HTTPS server, that might be shut down one day or could be changed to any arbitrary data at the will of the server host, NFTs tend to rely on distributed hosting systems like IPFS. For example, token_id 466 might return the following tokenURI string:
ipfs://QmXJ98cXwjxvnL57uKm1AzBJMaCw4ykYejUt3JoKrZgnNc
This is a content-addressable hash to a JSON file that describes an artwork of mine distributed on the Hic Et Nunc marketplace on Tezos. If you have an IPFS node running, you can view and host this file in a peer-to-peer manner, much like BitTorrent. I have a copy of this file on my own local disk, and a cloud server for redundancy, and various others within the community (platform operators, art collectors) are also helping to pin and maintain these files.
If you don’t have an IPFS node running, you can view this via a CDN gateway such as the one provided by Cloudflare. The full-resolution media file described in this JSON file is also using IPFS for distribution and hosting. Unlike a typical URL, the content is fixed to this hash, and so altering the content will create an entirely new string of characters. However, like a URL on a web server, it is also susceptible to link rot if the file happens to be lost forever—such as if all hosts stop pinning (seeding), and the original files are no longer accessible on any hard drives or other cloud hosting services.
Some projects, such as Autoglyphs, ArtBlocks, and the audio-visual work of Deafbeef will deploy contracts that in some way hold the entire metadata and media within them, allowing you to recreate the work without relying on any IPFS media hosting. These are often conceptual, procedural, algorithmic, or textual in nature, as they must fit within the byte constraints of smart contract deployment (where each additional byte can increase the cost). This is one reason that generative art and demoscene-like media has found a natural fit within these protocols, as they can be published and stored onto the distributed ledger in a rather immutable and somewhat permanent manner.
So far, I’ve mostly talked about the technical underpinnings of ERC-721 and NFT protocols, attempting to break down their basic components to help illustrate what lies beneath these rather complex subjects.
Perhaps my next post will be less technical, focusing more generally on what kinds of problems “crypto art” can solve for digital artists. For example: distribution, revenue, royalties, collaborative splits with nonprofits and OSS tools, self-hosted contracts, decentralized markets and auction platforms, digital ownership, and other concepts.