mastering_ethereum

Prévia do material em texto

Mastering Ethereum 
Preface 
Glossary 
What is Ethereum? 
Ethereum Basics 
Ethereum Clients 
Keys, Addresses 
Wallets 
Transactions 
Smart Contracts and Solidity 
Smart Contracts and Vyper 
Smart Contract Security 
Tokens 
Oracles 
Dapps 
The Ethereum Virtual Machine 
Consensus 
Appendix: Ethereum Fork History 
Appendix: Ethereum Standards 
Appendix: Ethereum EVM Opcodes and Gas Consumption 
Appendix: Development Tools, Frameworks and Libraries 
Appendix: web3.js Tutorial 
 
 
Preface 
This book is a collaboration between Andreas M. Antonopoulos and Gavin Wood. A 
series of fortunate coincidences brought these two authors together in an effort that 
galvanized hundreds of contributors to produce this book, in the best spirit of open 
source and the creative commons culture. 
Gavin had been wishing to write a book that expanded on the Yellow Paper (his 
technical description of the Ethereum protocol) for some time, primarily to open it up to 
a wider audience than the original greek-letter-infused document could possibly allow. 
Plans were underway---publishers had been found---when Gavin got talking to Andreas. 
Gavin knew Andreas, from the very beginning of his tenure with Ethereum, as a notable 
personality in the space who was interested in learning more about Ethereum. 
Meanwhile, Andreas had just published "Mastering Bitcoin," which quickly became the 
authoritative technical guide to Bitcoin and cryptocurrencies. Almost as soon as the 
book was published, his readers started asking him "When will you write 'Mastering 
Ethereum'?" Andreas was already considering his next project and found Ethereum to 
be a compelling technical subject. 
Finally, in May 2016, Gavin and Andreas were both coincidentally in the same city at the 
same time. They met up for a coffee to chat about working on "Mastering Ethereum" 
together. With both Andreas and Gavin being devotees of the open-source paradigm 
they both committed to making this a collaborative effort, released under a creative 
commons license. Thankfully the publishers, O’Reilly Media, were happy to agree and 
the "Mastering Ethereum" project was officially launched. 
Intended audience 
This book is mostly intended for coders. If you can use a programming language, this 
book will teach you how smart contract blockchains work, how to use them, and how to 
develop smart contracts and decentralized applications with them. The first few 
chapters are also suitable as an in-depth introduction to Ethereum for noncoders. 
The bees on the book’s cover 
The Western honey bee (Apis mellifera) is a species that exhibits highly complex 
behavior that, ultimately, benefits its hive. Each individual bee operates freely under a 
set of simple rules and communicates findings of importance by pheromones and 
waggle dance. This dance carries valuable information like the position of the sun and 
relative geographical coordinates from the hive to the target in question. By interpreting 
this dance, the bees can relay this information or act on it, thus carrying out the 
decentralized will of swarm intelligence. 
Although bees form a caste-based society and have a queen for producing offspring, 
there is no central authority or leader in a beehive. The highly intelligent and 
sophisticated behavior exhibited by a multi-thousand-member colony is an emergent 
property that arises from the interaction of the individuals in a social network. 
Nature demonstrates that decentralized systems can be resilient and can produce 
emergent complexity and incredible sophistication without the need for a central 
authority, hierarchy, or complex parts. 
Conventions used in this book 
The following typographical conventions are used in this book: 
Italic 
Indicates new terms, URLs, email addresses, filenames, and file extensions. 
Constant width 
Used for program listings, as well as within paragraphs to refer to program elements 
such as variable or function names, databases, data types, environment variables, 
statements, and keywords. 
 
Constant width bold 
Shows commands or other text that should be typed literally by the user. 
Constant width italic 
Shows text that should be replaced with user-supplied values or values determined by 
context. 
Tip This icon signifies a tip or 
suggestion. 
 
Note This icon signifies a general 
note. 
 
Warning This icon indicates a warning or 
caution. 
Code examples 
The examples are illustrated in Solidity, Vyper, and JavaScript, and using the command 
line of a Unix-like operating system. All code snippets are available in the GitHub 
repository under the code subdirectory. Fork the book code, try the code examples, or 
submit corrections via GitHub: 
https://github.com/ethereumbook/ethereumbook 
All the code snippets can be replicated on most operating systems with a minimal 
installation of compilers, interpreters and libraries for the corresponding languages. 
Where necessary, we provide basic installation instructions and step-by-step examples 
of the output of those instructions. 
Some of the code snippets and code output have been reformatted for print. In all such 
cases, the lines have been split by a backslash (\) character, followed by a newline 
character. When transcribing the examples, remove those two characters and join the 
lines again and you should see identical results to those shown in the example. 
All the code snippets use real values and calculations where possible, so that you can 
build from example to example and see the same results in any code you write to 
calculate the same values. For example, the private keys and corresponding public keys 
and addresses are all real. The sample transactions, contracts, blocks, and blockchain 
references have all been introduced to the actual Ethereum blockchain and are part of 
the public ledger, so you can review them. 
Using code examples 
This book is here to help you get your job done. In general, if example code is offered 
with this book, you may use it in your programs and documentation. You do not need to 
contact us for permission unless you’re reproducing a significant portion of the code. 
For example, writing a program that uses several chunks of code from this book does 
not require permission. Selling or distributing a CD-ROM of examples from O’Reilly 
books does require permission. Answering a question by citing this book and quoting 
example code does not require permission. Incorporating a significant amount of 
example code from this book into your product’s documentation does require 
permission. 
We appreciate, but do not require, attribution. An attribution usually includes the title, 
author, publisher, ISBN, and copyright. For example: " ​Mastering Ethereum​ by Andreas 
M. Antonopoulos and Gavin Wood (O’Reilly), 978-1-491-97194-9. Copyright 2018." 
Some editions of this book are offered under an open source license, such as 
CC-BY-NC​, in which case the terms of that license apply. 
If you feel your use of code examples falls outside fair use or the permission given 
above, feel free to contact us at ​permissions@oreilly.com​. 
References to companies and products 
All references to companies and products are intended for educational, demonstration, 
and reference purposes. The authors do not endorse any of the companies or products 
mentioned. We have not tested the operation or security of any of the products, projects 
or code segments shown in this book. Use them at your own risk! 
Ethereum addresses and transactions in this book 
The Ethereum addresses, transactions, keys, QR codes, and blockchain data used in 
this book are, for the most part, real. That means you can browse the blockchain, look 
at the transactions offeredas examples, retrieve them with your own scripts or 
programs, etc. 
However, note that the private keys used to construct the addresses printed in this book 
have been "burned". This means that if you send money to any of these addresses, the 
money will either be lost forever or will likely be taken since anyone who reads the book 
can take it using the private keys printed herein. 
Warning DO NOT SEND MONEY TO ANY OF THE ADDRESSES IN THIS 
BOOK. Your money will be taken by another reader, or lost forever. 
 
 
O’Reilly Safari 
Note Safari​ (formerly Safari Books Online) is a membership-based training and 
reference platform for enterprise, government, educators, and individuals. 
Members have access to thousands of books, training videos, Learning Paths, 
interactive tutorials, and curated playlists from over 250 publishers, including O’Reilly 
Media, Harvard Business Review, Prentice Hall Professional, Addison-Wesley 
Professional, Microsoft Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco 
Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe 
Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, and 
Course Technology, among others. 
For more information, please visit ​http://oreilly.com/safari​. 
How to contact us 
Please address comments and questions concerning this book to the publisher: 
● O'Reilly Media, Inc. 
● 1005 Gravenstein Highway North 
● Sebastopol, CA 95472 
● 800-998-9938 (in the United States or Canada) 
● 707-829-0515 (international or local) 
● 707-829-0104 (fax) 
Send comments or technical questions about this book to ​bookquestions@oreilly.com​. 
For more information about our books, courses, conferences, and news, see our 
website at ​https://www.oreilly.com​. 
Find us on Facebook: ​https://facebook.com/oreilly 
Follow us on Twitter: ​https://twitter.com/oreillymedia 
Watch us on YouTube: ​https://www.youtube.com/oreillymedia 
Contacting the authors 
Information about ​Mastering Ethereum​ as well as the Open Edition and translations are 
available on: ​https://ethereumbook.info/ 
Contacting Andreas 
You can contact Andreas M. Antonopoulos on his personal site: 
https://antonopoulos.com/ 
Subscribe to Andreas’s channel on YouTube: ​https://www.youtube.com/aantonop 
Like Andreas’s page on Facebook: ​https://www.facebook.com/AndreasMAntonopoulos 
Follow Andreas on Twitter: ​https://twitter.com/aantonop 
Connect with Andreas on LinkedIn: ​https://linkedin.com/company/aantonop 
Andreas would also like to thank all of the patrons who support his work through 
monthly donations. You can support Andreas on Patreon at: 
https://patreon.com/aantonop 
Contacting Gavin 
You can contact Dr. Gavin Wood on his personal site: ​http://gavwood.com/ 
Follow Gavin on Twitter: ​https://twitter.com/gavofyork 
Gavin generally hangs out in the Polkadot Watercooler on Riot.im: 
https://riot.im/app/#/room/#polkadot-watercooler:matrix.org 
Acknowledgments by Andreas 
I owe my love of words and books to my mother, Theresa, who raised me in a house 
with books lining every wall. My mother also bought me my first computer in 1982, 
despite being a self-described technophobe. My father, Menelaos, a civil engineer who 
published his first book at 80 years old, was the one who taught me logical and 
analytical thinking and a love of science and engineering. 
Thank you all for supporting me throughout this journey. 
Acknowledgments by Gavin 
My mother secured my first computer for me at the age of 9 years from a neighbor 
without which my technical progress would no doubt have been lessened. I also owe 
her my childhood fear of electricity and must acknowledge Trevor and my grandparents, 
who performed the grave duty of "watching me plug it in" time after time, and without 
whom said computer would have been useless. I must also acknowledge the various 
educators I have been lucky to have through my life, from said neighbor Sean (who 
taught me my first computer program), to Mr. Quinn my primary school teacher who 
fixed it for me to do more programming and less history through to secondary-school 
teachers like Richard Furlong-Brown, who fixed it for me to do more programming and 
less rugby. 
I must thank the mother of my children, Jutta, for continued support and the many 
people in my life, friends new and old, that keep me, roughly-speaking, sane. Finally, a 
huge dollop of thanks must go to Aeron Buchanan without whom the last five years of 
my life could never possibly have unfolded in the way they did and without whose time, 
support and guidance this book would not be in as good a shape as it is. 
Contributions 
Many contributors offered comments, corrections, and additions to the early-release 
draft on GitHub. 
Contributions on GitHub were facilitated by two GitHub editors who volunteered to 
project manage, review, edit, merge and approve pull requests and issues: 
● Lead Github Editor: Francisco Javier Rojas Garcia (fjrojasgarcia) 
● Assisting Github Editor: William Binns (wbnns) 
Major contributions were provided in the chapters on DApps, ENS, Fork History, Gas, 
EVM, Oracles, Smart Contract Security and Vyper. Additional contributions, which were 
not included in the first edition due to time and space constraints can be found in the 
contrib folder on the GitHub repository. Thousands of smaller contributions were 
provided throughout the book, improving the quality, legibility and accuracy of the book. 
Sincere thanks to all those who contributed! 
Following is an alphabetically sorted list of all GitHub contributors, including their GitHub 
ID in parentheses: 
● Abhishek Shandilya (abhishandy) 
● Adam Zaremba (zaremba) 
● Adrian Li (adrianmcli) 
● Adrian Manning (agemanning) 
● Alejandro Santander (ajsantander) 
● Alejo Salles (fiiiu) 
● Alex Manuskin (amanusk) 
● Alex Van de Sande (alexvandesande) 
● Anthony Lusardi (pyskell) 
● Assaf Yossifoff (assafy) 
● Ben Kaufman (ben-kaufman) 
● Bok Khoo (bokkypoobah) 
● Brian Ethier (dbe) 
● Bryant Eisenbach (fubuloubu) 
● Chanan Sack (chanan-sack) 
● Christopher Gondek (christophergondek) 
● Chris Remus (chris-remus) 
● Cornell Blockchain (CornellBlockchain) 
○ Alex Frolov (sashafrolov) 
○ Brian Guo (BrianGuo) 
○ Brian Leffew (bleffew99) 
○ Giancarlo Pacenza (GPacenza) 
○ Lucas Switzer (LucasSwitz) 
○ Ohad Koronyo (ohadh123) 
○ Richard Sun (richardsfc) 
● Cory Solovewicz (CorySolovewicz) 
● Dan Shields (NukeManDan) 
● Daniel Jiang (WizardOfAus) 
● Daniel McClure (danielmcclure) 
● Daniel Peterson (danrpts) 
● Denis Milicevic (D-Nice) 
● Dennis Zasnicoff (zasnicoff) 
● Diego H. Gurpegui (diegogurpegui) 
● Dimitris Tsapakidis (dimitris-t) 
● Enrico Cambiaso (auino) 
● Ersin Bayraktar (ersinbyrktr) 
● Flash Sheridan (FlashSheridan) 
● Franco Daniel Berdun (fMercury) 
● Harry Moreno (morenoh149) 
● Hon Lau (masterlook) 
● Hudson Jameson (Souptacular) 
● Iuri Matias (iurimatias) 
● Ivan Molto (ivanmolto) 
● Jacques Dafflon (jacquesd) 
● Jason Hill (denifednu) 
● Javier Rojas (fjrojasgarcia) 
● Joel Gugger (guggerjoel) 
● Jonathan Velando (rigzba21) 
● Jon Ramvi (ramvi) 
● Jules Lainé (fakje) 
● Kevin Carter (kcar1) 
● Krzysztof Nowak (krzysztof) 
● Lane Rettig (lrettig) 
● Leo Arias (elopio) 
● Luke Schoen (ltfschoen) 
● Liang Ma (liangma) 
● Marcelo Creimer (mcreimer) 
● Martin Berger (drmartinberger) 
● Masi Dawoud (mazewoods) 
● Matthew Sedaghatfar (sedaghatfar) 
● Michael Freeman (stefek99) 
● Miguel Baizan (mbaiigl) 
● Mike Pumphrey (bmmpxf) 
● Mobin Hosseini (iNDicat0r) 
● Nagesh Subrahmanyam (chainhead) 
● Nichanan Kesonpat (nichanank) 
● Nick Johnson (arachnid) 
● Omar Boukli-Hacene (oboukli) 
● Paulo Trezentos (paulotrezentos) 
● Pet3rpan (pet3r-pan) 
● Pierre-Jean Subervie(pjsub) 
● Pong Cheecharern (Pongch) 
● Qiao Wang (qiaowang26) 
● Raul Andres Garcia (manilabay) 
● Roger Häusermann (haurog) 
● Solomon Victorino (bitsol) 
● Steve Klise (sklise) 
● Sylvain Tissier (SylTi) 
● Taylor Masterson (tjmasterson) 
● Tim Nugent (timnugent) 
● Timothy McCallum (tpmccallum) 
● Tomoya Ishizaki (zaq1tomo) 
● Vignesh Karthikeyan (meshugah) 
● Will Binns (wbnns) 
● Xavier Lavayssière (xalava) 
● Yash Bhutwala (yashbhutwala) 
● Yeramin Santana (ysfdev) 
● Zhen Wang (zmxv) 
● ztz (zt2) 
Without the help offered by everyone listed above, this book would not have been 
possible. Your contributions demonstrate the power of open source and open culture, 
and we are eternally grateful for your help. Thank you. 
Sources 
Some of the content of this book references or sources various public and 
open-licensed sources: 
https://github.com/ethereum/vyper/blob/master/README.md 
License: The MIT License (MIT) 
{nbspc} 
https://vyper.readthedocs.io/en/latest/ 
License: The MIT License (MIT) 
{nbspc} 
https://solidity.readthedocs.io/en/v0.4.21/common-patterns.html 
License: The MIT License (MIT) 
{nbspc} 
https://arxiv.org/pdf/1802.06038.pdf 
License: Arxiv Non-Exclusive-Distribution 
{nbspc} 
https://github.com/ethereum/solidity/blob/release/docs/contracts.rst#inheritance 
License: The MIT License (MIT) 
{nbspc} 
https://github.com/trailofbits/evm-opcodes 
License: Apache 2.0 
{nbspc} 
https://github.com/ethereum/EIPs/ 
License: Creative Commons CC0 
{nbspc} 
https://blog.sigmaprime.io/solidity-security.html 
Licence: Creative Commons CC BY 4.0 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Quick Glossary 
This quick glossary contains many of the terms used in relation to Ethereum. These 
terms are used throughout the book, so bookmark this for quick reference. 
Account 
An object containing an address, balance, nonce, and optional storage and code. An 
account can be a contract account or an EOA (externally owned account). 
Address 
Most generally, this represents an EOA or contract that can receive (destination 
address) or send (source address) transactions on the blockchain. More specifically, it 
is the right-most 160 bits of a Keccak hash of an ECDSA public key. 
Assert 
In Solidity, assert(false) compiles to 0xfe, an invalid opcode, which uses up all 
remaining gas and reverts all changes. When an assert() statement fails, something 
very wrong and unexpected should be happening, and you will need to fix your code. 
You should use assert to avoid conditions which should never, ever occur. 
Big-endian 
A positional number representation where the most significant digit is first. The opposite 
of little-endian, where the least significant digit is first. 
 
 
 
 
BIP 
Bitcoin Improvement Proposals. A set of proposals that members of the Bitcoin 
community have submitted to improve Bitcoin. For example, BIP-21 is a proposal to 
improve the Bitcoin uniform resource identifier (URI) scheme. 
Block 
A block is a collection of required information (a block header) about the comprised 
transactions, and a set of other block headers known as ommers. It is added to the 
Ethereum network by miners. 
Blockchain 
In Ethereum, a sequence of blocks validated by the proof-of-work system, each linking 
to its predecessor all the way to the genesis block. This varies from the Bitcoin protocol 
in that it does not have a block size limit; it instead uses varying gas limits. 
Bytecode 
Abstract instruction set designed for efficient execution by a software interpreter or a 
virtual machine. Unlike human readable source code, bytecode is expressed in numeric 
format. 
Byzantium fork 
Byzantium is the first of two hard forks for the Metropolis development stage. It included 
EIP-649: Metropolis Difficulty Bomb Delay and Block Reward Reduction, where the Ice 
Age (see below) was delayed by 1 year, and the block reward was reduced from 5 to 3 
ether. 
 
 
Compiling 
Converting code written in a high-level programming language (e.g. Solidity) into a 
lower level language (e.g. EVM bytecode). 
Consensus 
When numerous nodes, usually most nodes on the network, all have the same blocks in 
their locally validated best block chain. Not to be confused with "consensus rules". 
Consensus rules 
The block validation rules that full nodes follow to stay in consensus with other nodes. 
Not to be confused with "consensus". 
Constantinople 
The second part of the Metropolis stage, planned for mid-2018. Expected to include a 
switch to hybrid Proof-of-Work/Proof-of-Stake consensus algorithm, among other 
changes. 
Contract account 
An account containing code that executes whenever it receives a transaction from 
another account (EOA or contract). 
Contract creation transaction 
A special transaction, with the "zero address" as the recipient, that is used to register a 
contract and record it on the Ethereum blockchain (see "zero address"). 
 
DAO 
Decentralized Autonomous Organization. Companies and other organizations which 
operate without hierarchical management. Also may refer to a contract named "The 
DAO" launched on 30th April 2016, which was then hacked in June 2016 and ultimately 
motivated a hard fork (codenamed DAO) at block #1,192,000 which reversed the 
hacked DAO contract, and caused Ethereum and Ethereum Classic to split into two 
competing systems. 
DApp 
Decentralized Application. At a minimum, it is a smart contract and a web 
user-interface. More broadly, a DApp is a web application that is built on top of open, 
decentralized, peer-to-peer infrastructure services. In addition, many DApps include 
decentralized storage and/or message protocol and platform. 
Deed 
Non-fungible token (NFT) standard introduced by the ERC721 proposal. Unlike ERC20 
tokens, deeds prove ownership and are not interchangeable, though they are not 
recognized as legal documents in any jurisdiction, at least not currently (see also 
"NFT"). 
Difficulty 
A network-wide setting that controls how much computation is required to produce a 
proof of work. 
Digital signature 
A digital signing algorithm is a process by which a user can produce a short string of 
data called a "signature" of a document using a private key such that anyone with the 
corresponding public key, the signature, and the document can verify that (1) the 
document was "signed" by the owner of that particular private key, and (2) the 
document was not changed after it was signed. 
ECDSA 
Elliptic Curve Digital Signature Algorithm, or ECDSA, is a cryptographic algorithm used 
by Ethereum to ensure that funds can only be spent by their owners. 
EIP 
Ethereum Improvement Proposals describe proposed standards for the Ethereum 
platform. An EIP is a design document providing information to the Ethereum 
community, describing a new feature or its processes or environment. For more 
information, see ​https://github.com/ethereum/EIPs​ (see also "ERC"). 
Entropy 
In the context of cryptography, lack of predictability, or level of randomness. When 
generating secret information, such as private keys, algorithms usually rely on a source 
of high entropy to ensure the output is unpredictable. 
ENS 
Ethereum Name Service. For more information, see ​https://github.com/ethereum/ens/​. 
EOA 
Externally Owned Account. Accounts created by or for human users of the Ethereum 
network. 
 
 
ERC 
Ethereum Request for Comments, a label given to some EIPs which attempt to define a 
specific standard of Ethereum usage. 
Ethash 
A Proof-of-Work algorithm for Ethereum 1.0. For more information, see 
https://github.com/ethereum/wiki/wiki/Ethash​. 
Ether 
Ether is the native cryptocurrency used by the Ethereum ecosystem, which covers gas 
costs when executing Smart Contracts. Its symbol is Ξ, the Greek uppercase Xi 
character. 
Event 
An event allows the use of EVM logging facilities. DApps can listen for events and use 
them to trigger JavaScript callbacks in the user interface. For more information, see 
http://solidity.readthedocs.io/en/develop/contracts.html#events ​. 
EVM 
Ethereum Virtual Machine, a stack-based virtual machine which executes bytecode. In 
Ethereum, the execution model specifies how the system state is altered given a series 
of bytecode instructions and a small tuple of environmental data. This is specified 
through a formal model of a virtual state machine. 
EVM assembly language 
A human-readable form of EVM bytecode. 
Fallback function 
A default function called in the absence of data or a declared function name. 
Faucet 
A service that dispenses funds in the form of free test ether that can be used on a 
testnet. 
Finney 
A denomination of ether. 10 ​15​ finney = 1 ether. 
Fork 
This term assumes two main meanings: a change in protocol causing the creation of an 
alternative chain, or a temporal divergence in two potential block paths during mining. 
Frontier 
The initial test development stage of Ethereum, which lasted from July 2015 to March 
2016. 
Ganache 
Personal Ethereum blockchain which you can use to run tests, execute commands, and 
inspect state while controlling how the chain operates. 
 
 
 
Gas 
A virtual fuel used in Ethereum to execute smart contracts. The Ethereum Virtual 
Machine uses an accounting mechanism to measure the consumption of gas and limit 
the consumption of computing resources (see "Turing complete"). 
Gas limit 
The maximum amount of gas a transaction or block may consume. 
Gavin Wood 
Gavin Wood is a British programmer who is the co-founder and former CTO of 
Ethereum. In August 2014 he proposed Solidity, a contract-oriented programming 
language for writing smart contracts. 
Genesis block 
The first block in a blockchain, used to initialize a particular network and its 
cryptocurrency. 
Geth 
Go Ethereum. One of the most prominent implementations of the Ethereum protocol, 
written in Go. 
Hard fork 
A hard fork, also known as a Hard-Forking Change, is a permanent divergence in the 
blockchain; one commonly occurs when non-upgraded nodes can’t validate blocks 
created by upgraded nodes that follow newer consensus rules. Not to be confused with 
fork, soft fork, software fork or Git fork. 
Hash 
A fixed-length fingerprint of variable-size input, produced by a hash function. 
HD wallet 
A wallet using the Hierarchical Deterministic (HD Protocol) key creation and transfer 
protocol (BIP32). 
HD wallet seed 
An HD wallet seed, or seed, is a value used to generate the master private key and 
master chain code for an HD wallet. The wallet seed can be represented by mnemonic 
words, making it easier for humans to copy, backup and restore private keys. 
Homestead 
The second development stage of Ethereum, launched in March 2016 at block 
#1,150,000. 
Ice Age 
A hard fork of Ethereum at block #200,000 to introduce an exponential difficulty 
increase (aka Difficulty Bomb), motivating a transition to Proof-of-Stake. 
IDE (Integrated Development Environment) 
An integrated user interface that typically combines a code editor, compiler, runtime, 
and debugger. 
 
 
Immutable Deployed Code Problem 
Once a contract’s (or library’s) code is deployed it becomes immutable. Standard 
software development practices rely on being able to fix possible bugs and add new 
features, so this represents a challenge for smart contract development. 
Inter-exchange Client Address Protocol (ICAP) 
An Ethereum Address encoding that is partly compatible with the International Bank 
Account Number (IBAN) encoding, offering a versatile, checksummed and interoperable 
encoding for Ethereum Addresses. ICAP addresses use a new IBAN pseudo-country 
code: XE, standing for "eXtended Ethereum", as used in non-jurisdictional currencies 
(e.g. XBT, XRP, XCP). 
Internal transaction (also "message") 
A transaction sent from a contract account to another contract account or an EOA. 
IPFS 
The Inter Planetary File System is a protocol, a network and an open-source project 
designed to create a content-addressable, peer-to-peer method of storing and sharing 
hypermedia in a distributed file system. 
Keccak256 
Cryptographic hash function used in Ethereum. Keccak256 was standardized as SHA-3. 
 
 
 
Key Derivation Function (KDF) 
Also known as a "password stretching algorithm", it is used by keystore formats to 
protect against brute-force, dictionary, and rainbow table attacks on passphrase 
encryption, by repeatedly hashing the passphrase. 
Keystore File 
A JSON-encoded file that contains a single (randomly generated) private key, encrypted 
by a passphrase for extra security. 
LevelDB 
LevelDB is an open source on-disk key-value store, implemented as a light-weight, 
single-purpose library, with bindings to many platforms. 
Library 
A library in Ethereum is a special type of contract that has no payable functions, no 
fallback function, and no data storage. Therefore, it cannot receive or hold ether, or 
store data. A library serves as previously deployed code that other contracts can call for 
read-only computation. 
Lightweight client 
A lightweight client is an Ethereum client that does not store a local copy of the 
blockchain, or validate blocks and transactions. It offers the functions of a wallet and 
can create and broadcast transactions. 
Merkle Patricia Tree 
A data structure used in Ethereum to efficiently store key-value pairs. 
Message 
An internal transaction that is never serialized and only sent within the EVM. 
Message Call 
The act of passing a message from one Account to another. If the destination account is 
associated with EVM Code, then the VM will be started with the state of said Object and 
the Message acted upon. 
Metropolis Stage 
Metropolis is the third development stage of Ethereum, launched in October 2017. 
METoken 
Mastering Ethereum Token. An ERC20 token used for demonstration in this book. 
Miner 
A network node that finds valid proof of work for new blocks, by repeated hashing. 
Mist 
The first Ethereum-enabled browser, built by the Ethereum Foundation. It contains a 
browser based wallet that was the first implementation of the ERC20 token standard 
(Fabian Vogelsteller, author of ERC20, was also the main developer of Mist). Mist was 
also the first wallet to introduce the camelCase checksum (EIP-55, see ​[eip55]​). Mist 
runs a full node, and offers a full DApp browser with support for Swarm-based storage 
and ENS addresses. 
 
Network 
Referring to the Ethereum network, a peer-to-peer network that propagates transactions 
and blocks to every Ethereum node (network participant). 
NFT 
A non-fungible token (also known as a "deed"). This is a token standard introduced by 
the ERC721 proposal. NFTs can be tracked and traded, but each token is unique and 
distinct; they are not interchangeable like ERC20 tokens. NFTs can represent 
ownership of digital or physical assets. 
Node 
A software client that participates in the network. 
Nonce 
In cryptography, a value that can only be used once. There are two types of nonce used 
in Ethereum. (1) An account nonce: A transaction counter in each account, which is 
used to prevent replay attacks. (2) Proof of work nonce: The random value in a block 
that was used to satisfy the proof of work. 
Ommer 
A child block of an ancestor that is not itself an ancestor. When a minerfinds a valid 
block, another miner may have published a competing block which is added to the tip of 
the blockchain. Unlike Bitcoin, orphaned blocks in Ethereum can be included by newer 
blocks as ommers and receive a partial block reward. The term "ommer" is the preferred 
gender-neutral term for the sibling of a parent node, but is also sometimes referred to as 
an "uncle". 
 
Parity 
One of the most prominent interoperable implementations of the Ethereum client 
software. 
Private key 
See "Secret Key". 
Proof-of-Stake (PoS) 
Proof-of-Stake is a method by which a cryptocurrency blockchain protocol aims to 
achieve distributed consensus. Proof-of-Stake asks users to prove ownership of a 
certain amount of cryptocurrency (their "stake" in the network) in order to be able to 
participate in the validation of transactions. 
Proof-of-Work (PoW) 
A piece of data (the proof) that requires significant computation to find. In Ethereum, 
miners must find a numeric solution to the Ethash algorithm that meets a network-wide 
difficulty target. 
Public key 
A number, derived via a one-way function from a private key, which can be shared 
publicly and used by anyone to verify a digital signature made with the corresponding 
private key. 
 
 
 
Receipt 
Data returned by an Ethereum client to represent the result of a particular transaction, 
including a hash of the transaction, its block number, the amount of gas used and, in 
case of deployment of a Smart Contract, the address of the Contract. 
Re-entrancy attack 
An attack that consists of an Attacker contract calling a Victim contract function in such 
a way that during execution the Victim calls the Attacker contract again, recursively. 
This can result, for example, in the theft of funds by skipping parts of the Victim contract 
that update balances or count withdrawal amounts. 
Reward 
An amount of ether included in each new block as a reward by the network to the miner 
who found the Proof-of-Work solution. 
Recursive Length Prefix (RLP) 
An encoding standard designed by the Ethereum developers to encode and serialize 
objects (data structures) of arbitrary complexity and length. 
Satoshi Nakamoto 
The name used by the person or people who designed Bitcoin, created its original 
reference implementation, and were the first to solve the double-spend problem for 
digital currency. Their real identity remains unknown. 
 
 
 
Singleton 
A computer programming term that describes an object of which only a single instance 
can exist. 
Secret key (aka private key) 
The secret number that allows Ethereum users to prove ownership of an account or 
contracts, by producing a digital signature (see public key, address, ECDSA). 
SHA 
The Secure Hash Algorithm (SHA) is a family of cryptographic hash functions published 
by the National Institute of Standards and Technology (NIST). 
Serenity 
The fourth and final development stage of Ethereum. Serenity does not yet have a 
planned release date. 
Serpent 
A procedural (imperative) smart contract programming language with syntax similar to 
Python. 
Smart contract 
A program which executes on the Ethereum computing infrastructure. 
 
 
Solidity 
A procedural (imperative) programming language with syntax that is similar to 
JavaScript, C++ or Java. The most popular and most frequently used language for 
Ethereum smart contracts. Created by Gavin Wood (co-author of this book). 
Solidity inline assembly 
EVM assembly language in a Solidity program. Solidity’s support for inline assembly 
makes it easier to write certain operations. 
Spurious Dragon 
A hard fork of the Ethereum blockchain, which occurred at block #2,675,000 to address 
more denial of service attack vectors, and another state clearing; see "Tangerine 
Whistle". Also, a replay attack protection mechanism. 
Swarm 
A decentralized (P2P) storage network, used along with Web3 and Whisper to build 
DApps. 
Szabo 
A denomination of ether. 10 ​12​ szabo = 1 ether. 
Tangerine Whistle 
A hard fork of the Ethereum blockchain, which occurred at block #2,463,000 to change 
the gas calculation for certain I/O-intensive operations and to clear the accumulated 
state from a denial of service attack, which exploited the low gas cost of those 
operations. 
Testnet 
Short for "test network", a network used to simulate the behavior of the main Ethereum 
network. 
Transaction 
Data committed to the Ethereum Blockchain signed by an originating account, targeting 
a specific address. The transaction contains metadata such as the gas limit for the 
transaction. 
Truffle 
One of the most commonly used Ethereum Development Frameworks. 
Turing complete 
A system of data-manipulation rules (such as a computer’s instruction set, a 
programming language, or a cellular automaton) is said to be "Turing complete" or 
"computationally universal" if it can be used to simulate any Turing machine. The 
concept is named after English mathematician and computer scientist Alan Turing. 
Vitalik Buterin 
Vitalik Buterin is a Russian–Canadian programmer and writer primarily known as the 
co-founder of Ethereum and as the co-founder of Bitcoin Magazine. 
Vyper 
A high-level programming language, similar to Serpent, with Python-like syntax. 
Intended to get closer to a pure-functional language. Created by Vitalik Buterin. 
 
Wallet 
Software that holds secret keys. Used to access and control Ethereum accounts and 
interact with Smart Contracts. Keys need not be stored in a wallet, and can instead be 
retrieved from an offline storage (e.g. a memory card or paper) for improved security. 
Despite the name, wallets never store the actual coins or tokens. 
Web3 
The third version of the web. First proposed by Gavin Wood, Web3 represents a new 
vision and focus for web applications: from centrally owned and managed applications, 
to applications built on decentralized protocols. 
Wei 
The smallest denomination of ether. 10 ​18​ wei = 1 ether. 
Whisper 
A decentralized (P2P) messaging service. It is used along with Web3 and Swarm to 
build DApps. 
Zero address 
A special Ethereum address, composed entirely of zeros, that is specified as the 
destination address of a contract creation transaction. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
What is Ethereum? 
Ethereum is often described as "the World Computer". But what does that mean? Let’s 
start with a computer science–focused description, and then try to decipher that with a 
more practical analysis of Ethereum’s capabilities and characteristics, while comparing 
it to Bitcoin and other decentralized information exchange platforms (or "blockchains" 
for short). 
From a computer science perspective, Ethereum is a deterministic but practically 
unbounded state machine, consisting of a globally-accessible singleton state and a 
virtual machine that applies changes to that state. 
From a more practical perspective, Ethereum is an open source, globally decentralized 
computing infrastructure that executes programs called ​smart contracts​. It uses a 
blockchain to synchronize and store the system’s ​state​ changes, along with a 
cryptocurrency called ​ether​ to meter and constrain execution resource costs. 
The Ethereum platform enables developers to build powerful decentralized applications 
with built-in economic functions. While providing high availability, auditability, 
transparency and neutrality, it also reduces or eliminates censorship, and reduces 
certain counterparty risks. 
Compared to Bitcoin 
Many people will come to Ethereum with some prior experience of cryptocurrencies, 
specifically Bitcoin. Ethereum shares many common elements with other open 
blockchains: apeer-to-peer network connecting participants, a Byzantine fault-tolerant 
consensus algorithm for synchronization of state updates (a proof-of-work blockchain), 
the use of cryptographic primitives such as digital signatures and hashes, and a digital 
currency (ether). 
Components of a blockchain 
The components of an open, public, blockchain are (usually): 
● A peer-to-peer network connecting participants and propagating transactions and 
blocks of verified transactions, based on a standardized "gossip" protocol. 
● Messages, in the form of transactions, representing state transitions. 
● A set of consensus rules, governing what constitutes a transaction and what 
makes for a valid state transition. 
● A state machine that processes transactions according to the consensus rules. 
● A chain of cryptographically secured blocks that acts as a journal of all the 
verified and accepted state transitions. 
● A consensus algorithm that decentralizes control over the blockchain, by forcing 
participants to cooperate in the enforcement of the consensus rules. 
● A game-theoretically sound incentivization scheme (e.g. proof-of-work costs plus 
block rewards) to economically secure the state machine in an open 
environment. 
● One or more open source software implementations of the above ("clients"). 
All or most of these components are usually combined in a single software client. For 
example, in Bitcoin, the reference implementation is developed by the ​Bitcoin Core 
open source project, and implemented as the bitcoind client. In Ethereum, rather than a 
reference implementation, there is a ​reference specification​, a mathematical description 
of the system in the Yellow Paper (see ​Further references​). There are a number of 
clients, which are built according to the reference specification. 
In the past, we used the term "blockchain" to represent all of the components above, as 
a short-hand reference to the combination of technologies that encompass all of the 
characteristics described. Today, however, there is a huge variety of blockchains with 
different properties. We need qualifiers to help us understand the characteristics of the 
blockchain in question, such as ​open, public, global, decentralized, neutral, and 
censorship-resistant ​, to identify the important emergent characteristics of a "blockchain" 
system that these components allow. 
Not all blockchains are created equal. When you are told that something is a 
blockchain, you have not received an answer; rather, you need to start asking a lot of 
questions to clarify what they mean when they use the word "blockchain". Start by 
asking for a description of the components above, then ask about whether this 
"blockchain" exhibits the characteristics of being ​open, public, etc.​. 
Development of Ethereum 
In many ways, both the purpose and construction of Ethereum are strikingly different 
from the open blockchains that preceded it, including Bitcoin. 
Ethereum’s purpose is not primarily to be a digital currency payment network. While the 
digital currency ​ether​ is both integral to and necessary for the operation of Ethereum, 
ether is intended as a ​utility currency​ to pay for use of the Ethereum platform as the 
"World Computer". 
Unlike Bitcoin, which has a very limited scripting language, Ethereum is designed to be 
a general-purpose programmable blockchain that runs a ​virtual machine​ capable of 
executing code of arbitrary and unbounded complexity. Where Bitcoin’s Script language 
is, intentionally, constrained to simple true/false evaluation of spending conditions, 
Ethereum’s language is ​Turing complete​, meaning that Ethereum can straightforwardly 
function as a general-purpose computer. 
The Birth of Ethereum 
All great innovations solve real problems, and Ethereum is no exception. Ethereum was 
conceived at a time when people recognized the power of the Bitcoin model, and were 
trying to move beyond cryptocurrency applications. But developers faced a conundrum: 
they either needed to build on top of Bitcoin or start a new blockchain. Building upon 
Bitcoin meant living within the intentional constraints of the network and trying to find 
workarounds. The limited set of transaction types, data types and sizes of data storage 
seemed to limit the sorts of applications that could run directly on Bitcoin; anything else 
needed additional off-chain layers, and that immediately negated many of the 
advantages of using a public blockchain. For projects that needed more freedom and 
flexibility while staying on-chain, a new blockchain was the only option. But that meant a 
lot of work: bootstrapping all the infrastructure elements, exhaustive testing, etc. 
Towards the end of 2013, Vitalik Buterin, a young programmer and Bitcoin enthusiast, 
started thinking about further extending the capabilities of Bitcoin and Mastercoin (an 
overlay protocol that extended Bitcoin to offer rudimentary smart contracts). In October 
of 2013, Vitalik proposed a more generalized approach to the Mastercoin team, one that 
allowed flexible and scriptable (but not Turing complete) contracts to replace the 
specialized contract language of Mastercoin. While the Mastercoin team was 
impressed, this proposal was too radical a change to fit into their development roadmap. 
In December 2013, Vitalik started sharing a white paper which outlined the idea behind 
Ethereum: a Turing-complete, general-purpose blockchain. A few dozen people saw 
this early draft and offered feedback, helping Vitalik evolve the proposal. 
Both of the authors of this book received an early draft of the white paper and 
commented on it. Andreas M. Antonopoulos was intrigued by the idea and asked Vitalik 
many questions about the use of a separate blockchain to enforce consensus rules on 
smart contract execution and the implications of a Turing-complete language. Andreas 
continued to follow Ethereum’s progress with great interest but was in the early stages 
of writing his book ​Mastering Bitcoin​, and did not participate directly in Ethereum until 
much later. Gavin Wood, however, was one of the first people to reach out to Vitalik and 
offer to help with his C++ programming skills. Gavin became Ethereum’s co-founder, 
co-designer and CTO. 
As Vitalik recounts in his ​"Ethereum Prehistory"​ post: 
This was the time when the Ethereum protocol was entirely my own creation. From here on, 
however, new participants started to join the fold. By far the most prominent on the 
protocol side was Gavin Wood... 
Gavin can also be largely credited for the subtle change in vision from viewing Ethereum as 
a platform for building programmable money, with blockchain-based contracts that can hold 
digital assets and transfer them according to pre-set rules, to a general-purpose computing 
platform. This started with subtle changes in emphasis and terminology, and later this 
influence became stronger with the increasing emphasis on the “Web 3” ensemble, which 
saw Ethereum as being one piece of a suite of decentralized technologies, the other two 
being Whisper and Swarm. 
Starting in December 2013, Vitalik and Gavin refined and evolved the idea, together 
building the protocol layer that became Ethereum. 
Ethereum’s founders were thinking about a blockchain without a specific purpose, that 
could support a broad variety of applications by being ​programmed​. The idea was that 
by using a general-purpose blockchain like Ethereum, a developer could program their 
particular application without having to implement the underlying mechanisms of 
peer-to-peer networks, blockchains, consensus algorithms, etc. The Ethereum platform 
was designed to abstract these details and provide a deterministic and secure 
programming environment for decentralized blockchain applications. 
Much like Satoshi, Vitalik and Gavin didn’tjust invent a new technology, they combined 
new inventions with existing technologies in a novel way and delivered the prototype 
code to prove their ideas to the world. 
The founders worked for years, building and refining the vision. And on July 30th 2015, 
the first Ethereum block was mined. The world’s computer started serving the world…​ 
Vitalik Buterin’s article "A Prehistory of Ethereum" was published in September 2017 
and provides a fascinating first-person view of Ethereum’s earliest moments. 
You can read it at ​https://vitalik.ca/general/2017/09/14/prehistory.html 
Ethereum’s four stages of development 
The birth of Ethereum was the launch of the first stage, named "Frontier". Ethereum’s 
development is planned over four distinct stages, with major changes occurring at each 
stage. A stage may include sub-releases, known as "hard forks", that change 
functionality in a way that is not backwards compatible. 
The four main development stages are codenamed Frontier, Homestead, Metropolis 
and Serenity. The intermediate hard forks that have occurred to date are codenamed 
"Ice Age", "DAO", "Tangerine Whistle", "Spurious Dragon", "Byzantium", and 
"Constantinople". Both the development stages and the intermediate hard forks are 
shown on the following timeline, which is "dated" by block number: 
Past transitions 
Block #0 
"Frontier" - The initial stage of Ethereum, lasted from July 30th 2015 to March 2016. 
Block #200,000 
"Ice Age" - A hard fork to introduce an exponential difficulty increase, to motivate a 
transition to Proof-of-Stake when ready. 
Block #1,150,000 
"Homestead" - The second stage of Ethereum, launched in March 2016. 
Block #1,192,000 
"DAO" - The hard fork that reimbursed victims of the hacked DAO contract and caused 
Ethereum and Ethereum Classic to split into two competing systems. 
Block #2,463,000 
"Tangerine Whistle" - A hard fork to change the gas calculation for certain I/O-heavy 
operations and to clear the accumulated state from a denial of service attack, which 
exploited the low gas cost of those operations. 
Block #2,675,000 
"Spurious Dragon" - A hard fork to address more denial of service attack vectors, and 
another state clearing. Also, a replay attack protection mechanism. 
Current state 
We are currently in the ​Metropolis​ stage, which was planned as two sub-release hard 
forks (see ​Future plans​) codenamed ​Byzantium​ and ​Constantinople​. Byzantium went 
into effect in October 2017 and Constantinople is anticipated in 2019. 
Block #4,370,000 
"Metropolis Byzantium" - Metropolis is the third stage of Ethereum, current at the time of 
writing this book, launched in October 2017. Byzantium is the first of two hard forks for 
Metropolis. 
Future plans 
After Metropolis' Byzantium hard fork, there is one more hard fork planned for 
Metropolis. Metropolis will be followed by the final stage of Ethereum’s deployment, 
codenamed Serenity. 
Constantinople 
The second part of the Metropolis stage, planned for mid-2018 but since delayed with 
no set release date. 
 
Serenity 
The fourth and final stage of Ethereum. Serenity does not yet have a planned release 
date. 
Ethereum: A general-purpose blockchain 
The original blockchain, namely Bitcoin’s blockchain, tracks the state of units of bitcoin 
and their ownership. You can think of Bitcoin as a distributed consensus ​state machine​, 
where transactions cause a global ​state transition​, altering the ownership of coins. The 
state transitions are constrained by the rules of consensus, allowing all participants to 
(eventually) converge on a common (consensus) state of the system, after several 
blocks are mined. 
Ethereum is also a distributed state machine. But instead of tracking only the state of 
currency ownership, Ethereum tracks the state transitions of a general-purpose data 
store. By "general-purpose data store" we mean a store that can hold any data 
expressible as a ​key–value tuple​. A key–value data store holds arbitrary values, each 
referenced by some key; for example, the value "Mastering Ethereum" referenced by 
the key "Book Title". In some ways, this serves the same purpose as the data storage 
model of ​Random Access Memory (RAM)​ used by most general-purpose computers. 
Ethereum has ​memory​ that stores both code and data and it uses the Ethereum 
blockchain to track how this memory changes over time. Like a general-purpose 
stored-program computer, Ethereum can load code into its state machine and ​run​ that 
code, storing the resulting state changes in its blockchain. Two of the critical differences 
from most general-purpose computers are that Ethereum state changes are governed 
by the rules of consensus and the state is distributed globally. Ethereum answers the 
question: "What if we could track any arbitrary state and program the state machine to 
create a world-wide computer operating under consensus?" 
Ethereum’s components 
In Ethereum, the components of a blockchain system described in ​Components of a 
blockchain ​ are, more specifically: 
 
 
P2P Network 
Ethereum runs on the ​Ethereum Main Network​, which is addressable on TCP port 
30303, and runs a protocol called ​ÐΞVp2p​. 
Consensus rules 
Ethereum’s consensus rules are defined in the reference specification, the Yellow Paper 
(see <<references>). 
Transactions 
Ethereum transactions are network messages that include (among other things) a 
sender, recipient, value and data payload. 
State Machine 
Ethereum state transitions are processed by the ​Ethereum Virtual Machine (EVM)​, a 
stack-based virtual machine that executes ​bytecode​ (machine-language instructions). 
EVM programs, called "smart contracts", are written in high-level languages (e.g. 
Solidity) and compiled to bytecode for execution on the EVM. 
Data Structures 
Ethereum’s state is stored locally on each node as a ​database​ (usually Google’s 
LevelDB), which contains the transactions and system state in a serialized hashed data 
structure called a ​Merkle Patricia Tree​. 
Consensus Algorithm 
Ethereum uses Nakamoto Consensus, i.e. Bitcoin’s consensus model, which uses 
sequential single-signature blocks, weighted in importance by Proof-of-Work to 
determine the longest chain and therefore the current state. However, there are plans to 
move to a Proof-of-Stake weighted voting system, codenamed ​Casper​, in the near 
future. 
Economic Security 
Ethereum currently uses a Proof-of-Work algorithm called ​Ethash​, but this will 
eventually be dropped with the move to Proof-of-Stake at some point in the future. 
Clients 
Ethereum has several interoperable implementations of the client software, the most 
prominent of which are ​Go-Ethereum (Geth)​ and ​Parity​. 
Further references 
The Ethereum Yellow Paper: ​https://ethereum.github.io/yellowpaper/paper.pdf 
The "Beige Paper": a rewrite of the "Yellow Paper" for a broader audience in less formal 
language: ​https://github.com/chronaeon/beigepaper 
ÐΞVp2p network protocol: 
https://github.com/ethereum/wiki/wiki/%C3%90%CE%9EVp2p-Wire-Protocol 
Ethereum Virtual Machine - a list of resources: 
https://github.com/ethereum/wiki/wiki/Ethereum-Virtual-Machine-(EVM)-Awesome-List 
LevelDB Database (used most often to store the local copy of the blockchain): 
http://leveldb.org 
Merkle Patricia Trees: ​https://github.com/ethereum/wiki/wiki/Patricia-Tree 
Ethash Proof-of-Work: ​https://github.com/ethereum/wiki/wiki/Ethash 
Casper Proof-of-Stake v1 Implementation Guide: 
https://github.com/ethereum/research/wiki/Casper-Version-1-Implementation-Guide 
Go-Ethereum (Geth) Client: ​https://geth.ethereum.org/ 
Parity Ethereum Client: ​https://parity.io/ 
Ethereum and Turing completeness 
As soon as you start reading about Ethereum,you will immediately hear the term 
"Turing complete". Ethereum, they say, unlike Bitcoin, is "Turing complete". What 
exactly does that mean? 
The term refers to English mathematician Alan Turing, who is considered the father of 
computer science. In 1936 he created a mathematical model of a computer consisting 
of a state machine that manipulates symbols by reading and writing them on sequential 
memory (resembling an infinite-length paper tape). With this construct, Turing went on 
to provide a mathematical foundation to answer (in the negative) questions about 
universal computability ​, meaning whether all problems are solvable. He proved that 
there are classes of problems that are uncomputable. Specifically, he proved that the 
Halting Problem​(whether it is possible, given an arbitrary program and its input, to 
determine whether the program will eventually stop running) is not solvable. 
Alan Turing further defined a system to be ​Turing complete​ if it can be used to simulate 
any Turing Machine. Such a system is called a ​Universal Turing Machine (UTM)​. 
Ethereum’s ability to execute a stored program, in a state machine called the Ethereum 
Virtual Machine, while reading and writing data to memory makes it a Turing-complete 
system and therefore a Universal Turing Machine. Ethereum can compute any 
algorithm that can be computed by any Turing Machine, given the limitations of finite 
memory. 
Ethereum’s groundbreaking innovation is to combine the general-purpose computing 
architecture of a stored-program computer with a decentralized blockchain, thereby 
creating a distributed single-state (singleton) world computer. Ethereum programs run 
"everywhere", yet produce a common state that is secured by the rules of consensus. 
Turing completeness as a "feature" 
Hearing that Ethereum is Turing complete, you might arrive at the conclusion that this is 
a ​feature ​ that is somehow lacking in a system that is Turing Incomplete. Rather, it is the 
opposite. Turing completeness is very easy to achieve; in fact, the simplest Turing 
complete state machine known (Rogozhin, 1996) has 4 states and uses 6 symbols, with 
a state definition that is only 22 instructions long. Indeed, sometimes systems are found 
to be "Accidentally Turing complete". A fun reference of such systems can be found 
here: ​http://beza1e1.tuxen.de/articles/accidentally_turing_complete.html 
However, Turing completeness is very dangerous, particularly in open access systems, 
like public blockchains, because of the Halting Problem we touched on earlier. For 
example, modern printers are Turing complete and can be given files to print that send 
them into a frozen state. The fact that Ethereum is Turing complete means that any 
program of any complexity can be computed in Ethereum. But that flexibility brings 
some thorny security and resource management problems. An unresponsive printer can 
be turned off and turned back on again. That is not possible with a public blockchain. 
Implications of Turing completeness 
Turing proved that you cannot predict whether a program will terminate by simulating it 
on a computer. In simple terms, we cannot predict the path of a program without 
running it. Turing complete systems can run in "infinite loops", a term used (in 
oversimplification) to describe a program that does not terminate. It is trivial to create a 
program that runs a loop that never ends. But unintended never-ending loops can arise 
without warning, due to complex interactions between the starting conditions and the 
code. In Ethereum, this poses a challenge: every participating node (client), must 
validate every transaction, running any smart contracts it calls. But as Turing proved, 
Ethereum can’t predict if a smart contract will terminate, or how long it will run, without 
actually running it (possibly running forever). Whether by accident, or on purpose, a 
smart contract can be created such that it runs forever when a node attempts to validate 
it. This is effectively a denial of service attack. Of course, between a program that takes 
a millisecond to validate and one that runs forever there is an infinite range of nasty, 
resource hogging, memory-bloating, CPU-overheating programs that simply waste 
resources. In a world computer, a program that abuses resources gets to abuse the 
world’s resources. How does Ethereum constrain the resources used by a smart 
contract if it cannot predict resource use in advance? 
To answer this challenge, Ethereum introduces a metering mechanism called ​gas​. As 
the EVM executes a smart contract, it carefully accounts for every instruction 
(computation, data access, etc.). Each instruction has a pre-determined cost in units of 
gas. When a transaction triggers the execution of a smart contract, it must include an 
amount of gas that sets the upper limit of computation that can be consumed running 
the smart contract. The EVM will terminate execution if the amount of gas consumed by 
computation exceeds the gas available in the transaction. Gas is the mechanism 
Ethereum uses to allow Turing-complete computation while limiting the resources that 
any program can consume. 
The next question is, 'how does one get gas to pay for computation on the Ethereum 
world computer?' You won’t find gas on any exchanges. It can only be purchased as 
part of a transaction, and can only be bought with Ether. Ether needs to be sent along 
with a transaction and it needs to be explicitly earmarked for the purchase of gas, along 
with an acceptable gas price. Just like at the pump, the price of gas is not fixed. Gas is 
purchased for the transaction, the computation is executed, and any unused gas is 
refunded back to the sender of transaction. 
From general-purpose blockchains to Decentralized 
Applications (DApps) 
Ethereum started as a way to make a general-purpose blockchain that could be 
programmed for a variety of uses. But very quickly, Ethereum’s vision expanded to 
become a platform for programming ​Decentralized Applications (DApps)​. DApps 
represent a broader perspective than "smart contracts". A DApp is, at the very least, a 
smart contract and a web user-interface. More broadly, a DApp is a web application that 
is built on top of open, decentralized, peer-to-peer infrastructure services. 
A DApp is composed of at least: 
● Smart contracts on a blockchain. 
● A web front-end user-interface. 
In addition, many DApps include other decentralized components, such as: 
● A decentralized (P2P) storage protocol and platform. 
● A decentralized (P2P) messaging protocol and platform. 
Tip You may see DApps spelled as ÐApps. The Ð character is the Latin 
character called "ETH", alluding to Ethereum. To display this character, use 
the Unicode codepoint 0xD0, or if necessary the HTML character entity eth 
(or decimal entity #208). 
The Third Age of the Internet 
In 2004, the term "Web 2.0" came to prominence, describing an evolution of the web 
towards user-generated content, responsive interfaces and interactivity. Web 2.0 is not 
a technical specification, but rather a term describing the new focus of web applications. 
The concept of DApps is meant to take the World Wide Web to its next natural 
evolutionary stage, introducing decentralization with peer-to-peer protocols into every 
aspect of a web application. The term used to describe this evolution is ​Web3​, meaning 
the third "version" of the web. First proposed by Gavin Wood, ​web3​ represents a new 
vision and focus for web applications: from centrally owned and managed applications, 
to applications built on decentralized protocols. 
In later chapters we’ll explore the Ethereum web3.js JavaScript library, which bridges 
JavaScript applications that run in your browser with the Ethereum blockchain. The 
web3.js library also includes an interface to a P2P storagenetwork called ​Swarm​and a 
P2P messaging service called ​Whisper​. We can see how these services might work 
together in ​Web3: A suite of decentralized application components for the next evolution 
of the web ​. With these three components included in a JavaScript library running in your 
web browser, developers have a full application development suite that allows them to 
build web3 DApps: 
 
Figure 1. Web3: A suite of decentralized application components for the next evolution 
of the web 
Ethereum’s development culture 
So far we’ve talked about how Ethereum’s goals and technology differ from other 
blockchains that preceded it, like Bitcoin. Ethereum also has a very different 
development culture. 
In Bitcoin, development is guided by very conservative principles: all changes are 
carefully studied to ensure that none of the existing systems are disrupted. For the most 
part, changes are only implemented if they are backwards compatible. Existing clients 
are allowed to "opt-in", but will continue to operate if they decide not to upgrade. 
In Ethereum, by comparison, the community’s development culture is focused on the 
future rather than the past. The (not entirely serious) mantra is "move fast and break 
things". If a change is needed, it is implemented, even if that means invalidating prior 
assumptions, breaking compatibility, or forcing clients to update. Ethereum’s 
development culture is characterized by rapid innovation, rapid evolution and a 
willingness to deploy forward-looking improvements, even if this is at the expense of 
some backwards compatibility. 
What this means to you as a developer, is that you must remain flexible and be 
prepared to rebuild your infrastructure as some of the underlying assumptions change. 
One of the big challenges facing developers in Ethereum is the inherent contradiction 
between deploying code to an immutable system and a development platform that is still 
evolving. You can’t simply "upgrade" your smart contracts. You must be prepared to 
deploy new ones, migrate users, apps and funds, and start over. 
Ironically, this also means that the goal of building systems with more autonomy and 
less centralized control is still not fully realized. Autonomy and decentralization requires 
a bit more stability in the platform than you’re likely to get in Ethereum in the next few 
years. In order to "evolve" the platform, you have to be ready to scrap and restart your 
smart contracts, which means you have to retain a certain degree of control over them. 
But, on the positive side, Ethereum is moving forward very fast. There’s very little 
opportunity for "bike-shedding", an expression that means holding up development by 
arguing over minor details such as how to build the bicycle shed at the back of a nuclear 
power station. If you start bike-shedding, you might suddenly discover the rest of the 
development team changed the plan, and ditched bicycles in favor of autonomous 
hovercraft. 
Eventually, the development of the Ethereum platform will slow down and its interfaces 
will become fixed. But in the meantime, innovation is the driving principle. You’d better 
keep up, because no one will slow down for you. 
Why learn Ethereum? 
Blockchains have a very steep learning curve, as they combine multiple disciplines into 
one domain: programming, information security, cryptography, economics, distributed 
systems, peer-to-peer networks etc. Ethereum makes this learning curve a lot less 
steep, so you can get started very quickly. But just below the surface of a deceptively 
simple environment lies a lot more. As you learn and start looking deeper, there’s 
always another layer of complexity and wonder. 
Ethereum is a great platform for learning about blockchains and it’s building a massive 
community of developers, faster than any other blockchain platform. More than any 
other blockchain, Ethereum is a ​developer’s blockchain​, built by developers for 
developers. A developer familiar with JavaScript applications can drop into Ethereum 
and start producing working code very quickly. For the first few years of Ethereum, it 
was common to see T-shirts announcing that you can create a token in just five lines of 
code. Of course, this is a double-edged sword. It’s easy to write code, but it’s very hard 
to write ​good​ and ​secure​code. 
What this book will teach you? 
This book dives into Ethereum and examines every component. You will start with a 
simple transaction, dissect how it works, build a simple contract, make it better and 
follow its journey through the Ethereum system. 
You will learn how to use Ethereum, how it works, but also why it is designed the way it 
is. You will be able to understand how each of the pieces works, and how they fit 
together and why. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Ethereum Basics 
Ether currency units 
Ethereum’s currency unit is called ​ether​, identified also as "ETH" or with the symbols Ξ 
(from the Greek letter "Xi" that looks like a stylized capital E) or, less often, ♦, for 
example, 1 ether, or 1 ETH, or Ξ1, or ♦1. 
Tip Use Unicode character U+039E for Ξ and U+2666 for ♦. 
Ether is subdivided into smaller units, down to the smallest unit possible, which is 
named ​wei​. One ​ether​ is 1 quintillion ​wei​ (1 x 10​18​ or 1,000,000,000,000,000,000). You 
may hear people refer to the currency "Ethereum" too, but this is a common beginner’s 
mistake. Ethereum is the system, ether is the currency. 
The value of ether is always represented internally in Ethereum as an unsigned integer 
value denominated in ​wei​. When you transact 1 ether, the transaction encodes 
10000000000000000000 wei as the value. 
Ether’s various denominations have both a ​scientific name​ using the International 
System of units (​SI​), and a colloquial name that pays homage to many of the great 
minds of computing and cryptography. 
Ether Denominations and Unit Names ​ shows the various units, their colloquial 
(common) name, and their SI name. In keeping with the internal representation of value, 
the table shows all denominations in wei (first row), with ether shown as 10 ​18​ wei in the 
7th row: 
Table 1. Ether Denominations and Unit Names 
Value (in wei) Expone
nt 
Common 
Name 
SI Name 
1 1 wei wei 
1,000 10​3 babbage kilowei or 
femtoether 
1,000,000 10​6 lovelace megawei or 
picoether 
1,000,000,000 10​9 shannon gigawei or 
nanoether 
1,000,000,000,000 10​12 szabo microether or 
micro 
1,000,000,000,000,000 10​15 finney milliether or milli 
1,000,000,000,000,000,000 10​18 ether ether 
1,000,000,000,000,000,000,00
0 
10​21 grand kiloether 
1,000,000,000,000,000,000,00
0,000 
10​24 megaether 
Choosing an Ethereum wallet 
The term "wallet" has come to mean many things, although they are all related and on a 
day-to-day basis they are pretty much the same thing. We will use the term "wallet" to 
mean a software application that helps you manage your Ethereum account. In short, 
an Ethereum wallet is your gateway to the Ethereum system. It holds your keys and can 
create and broadcast transactions on your behalf. Choosing an Ethereum wallet can be 
difficult because there are many different options with different features and designs. 
Some are more suitable for beginners and some are more suitable for experts. Even if 
you choose one that you like now, you might decide to switch to a different wallet later 
on. The Ethereum platform itself is still being improved and the "best" wallets are often 
the ones that adapt to the changes that come with the platform upgrades. 
But don’t worry! If you choose a wallet and don’t like how it works, you can change 
wallets quite easily. All you have to do is make a transaction that sendsyour funds from 
the old wallet to the new wallet, or move the keys by exporting and importing your 
private keys. 
To get started, we will choose three different types of wallets to use as examples 
throughout the book: a mobile wallet, a desktop wallet, and a web-based wallet. We’ve 
chosen these three wallets because they represent a broad range of complexity and 
features. However, the selection of these wallets is not an endorsement of their quality 
or security. They are simply a good starting place for demonstrations and testing. 
Remember that for a wallet application to work, it must have access to your private 
keys, so it is vital that you only download and use wallet applications from sources you 
trust. Fortunately, in general, the more popular a wallet application is, the more 
trustworthy it is likely to be. Nevertheless, it is good practice to avoid "putting all your 
eggs in one basket" and have your Ethereum accounts spread across a couple of 
wallets. 
Starter wallets: 
MetaMask 
MetaMask is a browser extension wallet that runs in your browser (Chrome, Firefox, 
Opera or Brave Browser). It is easy to use and convenient for testing, as it is able to 
connect to a variety of Ethereum nodes and test blockchains. MetaMask is a web-based 
wallet. 
Jaxx 
Jaxx is a multi-platform and multi-currency wallet that runs on a variety of operating 
systems including Android, iOS, Windows, Mac, and Linux. It is often a good choice for 
new users as it is designed for simplicity and ease of use. Jaxx is either a mobile or 
desktop wallet, depending on where you install it. 
MyEtherWallet (MEW) 
MyEtherWallet is a web-based wallet that runs in any browser. It has multiple 
sophisticated features we will explore in many of our examples. 
Emerald Wallet 
Emerald Wallet is designed to work with Ethereum Classic blockchain, but compatible 
with other Ethereum-based blockchains. It’s an open source desktop application, and 
works under Windows, Mac and Linux. Emerald wallet can run a full node or connect to 
a public remote node, working in a "light" mode. It also has a companion tool to do all 
operations from command line. 
We’ll start by installing MetaMask on our desktop but first, we’ll briefly discuss 
controlling and managing keys. 
Control and responsibility 
Open blockchains like Ethereum are important because they operate as a ​decentralized 
system. That means lots of things, but one crucial aspect is that each user of Ethereum 
can—and should—control their own private keys, which are the things that control 
access to funds and smart contracts. We sometimes call the combination of access to 
funds and smart contracts an "account" or "wallet". These terms can get quite complex 
in their functionality, so we will go into this in more detail later. As a fundamental 
principle, however, it is as easy as one private key equals one "account". Some users 
choose to give up control over their private keys by using a third party custodian, such 
as an online exchange. In this book, we will teach you how to take control and manage 
your own private keys. 
With control comes a big responsibility. If you lose your private keys, you lose access to 
funds and contracts. No one can help you regain access—your funds will be locked 
forever. Here are a few tips to help you manage this responsibility: 
● Do not improvise security. Use tried-and-tested standard approaches. 
● The more important the account (e.g. the higher the value of the funds controlled, 
or the more significant the smart contracts accessible), the higher security 
measures should be taken. 
● The highest security is gained from an air-gapped device, but this level is not 
required for every account. 
● Never store your private key in plain form, especially digitally. Fortunately, most 
user interfaces today won’t even let you see the raw private key. 
● Private keys can be stored in an encrypted form, as a digital "keystore" file. Being 
encrypted, they need a password to unlock. When you are prompted to choose a 
password, make it strong (i.e. long and random), back it up and don’t share it. If 
you don’t have a password manager, write it down and store it in a safe and 
secret place. To access your account, you need both the "keystore" file and the 
password. 
● Do not store any passwords in digital documents, digital photos, screenshots, 
online drives, encrypted PDFs, etc. Again, do not improvise security. Use a 
password manager or pen and paper. 
● When you are prompted to back up a key as a mnemonic word sequence, use 
pen and paper to make a physical backup. Do not leave that task for "later"; you 
will forget. These can be used to rebuild your private key in case you lose all data 
saved on your system, or if you forget or lose your password. However, they can 
also be used by attackers to get your private keys, so never store them digitally, 
and keep the physical copy stored securely in a locked drawer or safe. 
● Before transferring any large amounts (especially to new addresses), first do a 
small test transaction (e.g. less than $1 value) and wait for confirmation of 
receipt. 
● When you create a new account, start by sending only a small test transaction to 
the new address. Once you receive the test transaction, try sending back again 
from that account. There are lots of reasons account creation can go wrong, and 
if it has gone wrong, it is better to find out with a small loss. If the tests work, all is 
well. 
● Public block explorers are an easy way to independently see whether a 
transaction has been accepted by the network. However, this convenience has a 
negative impact on your privacy, because you reveal your addresses to block 
explorers, which can track you. 
● Do not send money to any of the addresses shown in this book. The private keys 
are listed in the book and someone will immediately take that money. 
Now that we’ve covered some basic best practices for key management and security, 
let’s get to work using MetaMask! 
Installing MetaMask 
Open the Google Chrome browser and navigate to: 
https://chrome.google.com/webstore/category/extensions 
Search for "MetaMask" and click on the logo of a fox. ​The detail page of the MetaMask 
Chrome Extension ​ should look like this: 
 
Figure 1. The detail page of the MetaMask Chrome Extension 
It’s important to verify that you are downloading the real MetaMask extension, as 
sometimes people are able to sneak malicious extensions past Google’s filters. The real 
one: 
● Shows the ID nkbihfbeogaeaoehlefnkodbefgpgknn in the address bar 
● Is offered by ​https://metamask.io 
● Has more than 800 reviews 
● Has more than 1,000,000 users 
Once you confirm you are looking at the correct extension, click "Add to Chrome" to 
install it. 
Using MetaMask for the first time 
Once MetaMask is installed you should see a new icon (head of a fox) in your browser’s 
toolbar. Click on it to get started. You will be asked to accept the terms and conditions 
and then to create your new Ethereum wallet by entering a password, see ​The 
password page of the MetaMask Chrome Extension​: 
 
Figure 2. The password page of the MetaMask Chrome Extension 
Tip The password controls access to MetaMask, so that it can’t be used by 
anyone with access to your browser. 
Once you’ve set a password, MetaMask will generate a wallet for you and show you a 
mnemonic backup ​ consisting of 12 English words. These words can be used in any 
compatible wallet to recover access to your funds should something happen to 
MetaMask or your computer. You do not need the password for this recovery. The 12 
words are sufficient. See ​The mnemonic backup of your wallet, created by MetaMask​: 
 
Figure 3. The mnemonic backup of your wallet, created by MetaMask 
Tip Backup your mnemonic