Homework answers / question archive / In chapter 4, the author discusses different options for testing blockchain applications

In chapter 4, the author discusses different options for testing blockchain applications

Computer Science

Share With

In chapter 4, the author discusses different options for testing blockchain applications. For our course, we have chosen to use Ganache, a local blockchain. Explore some of the advantages and disadvantages of using local and public blockchains to test apps and contrast the two options.

1)Contract the advantages and disadvantages of using local and public blockchains to test applications.

2)Explain how each advantage and disadvantage impacts blockchain application development, and why each is important to a successful blockchain implementation.

Ethereum ™ by Michael G. Solomon Ethereum™ For Dummies® Published by: John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030-5774, www.wiley.com Copyright © 2019 by John Wiley & Sons, Inc., Hoboken, New Jersey Published simultaneously in Canada No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without the prior written permission of the Publisher. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions. Trademarks: Wiley, For Dummies, the Dummies Man logo, Dummies.com, Making Everything Easier, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and may not be used without written permission. Ethereum is a trademark of Ethereum Foundation. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book. LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS. THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLE FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION OR WEBSITE IS REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE INFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT INTERNET WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN THIS WORK WAS WRITTEN AND WHEN IT IS READ. For general information on our other products and services, please contact our Customer Care Department within the U.S. at 877-762-2974, outside the U.S. at 317-572-3993, or fax 317-572-4002. For technical support, please visit https://hub.wiley.com/community/support/dummies. Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com. Library of Congress Control Number: 2019936125 ISBN 978-1-119-47412-8 (pbk); ISBN 978-1-119-47411-1 (ebk); ISBN 978-1-119-47406-7 (ebk) Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 Contents at a Glance Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Part 1: Getting to Know Blockchain and Ethereum. . . . . . . . . . . 5 CHAPTER 1: CHAPTER 2: CHAPTER 3: Introducing Ethereum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Learning about Blockchain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Exploring Use Cases for Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Part 2: Setting Up Your Ethereum Development Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 CHAPTER 4: CHAPTER 5: CHAPTER 6: Examining the Ethereum Ecosystem and Development Lifecycle. . . . . . 59 Getting and Configuring Ethereum Development Tools. . . . . . . . . . . . . . 77 Establishing an Ethereum Wallet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Part 3: Building Ethereum Distributed Blockchain Apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPTER 7: CHAPTER 8: CHAPTER 9: 107 Building Your First Ethereum Apps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Learning about Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Writing Your Own Smart Contracts with Solidity. . . . . . . . . . . . . . . . . . . 147 Part 4: Testing and Deploying Ethereum Apps . . . . . . . . . . . . . 173 Testing Ethereum Apps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Deploying and Maintaining Ethereum Apps . . . . . . . . . . . . . . . . . . . . . . 191 CHAPTER 12: Integrating Non-Blockchain Apps with Ethereum. . . . . . . . . . . . . . . . . . 205 CHAPTER 10: CHAPTER 11: Part 5: The Part of Tens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Ten Free Ethereum Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Ten Design Principles for Distributed Blockchain Apps. . . . . . . . . . . . . 229 CHAPTER 15: Top Ten Ethereum Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 CHAPTER 13: CHAPTER 14: Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Table of Contents INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 About This Book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Foolish Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Icons Used in This Book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beyond the Book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Where to Go from Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 2 2 3 PART 1: GETTING TO KNOW BLOCKCHAIN AND ETHEREUM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 CHAPTER 1: Introducing Ethereum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Describing Blockchain Technology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Introducing Ethereum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Exploring Ethereum’s Consensus, Mining, and Smart Contracts. . . . . 11 Buying, Spending, and Trading Ether. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Getting Started with DAO and ICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Exploring the Ethereum Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Delving into Development Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Building Blockchain Apps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 CHAPTER 2: Learning about Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Exploring Distributed Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Digging into distributed processing . . . . . . . . . . . . . . . . . . . . . . . . . . Exploring problems with distributed processing . . . . . . . . . . . . . . . Presenting some solutions to distributed processing problems. . . Examining the Bitcoin Solution to the Distributed Dilemma . . . . . . . . Describing Blockchains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examining blockchain details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protecting blockchain visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Building Blockchains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agreeing to add blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Making blocks immutable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reviewing the building process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Keeping all blockchains consistent. . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding How Blockchains and Databases Store Data Differently. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Storing data in a traditional database . . . . . . . . . . . . . . . . . . . . . . . . Storing data in a blockchain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Effectively Using Blockchains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transferring value without trust. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reducing transaction costs by eliminating middlemen. . . . . . . . . . Table of Contents 22 22 24 27 28 30 30 31 33 33 34 35 35 36 36 38 39 39 39 v Increasing efficiency through direct interaction. . . . . . . . . . . . . . . . Maintaining complete transaction history. . . . . . . . . . . . . . . . . . . . . Increasing resilience through replication. . . . . . . . . . . . . . . . . . . . . . Providing transparency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPTER 3: 40 40 41 41 Exploring Use Cases for Ethereum. . . . . . . . . . . . . . . . . . . . . 43 Diving Into Ethereum Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exploring Financial Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Banking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Ethereum escrow applications . . . . . . . . . . . . . . . . . . . . . . Examining ICOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Establishing Digital Identity Management. . . . . . . . . . . . . . . . . . . . . . . . Managing individual and device identities. . . . . . . . . . . . . . . . . . . . . Reducing fraud and identity theft. . . . . . . . . . . . . . . . . . . . . . . . . . . . Examining the ERC-725 standard and beyond . . . . . . . . . . . . . . . . . Examining Industry Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Healthcare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Energy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Supply chain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling Effective Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tax payment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Government spending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Voting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Policy development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 45 46 48 48 49 50 50 51 51 52 52 53 54 54 55 55 55 56 PART 2: SETTING UP YOUR ETHEREUM DEVELOPMENT ENVIRONMENT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 CHAPTER 4: Examining the Ethereum Ecosystem and Development Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Exploring the Ethereum Blockchain Block Structure. . . . . . . . . . . . . . . Describing Smart Contracts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introducing Solidity, the Language of Smart Contracts. . . . . . . . . . . . . Working with the Ethereum Virtual Machine . . . . . . . . . . . . . . . . . . . . . Fueling Your Code with Gas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Surveying Tools for Developing, Testing, and Deploying Ethereum Apps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ethereum blockchain client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Development and testing blockchain. . . . . . . . . . . . . . . . . . . . . . . . . Compiler and testing framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . Source code editor/IDE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Describing the Ethereum Development Lifecycle. . . . . . . . . . . . . . . . . . Introducing Smart Contract Development Tools . . . . . . . . . . . . . . . . . . vi Ethereum For Dummies 60 64 66 67 68 69 70 71 72 72 73 74 CHAPTER 5: Getting and Configuring Ethereum Development Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Examining Why Multiple Ethereum Development Tools Are Available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Downloading, Installing, and Configuring All the Pieces. . . . . . . . . . . . Installing the blockchain client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing the test blockchain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing the testing environment . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing the IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHAPTER 6: 78 79 79 83 86 91 Establishing an Ethereum Wallet. . . . . . . . . . . . . . . . . . . . . . 95 Unlocking the Secrets of an Ethereum Wallet. . . . . . . . . . . . . . . . . . . . . 96 Examining the Types of Ethereum Wallets . . . . . . . . . . . . . . . . . . . . . . . 96 Sorting out software wallets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Handling hardware wallets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Perusing paper wallets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Choosing an Ethereum Wallet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Software wallets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Hardware wallets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Paper wallets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Installing MetaMask, an Ethereum Wallet. . . . . . . . . . . . . . . . . . . . . . . 104 PART 3: BUILDING ETHEREUM DISTRIBUTED BLOCKCHAIN APPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Building Your First Ethereum Apps. . . . . . . . . . . . . . . . . . 109 Validating Your Ethereum Development Environment. . . . . . . . . . . . Creating a Truffle project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Editing the Truffle config file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exploring the Ganache Test Environment. . . . . . . . . . . . . . . . . . . . . . . Designing Simple Smart Contracts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Coding Your First Smart Contract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running Your First Smart Contract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Writing your code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compiling your code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploying your code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Invoking your code’s functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Paying as You Go. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 110 111 113 115 116 118 118 119 120 122 124 Learning about Smart Contracts . . . . . . . . . . . . . . . . . . . . 125 CHAPTER 7: CHAPTER 8: Introducing Supply Chain and Common Challenges. . . . . . . . . . . . . . 126 Describing supply chain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Explaining difficulties when implementing a supply chain. . . . . . 127 Table of Contents vii Examining How Blockchain Can Help Resolve Supply Chain Problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128 Describing a Blockchain Supply Chain Solution . . . . . . . . . . . . . . . . . . 129 Paying for supply chain services. . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Managing assets on the supply chain . . . . . . . . . . . . . . . . . . . . . . . 130 Digging into Solidity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Describing Basic Smart Contract Syntax . . . . . . . . . . . . . . . . . . . . . . . . 133 Declaring valid compiler version. . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Commenting your code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Importing external code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Defining your smart contracts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Handling Data in Solidity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Learning about Computation and Gas. . . . . . . . . . . . . . . . . . . . . . . . . . 140 Exploring Access Modes and Visibility of Smart Contract Functions and Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Controlling Execution Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144 Handling Errors and Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Writing Your Own Smart Contracts with Solidity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Reviewing Supply Chain Design Specification. . . . . . . . . . . . . . . . . . . . Payment token smart contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Supply chain smart contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating New Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ERC-20 token interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ERC-20 token smart contract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Supply chain smart contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Coding Primary Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ERC-20 token functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Supply chain functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Triggering events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introducing Ownership. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Designing for Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementing Minimal Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 149 150 151 153 154 155 157 157 160 163 165 166 168 170 171 PART 4: TESTING AND DEPLOYING ETHEREUM APPS . . . . 173 Testing Ethereum Apps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Understanding Ethereum dApp Testing . . . . . . . . . . . . . . . . . . . . . . . . Writing tests from the beginning . . . . . . . . . . . . . . . . . . . . . . . . . . . Choosing the right test blockchain. . . . . . . . . . . . . . . . . . . . . . . . . . Learning the steps in the testing lifecycle . . . . . . . . . . . . . . . . . . . . Testing for software quality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 176 176 177 177 CHAPTER 9: CHAPTER 10: viii Ethereum For Dummies CHAPTER 11: Deploying a dApp to a Test Ethereum Blockchain. . . . . . . . . . . . . . . . Telling Truffle to use the Ganache blockchain . . . . . . . . . . . . . . . . Deploying your code to the Ganache blockchain. . . . . . . . . . . . . . Writing Tests for Ethereum dApps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing using the command line. . . . . . . . . . . . . . . . . . . . . . . . . . . . Writing test cases in JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logging and Handling Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handling errors in Solidity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logging activity in smart contracts. . . . . . . . . . . . . . . . . . . . . . . . . . Fixing Bugs in a dApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 178 180 181 181 185 187 188 189 190 Deploying and Maintaining Ethereum Apps. . . . . . . 191 Test Blockchain Options versus Live Blockchains. . . . . . . . . . . . . . . . . 192 Testing with the Ganache blockchain. . . . . . . . . . . . . . . . . . . . . . . . 192 Deploying your code to other test blockchains. . . . . . . . . . . . . . . .193 Anticipating Differences in Live Environments. . . . . . . . . . . . . . . . . . . 195 Preparing Your Configuration for Deploying to Different Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Deploying a dApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Getting enough ether . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Compiling your code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Deploying your code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 CHAPTER 12: Integrating Non-Blockchain Apps with Ethereum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comparing Blockchain and Database Storage . . . . . . . . . . . . . . . . . . . Locating control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Imposing data format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Updating data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Optimizing performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protecting confidentiality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Paying for storage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Providing integrity and transparency. . . . . . . . . . . . . . . . . . . . . . . . Protecting resilience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contrasting Execution and Flow in Blockchain dApps and Traditional Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Designing Goals for Incorporating Blockchain into an Existing Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using existing smart contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Developing your own smart contracts. . . . . . . . . . . . . . . . . . . . . . . Identifying Interface Data and Transaction Requirements. . . . . . . . . Creating or Modifying Contracts to Provide Data Interface . . . . . . . . Testing Integrated dApps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploying Integrated dApps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table of Contents 205 206 207 207 207 208 208 208 209 209 210 211 213 213 214 215 215 216 ix PART 5: THE PART OF TENS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Ten Free Ethereum Resources . . . . . . . . . . . . . . . . . . . . . . . 221 CHAPTER 13: Exploring Alternative Ethereum Development Frameworks . . . . . . . 222 Managing you development with Populus . . . . . . . . . . . . . . . . . . . 222 Exploring Ethereum blockchain containers with Cliquebait. . . . . 222 Selecting a Free Integrated Development Environment . . . . . . . . . . . 223 Developing Solidity code with Atom. . . . . . . . . . . . . . . . . . . . . . . . . 223 Going online with Remix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Keeping it simple with EthFiddle. . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Exploring Ethereum Clients and APIs. . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Swapping your Ethereum client to Parity. . . . . . . . . . . . . . . . . . . . .226 Interacting with Ethereum by using Web3.js. . . . . . . . . . . . . . . . . . 226 Focusing on Wallets and Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Protecting your crypto-assets in Mist. . . . . . . . . . . . . . . . . . . . . . . . 227 Securing your dApps with OpenZeppelin . . . . . . . . . . . . . . . . . . . . 228 Learning More About Developing Ethereum dApps . . . . . . . . . . . . . . 228 Ten Design Principles for Distributed Blockchain Apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Designing for Trust. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enforcing Consistency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Removing Doubt through Transparency. . . . . . . . . . . . . . . . . . . . . . . . Providing Feedback, Guidance, and Setting Expectations. . . . . . . . . . Handling Mistakes with Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Designing Functions that Focus on User Actions, Not Data . . . . . . . . Storing Data Based on User Actions, Not Data Structures . . . . . . . . . Keeping It Simple. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Expecting Blockchain Access to Be Expensive. . . . . . . . . . . . . . . . . . . . Staying Out of the User’s Way. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 230 232 233 233 234 235 236 236 237 Top Ten Ethereum Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Predicting Future Events with Gnosis. . . . . . . . . . . . . . . . . . . . . . . . . . . Crowdsourcing Event Predictions in Augur. . . . . . . . . . . . . . . . . . . . . . Managing Decentralized Organizations with Aragon. . . . . . . . . . . . . . Breeding and Collecting Cryptokitties . . . . . . . . . . . . . . . . . . . . . . . . . . Exchanging Tokens with IDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Your Digital Identity with uPort. . . . . . . . . . . . . . . . . . . . . . . . Sharing Your Thoughts on the Blockchain with EtherTweet. . . . . . . . Searching for Jobs with EthLance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using TenX to Pay with Cryptocurrency. . . . . . . . . . . . . . . . . . . . . . . . . Buying and Selling Computing Power with Golem. . . . . . . . . . . . . . . . 240 240 241 241 242 243 243 244 245 246 INDEX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 CHAPTER 14: CHAPTER 15: x Ethereum For Dummies Introduction B lockchain technology is one of the most talked about disruptive technologies of the decade, and Ethereum is the most popular blockchain implementation. Blockchain technology holds the promise of making business interactions faster, cheaper, and more trustworthy. Ethereum For Dummies introduces blockchain and Ethereum, covers their effect on today’s ways of doing business, and teaches you how to design and develop your own Ethereum decentralized applications. You learn how to set up a development environment and write smart contracts that create and control transactions on the Ethereum blockchain. About This Book Blockchain technology has the potential to change how business operates. The unprecedented opportunities blockchain promises to provide include easy data sharing among large groups, transparency, trusted transactions, and complete historical audit trails. Today, most organizations protect transaction data as a valued asset, but sharable data could change everything. Sharing trusted data with many participants in a business process has the potential of revolutionizing how organizations interact with one another, reducing the need and cost of middlemen and providing unprecedented transparency to business processes. Staying current and pertinent means becoming part of this emerging blockchain business model. Ethereum For Dummies gives you the foundation of blockchain and Ethereum, and teaches you, in clear language, how to design and write your own software for the Ethereum blockchain environment. Introduction 1 Foolish Assumptions I don’t make many assumptions about your experience with blockchain technology, application programming, or cryptography, but I do assume the following: »» You have a computer and access to the Internet. »» You know the basics of using your computer and the Internet, and how to download and install programs. »» You know how to find files on your computer’s disk and how to create folders. »» You’re new to blockchain and you aren’t an experienced software developer. If you already know how to write software applications, you can skip the sections on programming basics. Icons Used in This Book The Tip icon marks tips (duh!) and shortcuts that you can use to make learning and using Ethereum and Solidity easier. Remember icons mark the information that’s especially important to know. To siphon off the most important information in each chapter, just skim through these icons. The Technical Stuff icon marks information of a highly technical nature that you can normally skip over. The Warning icon tells you to watch out! It marks important information that may save you headaches when writing your own blockchain applications. Beyond the Book In addition to the material in the print or e-book you’re reading right now, this product also comes with some access-anywhere goodies on the web. Check out the free cheat sheet for more on Ethereum and Solidity at www.dummies.com/ ­cheatsheet/ethereumfd. 2 Ethereum For Dummies You’ll find summary information on Ethereum and Solidity tools as well as tips on how to use them effectively. The cheat sheet is a reference to use over and over as you gain experience in developing Ethereum decentralize applications. In addition, if you’d rather download the code you see in this book instead of typing it, go to www.dummies.com/go/ethereumfd. You can download zip files for each of the projects you’ll create to develop and test smart contracts. Where to Go from Here The Dummies series tells you what you need to know and how to do the things you need to do to get the results you want. Readers don’t have to read the entire book to just learn about some topics. For example, if you just want to learn about smart contracts, you can jump right to Chapters 8 and 9. On the other hand, if you need to set up your own development environment, read Part 2, which tells you how to do that with clear, step-by-step instructions. Introduction 3 1 Getting to Know Blockchain and Ethereum IN THIS PART . . . Get a big-picture overview of the Ethereum blockchain and how it works. Discover how blockchain technology addresses distributed application problems. Explore use cases that are good fits for blockchain technology. IN THIS CHAPTER »» Getting to know Ethereum »» Understanding ether and trading »» Exploring DAOs and ICOs »» Setting up an Ethereum development environment »» Developing blockchain applications Chapter 1 Introducing Ethereum B lockchain technology is the most disruptive technology introduced in our generation, and Ethereum is by far the most popular blockchain implementation in use today. You can’t read many technology articles or blogs without seeing something about how blockchain changes everything. Although some claims seem to be a little far-fetched, blockchain technology really is a game-changer. Blockchain, which first burst on the scene in 2008, has gained global notoriety for what it has already changed and what is coming. At first, blockchain was all about a new type of electronic currency. But now, partially thanks to Ethereum, blockchain is so much more than a new way to pay for things. It’s a new way to think about things. It enables people and businesses to conduct business without many of the obstacles that have existed in trade relations for centuries. In this book you learn about what blockchain is and why it is viewed as so radical. You discover how powerful Ethereum is in diverse domains and how you can ­harness its promise and power in your own organizations. If you want to learn what Ethereum is and how it can work for you without having to trudge through hundreds of pages of theory and background, this is the book for you. CHAPTER 1 Introducing Ethereum 7 Describing Blockchain Technology You learn a lot more about blockchain technology in Chapter 2, but before you meet Ethereum, you need to know a little of Ethereum’s backstory. If you already know what blockchain is, this section will be like watching yet another depiction of why Bruce Wayne became Batman. Feel free to skim it and move on to the next section. There are only so many ways you can kill Thomas and Martha Wayne. Blockchain technology was introduced to support a new type of digital currency that you can trade in a trustless environment. Traditional currency exchanges require a trusted third party between the parties. Even if a buyer provides coins or bills to a seller at the point of transaction, some government provides the guarantee of the currency’s value. There is always a middleman. If the exchange involves a payment card or check, other financial institutions participate to handle the transfer of funds between parties. In 2008, Satoshi Nakamoto published a paper that changed everything. ­Nakamoto’s paper described a new way to store and distribute data with verifiable integrity among a group of nodes that don’t trust one another. You learn more about how Nakamoto’s proposal works, and about bitcoin, the cryptocurrency proposed in the paper, in Chapter 2. At this point, the most important takeaway is that this paper showed how to take the requirement for a trusted (and omnipotent) central authority out of the mix. Using this new technology, called blockchain, application developers can create environments in which nodes that do not trust one another can share data that they can trust. The idea is based on several concepts that are simple to consider but difficult to put into practice. First, data is logically presented as a ledger. The data isn’t really stored that way; you can just think of it as a ledger. A ledger is a way of recording data as transactions occur. One interesting feature of this ledger is that you can only add data to it. You can’t change anything after you’ve added it. So, the only two operations you can perform on this ledger are add and read. We refer to the “add only” property as the immutability property. In short, blockchains are immutable. As you’ll see, immutability is crucial for the technique to work. Another feature is that data is added to this ledger in blocks. Blocks are collections of transactions, each with an owner’s address. Addresses are the unique IDs of accounts in our ledger system. When there are enough transactions to make a new block, some of the blockchain participants begin a process of adding a new block to the ledger. Each new block is linked to the previous block, making a chain. That’s where the term blockchain comes from. A blockchain is basically a bunch of blocks where each block is connected to its predecessor. 8 PART 1 Getting to Know Blockchain and Ethereum Then, the entire set of blocks, or the entire blockchain, is shared with other ­participants. These participants are called nodes. These nodes communicate with one another and each stores an exact copy of the blockchain. Many blockchain networks are made up of thousands of nodes, and keeping all of the copies of the blockchain in sync (that is, ensuring that every copy is the same) is another ­revolutionary feature of blockchain technology. Blockchain technology is built on a democracy governance mode. Before any new block is added to the blockchain, a majority of nodes must agree that the new block is valid. All nodes agree to accept the majority decision. That’s how the blockchain stays in sync. Nodes essentially vote on all new blocks. Different blockchains use different voting methods, but one of the more common ones requires nodes to solve very hard mathematical puzzles to earn the right to add a new block to the blockchain. As an incentive for doing the hard work, the node that solves the puzzle first gets a reward. The reward encourages nodes to pitch in and help do the hard work of solving verification puzzles. Part of the puzzle solution involves creating a mathematical hash of the previous block. By storing the previous block’s hash in the current block, every node can quickly determine if any block has changed. Each node periodically scans the blockchain to ensure that nothing has changed. This is how nodes can be sure that the blockchain is the same across the entire network. And, because no block can change after it is added to the blockchain, you never have to worry about ­overwriting data. Putting it all together, a blockchain makes it possible to share a set of data with many nodes that you don’t trust. You can trust the democracy of the network, though. As long as you can trust that more than half of the nodes on the b ­ lockchain network are going to be honest, you can trust the blockchain. The last big advantage to blockchain technology is that you can put rules of operation in blocks on the blockchain as well. These rules are called smart contracts. A smart contract is just a program that lives in a blockchain block and governs how data is added to the blockchain. Because all blockchain data is immutable, even the smart contract code is immune from changes. That’s how you can exchange currency without a bank. As long as there are rules that dictate how a currency exchange is carried out, transaction data can be recorded on the blockchain and be part of the permanent ledger. For example, suppose you want to buy a car. You have enough digital currency in your blockchain account to buy the car, and the car owner has the car’s title stored in the blockchain. You can offer to buy the car and if the seller accepts your offer, a smart contract handles the transaction. The smart contract would verify that the title is owned by the seller and that you have enough money in your account to CHAPTER 1 Introducing Ethereum 9 make the purchase. If those two requirements are met, the smart contract would transfer the sales amount into the seller’s account and transfer the title to your account. Without any middleman, you have purchased a car and paid for it without carrying a wad of cash around. Of course, you really purchased a title to a car. Blockchain handles digital assets. You still have to physically get the keys and the car from the seller. Introducing Ethereum Bitcoin was the first blockchain technology application. It was revolutionary and defined the first widely used digital currency, called cryptocurrency. The crypto part of the name refers to the use of cryptographic hashes to ensure the integrity of the blockchain. The shared ledger literally keeps a copy of every cryptocurrency ­transaction that gets verified by all nodes. Using this approach, bitcoin created a permanent record of every exchange of their cryptocurrency. And, because account owners are identified only by an address, bitcoin has always enjoyed a measure of anonymity. Although bitcoin addresses aren’t linked directly to people, many exchanges have records of identities that are related to addresses. At some point, you have to exchange your cryptocurrency for real currency. That switchover point is where many law enforcement officials focus when they’re trying to track down criminals using cryptocurrency. As bitcoin became more and more popular, researchers began to see more ­applications for blockchain technology beyond cryptocurrency. In 2013, Vitalik Buterin, the cofounder of Bitcoin Magazine, published a whitepaper that proposed a new, more functional blockchain implementation. This new proposal was for the Ethereum blockchain. After gaining interest and attracting technical and financial support, the Ethereum Foundation, a Swiss non-profit organization, was founded and became the developer of Ethereum. Ethereum wasn’t created just to exchange cryptocurrency. In fact, it was designed from the beginning to be different. The core features of Ethereum are the smart contract and ether. Ether is the native cryptocurrency that Ethereum supports, although you can create your own tokens to exchange value in many other forms. Smart contracts provide an execution environment that ensures integrity across all nodes. Any code that executes on one node executes the same way on all nodes. This guarantee makes it possible to deploy a wide range of applications across untrusted environments. 10 PART 1 Getting to Know Blockchain and Ethereum The foundational guarantees Ethereum provides support many types of value exchanges without the concern about fraud, censorship, or any involvement by a third party. When you interact with an Ethereum application, you don’t have to rely on any intermediary to broker your transactions. You don’t need a bank, wholesaler, or transaction broker to provide trust. As a result of Ethereum’s ­disintermediation, you can often complete transactions faster, with far lower ­service fees and without requiring approval from external authorities. Ethereum is a comprehensive, decentralized application platform that expands the range of capabilities beyond what was possible before blockchain technology. Whereas legacy solutions to data and process sharing required third-party authorities to enforce integrity, Ethereum provides process and data integrity, along with disintermediation. The possibilities are just beginning to be explored. Exploring Ethereum’s Consensus, Mining, and Smart Contracts Ethereum provides integrity in the way it implements immutability and smart contracts. Immutability isn’t actually a blockchain guarantee. You can change data in any block — even after other blocks are added to the blockchain. However, as soon as you change a block, that block and all subsequent blocks fail integrity checks and your node is out of sync. Instead of saying that the blockchain is immutable, it is more accurate to say that any changes (mutations) to the blockchain are easily and immediately detected. Ethereum is based on democracy. Each node gets an equal vote. Every time nodes get a new block to add to the blockchain, they validate the block and its transactions, and then vote whether to accept or reject the block. If several different blocks are submitted by different nodes, only one of the blocks can receive votes from a majority. The block that gets more than half of the network node’s votes gets to join the blockchain as its newest block. One of the first problems is to determine when a new block is ready for the blockchain. When too many conflicting blocks are submitted, the voting process slows down. Ethereum makes it hard to add new blocks to keep the number of new block collisions low and to make voting faster. Ethereum uses a consensus protocol called Proof of Work (PoW), which sets the rules for validating and adding new blocks. PoW makes add blocks to the blockchain difficult but profitable. CHAPTER 1 Introducing Ethereum 11 Ethereum defines ether as its cryptocurrency. You can transfer ether between accounts or earn it by doing the hard work of adding blocks to the Ethereum blockchain. The Ethereum PoW mechanism requires that nodes find a number that, when combined with the block’s header data, produces a cryptographic hash value that matches the current target, which is a value that is adjusted to keep new block production at a steady rate. Finding a hash value that matches the current target is hard. You have to try on average more than a quadrillion values to find the right one. That’s the point. Using a PoW mechanism makes it so hard to ­submit a block that fewer blocks are submitted, which reduces the number of collisions. The node that finds the right value gets a small ether payment for the effort. This process is called mining, and the node that wins the prize is that block’s miner. Mining regulates the speed at which new blocks get submitted as candidate blocks, and results in a number that is easy to validate. Finding the right number to solve the puzzle is difficult, but verifying the number is fast and easy. Another interesting aspect of mining is that each block’s header contains a hash from the previous block. Ethereum nodes use the hash to easily detect unauthorized block changes. If a block changes, the hash result doesn’t match and the block becomes invalid. Mining is also a way to make money using blockchain technology. Mining has become competitive, and most of today’s miners invest in high-performance hardware with multiple GPUs to carry out the complex operations. To keep the mining process fair, Ethereum uses a complexity value that makes the mining process even harder as miners get faster. Adjusting the complexity allows ­Ethereum to regulate the new block frequency to an average of one new block every 14 seconds. The glue that holds the Ethereum environment together is the smart contract. Ethereum is much more than just a financial ledger, and smart contracts provide much of its rich functionality. Each Ethereum node runs a copy of the Ethereum virtual machine (EVM). The EVM runs smart contract code in a way that guarantees that smart contracts execute the same way on all nodes and produce the same output. Running smart contract code is not optional. Smart contracts execute based on specific rules and cannot be subverted or halted. The EVM smart contract guarantees provide a stable platform for automated transaction processing that you can trust. Smart contracts provide the primary power of the Ethereum environment. One of the known weaknesses with software is that attackers can sometimes bypass its controls and carry out unintended actions. That type of attack is more difficult in Ethereum, primarily due to its smart contract implementation. Attackers can’t directly attack the blockchain and make unauthorized changes because any such changes will be immediately detected. The next most likely attack vector is the smart contract interface to the blockchain data. Ethereum guarantees that 12 PART 1 Getting to Know Blockchain and Ethereum smart contract code, which is translated into bytecode before it is written to the blockchain, executes on every EVM instance the same way. Also, the EVM determines when code executes and what code executes. Attackers have few opportunities to leverage smart contract code, which makes Ethereum an even more secure environment. Buying, Spending, and Trading Ether Ethereum runs on ether (ETH), its main cryptocurrency. The majority of all ­existing ether was pre-mined when Ethereum first went live on July 30, 2015. Miners continually create ether, but the amount of mined ether is less than 30 percent of all ether in existence. The lifecycle of Ethereum transactions requires that you first acquire ether to participate in Ethereum. Many exchanges support exchanging legal tender, also called fiat currency, for cryptocurrency, including ether. You can navigate to https://99bitcoins.com/best-ethereum-exchangereview-comparison for an independent comparison of several popular exchanges. Before you can interact with the Ethereum blockchain, you need to create at least one account. Creating an Ethereum account is essentially just creating a cryptographic private and public key pair, and generating the associated address, which is based on your public key. The software that handles this process is called an Ethereum wallet. You learn about different options for Ethereum wallets in ­Chapter 6. You can use a wallet provided by an exchange or a standalone wallet. After you create your Ethereum account, you’ll need to select an exchange to ­purchase ether. After you select an exchange, you set up an exchange account and provide a funding source. Your main funding source is generally a bank account. The most common way to buy ether is to withdraw funds from your bank account and use that money to exchange for ether. Figure 1-1 shows the purchase ether web page for the coinbase.com exchange. Note that the funding source for this account is a Bank of America account. You can also purchase ether using cash. A growing number of cryptocurrency ATMs allow you to exchange cash for different types of cryptocurrency. All you need is the private key you generated using your Ethereum wallet and cash. However, you will pay for this convenience. Cryptocurrency ATMs often use exchange rates that are less favorable than more traditional exchanges. One current service, localcoin ATM, works just like a regular ATM. Navigate to https:// localcoinatm.com to see where you can find ATMs and how to use them. Figure 1-2 shows several steps in the process of purchasing ether with cash from an ATM. CHAPTER 1 Introducing Ethereum 13 FIGURE 1-1: Purchase ether using coinbase.com. FIGURE 1-2: Purchasing ether with cash. After you own ether, you can interact with other Ethereum accounts and send them some of your ether in exchange for good or services. Or you can simply hold on to your ether in hopes that is goes up in price. Ether, along with other cryptocurrencies, fluctuates in price continuously. Many investors buy and sell 14 PART 1 Getting to Know Blockchain and Ethereum cryptocurrencies as investments, just like trading fiat currencies or commodities. Figure 1-3 shows the main coinbase.com dashboard with popular cryptocurrency prices. FIGURE 1-3: Current ­cryptocurrency prices. At its highest price, ether sold for around $1,400. At the time of this writing, it was down near $100. Whether cryptocurrency is a good investment depends on your appetite for risk and belief in its long-term value. In addition to buying and trading ether, you can spend it just like any other ­currency. Of course, you generally have to buy from a vendor that accepts ether. Several service providers make it easy to accept payments with ether, such as Pay with Ether. This company provides the software and the services to make it easy for vendors of any size to accept ether as payment. Visit www.paywithether.com/ to find out more about this payment option. There are ways to spend cryptocurrency at vendors that don’t directly accept it. Several companies are planning to offer Visa cards that you fund with ­cryptocurrency. One company, Wirex, allows users to convert their cryptocurrency to USD, GPB, or EUR and use their card at any vendor that accepts Visa. Cryptocurrency is growing rapidly, but only a small number of vendors accept it. If you really want to pay with ether or other cryptocurrencies, take a look at TenX. This company offers a popular Visa card funded by cryptocurrency. The card isn’t available everywhere, but the company expects to increase its availability over time. Navigate to https://tenx.tech/en for more information on TenX and their cryptocurrency payment card. CHAPTER 1 Introducing Ethereum 15 Getting Started with DAO and ICO Blockchain technology has given rise to new classes of organizations and ­opportunities. You’ll often hear about decentralized autonomous organization (DAO) and initial coin offering (ICO). These terms simply describe endeavors that Ethereum makes possible. You’ll read a lot about these terms as you learn more about Ethereum, so it makes sense to cover them here. A DAO is an organization that operates only on the rules set forth in its smart ­contracts. In reality, most DAOs require some human interaction, but the majority of the functionality is automated. For example, assume in just a few years that autonomous vehicles (driverless cars) are more common. A DAO would be like a driverless Uber or Lyft car. The car waits for a passenger, and then drives to the pickup location when someone needs a ride. The autonomous car completes the trip and the passenger pays with cryptocurrency. The car just earned some money. However, the car’s maintenance smart contract detects that the brakes need replacing. So the car drives itself to a mechanic and pays for new brakes, using the profits of previous rides. The autonomous vehicle does not need human interaction to carry out its primary business function or to get necessary service. The autonomous vehicle is the same idea as a DAO. A DAO conducts business and engages in transactions without requiring human interaction. Today’s DAOs are relatively simple, but it is expected that they will grow in complexity and eventually replace (or at least compete with) some existing human-based businesses. Like all businesses, Ethereum-based or Ethereum-related businesses need ­funding to operate. Many traditional methods for raising funds exist, including soliciting private investors, securing loans, or selling shares in the company. In addition, Ethereum opens new options for funding businesses. Businesses that use Ethereum often create their own tokens, also called coins, that represents value associated with the business ventures. Businesses sell these tokens to raise funds to launch the business. These ICOs essentially exchange one type of currency for a digital item of value. Tokens may represent an expected future value as ownership in a new venture or current value that entitles the holder to some benefit. Either way, tokens are similar in some ways to stock shares. An ICO is a popular method to fund a new blockchain-based business. If you want to learn more about the most popular ICOs, navigate to www.coindesk. com/ico-tracker to explore coindesk’s ICO Tracker, shown in Figure 1-4. 16 PART 1 Getting to Know Blockchain and Ethereum FIGURE 1-4: coindesk ICO Tracker. Exploring the Ethereum Ecosystem The Ethereum environment, or ecosystem, is made up of several different parts. You’ve already learned about most of these pieces, but it helps to put those pieces together in one place. Starting from the lowest level of the blockchain, Ethereum is made up of the following components: »» Blockchain: The collection of data blocks that is the core of Ethereum. Each block contains data and smart contract code, and is cryptographically linked to its predecessor, creating a chain of blocks. »» EVM: The Ethereum virtual machine, which runs smart contract bytecode. Each Ethereum node runs an instance of the EVM. »» Wallet: Software, hardware, or physical paper that stores the public and private keys that correspond to an Ethereum account. The wallet stores the capability to access crypto-assets on the Ethereum blockchain. »» Exchange: A service the allows its users to exchange fiat currency for cryptocurrency. »» Development environment: The set of tools to write, compile, and perform unit tests on smart contract software. »» Testing environment: A simulated Ethereum blockchain used to perform integration testing on smart contracts and complete decentralized applications (dApps). »» Client interface: The client user interface’s software and libraries used to interact with Ethereum smart contracts. You learn much more about the details of each of these components in Chapter 4. CHAPTER 1 Introducing Ethereum 17 Delving into Development Tools Developing decentralized applications (dApps) for Ethereum requires several types of tools. Each of these tools provides support for various phases of software development and is necessary to create dApps for the Ethereum blockchain environment. In Chapter 4, you find out the different categories of development tools and learn about several alternatives for each type of tool. Tools that you’ll use when developing Ethereum dApps are in the following categories: »» Blockchain client: When developing Ethereum dApps, you’ll need to imple- ment a local EVM. A blockchain client launches a local EVM and executes your smart contract code. It also interacts with your Ethereum blockchain. »» Development and testing blockchain: Deploying to the live Ethereum blockchain, also called mainnet, is the last step in the development process. Before deployment, you want to interact with a local version of an Ethereum blockchain. Because live blockchain access costs ether, you should carry out development and testing on a local blockchain to avoid costs and errors. »» Compiler and testing framework: After you have a local EVM and local blockchain, you’ll need a way to interact with your smart contract code and place it on your test blockchain for test execution. A development and testing framework provides the tools you need to carry out development and testing tasks. »» Source code editor/IDE: Although you can use any text editor to write smart contract source code, an editor or integrated development environment (IDE) that is designed or extended to support Ethereum smart contract source code development will be very helpful. IDEs can increase developer efficiency and make it easier to create good smart contract code. As you work through the exercises in this book, you’ll learn more about each of these tools and install an example from each category. Building Blockchain Apps The process of building blockchain applications is not radically different from developing traditional applications. You have a few additional considerations and a few additional steps. As you work through the chapters in this book, you’ll learn each of the tasks required to develop effective and efficient blockchain applications for the Ethereum environment. 18 PART 1 Getting to Know Blockchain and Ethereum The main differences between traditional applications and blockchain applications is the distributed, transparent nature of the data and the fact that writing data to the blockchain costs money. Distributed and transparent data means that you can’t rely on the blockchain to provide any confidentiality. Anything you write to the blockchain is visible by users on any node. That should affect how you design your applications and data. Be careful when collecting data from users and storing it on the blockchain. Always assume that any blockchain data is available to the public. The other main difference is that writing to the blockchain costs money. The development and testing processes normally occur with simulated blockchains that use only fake cryptocurrency, but live blockchain I/O has a real cost. Most developers aren’t used to calculating computation and access costs. Because this is generally a new concept, many developers may put this consideration off until later in the development cycle. This decision is a mistake. It is always easier and cheaper to address blockchain access cost problems early in the development ­process. If you wait until the end, any changes will likely have cascading effects and costs. As with any good development practices, do everything you can to fully understand what your users want and need. Design your software with the users in mind and always cater to their needs first. Then make you software meet their needs in ways that are the most effect and economical. Stick with good software design and development principles, while incorporating blockchain-specific ­considerations, and you’ll be on your way to developing a good blockchain dApp. CHAPTER 1 Introducing Ethereum 19 IN THIS CHAPTER »» Understanding distributed applications »» Examining Bitcoin’s solution to the distributed dilemma »» Building blockchains »» Contrasting blockchains and databases »» Describing ways to use blockchain Chapter 2 Learning about Blockchain B lockchain technology is basically a distributed ledger that is shared between lots of computers and can run verifiable software to control how data is added. Blockchain technology depends on the capability to distribute data and software to many computers, using a technique called distributed processing. Distributed processing is the practice of spreading applications across multiple computers, and is a different way of looking at where data is stored and where application code is run from the more traditional centralized model. Software applications have to run somewhere. Today’s applications can run on endpoint computers and devices, or on servers you connect to through a network. Regardless of where software runs, the computer or device running it has limited capacity. Growth has always been a challenge for computing environments, and at some point, users will probably want services faster than the computer running an application can handle. That’s where distributed processing comes into play. In distributed processing, computers work together in teams to solve problems. If done well, distributed processing can help address the increasing demands that growth causes. However, it turns out that getting computers to work together in teams is hard. CHAPTER 2 Learning about Blockchain 21 Fortunately, a really smart researcher found a way to enable groups of computers that don’t trust each other to work together in a manageable way. This new approach to distributed processing and data storage is called blockchain technology, and it has revolutionized the way people think about distributed processing and trust. In this chapter you learn about how cool blockchains are, how they are built, why they are different from anything in the past, and most importantly, what you can do with them. Exploring Distributed Applications Way back in the early days of computing, it became clear that computers couldn’t do everything. They could do some things really fast, such as solving math problems, but even when doing what they do best, computers would eventually run out of processing capability. The Apollo 11 moon landing almost didn’t happen due to a computer overload. The navigation computer in the lunar module was getting radar data too fast and threw 1201 and 1202 alarms. Those alarms basically meant that the computer couldn’t keep up with the data it was receiving. NASA engineers quickly determined that the error wasn’t bad enough to abort the mission, so the landing attempt continued. But for a few seconds, a computer overload almost caused NASA to scrub the landing. Rumor has it that a deviation from the official NASA checklist ended up causing the lunar module 1201 and 1020 program alarms. According to the checklist, the docking radar should have been turned off once the lunar module undocked from the command module. The astronauts turned on the landing radar and left the docking radar on as well in case anything bad happened and they had to return to the command module. The navigation computer couldn’t handle input from two radars at once, so it triggered the program alarms. Digging into distributed processing One solution to application overload is to split up the computing load among ­multiple computers. What would have happened if the lunar module had been equipped with two computers? Maybe each one could have handled a different radar and no errors would have occurred. Of course, computers in 1969 were far larger and heavier than today’s devices. Adding a second computer at that time was just too heavy and expensive. Today things are quite different. Our smartphones are way more powerful than the computers the astronauts took with them to the moon. And they’re far smaller 22 PART 1 Getting to Know Blockchain and Ethereum and lighter too. Because computers are so small, fast, and affordable, we see distributed processing all the time in today’s applications. And networks are faster and cheaper to access. Most applications that run in a web browser or on a mobile device are distributed. That means part of the program runs in the browser or on the mobile device, and another part runs on a server. For instance, when you shop online, your web browser connects to a web server to fetch a list of products. The web server probably connects to an application server and a database server to get the data, and then returns it to your web browser. If you try to fetch more data from the same website, it is highly likely that you’d end up connecting to a different server. The entire process is transparent because it appears that you’re running software on one big computer. That’s the beauty of distributed processing. Web applications are just one example of distributed processing. Other examples include specialized servers, such as graphics processing, and parallel processing, where multiple CPUs or computers split up data and work on each part of the data at the same time. The goal in each case is the same: allow more users to run an application than is possible when using a single computer. Even though parallel processing really is a type of distributed processing, it’s ­generally considered a separate type of computing. In traditional parallel processing, all processors have access to the same area of shared memory. Traditional distributed processing, however, uses multiple computers, each with its own ­separate memory. Several popular architectures of distributed systems exist. The difference between architectures is in which components carry out different types of processing. The main distributed processing architectures follow: »» Client-server: A capable client computer does much of the work, while relying on the server only to store and manage shared data. You’ll find this architecture in small offices that run software on workstations connected to a central database server. »» Three-tier: Simple websites use this approach, in which a client connects to a server, such as a web server, to get some content. The web server often needs to get data from a database server, which might also handle some of the processing. »» n-tier: This architecture is an extension of the three-tier architecture, where jobs are clearly defined and multiple servers are used for specific tasks. Server types in an n-tier architecture can include web servers, application servers, database servers, and other servers that pervade specialized services. Most of today’s websites, such as shopping sites, are web applications running on n-tier architecture. CHAPTER 2 Learning about Blockchain 23 »» Peer-to-peer: In this architecture, all nodes, or participating computing components, are considered equal. Storage and processing is shared among nodes. Examples of peer-to-peer networks include file-sharing networks and the Linux software and updates distribution network. Figure 2-1 shows the main four distributed processing architectures. FIGURE 2-1: Distributed processing architectures. Exploring problems with distributed processing Distributed processing all sounds good, but there are problems with distributing programs and data. First, all computing nodes (computers running parts of a ­distributed application) have to trust one another. That’s not a problem if one company owns all of the computing nodes, but computers owned by competing companies simply do not trust one another. How can you trust that your competitor calculated that discount for your customer properly? Or even worse, suppose that your competitor saw a transaction for one of your customers and decided to cancel the transaction and then steal your customer? Lots of trust problems arise 24 PART 1 Getting to Know Blockchain and Ethereum when attempting to distribute processing across multiple computing nodes that are not centrally controlled. Scheduling and availability are other common problems. If you don’t own and manage all of the computing nodes, how can you make sure that they are always available when you need them? Could they be tied up running someone else’s applications? Or could one or more computing nodes be turned off or unavailable for some maintenance reason? These are just some of the problems with distributed processing. Think of it this way: what if your family grew and you couldn’t fit everyone into your car anymore? If you couldn’t afford a bigger car, you’d have to do something to get your family from point A to point B. If your neighbor has no kids and a huge SUV, that could help solve your problem! All you have to do is get your neighbor to agree to share the SUV and coordinate your trips with your neighbor. But what if your neighbor doesn’t want to go where you want to go? How do you solve that problem? And what if one of the vehicles breaks down? Or what if your neighbor wants to sleep late on Saturday but your kids have a 7 a.m. game? Coordinating computers is at least as hard as coordinating cars. When it comes to distributed processing, four main problems must be solved (and all of these problems relate directly to trust): »» Launching remote processes: How a process on one computer launches a process on another computer. »» Communicating between remote processes: How processes running on different computers communicate and coordinate activities. »» Storing one version of data in multiple locations: How to store and update data on different computers without running into confusing differences. »» Getting multiple computers to work together: How different computers handle issues such as resolving conflicts between computers and handling system load and outages. Launching remote processes Distributed processing makes it possible for one computer to spread the computing load by running part of the application on other computers. That means computer A has to launch part of the application on computer B. Security immediately becomes a problem. Traditionally, an operating system authenticates users that log in to that computer and then authorizes those users to run some programs. When a program run request comes from a different computer, figuring out how to limit who can run which programs can be difficult. CHAPTER 2 Learning about Blockchain 25 Assuming that you resolve the security issues, you have to define a protocol for how one machine requests that some process runs on another machine. You have to define what type of message should be sent and what data has to be included so that the target computer understands what it is being asked to do. Communicating between remote processes After computers can remotely launch processes on other computers, distributed systems have to communicate to work together. That means some process on machine A has to talk to another process on machine B, formally called interprocess communication (IPC), to get any work done between the two computers. The main problem with IPC is that all participating computers have to agree on the format of messages they want to exchange and the rules to communicate. Computer B may encounter problems or take longer than expected. In those cases, it has to be able to communicate back to computer A that things aren’t going well. And if things do go well, computer B needs to know how to sends its results back to computer A. Storing and synchronizing one version of data in multiple locations One of the more difficult problems with distributing applications is storing data in multiple locations and keeping all the copies of data the same. Centralized data storage is a lot easier because there is only one copy of the data. Suppose Mary’s checking account balance on computer A is decreased (she bought a large cappuccino at the local coffee shop). At the moment the data is changed, Mary’s checking account balance stored on computer B is incorrect. If Mary then uses a mobile app to transfer money into her account and that mobile app happens to be running on computer B, her balance could be all messed up. If computer B’s balance is considered to be correct, the cost of the cappuccino hasn’t been deducted from Mary’s account and she has more money in her account than she should have. If computer A’s balance is considered correct, there is no record of the deposit and Mary has less money in her account than she should have. Getting multiple computers to work together The last remaining big problem is just getting computers to work together nicely. Computers work as independently quite well, but it takes effort to get them to work together. For instance, if two computers store copies of the same data and both run the same programs, users expect that both computers will keep their data the same. But if computer A crashes and users change data on computer B while computer A is down, the data will be different. When computer A boots, its data will be old and inaccurate, and it becomes difficult to get computers A and B to coordinate to get their data back in sync. 26 PART 1 Getting to Know Blockchain and Ethereum Even if one of the computers doesn’t crash, anytime users try to change the same data but on different computers, the two computers must negotiate to see which change should be allowed. These types of problems happen frequently and make distributed processing more difficult as you add more computers and users. Presenting some solutions to distributed processing problems Computer scientists have been working on the problems with distributed processing for several decades. No one has completely solved all of the problems, but there are solutions to each problem you just learned about. Launching remote processes Remote Procedure Call (RPC) and Remote Method Invocation (RMI) are just two ways to define how computer A can launch a process on computer B. These two approaches simply set the communication rules and message formats for how two computers can run distributed processes. These aren’t the only solutions to remote process launching, but they have been around for a while and lay the foundation for process distribution. Communicating between remote processes The capability for processes running on different computer to communicate with one another is formally called inter-process communication (IPC). IPC is necessary to get any work done between the two computers. The main problem with IPC is that all participating computers have to agree on the format for exchanging ­messages and the rules for communication. Different standards, each with its pros and cons, exist. As with all distributed processing issues, all participating computing nodes must agree on how and when they communicate and what the messages look like. Storing one version of data in multiple locations Lots of approaches to synchronizing multiple copies of data exist. The biggest question is how to handle stale copies of data when one copy gets changed. One method is to mark the unchanged copies as “bad” or “stale” until the changed copy of data is written to the other copies. This approach raises all kinds of problems with timing and concurrency. Eventually, two users will update the same data on different computers at about the same time. A set of rules must be in place to govern which user wins. CHAPTER 2 Learning about Blockchain 27 Other methods for keeping data in sync are to apply locks to data before updates are allowed and to support merging multiple copies of data. Yet another approach is to place a timestamp on all data updates and resolve all conflicts by accepting the earliest change to the data. All existing approaches make developing and using distributed data applications more difficult, which is why computer scientists continue to search for a better way. Getting multiple computers to work together The last problem has perhaps the fewest standard solutions. In most cases, coordination among distributed computing nodes is based on one of two ­ approaches: temporary dominance or consensus. Temporary dominance means that one computing node becomes a node with authority and decides a course of action. Some approaches arbitrarily assign nodes to have decision authority in a round-robin approach, and others have nodes vote for a leader when they have a conflict. Either way, this approach depends on granting one computing node the authority to decide. The other main approach is to have all participating computing nodes engage in some game to come up with a decision. When a majority of nodes agree on some outcome, the group has reached consensus and accepts the majority decision. Many types of consensus “games” exist, and many are based on having computers solve puzzles. You learn more about consensus later in this chapter. Consensus is a major part of the “big solution.” Examining the Bitcoin Solution to the Distributed Dilemma In 2008, Satoshi Nakamoto published “Bitcoin: A Peer-to-Peer Electronic Cash System.” That paper contained a description of a new system of handling electronic currency. It described a data structure that consisted of a chain of special blocks, called a blockchain. This new approach makes it possible for many nodes that do not trust one another to exchange currency without a central authority. Satoshi Nakamoto is a fictional name. Even today, we still don’t know who wrote that paper. The author could be a single person or a group of people. Regardless, Nakamoto started a revolution in distributed computing. Nakamoto proposed blockchain — now known as blockchain — technology to implement the new cryptocurrency called bitcoin. In a few short years, bitcoin has 28 PART 1 Getting to Know Blockchain and Ethereum become a viable currency and blockchain has started changing the way we look at distributed processing. One common mistake when you’re new to blockchain is to confuse bitcoin and blockchain. They were proposed at the same time in the same paper, but they aren’t the same. Bitcoin is a cryptocurrency that is an implementation of blockchain technology. Blockchain can be implemented in many ways, not just to support bitcoin. The subject of this book, Ethereum, is another wildly popular implementation of blockchain. Let’s take a look at how blockchain provides a solution to each of the problems with distributed processing. »» Launching remote processes: Blockchain technology is based on a collection of computing nodes connected in a peer-to-peer network. That means no node has more authority than any other node. Each blockchain node runs as a completely independent computing device and doesn’t support launching remote processes on other nodes. »» Communicating between remote processes: This one is easy. Remote processes don’t communicate in blockchain technology because there are no remote processes. It looks like we’ve just ignored the first two problems with distributed processing. That’s because blockchain technology is out to solve only a few problems, not all of them. By ignoring remote processes, blockchain simplifies its approach to distributed processing and storage. »» Storing one version of data in multiple locations: Perhaps the greatest contribution of blockchain is how the central data structure is constructed. A blockchain is an ever-growing chain of blocks, with the blocks linked into a chain structure. New blocks can be added only if a majority of the nodes agree to each addition. After a block has been added to the blockchain, it can’t be modified. This feature solves the problem of keeping old data in sync. The only problem left to solve is coordinating how the blockchain expands. »» Getting multiple computers to work together: The other large contribution of blockchain is in defining how peers — nodes that operate at the same authority — work together. They have to agree on when to add blocks and under what rules. The blockchain definition sets up these rules in a simple and straightforward way that makes it hard to break the rules and easy for everyone else to see if any node did so. You’ll see that blockchain uses distributed processing to handle data storage and trust issues, and doesn’t focus on performance. CHAPTER 2 Learning about Blockchain 29 Describing Blockchains At its core, a blockchain is pretty simple: It is a bunch of blocks of data linked into a chain. All blockchains start with a genesis block. The only thing that makes a ­genesis block special is that it isn’t linked to a previous block. The genesis block contains header info and contents data. All other blocks also contain header and contents data, but they also contain a link to their predecessor block. Each block’s data can have different contents, in different formats. Blockchain block contents aren’t constrained in the same way as database records are. The structure of data that you store in each block can be dynamic, to fit the data you’re storing. Examining blockchain details You can think of a blockchain as being a big spreadsheet, except that each row may have different columns and a different number of columns. Instead of being identified by row number and column letter, each data value is identified by a key. That makes it easy to identify data in each block. At a higher level, a blockchain can be viewed as a big spreadsheet that is shared with every node in the blockchain network. Every copy of the blockchain is identical, and all nodes must agree before any new blocks are added to the ­ ­blockchain (think of adding new rows to the spreadsheet). That way, the b ­ lockchain always stays in sync. All blocks, except the genesis block, include a previous block link. This link is a cryptographic hash of the previous block’s header metadata. A cryptographic hash is a number that uniquely represents a block of data. It is the output of a mathematical function given the data of the block as input. Hash functions make is easy to calculate a fixed-length number that represents a large amount of input data. And even though a hash function returns a shorter number than the size of the input, the returned hash value is unique for data used as input. Different blockchains use different hash functions. For example, Ethereum uses the Keccak-256 hash function to calculate the hash value on the previous block. Ethereum uses that hash value as the link to attach a block to the previous block on the chain. The link Ethereum uses is the result of the Keccak-256 calculation of the previous block’s header information and a random number, called the nonce value. Ethereum nodes compete to be the first to find the right nonce that results in a hash value matching the current complexity target. Figure 2-2 shows the blockchain architecture. 30 PART 1 Getting to Know Blockchain and Ethereum FIGURE 2-2: Blockchain architecture. Blockchain uses data from a block, along with a nonce, to calculate a hash value that represents the block. The word nonce means “a number that is used only once.” A nonce is used to increase the uniqueness of a hash value for a block. ­Calculating a hash on a block using two different nonces will return two different hashes. Each Ethereum block contains some header information, including a timestamp, a block number, a version number, and other descriptive information, and content data. The content data can be any data that makes up the contents of the block, which can be plaintext data, encrypted data, or even executable code. A blockchain, when described only in terms of the blocks, looks like a straightforward data structure. But the real power of blockchain is how the data structure is created, extended, and used in applications. Current blockchain implementations define blockchains as immutable data structures, which means that after each block is added to the blockchain, it can never be changed. This immutability property helps to solve one of the more difficult problems of storing distributed data in multiple locations. If the blockchain cannot be changed after a block has been added to the chain, the only remaining problem with data synchronization is how to control when blocks are added to the chain. All blockchains have clear rules that control the process of adding blocks. Protecting blockchain visibility You can build two types of blockchain: public and private. Your choice depends on what you’re trying to do with your blockchain. Public blockchains are available to pretty much anyone, but private blockchains are only available to users authorized by the blockchain owner, as shown in Figure 2-3. CHAPTER 2 Learning about Blockchain 31 FIGURE 2-3: Public versus private blockchains. Public blockchain Anyone can interact with a public blockchain, also called a permissionless ­blockchain. All you need is a valid address, and you can read the blockchain and even submit transactions. This is the most popular type of blockchain, and one that most people think of when associating blockchain with cryptocurrency. Public blockchains ensure that no one organization controls the blockchain because any computer can become a node and each computer maintains a full copy of the blockchain. Not all nodes store full copies of blockchain blocks. Full nodes do maintain ­complete copies of the blockchain, but lightweight nodes store just some blocks of the blockchain. Lightweight nodes often store recent blocks and provide transaction validation services for clients. Private blockchain Prior authorization is required before you can access a private blockchain, also called a permissioned blockchain. Private blockchains are almost always owned by a single organization or a small group. The blockchain owner requires that each blockchain user request authorization to interact with the blockchain data and provide access credentials with each access request. Private blockchains provide organizations the features of blockchain applications without having to expose all of their data to the general public. 32 PART 1 Getting to Know Blockchain and Ethereum Building Blockchains You’ve already learned that blockchains are immutable and all nodes have to agree before new blocks can be added to the blockchain. Let’s look at how those two requirements are enforced. Agreeing to add blocks The first rule blockchain nodes must agree to is how to allow new blocks to be added to the blockchain. Because no node has more authority than any other node, the nodes use consensus to agree to add new blocks. Consensus in this sense simply means that when enough nodes agree to take some action, that the action is approved and agreed upon by all nodes. Most consensus strategies use simple majorities to succeed. So, as long as more than half of nodes agree to take some action, the action is approved. Several consensus approaches are in use or proposed: »» Proof of Work: Proof of Work (PoW) is the most popular consensus protocol used today, and is used by both bitcoin and Ethereum. Proof of Work means that some nodes compete to try to be the first to solve a mathematical puzzle. The puzzle is to find a random value to combine with a block’s header, such that the hash of the combined data matches a pattern. Solving the puzzle is hard, but verifying the solution to the puzzle is easy. The first node to solve the puzzle receives a reward for doing the work, and gets to add the new block to the blockchain. The block, along with the value the winning node found to solve the puzzle, is sent to all nodes. Each node quickly verifies the block and then adds it to their local blockchain. Although Proof of Work is the most popular consensus protocol and works well, it takes enormous computing power to complete. That means Proof of Work requires computers to use lots of energy, which produces a lot of heat. »» Proof of Stake: The Proof of Stake (PoS) consensus protocol will likely replace Proof of Work. The developers of Ethereum already have plans to move to this protocol. The Proof of Stake protocol provides a similar level of consistency as the current Proof of Work protocol without using so much computing power (and wasting energy). Each node that wants to compete to add a new block locks some of its cryptocurrency and submits it as a bet. The “winning” node that gets to add the new block to the blockchain is chosen based on the size of the bet and other criteria intended to randomize the selection. The random part of the selection criteria keeps the richest node from always adding new blocks. CHAPTER 2 Learning about Blockchain 33 »» Delegated Proof of Stake: Delegated Proof of Stake (DPoS) is a modified PoS protocol. Most of the pool of candidate nodes are selected as in the PoS protocol, but a small number of additional nodes are added to the pool based on votes. All nodes in the network can vote for some nodes to be included in the selection pool. The nodes receiving the highest number of votes are added to the selection pool, and the winner is randomly selected from all nodes in the pool. DPoS makes PoS fairer and less likely to favor the richest nodes. »» Delegated Byzantine Fault Tolerance (dBFT): The last consensus protocol is based on a dilemma encountered in all distributed systems: the Byzantine Generals’ Problem. This problem is a hypothetical situation that makes it easy to see how hard it is to get a consensus. Suppose nine generals and their armies from the Byzantine Empire have surrounded Rome and are waiting to attack. The generals have agreed that they must all attack or retreat in unison. If any general breaks rank and doesn’t do what the other generals do, they all will be defeated. In this case, consensus is necessary for survival. Because generals can communicate only through couriers, any courier could be bribed or even captured. Either of these actions would cause a message to be lost or changed. Any general could also be bribed to lie or just become scared and make the wrong decision. It is difficult for any general to trust that all other generals agree on any decision. The dBFT protocol ensures that all generals agree on a single course of action, even when some messages are changed or lost. The dBFT protocol is based on groups of nodes electing a delegate to represent them. Each time a new block is proposed for the blockchain, a speaker is randomly selected from the delegates. The speaker calculates the block’s hash and sends that to all other delegates. If at least two-thirds of the delegates agree with the calculated hash, the block is added to the blockchain. Otherwise, the block is discarded and the process starts over with new delegates and a new speaker being selected. Making blocks immutable The reason why so much effort is put into ensuring consensus is that after a block is added to the blockchain, it never changes. Well, that’s the goal. Technically, it is possible to change blockchain data, but it is very, very hard to do and very easy for anyone to detect the change. Using POW consensus protocol, the level of effort alone makes changing blocks pretty close to impossible. Let’s see why. Before you add a block to the blockchain, you must calculate a cryptographic hash of the previous block. That is the link to the previous block and the guarantee that it will never change. When you calculate the hash value of the previous block, that 34 PART 1 Getting to Know Blockchain and Ethereum block’s header (which is part of the data used to calculate the hash value) includes the hash of its pr...