Chapter 10. The Future of Blockchain

The comparison of blockchain and cryptocurrencies today to the early days of the internet isn’t entirely incorrect. As those of a certain age may remember, the consumer internet in its early days was slow and lacked most of the features we are accustomed to now.

Blockchain is at a similar stage. Consumer adoption is still pretty low, and doing things is often confusing and difficult. This means developers have a tremendous opportunity to shape the future of the blockchain industry.

In general, new technologies are being adopted ridiculously fast—faster than ever before (see Figure 10-1). Blockchain could be the next great consumer technology that takes off, if the right applications are found for it.

Of course, not everything ends up succeeding. The internet offers the lesson that being flexible and adaptable is the path to advancement. The world of blockchain can move at a dizzying pace, and therefore having views that adjust to the changing market and developer ecosystem is key.

Figure 10-1. Rate of adoption of different technologies over time

The More Things Change

In the 1970s, at the dawn of the internet, a group of computer industry representatives from the United States, the United Kingdom, and France got together and devised the Open Systems Interconnection (OSI) model. Their aim was to create an open and multilayered set of standardized protocols for data exchange on the internet. By the 1980s, the effort had been backed by many stakeholders, including engineers, regulators, and computer and telecommunications companies. However, by the early 1990s two more efficient and nimble standards had come to dominate instead: Transmission Control Protocol and Internet Protocol, or TCP/IP. Here’s a brief look at how this relative upstart took over:

1960s
Data transmission technology evolves from old-school circuit switching in telephone networks. Packet switching breaks information into blocks, transmits them, and then reassembles the data at the receiving end. ARPANET, an early version of the internet, is the first network to use packet switching.
1970s
Telephone carriers explore the idea of packet switching via “virtual” circuits, proposed in order to protect analog circuit revenue. However, the original proponents of packet switching propose a more innovative distributed datagram model. Following this divide, the OSI model is devised.
1980s
The reference model for OSI is published, including options for both packet switching implementations. The US government, the main sponsor for internet research, mandates purchasing OSI-standard computers by 1990.
1990s
TCP/IP, first used and developed throughout the ’80s and used in the ARPANET as the successor to its Network Control Program (NCP), gains traction. A revolt among engineers attempting to scale TCP/IP leads to the rejection of the OSI standard; while OSI is mired in standards and procedure, TCP/IP is free and open for use.
2000s
TCP/IP is the de facto standard for internet communications on all devices, beating out standards-based OSI because of its more permissive framework for engineers to build upon.

What does this snapshot history of internet communication protocols have to do with the future of blockchain? Decades ago, early internet pioneers probably thought OSI would rule the world. Instead, TCP/IP accomplished that feat. The blockchain world, over time, will likewise see promising projects fade for various reasons because the ecosystem today is still evolving.

The internet is not something anyone ever sees. They just see the applications built on top of it, like the web and email. Blockchain is much the same. Just like the internet, blockchain is a backbone for consumer-facing applications.

Cryptocurrency networks and the blockchains that underpin them are similar in essence to software. Software is dynamic, never finished, and part of a larger ecosystem. Cryptocurrency is also dynamic, and blockchain, as the recording device for cryptocurrencies, moves in a dynamic way too. Lots of things are set to change in a few short years. The future is bright, but it’s definitely not set in stone.

Blockchains to Watch

Besides Bitcoin, Ethereum, and various enterprise-type blockchains, there are lots of other projects available for developers to build on. Whether because of privacy, efficiency, or improved smart contract capabilities, these will be three of the platforms to watch out for in the near future:

EOS
An operating system and smart contract platform, EOS increases the number of transactions included in each block and requires no fees, using a resource-leasing model to provide transaction bandwidth for users on its blockchain by only utilizing a small set of concentrated nodes. The trade-off is that the nodes are part of a membership that is centralized. These block propagators use special hardware configurations to handle blockchain storage and smart contract execution on the network. The propagators receive rewards for block generation and for governance.
Cardano
A smart contract platform that uses proof-of-stake, Cardano’s consensus mechanism chooses random stakers to validate each block. Users are also able to “delegate” their stake in-wallet to stakers that are consistently online, a requirement for rewards. While delegating, users can still spend the native ADA cryptocurrency thanks to a structure of multisignature addresses. The project has been notable for its academic nature and its use of Haskell libraries, existing and established in programming, for the protocol.
Monero
A blockchain that has implemented privacy and is gaining traction for its ability to execute cash-like transactions, Monero makes transaction details private by implementing three cryptographic strategies: ring signatures, ring confidential transactions, and stealth addresses. Monero’s currency symbol is XMR.

Privacy in blockchains is an important component of the future. In the next section, we’ll briefly explore Monero in a little more detail.

How Monero Works

To demonstrate how Monero works, we’ll look at an example transaction of 0.5 XMR between two addresses.

Transaction details that are visible to the public are as follows:

  • Transaction ID: 7de8…53f1

  • Block #: 2015291

  • Miner fee: 0.00017681

  • Inputs: Only 1 real input and 10 decoy inputs

  • Key image: b142…da7e

These are the inputs that are publicly viewable:

  Ring members Block Timestamp
1 3154…a729 1936368 2019-10-03 6:07
2 60c9…de58 1970318 2019-11-19 13:11
3 F6a2…b1e3 1997733 2019-12-27 2:14
4 9a62…a1a8 2006400 2020-01-08 2:01
5 d0aa…c50b 2014276 2020-01-18 22:55
6 31b6…0bbf 2014635 2020-01-19 11:20
7 d3a6…6ef1 2014688 2020-01-19 12:41
8 754e…3a4d 2015113 2020-01-20 3:11
9 ce8b…6f7a 2015154 2020-01-20 4:34
10 0bab…594d 2015200 2020-01-20 5:58
11 228d…1bd0 2015278 2020-01-20 8:38

And these are the outputs:

  Stealth address Amount
1 0152…19e4 ?
2 c44f…e531 ?

The inputs that are hidden from the public are as follows:

  Monero address Amount Viewable by
1 43Ao…GHU9 0.01 Owner of this address, who also generated the transaction

And these are the outputs that are not visible to the public:

  Monero address Amount Viewable by
1 41qp…NxdK 0.005 Owner of this address
2 43Ao…GHU9 0.00482319 Owner of this address

Ring signatures hide the public address of a sender in a Monero transaction. Monero follows a UTXO accounting method, similar to Bitcoin. With Bitcoin, when the sender builds a transaction, they only include inputs from addresses for which they control the private keys. This is so the sender can sign the transaction that provides authorization to send those funds.

However, in Monero, when a sender builds a transaction they include decoy inputs chosen randomly from addresses that are owned by others. So, even though many inputs are included in the transaction, only one is actually sending funds. Publicly it is impossible to know which input is sending funds.

In the preceding example, funds are being sourced from only one input. There are 11 addresses in the ring signature, meaning that there are 10 decoy inputs. The generator of the transaction knows that the address sending the funds is #11 (228d…1bd0), but they are the only one who knows which one is the real input.

To prevent double spending, every Monero transaction includes a key image, which is generated by the true transaction sender. If the sender tries to send funds from an input that has already been sent, the key image they generate will be identical to the key image that was generated in the first transaction that sent those funds. The Monero miners won’t validate the double-spend attempt because the same key image has already been included in a previous transaction on the blockchain.

Note

The key image is Monero’s equivalent to Bitcoin’s transaction signature. It’s generated by the sender, and miners use the key image to prevent a sender from double spending. In the preceding example, the key image is b142…da7e.

The purpose of a ring confidential transaction (ring CT) is to hide the amount sent in a Monero transaction. It’s a privacy feature that masks the amounts sent to an output through cryptography—only the sender and receiver of the transaction know the actual amount of funds being sent.

To recap:

  • The sender is the one who generated the transaction details, and who therefore knows the transaction amount.

  • Every Monero address has a private/secret view key. In a Monero transaction, the owner of the address that received XMR can decrypt the amount sent using their private/secret view key.

The miners don’t care about the exact amount sent; their goal is simply to determine whether the transaction is valid or invalid. To validate a transaction, a miner must do a range proof. That is, they have to check if the following are true:

  1. The sum of the inputs is equal to the sum of the outputs.

  2. The amount sent to each output is greater than 0.

The miners can accomplish both these checks through cryptography without knowing the amount sent.

In the preceding example transaction, the funds were sent to two outputs. The first output goes to address 41qp…NxdK, and the owner of that address can use their secret view key to decrypt the amount value of 0.005 XMR. They cannot view the amount value for the second output.

Stealth addresses hide the receiver of a Monero transaction. The sender of a transaction creates a new stealth address for the receiver, using the receiver’s public view key, the receiver’s public spend key, and a random value.

Mimblewimble, Beam, and Grin

Mimblewimble is a blockchain protocol that emphasizes privacy paired with scalability. A zero-knowledge proof technology called Bulletproofs verifies that transactions are valid, and the state transition is recorded on the blockchain, obscuring the details.

Two other projects have emerged from this: Beam and Grin. These two projects are governed quite differently: Grin is a loosely organized open source group, whereas Beam’s team is backed by investors.

Both Beam and Grin share some key attributes, such as ASIC resistance, scalability, and privacy, but there are some differentiating features other than governance.

Beam characteristics include the following:

  • Implemented in C++

  • Uses Equihash proof-of-work

  • Supply capped at 263 million to encourage store of value

  • Sender and receiver wallets can create transactions without being online

  • Uses “scriptless script” for extension beyond transactions like escrow and atomic swaps

Grin characteristics include the following:

  • Implemented in Rust

  • Uses Cuckoo Cycle proof-of-work

  • Infinite supply to encourage spending

  • Transactions require sender and receiver to be online

  • Limited scripting, designed to be as simple as possible

The Scaling Problem

A lot of research in the coming years will center on increasing transaction capacity while remaining efficient, where fees are low and the crypto is still easy to use. Bitcoin and Ethereum definitely need to increase their scalability given their current limitations—Bitcoin can only process 3 to 7 transactions per second, and Ethereum can only get up to around 20 transactions per second. That’s not nearly enough for cryptocurrency networks to truly take off on a massive scale. This is why new ideas, some of which are discussed in this section, are needed to solve the scalability problem.

DAGs

Directed acyclic graphs (DAGs) rethink the way blockchains are constructed. Instead of blocks in a chain, DAGs are interconnected data structures, as Figure 10-2 illustrates. Transactions validate one another in a system where users act as both miners and validators. This design eliminates efficiency problems like orphaned blocks and long block times. Transactions are able to complete across this network in a more decentralized and faster method.

Figure 10-2. A DAG network design

Avalanche

A new type of consensus mechanism for cryptocurrencies, Avalanche relies on a dynamic population sampling voting mechanism to create a fluid blockchain with highly adaptable rules, with a “leaderless” model where all nodes are considered equal. This eliminates the hardware-based mining found in other cryptocurrency networks. Setting up nodes that have separate rules while still being part of the network is possible. In this way, the platform can use multiple scripting languages and virtual machines.

Lightning

A solution to the limitations of Bitcoin’s throughput in transactions per second, Lightning uses channels, as illustrated in Figure 10-3, that parties open with one another outside of the main Bitcoin blockchain. It uses a main chain-backed commitment scheme called Hash Time Locked Contracts to keep track of balances, providing settlement when a channel is closed or goes offline. There are several implementations for Lightning, including Blockstream’s c-lightning and Lightning Labs’s lnd. Square Crypto is also planning to release a Lightning Developers Kit (LDK) in the near future.

Figure 10-3. Lightning channels are created by two or more participants, who then assign value to the Bitcoin blockchain

The scaling problems that exist in cryptocurrency today aren’t all that different from what computer networks once faced. Necessity, as they say, is the mother of invention. As the internet’s popularity increased, the growing need for capacity led to numerous technical solutions. These included dark fiber, or fiber optic cable laid long before it was needed. Investment in numerous scaling solutions for cryptocurrency networks could be similar, as the research will likely be utilized as adoption picks up, including in Bitcoin and Ethereum.

Lightning aims to make Bitcoin more usable by solving the following scalability issues:

Transaction speed
As mentioned, Bitcoin can only process up to about seven transactions per second. If masses of consumers wanted to use Bitcoin, the network currently couldn’t support that level of demand.
Block times
On average a new block of transactions is generated every 10 minutes, and once a block is full, no more transactions can be processed by the network until the next block is discovered. If someone buys something with bitcoin, they are likely not willing to wait more than 10–20 minutes to receive confirmation that their transaction was processed.
Bitcoin blockchain size
Every miner and full Bitcoin node must maintain a copy of the entire Bitcoin blockchain, which was around 285 GB in size as of June 2020.

The Lightning Network solves these problems by enabling Bitcoin addresses to transact bitcoin through a payment channel. This channel acts as a ledger that two Bitcoin addresses manage peer-to-peer. Transactions through a payment channel are not recorded on the Bitcoin blockchain, but rather off-chain.

Note

This is a simplified explanation of payment channels that is meant only to give an idea of how they work. True payment channels involve a hashed secret and potentially several peer hops before they reach the intended recipient and sender.

Let’s say Alice visits Bob’s coffee shop every day and wants to buy a cup of coffee from Bob each day. One way she can pay conveniently is by buying a $100 gift card and using that each day. In this situation, Alice commits $100, and the gift card company controls a ledger of all her transactions.

The Lightning Network’s version of this situation would be Alice opening a payment channel with Bob and funding that channel with 0.01 BTC. In this situation, Alice commits 0.01 BTC, and instead of a third party controlling the ledger, Alice and Bob both control the ledger together. Cryptography and the cost associated with funding the channel force both Bob and Alice to act appropriately.

Off-chain transactions

At some time in the future, Alice and Bob will perform a withdrawal transaction (Figure 10-5) that requires both of their signatures. The question is, how much will Alice and Bob each receive from that future transaction? If they perform the multisig transaction before Alice buys anything at Bob’s coffee shop, the multisig transaction should send all the funds back to Alice’s address.

Here is possible future withdrawal transaction #1:

Inputs Outputs
bc1q...3ktl
(Payment channel)		 0.01 BTC 3DZ5...2NZU
(Alice)		 0.01 BTC
Signature 1: 001443692e0c9ce1c70840847495c3216318b04a7793
(Alice’s signature)
Signature 2: cb8b99f482852b6c0d40a2f5bc249743ea6d5a80
(Bob’s signature)
       

However, if Alice spends 0.007 BTC at Bob’s shop, the multisig transaction should send Bob 0.007 BTC and Alice 0.003 BTC. So here is possible future withdrawal transaction #2 (illustrated in Figure 10-5):

Inputs Outputs
bc1q...3ktl
(Payment channel)		 0.01 BTC 3DZ5...2NZU
(Alice)		 0.003 BTC
    38iS...E8SE
(Bob)		 0.007 BTC
Signature 1: 9a791cf4d808afec90ed7051314f80f4a9310372
(Alice’s signature)
Signature 2: 104f28ca0bf87c07ef5b97d33dae38f547d0435b
(Bob’s signature)
Figure 10-5. Alice and Bob withdrawing funds from the payment channel address

Each day, as Alice buys a coffee from Bob’s shop, the values of how much each receives in the future withdrawal transaction change. And each time the values change, Alice and Bob need to generate and sign a new unique transaction, to authorize the future withdrawal transaction and prove to the miners that the new withdrawal transaction is valid. This process of generating and signing new withdrawal transactions is essentially the same as Alice and Bob performing off-chain transactions.

Lightning nodes and wallets

A Lightning wallet is a Bitcoin wallet with additional features that allow one to open/close a payment channel and perform Lightning transactions. A common mistake first-time Lightning users make is trying to open a payment channel with no BTC sitting in their wallet. A Lightning wallet must have some BTC in it to pay for mining fees, and some funds to commit to the payment channel.

Lightning requires a blockchain to have no transaction malleability, which is a vulnerability that can allow an exploiter to modify some transactional data. Segregated Witness, or SegWit, is an update to the Bitcoin protocol that separates base transaction data and signature data. Since transactions are serialized using the original transaction data, signature-based malleability attacks are prevented. The signature data goes into the transaction witness area, used by SegWit-capable full nodes to confirm that the transactions are authorized.

Note

SegWit moves the witness data needed to check transaction validity to a different part of each bitcoin transaction generated. Before SegWit was implemented on the Bitcoin blockchain, for example, it was possible for a node to change prehash information, which was not originally included in a signed transaction. This resulted in malleability attacks on the network. In order for Lightning nodes to be feasible, the risk of these malleability attacks needed to be eliminated.

Once a user is running a Lightning node, they can open a payment channel. Multiple parties with open payment channels can then collaborate on a transaction. This is done using a commitment transaction.

Since Lightning uses channels instead of a blockchain, transactions are private. However, if a node drops or otherwise loses its connection in one of these bidirectional channels, it will close the channel and settle transactions on the blockchain. In addition, payment routing occurs in this system. This routing means that if a channel is not open for some reason, the payment can go through nodes to have channels open with other parties. 

Ethereum Scaling

Ethereum is planning to make major changes to its network in order to increase its capacity. In its next iteration, known as Ethereum 2.0, the network will move to a form of proof-of-stake called Casper that will enable greater efficiency without adding complexity. It will also be split into shards, as described earlier in this chapter. It’s an ambitious plan that brings together a number of novel research ideas in order to help the network move into the future.

The first phase of Ethereum 2.0 involves the following specifications:

Beacon chain
A new blockchain that will ensure the network stays in sync by providing consensus to all the shard chains. Each shard chain will have validators responsible for adding transactions to shard blocks and proposing new blocks to add to the beacon chain and all the shard chains. Validators are activated by the beacon chain and can be deactivated either voluntarily or due to misconduct.
Casper
A proof-of-stake algorithm designed specifically for Ethereum 2.0. It is expected to operate as a hybrid with Ethereum’s existing proof-of-work system in the beginning. Casper is Byzantine fault tolerant, which means consensus can be reached even if some nodes are unreliable and there is accountability, so misbehaving validators are penalized by their staked balance. As long as two-thirds of the staked validators reach consensus, the chain can be validated.
Fork choice rule
A rule that will help validators decide which chain to follow in the event of a fork (the one whose blocks have received the most votes from validators). While the network will use something called a random number heartbeat in order to choose validators at block generation, fork choice is another protection mechanism. An attacker would need to be able to modify the fork choice rule somehow to be effective.
Deposit contract
The contract that will hold balances for the beacon chain. It will exist on the Ethereum 1.0 network. The ETH in this contract will not be able to be used on the 1.0 network once it is deposited. The minimum deposit required to become a validator is 32 ETH. As with most proof-of-stake systems, there will be some kind of financial reward for acting as a validator, the calculation of which is not yet set.
Honest validator framework
A set of standards validators are expected to abide by in order to help secure the Ethereum 2.0 network. These include having an available private key for signing proposed blocks and for miscellaneous voting (the signing key, stored in a hot wallet) and a separate private key for withdrawing funds generated by being an active validator, which should be securely stored offline (the withdrawal key). The corresponding public keys are registered as part of the transaction with the validator deposit contract.
Note

It may take years for the transition from Ethereum 1.0 to 2.0 to be completed. For example, the execution environment for dapps is not part of the initial phase of Ethereum 2.0, so mainnet Ethereum 1.0 will remain an active developer platform for years to come.

Sharding in the network will result in an increase in gas costs and will remove the ability for atomic transactions, or the ability to make transactions all at one. This will increase the likelihood of Ethereum 2.0 becoming more of a software platform than a financial one used by traders.

Privacy

Privacy is expected to be one of the biggest growth areas for blockchain technology in the coming years. Developers and other stakeholders are realizing the need to not publicly transmit all data about transactions. Here are a few privacy-related projects that are in the works:

Secret Network
Originally an MIT-based project called Enigma, Secret Network is a type of peer-to-peer network enabling computation of data in private. A blockchain manages access control and identities, with the ERC-20 SCRT token used to compensate “secret nodes” for providing computing power to the network. This allows users to share data while keeping it private using cryptography, removing the need for a third party to store information for users (which can be susceptible to breaches).
Schnorr
A form of digital signature, the Schnorr algorithm enables simple, efficient, and short signatures. This will allow for several signatures in a transaction to be combined into one, which can obscure some data. For example, multisignature transactions can look the same as regular transactions. It also enables a cryptographic technique called “tweaking,” which makes it possible to use Taproot (discussed next). Bitcoin is expected to soft fork in order to enable Schnorr signatures.
Taproot
One of the interesting things that can be done with Schnorr key pairs is to use the Taproot scheme for signing transaction scripts. Taproot utilizes Merkelized Abstract Syntax Trees (MAST), a data structure that allows some script information to remain obscured. This is done with a Merkle tree that encodes several different paths of script logic flow.