Introduction | Verifiable Distribution Network: Blockchain Expansion Ultimate Solution

Due to the decentralized nature of the blockchain (ie, no entity controls its operation), more and more people expect, or at least hope, blockchains to exploit their disruptive potential in more areas. However, decentralization comes at a price: blockchains cannot scale, that is, they cannot handle large or even large amounts of transactions in a timely manner. For example, (on average) bitcoin can only process three transactions per second.

The root of the problem is also the bottleneck of the blockchain. The blockchain is based on a trustless peer-to-peer network. In this mode, information must be verified in every transmission between nodes in the network . There is no doubt that cloud distribution networks can address similar performance challenges in other areas (such as Akamai or YouTube to address the transmission performance of web and video), and can also be used to address blockchain scalability issues. The problem is that such a large centralized infrastructure like the cloud disrupts the decentralized nature of the blockchain, thereby eliminating the subversive potential of the blockchain. From this, one can ask the question: Can the cloud distribution network improve its scalability without destroying the decentralization characteristics of the blockchain? The answer is yes, the key to the solution is to propose an improved advanced version based on the existing concept (network neutrality): a verifiable neutral cloud distribution network.

The bitcoin revolution in blockchain and cryptography initiated by Bitcoin in 2008 was booming. Although the market value of mainstream cryptocurrency is highly volatile, it still has a scale of hundreds of billions of dollars. A unique feature of the blockchain is the lack of centralized governance. The blockchain relies only on a global peer-to-peer network consisting of participating nodes that validate and authenticate all transactions. Based on the purely distributed and decentralized design of blockchains, many believe that such systems have subversive potential in areas other than cryptocurrency, including medical, government, manufacturing, retail, insurance, Internet of Things, Sharing the economy and so on. Many high-tech companies, big and small, are paying close attention to the blockchain field and analyzing how this new technology will affect their current or future operations.

But one of the main problems with blockchain is scalability. The blockchain system throughput is measured by the TPS (number of transactions per second) that the system can support. Bitcoin currently has an average throughput of 3 TPS, while the Visa centralized system has an average throughput of 2000 TPS, a daily peak of 4000 TPS and a maximum throughput of 56,000 TPS. Without scalability, cryptocurrency systems will be difficult to mainstream, and blockchains are unlikely to achieve their subversive potential in any other area.

• Tencent's force blockchain game: "Catch the demon" public test on the day of the heat of the king is glory
• Babbitt column | The impact of non-standardization of products and services on blockchain applications
• April 14th market analysis: long and short sides are arrogant, the market is in a dilemma

What is a blockchain?

A blockchain is a publicly distributed distributed book that stores all past transactions, essentially a type of database created and shared by multiple (possibly up to tens of thousands) nodes interconnected in a peer-to-peer network. In order to reach a consensus on the correctness of the database, certain rules written to the database must be specified. Although the rules may vary, they generally include the following:

• A transaction (usually a user sending a certain amount of cryptocurrency to another user) must contain a digital signature from the initiator for authentication.
• Transactions must be added in order. Transactions are not individually billed, but instead they are added in batches, called blocks. For example, the Bitcoin blockchain requires that each new block contain a hash "difficult" answer, and the specific case of the hash "difficult" is determined by the specific situation of the previous block and the block currently attempting to be wound. (that is, each time you add a block is a brand new attempt).
• The process of adding blocks is very expensive and the participants need to compete with each other. Each participating node that wants to add a block to the blockchain either invests in cryptocurrency or invests in computational power, such as computing devices used to calculate the hash "difficulty" required for bitcoin outbound. Such a participating node is called a miner, and the process of adding a new block to the blockchain is called mining.
• The longest blockchain is the latest version. This rule, combined with the previous rules, makes the cost of successfully falsifying blockchains very high. Even copying an existing blockchain and attempting to modify the last few blocks is very expensive. Once the block is sufficiently confirmed on the network, deleting or modifying the block becomes extremely expensive and unprofitable. Therefore, transactions can only be added to the blockchain and will never be deleted after the link.
• Independent verification. When a node checks a copy of the blockchain database, it can independently verify that all previous rules have been followed. If each user can independently verify the blockchain, then all users can reach a consensus on the correct blockchain.
• Adding blocks to the blockchain can reward you. Because it is more difficult to write blocks to a blockchain, not all nodes will participate in this process. Many users create transactions and then request that transactions be written to the network, and users typically pay a fee for miners. In addition, as long as the miners win in a round of mining and have the opportunity to add a block to the blockchain, they can distribute the newly produced cryptocurrency currency to themselves.
• The blockchain branches and is resolved by the longest chain rule. Because the blockchain runs in a peer-to-peer network, due to network latency problems, two blocks may be dug out at the same location (ie, some nodes do not know that the new block has been dug, so after the last block) Continue to mine), this situation we call "bifurcation." The fork is actually a disagreement between the nodes on the latest version of the blockchain. But as long as the node always selects the longest blockchain on the network, the fork can be resolved after a period of time to reach a consensus.

Blockchain scalability problem

Before explaining the problem of blockchain scalability, let's look at the performance of the blockchain system. Figures 1 and 2 show the backlog of transactions between Bitcoin and Ethereum, two mainstream cryptocurrencies. As you can see, thousands of transactions are waiting to be written to the blockchain. In order to increase the possibility of being selected by the miners for "winding up", the user (voluntarily) increased the transaction fee. Therefore, during transaction congestion, transaction fees may increase significantly.

To understand where the bottleneck is, let's first calculate the actual throughput of the blockchain. The system throughput is directly dependent on two parameters: block size B (ie, the amount of transaction data that can be included in each block) and the block interval time T (ie, the average time required for the system to dig a new block) . In Bitcoin, B = 1 MB, T ~ 600 seconds, which is about 3 TPS. Thus, the throughput of the blockchain can be improved by adding B to include more transactions, decreasing T to get blocks faster, or two-pronged. The problem is that these parameters cannot be changed at will (the reason we will explain in detail later).

Obviously, it is the distributed nature of the blockchain that causes these problems. Indeed, as long as blocks and transactions can propagate instantaneously between nodes, a large number of blocks can be quickly dug up until the performance ceiling of a particular CPU and flash array is reached4. However, in reality, blockchain nodes—thousands or more—are distributed around the world. Therefore, the network is the bottleneck.

Nodes in a blockchain network communicate in a peer-to-peer manner. Unfortunately, this runs counter to the following high-throughput, low-latency goals:

• Information is transmitted from one node to another; therefore, propagating information throughout the network requires multiple hops (multiple transmission processes). Since each node in the network does not trust other nodes, the propagated information is independently verified in each hop . The verification process usually requires cryptographic operations, which increases latency and affects throughput.
• The performance of nodes in a blockchain network varies widely , which means that a single slow node on a critical path can swell the propagation time.
• Finally, nodes in a peer-to-peer network are randomly formed ; therefore, they cannot guarantee that the organized network can achieve optimal propagation: data is often transmitted through suboptimal paths in the network.

Therefore, it takes an average of 11.6 seconds to propagate a 1MB block to 90% of the Bitcoin network, which is the average propagation time observed in March 20171. Unfortunately, this is only part of the problem. Both Theory 7 and Practice 45 show that increasing the block size B by X times also increases the time required for block propagation by a factor of X. Similarly, reducing the block interval time T by a factor of X also produces a fully corresponding effect. This means that the block propagation time will increase proportionally as the two parameters increase.

For example, increasing the block size by a factor of ten will also increase the block propagation time by a factor of ten, making them more than 100 seconds long. Similarly, increasing the block size by a factor of 100 will result in a block propagation time of more than 1000 seconds . This propagation time exceeds the block interval, resulting in a fork every time a new block is dug. In fact, in this scenario, it is impossible to solve the bifurcation by continuing to dig out the subsequent blocks. On the contrary, the blockchain will be decomposed into "forked", "forked bifurcation" and "forked bifurcation" Fork "until the node and the miner don't know which fork is the "correct" chain – so the blockchain crashes. This is a blockchain scalability problem caused by network bottlenecks.

Cloud Distribution Network ( Cloud-Delivery Networks )

Cloud distribution networks have been very successful in addressing performance issues on the Internet. Such networks distribute content through a vast infrastructure that can be made up of thousands of servers around the world (for example, Akamai). In addition, the cloud distribution network performs extensive network and server measurements and uses these measurements to redirect customers to nearby servers . The Internet has thus been able to form a huge scale6. For example, YouTube alone has more than 1 billion users, and up to 70% of online traffic during peak hours in North America comes from streaming video and audio sites like Netflix and YouTube. This is not possible without a cloud distribution network.

This is in stark contrast to the current state of the blockchain. In fact, as explained earlier, propagating a 1 MB block through a blockchain network is a time consuming task, and increasing the size of the block can lead to irreparable errors. However, the cloud distribution network is capable of sending terabytes of data per second, and everyone feels that this is justified. Can such a network be used to extend the blockchain?

There is no doubt that cloud distribution networks can improve the performance of blockchains. But the problem is trust. In a blockchain ecosystem, a node does not trust its directly connected peers, so how does it trust a cloud distribution network that is much more powerful than any single node ? A cloud distribution network is a centralized system that can review transactions, blocks, or miners of a blockchain network. For example, a cloud distribution network administrator can reject blocks containing unauthorized traders or blocks of unauthorized miners based on their own policies, business interests, or legal requirements.

Therefore, the key question is whether it is possible to make the cloud distribution network trustless so that they can be used to extend the blockchain network without the review and other powers mentioned earlier in this article. This concept is called proven net neutrality. This article does not discuss its formal definition in depth, but outlines the key attributes associated with this concept.

First, the network should not review information based on the content of the block. Second, the network should not review nodes. Third, the node should be able to continuously verify the above two attributes, and can abandon and replace the network when the network has an erroneous behavior. How to implement these properties in a network?

A verifiable neutral blockchain distribution network

Consider a cloud distribution network whose goal is to extend the blockchain system (not necessarily just cryptographic currency) to thousands of winding transactions per second. In addition, its other goal is to provide scalability for a wide range of cryptographic currency and blockchains, using a global infrastructure to support distributed blockchain systems in a verifiable neutral manner. This is called the blockchain distribution network ( BDN ). This section provides an overview of the system's trust model and then describes the key mechanisms required to implement neutral attributes.

Reverse trust model

The trust model of the Blockchain Distribution Network (BDN) is based on two observations: First, long-term block propagation can never significantly increase the scalability of a trustless blockchain peer-to-peer network (such as Bitcoin). Secondly, the small centralization system can be well extended by trusting a small number of participating nodes and giving them control of the blockchain package transactions (such as Ripple and EOS).

However, this centralization undermines one of the most significant aspects of the blockchain: the distributed and decentralized control of transactions (or transactional packaging rights). Handing blockchain transaction packaging rights to a limited number of participating nodes allows the participating nodes to collude, review, and discriminate between users, nodes, and miners. The limited participating nodes also reduce the number of nodes that the malicious node has to pay for the control system.

Verifiable network neutrality

In short, the Blockchain Distribution Network (BDN) can only propagate all blocks fairly to all blockchain nodes, and BDN cannot treat discriminations differently because blockchain nodes often test BDNs. Network, and nodes are still connected in a point-to-point manner.

Encrypted block

In order to prevent the blockchain distribution network (BDN) from blocking the propagation of any block according to its content, the block is propagated after encryption (step 1 in Figure 3). BDN encryption also changes the block size, hiding the number of transactions and their total size. After the block is propagated, the receiver notifies the sender by sending a hash of the block (step 2 in Figure 3). Finally, the encryption key for a block is published and propagated directly on the blockchain peer-to-peer network (step 3 in Figure 3). The encryption key is small, only a few bytes, allowing it to spread quickly on the peer-to-peer network, and the BDN cannot block it. (Proofreading Note: The encryption technology used here should be symmetric encryption, ie the same key is used for encryption and decryption).

Indirect relay

To ensure that the blockchain distribution network (BDN) does not prevent individual nodes from propagating their blocks, the nodes may not propagate the blocks directly to the BDN. For a block that is not propagated by BDN (step 1 in Figure 4), the sending node will propagate it (block) to a peer node on the peer-to-peer network (step 2 in Figure 4), this peer The node will forward it (block) to the BDN (step 3 in Figure 4), obfuscating the origin of the block for the BDN. For example, a node that digs out a block in China can forward it to a node in Europe, which then sends the block through BDN. In addition to indirectly relaying blocks to the BDN, nodes can also request their peers to relay incoming blocks from the BDN to them. This ensures that the BDN cannot differentiate the nodes by delaying the distribution of the blocks because the nodes do not need to interact directly with the BDN in order to benefit from their services.

Auditing through test blocks

Although the blockchain distribution network (BDN) does not know which node digs into the block, it may attempt to block or delay blocks from certain nodes, affecting all the blocks they relay. In order to detect and prevent this behavior, the node must be able to continuously monitor the services of the BDN. This monitoring is accomplished by allowing the node to send the encrypted invalid block, test block directly to the BDN (Figure 5) and measure the time it takes for the peer node to report the arrival of the test block. BDN cannot use discriminatory policies only for valid blocks and faithfully propagate test blocks because the two test blocks are indistinguishable before the key is released.

Therefore, by using traffic encryption and indirect traffic relay, as well as explicitly auditing the BDN, the blockchain node can limit the misbehavior of the BDN and effectively decouple the BDN administrator's privileges from the BDN infrastructure. If the BDN stops distributing the block completely, or only distributes the block to a small number of nodes, the blockchain node can abandon the use of the BDN.

Because nodes often use test blocks to infer the best source of received blocks, nodes that are discriminated by BDN will only receive blocks from their peers. Therefore, if BDN maliciously discriminates against many or all peer nodes, peer nodes will form their own peer-to-peer networks directly until a different system replaces them. In addition, if the discrimination is caused by a large-scale system failure, once the failure is resolved, the peer node will return to use the BDN.

performance

Essentially, the Blockchain Distribution Network (BDN) deploys a broadcast primitive, which means it can efficiently transfer data from one source node to all other nodes in the blockchain network. Contrary to peer-to-peer networks (in a peer-to-peer network, each blockchain node is connected to many other nodes, which are usually distributed around the world), and the blockchain node replaces this one-to-many communication with a pair. One communication. This is because the blockchain node is connected to a single BDN server.

For larger TPS rates, using a single connection is more helpful than using multiple connections to increase scalability. In order to effectively audit the BDN, the blockchain node must be connected in the peer-to-peer network. However, most of the data is transferred back and forth between BDNs. Here are a few ways BDN can help extend the blockchain.

Transaction cache

In a blockchain system, such as Bitcoin or Ethereum, each node will repeatedly receive data for the same transaction: the first is when the original transaction is broadcast, and the second is when the transaction is on the chain (transaction data is the area) Part of the block data). BDN can effectively distribute transactions through the cloud, index them, and then leverage the index (rather than the original transaction) when transferring blocks. This effectively compresses the block size by more than 100 times, assuming the original transaction is approximately 500 bytes and the index can be 4 bytes or less.

Transaction caching is an existing idea in the blockchain ecosystem. It has been adopted by some projects. 3 However, only a few nodes deploy this technology, but not in the network protocol, because in the pure blockchain system. Not all transactions will reach all nodes, and even a slight async will result in a significant increase in block size (not all transactions are "compressed"), and performance will suffer. Instead, BDN can efficiently transfer and index blockchain transactions.

Straight path

Unlike blockchain nodes, BDN cannot check the validity of blocks flowing through the network because the blocks are encrypted. This helps to quickly transfer blocks of data over the network. In particular, before a BDN node receives all the bits of a block, the BDN can begin to transmit the bits of the received block to other parts of the network. This is called the straight path, which has been widely used in network switches for decades. For block propagation, it can still significantly speed up data transfer, especially when the data block is large.

Trading Incast issues

Transactions need to be broadcast in a blockchain network. In the absence of a BDN, when the TPS rate is high, a so-called transaction incast problem arises: a node receives the same transaction at a higher rate from multiple sources simultaneously. This will significantly affect the node's resources and affect the performance of the entire blockchain. BDN eliminates this problem because most of the data, including transactions, is propagated through a single BDN server.

Research on the scalability of blockchain

Other methods of increasing the scalability of blockchain are described below.

Off-chain solution

Another way to increase scalability is to use off-chain transactions, such as lightning networks, which are designed to reduce redundant data on the main chain. In general, an off-chain solution opens a payment channel between the parties to the transaction, allowing the buyer and the seller to exchange funds, while recording intermediate balances, and then closing the transaction on the blockchain.

BDN is not related to these solutions and does not conflict with each other. As an off-chain extension solution, there is still a need for a chaining feature. In addition, the potential expansion benefits are multiplied. If the underlying blockchain can support 1000 times more transactions than before, and the off-chain transaction increases throughput by a factor of 1000, the blockchain throughput can be multiplied by 6 orders of magnitude.

On-chain solution

On-chain solutions typically involve modifying the consensus protocol in some way to achieve higher throughput. One of the methods, sharding, divides the blockchain into several smaller shards. A full node only needs to track one shard, not the complete blockchain. These shards are interleaved and carefully maintained to preserve the original security attributes of the blockchain. There are many other ideas in this area 2 . Although these methods show some potential, their robustness, safety and availability remain to be seen in practice.

Still, in the faster network layer, all on-chain solutions will perform better, which is where BDN comes in. In fact, in a distributed consensus protocol, each node that follows the protocol must make the same decision. Therefore, each such peer node must obtain information about each transaction in the system independent of the consensus protocol. BDN is only working to solve this problem (in fact, it is a broadcast problem), because every valid piece of information must be propagated to every peer in the system. Therefore, the effectiveness of the BDN scheme is independent of the consensus protocol, which can significantly improve the performance of any blockchain.

to sum up

Verifiable Neutral Cloud is undoubtedly a viable solution to improve the scalability of blockchain. By optimizing the transport layer, not only can the throughput be fundamentally improved, but the latency can be significantly reduced. In fact, the delay distribution body of today's data centers has been biased toward microseconds, and the milliseconds only exist at the end of the distribution. There is no reason why BDN access points cannot achieve similar performance.

Adding a dedicated fiber infrastructure between these BDN sites will further reduce throughput and latency to build an advanced BDN backbone. However, the key to realizing this vision is to build trust in the underlying network infrastructure through the blockchain ecosystem. Decoupling management rights from the infrastructure through a verifiable neutral network design is our answer.

---

Note 1: Bitcoinstats.com. Data propagation; http://www.bitcoinstats.com/network/propagation/ .

Note 2: Cachin, C., Vukolic, M. 2017. Blockchain Consensus Agreement arXiv; https://arxiv.org/pdf/1707.01873.pdf .

Note 3: Clifford, A., Rizun, P. Suisani, A., Stone, A., Tschipper, P. 2016. Expanding to a large-scale chain: Demonstrating our block broadcast results with Xthin; https:/ /medium.com/@peter_r/towards-massive-on-chain-scaling-presenting-our-block-propagation-results-with-xthin-da54e55dc0e4 .

Note 4: Croman, K., Decker, C., Eyal, I., Gencer, AE, Juels, A., Kosba, A., Miller, A., Saxena, P., Shi, E., Sirer, EG , Song, D., Wattenhofer, R. 2016. On how to extend the decentralized blockchain. In International Conference on Financial Cryptography and Data Security. Springer. 106-125.

Note 5: Decker, C., Wattenhofer, R. 2013. Information dissemination in the Bitcoin network. In the 13th IEEE International Conference on Peer-to-Peer Computing; https://ieeexplore.ieee.org/document/6688704 .

Note 6: Internet Live Stats; http://www.internetlivestats.com/one-second/ .

Note 7: Klarman, U., Basu, S., Kuzmanovic, A., Sirer, EG 2018. bloXroute: An extensible, trust-free block distribution network; https://bloxroute.com/wp-content/uploads /2018/03/bloXroute-whitepaper.pdf .

Note 8: Nakamoto. S. 2008. Bitcoin: a peer-to-peer electronic cash system. Bitcoin.org; https://bitcoin.org/bitcoin.pdf .

---

Original link: https://queue.acm.org/detail.cfm?id=3319534 Author: Aleksandar Kuzmanovic Translation & proofreading: A Sword & Stone waves

Aleksandar Kuzmanovic is a professor of computer science at Northwestern University. His recent research includes content distribution networks, network neutrality, and blockchain. He is the co-founder of the startup bloXroute Labs and is the chief architect at the company.

This translation was modified on the basis of the translator's manuscript .

(This article is from the EthFans of Ethereum fans, and it is strictly forbidden to reprint without the permission of the author.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!