Scalability is a crucial factor that is talked about even before an application has been created. Yet, even after the application is deployed, the application will be required to be updated frequently to scale based on the application load. While scalability has been one of the concerns even in the blockchain space, it wasn’t the first priority when the technology was first proposed. However, over time and due to the increased interest in the technology, people are now working toward the improvement of every aspect of blockchain technology. In this article, we will explore various optimizations that can be implemented to help you achieve better performance or plan for scalability. This article is an excerpt from the book, Foundations of Blockchain by Koshik Raj. Blockchain technology is a combination of three popular concepts: cryptography, peer-to-peer networking, and game theory. Foundations of Blockchain is for anyone who wants to dive into blockchain from first principles and learn how decentralized applications and cryptocurrencies really work. Due to the decentralized nature of the blockchain applications, it is difficult to make huge changes to the blockchain protocols of the functioning applications. The existing protocols need to be optimized carefully to achieve improvements. In this upcoming section, we will discuss a few of the possible optimizations.
Transaction exchange
Communicating and exchanging data is the essence of a decentralized P2P network. In a blockchain network, transactions are the main data that is exchanged between nodes. Optimizing the exchange of transactions could be achieved by making use of protocols that are suitable for transaction data. A few optimization techniques are described in the following sections.
Blockchain relay networks
Although the nodes in the blockchain network are equal, the nodes could opt to perform a variety of roles. A few nodes might function as fullnodes, maintaining the entire blockchain, whereas a few others function as lightweight nodes by maintaining only the required transactions. In addition to this, the nodes that are willing to create new blocks will perform mining operations. When all these nodes communicate with each other in a P2P fashion, there will be a network latency involved. The mining nodes need to keep latency to a minimum since they are involved in time sensitive operations. Even during a critical financial transaction, a decentralized system needs to keep latency as minimal as possible so that clients and merchants can receive notifications quickly. The Bitcoin network uses a relay network to minimize the latency during block exchange between peers, especially with mining nodes that are competing to construct the next block. Relay nodes don’t fully verify data before relaying the block/transaction to the network. Although the relay nodes are quick at relaying most of the transactions, they may not be accurate in delivering every transaction of the system. A Bitcoin Core developer called Matt Corallo created a UDP-based relay network called Fast Internet Bitcoin Relay Engine (FIBRE). It uses a compression technique provided by the compact block, which was developed by Bitcoin Core. Since the FIBRE code base is an extension to the Bitcoin Core, FIBRE nodes could be set up just like the Bitcoin core nodes. Another relay network, called Falcon, uses application-level cut-through routing for faster block propagation. The optimized topology claims it is faster than compression-based relay networks. These relay networks not only guarantee that network nodes will achieve higher throughput but also promise future scalability for the decentralized P2P network.
Invertible bloom lookup tables
Invertible bloom lookup tables can be used to efficiently find the difference between the two datasets. This concept has been implemented in Bitcoin to achieve lower transaction exchange latency between peers. Without any mechanism to find the difference between two sets, each Bitcoin node had to keep transferring its own transaction set to the network and expect other nodes to reply with transactions that did not exist in the transaction set. This mechanism consumed a lot of Bitcoin network bandwidth and time due to the large set of transactions in each node. A solution is to transfer information that could be used to find the difference between datasets efficiently. Invertible bloom lookup tables solve this by creating smaller lookup tables that can find the transactional differences between the two sets. Invertible bloom lookup tables are a variant of bloom filters. They provide a successful lookup of the key-value pairs with high probability. Unlike the bloom filters, they not only allow you to look up a particular key but also list the inserted key/value pairs. Lookup tables are a probabilistic data structure, and the probability of successful lookup increases with the size of the lookup table. Each node on the network will broadcast a lookup table for the transaction pool, which will be recognized by the other nodes in the network. The nodes in the network will only exchange the required transactions and thus reduce redundant communication. Transactions in the pool can be synchronized quickly and securely with the help of these lookup tables.
Off-chain transactions
A set of transactions that can be performed outside the blockchain is referred to as off-chain transactions. Off-chain transactions rely on several methods of validation that are different from the one used in the main blockchain. Although the main motive of the off-chain transaction is to achieve increased transaction speed, it also should provide basic security by making sure that the transactions cannot be reversed by any participant.
Off-chain state channels
A state channel is a two-way communication between the members of a system that enables the members to perform a series of transactions without committing them to the blockchain. Off-chain transactions tremendously increase the throughput by avoiding blockchain confirmation for every transaction. Off-chain channels are ideal for micro-transactions where two parties communicate their transactions by setting up a payment channel that is independent of the blockchain state. The state channel can be closed once the transactions between the parties are concluded. The final state of the channel is then sent to the blockchain. Figure 1 shows a payment channel that is created between Alice and Bob. Alice and Bob will then perform a series of transactions whose state is written to the blockchain only after the state channel is closed: 
The Lightning Network
The Lightning Network is a second-layer payment protocol that operates on top of the Bitcoin blockchain. At the time of writing, the implementation of this protocol is running in beta mode on Bitcoin’s mainnet. It is a routed bidirectional network that was proposed to solve the Bitcoin transaction scalability problem. The Lightning Network creates a routed payment channel network where communication between the nodes is bidirectional. The design has been implemented by several open source communities by following a set of standards.
An example of a Lightning Network
Let’s consider an example where Alice wants to perform several Bitcoin payment transactions with Bob. Alice and Bob decide to open a payment channel using the Lightning Network. Alice and Bob both create a channel, initially funding it with 2 bitcoins each. The funds can be kept in a multi-signature address account, which will ensure that both parties need to agree on the finalized fund distribution. A balance sheet will be maintained, which will update the balances of Alice and Bob after each transaction. The balance sheet is similar to the concept of keeping tabs in a restaurant or bar; instead of paying for each order, a tab is maintained that can be used to pay for all the orders together. Alice wants to send 0.5 bitcoins to Bob, so she will create a transaction that pays 0.5 bitcoins to Bob. Instead of appending this transaction to the blockchain, the payment channel will update the balance sheet. Now the channel fund will reflect 1.5 bitcoins as Alice’s balance and 2.5 bitcoins as Bob’s balance: 
Routed payment network
A user in the Lightning Network doesn’t need to set up a direct payment channel with every user to perform a transaction. A user can find several connected payment channels to connect to the other user in order to set up a routed payment network. Consider an example where Alice wants to set up a micro-payment channel with Carol. Alice has earlier set up a channel with Bob. She also finds out that Bob has an active channel with Carol. So, instead of setting up a new payment channel, Alice decides to create a routing payment channel with Carol via Bob, as shown in Figure 3: 
