21

Scalability and Other Challenges

This chapter aims to explore various challenges that need to be addressed before blockchain can become a mainstream technology. Despite the fact that multiple use cases and Proof of Concept (PoC) systems have been developed, and that the technology works well for many scenarios, there still is a need to address some fundamental limitations that are present in blockchains to make the technology more adoptable.

At the top of the list of these issues comes scalability and then privacy, both of which are significant limitations. The lack of scalability is a general concern, where blockchains do not meet the adequate performance levels expected by users when the chain is used on a large scale. Privacy is also of utmost importance, especially as blockchains are envisioned to be used in privacy-demanding industries. There are specific requirements around the confidentiality of transactions in the finance, law, and health industries, for example. These two issues are becoming inhibiting factors toward blockchain technology's broader acceptance. A review of currently proposed and ongoing research in these two specific areas will be presented throughout this chapter.

In addition to scalability and privacy, other challenges facing blockchain include regulation, integration, interoperability, adaptability, and security in general. Although in blockchains generally, security is quite good—for example, Bitcoin has stood the test of time and is still extremely secure—there still are some caveats that may allow security to be compromised. Moreover, there are some reasonable security concerns in other blockchains such as Ethereum, regarding smart contracts, denial of service (DoS) attacks, and a large attack surface. All of these will be discussed in detail in the following sections, which are as follows:

• Scalability
• Privacy
• Security
• Other challenges

Now, we'll start with scalability, one of blockchain's biggest challenges.

Scalability

This problem has been a focus of intense debate, rigorous research, and media attention for the last few years.

This is the single most important problem in blockchain, which could mean the difference between the wider adaptability of blockchains or limited private use only by consortiums. As a result of substantial research in this area, many solutions have been proposed, which are discussed in the following section.

From a theoretical perspective, the general approach toward tackling the scalability issue generally revolves around protocol-level enhancements. For example, a commonly mentioned solution to Bitcoin scalability is to increase its block size. This would mean that a larger number of transactions can be batched in a block, resulting in increasing scalability.

Other proposals include solutions that offload certain processing to off-chain networks; for example, off-chain state networks.

Based on the aforementioned solutions, generally, the proposals can be divided into two categories: on-chain solutions, which are based on the idea of changing fundamental protocols on which the blockchain operates, and off-chain solutions, which make use of network and processing resources off-chain in order to enhance the blockchain.

Now, we'll introduce an approach that has been proposed to view blockchains as being composed of different planes. We'll then address each plane separately to develop an overall scalability solution.

Blockchain planes

Another approach to addressing limitations in blockchains has been proposed by Andrew Miller et al. and others in their position paper On Scaling Decentralized Blockchains (available at https://doi.org/10.1007/978-3-662-53357-4_8) In this paper, it is shown that a blockchain can be divided into various abstract layers called planes. Each plane is responsible for performing specific functions. These include the network plane, consensus plane, storage plane, view plane, and side plane. This abstraction allows limitations at each plane to be addressed individually and in a structured manner, which then results in an overall scalability solution. A brief overview of each layer is given in the following subsections with some references to the Bitcoin system.

Network plane

First, we'll discuss the network plane. The paper On Scaling Decentralized Blockchains mentioned previously identifies that, in Bitcoin, the network plane underutilizes network bandwidth in regards to transaction propagation, which is one of its key functions. This limitation transpires due to the way the Bitcoin protocol effectively duplicates transaction broadcasts. First, local transaction validation occurs, where the protocol propagates all transactions. Then, after mining, block propagation occurs, which contains previously disseminated transactions again.

Consensus plane

The second layer is called the consensus plane. This layer is responsible for mining and achieving consensus. Bottlenecks in this layer revolve around limitations in Proof of Work (PoW) algorithms, whereby increasing consensus speed and bandwidth results in compromising the security of the network due to an increase in the number of forks.

Storage plane

The storage plane is the third layer, which stores the ledger. Issues in this layer revolve around the need for each node to keep a copy of the entire ledger, which leads to certain inefficiencies, such as increased bandwidth and storage requirements. Bitcoin has a method available called pruning, which allows a node to operate without the need to keep the full blockchain in its storage. Pruning means that when a Bitcoin node has downloaded the blockchain and validated it, it deletes the old data that it has already validated. This saves storage space. This functionality has resulted in major improvements from a storage perspective.

View plane

Next on the list is the view plane, which proposes an optimization based on the proposal that Bitcoin miners do not need the full blockchain to operate, and that a view can be constructed out of the complete ledger as a representation of the entire state of the system, which is sufficient for miners to function. Implementation of views will eliminate the need for mining nodes to store the full blockchain.

Side plane

Finally, there's the side plane, which represents the idea of off-chain transactions. This is the process whereby the concept of payment or transaction channels is used to offload the processing of transactions between participants. However, it is still backed by the main Bitcoin blockchain.

Clearly, this plane-based model can be used to describe limitations and improvements in current blockchain designs in a targeted, structured manner.

Also, there are several other general strategies that have been proposed over the last few years that can address the limitations in current blockchain designs, such as Ethereum and Bitcoin. These approaches will be characterized and discussed individually in the following section.

Methods for improving scalability

As this is a very active area of research, over the years many techniques and proposals have been made to address the blockchain scalability problem. In this section, we'll introduce many of these techniques.

We can divide approaches to solving scalability issues into three main categories based on the layer in the blockchain stack they operate on.

We describe these categories here:

• Layer 0 methods, or network layer methods, where the mechanisms to improve scalability operate at the network level of the blockchain architecture stack.
• Layer 1 methods are also called on-chain methods, where the blockchain protocol itself is enhanced to improve scalability. This layer represents the blockchain itself.
• Layer 2 methods, or off-chain methods, where mechanisms that are not part of the blockchain and exist outside of the main blockchain are used to improve the scalability of the blockchain.

Scalability has two facets. One is increasing the processing speed of transactions, and the other is the increase in the number of nodes on the network. Both are desirable in many situations; however, speed of transactions is more sought after on public networks.

Layer 0 – network solutions

We'll describe some of the Layer 0, or network layer, solutions in the following sections.

Kadcast

This is a new protocol that enables fast, efficient, and secure block propagation for the Bitcoin blockchain network.

bloXroute

Another network layer solution is bloXroute, which aims to address scalability problems by creating a trust-less blockchain distribution network.

Next, let's move on to some core on-chain solutions, or Layer 1 solutions.

Layer 1 – on-chain solutions

In this section, we'll describe Layer 1, or on-chain, solutions, which target core blockchain elements such as blocks, transactions, and other on-chain data structures to address the scalability problem.

Transaction parallelization

Usually, in blockchain designs, transactions are executed sequentially. For example, in Ethereum, all transaction execution is sequential, which allows it to be safe and consistent. This also raises a question that if, somehow, transaction executions can be done in parallel, without compromising the consistency and security of the blockchain, it would result in much better performance.

Some suggestions have already been made for Ethereum, for example:

• Easy parallelizability, which introduces a new type of transaction: https://github.com/ethereum/EIPs/issues/648.
• Transaction parallelizability in Ethereum, which proposes a mechanism to enable parallel transaction execution in Ethereum. The paper is available here: https://arxiv.org/pdf/1901.09942.pdf.

However, at the time of writing, none of these ideas are production-ready. Currently, Hyperledger Sawtooth is to be the only blockchain that supports parallel transactions and is ready to be used in production. We discussed Sawtooth in detail in Chapter 17, Hyperledger.

Increase in block size

This is the most debated proposal for increasing blockchain performance (transaction processing throughput). Currently, Bitcoin can process only about three to seven transactions per second, which is a major inhibiting factor in adapting the Bitcoin blockchain for processing microtransactions. Block size in Bitcoin is hardcoded to be 1 MB, but if the block size is increased, it can hold more transactions and can result in faster confirmation time. There are several Bitcoin Improvement Proposals (BIPs) made in favor of block size increase. These include BIP 100, BIP 101, BIP 102, BIP 103, and BIP 109.

In Ethereum, the block size is not limited by hardcoding; instead, it is controlled by a gas limit. In theory, there is no limit on the size of a block in Ethereum because it's dependent on the amount of gas, which can increase over time. This is possible because miners are allowed to increase the gas limit for subsequent blocks if the limit has been reached in the previous block. Bitcoin Segregated Witness (SegWit) has addressed this issue by separating witness data from transaction data, which resulted in more space for transactions. Other proposals for Bitcoin include Bitcoin Unlimited, Bitcoin XT, and Bitcoin Cash. You can refer to Chapter 6, Introducing Bitcoin, for more details.

Block interval reduction

This is another proposal about reducing the time between each block generation. The time between blocks can be decreased to achieve faster finalization of blocks, but it may result in less security due to the increased number of forks. Ethereum has achieved a block time of approximately 14 seconds.

This is a significant improvement from the Bitcoin blockchain, which takes 10 minutes to generate a new block. In Ethereum, the issue of high orphaned blocks resulting from smaller times between blocks is mitigated by using the Greedy Heaviest Observed Subtree (GHOST) protocol, whereby orphaned or stale blocks (also called uncles in the Ethereum chain) are also included in determining the valid chain. Once Ethereum moves to Proof of Stake (PoS), this will become irrelevant as no mining will be required and almost immediate finality of transactions can be achieved.

Invertible Bloom Lookup Tables

This is another approach that has been proposed to reduce the amount of data required to be transferred between the Bitcoin nodes. Invertible Bloom Lookup Tables (IBLTs) were originally proposed by Gavin Andresen, and the key attraction in this approach is that it does not result in a hard fork of Bitcoin if implemented. The key idea is based on the fact that there is no need to transfer all transactions between nodes; instead, only those that are not already available in the transaction pool of the syncing node are transferred. This allows quicker transaction pool synchronization between nodes, thus increasing the overall scalability and speed of the Bitcoin network.

Sharding

Sharding is not a new technique and has been used in distributed databases for scalability, such as MongoDB and MySQL. The key idea behind sharding is to split up the tasks into multiple chunks that are then processed by multiple nodes. This results in improved throughput and reduced storage requirements. In blockchains, a similar scheme is employed, whereby the state of the network is partitioned into multiple shards. The state usually includes balances, code, nonce, and storage. Shards are loosely coupled partitions of a blockchain that run on the same network. There are a few challenges related to inter-shard communication and consensus on the history of each shard. This is an open area of research and has been extensively studied in the context of Ethereum 2.0.

Private blockchains

Most private blockchains are inherently faster because no real decentralization is required and participants on the network do not need to mine using PoW; instead, they can only validate transactions. This can be considered as a workaround to the scalability issue in public blockchains; however, this is not the solution to the scalability problem. Also, it should be noted that private blockchains are only suitable in specific areas and setups such as enterprise environments, where all participants are known.

Proof of Stake

PoS algorithm-based blockchains are fundamentally faster because PoS algorithms do not require the completion of time- and energy-consuming PoW. PoS was explained in detail in Chapter 5, Consensus Algorithms.

Block propagation

In addition to the preceding proposal, pipelining of block propagation has also been suggested, which is based on the idea of anticipating the availability of a block. In this scheme, the availability of a block is already announced without waiting for actual block availability, thus reducing the round-trip time between nodes. Finally, the problem of long distances between the transaction originator and nodes also contributes toward the slowdown of block propagation. It has been shown in the research conducted by Christian Decker et al. that connectivity increase can reduce propagation delay of blocks and transactions. This is possible because, if at any one time the Bitcoin node is connected to many other nodes, it can speed up the information propagation on the network.

An elegant solution to scalability issues will most likely be a combination of some or all of the aforementioned general approaches. A number of initiatives taken in order to address scalability and security issues in blockchains are now almost ready for implementation or already implemented. For example, Bitcoin SegWit is a proposal that can help massively with scalability and only needs a soft fork in order for it to be implemented. The key idea behind so-called SegWit is to separate signature data from the transactions, which resolves the transaction malleability issue and allows block size increase, thus resulting in increased throughput.

Bitcoin-NG

Another proposal, Bitcoin-NG, which is based on the idea of microblocks and leader election, has gained some attention recently. The core idea is to split blocks into two types, namely leader blocks (also called key blocks) and microblocks:

• Leader blocks: These are responsible for PoW, whereas microblocks contain actual transactions.
• Micro blocks: These do not require any PoW and are generated by the elected leader every block-generation cycle. This block-generation cycle is initiated by a leader block. The only requirement is to sign the microblocks with the elected leader's private key. The microblocks can be generated at a very high speed by the elected leader (miner), thus resulting in increased performance and transaction speed.

On the other hand, the Ethereum 2.0 Mauve Paper, written by Vitalik Buterin and presented at Ethereum Devcon2 in Shanghai, describes a different vision of a scalable blockchain.

This proposal is based on a combination of sharding and an implementation of the PoS consensus algorithm. The paper defined certain goals such as gaining efficiency via PoS, minimizing block time, and ensuring economic finality, scalability, cross-shard communication, and censorship resistance.

DAGs

DAG stands for Directed Acyclic Graph. It is seen as an alternative to blockchain technology. Blockchain is fundamentally a linked list, whereas DAG is an acyclic graph where links between nodes have only one direction. The DAG structure eliminates the need for mining and blocks, which allows parallel creation and confirmation of transactions, thus achieving high transaction throughput. One example of DAG is IOTA cryptocurrency. More information about this can be found at https://www.iota.org.

Consensus mechanisms

Traditionally, blockchains are based on PoW or PoS algorithms, which are inherently slow in terms of performance. Especially PoW is able to process only a few transactions per second. If a different consensus mechanism such as Raft or PBFT is used, then the professing speed can increase significantly. We examined these concepts in Chapter 5, Consensus Algorithms in greater detail.

So far, we have discussed Layer 0 (network-based solutions) and Layer 1 (on-chain solutions) to the scalability issue. In the next section, we'll introduce another approach that aims to solve the scalability problem by using off-chain or Layer 2 components.

Layer 2 – off-chain and multichain solutions

Layer 2 solutions are based on the idea that instead of modifying the main chain to achieve scalability, the objective should be to offload some of the processing to faster mechanisms outside of the main underlying chain, do processing there, and then write the result back on the main chain as an integrity guarantee. Several such techniques are described here.

State channels

This is another approach proposed for speeding up the transaction on a blockchain network. The basic idea is to use side channels for state updating and processing transactions off the main chain; once the state is finalized, it is written back to the main chain, thus offloading the time-consuming operations from the main blockchain.

State channels work by performing the following three steps:

1. First, a part of the blockchain state is locked under a smart contract, ensuring the agreement and business logic between participants.
2. Now, off-chain transaction processing and interaction is started between the participants that update the state (only between themselves for now). In this step, almost any number of transactions can be performed without requiring the blockchain. This is what makes the process so fast and arguably the best candidate for solving blockchain scalability issues. It could be argued that this is not a real on-blockchain solution such as, for example, sharding, but the end result is a faster, lighter, and more robust network that can prove very useful in micropayment networks, IoT networks, and many other applications.
3. Once the final state is achieved, the state channel is closed, and the final state is written back to the main blockchain. At this stage, the locked part of the blockchain is also unlocked.

This process is shown in the following diagram:

Figure 21.1: State channels

This technique has been used in the Bitcoin Lightning network and Ethereum's Raiden. The key difference between Lightning and Raiden is that Lightning only works for Bitcoin transactions, whereas Raiden supports all ERC20-compliant tokens, making the Raiden network a more flexible option.

Sidechains

Sidechains can improve scalability indirectly by allowing many sidechains to run along with the main blockchain, while allowing usage of perhaps comparatively less secure and faster sidechains to perform transactions but that are still pegged with the main blockchain. The core idea of sidechains is called a two-way peg, which allows the transferal of coins from a parent chain to a sidechain and vice versa.

Sub-chains

This is a relatively new technique recently proposed by Peter R. Rizun and is based on the idea of weak blocks, which are created in layers until a strong block is found.

Weak blocks can be defined as those blocks that have not been able to be mined by meeting the standard network difficulty criteria, but have done enough work to meet another weaker difficulty target. Miners can build sub-chains by layering weak blocks on top of each other, unless a block is found that meets the standard difficulty target.

At this point, the sub-chain is closed and becomes the strong block. Advantages of this approach include reduced waiting time for the first verification of a transaction. This technique also results in a reduced chance of orphaning blocks and a speeding up of transaction processing. This is also an indirect way of addressing the scalability issue. Sub-chains do not require any soft fork or hard fork to implement but need acceptance by the community.

Tree chains

There are also other proposals to increase Bitcoin scalability, such as tree chains, which change the blockchain layout from a linearly sequential model to a tree. This tree is basically a binary tree that descends from the main Bitcoin chain. This approach is similar to sidechain implementation, eliminating the need for major protocol change or block size increase. It allows improved transaction throughput. In this scheme, the blockchains themselves are fragmented and distributed across the network in order to achieve scalability.

Moreover, mining is not required to validate the blocks on the tree chains; instead, users can independently verify the block header. However, this idea is not ready for production yet and further research is required in order to make it practical.

In addition to the aforementioned general techniques, some Bitcoin-specific improvements have also been proposed by Christian Decker (much of Decker's work can be found here: https://scholar.google.ch/citations?user=ZaeGlZIAAAAJ&hl=en) in his book On the scalability and security of Bitcoin. This proposal is based on the idea of speeding up propagation time as the current information propagation mechanism results in blockchain forks. These techniques include minimization of verification, pipelining of block propagation, and connectivity increase. These changes do not require fundamental protocol-level changes; instead, these changes can be implemented independently in the Bitcoin node software.

With regards to verification minimization, it has been noted that the block verification process is contributing toward propagation delay. The reason behind this is that a node takes a long time to verify the uniqueness of the block and transactions within the block. It has been suggested that a node can send the inventory message as soon as the initial PoW and block validation checks are completed. This way, propagation can be improved by just performing the first difficulty check and not waiting for transaction validation to finish.

Plasma

Another recent scalability proposal is Plasma, which has been proposed by Joseph Poon and Vitalik Buterin. This proposal describes the idea of running smart contracts on the root blockchain (Ethereum mainnet), and having child blockchains that perform high numbers of transactions, to feedback small amounts of commitments to the parent chain. In this scheme, blockchains are arranged in a tree hierarchy with mining performed only on the root (main) blockchain, which feeds the proofs of security down to child chains. This is also a Layer 2 system since, like state channels, Plasma also operates off-chain.

Commit chains

Commit chains are a more generic term for Vitalik Buterin's Plasma proposal. They are also referred to as non-custodial side chains but without a new consensus mechanism, as is the case with sidechains. They rely on main chain consensus mechanism, so they can be considered as safe as the main chain. The operator of the commit chain is responsible for facilitating communication between transacting participants and sending regular updates to the main chain.

Zk-Rollups

Zk-Rollups is a Layer 2 solution that allows multiple transactions to be bundled into a single transaction. This approach enables mass transfer processing using a single transaction, which improves scalability.

Trusted hardware-assisted scalability

This technique is based on the idea that complex and heavy computing can be offloaded to off-chain resources in a verifiably secure manner. Once the computations are complete, the verified results are sent back to the blockchain.

Other scalability techniques include multichain approaches. One of the prime examples of such techniques is Polkadot, which we'll describe briefly later in this chapter in the context of interoperability. However, this mechanism also provides scalability.

With this, we have completed our discussion of some of the many potential scalability improvements of blockchain. In the next section, we'll discuss privacy and some relevant techniques to achieve privacy in blockchain.

Privacy

Privacy in blockchain can be divided into two main categories based on the type of service required. These categories are the anonymity of the users and the confidentiality of the transactions. Anonymity is concerned with hiding the sender's or receiver's identity, whereas confidentiality addresses the requirements of hiding transaction values.

Anonymity

Anonymity is desirable in situations where the identity of users is required to be hidden from other participants on the network. This can be due to regulatory requirements, enterprise requirements, or just due to the sensitive nature of the transactions. For example, in a business network, it might be desirable to hide the dealings between different participants on the network from other competitors to avoid friction or unjustified business competitive advantage. The properties of unlinkability and untraceability are used to achieve anonymity.

The property of untraceability allows for the hiding of the trace of a transaction from one party to another. On the other hand, unlinkability means that an observer is unable to deduce the link between transactions and its participants, or the relationships between transaction participants (senders and receivers). We also discussed anonymity in Chapter 9, Alternative Coins, in greater detail.

Confidentiality

Confidentiality is an absolute requirement in many industries such as finance, law, and health. Similarly, privacy of transactions is a much-desired property of blockchains. However, due to its very nature, especially in public blockchains, everything is transparent, thus inhibiting its usage in various industries where privacy is of paramount importance, such as finance, health, and many others.

There are different proposals that have been made to address the privacy issue and some progress has already been made. Several techniques, such as indistinguishability obfuscation, homomorphic encryption, zero-knowledge proofs (ZKPs), and ring signatures, have all been researched and implemented. All of these techniques have their merits and demerits and will be discussed in the following sections.

Techniques to achieve privacy

In this section, we'll describe different techniques to achieve privacy, including anonymity and confidentiality.

Similar to scalability solutions, we can also divide privacy solutions into three categories, based on the layer within the blockchain architecture stack that they operate:

• Layer 0 methods, or network layer methods, where the mechanism to achieve privacy operates at a network level.
• Layer 1 methods, also called on-chain methods, where the blockchain protocol itself is enhanced to achieve privacy.
• Layer 2 methods, or off-chain methods, where mechanisms that exist outside of the main blockchain are used to achieve privacy on the blockchain.

As many of the techniques described in the following sections can be used at Layers 1 and 2—for example, zero-knowledge proofs—we are not distinguishing between these layers. Instead, we'll only list these solutions and discuss what they can be used for. Furthermore, solutions for anonymity and confidentiality also overlap and techniques used to achieve confidentiality are also more or less applicable in achieving anonymity. We do, however, segregate Layer 0, the network layer, and describe some of the network approaches to achieve anonymity, before moving on to introduce a range of privacy mechanisms that are applicable at Layers 1 and 2.

Layer 0

These solutions are network layer-level methods that provide anonymity by using TOR and I2P. These methods allow for hiding the identities of the parties involved.

Tor

Tor, the Onion Router, is a software that enables anonymous communications. More information on Tor is available here: https://www.torproject.org. We can use Tor to enable anonymous communication in cryptocurrency blockchain networks. Tor is a common choice to enable anonymous communication and has been used in Monero, Verge and in Bitcoin to provide anonymity.

For Bitcoin, see https://en.bitcoin.it/wiki/Tor. Monero can also be run with Tor (https://web.getmonero.org/). Verge is another example of cryptocurrency making use of Tor for IP obfuscation.

I2P

I2P, Invisible Internet Project, is an anonymous network built on the internet. It enables censorship-resistant peer-to-peer communication. It is used in Monero to provide anonymity services. More information on I2P is available here: https://geti2p.net/en/.

Layers 1 and 2

Other layers include Layer 1 and Layer 2 solutions, which we'll introduce next.

Indistinguishability obfuscation

This cryptographic technique may serve as a silver bullet to all privacy and confidentiality issues in blockchains, but the technology is not yet ready for production deployments. Indistinguishable obfuscation (IO) allows for code obfuscation, which is a very ripe research topic in cryptography. If applied to blockchains, IO can serve as an unbreakable obfuscation mechanism that will turn smart contracts into a black box where the behavior of the obfuscated code is indistinguishable. In simpler words, the inner functionality of the smart contract is totally hidden.

The key idea behind IO is what's called by researchers a multilinear jigsaw puzzle, which basically obfuscates program code by mixing it with random elements, and if the program is run as intended, it will produce the expected output. However, any other way of executing it would make the program look like random garbage data. This idea was first proposed by Sanjam Garg et al. in their research paper Candidate Indistinguishability Obfuscation and Functional Encryption for All Circuits.

Homomorphic encryption

This type of encryption allows operations to be performed on encrypted data. Imagine a scenario where the data is sent to a cloud server for processing. The server processes it and returns the output without knowing anything about the data that it has processed. This is also an area ripe for research and fully homomorphic encryption, which allows all operations on encrypted data, is still not fully deployable in production; however, major progress in this field has already been made. Once implemented on blockchains, it can allow processing on ciphertext, which will allow the privacy and confidentiality of transactions inherently.

For example, the data stored on the blockchain can be encrypted using homomorphic encryption, and computations can be performed on that data without the need for decryption, thus providing privacy service on blockchains. This concept has also been implemented in a project named Enigma, which is available online at https://www.media.mit.edu/projects/enigma/overview/, by MIT's Media Lab. Enigma is a peer-to-peer network that allows multiple parties to perform computations on encrypted data without revealing anything about the data.

Zero-knowledge proofs

ZKPs have recently been implemented in Zcash successfully, as seen in Chapter 9, Alternative Coins. More specifically, Succinct Non-Interactive Argument of Knowledge (SNARKs) have been implemented in order to ensure privacy on the blockchain.

The same idea can be implemented in Ethereum and other blockchains also. Integrating Zcash on Ethereum is already a very active research project being run by the Ethereum Research & Development team and the Zcash company.

There is a recent addition to the family of ZKPs called zero-knowledge Succinct Transparent Argument of Knowledge (zk-STARK), which is an improvement on zk-SNARKs in the sense that zk-STARKs consume a lot less bandwidth and storage. Also, they do not require the initial, somewhat controversial, trusted setup that is required for zk-SNARKs. Moreover, zk-STARKs are much quicker as they do not make use of elliptic curves or rely on hashes.

Bulletproofs are non-interactive zero-knowledge short proofs. They require no trusted setup. This scheme allows a prover to prove that an encrypted number is within a range of numbers without revealing any other information about the number.

State channels

Privacy using state channels is also possible, simply due to the fact that all transactions are run off-chain, and the main blockchain does not see the transaction at all except for the final state output, which ensures privacy and confidentiality.

Secure multiparty computation

The concept of secure multiparty computation is not new and is based on the notion that data is split into multiple partitions between participating parties, under a secret sharing mechanism, which then does the actual processing on the data without the need to reconstruct data on a single machine.

The output produced after processing is also shared between the parties. Multiple parties carry out the computation mutually without revealing their inputs. Only the output of the computation is revealed.

Trusted hardware-assisted confidentiality

Trusted computing platforms can be used to provide a mechanism by which confidentiality of a transaction can be achieved on a blockchain, for example, by using Intel Software Guard Extension (SGX), which allows code to be run in a hardware-protected environment called an enclave. Once the code runs successfully in the isolated enclave, it can produce a proof, called a quote, which is attestable by Intel's cloud servers.

It is a concern that trusting Intel will result in some level of centralization and is not in line with the true spirit of blockchain technology. Nevertheless, this solution has its merits and, in reality, many platforms already use Intel chips anyway, so trusting Intel may be acceptable by some in some cases.

If this technology is applied to smart contracts, then once a node has executed the smart contract, it can produce a proof of correctness, thus proving successful execution, and other nodes will only have to verify it. This idea can be further extended by using any Trusted Execution Environment (TEE), which can provide the same functionality as an enclave and is available even on mobile devices with Near Field Communication (NFC) and a secure element.

For example, Ekiden is a platform that makes use of Intel SGX's TEE to run smart contracts while preserving confidentiality.

CoinJoin

CoinJoin is a technique that is used to anonymize Bitcoin transactions by mixing them interactively. The idea is based on forming a single transaction from multiple entities without causing any change in inputs and outputs. It removes the direct link between senders and receivers, which means that a single address can no longer be associated with transactions, which could lead to the identification of users.

CoinJoin needs to cooperate between multiple parties that are willing to create a single transaction by mixing payments. Therefore, it should be noted that, if any single participant in the CoinJoin scheme does not keep up with the commitment made to cooperate for creating a single transaction, by not signing the transactions as required, then it can result in a DoS attack.

In this protocol, there is no need for a single trusted third party. This concept is different from mixing a service, which acts as a trusted third party or intermediary between the Bitcoin users and allows shuffling of transactions. This shuffling of transactions results in the prevention of tracing and linking payments to a particular user.

Confidential transactions

Confidential transactions make use of Pedersen commitments in order to provide confidentiality. Commitment schemes allow a user to commit to some value while keeping it secret with the capability of revealing it later. Commitment schemes can be constructed simply by using cryptographic hash functions. Two properties that need to be satisfied in order to design a commitment scheme are binding and hiding.

Binding makes sure that the committer is unable to change the chosen value once committed, whereas the hiding property ensures that any adversary is unable to find the original value to which the committer made a commitment.

A Pedersen commitment is a type of information hiding, computationally-binding commitment scheme, under a discrete logarithm assumption. Pedersen commitments allow for additional operations and preserve commutative property on the commitments, which make them particularly useful for providing confidentiality in Bitcoin transactions. In other words, they support partial homomorphic encryption of values, meaning that using commitment schemes allows the hiding of payment values in a Bitcoin transaction.

MimbleWimble

The MimbleWimble scheme was proposed somewhat mysteriously on the Bitcoin IRC channel and since then has gained a lot of popularity. MimbleWimble extends the idea of confidential transactions and CoinJoin, which allow the aggregation of transactions without requiring any interactivity. However, it does not support the use of the Bitcoin scripting language, along with various other features of the standard Bitcoin protocol. This makes it incompatible with the existing Bitcoin protocol. Therefore, it can either be implemented as a sidechain to Bitcoin or on its own as an alternative cryptocurrency.

This scheme can address both privacy and scalability issues at once. The blocks created using the MimbleWimble technique do not contain transactions as in traditional Bitcoin blockchains; instead, these blocks are composed of three lists: an input list, an output list, and something called excesses, which are lists of signatures and differences between outputs and inputs. The input list basically references the old outputs, and the output list contains confidential transactions outputs.

The blocks created using the MimbleWimble scheme are verifiable by nodes by using signatures, inputs, and outputs to ensure the legitimacy of the block. In contrast to Bitcoin, MimbleWimble transaction outputs only contain pubkeys, and the difference between old and new outputs is signed by all participants involved in the transactions.

Mixing protocols

A mixing protocol, or mixer, is a service that allows users to preserve their privacy by mixing their coins with other users. We discussed mixers in detail in Chapter 9, Alternative Coins.

Attribute-based encryption

The attribute-based encryption (ABE) is a type of public key cryptography that provides confidentiality and access control simultaneously. The key idea behind this scheme is that the private key of a user and its ciphertext are dependent on the user's attributes such as their location, time zone, or their role in the organization. This means that the decryption is only possible when not only the private key is available but also the matching attributes are present.

Anonymous signatures

Anonymous signatures are types of digital signatures where the signatures do not reveal the identity of the signer. There are primarily two schemes available for anonymous signatures: group signatures and ring signatures.

Group signatures allow a set of signers to form a group managed by a group manager. Each member of the group is issued with a group signing key by the group manager. This group signing key allows each member of the group to anonymously sign messages on behalf of the group. The group manager is able to figure out who is the signer of the message, whereas external entities cannot. While group signatures can work well, one of the limitations of this scheme is that the group manager is able to identify the users. This issue was addressed with ring signatures.

Ring signatures allows a set of signers to form a group (a ring) of members. Each member in this group is able to sign messages on behalf of the ring. Unlike group signatures, there is no group manager in ring signatures, so no one is able to identify the signers.

While all these techniques are useful and provide many desirable properties of anonymity, there is also a problem of using this technology maliciously. Imagine if anonymity is misused by criminals involved in money laundering or selling illegal drugs by using anonymous cryptocurrency. It would be almost impossible to trace illegal activities back to the originator if absolute anonymity is achieved. Imagine a Silk Road marketplace (https://en.wikipedia.org/wiki/Silk_Road_(marketplace)) variant using anonymous cryptocurrency. How could that be traced and stopped?

Privacy managers

Privacy managers provide a mechanism that provides confidentiality of transactions. These are off-chain components that substitute the transaction payload with a hash index, in such a way that only those participants who are party to the transaction are able to find the corresponding encrypted payload represented by the hash index. Other parties who are not privy to the transaction will simply ignore the hash. This concept was discussed in Chapter 20, Enterprise Blockchains.

We can visualize many of the blockchain privacy techniques discussed so far in this chapter using the following chart:

Figure 21.2: High-level taxonomy of blockchain privacy techniques

Other than scalability and privacy, there are several other general security aspects that need to be addressed in blockchain. We'll describe these general security topics next.

Security

Blockchains are generally secure and make use of asymmetric and symmetric cryptography, as required throughout the blockchain network, to ensure that the core layer of the blockchain is secure. However, there still are few caveats that can result in compromising the security of the blockchain.

There are a few examples of transaction malleability, eclipse attacks, and the possibility of double-spending in Bitcoin that, in certain scenarios, have been shown to work by various researchers. Transaction malleability opens up the possibility of double withdrawal or deposit by allowing a hacker to change a transaction's unique ID before the Bitcoin network can confirm it, resulting in a scenario where it would seem that transactions did not occur. BIP 62 is one of the proposals, along with SegWit, that has suggested solutions to solve this issue. It should be noted that this is a problem only in the case of unconfirmed transactions; that is, scenarios where operational processes rely on unconfirmed transactions. In the case of normal applications that only rely on confirmed transactions, this is not an issue.

Information eclipse attacks in Bitcoin can result in double-spending. The idea behind eclipse attacks is that the Bitcoin node is tricked into connecting only with the attacker node IPs. This opens up the possibility of a 51% attack by the attacker. This has been addressed to some extent in Bitcoin client v0.10.1—more information on the attack and how it has been fixed is available here: http://cs-people.bu.edu/heilman/eclipse/.

Now, before discussing security further in blockchains, let's have a look at the interesting topic of formal verification. This is becoming a hot topic in blockchain space, due to its strong technical merits as a technique to address security issues. Note that this is not a new technique, but it has found very interesting applications in blockchain technology.

Formal verification

Before diving into different formal verification techniques that are available in blockchain space, first, let's develop some understanding of what formal verification is, what its types are, and why it is desirable.

Formal methods are the set of techniques used to model systems as mathematical objects. These methods include writing specifications in formal logic, model checking, verification, and formal proofs. Generally, formal methods can be divided into two broad disciplines called formal specifications and formal verification. The first discipline is concerned with writing precise and concrete specifications, whereas the latter encompasses the development of proofs to prove the correctness of a specification.

In essence, formal verification is comprised of three steps:

1. First, creating a formal model of the system to be checked.
2. Secondly, write a formal specification of the properties that are expected to be satisfied by our model.
3. Finally, the model is checked to ensure that the model satisfies the specification.

For checking, there are two broad categories of techniques that can be used, namely state exploration-based approaches and proof-based approaches. There are pros and cons to both:

• State exploration-based approaches are automatic but are inefficient and difficult to scale. A usual problem is state explosion, where the number of states to check grow so exponentially big that the model does not fit in a computer's memory.
• On the other hand, proof-based approaches (theorem proving) are more precise but usually require human interaction and more in-depth knowledge of the proofs and relevant techniques.

In the next section, we'll introduce a formal verification technique called model checking, which is used to check a system model for its correctness.

Model checking

Model checking can be defined as a technique used to verify finite state systems automatically. The underlying process is based on running an exhaustive search of the state space of the system. With this brute-force approach, it can be determined whether a specification is true or false. This option is becoming more popular because it does not require time-consuming proof-writing.

Instead, this paradigm allows a designer to write the specification formally, and its properties and the model checker will automatically explore the entire state space and evaluate the model against the specified properties. For example, if the specification says that a particular state should never be reached and during state exploration, the model checker finds that there is an execution (trace) that does enter that very state that is undesirable, then it will report that. The designer can then address the problem accordingly.

A visual representation of the model checking process is shown in the following diagram:

Figure 21.3: Model checking

The process of model checking starts with modeling, where a formal specification is created from an informal design of the model. The specification step comes next, where relevant properties of the design are specified using some logical formalism. Finally, verification of the model is carried out, which checks all the properties defined in the specification and provides results. In the case of false or negative outcomes, error traces with counterexamples (roughly defined as exceptions) are provided to help the designer trace the error.

Mathematical assertion languages called temporal logics are used to describe states of a system over time. Temporal logic is used at the specification step of the model checking process, which represents the evolution of the behavior of a system over time, or in this case, the ordering of events of a system over time. In this paradigm, a specification of the behaviors of the system over time is built using various fundamental properties of individual states.

For example, in a state, it can be said that "something is on" or "something is active." There are also propositional connectors used in the specification's design, such as AND , OR , NOT , and IMPLY . We will use these connectors in some basic examples shortly to demonstrate how they can be used in conjunction with formulas to describe system properties.

Finally, there are also temporal connectives, which issue statements like "the system can always only have one process active", or "the system can never be in a state where both read and write operations are performed simultaneously."

There are two types of temporal logics, namely Linear Temporal logic (LTL) and Computation tree logic (CTL). LTL is concerned with the model properties on a single computation path or execution, whereas CTL is used to express properties over a tree of all possible paths.

There are a few fundamental temporal operators used in LTL to describe a system's behavior. These properties can be used to specify the safety and liveness properties of a system. The formulas are P (always), P (eventually), U (Until), and (Next). The always and eventually properties are most commonly used.

For example, ((Message) signed sealed) valid) means if a message is not signed or sealed, then it is always the case that the message is not valid. Another example could be ((broadcast) received), meaning that broadcast always implies that eventually the message will be received. Another general example could be that of a microwave oven ensuring that heating must not start until the door is closed, which can be represented in temporal logic as Startheating U Door(closed).

Formal methods are needed to ensure the safety of a system and have been in use in the avionics, electronics, hardware, and embedded systems industries for quite some time and, most lately, in the software industry. Due to renewed interest in distributed systems research with the advent of blockchain, and several high-profile incidents resulting in financial loss, such as the infamous DAO hack, the need to use formal methods in the blockchain space is becoming increasingly prominent. Some initiatives have already taken place; however, there is still a long way to go.

Blockchain needs to leverage on the research that has already been done in distributed systems and formal verification space, so that not only can existing blockchain systems be made safer, but new platforms can be developed based on formal specification. It should be noted that not all aspects of a blockchain need to, or should be, formally verified, due to the time-consuming and highly involved nature of the verification process. Therefore, at times, it is sufficient to model and test the most critical parts of a blockchain, such as consensus and security protocols.

There are many dimensions in a blockchain where model checking and specification using temporal logics can be quite useful. It can be used to describe an aspect of the blockchain platform formally, which can then be verified formally to ensure that all required properties are met. For example, in smart contract development, regardless of the language used, a model could be developed and checked before the actual coding of the smart contract. This approach will ensure that the program code, if programmed correctly according to the verified specification, will behave as it is intended. As smart contracts are used in all kinds of critical use cases, including financial transactions, it is advisable to apply model checking in this domain to ensure fairness and security of the system.

Now, we'll briefly look at how consensus mechanisms can be verified.

Verifying consensus mechanisms

From another angle, a consensus mechanism, such as PBFT, exists in a blockchain, which ensures that all the nodes in a blockchain network reach an agreement on the proposed values, even in the presence of faulty nodes.

This is an area of prime importance and due to its critical nature is regarded as the most vital core mechanism of a blockchain. Model checking can play a crucial role in the formal description and verification of consensus algorithms, to ensure that the protocols meet the required security properties.

A general approach to verifying properties of a consensus algorithm in blockchain starts from specifying the requirements, required properties, and specification in a formal language.

A distributed consensus algorithm is evaluated against two categories of correctness properties, namely safety and liveness. Safety generally means that nothing bad will happen, whereas liveness implies that something good will eventually occur. Both of these properties, then, have some sub-properties, depending on the requirements. Usually, for consensus mechanisms, we have agreement, integrity, and validity attributes under safety properties and for liveness, often, termination is a desired property.

We can say that a program is correct if, in all possible executions, the program behaves correctly according to the specification. The specification is formally defined, which is then verified using a model checker or theorem provers.

Static analysis allows us to check the code against a set of coding rules to find code defects. The code does not execute; instead, it is statically checked. On the other hand, there is a dynamic analysis technique where the code is executed to find bugs and tested against test criteria. Dynamic analysis usually constitutes unit tests and is not considered a formal verification technique. Static analysis using formal techniques is used to formally verify the correctness of the program.

With this, we've completed our basic introduction to formal verification. Now, let's have a look at smart contract security and see what formal tools are available for smart contract security verification.

Smart contract security

Recently, a lot of work has been started in smart contract security and, especially, the formal verification of smart contracts is being discussed and researched. This was all triggered especially due to the infamous DAO hack.

Formal verification is a process of verifying a computer program to ensure that it satisfies certain formal statements. This is not a new concept and there are a number of tools available for other languages that achieve this; for example, Frama-C (https://frama-c.com) is available for analyzing C programs.

The key idea behind formal verification is to convert the source program into a set of statements that is understandable by the automated provers. For this purpose, Why3, which is a platform for program verification, is commonly used. We'll discuss Why3 at length in the Why3 topic, later in this section.

Smart contract security is of paramount importance now, and many other initiatives have also been taken in order to devise methods that can analyze Solidity programs and find bugs. A recent and seminal example is Oyente, which is a tool built by researchers to analyze smart contracts.

Several security bugs in smart contracts have been discovered and analyzed in the Oyente white paper, Making Smart Contracts Smarter. These include transaction ordering dependence, timestamp dependence, mishandled exceptions such as call stack depth limit exploitation, and reentrance vulnerability. The transaction ordering dependency bug basically exploits the scenarios where the perceived state of a contract might not be what the state of the contract changes to after execution.

This weakness is a type of race condition. It is also called frontrunning and is possible due to the fact that the order of transactions within a block can be manipulated. As all transactions first appear in the memory pool, the transactions there can be monitored before they are included in the block. This allows a transaction to be submitted before another transaction, thus leading to controlling the behavior of a smart contract.

Timestamp dependency bugs are possible in scenarios where the timestamp of the block is used as a source of some decision-making within the contract, but timestamps can be manipulated by the miners. The call stack depth limit is another bug that can be exploited due to the fact that the maximum call stack depth of EVM is 1,024 frames. If the stack depth is reached while the contract is executing, then, in certain scenarios, the send or call instruction can fail, resulting in non-payment of funds.

The reentrancy bug was exploited in the DAO attack to siphon out millions of dollars into a child DAO. The reentrancy bug essentially means that a function can be called repeatedly before the previous (first) invocation of the function has completed. This is particularly unsafe in ether withdrawal functions in Solidity smart contracts. This is because block. timestamp, the withdrawal function, can call back into it repeatedly, without waiting for the first call to complete. More on this shortly in the Oyente section.

In addition to the aforementioned bugs, there are several other problems that should be kept in mind while writing contracts, such as the fact that when sending funds to another contract, sending can fail, and even if throw is used as a catch-all mechanism, it will not work.

Timestamp dependence is another vulnerability that is quite common. Usually, the timestamp of a block is accessed via now or block.timestamp, but this timestamp can be manipulated by miners, leading to influencing the outcome of some function that relies on timestamps. Often, this is used as a source of randomness in lottery games to select the next winner. Thus, it might be possible for a miner to modify the timestamp in such a way that its chances of becoming the next winner increase.

Other usual software bugs, such as integer overflow and underflow, are also quite significant, and any use of integer variables should be carefully implemented in Solidity. For example, a simple program where uint8 is used to parse through elements of an array with more than 255 elements can result in an endless loop. This occurs because uint8 is limited to 256 numbers.

Smart contracts and, generally, all aspects of blockchain can be formally verified. In the following sections, examples of contract verification will be shown using Remix IDE, Why3, and Oyente.

Static analysis in Remix IDE

Static analysis of Solidity code is now available as a feature in the Solidity online Remix IDE. The code is analyzed for vulnerabilities and reported in the analysis tab of the Remix IDE:

Figure 21.4: Remix IDE analysis options

A sample output of a contract with reentrancy bug is shown at the bottom of the preceding screenshot.

Static analysis in Remix IDE analyzes several categories of vulnerabilities, including Security and Gas & Economy. As shown in the preceding screenshot, the analysis tool has successfully detected the reentrancy bug, details of which are shown at the bottom of the screen.

Other than static analysis capabilities within the Remix IDE, other tools are also available, such as Why3, which we'll discuss next.

Why3

Why3 can also be used for formally analyzing Solidity code.

In the following example, a simple piece of Solidity code that defines the z variable as the maximum limit of uint is being shown. When this code runs, it will result in returning 0, because uint z will overrun and start again from 0. This can also be verified using Why3, which is shown here:

Figure 21.5: Solidity online compiler with formal verification

Conversion from Solidity to Why3 compliant code used to be available in Solidity's online compiler, but it is no longer available. Therefore, the following example is only for completeness purposes and to shed light on an important class of bugs that can go undetected with traditional tools. In this example, integer overflow is shown as an example.

The following example shows that Why3 successfully checks and reports integer overflow errors. This tool is under heavy development but is still quite useful. Also, it should be noted that tool, or any other similar tool, is not a silver bullet. Even formal verification generally should not be considered a panacea. This is because specifications in the first place should be defined appropriately:

Figure 21.6: Why3 analyzing a smart contract for issues

In the preceding screenshot, the Why3 IDE is shown with a smart contract being analyzed for issues, which are reported on the right-hand side. In this case, an integer overflow has been found, which is reported.

In the next section, we'll see how a different tool, Oyente, can be used to test a smart contract for security vulnerabilities.

Oyente

Currently, Oyente is available as a Docker image for easy testing and installation. It is available at https://github.com/melonproject/oyente and can be downloaded and tested.

In the following example, a simple contract taken from the Solidity documentation that contains a reentrancy bug has been tested. First, we will show the code with a reentrancy bug:

Figure 21.7: Contract with a reentrancy bug, sourced from the Solidity documentation

This sample code contains a reentrancy bug, which basically means that if a contract is interacting with another contract or transferring ether, it is effectively handing over the control to that other contract. This allows the called contract to call back into the function of the contract from which it has been called, without waiting for completion. For example, this bug can allow calling back into the withdraw function shown in the preceding example again and again, resulting in obtaining ETH multiple times. This is possible because the share value is not set to 0 until the end of the function, which means that any later invocations will be successful, resulting in withdrawing again and again.

An example is shown of Oyente running to analyze the contract shown here and, as can be seen in the following output, the analysis has successfully found the reentrancy bug. The bug is proposed to be handled by a combination of the Checks-Effects-Interactions pattern described in the Solidity documentation:

Figure 21.8: Oyente tool detecting Solidity bugs

Oyente is also available in the analysis tools for smart contracts at https://oyente.melonport.com. A sample output is shown here:

Figure 21.9: Oyente analysis

With this example, we conclude our introduction to security and analysis tools for Solidity. This is a very rich area of research, and more and more tools are expected to be available with time.

There are many experts and researchers in academia and the commercial sector exploring this area and soon, there will be many automated tools available for the verification of smart contracts. There is an online tool available already at https://securify.ch that analyzes smart contract code to find security vulnerabilities.

Now, well discuss some other tools that we can use to analyze smart contracts for correctness and security vulnerabilities.

Other tools

Other relevant tools and research in the security arena of blockchain technology include Solgraph, Manticore, and other tools for formal verification of smart contracts.

Solgraph

This tool generates a graph of function control flow of a Solidity contract and finds possible security vulnerabilities. More information on this tool is available here: https://github.com/raineorshine/solgraph.

Manticore

This is a symbolic execution framework that can be used for binaries and smart contracts.

Symbolic execution is a method used to analyze computer programs to determine which part of the computer program executes as a result of what input. In other words, it establishes which input executes which part of the program. In symbolic execution, instead of actual input data, symbolic values are used, which are then used to evaluate the program. Also, an automated theorem prover is used to check whether there are values that results in incorrect behavior of the program or cause it to fail. It is used for debugging, software testing, and security.

Formal verification of smart contracts

A lot of research on formal verification of smart contracts have also been conducted. The proposed techniques include, but are not limited to, model checking, static analysis, dynamic analysis, and verification using proof assistants.

Some of the more relevant papers on the subject include the following:

• Nehai, Z., Piriou, P.Y. and Daumas, F., 2018, July. Model-checking of smart contracts. In 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData) (pp. 980-987). IEEE. https://hal.archives-ouvertes.fr/hal-02103511/file/Nehai-Piriou-Daumas%20V18_03_09.pdf.
• Bang, T., Nguyen, H.H., Nguyen, D., Trieu, T. and Quan, T., 2020. Verification of Ethereum Smart Contracts: A Model Checking Approach. International Journal of Machine Learning and Computing, 10(4). http://www.ijmlc.org/vol10/977-AM0059.pdf.
• Antonino, P. and Roscoe, A.W., 2020. Formalising and verifying smart contracts with Solidifier: a bounded model checker for Solidity. arXiv preprint arXiv:2002.02710. https://arxiv.org/pdf/2002.02710.
• Kalra, S., Goel, S., Dhawan, M. and Sharma, S., 2018, February. ZEUS: Analyzing Safety of Smart Contracts. In NDSS. http://pages.cpsc.ucalgary.ca/~joel.reardon/blockchain/readings/ndss2018_09-1_Kalra_paper.pdf.
• Amani, S., Bégel, M., Bortin, M. and Staples, M., 2018, January. Towards verifying Ethereum smart contract bytecode in Isabelle/HOL. In Proceedings of the 7th ACM SIGPLAN International Conference on Certified Programs and Proofs (pp. 66-77). https://dl.acm.org/doi/pdf/10.1145/3167084.
• Chen, X., Park, D. and Roşu, G., 2018, November. A language-independent approach to smart contract verification. In International Symposium on Leveraging Applications of Formal Methods (pp. 405-413). Springer, Cham. http://fsl.cs.illinois.edu/FSL/papers/2018/chen-park-rosu-2018-isola/chen-park-rosu-2018-isola-public.pdf.

After all this discussion on smart contract security, we should now understand its significance. While all the issues and techniques discussed here to mitigate the security issues in smart contracts are valuable, a question still arises about what else we can do, given that smart contract security is a sensitive topic that can result in serious financial losses. The answer could be that we treat smart contracts and the underlying blockchain as safety-critical systems, and then apply all attributes of safety-critical systems to smart contracts. From an engineering perspective, it will become a subject of safety-critical systems and will be treated as such.

This idea might sound a bit over the top, but imagine if, one day, a smart contract is responsible for generating an event that would trigger a shutdown as a result of overheating in a nuclear reactor. Again, a little exaggerated perhaps, but entirely possible: with IoT and blockchain convergence such scenarios might become a reality, where nuclear reactors are running using a blockchain as a mechanism to control and track associated operations.

Now, we'll introduce some other challenges that blockchain technology faces, which should be resolved in order to enable the mainstream adoption of blockchain.

Other challenges

In addition to key issues such as privacy and scalability, there are a few other challenges that can hinder the adoption of blockchain as a mainstream technology. We'll discuss these challenges and some possible solutions next.

Interoperability

We discussed interoperability briefly earlier in this book. It is sufficient to say here that interoperability is an open challenge and while many initiatives such as Cosmos, Polkadot, and Interledger are in progress to address this limitation, there is still a long way to go. One of the approaches is standardization of blockchain protocols, thus making them compatible with one another. Another approach is to develop protocols that will make existing blockchains interact with each other, such Interledger.

We cover Cosmos and Interledger in detail in this book's bonus content pages, here https://static.packt-cdn.com/downloads/Altcoins_Ethereum_Projects_and_More_Bonus_Content.pdf. In this section, we will briefly describe Polkadot.

Polkadot

Polkadot is a platform that allows connectivity between different private and public chains, oracles, and many other technologies. It is a platform used to enable Web3, a decentralized web, and allows any type of data to be exchanged between any type of blockchain. It offers heterogenous sharding, scalability, upgradability, transparent governance, and cross-chain composability.

The key concept behind Polkadot is a relay chain, which is responsible for cross-chain interoperability, consensus, and overall network security. Polkadot allows communication between different independent blockchain shards called parachains. Parachains connect to the relay chain after paying a fee. Other components include bridges, which are a special type of blockchain that enable connectivity of parachains with outside networks such as Bitcoin and Ethereum.

From a consensus perspective, there are several elements in Polkadot. Validators secure the chain by staking tokens called DOTs. DOTs provide governance, staking, and bonding. DOT holders are allowed to participate in governance activities such as protocol upgrades. Staking with DOTs provides a mechanism to ensure the security and stability of the Polkadot network. Also, bonding using DOTs allows new parachains to be added to the network. Overall, in the Polkadot network, validators secure the chain and are selected by nominators due to their trustworthiness. Collators maintain shards, and so-called fishermen operate on the network for monitoring and policing purposes.

Lack of standardization

Lack of standardization leads to disparate systems that are unable to communicate with each other. This leads to interoperability issues. Therefore, there is a need to develop a common understanding of the requirements in order to develop blockchain platforms to the same standard. Doing this will ensure that all platforms are interoperable.

Post-quantum resistance

With the advent of quantum computers, it is envisaged that, soon, cryptography used in blockchain will be at the risk of becoming less secure. This is due to the ability of quantum computers to work at phenomenal speed, allowing cryptanalysis of most of the schemes currently in use. There is already some work being done in order to secure blockchains against post-quantum attacks, but there is still a lot to do.

Ethereum 2.0 is also ensuring that its chosen cryptography is either quantum-secure or pluggable with quantum-secure counterparts when available.

Also, quantum-resistant signature schemes such as Extended Markle Signature Scheme (XMSS) and SPHINCS are being investigated for Ethereum 2.0. The beacon chain's RANDAO is also expected to be quantum-resistant.

Compliance and regulation

Compliance and regulation are important aspects. In traditional IT systems, compliance and regulation plays a vital role in ensuring that data and information are handled in accordance with the policies, rules, and standards set by regulatory authorities. Adhering to such standards minimizes the possibility of security breaches, unauthorized access to data, and other issues stemming from the improper handling of data. Now, blockchain can, in fact, help to achieve compliance with certain regulations, such as GDPR and other use cases, where tamper-resistant auditing of logs is required.

A lot of work has already been done in the context of cryptocurrencies and tokens, but not so much from the underlying blockchain perspective. Treating cryptocurrencies and tokens as securities (allowing them to be governed by existing securities laws) is one thing, but regulating the underlying blockchain technology in terms of adherence to security standards, data sovereignty, and information-sharing regulations is another. We discussed compliance in detail in Chapter 20, Enterprise Blockchains.

With this, we have completed our examination of different challenges that blockchain faces, and also discussed some of the current solutions available to address these challenges during the next stages of blockchain evolution.

Summary

In this chapter, we introduced the various challenges facing blockchain technology. A major challenge, blockchain's limited scalability, was discussed, along with several methods available to achieve greater scalability. We approached these methods using different models, which divide the blockchain into planes, or layers, that can be improved in different ways.

We also discussed privacy, which is one of the major limiting factors toward adopting public blockchains for various enterprise use cases. Next, we explored smart contract security and various tools to improve it, such as model checking. Formal verification is a deep and extensive subject, but a brief introduction to various aspects was given, which should serve as solid ground for further research in this area. We also saw examples of formal verification to have an idea of what tools are available.

Finally, we discussed some other challenges to consider for the future of blockchain, including the issue of standardization and pluggability, and the inevitable need for quantum resistance.

In the next and final chapter of this book, we will explore the current landscape and future prospects of the blockchain technology.