Chapter 1. A first look at decentralized applications

How many times have you found yourself in the following situation? You were browsing around to buy the latest gadget and were comparing prices online, when you came across SmallWebRetailer.com that was offering it 30% cheaper than WellKnown.com. You quickly put the item in the basket, fearing the price would rise at any moment, and entered your postal address and credit card details, but suddenly...you got cold feet. You started to wonder: Is the price too good to be true? What if this unknown SmallWebRetailer.com is a scam? Will they run off with my money? After a few minutes of hesitating on the Buy button, you opened a new browser tab and went straight to WellKnown.com. You submitted the order, aware you might have overpaid 30% for your gadget.

Why did you panic? Perhaps you didn’t trust SmallWebRetailer.com. Perhaps you didn’t want to waste your time contacting the credit card company and possibly waiting for a refund if the transaction turned sour.

What if you could’ve bought the gadget from the same small, unknown retailer through an “alternative e-commerce application” that guaranteed the seller couldn’t access your money until you’d confirmed safe delivery of your order? What if that guarantee hadn’t been provided by the seller or by a single third party, but by many independent parties participating in a platform designed to process transactions according to conditions encoded in software anyone could inspect? Hold on, probably I’ve said it too fast. I’ll repeat it more slowly:

1. What if the money transfer was held until delivery, not by the retailer or a third party but by many participants in the platform?
2. What if the rules for escrowing and then releasing the money transfer were encoded in logic, not subjected to manual interaction?
3. What if, in case you were still unconvinced, you could inspect the code yourself?

I bet you’d click Buy, confident your funds would be safely stored on this platform until the delivery arrived. Such systems do exist, and they’re called decentralized applications. Decentralized marketplaces, such as OpenBazaar (https://openbazaar.org/), work this way. The mechanism by which funds are routed to the seller only when you’ve confirmed safe delivery of the goods is called a smart contract.

Decentralized applications, also known as decentralized apps or Dapps (generally pronounced dee-apps), are part of a new wave of web applications meant to increase the transparency around commercial transactions, governmental processes, supply chains, and all those systems that currently require mutual trust between customer and supplier, user and provider. The objective of Dapps is to minimize or eliminate the need for any trust between the participants in a system interaction, with the aim of empowering users beyond what Web 2.0 has delivered. Some claim Dapps could be the backbone of Web 3.0.

Assuming you have programming experience—even better if it’s in JavaScript—and some familiarity with web applications, this book will teach you how to build Dapps made of one or more smart contracts controlled by a user interface. By the end of this book, you’ll be able to not only write smart contract code but design, implement, test, debug, deploy, and secure a full end-to-end decentralized application. Along the way, you’ll also learn a new language, a new platform, and, most of all, a new way of thinking about, designing, and running applications.

In this first chapter, I’ll give you a high-level overview of Dapps. I’ll explain in detail what they are, what they look like, what technology stack they’re built on, and when it makes sense to build them. Best of all, I’ll help you start building your own! Let’s start our journey.

1.1. What is a Dapp?

Before I talk about decentralized applications, I’ll refresh a concept you’re already familiar with, most likely without realizing it: that of a centralized application. Probably you’ve never heard this expression before because conventional web and enterprise applications are implicitly centralized with respect to their users. I can hear you asking, what does “centralized” mean exactly?

A centralized application or system is controlled by a single or central entity: an individual, company, institution, governmental agency, and so on. The entity hosts the system directly on its premises or through a service or cloud provider and has full control of all the components and layers of the system architecture. The user trusts the good faith of the central entity and decides whether to access its system depending on the entity’s reputation. From the point of view of the user, the system is either trusted or not. This is how most web and enterprise applications are designed today.

Figure 1.1 illustrates a typical interaction between a user and a centralized trusted system. You shouldn’t find anything surprising about it.

Figure 1.1. A centralized application is strongly associated with the single entity controlling it. Consequently, users decide whether to access it depending on their trust of the entity.

Let’s move on to decentralized applications. If you consider for a moment the alternative e-commerce application I introduced earlier, you’ll agree it has advantages with respect to SmallWebRetailer.com:

• Favorable transaction conditions—The transaction would be completed and the money would be fully transferred to the retailer only when the retailer had complied with all the conditions associated with the transaction, such as your confirmation of safe delivery. This would remove one of the biggest reservations you had about SmallWebRetailer.com: uncertainty whether you’d get the delivery and what would happen to your money if not.
• Independent transaction execution and verification—The transaction wouldn’t be processed by the retailer or a single third party but by one of many participants in the platform supporting the e-commerce application, and then all the participants in the platform would independently verify it. The mechanism that all parties would use to agree on the verification of a transaction is called consensus (defined in the callout). The consensus mechanism would reassure you that the promised transaction conditions would be enforced and verified by many independent parties rather than an unknown retailer.

Definition

Consensus is a distributed and trustless form of agreement on the verification of a transaction. Distributed means that an independent central authority doesn’t perform the verification of a transaction; instead, all parties contribute to and agree on its verification. Trustless means that parties don’t need to trust each other to agree on the verification outcome. Consensus is reached when a qualified majority of the participants have agreed on the outcome of the transaction.

• Transparency—You’d be able to check the code processing the transaction and verify that it was observing the specified conditions before transferring your money to the retailer. This would give you a further level of reassurance that the application was executing under the promised terms.

You can deliver all of these requirements by building the alternative e-commerce application as a network of processing nodes of equal importance and functionality, each owned by a different party. Each node would

• be able to process a transaction the same way other nodes do
• verify all transactions in the same way other nodes do
• contribute in an equal way to the outcome of a transaction

The consequence of this architecture would be that the processing would be decentralized to a network of independent nodes rather than being centralized to a specific set of servers that a specific entity owns. Such decentralization would relieve the user from having to trust a specific entity: the user would have to trust only the design of the network as a whole.

Applications built on this architecture are known as decentralized applications. I’ll provide another example to make the concept clearer.

1.1.1. Dapps vs. conventional centralized applications

To explain more clearly the benefit of building a Dapp, as opposed to developing a conventional centralized application, I’ll illustrate for you a typical use case: an electronic voting application.

Centralized voting application

Traditional centralized voting applications are generally provided by a company to facilitate shareholder voting or by a local administration or government to facilitate the approval or selection of law proposals. The institution running the application owns it, directly or indirectly, at least during the voting session.

As you can see at the top of figure 1.2, a centralized voting application runs on one or more application servers connected to a central database. The system is exposed to the voters through one or more web servers hosting the voting website. The institution can have the web, application, and database servers hosted directly on the premises or in the cloud. Cloud hosting can happen through a cloud computing provider offering Infrastructure as a Service (IaaS) if the voting system has been implemented in-house by the institution, or through a cloud application provider offering Software as a Service (SaaS) if the voting system is only leased or rented from an external provider during the voting session. This architecture might not be ideal from the point of view of the voter, because of potential worries about trust and security.

Trust in centralized voting

Given all the financial and accounting scandals that have happened at both corporate and governmental levels in the last few years, it’s understandable if you don’t fully trust the organizations you’re a shareholder or citizen of. You might wonder whether the outcome of electronic voting might get manipulated in some way.

It’s easy to imagine, for example, that a malicious developer or administrator of the voting application, colluding with some party interested in a certain outcome of the voting, could access key parts of the system and tamper with the way votes are collected, processed, and stored at various levels of the application architecture. Depending on how the application has been designed, it could be possible for some malicious database administrators to even modify votes retroactively.

Security in centralized voting

When voting through a centralized application, you’d worry about not only the good faith of the company or institution organizing the election, but also whether the system was secured adequately against external manipulation. For example, external parties might be interested in having the voting go a certain way and might try to get their desired outcome by hacking into the system.

As I explained earlier, a centralized voting system includes only a certain number of servers located within the same network. Each server generally provides only one function, and it’s therefore a single point of failure, not only from a processing point of view but also, and especially, from a security point of view. For example, if a hacker managed to alter code on the web server so that votes were intercepted and modified in that layer, the entire system would be compromised. The same outcome could be achieved by hacking only into the application server or, even better, into the database server. A breach of security in one part of the system is sufficient to compromise the security of the entire system.

Decentralized voting application

A decentralized application is based on two key technical principles:

• Its application logic is present and executed simultaneously and independently on each server of a peer-to-peer (P2P) network. In theory, a different participant owns each server, also known as a node. A central node doesn’t control or coordinate the servers; instead, they communicate directly with each other and are consequently also known as peer nodes. They continuously verify each other’s output, so a user need only trust the P2P network, not an individual organization. The application data and state are stored on a local copy of a database on each server of the network, as shown at the bottom of figure 1.2.
• Its database technology, called blockchain, guarantees that data can’t be modified retroactively.

Figure 1.2. Comparison of a centralized voting application with a decentralized one. One institution owns all servers of a centralized application. A decentralized voting application runs simultaneously on multiple nodes of a network that different entities own.

Trust and security in Dapps thanks to P2P network replication

How can you address trust and security concerns by decentralizing the voting application according to the two principles I outlined? A decentralized voting application makes trust and security breaches pointless by replicating its execution over a network including many servers, each in theory owned by a different party. Think about it: if votes were processed and verified not by one single server but independently by many servers owned by different parties, and they were stored not in a single database but in many databases, each one local to the processing party, both trust and security concerns would be addressed:

• Trust—If one of the participants tried to maliciously alter a vote and propagate the modified vote to the network, the other participants would detect the vote as modified during their validation and would reject it. They wouldn’t store it in their local copy of the database and wouldn’t propagate the altered vote further throughout the network, so the malicious modification would become pointless.
• Security—Hackers would find trying to alter votes in a decentralized system much more difficult than trying to do so in a centralized one. Even if they managed to modify votes on one server, or they hosted themselves on one server of the decentralized voting application network to do so more easily, other participants would spot and reject the alteration, as seen earlier. Successful hacking would therefore require compromising not one server of the network but at least 51% of the nodes of the network simultaneously, assuming the state of the application is what is agreed among the majority of the network nodes. As you can understand, trying to manipulate a large part of a network including thousands of servers is an incredibly challenging task, especially if each one is managed independently. Also, each one might potentially be set up with a different way of preventing security breaches.

Trust and security in Dapps thanks to the blockchain

A blockchain database is based on a data structure that, as its name suggests, is a chain of blocks. A block can be seen as a record containing a set of transactions, each one digitally signed, some metadata (such as block number and time stamp information), and a link to the previous block. Each transaction, each block as a whole, and the links between blocks are secured with cryptographic technology, which makes them immutable: retroactive alteration of single transactions is nearly impossible, especially as more blocks are added to the chain. A blockchain database therefore addresses trust and security concerns by providing further protection against manipulation attempts by malicious participants and external parties.

Outstanding questions on low-level aspects

At this stage, you might find the decentralized voting application concept promising from a logical or a high-level point of view, but you might still be confused about physical and lower level aspects of its architecture. You might have doubts in various areas:

• System architecture—Is the network hosting the decentralized voting application a special kind of network? Do servers communicate with each other using a special protocol or using standard internet technology?
• Vote processing and validation—How does vote submission get propagated across the network so that a vote gets processed on each server of the network? How does a vote get counted and then stored on the blockchain? How does a member of the network verify the authenticity of the consolidated vote records received from other members?

I’ll try to answer these questions in the next two sections, which cover low-level details of the decentralized voting application. I’ll also assume the voting Dapp has been developed for Ethereum, the blockchain and Dapp platform this book is focused on. Doing so will allow me to start introducing Ethereum and to refer to concrete infrastructural components while presenting two complementary low-level views of the system:

• A structural Dapp view—I’ll describe the low-level architecture of the client and server sides of our voting Dapp.
• A transactional Dapp view—I’ll walk you, step-by-step, through the entire lifecycle of a voting transaction.

1.1.2. Structural view: Anatomy of a Dapp

The structural view of the decentralized voting application includes a description of the components of both the client side, represented by the web UI through which a voter submits a vote, and the server side, represented by a network of servers running the application logic.

Dapp client side: a web application

The voting application web client, shown in figure 1.3, gets initially downloaded into the user browser from a conventional web server, generally as a web application containing HTML and JavaScript. The web user interface doesn’t contain any server-side scripts and communicates directly with a specific server of the network through a client-side JavaScript library called Web3.js. It might also allow the user to communicate with a network node located on their premises. So far, this application differs in no major way from a conventional web application.

Figure 1.3. A decentralized voting application is exposed to the voter as a web application, which contains both HTML and JavaScript and is downloaded from a conventional web server. The web application, which doesn’t contain any server-side scripts (otherwise, it would be partially centralized), is generally configured to communicate directly with a specific node of the network.

Dapp server side: a P2P network

The server side of a decentralized application is a P2P network of servers that run the same code and have identical copies of a blockchain database. As you know, a key characteristic of this network topology is that it uses no central coordination, but instead uses direct communication between each node and a number of other nodes, known as peer nodes or simply peers. No master node is needed. As shown in figure 1.4, a node doesn’t need to be connected to all of the other nodes of the network. Being connected to a few nodes is sufficient to ensure transactions are rapidly propagated to the whole network.

Figure 1.4. A peer-to-peer (P2P) network is made of nodes that communicate directly with each other without the coordination of a master node.

The Ethereum network

Various P2P networks supporting blockchain platforms exist. The most well-known one is the Bitcoin network.

In this book, I’ll focus on the Ethereum network, whose participant nodes, as shown in figure 1.5, host a blockchain database and a piece of software called a node client, which allows a node to communicate with other nodes. Because all nodes are equivalent to each other, within the Ethereum network you have no clear-cut concept of client and server. Each node is a server to other nodes, but, at the same time, it’s also a client of other nodes. That’s why the software element of an Ethereum node is called a client.

Ethereum clients expose a common client interface and communicate with each other through a P2P protocol called Wire. That protocol enforces a standard way of sending data throughout the network, specifically a transaction, such as a submitted vote, and a block, such as a set of votes consolidated in the blockchain database.

Various implementations of an Ethereum client exist. As you can see in figure 1.5, they’re written in various languages, from C++ to Go, but all implement the standard client interface and the Wire protocol, so they can interact seamlessly.

Figure 1.5. Each node of the Ethereum network hosts a blockchain database and a node client capable of executing application code stored in the blockchain. Nodes communicate through the Wire protocol and expose the same interface but can be implemented in different languages.

The advantage of an Ethereum node client over a Bitcoin node client is that it’s able not only to propagate cryptocurrency transactions and blocks throughout the network, as a Bitcoin node does, but also to execute application code hosted on the blockchain database. From this point of view, platforms such as Ethereum are known as programmable blockchains. The code of decentralized applications is structured in smart contracts, which encapsulate logic and state in the same way classes do in most object-oriented languages. The voting decentralized application, for example, would be structured on various smart contracts that would be hosted on the Ethereum blockchain. I’ll explain shortly what a smart contract is, how you deploy it, how you execute it, and where a smart contract is stored and runs. Bear with me.

The role of network nodes

Although all network nodes communicate seamlessly through the common P2P Wire protocol, not all nodes perform the same function. Broadly, as shown in figure 1.6, the two main types of nodes, which are functionally different, are as follows:

• Full node—Most nodes have a standard setup that allows them to process transactions passively: they can read from the blockchain database, but they can’t create new blockchain blocks. But they can append blocks received from peer nodes to the local blockchain. They do execute transactions, but only to verify the correctness of the blockchain blocks they receive from peer nodes. In the case of the voting application, full nodes propagate votes received from their peers to other peers. They also verify that the blocks received are correct and contain authentic votes by running the voting Dapp smart contracts. But full nodes don’t store votes in new blockchain blocks.

  Figure 1.6. The Ethereum network includes two main types of nodes. Full nodes process transactions passively and can read, but can’t write on, the blockchain. Mining nodes process transactions actively: they validate the correctness of transactions as full nodes do, but they also assemble transactions into new blocks that are appended onto the blockchain.

  

• Mining node—Some of the nodes are configured to process transactions actively: they group and store transactions in new blockchain blocks. They’re rewarded in Ether, the cryptocurrency supported in the Ethereum platform, for performing such computationally intensive and energy demanding work. They then propagate these new blocks to the rest of the P2P network. Such nodes are called mining nodes because the process of consolidating a new block to the blockchain and being rewarded for it in cryptocurrency tokens is known as mining. In the case of the voting Dapp, mining nodes group votes received from peer nodes into a new block, append the block to the blockchain, and propagate the block through their peers.

Putting everything together

You’ve examined the structural view of the voting Dapp. Figure 1.7 shows the entire system, including the client and server sides.

Figure 1.7. The entire static view of a decentralized voting application, including client and server sides

1.1.3. Transactional view: Through the lifecycle of a transaction

Adding a temporal dimension to the static view you saw in figure 1.7, figure 1.8 illustrates step-by-step the full lifecycle of a voting transaction:

1. The user selects one of the possible voting options from a drop-down list box on the web client and clicks Vote.
2. A JavaScript function handles the click event and grabs the voting selection. Then, through various web3.js library functions, it sets up the communication with a configured Ethereum node, connects with the voting smart contract, and calls the castVote() function on it. The invocation of castVote() generates a transaction message that’s digitally signed against the account of the user to prove they’re the genuine sender.
3. The contacted local Ethereum node handles the transaction message, verifies it, and relays it to its peer nodes.
4. Peer nodes do the same and keep propagating the transaction, until the transaction hits mining nodes. This will happen relatively quickly, depending on the ratio of full nodes to mining nodes. Mining nodes perform the same steps (steps 2 and 3) of a full node. In addition, a mining node picks a transaction, such as a voting transaction. A transaction is considered profitable if it’s expected to generate an acceptable transaction fee, higher than the electricity costs the mining node faces while processing transactions. If so, the mining node executes the castVote() function and competes with other mining nodes to store the transaction on the blockchain. The winning mining node (which is the mining node successfully solving the so-called consensus algorithm, a cryptographic problem) consolidates the voting transaction among other transactions in a new block of the blockchain. It then relays the new block to all its peer nodes (regardless of whether they’re full or mining nodes).
5. Each node that has received a new block verifies whether the individual transactions included in it are genuine and whether the block as a whole is valid. It then processes all the transactions present in it. While doing this, it implicitly verifies the validity of the contract state. For example, the vote submission logic might include an invariant verifying that the number of votes cast for a candidate, or the total number of votes cast for all candidates, isn’t higher than the number of registered voters. If the node verifies the block successfully, it relays it to its peer nodes, which perform the same validation and propagation action until the whole network has acquired the new blockchain block. (The verification process will become clearer to you in the next chapter, when I’ll present the cryptographic techniques it’s based on.)
6. The local Ethereum node with respect to the user receives the new block and verifies it by executing all the transactions present on it, as all the other nodes have done. One of these is the voting transaction, which has been programmed to raise a VoteConfirmation event on successful completion. The event is published to all the clients subscribed to it, including the Dapp web UI.

   Figure 1.8. The lifecycle of a voting transaction. A voting transaction is created when a voter browser invokes the castVote() function on the Voting smart contract on a local node of the Ethereum network. This is then validated and propagated throughout the network until it’s included on a new blockchain block by a mining node. The new block is propagated throughout the network, and then it finally gets back to the local node.

   

7. The JavaScript code present on the voting web client contains a callback function registered against the VoteConfirmation event, which then gets triggered.
8. Finally, the callback function shows a vote confirmation notification on the voter’s screen.

1.1.4. Some Dapp terminology

Although decentralized applications are a relatively new idea, standard terminology around them started to appear relatively soon after the first Dapps were built. In this section, I’ll provide a summary of the key terms that Vitalik Buterin, the creator of Ethereum, described in a famous blog post^[1] he wrote to explain key Dapp concepts. You’ve already come across some of these terms in the previous sections, but now I’ll define them more precisely.

¹

Vitalik Buterin, “DAOs, DACs, DAs and More: An Incomplete Terminology Guide,” http://mng.bz/vNrq.

Smart contract

A smart contract is an arrangement between two or more parties that involves an exchange of digital assets. One or more of these parties allocates digital assets to the contract at its initiation. Subsequently, the assets are redistributed among the parties according to a predefined protocol encoded in logic and a state that’s initialized at the start of the contract.

Autonomous agent

An autonomous agent is a software entity that interacts autonomously with external software services and can reconfigure or even reprogram itself following verified changes in the external environment.

Decentralized organization

A traditional centralized organization contains assets and different classes of individuals, typically investors, employees, and customers. Investors control the organization by owning a part of it through the purchase of shares. Interactions between some classes of individuals are influenced by whether they control the organization. For instance, employees can get recruited by investors or by other employees authorized directly or indirectly by investors.

A decentralized organization (DO) isn’t controlled by any one person or entity. Predefined protocols are what determine interactions between classes of individuals involved in the organization. But such protocols can be designed so that certain individuals have more power than others—for instance, depending on the number of shares owned—exactly as with centralized organizations.

Decentralized autonomous organization

A decentralized autonomous organization (DAO) is both a DO and an autonomous agent. Like an autonomous agent, it’s a software entity that interacts autonomously with external software services. Individuals involved with the DAO interact, as with DOs, through predefined protocols.

The main difference between a DAO and a DO is that interactions between DAOs and external parties are largely automated, and the interaction protocols are programmed in a smart contract, whereas interactions between the individuals who own the DO and external parties are subject only to a manual protocol. The key point is that from the point of view of external parties, DAOs are more trustworthy than DOs because automated interactions are predictable, whereas interactions based on a manual protocol rely entirely on the reputation of the individuals following it.

According to these definitions, opinions diverge as to whether blockchain platforms built with the main or only purpose of supporting a cryptocurrency can be classified as DAOs or DOs. Because the Bitcoin infrastructure doesn’t allow for implementation of easily automated interaction protocols, some think it should be classified as a DO.

Decentralized autonomous corporation

A decentralized autonomous corporation (DAC) is a DAO that can be partially owned through a purchase of shares. As with classic (centralized) corporations, a DAC redistributes dividends periodically, depending on its financial success. A pure DAO, on the other hand, is generally a nonprofit organization, and participants benefit economically exclusively by contributing to its ecosystem and increasing its internal capital.

Note

The current widely accepted definition of decentralized application corresponds to that of DAO described previously, which is still in use among Ethereum purists. I’ll use this definition for Dapp for the rest of this book. The reason why the initial terminology used the word organization rather than application was because the Ethereum founders wanted to put emphasis on the fact that a decentralized application can transact with other parties exactly like conventional organizations: by following rules and protocols and exchanging monetary value, obviously in the form of cryptocurrency rather than conventional currency.

The key aspects of each of these terms are summarized in table 1.1.

Table 1.1. Matrix summarizing key aspects of each term, with DAO standing for Dapp

	Is software	Has capital	Is autonomous	Is owned
Autonom agent	YES	NO	YES	NO
DO	NO	YES	NO	YES
DAO	YES	YES	YES	NO
DAC	YES	YES	YES	YES

Although you’ve learned some of the high-level terms, you can’t truly understand the purpose of Dapps and how they work without familiarizing yourself with the concept of blockchain. Because Dapps are built on top of the blockchain and rely heavily on it, you should learn about it and its underlying technologies. I’ll cover this in the next section.

1.2. Good and bad Dapps

In the last few years, many Dapps have been developed. Some have received various rounds of venture capital funding and have been deployed successfully into production. Others have failed to convince investors and users and never passed the proof-of-concept stage.

1.2.1. Good use cases

Given the novelty of the technology, it’s hard to predict what’s going to work and what’s going to fail. Nevertheless, various use cases are being widely recognized as a good fit for the blockchain and in particular for Ethereum. Ideal Dapps are those that take advantage of the main benefits of these technologies, specifically record immutability, decentralization, security, and resilience. As a result, the main fields likely to be revolutionized by Dapps are provenance and ownership tracking, authenticity tracking, identity verification, regulatory auditing, charity expense auditing, prediction markets, customer loyalty management, crowdfunding, electronic voting, investing, gambling, lending, online games management, author royalty payment, Internet of Things, cloud computing, and even freedom of speech. Let’s see what innovative solutions have already been found in some of these areas.

Provenance and authenticity tracking

One of the biggest problems affecting supply chain management, particularly when involving long chains of processed goods crossing several countries, is tracking the authenticity of materials. Here are some Dapps that are innovating in this area with blockchain-based solutions:

• Dapps such as Provenance provide blockchain-based provenance tracking of materials to ensure no information is lost or manipulated within the supplier chain and goods of expected quality reach the end customer. One of the first applications built on Provenance has been focused on the food industry, to track the supply chain of ingredients from the point of collection, though the process of food manufacturing, to the final point of consumer sale. The aim of this system is to prove the food being sold has the claimed characteristics advertised to the consumers, such as location and sustainability of harvesting or breeding, whether the sources are organic or have been genetically modified, whether they’re coming from fair trade, and so on.
• Unilever, the multinational consumer goods corporation, is developing a blockchain-based system in collaboration with a number of start-ups to track the tea supply chain starting from farmers in Malawi.
• Everledger is a Dapp that aims to replace the paper certification process for diamonds with a blockchain-based system. A full digital record of a diamond, including its certificate ID and many properties, such as cut, grade, clarity, color, and carat, is stored on the blockchain, and the certificate ID is then engraved with a laser on the stone. All the information related to a diamond can then be retrieved at any point of the supply chain with the help of a scanner that reads the certificate ID from the stone. Almost 2 million diamonds have already been stored on Everledger.
• The pharmaceutical company Pfizer is partnering with the biotechnology company Genentech to develop MediLedger, a blockchain-based drug delivery tracking system. The aim is to verify the provenance and authenticity of Pfizer drug deliveries throughout the entire distribution chain to prevent thefts, fraud, and counterfeiting.

Identity verification

As with provenance tracking, verification of proof of identity tries to protect businesses and individuals from the consequences of fraud and identity theft. KYC-Chain is a novel platform built on the Ethereum blockchain that allows users to manage their digital identity securely. It also helps businesses and financial institutions to manage customer data in a reliable and easy manner. The system is designed so that users own the “keys” to their personal data and identity certificates. Consequently, identity owners, who can be individuals or companies, are the only ones who get to choose which part of their information is shared, with whom, and under what terms. Such information is digitally attested by notaries and institutions before being shared by owners and registered agents.

Proving ownership

Traditional blockchains associated with cryptocurrencies such as Bitcoin as ledgers implicitly prove the ownership of digital assets, such as the amount of Bitcoin stored at a certain address. Only the legitimate owners of the address are able to transfer funds because they’re the only ones who know the private key.

TrustToken tries to go further. It’s a Dapp conceived for proving the ownership of physical assets, such as real estate; financial assets, such as stocks and bonds; commodities, such as gold; and even intellectual property, such as music, books, and patents, through smart contracts. The idea is that you can transfer the ownership of these assets from one person to the other in the same way Bitcoins are transferred between addresses. The underlying assumption for TrustToken to be successful is that proof of ownership recorded through the system should be enforceable under law.

Economy of Things

The tech startup Slock.it (https://slock.it/) is building the infrastructure for the “economy of things,” which lies at the intersection between the Internet of Things and blockchain technology. This infrastructure, which the company has named the Universal Sharing Network, has the potential to be used as a financial internet, where connected autonomous objects can not only sell and rent themselves but also pay for each other’s services. The technology the company is developing, based on Ethereum smart contracts, aims to provide autonomous objects an identity and the ability to receive payments and enter into agreements without the need for intermediaries. Smart lockers, which enable the unlocking of physical objects when a fee is paid, are some of the applications already created on this platform. Because smart lockers make renting of sports equipment, hotel rooms, bicycles, and offices easy, this solution is thought to provide the foundation for the sharing economy.

Decentralized prediction markets

Prediction markets reward people for correctly predicting real-world events, such as the winner of a presidential election, the outcome of a referendum, the level of interest rates at a specific date, or the winner of a sports competition. Aside from speculative uses, they’re also useful tools for economists, public administration planners, and corporate strategists, who can base their decisions on the event probabilities being currently traded, which are thought to reflect the “wisdom of the crowds.”

Although centralized markets such as predictit.org (www.predictit.org) exist, several decentralized initiatives are starting to emerge. Augur is a decentralized market prediction platform built on Ethereum. The idea is that decentralization brings the following benefits:

• Being based on the Ethereum network, it has no central point of failure, so it’s inherently highly available.
• Nobody controls the definition of markets: anyone can start a new market on a new prediction and can get rewarded for having created that market.
• The official outcome of each prediction isn’t decided centrally; it’s crowdsourced from market participants, so it’s less likely to be subject to manipulation.
• Funds are stored on the blockchain, which eliminates counterparty risk, makes payment to prediction winners fast, and reduces the likelihood of errors.

International trade finance

International trade between a supplier and a manufacturer located in different countries is a complex business. As you can see in figure 1.9, it’s generally based on a complicated workflow involving many parties, such as banks that facilitate the payment, commercial intermediaries that facilitate the distribution, shipping and delivery companies that transport the goods, insurers that cover financial risks while the goods are in transit, and customs officials who check the legality of the goods and the payment of import duties.

Figure 1.9. Typical international trade involving many parties: banks, commercial intermediaries, shipping companies, insurers, customs officials, and so on

Parties involved in a specific transaction often have never dealt with each other previously. But for the transaction to complete successfully, they must communicate with each other effectively, generally through established lengthy protocols designed to protect a party against the malicious behavior of another party. Parties cross-check each other, and this takes a huge amount of paperwork and time, which often causes long delays.

we.trade is a platform sponsored by a consortium of banking partners (including Société Générale, Deutsche Bank, Nordea, Santander, and HSBC) that aims at simplifying and streamlining such processes with the help of blockchain technology. The platform tracks each step of the transaction openly and transparently so that each party is able to submit and consume the relevant documentation with the confidence that no one will tamper with it. Trades that used to take weeks can be now completed in a few days.

Regulatory auditing

The blockchain is particularly suitable for ensuring that records stored on it haven’t been altered or tampered with. Balanc3 is a Dapp built on Ethereum that ensures the integrity of accountancy records for regulatory purposes.

Crowdfunding

WeiFund aims at providing open source modular and extensible decentralized crowdfunding utilities based on the Ethereum blockchain. Users can set up and manage crowdfunding campaigns through these utilities. The possibility of encoding funding rules based on smart contract technology allows users to know precisely what will happen with their money if the campaign fails or is successful.

Gambling

Intuitively, a natural fit for a decentralized application is a gambling platform, because users get the benefit of being assured that bets are processed fairly and predictably. Edgeless is an example of such a platform, and it’s currently being developed after a successful crowdfunding campaign.

Now that you’ve learned about some successful Dapp implementations, you might be wondering whether it’s always worth basing your application on blockchain technology. We’ll explore this in the next section.

1.2.2. Pointless Dapps

Deciding whether the blockchain is a suitable technology for an application you’re planning to build might be difficult. What you should ask yourself is whether the functionality that a blockchain platform offers will meet your business requirements. More importantly, consider whether the benefits of using such a platform would be outweighed by all the technical limitations and additional complexities that come with this technology. A sobering blog post titled “Avoiding the Pointless Blockchain Project”^[2] analyzes the requirements necessary to justify the use of a blockchain platform over more traditional technologies such as SQL or NoSQL databases. It concludes that a blockchain project only makes sense if you can answer yes to all of the following questions:

²

Gideon Greenspan, “Avoiding the Pointless Blockchain Project,” http://mng.bz/4Oqg.

• Does your application require a shared database?
• Does the database need to support multiple writing parties?
• Do the writing parties have no trust in each other?
• Do the writing parties want to modify the state of the database directly, without requiring a central entity trusted by all participants?
• Do transactions that the writing parties create interact collaboratively with each other?

According to these criteria, for example, an internal enterprise application that wouldn’t expose any data to external parties wouldn’t be a suitable choice for a Dapp. Other poor Dapp candidates are applications for which confidentiality around the business rules is important. A smart contract is, by definition, completely open and transparent to all interacting parties. Therefore, preventing participants from accessing and understanding the logic of the rules would defeat the purpose.

Although decentralized microblogging applications such as EthTweet are considered sensible Dapps to those who value the fact that messages can’t be censored and altered after they’re sent, an instant messaging Dapp, such as a “decentralized WhatsApp,” wouldn’t be a particularly useful product for a fundamental reason. One of the technical downsides of the blockchain platform is that processing transactions (in this case instant messages) requires roughly 15 seconds to consolidate a new blockchain block. Therefore, messages would never be instant at all.

When building a Dapp, you also should keep in mind some operational aspects that, given the novelty of the technology, may cause some issues down the road. For instance, although a smart contract can automatically guarantee funds are routed and released subject to certain conditions, a commercial transaction might also be subject to real-world conditions that programming logic can’t enforce. A classic example for a non-fully automatically enforceable smart contract is that of an electronic loan. If the borrower had to keep the borrowed money stuck on a blockchain account so a smart contract could automatically give it back to the lender if the borrower missed an interest payment, the borrowing wouldn’t make any economic sense. In these cases, it isn’t clear yet whether a court of law would be able to enforce the nonautomated elements of a smart contract or it would be necessary to complement the deal with a traditional legal arrangement.

1.3. A five-minute Dapp implementation

By now, you should have a good understanding of what a Dapp is, the purpose of Dapps over conventional apps, the main architectural components of a decentralized application, and whether it makes sense to embark on a project based on blockchain technologies. It’s now time to take one little step further and get on with some programming. In the rest of the chapter, you’ll start building the smart contract for a custom cryptocurrency. You’ll then activate it and interact with it.

1.3.1. Building SimpleCoin, a basic cryptocurrency

Most Dapps are designed using functionality based on the exchange of cryptocurrency or tokens through rules encoded in one or more smart contracts. You’ll start to get a feel for Dapps programming by building SimpleCoin, a basic cryptocurrency that will present useful preliminary concepts about smart contracts and the Ethereum platform. You’ll progressively build on it in the following chapters, where you’ll learn more about Dapp development. You’ll also use or reference SimpleCoin from other Dapps that you’ll build in later chapters.

Because you haven’t installed an Ethereum platform client on your computer yet, you’ll be writing code on the Remix Solidity (previously known as Browser Solidity) integrated development environment (IDE) for now. This online tool will allow you to implement smart contracts in a high-level language called Solidity, similar to Java-Script, and run them on a local JavaScript VM that emulates the Ethereum Virtual Machine that you’ll meet in the next chapter. It’s also possible through this tool to interact with real smart contracts deployed on the Ethereum network.

Open a web browser and go to: http://remix.ethereum.org/. You should see a screen like figure 1.10. On the website, the left side of the IDE is a file explorer (which you can hide by clicking the double arrow toggle at the top left); in the middle you have the code editor; and the right side contains various panels to run the code and interact with it.

Figure 1.10. Screenshot of the Remix opening screen, with the code on the left and the code execution panels on the right. I’ve hidden the file explorer by clicking the double arrow toggle at the top left.

In your first encounter with Solidity, you’ll implement the simplest possible smart contract. If you think of a smart contract as the equivalent of a class in an object-oriented language, you’ll write a single class with only one member field, one constructor, and one method. Then you’ll run it and interact with it.

Hide the file explorer by clicking the double arrow toggle at the top left, and then enter the code in listing 1.1 in the Remix editor, in the left side of the screen.

Listing 1.1. First implementation of SimpleCoin, a basic cryptocurrency

pragma solidity ^0.4.0;                                          1

contract SimpleCoin {                                            2

  mapping (address => uint256) public coinBalance;               3

  constructor() public {                                         4
    coinBalance
 [0x14723A09ACff6D2A60DcdF7aA4AFf308FDDC160C] = 10000;         5
  }

  function transfer(address _to, uint256 _amount) public {       6
    coinBalance[msg.sender] -= _amount;                          7
    coinBalance[_to] += _amount;                                 8
  }
}

• 1 Pragma directive indicating the supported version of the Solidity compiler. (The code supports a compiler later than 0.4.0 but earlier than 0.5.0.)
• 2 Defines a contract, which is similar to a class in other languages
• 3 Defines a state variable as a “mapping” between an address and an integer. A state variable is the equivalent of a member variable. A mapping is equivalent to a hash table or hash map.
• 4 Starts defining the contract constructor
• 5 Assigns 10,000 SimpleCoin tokens to the coin account with address 0x14723a09acff6d2a60dcdf7aa4aff308fddc160c at contract creation
• 6 Defines a function that moves a number of SimpleCoin tokens from the coin account of the function caller to a specified coin account
• 7 Decreases the coin balance of the message sender by the specified number of tokens. (The special implicit property msg.sender represents the address of the sender of the transaction.)
• 8 Increases the coin balance by the specified number of tokens

Let’s examine this code in detail. A contract in Solidity is a type similar to a class in any other language: it has state variables (such as coinBalance), a constructor, functions (such as transfer), and events.

The coinBalance state variable is defined as a mapping. A mapping is a hash map, equivalent to a hashMap in Java, Dictionary in C#, or dict in Python. In this example, the type of the key is an address, whereas the value is a uint256—an unsigned 256-bit integer. An address holds a 20-byte value and can identify a specific smart contract account or a specific user account. An account, as you’ll see later in detail, is the sender or the receiver of a transaction. The coinBalance state variable therefore represents a collection of coin accounts, each holding a number of SimpleCoin tokens.

The transfer function is meant to move a number of SimpleCoin tokens from the coin account of the function caller to a specified coin account. In smart contract terminology, a function caller is the transaction sender. msg is a special implicitly defined variable that represents the incoming message. It has various properties, among which msg.sender represents the address of the sender of the transaction, who is the caller of transfer.

The body of the transfer function is simple to understand. It involves subtracting the specified amount from the cash account associated with the function caller and adding the amount specified in the _amount parameter to the account associated with the address specified in the _to parameter. To keep this initial code simple, this implementation isn’t performing any boundary checks yet on the number of SimpleCoin tokens owned by the transaction sender, who, for example, shouldn’t be allowed to send more tokens than they own. You’ll perform such checks when we revisit SimpleCoin in later chapters.

At this point, you should understand that your SimpleCoin contract is, in practice, a class with a constructor (SimpleCoin function), some state (coinBalance variable), and a method (transfer function). Table 1.2 gives a quick summary of the Solidity keywords you’ve come across.

Table 1.2. A summary of Solidity keywords used in the first code sample

Keyword	Explanation
contract	Type similar to class in any other language
mapping	Data structure similar to a hash table or hash map
address	20-byte value representing an Ethereum user account or contract account
uint256	Unsigned 256-bit integer
msg	Special variable representing an incoming message object
msg.sender	Property of the msg object representing the address of the message sender

1.3.2. Running the contract

Move now to the right side of the screen to deploy the SimpleCoin contract. First, make sure the Auto Compile option in the Compile tab is checked, as shown in figure 1.11, so that Remix will recompile the code at every change. Also, make sure you’ve selected version 0.4.24 of the compiler (for example 0.4.24+commit.e67f0147), because this is the version I’ve been using when writing SimpleCoin.

Figure 1.11. The Auto Compile option in the Compile tab makes sure the code entered in the editor is recompiled at every change.

If you’ve typed your code correctly (I recommend you copy the code from the files provided on the book website!), and no compilation errors have occurred, you should see the following buttons in the Run tab: Deploy and At Address, as shown in figure 1.12. Ignore At Address for now and focus your attention on Deploy. By clicking this button, you’ll deploy the SimpleCoin contract on an emulated blockchain within Remix.

Figure 1.12. Once the code has been compiled correctly, the Run tab will show two buttons: Deploy and At Address. You can instantiate the contract by clicking Deploy.

The contract will be stored against an address on the emulated Ethereum blockchain, and a new Deployed Contracts panel will appear, as shown in figure 1.13. You can read the deployment address by clicking the Copy Address icon and pasting it in Notepad, for example.

Figure 1.13. After deploying the contract, the Deployed Contracts panel appears, containing a drop-down with a SimpleCoin option; click it, and you’ll see the contract operations.

1.3.3. Interacting with the contract

Now that the SimpleCoin contract has been deployed, you’ll be able to perform simple operations against it: you’ll check SimpleCoin token balances and move tokens across accounts.

Click the SimpleCoin drop-down list within the Deployed Contracts panel. Two new buttons will appear: CoinBalance and Transfer, as shown in figure 1.14.

Figure 1.14. SimpleCoin operations buttons: CoinBalance and Transfer. CoinBalance is a getter of the coinBalance state variable and is a read-only operation. Transfer allows you to transfer the specified number of tokens to the indicated address.

The Remix IDE shows two types of buttons:

• Blue buttons—They perform read operations against the contract, such as checking the value of state variables or calling read-only functions.
• Red buttons—They perform write operations against the contract, such as instantiating the contract through the constructor (Create), or call functions that modify any state variables.

In this case, CoinBalance is blue because it allows you to read the coin balance associated with an address. Transfer is red because by clicking it you’ll alter the state of the contract, specifically by changing values contained in the coinBalance mapping state variable.

Now check that the coinBalance associated with the address specified in the constructor has the full initial supply of SimpleCoin you set at construction. Wrap the address with double quotes: "0x14723A09ACff6D2A60DcdF7aA4AFf308FDDC160C". Enter it in the text box and click CoinBalance. Some output will appear. At the bottom, you should see the expected number of SimpleCoin tokens you specified in the constructor: 10,000.

0x14723A09ACff6D2A60DcdF7aA4AFf308FDDC160C is the address of one of the five test accounts present on the Remix IDE. You can see them in the Transaction Origin drop-down list box on the top-right of the screen. Although they aren’t fully visible on the screen, their full addresses are reported in table 1.3. (I’ve retrieved them one by one by clicking the Copy Address icon next to the Account drop-down.)

Table 1.3. Remix test accounts whose full address is hidden behind the HTML

0xca35b7d915458ef540ade6068dfe2f44e8fa733c

0x14723a09acff6d2a60dcdf7aa4aff308fddc160c

0x4b0897b0513fdc7c541b6d9d7e929c4e5364d2db

0x583031d1113ad414f02576bd6afabfb302140225

0xdd870fa1b7c4700f2bd7f44238821c26f7392148

You can double-check that the amount of SimpleCoin tokens associated with any address different from 0x14723A09ACff6D2A60DcdF7aA4AFf308FDDC160C is zero. For instance, enter the following address, wrapped with double quotes as you did earlier, in the CoinBalance text box: "0x583031D1113aD414F02576BD6afaBfb302140225". After clicking the button, you’ll see a zero, as expected.

To recap, when you instantiated the contract, an amount of 10,000 SimpleCoin tokens got assigned as initial money supply to the address starting with 0x14723A09. No other address owns any tokens yet, as summarized in table 1.4.

Table 1.4. Balance of each Remix test account after contract instantiation

Account address	Account balance
0xca35b7d915458ef540ade6068dfe2f44e8fa733c	0
0x14723a09acff6d2a60dcdf7aa4aff308fddc160c	10,000
0x4b0897b0513fdc7c541b6d9d7e929c4e5364d2db	0
0x583031d1113ad414f02576bd6afabfb302140225	0
0xdd870fa1b7c4700f2bd7f44238821c26f7392148	0

Now you’ll call the transfer function to move some tokens from the account with the address starting with 0x14723a09 to a different test account. Because the transfer function moves tokens from the account of its caller, the function must be called from the contract creator’s address starting with 0x14723a09. Pick this address from the Account drop-down at the top right of the Run tab, then enter in the text box of the transfer method the destination address—for example, the address starting with 0x4b0897b0—and a number of tokens to be transferred—for instance, 150 tokens. You should separate the values of these parameters with a comma:

"0x4B0897b0513fdC7C541B6d9D7E929C4e5364D2dB", 150

Now click Transfer. The function returns no result, as expected.

Check the number of tokens present in the contract creator’s address by clicking CoinBalance after entering the contract creator’s address ("0x14723A09AC-ff6-D2-A60Dcd-F7aA4AFf308FDDC160C") in the related text box. The value is now 9,850, as expected.

If you perform the same check on the destination address ("0x4B0897b0513fdC7C541B6d9D7E929C4e5364D2dB"), you’ll get 150. All other addresses still have zero tokens, as summarized in table 1.5.

Table 1.5. Balance of each Remix test account after a transfer operation

Account address	Account balance
0xca35b7d915458ef540ade6068dfe2f44e8fa733c	0
0x14723a09acff6d2a60dcdf7aa4aff308fddc160c	9,850
0x4b0897b0513fdc7c541b6d9d7e929c4e5364d2db	150
0x583031d1113ad414f02576bd6afabfb302140225	0
0xdd870fa1b7c4700f2bd7f44238821c26f7392148	0

As an exercise, you can try to transfer coins from the address starting with 0x4b0897b05 to a different address and recheck if the amounts are correct. While doing so, please don’t perform any crazy transactions yet, such as trying to move more coins than a certain address is holding. To keep the code simple for the moment, you haven’t coded any boundary conditions to handle such situations. You’ll learn about these in the next chapter.

Although the code you’ve written so far is simple, your main objective at this stage was only to start to familiarize yourself with smart contracts, the Solidity language, and Remix. By now, you should have achieved that objective, and you should understand how contract instantiation works and how to interact with a contract from different accounts.

SimpleCoin is still at the stage of an embryonic Dapp. So far, you’ve only executed its code on a JavaScript VM-based simulator and, because it’s lacking a UI, you’ve seen its output through Remix. In the next chapter, you’ll take a step further and install an Ethereum client. You’ll then deploy SimpleCoin to a real Ethereum network and interact with it again.

Warning

If the compiler configured in the Compile tab is version 0.4.25, Remix will only allow you to enter addresses with a valid checksum in the code editor. I’ll explain what a valid checksum is in chapter 5. But for now, it means 0x14723a09acff6d2a60dcdf7aa4aff308fddc160c (all in lowercase) and 0x14723A09ACff6D2A60DcdF7aA4AFf308FDDC160C aren’t interpreted as being equivalent to each other. Unfortunately, addresses in the Account drop-down within the Run tab are all in lowercase and therefore aren’t compliant. If you want to know the corresponding address with a valid checksum, you can use Etherscan, the online blockchain viewer (https://etherscan.io/). Enter the incorrectly formatted address (for example, 0x14723a09acff6d2a60dcdf7aa4aff308fddc160c) in the text box at the top of the screen, and you’ll see the correctly formatted corresponding address (0x14723A09ACff6D2A60DcdF7aA4AFf308FDDC160C) in the Address header also at the top of the screen.

Summary

• A decentralized application is a novel type of application that isn’t owned or controlled by any entity and runs on a trustless decentralized P2P network.
• The topology of a decentralized application is different from that of a conventional, centralized, one because both its business logic layer and its data layer (the blockchain) are fully replicated on each node of the network.
• Dapps rely on blockchain technology, which is based, in turn, on public key cryptography, cryptographic hash functions, and the concept of mining through a consensus protocol.
• Many appropriate use cases exist for decentralizing an application, especially in the fields of provenance and authenticity tracking, identity verification, regulatory auditing, prediction markets, and crowdfunding.
• Decentralized applications aren’t always the best solution for a business problem. For example, it doesn’t make sense to decentralize an internal enterprise application that isn’t shared with any external participant.
• You can implement smart contracts, which are at the heart of Dapps, within the Ethereum platform in a language called Solidity, similar to JavaScript. It’s possible to write simple smart contracts through the Remix Solidity IDE and simulate their activation and interaction with various mock Ethereum accounts.