Exploring Ethereum Dapps (Manning, 2019)

Save 50% on these selected books – eBook, pBook, and MEAP.
Enter ebblockchain50 in the

Promotional Code box when you checkout. Only at manning.com.
Building Ethereum Dapps

Decentralized applications on the Ethereum blockchain
by Roberto Infante
ISBN 9781617295157
504 pages
$31.99
March 2019
Ethereum DApps in Motion

by Julien Klepatch
Duration: 6h 25m
44 exercises
$49.99
Grokking Bitcoin
by Kalle Rosenbaum
ISBN 9781617294648
480 pages
$31.99
April 2019
Licensed to UNKNOWN UNKNOWN <[email protected]>

Exploring Ethereum Dapps
Chapters Selected by Roberto Infante
Manning Author Picks
Copyright 2019 Manning Publications

To pre-order or learn more about these books go to www.manning.com

For online information and ordering of these and other Manning books, please visit
www.manning.com. The publisher offers discounts on these books when ordered in quantity.
For more information, please contact
Special Sales Department

Manning Publications Co.
20 Baldwin Road
PO Box 761
Shelter Island, NY 11964
Email: Candace Gillhoolley, [email protected]
©2019 by Manning Publications Co. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in

any form or by means electronic, mechanical, photocopying, or otherwise, without prior written
permission of the publisher.
Many of the designations used by manufacturers and sellers to distinguish their products are
claimed as trademarks. Where those designations appear in the book, and Manning
Publications was aware of a trademark claim, the designations have been printed in initial caps
or all caps.
Recognizing the importance of preserving what has been written, it is Manning’s policy to have
the books we publish printed on acid-free paper, and we exert our best efforts to that end.
Recognizing also our responsibility to conserve the resources of our planet, Manning books
are printed on paper that is at least 15 percent recycled and processed without the use of
elemental chlorine.
Manning Publications Co.

20 Baldwin Road Technical
PO Box 761
Shelter Island, NY 11964
Cover designer: Leslie Haimes
ISBN: 9781617297106
Printed in the United States of America
1 2 3 4 5 6 7 8 9 10 - EBM - 24 23 22 21 20 19

contents
introduction iv
1 A first look at decentralized applications 1

1.1 What is a Dapp? 2
1.2 Good and bad Dapps 18
1.3 A five-minute Dapp implementation 23
1.4 Summary 30
3 The Ethereum platform 31

3.1 Connecting to Ethereum through the wallet 32
3.2 Smart contracts: The brain of Dapps 37
3.3 Connecting to Ethereum with geth 45
3.4 Managing accounts with geth 59
3.5 Revisiting SimpleCoin’s contract 64
3.6 Summary 71
index 72
iii

introduction
Unless you have been living on Mars in the last few months, you have surely witnessed
the meteoric rise and (hopefully) temporary fall of cryptocurrencies. You have also
definitely heard and read about blockchain, perhaps even about decentralized appli-
cations. But do you know how they actually work?
Although cryptocurrencies are currently in a relative low within their continuous
boom and burst cycle, the underlying technology is here to stay. Decentralized appli-
cations, also known as Dapps, are applications that take advantage of the decentraliza-
tion of peer-to-peer networks with the immutability and untamperability of the
blockchain data structure. In simple terms, you can think of a Dapp as an application
whose logic runs concurrently on thousands of servers, each owned by a different
party, and whose data is stored on the blockchain. Independent execution and cross-
validation on many servers guarantees integrity of the processing; the blockchain data
structure guarantees integrity of its data.
This architecture makes Dapps inherently trustless, which means as a user you do
not need to trust anyone or any institution to be confident your data will get pro-
cessed and stored correctly and as intended. This is guaranteed by the technology.
The potential offered by this innovation is already being harvested to build prove-
nance and supply-chain management systems that allow different companies and insti-
tutions to interact in a trustless fashion throughout the production process of finished
goods such as diamond or medicines, therefore minimizing or eliminating completely
the risk of counterfeiting.
Building Ethereum Dapps will teach you how to build decentralized applications
on the Ethereum blockchain. Not only can you finally understand what happens
under the bonnet of a blockchain and of a Dapp, but you will be able to write smart
contracts in no time, following the best practice, and deploy them onto the Ethereum
network.
In this eBook you will find two sample chapters. Chapter 1 is a general introduc-
tion to decentralized application and blockchain technology. Chapter 3 is more
hands-on: you will have the opportunity to play with Go Ethereum, also known as
iv

INTRODUCTION v
geth, the most popular Ethereum client. I will show you how to launch simple com-
mands, which will allow you to get network and blockchain information and manage
accounts. At the end of each chapter, we will also start building SimpleCoin, a simple
demo cryptocurrency.
I hope you find these chapters interesting and continue your Ethereum learning
journey in the full book!

Chapter 1
Chapter 1 from Exploring Ethereum
Dapps by Roberto Infante
A first look at
decentralized applications
This chapter covers

 What a decentralized application is
 What a Dapp looks like and how it works
 Dapp terminology
 Suitable and less suitable Dapps
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 Well-
Known.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 sud-
denly…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.

2 CHAPTER 1 A first look at decentralized applications
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, proba-
bly 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 applica-
tions. 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 pro-
nounced 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, imple-
ment, 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

What is a Dapp? 3
applications are implicitly centralized with respect to their users. I can hear you ask-
ing, what does “centralized” mean exactly?
A centralized application or system is controlled by a single or central entity: an indi-
vidual, company, institution, governmental agency, and so on. The entity hosts the sys-
tem 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 sys-
tem. You shouldn’t find anything surprising about it.
Entity
A centralized application
is strongly associated with
the owning entity.
Internet Centralized
Trust application
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 alterna-
tive 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 com-
plied with all the conditions associated with the transaction, such as your confir-
mation 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 partic-
ipants 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 inde-
pendent 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 out-
come 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 decen-
tralized 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 elec-
tronic 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 institu-
tion can have the web, application, and database servers hosted directly on the prem-
ises 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

What is a Dapp? 5
as a Service (SaaS) if the voting system is only leased or rented from an external pro-
vider 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 col-
lected, processed, and stored at various levels of the application architecture. Depend-
ing 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 sys-
tem was secured adequately against external manipulation. For example, external par-
ties 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 coor-
dinate 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 organiza-
tion. 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 modi-
fied retroactively.

Entity
Centralized voting application
A centralized voting
application contains
various servers. Each
server plays a different
role, but the owning
Internet entity controls all
Web App DB of them.
server server server
Decentralized voting application P2P network
Internet
A decentralized voting
application runs simultaneously on
each node of a P2P network.
All nodes are equivalent to each
other: each contains both application
logic and a database. A different entity
controls each node.
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 applica-
tion 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 con-
cerns would be addressed:
 Trust —If one of the participants tried to maliciously alter a vote and propa-
gate 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

What is a Dapp? 7
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 man-
aged 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 partici-
pants 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 thou-
sands of servers is an incredibly challenging task, especially if each one is man-
aged 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 phys-
ical 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 spe-
cial 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 mem-
ber 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 con-
taining 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 communi-
cate with a network node located on their premises. So far, this application differs in
no major way from a conventional web application.
Conventional web server

hosting Dapp’s UI
Voting Dapp UI downloaded as

Single-Page Application (SPA)
Candidate1 <Javascript>
Candidate2 Javascript and
Web3.js code
Candidate3 </Javascript>
Candidate4
<HTML>
Vote </HTML>
Voting web app Voting web app code
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.

What is a Dapp? 9
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.
P2P network
Node Node
Node
Node Node
Figure 1.4 A peer-to-peer (P2P) network is made of

Node Node
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 equiva-
lent to each other, within the Ethereum network you have no clear-cut concept of cli-
ent 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.
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

P2P Ethereum network
Nodes communicate Hsk Py

with each other client client
through the Wire
protocol.
Java
C++ client
client Go
client
Parity
Ruby client
client
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.
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 block-
chain. 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 trans-
actions 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

What is a Dapp? 11
Full
node
Mining
node
Full
Mining node
Full node
node
Full Full
node node
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.
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.
 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 perform-
ing 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 min-
ing. 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 propa-
gate 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.

Conventional web server

hosting Dapp’s UI
Voting Dapp UI downloaded as

standard web application containing
only client-side scripting (JavaScript)
Web3.js code
Candidate4
<HTML>
Vote </HTML>
Voting web app Voting web app code
Internet
Full
node
Mining
node
Full
Mining node
Full node
node
Full Full
node node
Figure 1.7 The entire static view of a decentralized voting application, including client and server
sides

What is a Dapp? 13
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 illus-
trates 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 trans-
action 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 cryp-
tographic problem) consolidates the voting transaction among other transac-
tions 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 transac-
tions 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 candi-
date, 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 verifica-
tion 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

1. Vote click
event is
handled by
web page
JavaScript
Web3.js code
Candidate4
<HTML>
Vote 8. Vote </HTML>
confirmation
Voting web app is displayed Voting web app code
on web page
7. During block processing, Transaction 2. Web page

the VoteConfirmation Event JavaScript
from:0x6cba
event is published to VoteConfirmation calls castVote()
candidate:3
subscribed listeners. on Voting
contract and
generates a
transaction
Transaction
Event Internet
from:0x6cba
VoteConfirmation
candidate:3
6. Block is validated,
executed, and
propagated to peers
Peer Local
full node full node
Block 566
tran1652b1
tran27655c
5. Transaction is
Block 566 Transaction 3. Voting transaction
placed on new block;
tran1652b1 from:0x6cba is validated and
block is propagated
tran27655c candidate:3 propagated to peers
to peers
Transaction
from:0x6cba
candidate:3
Peer
Mining node full node
4. Voting transaction
is validated and
propagated to
mining node
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.

What is a Dapp? 15
to raise a VoteConfirmation event on successful completion. The event is pub-

lished to all the clients subscribed to it, including the Dapp web UI.
7 The JavaScript code present on the voting web client contains a callback func-
tion 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 post1 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.
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 soft-
ware 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. Pre-
defined protocols are what determine interactions between classes of individuals
involved in the organization. But such protocols can be designed so that certain indi-
viduals 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
1
Vitalik Buterin, “DAOs, DACs, DAs and More: An Incomplete Terminology Guide,” http://mng.bz/vNrq.

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 pro-
grammed 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 man-
ual protocol rely entirely on the reputation of the individuals following it.
According to these definitions, opinions diverge as to whether blockchain plat-
forms 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 imple-
mentation of easily automated interaction protocols, some think it should be classi-
fied 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 redis-
tributes dividends periodically, depending on its financial success. A pure DAO, on the
other hand, is generally a nonprofit organization, and participants benefit economi-
cally exclusively by contributing to its ecosystem and increasing its internal capital.
NOTE The current widely accepted definition of decentralized application cor-

responds 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 exchang-
ing monetary value, obviously in the form of cryptocurrency rather than con-
ventional 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

What is a Dapp? 17
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.
Decentralized vs. distributed applications

Decentralized applications shouldn’t be confused with distributed applications. The
two concepts have similarities, but they’re not the same thing.
An application is distributed if it runs over multiple servers within a network. The sim-
plest example of a distributed application is a web application, which is typically dis-
tributed over a web server, an application server, and a database server, and possibly
an email server and legacy mainframes. The centralized voting application seen ear-
lier is an example of a distributed application. It’s distributed because it’s spread
over several servers, but it’s also centralized because all the servers are owned by
the same institution.
A distributed application runs over multiple servers of a network. A decentralized
application is replicated in its entirety over each node of a wide network.
DB server
Mainframe
Mainframe
Web server App server DB server
DB server
Email server
Distributed application Decentralized application
Comparison of the structures of distributed and decentralized applications
An application is decentralized if it’s replicated in its entirety over each node of a net-
work, with each node being theoretically owned by a different entity. The higher the
number of entities owning nodes of the network, the more trustful the network in its
entirety is. Obviously, networks that have only a few owners can’t be considered trust-
ful because they don’t truly decentralize the processing.
A centralized application is generally distributed, but decentralized applications can
also be distributed over multiple servers within each logical node.

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 produc-
tion. 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 immuta-
bility, decentralization, security, and resilience. As a result, the main fields likely to be
revolutionized by Dapps are provenance and ownership tracking, authenticity track-
ing, 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 solu-
tions 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 adver-
tised 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 dia-
monds 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

Good and bad Dapps 19
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 com-
pany 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 busi-
nesses 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 man-
age 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; commod-
ities, 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 inter-
est rates at a specific date, or the winner of a sports competition. Aside from specula-
tive 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, sev-
eral 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 coun-
tries is a complex business. As you can see in figure 1.9, it’s generally based on a com-
plicated workflow involving many parties, such as banks that facilitate the payment,
commercial intermediaries that facilitate the distribution, shipping and delivery com-
panies 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.
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 simpli-
fying 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

Good and bad Dapps 21
Insurer
The insurer might inspect

the goods and the
shipping facilities.
Manufacturer Import customs Export customs Supplier

Delivery check Shipping check Delivery
company incoming goods company outgoing goods company
Payment to local bank
Manufacturer’s Correspondent bank Manufacturer’s

bank bank
Electronic invoicing
Invoicing system
Figure 1.9 Typical international trade involving many parties: banks, commercial intermediaries,
shipping companies, insurers, customs officials, and so on
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 crowd-
funding 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 hap-
pen 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 tech-
nology. 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 func-
tionality that a blockchain platform offers will meet your business requirements. More
importantly, consider whether the benefits of using such a platform would be out-
weighed by all the technical limitations and additional complexities that come with
this technology. A sobering blog post titled “Avoiding the Pointless Blockchain Proj-
ect”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:
 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 consid-
ered 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 block-
chain 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 sub-
ject to certain conditions, a commercial transaction might also be subject to real-world
2
Gideon Greenspan, “Avoiding the Pointless Blockchain Project,” http://mng.bz/4Oqg.

A five-minute Dapp implementation 23
conditions that programming logic can’t enforce. A classic example for a non-fully auto-
matically 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 auto-
matically give it back to the lender if the borrower missed an interest payment, the borrow-
ing 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 pro-
gramming. In the rest of the chapter, you’ll start building the smart contract for a cus-
tom 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 cryptocur-
rency 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.
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.

Panels for
File explorer toggle Code editor running code
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.
Listing 1.1 First implementation of SimpleCoin, a basic cryptocurrency
Defines a state variable as a “mapping” between Pragma directive indicating the supported
an address and an integer. A state variable is the version of the Solidity compiler. (The code
equivalent of a member variable. A mapping is supports a compiler later than 0.4.0 but
equivalent to a hash table or hash map. earlier than 0.5.0.)
pragma solidity ^0.4.0;
Defines a contract, which is similar
contract SimpleCoin { to a class in other languages
mapping (address => uint256) public coinBalance; Starts defining the

contract constructor
constructor() public {
coinBalance Defines a function that
➥ [0x14723A09ACff6D2A60DcdF7aA4AFf308FDDC160C] = 10000; moves a number of
} SimpleCoin tokens from
the coin account of the
function transfer(address _to, uint256 _amount) public { function caller to a
coinBalance[msg.sender] -= _amount; specified coin account
coinBalance[_to] += _amount;
Increases Decreases the coin balance 
} the coin of the message sender by the
} balance by specified number of tokens.
Assigns 10,000 SimpleCoin tokens  the specified (The special implicit property
to the coin account with address number of msg.sender represents the
0x14723a09acff6d2a60dcdf7aa4aff308fddc160c tokens address of the sender of the
at contract creation transaction.)

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 rep-
resents 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 ter-
minology, 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 imple-
mentation 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 Simple-
Coin 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 fig-
ure 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 pro-
vided 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.
Click Deploy to instantiate the contract.
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.

Copy address icon
Click here to show the contract operations.
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 sim-
ple 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.
Transfer is a CoinBalance is
write operation. read-only.
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 check-
ing the value of state variables or calling read-only functions.
 Red buttons —They perform write operations against the contract, such as instan-
tiating 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 associ-
ated 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 con-
structor 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 bot-
tom, 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 click-
ing CoinBalance after entering the contract creator’s address ("0x14723A09ACff6-
D2A60DcdF7aA4AFf308FDDC160C") in the related text box. The value is now 9,850, as
expected.
If you perform the same check on the destination address ("0x4B0897b0513f-
dC7C541B6d9D7E929C4e5364D2dB"), 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
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 cer-
tain 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 conven-
tional, 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, regula-
tory auditing, prediction markets, and crowdfunding.
 Decentralized applications aren’t always the best solution for a business prob-
lem. 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 possi-
ble to write simple smart contracts through the Remix Solidity IDE and simu-
late their activation and interaction with various mock Ethereum accounts.

Chapter 3
Chapter 3 from Exploring Ethereum
Dapps by Roberto Infante
The Ethereum platform
This chapter covers

 Interacting with Ethereum through the Ethereum
wallet
 Understanding the characteristics of Ethereum
smart contracts
 Interacting with Ethereum through the Go
Ethereum (geth) client
 Understanding and managing accounts
The previous chapter introduced Dapps and the underlying concepts and techno-
logies, among which is Ethereum. In this chapter, I’ll cover Ethereum in much
greater depth, so you’ll get the foundation you need to develop Dapps on this plat-
form effectively. I’ll begin by presenting the Ethereum wallet, a UI tool you’ll use to
start interacting with the Ethereum P2P network by transferring some Ether, the
Ethereum cryptocurrency. Then you’ll get a wide overview of smart contracts,
the key technology that Ethereum introduced.
After learning about Go Ethereum, one of the many clients available on the
platform, and once you understand the purpose of accounts, you’ll move to the
next level and start interacting with the Ethereum network through Go Ethereum
31

32 CHAPTER 3 The Ethereum platform
in several ways: with commands entered into the operating system shell, with instruc-
tions entered into the Go Ethereum console, and with HTTP requests. At that point,
you should have acquired enough familiarity with the platform to progress with con-
fidence through the rest of the book. It’ll be a dense but rewarding chapter. Let’s
get started.
3.1 Connecting to Ethereum through the wallet

The Ethereum network offers two main graphical user interfaces:
 Mist —A browser for Ethereum Dapps
 Ethereum wallet —A specific version of Mist with a single Dapp bundled in it
You’ll learn about Mist in a later chapter. For the moment, we’ll focus on the Ethe-
reum wallet. The main purpose of the wallet is to store, receive, and transfer Ether,
the Ethereum cryptocurrency. It’s similar to a Bitcoin wallet, if you’ve ever handled
bitcoins, and you’ll initially use it to transfer Ether so that you can start to interact with
the platform in the simplest way. It’s also a useful tool to learn how to deploy smart
contracts and interact with them on one of the public Ethereum networks.
3.1.1 Getting started with the Ethereum wallet

When you open the download page (https://github.com/ethereum/mist/releases),
you’ll find various versions of Mist and the Ethereum wallet. Pick the version of the
Ethereum wallet corresponding to your operating system and download the related
zip file. (I’ve picked Ethereum-Wallet-win64-0-11-1.zip.) After unzipping it, you can
run the executable Ethereum Wallet.exe directly. The first time you launch it, it’ll
default to the main network. In this chapter, you’ll work against the public test Rop-
sten network instead. To select it, you must pick it from the top menu, as shown in
figure 3.1: Develop > Network > Ropsten. You also can select the Ropsten network
through the Alt+Ctrl+2 shortcut.
Select the Ropsten test

network from the menu.
Figure 3.1 Choosing the test Ropsten network from the Develop > Network >
Ropsten menu option or through the Alt+Ctrl+2 shortcut

Connecting to Ethereum through the wallet 33
After you select the Ropsten network, the wallet will start to synchronize with the
related blockchain. By default, the synchronization mode is Light, which, as you saw
in the previous chapter, downloads the current state trie from a peer full node, so you
don’t have to wait long (minutes). This will allow you to get up and running quickly.
But if you want to perform write operations, such as transferring Ether or deploying
smart contracts, which is what you’ll be doing, you must get a full copy of the block-
chain—you can choose between Fast and Full. (Go back to the previous chapter if you
don’t remember how these sync modes work.) Here’s a rough estimate of what to
expect when you’re synchronizing the Ropsten blockchain locally:
 Fast —Uses roughly 1 GB of disk space and takes two to four hours
 Full —Uses roughly 100 GB of disk space and can take up to a day or two
Once you’re synchronized, you’ll be able to see synchronization details at the top of
the screen, including the name of the network you’re connected to, the latest block
number, and the number of seconds passed since receiving the last block, as shown in
figure 3.2.
Figure 3.2 You can see synchronization details,

including the name of the network and the latest
Network name Latest block block number, at the top of the screen.
WARNING To perform the operations I’ll cover in this chapter and the next,
you must choose Fast or Full synchronization; otherwise, you won’t be able to
transfer Ether or deploy a contract through the wallet. To be able to execute
a transaction, you must have a full local copy of the blockchain. If the wallet
appears unresponsive after a while and you don’t notice any progress in the
synchronization, it might be because the wallet hasn’t managed to connect to
any peer nodes. In that case, close it down and try to synchronize the Ropsten
blockchain through the geth client. If you need to do this, read about geth in
section 3.3, and then synchronize it to Ropsten as explained in chapter 8, sec-
tion 8.1.
At this point, you’re ready to create accounts. Click the Wallets tab, which will bring
you to the Accounts Overview screen, and then click the Add Account button, which
has a plus symbol next to it, as you can see in figure 3.3.
You’ll see a small dialog box asking for a strong password. (Make sure you stretch
the dialog from the bottom-right corner until you see the OK button.) After entering
a password (twice), you’ll be reminded to back up your keyfiles (more on this later)
and password.

Click here to create a

new account.
Figure 3.3 Accounts overview screen. You can create an account by clicking Add Account.
WARNING Manage your passwords carefully. If you forget your password, you
won’t be able to click any “I Forgot My Password” button. Losing your password
means losing the Ether stored in the account. This isn’t a major problem
when pointing to a test network, because Ether has no value there. But, espe-
cially when moving to the production network, you should get into the habit
of choosing a strong password and keeping a copy of it somewhere secure.
Better safe than sorry!
NOTE If you’re using the Ethereum wallet for Mac OS or LINUX, the inter-
face is slightly different, screenshots won’t match what you see, and my
descriptions might not work to the letter. Also, the default network shown
might be different. But you should be able to find alternative ways to perform
the operations I describe.
After the wallet has generated the account, on the Accounts Overview screen you’ll
see Account 1 with the related hexadecimal address and a balance of zero Ether. I’ll
cover accounts in more detail later; for now, create one more account in the same way,
and you now should see two accounts on the screen, as shown in figure 3.4. Now that
you have a couple of accounts (feel free to create more), you can try out some com-
mon operations with the wallet.

Connecting to Ethereum through the wallet 35
Account balance Account address

Figure 3.4 Account details shown on the Accounts Overview screen after their creation
3.1.2 Performing common operations with the wallet

With a balance of zero Ether (the Ethereum cryptocurrency) on all your accounts,
you won’t be able to go too far, because as you’ll learn, to execute transactions on the
network, you must pay transaction costs in Ether. Because it isn’t possible to buy Ether
in the test network, you’ll have to generate it somehow. One way is through mining.
MINING
Mining is the process through which new transactions get consolidated into blocks of
the blockchain. Many participants in the Ethereum network run special mining nodes
through which they hope to be rewarded in Ether tokens and be compensated for the
computational power they provide to the network. Although mining Ether in the real
public network is challenging and requires specialized hardware based on advanced
GPU chipsets, it’s easy to generate Ether in the test network with “plain CPU” mining
through the wallet menu:
Develop > Start Mining (Testnet only)
NOTE The menu option Develop > Start Mining will appear only after the
blockchain has been entirely synchronized in Fast or Full mode.
The CPU of your machine will get busy, and after a few minutes you should have accu-
mulated enough Ether to get going.
If for any reason mining is taking too long, an alternative way to fund your Ropsten
accounts is through the so-called faucet. The following URL can send your addresses
free test Ether: http://faucet.ropsten.be:3001/donate/<destination address>, for exam-
ple, http://faucet.ropsten.be:3001/donate/0x8713Cb74c7DB911f2056C8DD2bA5036-
7eeEa11D0. After a few seconds, your destination address should receive 1 Ether, as
you can see in figure 3.5. You can check the status of the Ether transfer from the fau-
cet by entering your address in the text box at the top of the Ropsten Etherscan web-
page: https://ropsten.etherscan.io/. If faucet.ropsten.be isn’t working as expected or
you keep getting gray-listed, try https://faucet.kyber.network/. Alternatively, try Goo-
gle ropsten faucet.

Figure 3.5 Account balances after using the faucet facility
TRANSFERRING ETHER
Now you can try to move some Ether between accounts. It’s easy. First, go to the Send
screen. Select the source (Account 1) and target account addresses (copy the address
of Account 2 from the Accounts Overview screen), then select the amount of Ether
you want to transfer—for example, 0.5 Ether. Finally, after deciding on a transaction
fee, click Send Transaction. Don’t worry too much about this for now; we’ll examine
transaction fees later.
You’ll be prompted to enter a password, as shown in figure 3.6. Enter the password
of the source account (Account 1) to digitally sign the transaction and subsequently
prove that the account owner is sending it, and then click Send Transaction. You’ve
now completed your first Ether transaction!
Figure 3.6 Password entry screen for moving Ether between accounts. You’re
required to enter the password of the sending account when transferring Ether
with the Ethereum wallet, to digitally sign the transaction and consequently prove
it’s genuinely the account owner who’s sending the Ether.

Smart contracts: The brain of Dapps 37
To check the status of the transaction, go back to the Accounts Overview screen and
click Latest Transactions at the bottom of the screen. Clicking on the related link will
allow you to drill down into further details, such as those shown in the screenshot in
figure 3.7.
Figure 3.7 Summary transaction information from the Transactions panel

of the Accounts Overview screen
You can get a better idea of how your transaction has contributed to the Ropsten
blockchain by checking it on Etherscan, a website reporting the real-time evolution of
the Ethereum blockchain. Use this URL to access the test network: https://ropsten
.etherscan.io/. You’ll be able to get detailed block and transaction information.
Now that you’ve acquired some familiarity with Ethereum, it’s time to learn more
about one of the greatest innovations that this platform introduced: smart contracts.
Once you grasp how smart contracts work, you’ll be able to make further progress on
SimpleCoin, the cryptocurrency you started to build in the previous chapter.
3.2 Smart contracts: The brain of Dapps

As I described in chapter 1, an Ethereum smart contract, or simply contract, is a soft-
ware artifact containing business rules and a state. It’s written in a high-level language
such as Solidity, compiled into EVM bytecode, deployed onto the Ethereum network,
and stored on its blockchain against a specific account generated at deployment.
As shown in figure 3.8, a contract receives transaction messages from a user
account (or from other contracts) and executes its logic on the Ethereum Virtual
Machine (EVM). This might optionally involve sending messages to other contracts,

1. A user starts a transaction 2. A contract function executes its 3. The contract reads/writes
message by invoking a contract logic on the EVM. its state from/to the blockchain.
function, for example vote(), from
an account containing some Ether. Ethereum node
Ethereum Virtual Machine (EVM) Blockchain
VotingContract
vote()
User account Transaction Transaction

Internet
address: 0x6cba from:0x6cba from:0x6cba
ether: 2.678 VotingContract.vote() VotingContract.vote()
ContractA ContractB
5. The transaction cost for the computational

resources consumed during the execution ContractC ContractD
of the contract function is calculated in a unit
called gas and charged to the user in Ether.
4. While a contract function is executing,

it might call external contract functions that
get executed on the EVM.
Figure 3.8 An Ethereum contract receives a transaction message from a user account. Its logic is executed on
the Ethereum Virtual Machine (EVM); then the successful miner calculates the cost for the computational and
network resources used, in a unit called gas, and charges the user account in Ether.
reading state from the blockchain, or writing state to the blockchain (specifically
from/to the State Merkle-Patricia trie). The account sending the message to the con-
tract gets charged (in Ether) by the successful mining node for computation and net-
work resources consumed during the processing of the requested operation. The
amount of such computation and resources is calculated in a unit called gas, as you’ll
see in section 3.2.3, so it’s common to say that a transaction consumes a certain
amount of gas (rather than resources).
If you want to understand smart contracts, how they get instantiated by users and
by other contracts, and especially how they get executed, you need to go in greater
detail through various concepts I’ve only touched on so far:
 Accounts
 Ether and gas
 Transaction messages
 The Ethereum Virtual Machine
I’ll start by telling you more about the various types of accounts.

3.2.1 Accounts
You’ve already come across the concept of accounts a few times. Accounts are available
in two types:
 Externally owned accounts (EOA) (or simply External Accounts)—These are also
known informally as user accounts. They’re publicly identifiable from their pub-
lic key, but they can only be operated by knowing the private key. If you buy
some Ether, you’d store it in this type of account. Also, you’d start a transaction
against a smart contract from an EOA.
 Contract accounts —These are the accounts that contracts are executed under.
The account address is generated at deployment time, and it identifies the loca-
tion of the contract in the blockchain.
Both EOAs and contract accounts hold data in the form of a key-value store and an
Ether balance. Table 3.1 compares the main properties of EOAs and contract accounts.
Table 3.1 Comparison between an EOA and a Contract Account
Property Externally owned account Contract account
Has Ether balance Yes Yes
Can start transaction message Yes No
Can start call message No Yes
Has code No Yes
3.2.2 Ether
I’ve mentioned Ether casually a few times, so it’s probably time you learned more about
it. Ether is the cryptocurrency that the Ethereum blockchain supports. Its main pur-
pose is to represent monetary value for services and goods traded over the platform.
Ether is also used to pay for transaction fees. These are, as mentioned in section 3.2
and covered more in section 3.2.3, calculated in a unit called gas, which measures
computational resources that a transaction consumes. But these fees are settled in
Ether (calculated from the price of a unit of gas, expressed in Ether). Miners charge
transaction fees to get compensated for the computational power they provide the
network while appending new transaction blocks to the blockchain.
Ether comes in various denominations, which are all defined, as you can see in
table 3.2, as a multiple of Wei, the smallest Ether denomination.
Table 3.2 Ether denominations and values in Wei
Unit Wei value Wei
Wei 1 Wei 1
Kwei (Babbage) 1e3 Wei 1,000

Table 3.2 Ether denominations and values in Wei
Unit Wei value Wei
Mwei (Lovelace) 1e6 Wei 1,000,000
Gwei (Shannon) 1e9 Wei 1,000,000,000
Microether (Szabo) 1e12 Wei 1,000,000,000,000
Milliether (Finney) 1e15 Wei 1,000,000,000,000,000
Ether 1e18 Wei 1,000,000,000,000,000,000
Figure 3.9 summarizes the Ether lifecycle, which goes through the following steps:
1 Minting Ether
2 Transferring Ether
3 Storing Ether
4 Exchanging Ether
Mining 1. Minting Ether

node
Miner account
address: 0xab32c
Ether is minted into Ether: 200.678
the account of the miner.
2. Transferring Ether
Ether is transferred
from a miner account
You can buy Ether
to other accounts. You can manage Ether stored
from exchanges by paying
in an account with a variety
for it in real currencies.
3. Storing of wallets based on different
4. Exchanging Ether technologies.
Ether User account
$ address: 0x4dac2
Ether: 12.67
Mobile
wallet
£ Cryptocurrency
exchange 4. Exchanging
Ether Desktop
You can sell Ether to wallet
exchanges and get it
converted into real
currencies.
Online
$ wallet
¥ Paper Hardware
wallet wallet
Figure 3.9 The Ether lifecycle. Ether is minted by miner nodes into miner user accounts. Then it’s transferred to
EOAs (also known as user accounts). From there, it can be stored on various wallets. Ultimately, it can be
converted to real currency, such as USD, EUR, YEN, GBP, and others, through cryptocurrency exchanges.

MINTING ETHER
If you’re unfamiliar with cryptocurrencies, you must be wondering how Ether is
minted and exchanged. Ether is generated through the mining process, during which
miners compete to group and append transactions into new blockchain blocks, as I
discussed in section 1.1.2. When successful, a miner gets rewarded with a certain num-
ber of Ether coins. Blocks are added to the Ethereum blockchain every 15 seconds or
so, and the money supply increases accordingly.
TRANSFERRING ETHER
Once Ether has been generated, it’s allocated to the miner’s external account. Miners
can then transfer Ether to other external accounts or contract accounts, either through
the Ethereum wallet or programmatically, as you’ll see later.
EXCHANGING ETHER
Because Ether is valuable, it doesn’t generally get transferred for free between accounts.
It’s often transferred in return for goods and services traded through smart contracts,
but also in return for conventional currency, such as US dollars, euros, pounds, yen, and
so on. Although it’s possible to buy Ether from individual owners and pay them an
agreed amount of conventional currency, it’s more effective to handle such transactions
using cryptocurrency exchanges. Two main types of exchanges are available: central-
ized, such as Kraken, Coinbase, and Coinsquare, and decentralized, such as EtherEx.
Each exchange is generally biased toward a specific real-world currency.
STORING ETHER
Once someone acquires Ether, whether through mining, smart contract trading, or
exchange-based trading, it’s allocated to an account. You can manage accounts using
many methods, each with a different trade-off between convenience and security. The
most convenient one is generally through desktop or online wallets, which allow you
to transfer Ether easily. The most secure one is through cold or paper storage, which
means generating the private key offline and holding it literally on a piece of paper.
Hardware wallets present another high-security option and are conceptually similar to
paper wallets because they can be considered offline. The main difference is that the
account owner stores the private key on a small electronic device similar to a USB key.
Table 3.3 summarizes the different options.
Table 3.3 Wallet types and their characteristics
Wallet type Convenience Security Examples
Desktop wallet High High Ethereum wallet, Exodus
Mobile wallet High Low Jaxx
Online wallet High Medium MyEtherWallet, Coinbase, Kraken
Hardware wallet Medium Very high Trezor, Ledger Nano, KeepKey
Paper storage Low Very high EthAddress

I’ve mentioned that transaction fees are charged in Ether but calculated in a unit
called gas. Let’s see what gas is and how it’s related to transaction costs.
3.2.3 Gas
Gas is the unit of measure for transaction fees charged on the Ethereum platform.
The amount of gas used to complete a transaction depends on the amount of compu-
tational resources that the EVM spends while running the transaction. Specifically, it
depends on the exact low-level EVM instructions that have been executed during the
transaction. Table 3.4 gives an idea of the amount of gas charged for the most com-
mon EVM operations.
Table 3.4 Gas cost for simple EVM operations
Operation EVM op code Gas cost
Addition, subtraction ADD, SUB 3
Multiplication, division MUL, DIV 5
Comparison LT, GT, SLT, SGT 3
Load word from memory MLOAD 3
Store word to memory MSTORE 3
Load word from storage SLOAD 200
Storing word into storage SSTORE >5000
Contract creation CREATE 32000
The main reason the execution of a transaction is charged in units of gas, and indi-
rectly in units of computational work, is to prevent denial of service (DoS) attacks by
unscrupulous participants who might want to disrupt the network. To launch a DoS
attack, a malicious participant would have to spam the network with a high number of
transactions, each performing a large amount of computational work; for instance, an
infinite loop. The amount of gas corresponding to this work would be high, and it
would have to be paid in a correspondingly high amount of Ether—it’s unlikely any-
one would pay to disrupt a service!
Most smart contract development IDEs give an idea of the total amount of gas
required to complete a transaction. For example, in the screenshot in figure 3.10, you
Figure 3.10 Transaction costs for the execution of the SimpleCoin transfer function

can see a gas estimate for the execution of the transfer function of the SimpleCoin
contract from the last section of chapter 1, obtained by clicking the Details button on
the output panel.
Transaction fee costs are calculated according to this formula: transaction fees (in
Ether) = number of units of gas consumed * price per unit of gas (in Ether). Let’s
break it down:
 The EVM determines the number of units of gas consumed while running the trans-
action, and that depends on the computational cost of the code being run
during the transaction.
 The sender of the transaction decides the price of a unit of gas (in Ether). The
higher it is, the more likely it is that miners will include the transaction in the
block they’re processing. Miners prioritize transactions that are likely to pay
high fees, so if a transaction is expected to consume a relatively low amount of
gas, the sender will have to set a relatively high gas price to guarantee quick pro-
cessing.
 The transaction sender sets a limit for the maximum amount of gas that a transac-
tion should consume. This protects the sender from higher-than-expected
transaction costs due to execution of the code in a way different from what was
intended; for instance, if the developer introduces a bug that causes an infinite
loop. Such limits should be relatively close to the estimated amount of gas
needed to complete the transaction.
While a transaction is being executed, the EVM consumes its gas. Two outcomes are
possible at the end of the transaction:
1 The transaction completes successfully. In this case, the unused gas is returned to the
sender.
2 The amount of gas available ends before the completion of the transaction. In this case,
the EVM throws an end of gas exception, and the transaction is rolled back.
You might be wondering who pockets the transaction fee. Given either of the two
transaction outcomes, the miner who has processed the transaction receives the fee.
For the first outcome, they earn the fee by including the transaction in a new block
that has been successfully appended to the blockchain. For the second outcome, even
though the EVM throws an exception, the miner still charges the gas in Ether, and
they collect the related transaction fee as usual. In short, a successful miner is
rewarded by minting new Ether and getting transaction fees from the transaction
senders. In the early stages of the Ethereum platform, most of a miner’s profits came
from minting.

3.2.4 Calls and transactions

Accounts interact with each other through two types of messages: calls and transac-
tions.
CALLS
A call is sent through a message that doesn’t get stored on the blockchain and whose
execution has the following characteristics:
 It can only perform read-only operations, which don’t alter the state of the
blockchain.
 It doesn’t consume any gas, and consequently, it’s free.
 It’s processed synchronously.
 It immediately returns a return value.
 It doesn’t allow transferring Ether to the contract account.
Typical calls are direct invocations of contract member variables, including mappings,
and invocations of so-called constant functions, which don’t alter contract state. You
performed calls, for example, when you checked account balances of SimpleCoin, the
basic cryptocurrency you started to build at the end of chapter 1.
TRANSACTIONS
A transaction, which I introduced to you in the Dapp dynamic view in chapter 1, is
sent through a message that gets serialized and stored on the blockchain during the
mining process. It contains the following fields:
 Sender address
 Recipient address
 Value —Amount of Ether to be transferred (in Wei), in case the message is being
used to transfer Ether (optional)
 Data —Input parameters, in case the message is being used as a function call
(optional)
 StartGas —Maximum amount of gas to be used for the execution of the mes-
sage. If this limit is exceeded, the EVM throws an exception and rolls back the
state of the message.
 Digital signature —Proves the identity of the transaction sender
 GasPrice —The price of a unit of gas (expressed in Ether) the transaction initia-
tor is willing to pay, as discussed in the gas section
You executed transactions when you performed SimpleCoin transfers. The execution
of a transaction has the following characteristics:
 It can perform write operations, which alter the state of the blockchain.
 It consumes gas, which must be paid for in Ether.
 It’s processed asynchronously: it gets executed through mining and then gets
appended on a new blockchain block, which gets broadcast throughout the
network.

Connecting to Ethereum with geth 45
 It immediately returns a transaction ID, but not a return value.

 It allows transferring Ether to the contract account. (The Ether transfer becomes
part of the transaction itself.)
By now you know contracts are executed on the EVM on each node of the Ethereum
network. I’ll provide a quick overview of how the EVM works.
3.2.5 The Ethereum Virtual Machine

The Ethereum Virtual Machine (EVM) is a stack-based abstract computing machine,
similar in purpose to the Java virtual machine (JVM) and to the .NET Common Lan-
guage Runtime (CLR). It enables a computer to run an Ethereum application and has
two memory areas:
 Volatile memory, or simply memory. This is a word-addressed byte array, which gets
allocated to a contract at every message call. Reads access 256-bit words,
whereas writes can be performed on a width of 8 or 256 bits.
 Storage. This is a key-value store where both key and value have a width of 256
bits. Storage is allocated to each account and is persisted on the blockchain. A
contract account can access only its own storage.
EVM opcodes cover operations including Boolean, bitwise, and arithmetic compari-
sons and jumps (both conditional and unconditional). These are the main opcodes
handling contract creation and calls:
 CREATE—This performs the creation of a new contract instance.
 CALL—A contract sends a message to itself or other contracts through this operator.
 DELEGATECALL—This operator allows the calling contract to send a message to
an external contract but execute the related code in the context of the caller.
This operator is especially useful for the creation of libraries of shared code
that multiple contracts can access.
The EVM is completely sandboxed: a contract can’t access network or filesystem
resources. It can only access other contracts. A more in-depth explanation of the EVM
is outside the scope of this book. The best reference for understanding its design is
Gavin Wood’s so-called Yellow Paper: http://gavwood.com/paper.pdf.
At this point, you’ve consolidated your knowledge on smart contracts. Now it’s
time to take a step further and connect to the Ethereum network through a proper
client: the Go Ethereum client.
3.3 Connecting to Ethereum with geth

Before you start installing a client, I’d like to give you a more detailed overview of the
Ethereum network, which I started introducing in chapter 1. It’ll help you understand
the wider context that a client fits in.
You already know the Ethereum network is a peer-to-peer (P2P) network, which
means there’s no central master or server node coordinating them. Consequently, all
nodes are clients to each other. Nodes are designed to work and communicate with

each other in exactly the same way, according to a predefined protocol called Wire,
described in the Yellow Paper. This means all nodes must be able to append new trans-
action blocks to the blockchain (if mining is activated) and verify them while blocks
get propagated throughout the network.
From an implementation point of view, the network contains two broad categories
of nodes:
 Miners —They process the latest transactions and consolidate them into the
blockchain in exchange for transaction fees and a mining reward (in Ether) if
they manage to execute the consensus algorithm successfully. In that case, they
propagate the blocks they’ve consolidated onto the blockchain to other peers
of the network. Because these nodes generate new blocks, they’re considered
producers (although they’re technically also still consumers).
 Full nodes —They mainly verify the validity of the blocks they’ve received from
neighboring peers and keep propagating them to the rest of the network.
Therefore, they’re considered consumers.
Mining nodes run on clients optimized for processing transactions, generating blocks,
and executing the Proof of Work algorithm efficiently, to get rewarded relatively fre-
quently. Mining implementations, such as ethminer, have been written in C++ and use
GPU libraries such as NVIDIA’s CUDA. Consequently, they run on GPU hardware that
can deliver superior performance.
On the other hand, full nodes don’t have performance requirements, so standard
clients have been implemented in various languages. Table 3.5 summarizes the main
client implementations available to date, ordered by popularity, as reported in Ether-
nodes (https://ethernodes.org/network/1).
Table 3.5 Ethereum client implementations by language
Client Language
Go Ethereum (geth) Go
Parity Rust
Cpp-ethereum (eth) C++
Ethereum(J) Java
Pyethapp Python
ethereumjs-lib JavaScript
ruby-ethereum Ruby
ethereumH Haskell
Each client comes with a console, and some of them also include a graphical browser
or a wallet. While working with this book, you’ll use Go Ethereum, also known as geth,
which is the most popular client, installed on over 70% of the network nodes.

3.3.1 Getting started with geth

The download page for the Go Ethereum website, https://ethereum.github.io/go-
ethereum/downloads/, shows releases for all major operating systems: Android, iOS,
Linux, MacOS, and Windows. Various installation formats are available for some of the
supported operating systems. For example, for Windows, you can choose between the
32- and 64-bit version and whether to download only the executable (Archive option) or
the full installer (Installer option). I’ve picked the 64-bit Geth & Tools 1.8.13 archive.
Once you’ve installed or uncompressed the relevant file, you can run the geth exe-
cutable. If you have the Ethereum wallet open, close it before starting geth, because
they use the same port number! If you run geth with no parameters, it’ll start to syn-
chronize in Full mode with the public production network, also known as MAINNET,
as shown in the screenshot in figure 3.11.
Figure 3.11 geth synchronizing with the MAINNET network at startup
After geth has synchronized the full blockchain (this could take from hours to days,
depending on your hardware and internet connection), the console will start to slow
down and show blocks being added to the blockchain in real time.
NOTE As for the wallet, you can synchronize geth in Light or Fast mode—for
example, C:\program files\geth>geth –-syncmode "light"—if you prefer
to get up and running more quickly (in minutes as opposed to hours or even
days) and don’t mind not having downloaded the full blockchain locally.
You can interact with geth in two ways:

 Through the user-friendly geth interactive JavaScript console
 Through low-level JSON-RPC calls over HTTP

I’ll present both techniques to you. Let’s start with the simpler tool: the interactive
JavaScript console.
3.3.2 A first look at the geth interactive console

geth comes with an interactive console that accepts JavaScript instructions. It implic-
itly references Web3.js, a JavaScript implementation of Web3, the official high-level
library for interacting with Ethereum clients. This console is similar in purpose to
read-eval-print loop (REPL) consoles for programming language IDEs. I’ll cover
Web3 extensively in the next few chapters. For the moment, let’s get a quick feel for it.
First, open the interactive console. You’ve got two possible ways to start it up:
 If no geth clients are running on the same machine, run the geth executable
with the console command:
C:\program files\geth> geth console
 If a geth client is already running on the machine, attach to a running geth pro-
cess with the attach command:
C:\program files\geth> geth attach ipc:\\.\pipe\geth.ipc
You have a running geth process, so you’ll go for the second option.
NOTE In this book, I’m assuming you use Windows, as over 60% of the nodes
of the Ethereum network run on this operating system. Consequently, I’ll
show shell commands with a Windows command prompt format. Also note
that after successful execution of instructions in the console, you might see
undefined right before or after the correct results. You can ignore it.
DISPLAYING VERSION INFORMATION
First of all, you can query the console for version information. A Web3 object named
web3 is implicitly instantiated when opening the console, so you can access version
information in this way by typing
> web3.version
and you’ll see something like

{
api: "0.20.1",
ethereum: "0x3f",
network: "1",
node: "Geth/v1.8.13-stable-225171a4/windows-amd64/go1.10.3",
...
As you can see, the version property is an object that contains many subproperties. If
you want, you can be specific and query an individual property of the version object:
> web3.version.api


"0.20.1"
Because the console accepts JavaScript instructions, it’s possible to assign the values of
Web3 properties and subproperties to variables and then display them through the
console object:
> var apiVersion = web3.version.api
> var nodeVersion = web3.version.node
> console.log(‘Api version: ' + apiVersion)
> console.log(‘Node version: ' + nodeVersion)
CHECKING CONNECTIVITY
You can get some client connectivity information from the web3.net object. (You can
omit the web3 namespace because it’s implicitly referenced.) If you type
> net
you’ll see something like

{
listening: true,
peerCount: 2,
version: "3",
getListening: function(callback),
getPeerCount: function(callback),
getVersion: function(callback)
}
As for the version object, you can directly access individual properties of the net object
as follows:
> console.log('this geth instance is listening for network connections : ' +
web3.net.listening)
> console.log('number of peers connected to this geth instance: ' +
web3.net.peerCount)
If you want to get more detailed information about your node, you can use the
web3.admin object and call
> admin.nodeInfo

{
enode: "enode://90946319e42ef4d4670c1d7...,
id: "90946319e42ef4d467...,
ip: "::",
listenAddr: "[::]:30303",
name: "Geth/v1.8.13-stable-225171a4/windows-amd64/go1.10.3",
...

The peers property gives you detailed information about the peers you’re connected to:
> admin.peers
will yield something like

[{
caps: ["eth/62", "eth/63"],
id: "0b64924d478abaf6900ffe...,
name: "Geth/v1.6.1-stable-021c3c28/linux-amd64/go1.8.1",
network: {
localAddress: "192.168.1.108:53557",
remoteAddress: "136.144.129.222:30303"
},
...
ACCESSING THE BLOCKCHAIN

The web3.eth object retrieves real-time information about the client and the block-
chain. Look at the console of the geth process currently running. You should see how
new blocks are getting appended to the blockchain in real time. Take note of the
block number of a recently appended block, and then switch back to the JavaScript
console.
You can get the most recent block number through the eth.blockNumber property:
> var latestBlockNum = eth.blockNumber
> console.log('Latest block #: ' + latestBlockNumber)
Then you can display summary information about this block by calling
> eth.getBlock(latestBlockNum)

{
difficulty: 64344784,
extraData: "0xd7830106078467657...,
gasLimit: 4723091,
gasUsed: 262264,
hash: "0x8196edb66315b460f0bd4b9bdfa884...,
nonce: "0x2ac78a350ec95787",
number: 1732206,
...
You also can drill down at transaction level. You can get the first transaction stored in
the latest block in this way:
> eth.getTransactionFromBlock(latestBlockNum, 0)
You’ll see something like

{
blockHash: "0x8196edb66315b460f0bd4b9bdfa88...,
blockNumber: 1732206,

from: "0x392fd4954de442bb6c4d57f1923b4708642d3408",
gas: 210000,
gasPrice: 120000000000,
hash: "0x4eb5ae8d7b7919f92d1dd02fcc407d6...",
...
I encourage you to have a look at the content of the whole eth object:
> eth
PERFORMING ETHER CONVERSIONS

The Web3 API offers some useful functions to convert any Ether denomination from/to
Wei. You can convert a Wei amount to a specific denomination:
> var amountInWei = 12000000
> var amountInSzabo = web3.fromWei(amountInWei, 'szabo')
> console.log(amountInWei + ' Wei is equivalent to ' + amountInSzabo + '
szabo')
12000000 Wei is equivalent to 0.000012 szabo
And you can convert a specific denomination into Wei:

> var amountInEther = 12
> var amountInWei = web3.toWei(amountInEther, 'Ether')
> console.log(amountInEther + ' Ether is equivalent to ' + amountInWei + '
Wei')
12 Ether is equivalent to 12000000000000000000 Wei
3.3.3 A first look at JSON-RPC

Now that you’ve learned the basics of the JavaScript console, you can try to interact
with geth by performing a few JSON-RPC calls. geth offers a remote procedure call
(RPC) interface that allows you to access node functionality and blockchain data to a
much finer degree of control than that offered by the Web3 API. In fact, Web3 is built
on top of the RPC layer, which is the lowest level API exposed by the Ethereum plat-
form, as shown in figure 3.12.
geth console curl commands

on OS console
Web3.js is a high-level You can perform low-level JSON-RPC

JavaScript API that wraps Web3.js API API instructions interactively
the low-level JSON-RPC with curl commands on an OS shell.
API for easier consumption.
You can execute Web3.js JSON-RPC API
instructions interactively
from the geth console.
Go Ethereum client
Figure 3.12 Comparison between accessing geth through Web3.js and JSON-RPC

The RPC interface has been designed against the JSON-RPC 2.0 standard, and conse-
quently it sends and receives data in JSON format. You can find more information on
JSON-RPC in the sidebar.
If you want to communicate with geth directly through JSON-RPC, you have to do
two things:
1 Stop any instance of geth running in a standard operating system command
shell or in a geth console.
2 Start geth in RPC mode using the --rpc and --rpcapi options:
C:\program files\geth>geth --rpc --rpcapi "eth,net,web3,personal"
When you launch geth in RPC mode, it’s accessible through an HTTP server that
accepts HTTP requests, by default on
http://localhost:8545
JSON-RPC
JSON-RPC is a lightweight remote procedure call that uses JSON as a data format.
You invoke an RPC call by sending a request object to a server, typically over HTTP,
or in any other way, such as socket or even messaging, because the transport layer
isn’t part of the protocol.
The request object must contain the following members:
 jsonrpc—This sets the protocol version, currently 2.0.
 method—Name of the remote procedure to be called.
 params—Array with procedure parameters.
 id—A call identifier, typically a string or integer. It must be not null.
After the server processes the call, it replies with a response object, which contains
the following members:
 jsonrpc—This sets the protocol version, currently 2.0.
 result—This field is present if the response is successful; it isn’t included if
errors occur.
 error—This field is present if errors occur; it isn’t included if the response is
successful.
 id—Same as specified in the request.
You’ll perform JSON-RPC calls to geth’s HTTP server using the cURL console com-
mand. To help you appreciate the differences between the Web3 API and the JSON-
RPC API, I’ll show you how to execute in cURL the same operations you performed in
Web3 through the interactive console.

NOTE cURL is available in most operating systems, including Windows (ver-

sion 7 and 10) and Linux. Alternatively, you can either download from the
internet an open source version of cURL or perform HTTP requests through
a graphical tool such as Postman, if you prefer.
DISPLAYING VERSION INFORMATION
You can retrieve version information about the geth client with this call:
C:\>curl -H "Content-Type: application/json" -X POST --data
{\"jsonrpc\":\"2.0\",\"method\":\"web3_clientVersion\",\"params\":[],\"id\":2
3} http://localhost:8545
{"jsonrpc":"2.0","id":23,"result":"Geth/v1.6.5-stable-cf87713d/windows-
amd64/go1.8.3"}
(If you’re using Windows, you must escape JSON double quotes, as explained in the
sidebar.) The result is equivalent to what you got from web3.version.node.
cURL JSON escaping on Windows

cURL operations must escape the double-quote symbol " with \" in the JSON POST
data, in certain versions of Windows. For example, in a command shell in Windows,
you perform the request this way:
{\"jsonrpc\":\"2.0\",\"method\":\"web3_clientVersion\",\"params\":[],\"i
d\":23} http://localhost:8545
And in Linux:
$curl -H "Content-Type: application/json" -X POST --data
'{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":23}'
CHECKING CLIENT CONNECTIVITY

You can get connectivity information by performing several calls. For instance, to
check whether the client is actively listening for network connection, you must exe-
cute this request:
{\"jsonrpc\":\"2.0\",\"method\":\"net_listening\",\"params\":[],\"id\":23}
And you’ll get

{"jsonrpc":"2.0","id":23,"result":true}
The result is equivalent to web3.net.listening.

To get the number of peers connected to the client, you must execute this call:
{\"jsonrpc\":\"2.0\",\"method\":\"net_peerCount\",\"params\":[],\"id\":23}
And you’ll get

{"jsonrpc":"2.0","id":23,"result":"0x6"}
The result, which contains numbers encoded in hexadecimal format, as explained in

the sidebar, is equivalent to web3.net.peerCount.
Numbers through JSON-RPC

Ethereum’s JSON-RPC interface handles numbers differently than the official JSON-
RPC 2.0 specification does. Numbers sent and returned through JSON-RPC must
be encoded in hexadecimal format. Doing so makes sure each client implementa-
tion parses and processes large numbers appropriately, independent of the sup-
port for large numbers that the underlying language in which the client has been
coded provides.
Hexadecimal encoding should include a 0x prefix and at least one valid digit with no
leading zeros, as shown here:
This is equivalent to
0x4d2
1234 in decimal.
Here are some examples of how numbers should be encoded into hexadecimal format:
Decimal format Hexadecimal format
0 0x0
9 0x9
1234 0x4d2
And here are some examples of incorrectly encoded numbers:
Incorrect hex encoding Reason
0x No digit has been specified after the 0x prefix.
42d No 0x prefix has been specified.
0x042d Leading 0 digits aren’t allowed.

ACCESSING THE BLOCKCHAIN

You can get the latest blockchain block number this way:
{\"jsonrpc\":\"2.0\",\"method\":\"eth_blockNumber\",\"params\":[],\"id\":23}
And you’ll get

{"jsonrpc":"2.0","id":23,"result":"0x1a705d"}
Once you have the latest block number, you can inspect it by calling (replacing the
block number in params with the one from your result):
{\"jsonrpc\":\"2.0\",\"method\":\"eth_getBlockByNumber\",\"params\":[\"0x1a70
5d\",true],\"id\":23} http://localhost:8545
And you’ll get

{"jsonrpc":"2.0","id":23,"result":{"difficulty":"0x3e37031","extraData":"0xd6
83010700846765746885676...","gasLimit":"0x47e7c4","gasUsed":"0x323db6","
hash":"0x0d6ae4b07a731834f5ca0d18859...",...
"miner":"0x22d1d502356c1c2d...","nonce":"0x3b886846920d3c81","number":"0x1a70
5d","parentHash":"0x90fbbacbf8945fb8d4..."
...
Then you can inspect the first transaction of the block you retrieved in a way equiva-
lent to how you did in Web3 through the interactive console (again, putting the block
number you got in results into params):
{\"jsonrpc\":\"2.0\",\"method\":\"eth_getTransactionByBlockNumberAndIndex\",\
"params\":[\"0x1a705d\",\"0x0\"],\"id\":23} http://localhost:8545
And you’ll get

{"jsonrpc":"2.0","id":23,"result":{"blockHash":"0x0d6ae4b07a731834f5ca0d1885.
..","blockNumber":"0x1a705d","from":"0xcaf4a30e5fef5c0a...","gas":"0x47b760",
"gasPrice":"0x1bf08eb000","hash":"0x9acf62392d266086ec8..."
...
The result object is similar to that returned by the Web3 eth.getTransactionFrom-

Block call.
In the rest of the book, you’ll be interacting with geth mainly through Web3.js, but
occasionally I’ll show you how to perform equivalent operations in JSON-RPC. If
you’re interested in learning more about the JSON-RPC API, consult its wiki at
https://github.com/ethereum/wiki/wiki/JSON-RPC.

3.3.4 Mining with the geth console

You can’t consider a section on Ethereum clients to be complete before at least men-
tioning how to perform mining through a client. You already performed some mining
through the Ethereum wallet at the beginning of this chapter, to load your test
accounts with Ether.
As you can imagine, performing operations through the wallet hides what happens
under the hood. For example, have you asked yourself why the Ether you mined got
assigned to account1? That happened because the etherbase account, which is the
account associated with the miner thread, is set by default to eth.accounts[0]. But
after restarting geth and reopening the geth console in attach mode, as you did previ-
ously (in case you shut it down), you can reconfigure the etherbase account to
eth.accounts[1], if you prefer, through the implicitly instantiated miner object,
as follows:
C:\program files\geth> geth attach ipc:\\.\pipe\geth.ipc
> miner.setEtherbase(eth.accounts[1])
Regardless of whether your etherbase account is eth.accounts[0] or you’ve reconfig-

ured it to eth.accounts[1], you can start mining as follows:
> miner.start()
At this point, the CPU of your machine will go to nearly 100%. Then you can stop
mining:
> miner.stop()
In the unlikely event you’ve mined some Ether, this will now be assigned to your
eth.accounts[1], or to eth.accounts[0] if you decided not to reconfigure it.
When you kicked off mining on the geth interactive window with miner.start(),
you might have noticed output similar to the following:
INFO [09-29|18:08:23] Imported new chain segment blocks=1
txs=20 mgas=4.401 elapsed=25.066ms mgasps=175.592 number=1732751
hash=fa5a62…050eb5
INFO [09-29|18:08:25] Updated mining threads threads=0
INFO [09-29|18:08:25] Transaction pool price threshold updated
price=18000000000
INFO [09-29|18:08:25] Starting mining operation
INFO [09-29|18:08:25] Commit new mining work number=1732752
txs=5 uncles=0 elapsed=7.017ms
INFO [09-29|18:08:27] Generating DAG in progress epoch=57
percentage=0 elapsed=922.455ms
percentage=1 elapsed=1.846s


hash=c98db8…2d044c
INFO [09-29|18:08:31] Commit new mining work number=1732753
txs=6 uncles=0 elapsed=22.058ms
hash=f4432f…8bae81
You might wonder what DAG is and why it takes such a long time to compute. DAG
stands for directed acyclic graph, and it’s the data structure underlying Ethash, the
Proof of Work (PoW) algorithm for mining on the Ethereum platform. DAG
requires a relatively high amount of memory, so Ethash is considered a memory-
intensive PoW algorithm. It consequently discourages mining through application-
specific integrated circuit (ASIC) hardware, which is effective only for CPU-intensive
PoW algorithms, such as the one used on the Bitcoin network. The Ethash algorithm
encourages mining instead through commodity hardware, such as a GPU chipset
(explained more in sidebar).
Mining is a specialized topic outside the scope of this book. If you’re interested
in learning more about Ethash, I encourage you to consult the official notes at
http://mng.bz/WaOw.
Now that you’ve experienced mining firsthand, you might ask yourself what hap-
pens if you have the luck to append a new block to the blockchain, get the related
Ether reward in your etherbase account, and then decide to quit your mining activity
by shutting down your node. Would the block you’ve created and appended to the
blockchain still be valid, even if you’ve disappeared from the network? Would the
transactions included in the block still be valid? Would you still be able to transfer the
Ether in your etherbase account to another account?
The answer to all these questions is yes. Remember that the blockchain validation
process, performed continuously by all active full nodes, only cares about the cryp-
tographic consistency between a block hash and the public address of the miner who
has generated the block, in the same way it cares about the consistency between a
transaction hash and the public address of the account that has generated it. So
whether the node that created a new block is active or inactive is as irrelevant to the
block (and transaction) history as whether your computer is on or off after having
transferred some Ether from an account of your desktop Ethereum wallet to another
account.

GPU mining
If you want to try your luck and hope to get rich by generating Ether on the public pro-
duction network with CPU mining, as you’ve done so far in the test network, I hate to
break the news, but you’re more likely to get rich by winning the lottery. As you saw
in chapter 1, the execution of the PoW algorithm is successful only if the hash
obtained combining the block information and a nonce has certain characteristics—
for example, a high number of leading zeros. PoW algorithms are designed so that
you must try millions of nonce values before hitting the lucky one that generates a
valid hash. Consequently, mining successfully means being able to generate more
hashes per second than other miners.
With the best CPU chipset, you’ll be able to generate at most 1 megahash per second
(Mh/s), where megahash means one million hashes. With good GPU chipsets, you
might be able to generate up to 30 Mh/s—nearly 30 times the hashing capability of
a standard CPU. Also consider that mining pools, which are organizations that pool
various GPU miners together so they can share resources and rewards, can generate
up to 30 Th/s (30 trillion hashes per second), which means up to 30 million times
what a CPU is able to generate during the same time. Finally, consider that in the
Ethereum space, around 40 mining pools have a hash rate ranging between 30 Gh/s
and 30 Th/s.
Now you can understand why your chances of generating Ether using a CPU alone are
slim. You might find this stark reality disappointing, and you might even think that the
huge influence of mining pools on the mining process might bring into question Ethe-
reum’s credibility, as far as decentralization is concerned. Many Ethereum partici-
pants believe that as long as many mining pools are competing, decentralization
should be guaranteed. Also consider that the new consensus algorithm being imple-
mented, Stake of Work, introduced in the previous chapter, might change completely
how power is concentrated (or hopefully spread) in the Ethereum network. Here’s a
quick summary of the hash rate that different hardware can achieve:
Hardware Hashrate
Single CPU 1 Mh/s
Single GPU 30 Mh/s
GPU rig (10xGPUs) 300 Mh/s
Mining pool 30,000,000 Mh/s
3.3.5 Other clients

Although Go Ethereum is the most popular client, other implementations offer vari-
ous benefits with respect to geth:
 Parity, written in Rust, is the second most popular Ethereum client, and it’s
regarded as the fastest, lightest, and most secure implementation. It comes with
a console and a built-in wallet.

Managing accounts with geth 59
 cpp-ethereum, written in C++ and known as eth, is another fast implementation,

third in popularity, and well regarded for its portability. Ethminer, a specialized
mining client, is a fork from cpp-ethereum.
 pyethapp, written in Python, is built on two core components: pyethereum provides
EVM, blockchain, and mining functionality, whereas pydevp2p supports access to
the P2P network and node discovery mechanisms. Python developers especially
appreciate this implementation for its extensibility.
You’ve learned about various components and tools of the Ethereum platform. Before
leaving this chapter, you’ll reinforce your understanding of accounts, a key concept
you must get familiar with to work effectively with Ethereum.
3.4 Managing accounts with geth

At the beginning of this chapter, while covering smart contracts, I touched briefly on
accounts. I also helped you create some accounts through the Ethereum wallet UI so
you could use them to transfer some Ether around. Armed with the geth console, you
can now deepen your knowledge of accounts by creating them and interacting with
them programmatically.
3.4.1 Ethereum accounts

As you know, the Ethereum platform supports two types of accounts:
 Externally owned accounts (EOAs) —These impersonate end users, as well as min-
ers and autonomous agents.
 Contract accounts —These impersonate contracts.
For the rest of this chapter, we’ll deal only with EOAs, which I’ll call accounts.
As with most blockchain systems, the security of the Ethereum platform is based on
public key cryptography. An account is therefore identified by a private/public key
pair. The account’s address is represented by the last 20 bytes of the public key.
The private/public key pair associated with an account is stored in a text keyfile.
The public key is visible in plain text, whereas the private key is encrypted with the
password introduced at account creation. Account keyfiles are in the keystore folder
within the Ethereum node’s data directory:
 Windows: C:\Users\username\%appdata%\Roaming\Ethereum\keystore
 Linux: ~/.ethereum/keystore
 Mac: ~/Library/Ethereum/keystore
TIP It’s strongly recommended that you back up the keystore folder on a
regular basis and keep a copy of the passwords you’ve introduced when creat-
ing each account in a secure place. Sorry if I keep pestering you with this, but
if you haven't noticed, I do want to make a point of how sensitive key and
password details are in the blockchain world!

Account portability
You can’t use an account that you’ve created on the public production network on a
test network, for example Ropsten, and vice versa. This is because the keystore of
each network is different and is located in a separate folder within the Ethereum
folder:
 Main prod network keystore: ~/.ethereum/keystore
 Rinkeby test network keystore: ~/.ethereum/rinkeby/keystore
 Ropsten test network keystore: ~/.ethereum/testnet/keystore
You can create accounts and interact with them through four different avenues:
 The Ethereum wallet, as you saw earlier in this chapter
 geth commands
 Web3 on the geth console
 JSON-RPC calls
You’ve already seen how to manage accounts with the Ethereum wallet. In the next
several sections, you’ll manage accounts through geth commands and the geth con-
sole. You’ll also get a quick feel for how to perform some operations on accounts
through the JSON-RPC API.
3.4.2 Managing accounts with the geth command

You can manage an account easily through your operating system console by entering
specific geth commands from the directory of the geth executable (or from any direc-
tory if geth is in your PATH global variable).
CREATING A NEW ACCOUNT
You can create a new account manually or using a plain text file:
1 Manual creation
a To create a new account, enter
C:\program files\geth>geth account new
b You’ll be prompted to enter a password twice, and then you’ll be shown the
address of the account you created:
Your new account is locked with a password. Please give a password.
Do not forget this password.
Passphrase:
Repeat passphrase:
Address: {47e3d3948f46144afa7df2c1aa67f6b1b1e35cf1}
TIP Get into the habit of choosing strong passwords or generating them
through a strong password generator. I’m repeating myself; I know, I know!
But this is important, believe me!

2 Text file creation

a To avoid having to enter the password manually, you can store it in plain text
in a text file.
b Execute the geth account command as follows:
C:\program files\geth>geth --password passworddirectory/passwordfile

account new
TIP As you can understand, although placing a password in a plaintext file

might be acceptable in a test environment, this way of creating an account
might pose much greater risks in a production environment, where you must
make sure access to the password file is tightly restricted.
LISTING ACCOUNTS
Once you’ve created an account, you can verify it’s indeed present in your node by
executing the following command:
C:\program files\geth>geth account list
You’ll see the accounts you created through the geth account command and the geth
console:
Account #0: {edde06bc0e45645e2f105972bdefc220ed37ae10}
keystore://C:\Users\rober\AppData\Roaming\Ethereum\keystore\UTC--2017-
06-24T08-49-46.377533700Z--edde06bc0e45645e2f105972bdefc220ed37ae10
Account #1: {4e6c30154768b6bc3da693b1b28c6bd14302b578}
06-24T13-26-18.696630000Z--4e6c30154768b6bc3da693b1b28c6bd14302b578
Account #2: {70e36be8ab8f6cf66c0c953cf9c63ab63f3fef02}
06-24T18-21-36.890638200Z--70e36be8ab8f6cf66c0c953cf9c63ab63f3fef02
Account #3: {c99048e9b98d3fcf8b5f0d5644794b562f9a2ea4}
06-24T18-21-47.794428600Z--c99048e9b98d3fcf8b5f0d5644794b562f9a2ea4
…
UPDATING ACCOUNTS
After geth creates and saves an account in a keyfile in the keystore folder, a subse-
quent geth release might implement a new keyfile format. In that case, it becomes
necessary to update the account. Another reason you might want to update an
account is because you want to change the password.
You can update account 47e3d3948f46144afa7df2c1aa67f6b1b1e35cf1 you created
earlier with the following geth command (obviously replace with your account number):
C:\program files\geth>geth account update
47e3d3948f46144afa7df2c1aa67f6b1b1e35cf1

You’ll be prompted to enter the existing password, to unlock the account, and subse-
quently a new password, which you’ll have to type twice, as usual. You’ll then be shown
the new address of the account:
Unlocking account 47e3d3948f46144afa7df2c1aa67f6b1b1e35cf1 | Attempt 1/3
Passphrase:
INFO [09-30|08:36:25] Unlocked account
address=0x47e3d3948f46144afa7df2c1aa67f6b1b1e35cf1
Please give a new password. Do not forget this password.
Passphrase:
Repeat passphrase:
The geth account update command offers the same --password option that the geth
account new command provides. But in this case you can also use it to unlock the
account for the purpose of converting it into a new keyfile format.
3.4.3 Managing accounts with Web3 on the geth console

Let’s repeat some of the earlier account management operations through the interac-
tive console.
CREATING A NEW ACCOUNT
Go back to the interactive geth console. You can create accounts using the web3.per-
sonal object:
> personal.newAccount()
As for the geth account command, you’ll be asked to enter a password twice, and then
you’ll be shown the account address:
Passphrase:
Repeat passphrase:
"0x70ff99d4bc8054b2e09269bcbfdddf8e1ae7d155"
LISTING ACCOUNTS
You can list accounts with the interactive console by displaying the value of the
account property of the web3.eth object. You’ll get the same result set you obtained
with the geth account list command:
> eth.accounts
will yield something like

["0xedde06bc0e45645e2f105972bdefc220ed37ae10",
"0x4e6c30154768b6bc3da693b1b28c6bd14302b578",
"0x70e36be8ab8f6cf66c0c953cf9c63ab63f3fef02",
"0xc99048e9b98d3fcf8b5f0d5644794b562f9a2ea4",
…

You also can directly reference a specific account of the eth.accounts array:
> eth.accounts[0]
This will yield something like

"0xedde06bc0e45645e2f105972bdefc220ed37ae10"
CHECKING AN ACCOUNT’S ETHER BALANCE

You can check the amount of Ether stored in an account using the following call,
which returns it in Wei:
> var balanceInWei = eth.getBalance(
"0x407d73d8a49eeb85d32cf465507dd71d507100c1")
Then you can convert it to Ether as usual:

> var balanceInEther = web3.fromWei(balanceInWei, "Ether")
TRANSFERRING ETHER BETWEEN ACCOUNTS

You can try transferring 0.0025 Ether from accounts[1] to accounts[2]. First of all,
check the current balances of these accounts, as you saw earlier:
> var balanceAcc1 = eth.getBalance(eth.accounts[1]);
> var balanceAcc2 = eth.getBalance(eth.accounts[2]);
> console.log('Balance account 1: ' + balanceAcc1 + '; Balance account 2: ' +
balanceAcc2);
Balance account 1: 1938331059000000000; Balance account 2:
1000741600000000000
Before transferring Ether from a certain account, for example accounts[1], you must
unlock it:
> personal.unlockAccount(eth.accounts[1]);
As usual, you’ll be asked to enter the password associated with this account:
Unlock account 0x4e6c30154768b6bc3da693b1b28c6bd14302b578
Passphrase:
true
Then, you can transfer Ether between accounts with the web3.eth.sendTransaction
function, which takes an amount in Wei, as follows:
> var sender = eth.accounts[1];
> var recipient = eth.accounts[2];
> var amount = web3.toWei(0.0025, "Ether");
> eth.sendTransaction({from:sender, to:recipient, value: amount});
"0xf1c342c668bcd1d59f3e95cfaf08acc6d7cda8adae02da05ceb76c8c3c137eef"
The value returned is the hash of the transaction sent.

After a couple of minutes, recheck the balances:

> console.log('Balance account 1: ' + eth.getBalance(eth.accounts[1]) + ';
Balance account 2: ' + eth.getBalance(eth.accounts[2]));
Balance account 1: 1933311059000000000; Balance account 2:
1003241600000000000
If the balance hasn’t been updated yet, it’s because the transaction hasn’t been mined yet.
3.4.4 Managing accounts with JSON-RPC

I’ll give you a quick example of how to perform account management operations in
JSON-RPC. Open a new OS shell and you can list your accounts with the following
JSON-RPC call:
{\"jsonrpc\":\"2.0\",\"method\":\"eth_accounts\",\"params\":[],\"id\":23}
This will yield something like

{"jsonrpc":"2.0","id":23,"result":["0xedde06bc0e45645e2f105972bdefc220ed37ae1
0","0x4e6c30154768b6bc3da693b1b28c6bd14302b578","0x70e36be8ab8f6cf66c0c953cf9
c63ab63f3fef02","0xc99048e9b98d3fcf8b5f0d5644794b562f9a2ea4",...
3.5 Revisiting SimpleCoin’s contract

We’ve covered quite a lot of ground in this chapter. If you’ve followed me up to this
point, congratulations: you’ve completed the introduction to Ethereum covering the
Ethereum wallet and the Go Ethereum client. You’ve also started interacting with the
platform in many ways—through the geth commands, through Web3 instructions on
the geth interactive console, and through direct JSON-RPC requests.
It’s been an intense ride. I bet you’re eager to get back to some coding! Let’s revisit
your initial implementation of SimpleCoin, the basic cryptocurrency I introduced at
the end of chapter 1, and try to improve it.
Reenter the SimpleCoin code you saw in the previous chapter into Remix
(http://remix.ethereum.org), as shown in the following listing. As usual, ignore warn-
ings for the moment: they’ll disappear as you improve the code in the next chapters.
Listing 3.1 SimpleCoin contract as you left it in chapter 1
contract SimpleCoin {
mapping (address => uint256) public coinBalance;
constructor() public {
coinBalance[0x14723A09ACff6D2A60DcdF7aA4AFf308FDDC160C] = 10000;
}

Revisiting SimpleCoin’s contract 65
function transfer(address _to, uint256 _amount) public {

coinBalance[msg.sender] -= _amount;
}
}
This code is rudimentary. Even if you don’t know the Solidity language yet, you can
see a hardcoded value in the constructor and a lack of input validation in the transfer
function. You can improve the code in several ways. First of all, you can parameterize
the constructor so the initial money supply doesn’t get allocated to the address of an
arbitrary test account, but to the address of the contract owner’s account. Then you
can introduce some checks in the transfer function to prevent incorrect transfers.
Finally, you can set things up so that when tokens get transferred, an event can be
raised, and then clients of the smart contract can be notified or react to it.
3.5.1 Improving SimpleCoin’s contract

You’ll improve both the constructor and the transfer function. You can start from the
constructor.
PARAMETERIZING THE CONSTRUCTOR
Rewrite the constructor as follows:
constructor(uint256 _initialSupply) public {
coinBalance[msg.sender] = _initialSupply;
}
You’ve already come across the special property msg.sender, whose value is the
address of the message sender (or function caller). When it comes to the constructor,
the message sender is the account that instantiates the contract, which consequently
becomes its owner. As a result, when the constructor gets called, the amount of tokens
specified in the _initialSupply parameter gets allocated to the contract owner.
MAKING TRANSFERS MORE ROBUST
Rewrite the transfer function as shown in the following listing.
Listing 3.2 A more robust transfer function with checks on the input
Checks that the sender account

function transfer(address _to, uint256 _amount) { has an amount of coins equal to
require(coinBalance[msg.sender] >= _amount);
or larger than what you’re
trying to transfer
require(coinBalance[_to] + _amount >=
coinBalance[_to]);
Checks that an arithmetic overflow hasn’t
coinBalance[msg.sender] -= _amount; been produced on the recipient’s balance
coinBalance[_to] += _amount; during the transfer operation. (This can
} happen if the balance, because of the
amount received from the sender, 
becomes bigger than uint256.)

The require special function throws an exception if the condition isn’t met. You can
also throw the exception directly with the throw keyword, but this way of validating
input is being deprecated. For example
require(coinBalance[msg.sender] > _amount);
could have been previously written as

if (coinBalance[msg.sender] < _amount) throw;
RAISING AN EVENT
A contract can declare one or more events that can be raised in any of its functions. A
client that’s monitoring the state of a contract can handle an event. For instance, you
can declare an event that notifies that a transfer of SimpleCoin tokens has taken
place:
event Transfer(address indexed from, address indexed to, uint256 value);
You’ll raise this event at the bottom of the transfer function:

function transfer(address _to, uint256 _amount) {
...
emit Transfer(msg.sender, _to, _amount);

}
3.5.2 Trying out the amended code

The amended SimpleCoin contract will now look like the following listing.
Listing 3.3 SimpleCoin with parameterized constructor, input validation, and event
contract SimpleCoin {
mapping (address => uint256) public coinBalance;
event Transfer(address indexed from, address indexed to, uint256 value);
constructor(uint256 _initialSupply) public {

coinBalance[msg.sender] = _initialSupply;
}
function transfer(address _to, uint256 _amount) public {

require(coinBalance[msg.sender] > _amount);
require(coinBalance[_to] + _amount >= coinBalance[_to] );
coinBalance[msg.sender] -= _amount;
emit Transfer(msg.sender, _to, _amount);
}
}

TRYING OUT THE AMENDED CONSTRUCTOR

Reopen Remix if you closed it, and copy the code in listing 3.3 into the editor. Then
pick a test account address from the Transaction Origin drop-down list; for example,
0x4b0897b0513fdc7c541b6d9d7e929c4e5364d2db. This will be the account executing
the constructor, and it’ll consequently become the contract owner.
Click the Run tab on the right panel. You can now enter the initial supply of Sim-
pleCoin tokens next to the Deploy button, say 10,000, and then click Deploy. As usual,
the coinBalance and transfer buttons will appear on the lower part of the screen, as in
the previous chapter, as shown in the screenshot in figure 3.13.
Deploy calls the

constructor, which now
takes a parameter.
CoinBalance is associated with Transfer calls the

the coinBalance variable. transfer() function.
Figure 3.13 The Deploy operation now accepts the constructor input.
After you instantiate the contract by clicking Deploy, the CoinBalance
and Transfer buttons appear.
You can check the contract owner’s address balance in the coinBalance mapping. As
expected, you’ll get 10,000. You can also double-check that the balances of the other
addresses are zero, as shown in table 3.6.

Table 3.6 The balances of the SimpleCoin accounts
0x14723a09acff6d2a60dcdf7aa4aff308fddc160c 0
0x4b0897b0513fdc7c541b6d9d7e929c4e5364d2db 10,000
0x583031d1113ad414f02576bd6afabfb302140225 0
0xdd870fa1b7c4700f2bd7f44238821c26f7392148 0
TRYING OUT THE AMENDED TRANSFER FUNCTION

Try to transfer some SimpleCoin tokens from an account that doesn’t have any; for
example, 0x583031d1113ad414f02576bd6afabfb302140225. Select this address from
the Transaction Origin drop-down list and enter the following comma-delimited value
into the transfer text box:
"0xdd870fa1b7c4700f2bd7f44238821c26f7392148", 150
After clicking Transfer, you’ll get the following error message, thanks to the require
check you added earlier:
transact to browser/SimpleCoin.sol:SimpleCoin.transfer errored: VM error:
invalid opcode.
The constructor should be payable if you send value.
The execution might have thrown.
Debug the transaction to get more information.
Now try to transfer 150 tokens from the contract owner’s account to the same recipi-
ent you just tried. You need to select the account starting with 0x4b0897b on the
Transaction Origin drop-down list and reenter the following comma-delimited value
into the transfer text box:
"0xdd870fa1b7c4700f2bd7f44238821c26f7392148", 150
The operation will now be successful, as you can see in the output on the left side of
the screen shown in figure 3.14.
Figure 3.14 Output of successful transfer operation

If you click the arrow next to Debug, you can verify in the logs property that the
Transfer event has been raised at the end of the function call:
[
{
"event": "Transfer",
"args": [
"0000000000000000000000004b0897b0513fdc7c541b6d9d7e929c4e5364d2db",
"000000000000000000000000dd870fa1b7c4700f2bd7f44238821c26f7392148",
"150"
]
}
]
After rechecking all the balances, the results should match table 3.7.
Table 3.7 The new balances of the SimpleCoin accounts
0x14723a09acff6d2a60dcdf7aa4aff308fddc160c 0
0x4b0897b0513fdc7c541b6d9d7e929c4e5364d2db 9,850
0x583031d1113ad414f02576bd6afabfb302140225 0
0xdd870fa1b7c4700f2bd7f44238821c26f7392148 150
Congratulations! You’ve completed this exercise. The improvements you’ve made

weren’t particularly challenging, but making them should have helped you gain more
familiarity with contracts.
3.5.3 How does the coin transfer execute in the Ethereum network?
You might have understood the Solidity code that performs the coin transfer but...if
this transfer was taking place on a real Ethereum network rather than on the Remix
JavaScript EVM emulator, would you know where within the network it would be exe-
cuted? And would you know what effect a transfer of SimpleCoin tokens would have
on the blockchain? You can get the answers to these questions by looking at the dia-
gram in figure 3.15. I’ve adapted it for SimpleCoin from the transactional view you
saw in figure 1.8 (chapter 1).
You’ll see other transaction lifecycle diagrams similar to this for all Dapps I’ll cover
in the book. The lifecycle of an Ethereum transaction will be cemented in your head
progressively throughout the book, until it becomes second nature to you.

1. Transfer click
event is
handled by
web page
JavaScript
To: ac3432a <Javascript>
Javascript and
Amount 120 Web3.js code
</Javascript>
Transfer <HTML>
8. Transfer </HTML>
user public address: confirmation
from:0x6cba SimpleCoin is displayed SimpleCoin
web wallet app on web page wallet web app code
7. During block processing, Transaction 2. Web page

the Transfer event is published Event JavaScript
from:0x6cba
to subscribed listeners Transfer
to:0xac3432 calls transfer()
amount:100 on SimpleCoin
contract and
generates a
transaction
Transaction
Event Internet
from:0x6cba
Transfer
to:0xac3432
amount:100
6. Block is validated,
executed, and
propagated to peers
Peer Local
full node full node
Block 233
tran1652b1
tran27655c
5. Transaction is Transaction
Block 233 3. Transfer transaction
placed on new block; from:0x6cba
tran1652b1 is validated and
block is propagated to:0xac3432
tran27655c propagated to peers
to peers amount:100
Transaction
from:0x6cba
to:0xac3432
amount:100
Peer
Mining node full node
4. Transfer transaction
is validated and
propagated to
mining node
Figure 3.15 The lifecycle of a SimpleCoin transfer transaction. A transfer transaction is created
when a SimpleCoin wallet invokes the transfer() function on the SimpleCoin 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 then
propagated throughout the network, and finally it gets back to the local node.

Summary 71
Summary
 The Ethereum wallet is a GUI that allows you to interact with the platform by
creating accounts and transferring Ether intuitively.
 The most popular Ethereum client is Go Ethereum, also known as geth. It
comes with an interactive console that references Web3.js, a high-level interface
to Ethereum clients.
 It’s possible to interact with geth, for instance to create accounts, through vari-
ous avenues:
– geth commands executed in the operating system command shell
– Web3.js instructions executed in the geth interactive console
– HTTP JSON-RPC commands executed through cURL or a UI tool such as
Postman
 Ethereum smart contracts, or just contracts, are written in a high-level language
such as Solidity, compiled into EVM bytecode, deployed on the Ethereum net-
work, and stored in the blockchain.
 It’s possible to communicate with contracts using calls, transactions, and events.
A transaction involves the consumption of computational and network resources,
which is calculated in a unit called gas and settled in Ether, the cryptocurrency
of the Ethereum platform.

index
A blockchain
accessing with geth 50–51
account property 62 accessing with JSON-RPC 55
accounts trust and security in Dapps 7
checking an Ether balance of 63 blockchain database 5, 9
creating blue buttons, Remix IDE 27
with geth commands 60–61
Browser Solidity 23
with Web3 on geth console 62
listing
with geth commands 61 C
with Web3 on geth console 62–63
managing 59–60 CALL operator 45
Web3 on geth console 62–64 calling 44–45
with geth commands 60–62 castVote() function 13–14
with JSON-RPC 64 central node 5
portability of 60 centralized application 2–3
transferring Ether between 63–64 centralized organization 15
types of 39 centralized trusted system 3
updating with geth commands 61–62 client connectivity 53–54
Accounts Overview screen, Ethereum wallet  CLR (Common Language Runtime) 45
35, 37 code, amended 66–69
agents. See autonomous agents coinBalance property 25, 28
amended constructors 67–69 coinBalance variable 25
_amount parameter 25
coins, transferring, on Ethereum networks 69
application-specific integrated circuit (ASIC) 57
Common Language Runtime (CLR) 45
ASIC (application-specific integrated circuit) 57
authenticity, tracking 18–19 connectivity
Auto Compile option, Compile tab 26 checking with geth console 49–50
autonomous agents 15 of clients 53–54
consensus 3–4
B constant functions 44
constructors
balances, checking 63 amended 67–69
Bitcoin 9, 19 parameterizing 65
block variable 9 contract accounts 39, 59
72

INDEX 73
contracts 64–71 lifecycle of transactions 13–15

amended code 66–69 pointless 22–23
executing coin transfer in Ethereum terminology 15–17
networks 69 autonomous agents 15
improving 65–66 DAC 16–17
parameterizing constructors 65 DAO 15–16
raising events 66 DO 15
robust transfers 65–66 smart contracts 15
interacting with 27–30 vs. conventional centralized applications 4–8
running 26 centralized voting applications 4–5
See also smart contracts decentralized voting applications 5
conventional centralized applications vs. security in centralized voting 5
Dapps 4–8 trust and security in Dapps 6–7
centralized voting applications 4–5 trust in centralized voting 5
decentralized voting applications 5 decentralized applications. See Dapps
security in centralized voting 5 decentralized autonomous corporation
trust and security in Dapps 6–7 (DAC) 16–17
trust in centralized voting 5 decentralized autonomous organization
conversions with geth console 51 (DAO) 15–16
cpp-ethereum 59 decentralized organization. See DO
CPU mining 58 decentralized prediction markets 20
CREATE operator 45 DELEGATECALL operator 45
crowdfunding 21 denial of service attacks. See DoS attacks
cryptocurrencies, building 23–25 Deployed Contracts panel 26–27
cURL console command 52–53 Desktop wallet 41
distributed applications 4, 17
D DO (decentralized organization) 15
DoS (denial of service) attacks 42
DAC (decentralized autonomous double-quote symbol 53
corporation) 16–17
DAO (decentralized autonomous E
organization) 15–16
Dapps (decentralized applications) 1–30 economy of things 19–20
anatomy of 8–11 EOA (externally owned accounts) 39, 59
Ethereum network 9–10 eth.accounts array 63
network nodes 10–11 eth.blockNumber property 50
P2P networks 9 eth.getTransactionFromBlock 55
web applications 8 Ethash algorithm 57
five-minute implementation 23–30 Ether 39–42
building basic cryptocurrencies 23–25 exchanging 41
interacting with contracts 27–30 lifecycle 40
running contracts 26 mining 35
good use cases for 18–22 minting 41
authenticity tracking 18–19 storing 41–42
crowdfunding 21 transferring 36–37, 41
decentralized prediction markets 20 Ethereum
economy of things 19–20 networks 9–10
gambling 21–22 wallets 32–37
identity verification 19 common operations with 35–37
international trade finance 20–21 overview of 32–34
provenance tracking 18–19 Ethereum Virtual Machine. See EVM
proving ownership 19 Ethernodes 46
regulatory auditing 21 Ethminer 46, 59

74 INDEX
EthTweet 22 J
events, raising 66
Everledger 18 JSON-RPC protocol 51–55
EVM (Ethereum Virtual Machine) 37, 45 accessing blockchain with 55
exchanging Ether 41 checking client connectivity with 53–54
displaying version information with 53
externally owned accounts (EOA) 39, 59
managing accounts with 64
JVM (Java Virtual Machine) 45
F
fast synchronization 33
K
faucet 35 keyfile 59
full nodes 10, 46 keystore folder 59
full synchronization 33 KYC-Chain 19
G L
gambling 21–22 listing accounts
gas 42–43 with geth commands 61
geth with Web3 on geth console 62–63
commands 60–62
console 48–51 M
accessing blockchain 50–51
checking connectivity 49–50 MAINNET network 47
manual protocol 16
displaying version information 48–49
MediLedger 19
mining with 56–57
memory 45
performing conversions 51 miner.start() function 56
JSON-RPC 51–55 mining
accessing blockchain 55 Ether 35
checking client connectivity 53–54 with geth console 56–57
displaying version information 53 minting, Ether 41
overview of 47–48 msg variable 25
Web3 on console 62–64 msg.sender property 25
GPU mining 58
N
H
network nodes 10–11
Hardware wallet 41
hash map 25 O
hexadecimal encoding 54
Online wallet 41
OpenBazaar 2
I ownership, proving 19
IaaS (Infrastructure as a Service) 4
identities, verifying 19
P
independent transactions 3 P2P (peer-to-peer) networks 5–7, 9, 45
Infrastructure as a Service (IaaS) 4 Paper storage 41
_initialSupply parameter 65 parameterizing constructors 65
international trade finance 20–21 Parity 58
Internet of Things 19 participant nodes 9

INDEX 75
- -password option 62 RPC (remote procedure call) 51

passwords 34, 60 - -rpc option 52
peer nodes 5 - -rpcapi option 52
peers property 50
peer-to-peer (P2P) networks 5–7, 9, 45 S
Pfizer 19
platforms 31–71 SimpleCoin contract 25–27
connecting to Ethereum with geth 45–59 SimpleCoin function 25, 43
geth console 48–51 Slock.it 19
JSON-RPC 51–55 smart contracts 2, 10, 15–16, 22, 37–45
mining with geth console 56–57 accounts 39
overview of geth 47–48 calls 44–45
contracts 64–71 Ether 39–42
amended code 66–69 exchanging 41
executing coin transfer in Ethereum minting 41
networks 69 storing 41–42
improving 65–66 transferring 41
Ethereum wallet 32–37 EVM (Ethereum Virtual Machine) 45
common operations with 35–37 gas 42–43
overview of 32–34
transactions 44–45
managing accounts 59–64
Solidity 23, 25
Ethereum accounts 59–60
State Merkle-Patricia trie 38
with geth commands 60–62
state variables 25, 27
with JSON-RPC 64
storing Ether 41–42
with Web3 on geth console 62–64
subproperties 48–49
smart contracts 37–45
system architecture 7
accounts 39
calls 44–45
Ether 39–42 T
EVM (Ethereum Virtual Machine) 45
gas 42–43 throw keyword 66
transactions 44–45 _to parameter 25
PoW (Proof of Work) 57 tracking
predictit.org 20 authenticity 18–19
private networks provenance 18–19
programmable blockchains 10 transaction sender 25
Proof of Work (PoW) 57 transactions, lifecycle of 13–15
provenance 18–19 transfer() function 25, 29, 42–43, 65, 70
pyethapp 59 transferring 65–66
pyethereum 59 between accounts 63–64
coins 69
R Ether 36–37, 41
transparency 4
read-eval-print loop (REPL) 48 trustless 4
red buttons, Remix IDE 27 TrustToken 19
regulatory auditing 21
Remix 23, 64, 69 U
remote procedure call (RPC) 51
REPL (read-eval-print loop) 48 Unilever 18
require() function 66 Universal Sharing Network 19
Ropsten Etherscan webpage 35 updating accounts 61–62
Ropsten network 32 user accounts 39

76 INDEX
V W
validation 7 wallets for Ethereum 32–37
variables common operations with 35–37
See state variables overview of 32–34
version information we.trade 20
displaying with geth console 48–49 web applications 8
displaying with JSON-RPC 53 web3.eth object 62
volatile memory 45 web3.eth.sendTransaction function 63
vote processing 7 Web3.js libraries 8
VoteConfirmation event 15 on geth console 62–64
voting web3.net.peerCount 54
centralized web3.personal object 62
security in 5 Wire protocol 9–10
trust in 5
centralized applications 4–5
decentralized applications 5

ma
nni
ng

Exploring Ethereum Dapps (Manning, 2019)

Uploaded by

Copyright:

Available Formats

Exploring Ethereum Dapps (Manning, 2019)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Exploring Ethereum Dapps (Manning, 2019)

Uploaded by

Copyright:

Available Formats

Save 50% on these selected books – eBook, pBook, and MEAP.

Enter ebblockchain50 in the

Building Ethereum Dapps

Ethereum DApps in Motion

Licensed to UNKNOWN UNKNOWN <[email protected]>

Manning Author Picks

Copyright 2019 Manning Publications

Licensed to UNKNOWN UNKNOWN <[email protected]>

For more information, please contact

Special Sales Department

©2019 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in

Manning Publications Co.

Cover designer: Leslie Haimes

Licensed to UNKNOWN UNKNOWN <[email protected]>

1 A first look at decentralized applications 1

3 The Ethereum platform 31

Licensed to UNKNOWN UNKNOWN <[email protected]>

Licensed to UNKNOWN UNKNOWN <[email protected]>

Licensed to UNKNOWN UNKNOWN <[email protected]>

This chapter covers

Licensed to UNKNOWN UNKNOWN <[email protected]>

1.1 What is a Dapp?

Licensed to UNKNOWN UNKNOWN <[email protected]>

Licensed to UNKNOWN UNKNOWN <[email protected]>

DEFINITION Consensus is a distributed and trustless form of agreement on the

1.1.1 Dapps vs. conventional centralized applications

Licensed to UNKNOWN UNKNOWN <[email protected]>

Licensed to UNKNOWN UNKNOWN <[email protected]>

Centralized voting application

Decentralized voting application P2P network

TRUST AND SECURITY IN DAPPS THANKS TO P2P NETWORK REPLICATION

Licensed to UNKNOWN UNKNOWN <[email protected]>

vote further throughout the network, so the malicious modification would

Licensed to UNKNOWN UNKNOWN <[email protected]>

concrete infrastructural components while presenting two complementary low-level

1.1.2 Structural view: Anatomy of a Dapp

Conventional web server

Voting Dapp UI downloaded as

Voting web app Voting web app code

Licensed to UNKNOWN UNKNOWN <[email protected]>

DAPP SERVER SIDE: A P2P NETWORK

Figure 1.4 A peer-to-peer (P2P) network is made of

THE ETHEREUM NETWORK

Licensed to UNKNOWN UNKNOWN <[email protected]>

P2P Ethereum network

Nodes communicate Hsk Py

Licensed to UNKNOWN UNKNOWN <[email protected]>

Figure 1.6 The Ethereum network includes two main types of

Licensed to UNKNOWN UNKNOWN <[email protected]>

Conventional web server

Voting Dapp UI downloaded as

Voting web app Voting web app code

Licensed to UNKNOWN UNKNOWN <[email protected]>

1.1.3 Transactional view: Through the lifecycle of a transaction

Licensed to UNKNOWN UNKNOWN <[email protected]>

7. During block processing, Transaction 2. Web page

Licensed to UNKNOWN UNKNOWN <[email protected]>

to raise a VoteConfirmation event on successful completion. The event is pub-

1.1.4 Some Dapp terminology