This chapter covers

• Exploring decentralized identity management

• Understanding consensus among decentralized participants

• Reviewing scalability, privacy, security, and confidentiality

• Analyzing public, private and permissioned blockchain networks

• Capturing the scientific research behind blockchain concepts

Any emerging technology will experience challenges as it is maturing. Blockchain is no exception. This field is churning with activities and initiatives in a quest for continuous improvement in technology. Although blockchain is a brilliant technology for trusted transactions, social interaction, and commerce, it is also open and decentralized. Openness and inclusivity of decentralized participants are two of the many impediments to the ready adoption of the technology. Dapps deployed on the blockchain address these concerns by enabling trusted transactions. Now that you are armed with the knowledge from earlier chapters, I encourage you to examine the challenges at all levels of the blockchain stack, from decentralized application development to contribution to protocol improvements.

In this chapter, you’ll learn about some nonfunctional attributes that are relevant to blockchain applications. You need to pay attention to these attributes while designing and developing Dapps. This chapter will provide a high-level view of these attributes, challenges, existing solutions, potential opportunities, and the road ahead.

12.1 Decentralized identity

What is your name? How are you identified? Identity is a fundamental requirement for interacting with any system, computing or noncomputing. You need an instrument such as a driver’s license to identify you for many of your routine activities, such as cashing a large check or taking an airline flight. You use a student ID card to avail yourself of the services of a university. But these identities are issued by a central authority after verification of your credentials, such as your Social Security number. For decentralized applications, there is no central authority for assigning identity for the participants. A decentralized system is made up of unknown participants who are potentially from anywhere in the world. In such a system, the challenge is how to

• Define a unique identity for participants

• Create and assign it to the participants

• Make it unique for every participant

• Manage (restore and remember) it

In addressing these concerns, blockchains rely on two fundamental concepts: cryptographic algorithms and larger address space (256 bits versus 64 bits). As you’ll recall from chapter 5, the Ethereum identity of a participant is 160 bits. It is derived from a private-public key pair of 256 bits, using hashing algorithms for uniqueness, and can be self-generated. This kind of self-managed identity is an important distinction between traditional centralized applications and blockchain-based decentralized applications.

12.2 Self-managed identity

To understand the concept of self-managed identity, let’s create it and do some blockchain operations with it. You’ll also collect test Ethereum cryptocurrency with it. First, you’ll generate a private-public key pair, generate a mnemonic for it, and use that mnemonic to extract account addresses to populate a MetaMask wallet. This mnemonic represents a deterministic set of account addresses for your digital wallet, such as MetaMask. (Deterministic means that the same unique set of accounts is generated for a given mnemonic representing a private key.) You performed these steps within the context of developing Dapps in chapters 5 and 8:

1. Open your Chrome browser.

2. Link to the website https://iancoleman.io/bip39.

   Figure 12.1 shows the screenshot of the web page. You can see that this web tool can generate addresses for other coins (cryptocurrencies) too.

3. Make these three choices, as indicated in the figure:

   • Generate a 12-word mnemonic.
   • Choose English as the language for the mnemonic, and press the Return key.
   • Choose ETH (Ethereum) as the coin or cryptocurrency.

4. The mnemonic appears in the BIP39 mnemonic box. Copy it, and keep it safe and secure. The mnemonic generated for me was later dirt alert wear exotic hotel nasty thunder comfort powder alarm build.

   You can retrieve accounts and their balances by using this mnemonic. Next, let’s obtain a seed phrase.

    

   Figure 12.1 BIP39 interface to generate a seed phrase/ mnemonic from a private key

   Secure your seed phrase The seed phrase represents your private key. If the seed phrase is compromised (stolen or given away), the loss is equivalent to losing a credit card from your wallet. The person who gets hold of the seed phrase can restore the accounts on their wallet and divert the funds there.

   In the next steps, you’ll create an account address to represent your decentralized identity. With this identity, you’ll be able to collect test Ethereum cryptocurrency for transactions on the Ropsten network.

5. Click the MetaMask icon in your Chrome browser.

6. Choose the Ropsten network as shown in figure 12.2

7. You may choose other networks for your later explorations.

8. Click Import Account Using Seed Phrase at the bottom of the MetaMask drop-down box.

9. In the screen that appears in figure 12.2, enter the mnemonic you generated earlier.

10. Enter a password, repeat it to confirm, and click Restore. You see your account number in the MetaMask drop-down box.

    My account address after this exercise was 0xCbc16bad0bD4C75Ad261BC8 593b99c365a0bc1A4. Here, 0x indicates that what follows is hexadecimal, followed by 20 bytes or a 160-bit address. This address is your decentralized identity; you can share it with any application to interact with it. You can give out the account numbers but not the mnemonic representing the private key. You can create many account numbers similar to the numbers of your checking, savings, college, and home accounts, and so on.

11. In MetaMask, click the Account 1 logo, and in the drop-down box that appears, select Create Account to create different accounts or identities for yourself. The MetaMask drop-down box will be similar to the one in figure 12.2, but with account details.

    
    

    Figure 12.2 Restore account using seed phrase in MetaMask wallet

    The MetaMask wallet shows that your account balance is 0. You need test ether to transact on the Ropsten Ethereum test network. Let us start collecting ether from a cryptocurrency faucet meant for this purpose.

12. Copy your account address, as shown in MetaMask. You need this address to collect test ether for your account.

13. Open a Ropsten faucet (https://faucet.ropsten.be) to receive 1.0 test ether.

14. In the box that appears, enter your testnet account address from step 10, and click the Send Me Test Ether button. You’ll have to connect the account to the Ropsten faucet using the connect option on MetaMask account.

    You should see a 1.0 ETH balance added to your account. You can view this balance in the MetaMask wallet.

    You can collect 1.0 ETH every 24 hours. Keep collecting ether to support the explorations of the various Dapps you may create.

The mnemonic you generated earlier in this section defines a unique set of accounts for your wallet. You can access these accounts from anywhere with the MetaMask-enabled browser and the mnemonic. The solution discussed in this section is for a single user self-generating the identity.

The account addresses generated can be used as identities on any Ethereum-based blockchain networks. The challenge is to teach users that they must keep the key phrases safe and secure, as they do with their Social Security numbers. Thus, managing identities is a crucial concept in production environments. To manage identities, the Sovrin organization has defined a complete, self-sovereign identity framework that provides an open identity management framework (http://mng.bz/QxWw) by using digital credentials you own. Sovrin uses an issuer-verifier-owner model for managing identity and trust.

12.3 Consensus and integrity

The consensus model is a hotly debated topic in blockchain technology. Participants enabled by the self-assigned identity can send transactions, and these transactions are collected into different blocks by the blockchain (miner) nodes, as shown in figure 12.3. One of the many blocks formed will be appended to the chain. The challenge is to add a block about which the stakeholders in the network agree. Let’s explore this aspect next.

Consensus means agreement among peers. This consensus is an agreement among the full nodes about the next block to be added to the chain, a process that ensures the integrity of the chain. To address this issue, different consensus models--such as proof of work (POW), proof of authority (POA), and proof of stake (POS)--have been proposed and tried.

Bitcoin uses proof of work (POW) for consensus. Figure 12.3 shows a high-level depiction of POW consensus. The figure shows that miners compete (by solving a computation puzzle) to add the next block to the chain. POW is computationally intensive and results in enormous power consumption in the massive racks of specialized computers used in solving the POW puzzle for the right to mine the next block. It is estimated that Bitcoin mining consumes as much as energy as the country of Ireland uses per day. Therein lies the problem. Let’s discuss the POW method and two alternatives to it.

Figure 12.3 Block creation and transaction confirmation with POW consensus model

12.3.1 Proof of work

The POW algorithm has been working in Bitcoin since its inception more than ten years ago; Ethereum has used POW since its release. POW is the baseline for many consensus algorithms that are being proposed, so it is good to review POW in this section. POW works like this. Compute the hash H of block header elements (fixed) and a nonce (variable):

1. H = hash(header, nonce) //nonce is variable parameter in the header

2. If H <= function(difficulty) for Ethereum, the miner has solved the puzzle, jump to step 4. //difficulty is a variable parameter in the header

3. Else change the nonce and repeat steps 1 and 2.

4. Puzzle has been solved.

Although it is difficult to find the combination (header, nonce) that solves the problem in step 2, it is easy to verify. How do you verify that a hash H <= 2128 assuming 2128 is the function(difficulty) in the steps? Check whether the leading (256-128= 128) 128 bits of H is zero. Note that all data and computations are in 256 bits. In the newer version, Ethereum Istanbul, the plan is to use proof of stake (section 12.3.2).

12.3.2 Proof of stake

In proof of stake (POS), the full node with the most at stake or most coins in its account chooses the next block to be added to the chain, which is why it is called proof of stake. The idea is that the node with the most at stake will not act maliciously and risk its stake by forking the network. A round-robin policy is used to avoid monopoly by the node with the most at stake. The transaction fees pay the minter (yes, minter, not miner) fee, and there is no miner fee, such as in POW. The POS approach is expected to be environment-friendly and efficient.

12.3.3 Byzantine fault-tolerant consensus

Practical Byzantine Fault Tolerance (PBFT) has been proven to tolerate random or Byzantine node failures (including malicious nodes). In PBFT, nodes elect a leader, and that leader adds the next block to the chain. The nodes exchange messages. The messages, along with the saved state, are used to reach a consensus in the presence of random independent faults or bad nodes. The chosen node adds the next block of validated transactions. PBFT is popular in permissioned blockchains such as Hyperledger Fabric.

As you can see, consensus is a core component of a blockchain protocol, and an efficient algorithm is essential for both the integrity and scalability of blockchain. Scalability is the next challenge I’ll discuss.

12.4 Scalability

Scalability is a bottleneck preventing the broader adoption of blockchain for business applications. The question many businesses ask is whether blockchain protocol, infrastructure, network, and nodes can successfully deliver a transaction rate on par with that of credit card transactions. Average transaction confirmation time depends on the average block time--the time required to confirm a block. As shown in figure 12.3, transactions are packed in a block, and the block is appended to the chain. All the transactions in a confirmed block have the timestamp of the block. You must be aware of this fact when using transaction confirmation times for verification in your application.

DEFINITION Scalability is the ability of a system to perform satisfactorily at all practical levels of load. Load, in the context of the blockchain, could be transaction times, transaction rate, number of nodes, number of participants and accounts, number of transactions, or other attributes.

In the case of blockchain, practitioners are concerned about the transaction rate, or transactions per second. This metric is critical for many applications, from payment systems to supply chain management, so let’s focus on transactions per second as the metric for scalability.

Blockchain has taken on the responsibilities of the intermediaries, including validation, verification, and recording of the transaction. The consensus process for the integrity of the chain is another time-consuming function. All these functions take time and result in significant overhead in Tx confirmation time compared with that of a centralized system. The transactions execute sequentially. The full nodes store the entire chain. Thus, transaction rates are not satisfactory compared with those of centralized applications, which affects scalability. In this section, let’s examine some solutions that address scalability.

Figure 12.4 Ethereum average block time chart

Figure 12.4 shows average transaction time from etherscan.io from January 2016 to July 2020, the average block time, ranging from 12 seconds in 2020 to a maximum 30 seconds in 2017. A credit card transaction can be confirmed in less than a second, whereas it takes an average of 10 seconds for Ethereum. It is expected that in the latest version of Ethereum, transactions per second will improve to 3,000. But the Visa credit card network is capable of handling a load of 65,000 transactions per second. Thus, scalability is an area that requires a lot of attention, and this is an opportunity for you to contribute creative solutions.

12.5 Scalability solutions

Many solutions have been proposed, and quite a few of them have been in operation in production networks. The Ethereum community is working hard to address the scalability issues. The proposed solutions are across all levels of the stack.

12.5.1 Side channel

Side channel is a solution at the blockchain application level. The state channel of Ethereum and the lightning channel of Bitcoin are examples. The idea is to keep only relevant transactions on-chain for confirmation and recording. Other transactions between trusted parties are offloaded to a side channel, thus reducing the transaction load on the main channel. Periodically, the gist of the off-chain happenings are synchronized with a transaction on the main channel. The transactions of off-chain channels take place at much higher speeds than on the blockchain networks because no consensus or recording on the blockchain distributed ledger is required.

Recall that you used a side channel in the MPC-Dapp in chapter 7. This Dapp addresses scalability to a certain extent at the application level. At this point, you have the knowledge and skill to apply the side channel concept when developing Dapps, as demonstrated in MPC-Dapp. Try using the side channel model where it is relevant in your Dapp development.

12.5.2 Block size

Increasing block size is a protocol-level solution. Transaction time depends on block time. So why not increase the size of the block to accommodate more transactions, thus increasing the number of transactions per block? The idea is to double the block size and store the block header data segregated (Segwit2X) to accommodate more transactions in a block.

12.5.3 Network speed

Improving network speed is a network-level solution. Researchers believe that scalability is a network-level problem, and increasing the bandwidth at the level that of the internet will help. The idea is that higher network speed may lead to a faster relay of transactions and block, leading to faster consensus and block selection. There are many opportunities for you to contribute to existing or new scalability solutions at the network and protocol levels.

12.6 Privacy

When I introduce blockchain to any audience, the most frequently asked question is about privacy. A public blockchain is an open network that anybody can join and leave, so how do you keep it private? I often reply with another question: How do you keep something private in real life? By not allowing others to see it.

The first-line solution for addressing privacy is restricting and controlling who is allowed to join and transact on the blockchain. That’s been the solution for blockchain too. Consider a democratic voting system on the blockchain. There is no need for the country’s voting blockchain network to be open to the entire world; you want this network to be private to the legal or permitted citizens of that country. Hence, we have permissioned blockchain, which leads to the first line of defense supporting privacy, the three major models for blockchain networks: public, private, and permissioned.

12.7 Public, private, and permissioned networks

Bitcoin (also called the permissionless blockchain) is a working example of a public blockchain. The primary purpose of the Bitcoin blockchain is to support a decentralized, peer-to-peer payment system. It’s meant to be a transparent, permissionless public system that anyone can join and leave as they wish, as in any other bearer payment system, such as transacting cash. If you pay cash for an item you purchase in a store, for example, nobody asks you for your signature or needs you to authorize the payment. Similarly, Bitcoin enables a peer-to-peer digital payment system without any intermediaries.

When the use cases for blockchain expanded beyond the simple payment system into business areas such as personal health care systems and financial systems, privacy and restricted access became necessary. Even in the public payment systems, it became apparent that the whole chain may not be relevant to all the participants. Business transactions in a Buffalo school district may not be relevant to the Nairobi tourism board, for example. Such thoughts and ideas resulted in the creation of permissioned blockchain (figure 12.5), in which only permitted participants can transact and take part in the blockchain operations.

The permissioned blockchain is also known as a consortium blockchain based on its everyday use cases in specific vertical business domains, such as the auto or food services consortiums. Chapters 2 and 6 introduced the ASK airline consortium, which is a suitable Dapp for a permissioned blockchain. In the case of the micropayment channel in chapter 7, a public chain is appropriate.

Figure 12.5 Public, permissioned, and private blockchain networks

The third type, private, is an extreme case of permissioned network in which membership is highly selective and often limited and permanent. Although experts claim that a private blockchain is no different from a centralized system among known participants, it still has potential for useful applications. Sometimes, trust is a significant issue even among known or related peers, such as members of a family, the board of directors of a company, or a group of researchers working on sensitive matters of national security. You could develop a private blockchain among a closed set of entities to record deliberations and decisions, to be used later for discovery and in some cases for litigation. The significant issue with a smaller membership and consequently with private blockchain is the 51 percent attack. In this case, it is potentially easier for a few members to collude and make the chain inconsistent.

All three types of public blockchains--permissionless, permissioned, and private--are relevant in the blockchain application domains. They differ mainly in the way membership is determined. With closed membership, it is possible to implement a more efficient consensus mechanism than the POW of Bitcoin, which consumes an enormous amount of power. But in a closed, private system, you are reverting to trusting a few designated participants, as in a centralized system. You must weigh these facts when deciding which type of blockchain is appropriate for a given problem. Whether the blockchain is public, private, or permissioned, you need security mechanisms to protect the data.

12.8 Confidentiality

Many people equate privacy with confidentiality. Confidentiality is different from privacy; it is about keeping details (or metainformation) about the transaction closed. In some situations, transactions have to be confidential. Consider a patient-doctor relationship. If there were ten transactions between a patient and healthcare provider in a day, this information might convey something, even if the content of the transactions is kept private. The fact that ten transactions occurred between the parties implies something.

Let’s explore how open the transactions are in the Ropsten network you used to deploy your Dapps.

12.8.1 Open information

Whether it is a public chain or a private chain, you can search the blockchain ledger with an account number to find all the transactions associated with this address, as shown in figure 12.6. You can also search by transaction hash, block number, and other filters. If you have an account number, you can try it for by yourself at the Etherscan for Ropsten site (https://ropsten.etherscan.io).

Figure 12.6 Searching the blockchain records by a certain filter

If I want to know all the transactions that originated from a certain identity, for example, I can search for it by using its account address, as shown in figure 12.7. You realize that you can secure all the data by using encryption, but the fact that the transaction happened is not confidential. It shows the transaction from account 0x28... along with other details. Even if the contents of transactions are encrypted, the transactions themselves are not confidential. If this is my address, you know that I have been frequently invoking a smart contract at the address 0x1e... This information conveys some intelligence to you. If the smart contract were my stockbroker, you might infer that I have been considering some financial moves. In other words, although my transactions were secure, they were not confidential.

Figure 12.7 Transactions from account 0x2812c... on Ropsten public chain

12.8.2 A solution

How do you achieve confidentiality in blockchain applications? To protect the confidentiality of data, a novel concept called zero-knowledge-proof has been proposed. Zcash (https://z.cash/technology) is a working solution for realizing confidentiality in cryptocurrency transfers. It achieves confidentiality by implementing a novel type of Txs called shielded transactions or z Txs. In this realm, unshielded Txs are referred to as t Txs. Zcash is well-founded in a strong scientific background. It offers four types of Txs:

• Both sender (z) and receiver (z) are shielded (fully private).

• Only sender (z) is shielded, not the receiver (t).

• Only receiver (z) is shielded, not the sender (t).

• Both receiver and sender are not shielded (public).

In this case, z refers to shielding or hiding, and t refers to a regular nonshielded entity. Although this solution is available only for digital currency such as that offered by Zcash, a similar solution can be adapted to other application domains, such as health care, financial, and military.

12.9 Security

Security is a challenge for any computing system and network, especially in an open and decentralized system of typically unknown participants. Over the years, security at the network level (http:// to https://), infrastructure level (firewalls), system level (dual authentication passwords), and similar measures have improved the overall security of networked systems. Typically, a blockchain-based application is part of such a system. In addition, robust cryptographic algorithms and hashing algorithms have helped secure blockchain at the protocol level and the application level. Here are some of the approaches used:

• 256-bit processors and computations for blockchain operations --The 256-bit address space is four times exponentially larger than 64-bit space, and a larger address space means that the probability of hashing collision is lower, thus preserving the integrity and security of blockchain operation.

• The private-public key pair --The private-public key pair is the metaphorical passport to participating and transacting on the blockchain. Similar to the way you use, secure, and protect a credit card, you need to protect the private key and the mnemonic representing it for the security of your assets.

• Elliptic curve cryptography (ECC) --At the protocol level, blockchain protocol uses the ECC family of algorithms instead of the traditional RSA (Rivest-Shamir-Edelman) algorithm. Why ECC, not RSA? ECC is stronger than RSA for a given number of bits. A 256-bit ECC key-pair is equivalent in strength to about a 3072-bit RSA key pair.

• Tx and block hashes --Tx hashes and block hashes are computed at the time of their creation. Any modifications (even a single bit) to a Tx or a block will result in a mismatched hash, resulting in rejection of the Tx and the block securing the integrity of the chain.

• Off-chain data security --Application data off-chain can be secured by hashing the data and storing only the hash value on the chain. This concept is discussed in chapters 2-6, in which the airline data off-chain can be secured by a hash on the chain.

• On-chain data security --At the application level, a combination of encryption, hashing, and one-time-password helps secure the data transmitted in a Tx. You used hashing and encryption with a one-time password to secure the bid in the MPC-Dapp in chapters 7 and 8.

Thus, a combination of hashing and cryptography plays a critical role in the blockchain creation process, as well as the integrity of transactions and the security of data. A developer will routinely use cryptography and hashing algorithms in their development. As you learned in chapter 9, the web3 API provides Keccak and SHA3 functions to facilitate security in Dapps.

Do you wonder about the role of cryptocurrency in a typical Dapp? Do you wonder whether you can develop without the use of cryptocurrency and focus solely on business logic on the blockchain? That’s what you’ll explore next.

12.10 Securing it with cryptocurrency

Another important consideration in blockchain applications is the cryptocurrency aspect that is not prevalent in your regular network computations. The genesis of blockchain is cryptocurrency transfers with the advent of Bitcoin. As you may have realized through your explorations in this book, ETH cryptocurrency is required for deploying a Dapp, transacting, and executing smart contract functions. The cryptocurrency, miner fees, transaction fees, gas points, and incentives all ensure proper operation and enable trust. In other words, these expenses incurred are the cost of trust. Blockchain platforms use cryptocurrency as well as protocol logic to implement trust. This aspect leads to the classification of platforms based on their primary purpose. Bitcoin, Ethereum, and Linux Foundation’s Hyperledger (figure 12.8) are three different platforms based on their primary purpose. Many other platforms are available, and I urge you to explore appropriate ones for your application domain.

Figure 12.8 Types of blockchain, from pure cryptocurrency to pure logic

Here are a few prominent platforms to consider for your applications:

• Bitcoin is meant for cryptocurrency transfer and does not support arbitrary logic in such instruments as a smart contract. Bitcoin protocol does support a minimal script for conditional transfer of cryptocurrency.

• The Ethereum mainnet is a public network, but Ethereum can be used for private, public, and permissioned networks. Enterprise Ethereum Alliance (EEA) was created to support the need for consortium or permissioned as well as private Ethereum networks. Ethereum supports cryptocurrency as well as computational logic in smart contracts.

• The Hyperledger framework focuses on computation logic and currently does not support cryptocurrency. The Hyperledger framework has many implementations, including Iroha, Intel’s Sawtooth, Fabric, Indy, Burrow, and IBM’s Fabric (version 2). Currently, these platforms are purely business-logic-based. No cryptocurrency is involved.

Thus in figure 12.8, you can see the two ends of the spectrum of blockchains, from real cryptocurrency enablers to pure business logic enablers. When you are designing blockchain-based solutions, you must consider cryptocurrency to be an integral part. Blockchain may not be only for sending and receiving value. You can create incentive models involving participants, fees for various activities, creative solutions for planetary-level problems (such as MPC discussed in chapter 7), and new economic models centered on a working digital currency. The cryptocurrency incurred is the cost of trust for the decentralized blockchain-based application.

12.11 Accessing off-chain data (Oracles)

Have you wondered how a smart contract can access external data? A smart contract operates in a sandbox. It cannot call an outside function or link to an external resource. Why can’t a smart contract access outside sources? Depending on the source called, external data access from a smart contract may affect the global consistency of the blockchain. The results of any operation on the blockchain have to be deterministic. These issues limit the applicability of smart contracts in many real-world applications that may involve obtaining facts, data, and assets from external real-world sources. Moreover, data may have to be obtained at the time of execution and may not be available at the time of deployment of the contract. Let’s look at some examples:

• Temperatures on Mount Kilimanjaro on a given day --The temperatures are universal facts, but they have to be obtained from an authentic external weather source.

• Stock market data --This data may be the high and low prices of a stock on a particular date on the NASDAQ market. This condition ensures that all the participants on the chain get the same consistent outcome for a smart contract operation.

How do you get access to external resources? Accessing data sources external to the smart contract is addressed by a concept called oracles. An oracle service fetches external data for a smart contract. Merriam-Webster defines oracle as “an authoritative or wise expression or answer.” This definition closely defines the role of the oracle service in smart-contract development.

Definition An oracle service is a data carrier between web resources (APIs and URLs) and a smart contract. An oracle service is located outside the blockchain protocol.

An oracle is a useful component that facilitates the availability of real-world facts needed for the functioning of certain smart contracts. Provable (https://provable .xyz/index.html) is an implementation of an oracle service for getting outside data into a smart contract. Chainlink (https://chain.link/features) is a more recent oracle service for smart contracts to access external data feeds, APIs, and payments.

Oracle service is implemented as a smart contract that provides a query function to access external sources. The oracle smart contract is imported into the calling smart contract and inherited. Then a query is used to access the oracle with the required data. The data requested is returned through a callback function because accessing data and verification may take some time. Figure 12.9 shows a simple class diagram relating a smart contract, oracle services, and an external data source.

Figure 12.9 Accessing external data through oracle service

When the smart contract AvgWinterTemperature is deployed, it calls fetchData(), which in turn invokes the oracle service’s query with the URL for the data source. It may take time to fetch the data, so a callback function is provided that can be invoked when the required data has been fetched. The oracle service accesses the external data source, authenticates the requested data, and sends it to the originating smart contract. Additionally, the service may offer methods to verify the authenticity of the data fetched.

12.12 From foundations to practical systems

Blockchain is based on nearly 40 years of scientific research in cryptography and math algorithms. The butterfly effect is defined as a little perturbation of an initial state that culminates in significant outcomes. This concept is defined in the context of chaos theory. The advent of Bitcoin has had a butterfly effect on technology. It has creatively synthesized scientific research results from the past four decades to release an innovative working model for a peer-peer digital payment system, as shown in figure 12.10. It shows how foundational research in public-key cryptography and security has led to the discovery of the internet and secure distributed systems. These discoveries, along with hashing and cryptographic algorithms, enabled Bitcoin and the underlying foundation of blockchain. All these concepts culminated in blockchain’s distributed ledger, disintermediation, smart contracts, decentralized apps, and planetary-level inclusive systems.

The smart contract concept in figure 12.10 is enabled by blockchain. A smart contract represents a token. In other words, a smart contract can provide an elegant representation of an asset in the physical world or digital world: a stock, a piece of real estate (as discussed in chapter 9), or a digital game bounty. This tokenized asset can be traded, discounted, divided, archived, and destroyed. The tokens (or their fractions) can be used for incentivization, such as shopping coupons and participatory remuneration. The entire history, since the creation of the asset, can be recorded in a trusted distributed immutable ledger that can facilitate audits and authentication. These features have the potential to spawn a new token economy.

You can see from figure 12.10 that this single idea of blockchain is ushering in a technological and a social revolution. You are witnessing the transformation from centralized to decentralized applications enabled by blockchain technology and cryptocurrencies. These emerging technologies are expected to culminate in new applications that transcend demographics and national barriers. As explained in this chapter, this area is in flux, and a lot more needs to be done. Transforming this strong foundational knowledge into practical and useful Dapps will require reimagining traditional applications to include the trust component. You can play an important role as a participant, collaborator, and contributor to this revolution.

Figure 12.10 The blockchain butterfly: foundations to contributions

12.13 Looking ahead

At the global level, organizations such as the United Nations have an opportunity to serve as a test bed for many blockchain applications, such as verifiable disaster relief, vaccine distribution, maintaining international peace through trust, and enforcing democratic processes. Chapters 7 and 8 demonstrate a massive global plastics cleanup problem.

Within any country, government officials and policymakers can take up policies and regulations to ease the adoption of blockchain. U.S. states such as New York and Delaware are considering regulations that will help in the widespread adoption of blockchain solutions. Unlike with other traditional technologies, the government can host a full node or nodes to facilitate decentralized operations. This feature offers the additional benefit of full nodes storing a completed timestamped ledger of Txs. The information on the ledger can be used for audit and review purposes. The Department of Education, for example, may play a vital leadership role in the adoption of blockchain for educational purposes such as countrywide credentialing. (Chapter 11 discusses the credentialing prototype DCC-Dapp.)

At the application level, autonomous vehicles and robots on shop floors and in home care have become a reality. Augmenting these innovations with blockchain can develop a layer of trust for monitoring autonomous actions. Enabling a cryptocurrency capability for these autonomous entities, you can design self-paying and self-managing machines. You can send cryptocurrency to pay these machines for their services in cryptocurrency, and they can use their cryptobalances to self-schedule repairs, replen-ishments, and payments.

Have you wondered about the data that gets stored on the distributed immutable ledger of blockchain? This timestamped data is indeed a valuable resource for post-analysis to discover patterns, actionable intelligence, and anomalies.

More developers and practitioners are wanted to focus on many of the challenges discussed in this chapter. More tools, frameworks, and test beds are needed for rapid prototyping and testing. Educating stakeholders at all levels and training users and developers in the proper use of blockchain technology is an important step. Thinkers and designers who are knowledgeable about blockchain are needed to use blockchain to solve problems creatively.

12.14 Best practices

Here are some best practices for what you learned in this chapter:

• Choose the type of blockchain based on the membership requirements of the application: private, public (permissionless), or permissioned (consortium).

• Determine the blockchain platform for your environment, depending on whether you need cryptocurrency.

• Carefully review the problem; it may not require blockchain involvement.

• To support Dapp development, choose the language for the smart contract, frameworks for the frontend, tools such as Remix and Truffle, test bed (Ganache), cloud support (Infura), and test plans.

• Design before you develop. Use a test-driven development approach (as discussed in chapters 4, 6, and 10).

• Make sure to pay attention to the best practices discussed throughout this book for developing Dapps.

12.15 Retrospective

Blockchain is here to stay. Bitcoin is an excellent example of what has been running autonomously and supported by a developer community. Blockchain, such as Ethereum discussed in this book, has added execution logic to make it viable for solving business problems. Blockchain is not without its share of challenges, as it is evolving and growing its ecosystem.This book covered quite a range of decentralized applications and supporting concepts. The seven worked-out examples are

• A versatile counter (Counter-Dapp)

• A digital democracy (Ballot-Dapp)

• A marketplace for unused airline seats (ASK-Dapp)

• A blind auction framework (BlindAuction-Dapp)

• An incentivization model and side channel for micropayments (MPC-Dapp)

• A token model for real estate transactions (RES4-Dapp)

• An educational credentialing model (DCC-Dapp)

These Dapps provide application models with instructions to support your learning and development efforts. The book also covered relevant concepts that support the development of these Dapps, including

• Trust and integrity

• Security and privacy

• Off-chain and on-chain data

• Local and public deployment

• Automated testing

All the concepts are supported by code to illustrate their application in the development process. I hope you find them useful for understanding and developing with blockchain technology.

12.16 Summary

• Decentralized identity, consensus, and cryptocurrency are unique issues related to blockchain that you do not find in traditional networked systems.

• Scalability is a major challenge in blockchain networks. Innovative solutions are needed to address scalability and to encourage broader adoption of blockchain.

• Privacy, confidentiality, and security are critical in systems supported by blockchain because no central authority polices or manages them.

• Blockchain has a deep, strong foundation in nearly four decades of mathematical and scientific research.

• Blockchain provides a trust layer to enable autonomous applications. These applications will usher in a new wave of innovations that is sure to lead us to another revolution in internet technology.