Before Blockchain, There Was The Web

Before blockchain and before ERC-721 there was the World Wide Web (or simply the web). The first commercial uses for the internet appeared in the late 1980’s, and in 1989 Tim Berners-Lee created the web on top of the internet. The web consists of HyperText Transfer Protocol (HTTP), HyperText Markup Language (HTML), Universal Resource Identifiers (URI’s) and web browsers. HTTP is the underlying protocol for connecting all the pieces together. HTML provides a language to create sites users can visit. URI’s identify resources such as websites, documents, and images people can use. Browsers allow users to visit and utilize these various resources.

The original purpose of the web was to enable researchers to share documents and to facilitate the free exchange of ideas. This not only succeeded beyond all reasonable expectations but also changed the world in a few short years.

Problems with the Web: 

The web’s limitations became apparent. The free exchange of ideas failed to account for digital ownership and property rights. If an engineer creates a new software invention and releases it onto the web, nothing in the protocol protects the author – users download it, execute it, copy it; the invention lends itself to purposes the creator never intended and may not approve of. The protocol provides no mechanism to financially compensate the author for use of his work, and the protocol does not even provide a mechanism to prevent someone from taking the inventor’s software, putting their own name on it, and selling it as their own.

As the web has developed, individuals and organizations who want to do commerce have searched ways of trying to protect their property rights, but lack of protection built into the protocol itself limits the possibilities.

The world of blockchain is different.

Cover Your Assets on the Blockchain

In a blockchain environment, someone owns an asset by possessing a private key. They prove ownership by signing that asset with a public digital signature created from that private key. Blockchains transact digital currency in a trustless, decentralized environment, but users transact assets beyond digital currency as well. Any goods or services capable of being represented in software can serve as a digital asset on a blockchain.

An asset is classified as fungible or non-fungible. A fungible asset is where every unit is exactly equal to every other unit in its class. The U.S. dollar is fungible. If you go to a store and make a purchase, the merchant does not care if you use this dollar or that dollar for the transaction because all dollars are the same. Non-fungible assets are unique in their class. Assume you go to a restaurant and order a chicken sandwich that costs X amount, and the waiter brings you a fish sandwich that costs exactly X amount. The two are non-fungible because even though they are of the same nature (both being sandwiches) and have exactly the same value, they are not the same thing at all.

(Classify Bitcoin as non-fungible. Although each bitcoin holds the same value at a given time, every bitcoin contains a known history, and one bitcoin spent on money laundering, drug dealing, or other illicit activity in the past becomes less desirable than another bitcoin with a clean history .)

ERC-20 and Token Standards

In the Ethereum network, the ERC-20 token standard exists to create fungible assets. The ERC acronym stands for Ethereum Request for Comment, and the number is simply an identifying index. The ERC-721 standard has been created to transact non-fungible assets (erc721.org).

An ERC token standard functions somewhat like an interface inobject-orientedd programming. An interface defines a contract a programmer must follow to create objects. Programmers create multiple objects from a single interface, but they must implement every property and method of that interface. The objects can implement additional properties and methods beyond those defined in the interface. For example, an interface might define a “vehicle” with properties defined as “tires” and “steering mechanism”.

From this interface, programmers create “tricycle” objects, “motorcycle” objects, and “car” objects. “Motorcycle” and “car” objects include a “gas tank” property that “tricycle” objects do not need. ERC token standards operate in exactly the same way.

CryptoKitties and the Dawn of ERC-721

The ERC-721 standard was introduced by Dieter Shirley of Axiom Zen. The original purpose of the standard was to create CryptoKitties. CryptoKitties are unique collectible digital artworks of cats. You can not only own a unique collection of CryptoKitties, but you can also breed the cats to create new CryptoKitties.

This opens avenues of potential revenue where you can create new cats and sell them. If you have a particularly desirable CryptoKitty that others would like to breed with theirs, you could earn money charging stud fees.

In time CryptoKitties themselves may prove no more valuable than the hula hoops or Davy Crockett coonskin caps that were huge fads in the childhood days of baby boomers. In those days, cutting edge technology was black and white broadcast television. The real value of CryptoKitties may well turn out to be that they provide a proof of concept for non-fungible digital asset ownership.

The Not So Secret Code

The code of the ERC-721 token standard is a contract that defines events and functions.  General explanations of the code suffice here, and detailed technical information exists at the ERC-721 website.

Programmers must implement three events: Transfer(), Approval(), and ApprovalForAll(). Transfer triggers when ownership changes. Approval triggers when the approved address for an a Non-Fungible Token (NFT) changes or reaffirms. ApprovalForAll triggers when an operator enables or disables an owner.

The functions programmers must implement are:

balanceOf() to count all Non-Fungible Tokens (NFT’s) assigned to an owner

ownerOf() to find the owner of an NFT

safeTransferFrom() to transfer the ownership of an NFT from one address to another address and throws exceptions if the parameters have problems

transferFrom() to transfer ownership of an NFT

approve() to set or reaffirm the approved address for an NFT

setApprovalForAll() to enable or disable approval of a third party (“operator”) to manage all of msg.sender’s assets

getApproved() returns the approved address for this NFT or the zero address if there is none

isApprovedForAll() returns true if the operator is an approved operator for the owner, otherwise returns false

supportsInterface() returns true if the contract implements a valid interfaceID, otherwise returns false

Final Thoughts:  The Nine Lives of Emerging Technologies

Right from the get-go ERC-721 shows some potential limitations simply by virtue of the nature of digital technology. Any digital object simply structures a collection of bits, and the bits can be altered. Suppose you are an artist who has created the greatest digital portrait ever. If someone chooses to copy the portrait and paint a mustache on it, could you prevent that simply because you can prove ownership of the original asset? Do you own the new asset derived from your property? If the asset was not an art work but a piece of executable code, would you be able to limit use of that code?

When a new technology emerges onto the scene, all the possibilities and limitations are not immediately obvious. Consequently, engineers brainstorm on the potentials and challenges, and if the brain is not capable of storms, light drizzles and occasional flurries will often suffice. What we can say at this point is that ERC-721 is a thoughtful approach, and it provides a modest amount of hope in alleviating some of the original shortcomings of the World Wide Web protocol.

The post Beyond CryptoKitties: The Future of ERC-721 and Ownership of Unique Assets appeared first on CoinCentral.