34,79 €
Blockchain is a decentralized ledger that maintains a continuously growing list of data records that are secured from tampering and revision. Every user is allowed to connect
to the network, send new transactions to it, verify transactions, and create new blocks,
making it permission-less.
This book will teach you what blockchain is, how it maintains data integrity, and how to create real-world blockchain projects using Ethereum. With interesting real-world
projects, you will learn how to write smart contracts which run exactly as programmed
without any chance of fraud, censorship, or third-party interference, and build end-to-e
applications for blockchain.
You will learn about concepts such as cryptography in cryptocurrencies, ether security, mining, smart contracts, solidity, and more. You will also learn about web sockets, various API services for Ethereum, and much more.
The blockchain is the main technical innovation of bitcoin, where it serves as the public ledger for bitcoin transactions.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 300
Veröffentlichungsjahr: 2017
BIRMINGHAM - MUMBAI
Copyright © 2017 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: April 2017
Production reference: 1240417
ISBN 978-1-78712-214-7
www.packtpub.com
Author
Narayan Prusty
Copy Editor
Stuti Srivastava
Reviewers
Imran Bahsir Daniel Kraft Gaurang Torvekar
Project Coordinator
Nidhi Joshi
Commissioning Editor
Veena Pagare
Proofreader
Safis Editing
Acquisition Editor
Vinay Argekar
Indexer
Pratik Shirodkar
Content Development Editor
Mayur Pawanikar
Graphics
Tania Dutta
Technical Editor
Prasad Ramesh
Production Coordinator
Melwyn Dsa
Narayan Prusty is a full-stack developer, with five years of experience in the field. He specializes in Blockchain and JavaScript. His commitment has led him to build scalable products for startups, the government, and enterprises across India, Singapore, USA, and UAE.
At present, Ethereum, Bitcoin, Hyperledger, IPFS, Ripple, and so on are some of the things he uses on a regular basis to build decentralized applications. Currently, he is a full-time Blockchain SME (Subject-Matter Expert) at Emirates National Bank of Dubai.
He has already written two books on JavaScript titled Learning ECMAScript 6 and Modern JavaScript Applications. Both these books were reviewed and published by Packt.
He starts working on something immediately if he feels it’s exciting and solves real work problems. He built an MP3 search engine at the age of 18, and since then, he has built various other applications, which are used by people around the globe. His ability to to build scalable applications from top to bottom is what makes him special.
Currently, he is on a mission to make things easier, faster, and cheaper using the blockchain technology. Also, he is looking at possibilities to prevent corruptions, fraud, and to bring transparency to the world using blockchain technology. You can learn more from him from his blog http://qnimate.com and you can reach him out at LinkedIn https://www.linkedin.com/in/narayanprusty/.
Imran Bashir has an M.Sc. degree in Information Security from Royal Holloway, University of London, and has a background in software development, solution architecture, infrastructure management, and IT service management. He is also a member of the Institute of Electrical and Electronics Engineers (IEEE) and the British Computer Society (BCS). Imran has sixteen years of experience in public and financial sector. He had worked on large-scale IT projects for the public sector before moving to the financial services industry. Since then, he worked in various technical roles for different financial companies in Europe’s financial capital, London. He is currently working for an investment bank in London as Vice President in the technology department.
Daniel Kraft has studied mathematics and physics and holds a PhD degree in applied mathematics from the University of Graz in Austria. He has been involved in development with cryptocurrencies since 2013, has been the lead developer and chief scientist for both Namecoin and Huntercoin since 2014, and has published two research papers about cryptocurrency in peer-reviewed journals. He works as a software engineer and is a cofounder of Crypto Realities Ltd, a start-up that works on building decentralized multiplayer game worlds with blockchain technology.
Gaurang Torvekar has a master's degree in Information Systems from Singapore Management University. He is the cofounder and CTO of Attores, a Smart Contracts as a Service company, based in Singapore. He has extensive experience in Ethereum and Hyperledger application development. He has been a speaker at several blockchain conferences, conducted many hands on blockchain courses in Polytechnics in Singapore, and is also a Blockchain mentor at Angelhack.
For support files and downloads related to your book, please visit www.PacktPub.com.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www.packtpub.com/mapt
Get the most in-demand software skills with Mapt. Mapt gives you full access to all Packt books and video courses, as well as industry-leading tools to help you plan your personal development and advance your career.
Fully searchable across every book published by Packt
Copy and paste, print, and bookmark content
On demand and accessible via a web browser
Thanks for purchasing this Packt book. At Packt, quality is at the heart of our editorial process. To help us improve, please leave us an honest review on this book's Amazon page at https://www.amazon.com/dp/178712214X.
If you'd like to join our team of regular reviewers, you can e-mail us at [email protected]. We award our regular reviewers with free eBooks and videos in exchange for their valuable feedback. Help us be relentless in improving our products!
Preface
What this book covers
What you need for this book
Who this book is for
Conventions
Reader feedback
Customer support
Downloading the example code
Downloading the color images of this book
Errata
Piracy
Questions
Understanding Decentralized Applications
What is a DApp?
Advantages of decentralized applications
Disadvantages of decentralized applications
Decentralized autonomous organization
User identity in DApps
User accounts in DApps
Accessing the centralized apps
Internal currency in DApps
Disadvantages of internal currency in DApps
What are permissioned DApps?
Popular DApps
Bitcoin
What is a ledger?
What is blockchain?
Is Bitcoin legal?
Why would someone use Bitcoin?
Ethereum
The Hyperledger project
IPFS
How does it work?
Filecoin
Namecoin
.bit domains
Dash
Decentralized governance and budgeting
Decentralized service
BigChainDB
OpenBazaar
Ripple
Summary
Understanding How Ethereum Works
Overview of Ethereum
Ethereum accounts
Transactions
Consensus
Timestamp
Nonce
Block time
Forking
Genesis block
Ether denominations
Ethereum virtual machine
Gas
Peer discovery
Whisper and Swarm
Geth
Installing geth
OS X
Ubuntu
Windows
JSON-RPC and JavaScript console
Sub-commands and options
Connecting to the mainnet network
Creating a private network
Creating accounts
Mining
Fast synchronization
Ethereum Wallet
Mist
Weaknesses
Sybil attack
51% attack
Serenity
Payment and state channels
Proof-of-stake and casper
Sharding
Summary
Writing Smart Contracts
Solidity source files
The structure of a smart contract
Data location
What are the different data types?
Arrays
Strings
Structs
Enums
Mappings
The delete operator
Conversion between elementary types
Using var
Control structures
Creating contracts using the new operator
Exceptions
External function calls
Features of contracts
Visibility
Function modifiers
The fallback function
Inheritance
The super keyword
Abstract contracts
Libraries
Using for
Returning multiple values
Importing other Solidity source files
Globally available variables
Block and transaction properties
Address type related
Contract related
Ether units
Proof of existence, integrity, and ownership contract
Compiling and deploying contracts
Summary
Getting Started with web3.js
Introduction to web3.js
Importing web3.js
Connecting to nodes
The API structure
BigNumber.js
Unit conversion
Retrieving gas price, balance, and transaction details
Sending ether
Working with contracts
Retrieving and listening to contract events
Building a client for an ownership contract
The project structure
Building the backend
Building the frontend
Testing the client
Summary
Building a Wallet Service
Difference between online and offline wallets
hooked-web3-provider and ethereumjs-tx libraries
What is a hierarchical deterministic wallet?
Introduction to key derivation functions
Introduction to LightWallet
HD derivation path
Building a wallet service
Prerequisites
Project structure
Building the backend
Building the frontend
Testing
Summary
Building a Smart Contract Deployment Platform
Calculating a transaction's nonce
Introducing solcjs
Installing solcjs
solcjs APIs
Using a different compiler version
Linking libraries
Updating the ABI
Building a contract deployment platform
The project structure
Building the backend
Building the frontend
Testing
Summary
Building a Betting App
Introduction to Oraclize
How does it work?
Data sources
Proof of authenticity
Pricing
Getting started with the Oraclize API
Setting the proof type and storage location
Sending queries
Scheduling queries
Custom gas
Callback functions
Parsing helpers
Getting the query price
Encrypting queries
Decrypting the data source
Oraclize web IDE
Working with strings
Building the betting contract
Building a client for the betting contract
Projecting the structure
Building the backend
Building the frontend
Testing the client
Summary
Building Enterprise Level Smart Contracts
Exploring ethereumjs-testrpc
Installation and usage
The testrpc command-line application
Using ethereumjs-testrpc as a web3 provider or as an HTTP server
Available RPC methods
What are event topics?
Getting started with truffle-contract
Installing and importing truffle-contract
Setting up a testing environment
The truffle-contract API
The contract abstraction API
Creating contract instances
The contract instance API
Introduction to truffle
Installing truffle
Initializing truffle
Compiling contracts
Configuration files
Deploying contracts
Migration files
Writing migrations
Unit testing contracts
Writing tests in JavaScript
Writing tests in Solidity
How to send ether to a test contract
Running tests
Package management
Package management via NPM
Package management via EthPM
Using contracts of packages within your contracts
Using artifacts of packages within your JavaScript code
Accessing a package's contracts deployed addresses in Solidity
Using truffle's console
Running external scripts in truffle's context
Truffle's build pipeline
Running an external command
Running a custom function
Truffle's default builder
Building a client
Truffle's server
Summary
Building a Consortium Blockchain
What is a consortium blockchain?
What is Proof-of-Authority consensus?
Introduction to parity
Understanding how Aura works
Getting parity running
Installing rust
Linux
OS X
Windows
Downloading, installing and running parity
Creating a private network
Creating accounts
Creating a specification file
Launching nodes
Connecting nodes
Permissioning and privacy
Summary
Blockchain is a decentralized ledger that maintains a continuously growing list of data records secured from tampering and revision. Every user is allowed to connect to the network, send new transactions to it, verify transactions, and create new blocks.
This book will teach you what Blockchain is, how it maintains data integrity, and how to create real-world Blockchain projects using Ethereum. With interesting real-world projects, you will know learn how to write smart contracts which run exactly as programmed without any chance of fraud, censorship or third-party interference, and build end-to-end applications for Blockchain. You will learn concepts such as cryptography in cryptocurrencies, ether security, mining, smart contracts, and solidity.
The blockchain is the main technical innovation of bitcoin, where it serves as the public ledger for bitcoin transactions.
Chapter 1, Understanding Decentralized Applications, will explain what DApps are and provide an an overview of how they work.
Chapter 2, Understanding How Ethereum Works, explains how Ethereum works.
Chapter 3, Writing Smart Contracts, shows how to write smart contracts and use geth's interactive console to deploy and broadcast transactions using web3.js.
Chapter 4, Getting Started with web3.js, introduces web3js and how to import, connect to geth, and explains use it in Node.js or client-side JavaScript.
Chapter 5, Building a Wallet Service, explains how to build a wallet service that users can create and manage Ethereum Wallets easily, even offline. We will specifically use the LightWallet library to achieve this.
Chapter 6, Building a Smart Contract Deployment Platform, shows how to compile smart contracts using web3.js and deploy it using web3.js and EthereumJS.
Chapter 7, Building a Betting App, explains how to use Oraclize to make HTTP requests from Ethereum smart contracts to access data from World Wide Web. We will also learn how to access files stored in IPFS, use the strings library to work with strings, and more.
Chapter 8, Building Enterprise Level Smart Contracts, explains how to use Truffle, which makes it easy to build enterprise-level DApps. We will learn about Truffle by building an alt-coin.
Chapter 9, Building a Consortium Blockchain, we will discuss consortium blockchain.
You require Windows 7 SP1+, 8, 10 or Mac OS X 10.8+.
This book is for JavaScript developers who now want to create tamper-proof data (and transaction) applications using Blockchain and Ethereum. Those who are interested in cryptocurrencies and the logic and database empowering it will find this book extremely useful.
Feedback from our readers is always welcome. Let us know what you think about this book-what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of. To send us general feedback, simply e-mail [email protected], and mention the book's title in the subject of your message. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
You can download the code files by following these steps:
Log in or register to our website using your e-mail address and password.
Hover the mouse pointer on the
SUPPORT
tab at the top.
Click on
Code Downloads & Errata
.
Enter the name of the book in the
Search
box.
Select the book for which you're looking to download the code files.
Choose from the drop-down menu where you purchased this book from.
Click on
Code Download
.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
WinRAR / 7-Zip for Windows
Zipeg / iZip / UnRarX for Mac
7-Zip / PeaZip for Linux
The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Building-Blockchain-Projects. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from https://www.packtpub.com/sites/default/files/downloads/BuildingBlockchainProjects_ColorImages.pdf.
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books-maybe a mistake in the text or the code-we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at [email protected] with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
If you have a problem with any aspect of this book, you can contact us at [email protected], and we will do our best to address the problem.
Almost all of the Internet-based applications we have been using are centralized, that is, the servers of each application are owned by a particular company or person. Developers have been building centralized applications and users have been using them for a pretty long time. But there are a few concerns with centralized applications that make it next to impossible to build certain types of apps and every app ends up having some common issues. Some issues with centralized apps are that they are less transparent, they have a single point of failure, they fail to prevent net censorship, and so on. Due to these concerns, a new technology emerged for the building of Internet-based apps called decentralized applications (DApps). In this chapter, we will learn about decentralized apps.
In this chapter, we'll cover the following topics:
What are DApps?
What is the difference between decentralized, centralized, and distributed applications?
Advantages and disadvantages of centralized and decentralized applications.
An overview of the data structures, algorithms, and protocols used by some of the most popular DApps
Learning about some popular DApps that are built on top of other DApps.
A DApp is a kind of Internet application whose backend runs on a decentralized peer-to-peer network and its source code is open source. No single node in the network has complete control over the DApp.
Depending on the functionality of the DApp, different data structures are used to store application data. For example, the Bitcoin DApp uses the blockchain data structure.
These peers can be any computer connected to the Internet; therefore, it becomes a big challenge to detect and prevent peers from making invalid changes to the application data and sharing wrong information with others. So we need some sort of consensus between the peers regarding whether the data published by a peer is right or wrong. There is no central server in a DApp to coordinate the peers and decide what is right and wrong; therefore, it becomes really difficult to solve this challenge. There are certain protocols (specifically called consensus protocols) to tackle this challenge. Consensus protocols are designed specifically for the type of data structure the DApp uses. For example, Bitcoin uses the proof-of-work protocol to achieve consensus.
Every DApp needs a client for the user to use the DApp. To use a DApp, we first need a node in the network by running our own node server of the DApp and then connecting the client to the node server. Nodes of a DApp provide an API only and let the developer community develop various clients using the API. Some DApp developers officially provide a client. Clients of DApps should be open source and should be downloaded for use; otherwise, the whole idea of decentralization will fail.
But this architecture of a client is cumbersome to set up, especially if the user is a non-developer; therefore, clients are usually hosted and/or nodes are hosted as a service to make the process of using a DApp easier.
Here are some of the advantages of decentralized applications:
DApps are fault-tolerant as there is no single point of failure because they are distributed by default.
They prevent violation of net censorship as there is no central authority to whom the government can pressurize to remove some content. Governments cannot even block the app's domain or IP address as DApps are not accessed via a particular IP address or domain. Obviously the government can track individual nodes in the network by their IP address and shut them down, but if the network is huge, then it becomes next to impossible to shut down the app, especially if the nodes are distributed among various different countries.
It is easy for users to trust the application as it's not controlled by a single authority that could possibly cheat the users for profit.
Obviously, every system has some advantages and disadvantages. Here are some of the disadvantages of decentralized applications:
Fixing bugs or updating DApps is difficult, as every peer in the network has to update their node software.
Some applications require verification of user identity (that is, KYC), and as there is no central authority to verify the user identity, it becomes an issue while developing such applications.
They are difficult to build because they use very complex protocols to achieve consensus and they have to be built to scale from the start itself. So we cannot just implement an idea and then later on add more features and scale it.
Applications are usually independent of third-party APIs to get or store something. DApps shouldn't depend on centralized application APIs, but DApps can be dependent on other DApps. As there isn't a large ecosystem of DApps yet, it is difficult to build a DApp. Although DApps can be dependent on other DApps theoretically, it is very difficult to tightly couple DApps practically.
Typically, signed papers represent organizations, and the government has influence over them. Depending on the type of organization, the organization may or may not have shareholders.
Decentralized autonomous organization (DAO) is an organization that is represented by a computer program (that is, the organization runs according to the rules written in the program), is completely transparent, and has total shareholder control and no influence of the government.
To achieve these goals, we need to develop a DAO as a DApp. Therefore, we can say that DAO is a subclass of DApp.
Dash, and the DAC are a few example of DAOs.
One of the major advantages of DApps is that it generally guarantees user anonymity. But many applications require the process of verifying user identity to use the app. As there is no central authority in a DApp, it become a challenge to verify the user identity.
In centralized applications, humans verify user identity by requesting the user to submit certain scanned documents, OTP verification, and so on. This process is called know your customer (KYC). But as there is no human to verify user identity in DApps, the DApp has to verify the user identity itself. Obviously DApps cannot understand and verify scanned documents, nor can they send SMSes; therefore, we need to feed them with digital identities that they can understand and verify. The major problem is that hardly any DApps have digital identities and only a few people know how to get a digital identity.
There are various forms of digital identities. Currently, the most recommended and popular form is a digital certificate. A digital certificate (also called a public key certificate or identity certificate) is an electronic document used to prove ownership of a public key. Basically, a user owns a private key, public key, and digital certificate. The private key is secret and the user shouldn't share it with anyone. The public key can be shared with anyone. The digital certificate holds the public key and information about who owns the public key. Obviously, it's not difficult to produce this kind of certificate; therefore, a digital certificate is always issued by an authorized entity that you can trust. The digital certificate has an encrypted field that's encrypted by the private key of the certificate authority. To verify the authenticity of the certificate, we just need to decrypt the field using the public key of the certificate authority, and if it decrypts successfully, then we know that the certificate is valid.
Even if users successfully get digital identities and they are verified by the DApp, there is a still a major issue; that is, there are various digital certificate issuing authorities, and to verify a digital certificate, we need the public key of the issuing authority. It is really difficult to include the public keys of all the authorities and update/add new ones. Due to this issue, the procedure of digital identity verification is usually included on the client side so that it can be easily updated. Just moving this verification procedure to the client side doesn't completely solve this issue because there are lots of authorities issuing digital certificates and keeping track of all of them, and adding them to the client side, is cumbersome.
Due to these issues, the only option we are currently left with is verifying user identity manually by an authorized person of the company that provides the client. For example, to create a Bitcoin account, we don't need an identification, but while withdrawing Bitcoin to flat currency, the exchanges ask for proof of identification. Clients can omit the unverified users and not let them use the client. And they can keep the client open for users whose identity has been verified by them. This solution also ends up with minor issues; that is, if you switch the client, you will not find the same set of users to interact with because different clients have different sets of verified users. Due to this, all users may decide to use a particular client only, thus creating a monopoly among clients. But this isn't a major issue because if the client fails to properly verify users, then users can easily move to another client without losing their critical data, as they are stored as decentralized.
Many applications need user accounts' functionality. Data associated with an account should be modifiable by the account owner only. DApps simply cannot have the same username- and password-based account functionality as do centralized applications because passwords cannot prove that the data change for an account has been requested by the owner.
There are quite a few ways to implement user accounts in DApps. But the most popular way is using a public-private key pair to represent an account. The hash of the public key is the unique identifier of the account. To make a change to the account's data, the user needs to sign the change using his/her private key. We need to assume that users will store their private keys safely. If users lose their private keys, then they lose access to their account forever.
A DApp shouldn't depend on centralized apps because of a single point of failure. But in some cases, there is no other option. For example, if a DApp wants to read a football score, then where will it get the data from? Although a DApp can depend on another DApp, why will FIFA create a DApp? FIFA will not create a DApp just because other DApps want the data. This is because a DApp to provide scores is of no benefit as it will ultimately be controlled by FIFA completely.
So in some cases, a DApp needs to fetch data from a centralized application. But the major problem is how the DApp knows that the data fetched from a domain is not tampered by a middle service/man and is the actual response. Well, there are various ways to resolve this depending on the DApp architecture. For example, in Ethereum, for the smart contracts to access centralized APIs, they can use the Oraclize service as a middleman as smart contracts cannot make direct HTTP requests. Oraclize provides a TLSNotary proof for the data it fetches for the smart contract from centralized services.
For a centralized application to sustain for a long time, the owner of the app needs to make a profit in order to keep it running. DApps don't have an owner, but still, like any other centralized app, the nodes of a DApp need hardware and network resources to keep it running. So the nodes of a DApp need something useful in return to keep the DApp running. That's where internal currency comes into play. Most DApps have a built-in internal currency, or we can say that most successful DApps have a built-in internal currency.
The consensus protocol is what decides how much currency a node receives. Depending on the consensus protocol, only certain kinds of nodes earn currency. We can also say that the nodes that contribute to keeping the DApp secure and running are the ones that earn currency. Nodes that only read data are not rewarded with anything. For example, in Bitcoin, only miners earn Bitcoins for successfully mining blocks.
The biggest question is since this is a digital currency, why would someone value it? Well, according to economics, anything that has demand and whose supply is insufficient will have value.
Making users pay to use the DApp using the internal currency solves the demand problem. As more and more users use the DApp, the demand also increases and, therefore, the value of the internal currency increases as well.
Setting a fixed amount of currency that can be produced makes the currency scarce, giving it a higher value.
The currency is supplied over time instead of supplying all the currency at a go. This is done so that new nodes that enter the network to keep it secure and running also earn the currency.
The only demerit of having internal currency in DApps is that the DApps are not free for use anymore. This is one of the places where centralized applications get the upper hand as centralized applications can be monetized using ads, providing premium APIs for third-party apps, and so and can be made free for users.
