Chapter 2. Decentralized Applications
In this chapter we will take a look at a few sample use cases for building applications on the Ethereum blockchain. For each case we will take a look at what characteristics of the blockchain lend themselves well to supporting these applications and, where applicable, we will take a look at a few production examples. We will then conclude this chapter with a few questions to ask yourself when starting your next project to make sure the blockchain is the right technology to use.
Let’s jump into our first and likely most common use, tokens.
Tokens
Tokens are an abstraction that represents ownership. Ownership implies certain privileges such as the right to use or sell an item like a vehicle or a house. In these cases the token, or proof of ownership, is represented by a title or deed. It can also provide the right to access something such as software or a movie. Here the tokens may be represented by a license key or a physical ticket. With ownership being something that can change often, tracking these changes on a cryptographically secured platform makes a lot of sense.
To assist developers in the creation of tokens, the Ethereum community has developed several different types of token standards through the Ethereum Improvement Proposal (EIP) process. Let’s take a look at two of these standards, ERC-20 and ERC-721.
ERC-20
The ERC-20 standard is used when creating a fungible, or mutually interchangeable token. These tokens would be ideal replacements for things like rewards points from retailers, miles from airlines, or a currency. All tokens created from an ERC-20 contract are considered to have the same value and are effectively indistinguishable from each other. Because all the tokens are considered identical, the primary responsibility of an ERC-20 contract is tracking balances.
This standard has several optional fields such as name and symbol, but requires the implementation of the following:
totalSupply()-
Returns the number of tokens in circulation.
balanceOf(address owner)-
Returns the balance for the provided address.
transfer(address to, uint value)-
Returns
trueorfalsebased on the success or failure of the transfer. transferFrom(address from, address to, uint value)-
Returns
trueorfalsebased on the success or failure of the transfer. In this case the transfer is initiated by another address that is not the owner, and must have been previously approved to spend these funds on the owner’s behalf. approve(address spender, uint value)-
Returns
trueorfalseif successful. The method is used to set an amount that another address can spend on the owner’s behalf. allowance(address owner, address spender)-
Returns the amount still available for the spender to withdraw.
If you ever find yourself working on an application that requires an ERC-20 implementation, you can create an ERC-20 token by defining these functions; however, we recommend using the OpenZeppelin contracts as a basis to get started. These contracts have all been thoroughly audited and well documented, making them a great starting place for crafting your own token.
ERC-20 tokens have been used for many different purposes, but one that has likely caught your attention is the Initial Coin Offering (ICO). In an ICO, an organization will sell tokens as a means to raise funds. In some regards this is similar to what Kickstarter does for organizations or new projects but in a decentralized way.
If the token is expected to gain in value based on the performance of the issuing organization, the token may be considered a security. If that is the case, there are likely going to be some regulatory requirements that need to be considered when developing these smart contracts. For tokens that may fall into this category, there is a draft proposal in the works that may help keep the token in compliance.
For real-world examples, you can check out a list of deployed tokens on Etherscan.
Now let’s talk about tokens that are not mutually interchangeable or, in other words, non-fungible.
Non-Fungible Token (ERC-721)
ERC-721 provides the standard for non-fungible tokens. These tokens are—or at least have the ability to become—different from each other. Because these tokens are distinct, the contract cannot simply track a balance of tokens but must track each individual token that it issues.
Like the ERC-20, ERC-721 contracts may optionally implement fields for name and symbol, and they can also optionally include a token URI (Uniform Resource Identifier), but they must implement the following:
balanceOf(address owner)-
Returns the number of non-fungible tokens (NFT) for the passed-in owner.
ownerOf(uint256 tokenId)-
Returns the address of the owner for that particular token ID. Remember, every token is unique and the contract has to maintain a data structure that tracks ownership.
setTransferFrom(address from, address to, uint256 tokenId, bytes data)-
Transfers ownership of the token. In a case where the
toaddress is a contract, it will subsequently invoke theonERC721Receivedfunction to ensure it can accept the token. setTransferFrom(address from, address to, uint256 tokenId)-
Same as the previous function, but sets data to an empty string. This also shows that the Solidity programming language supports method overloading, or two methods with the same name but different parameters.
transferFrom(address from, address to, uint256 tokenId)-
Transfers ownership of the token. Unlike the
safeTransferFrommethods, it does not check to make sure the receiver is capable of receiving an ERC-721 token. If the receiver is not able to accept ERC-721 tokens, and this method is used, it may be permanently lost. If there’s any doubt, use thesafeTransferFrommethod instead. approve(address approved, uint256 tokenId)-
Allows another address to transfer the token on behalf of the owner. This is much like the
approvemethod for ERC-20, but instead of an amount, we specify which token the approved address can transfer. setApprovalForAll(address operator, bool approve)-
When approve is set to
true, it approves all tokens from the contract owned by the current owner (message sender) for the address of the operator. When approve is set tofalse, it removes access from all tokens owned by the current owner (message sender) for the operator address. getApproved(uint256 tokenId)-
Returns the approved address for the provided token ID.
Just like ERC-20, OpenZeppelin has created contracts that can be used as the basis for your own implementation of ERC-721.
For an example of how ERC-721s have been used, let’s take a look at CryptoKitties. CryptoKitties is a game that allows users to collect virtual cats, where each cat has a unique set of cattributes, which are represented by a 256-bit genome. Users then breed their cats to generate new ones, which inherit a mix of the traits from the parent genomes.
This may sound silly, but as of this writing, people have spent over $27 million USD buying these kitties, with a single kitty going for over $172,625 USD. If you’d like to see current figures, check out the Kitty Sales website.
ERC-721 tokens can represent just about any unique item that can be transferred. This makes it an ideal token for managing digital collectables or license keys, or even for a registry of physical real-world goods.
Speaking of real-world goods, let’s jump into our next major use case, the supply chain.
Supply Chain
In general, a supply chain is made up of the organizations, people, and processes that help products move from supplier to customer. To illustrate a supply chain, let’s talk about coffee.
Coffee is typically grown in a region referred to as the Bean Belt. This is an area near the equator that is bounded by the Tropic of Capricorn and Tropic of Cancer. Here you have farmers that plant and harvest coffee, eventually selling their crops to exporters. Exporters will transport the coffee overseas, where they will sell their shipments to the local distributors. The local distributors will then transport the coffee beans to the roasters. The roasters will then roast, blend, and package up coffee that can then be sold to coffee shops for customers to enjoy. This chain is illustrated in Figure 2-1.
Figure 2-1. Coffee supply chain
Each one of these roles, from the farmer to the coffee shop, can be its own company or business entity. This means that each organization is likely going to have an independent system for tracking purchases from supplier to sales. Some will link the sales to a specific lot of incoming product, while others may not make this connection. In cases where the link is not explicitly made, tracing a cup of coffee back to the farm and specific harvest could take a tremendous amount of time.
Shifting this to the blockchain would allow us to trace the origin of the cup of coffee back to the harvest far more quickly. Each harvest would be recorded on-chain, along with each change of ownership, all the way through to the coffee shop. Couple this with IoT devices that ride along with the shipment, posting conditions such as temperature and humidity to the blockchain, and you can have a highly detailed journey from farm to cup. Imagine scanning a QR code on a bag of coffee and seeing where it was farmed, along with the the path and environmental conditions from the moment it left the farm until it arrived in the coffee shop.
Now, this may be extreme for coffee, but this is not too far removed from the experiment that Walmart is running. In Walmart’s experiment, they are tracking mangos in Mexico and pork in China, with the goal of improving traceability. In order to set a baseline, a team was asked to identify the farm from which a packet of sliced mangos originated. It took the team nearly a week to do the legwork required to trace the mango slices to the farm. After implementing the blockchain solution, it took 2.2 seconds. In a case of food contamination, identifying the source could go a long way toward saving lives.
Note
Walmart is using the Hyperledger Fabric for its blockchain experiment. Hyperledger Fabric is a permissioned blockchain, which means that certain roles and activities, such as transaction validation (mining), account creation, etc., may be restricted or controlled by rules that may or may not live on the chain.
So far we have mostly discussed tracking food, but supply chain applications could be used for just about anything you see on the store shelf. For instance, imagine using this as a consumer to see where the cotton of the shirt you purchased was sourced, or the journey of a piece of furniture took to reach your living room. Having this would give consumers much more insight into their products, allowing them to make informed decisions.
Now that we know how supply chains could be great applications on the blockchain, what about record keeping?
Permanent Records
When you have a long-term asset like a house or a car, it would be great to track all the maintenance that has happened to it in some type of log. Even better than just tracking it would be to have it in a place where these records cannot be destroyed, and this is where the blockchain can help.
This type of record-keeping application is something that is being developed by Aeron Labs. Aeron is focused on the aviation industry, with the goal of making records such as aircraft maintenance and pilot logbooks available on the blockchain.
In the United States, pilot experience requirements and aircraft maintenance requirements are regulated by the Federal Aviation Administration (FAA). Looking at the requirements for pilots, there are different levels of pilot certificates that, once earned, allow certain privileges such as flying in the clouds or flying airplanes with multiple engines. In addition to earning these certificates, pilots may be required to maintain a level of currency by performing specific maneuvers within a given time period. As an example, a pilot may not take passengers with them unless they have performed 3 takeoffs and landings in the last 90 days, and the current way to prove this would be to look at the pilot’s logbook.
Proving something like this could be nearly impossible if the logbook in question were lost or destroyed. Putting this type of information on the blockchain would mean the information is permanent, accessible to appropriate parties such as the FAA or National Transportation Safety Board (NTSB), and protected from forgery.
Just like pilots, aircraft are required to have logbooks. Aircraft logbooks track maintenance and compliance with Airworthiness Directives, which are similar to recall notices from an auto manufacturers. With aircraft logbooks, mechanics add records every time they perform any type of upkeep item or repair to the aircraft. If this were moved to the blockchain, as Aeron is attempting, these records would be more quickly available and could not be lost or destroyed.
Aeron is currently building two applications. One is focused on the pilots and would replace traditional logbooks, and the other is on aircraft care to replace the maintenance logbooks. This would be a significant change for the aviation industry, and its success is dependent on many organizations adopting the technology. If Aeron can help shepherd in blockchain services to this industry, they can demonstrate an example for many other industries to adopt. This type of logging or additive record system could be great for any long-lived asset, and if the technology were adapted to help with health care, you could even have medical records that follow you your entire life.
With these types of applications in mind, let’s now turn our attention to deciding if the blockchain is a good fit for you.
Evaluating Blockchain for Your Application
How do you know if the blockchain is right for your application? What things should you consider when making this decision? The following sections describe some strengths of the blockchain.
Verifiable
If you need to make sure that the changes are being made by authorized individuals, the Ethereum blockchain has you covered. This is specifically useful for trustless environments, or environments without a centralized authority. By using cryptographically signed and verified transactions, every state change is protected from forgery or manipulation. The only way someone other than the owner of an EOA could make a transaction on their behalf is if they obtained a copy of their private key.
Transparent
With the Ethereum blockchain being public, anyone can see the transactions that are taking place. This means everything is fully available for auditing. There are tools such as Etherscan that allow you to inspect all the blocks and their transactions via a browser, or you can run your own Ethereum node and dive into transactions on your local machine. This means users no longer have to rely on the information provided to them from any entity; when the application is on the blockchain, they can go look for themselves. If your application is there to provide clarity for consumers or other industry collaborators, this functionality is already baked in.
Resilient
Each Ethereum node includes a full copy of the blockchain data. This means you will never find yourself in a situation where data was accidentally destoyed and not recoverable. If the data is on the chain, you can get it back by resyncing a node.
If any of these match the requirements of your application, then Ethereum is worth a closer look.
Summary
In this chapter we discussed how the blockchain is being used to build out tokens, provide transparency in supply chains, and create a way to audit pilot and airplane logbooks. These applications are just the tip of the iceberg of what is an exciting tech stack.
In the next chapter we will begin getting our machine ready for smart contract development!