The bloXroute Solution
bloXroute’s goal is to enable cryptocurrencies and blockchain systems to scale to thousands of on-chain transactions per second. bloXroute provides that scalability to numerous cryptocurrencies and blockchains simultaneously utilizing a global high performance blockchain distribution network. This document outlines the key components and features of the bloXroute solution.
To be truly useful for numerous applications they are intended for, cryptocurrencies and blockchains must scale the number of transactions they can process to thousands of transactions per second. The limiting factor of all cryptocurrencies and blockchains is their network. Speciﬁcally, they employ a trustless P2P network model to propagate transactions and blocks, which does not scale as the volume of transactions increases. bloXroute’s mission is to address this problem and scale cryptocurrencies and blockchains that wish to utilize its services.
To allow all cryptocurrencies to scale to thousands of on-chain transactions per second, bloXroute developed a blockchain distribution network (BDN). The use of BDN allows to safely increase the block size and to cut down the time interval between blocks, without increasing the risk of forks. Furthermore, the use of bloXroute’s BDN requires no consensus, nor a protocol change, beyond adjusting system parameters. With the networking bottleneck removed, each cryptocurrency community is free to adjust its protocol to best leverage this newfound capacity, in order to increase its real-world impact and value.
The rest of this document is structured as follows. We first present a high-level overview of the bloXroute architecture. Then, we explain the key elements that enable high network performance and blockchain scaling, and then provide “a deeper dive” into the bloXroute architecture. Finally, we provide a set of practical installation and deployment procedures.
bloXroute Architecture: a High-Level Overview
The core of the bloXroute system is a high-capacity, low-latency global network of servers (called relays) optimized to quickly propagate transactions and blocks for multiple blockchain systems. However, in order for a blockchain node to access the relay network, it is essential to have a gateway software, to enable interoperability, i.e., mapping between native blockchain messages and bloXroute protocol messages, and vice versa. Below, we first explain, at a high level, the bloXroute gateways, then the relay network. In the rest of the document, we use the terms “BDN” and “relay network” interchangeably.
A Gateway Needed to Access the BDN
A user node is the computer of any user who wants to use the bloXroute BDN with their blockchain node. Each user node runs our Gateway software, a piece of open source code that communicates with their blockchain node to transmit transactions and blocks to and from nearby bloXroute servers. Users of bloXroute may include anyone running a blockchain full node that would like greater performance for block and transaction propagation. As shown in the figure below, to use bloXroute, a user installs the bloXroute Gateway on their server and configures it to communicate with their Blockchain software.
The bloXroute Gateway is the entrypoint for the blockchain software into the bloXroute’s BDN, passing transactions and blocks between the blockchain software the rest of the BDN. The Gateway talks to the blockchain software using the blockchain software’s native peer-to-peer communication protocol. From the perspective of the blockchain software, a gateway is just another peer in the network. The Gateway is open-source software. Anyone can modify it to meet their needs, or review the code to ensure that the software is behaving as expected.
A Relay Network for High Performance
At the core of the bloXroute BDN is a high performance relay network. The relay network is comprised of individual relay servers located around the globe at points optimized to provide faster propagation of transactions and blocks between Gateways. The relay servers are connected in an optimized topology to ensure that data from each individual gateway is moved optimally to all other gateways in the network. Gateways connect to Relays to receive notifications of new transactions and blocks faster than they would otherwise be received from the peer-to-peer network.
bloXroute Relays come in two types: Transaction Relays and Block Relays. As the names suggest, Transaction Relays propagate transactions and Block Relays propagate blocks. The split relay design ensures that transactions do not interfere with the propagation of blocks.
The figure below shows an overview of the relay network. As shown, globally distributed users run blockchain software that is connected to the blockchain’s peer-to-peer network. Each user installs and runs the bloXroute Gateway software on their server. Each Gateway then connects to a Transaction Relay and a Block Relay to begin sending and receiving transactions and blocks over the relay network.
Keys to High Performance and Scalability
In the BDN we employ three major techniques to achieve high performance: block compression via transaction indexing, cut-through routing, and an optimized dynamic scale topology. Future iterations may include additional networking techniques that allow us to achieve even faster block propagation.
Block Compression via Transaction Indexing
bloXroute uses compression to enable faster propagation by reducing the size of blocks. Compression is enabled through the use of transaction caching and indexing. A unique feature of bloXroute’s BDN is that it propagates and indexes transactions in addition to blocks. As a result, transactions are already known when it’s time to send out the block (as an unconfirmed transaction stored in the mempool, rather than send a block with “raw” transactions), the BDN sends just a few bytes representing the transaction. It does this by indexing the transactions, and then utilizing the indexes when transmitting blocks.
The transaction propagation process operates as shown in the figure below. A transaction is generated from a blockchain node and sent to its peer including a Gateway. The Gateway then sends the transaction to its Transaction Relay server for propagation. The Transaction Relay assigns the transaction a 4-byte long internal ID, called a short id or SID, and sends the transaction/ID pair to the rest of the BDN (including both relays and Gateways). Because each Transaction Relay can assign a transaction a SID, occasionally two Transaction Relays will receive a transaction at the same time and each issue the transaction a separate SID. Because each SID uniquely maps to a single transaction, these redundant SID assignments are not a problem, and the redundant SID assignments will be stored in the transaction cache without issues.
The receiving relays and Gateways keep track of the transaction/short ID pair in their transaction cache. Additionally, the Gateways forward the transaction to the blockchain full node. The blockchain full node then validates the transaction and adds the transaction to its mempool, if appropriate.
When a miner builds and then sends its block to the Gateway, the Gateway replaces each transaction with a 4-byte SID. This technique allows bloXroute to effectively compress the block size by more than 100x (given that the average raw transaction is approximately 500 bytes, the index size is 4 bytes and the Gateway has a full mapping of the transactions that exist in the block) and in turn, propagate blocks faster, as we will explain below. If a transaction in a block has no SID, it is not replaced in the block.
After a new block is mined, it is sent to the miner’s blockchain full node and to its peer nodes, including the Gateway. After compression, the Gateway sends the compressed block to its Block Relay which propagates the block throughout the BDN. Next, the compressed block is propagated throughout the BDN. Upon successfully decompressing the entire block, the receiving Gateway forwards the “raw” block to the blockchain full node. Hence, the bloXroute operations are completely transparent to a blockchain node.
The figure below illustrates the process of compressing a block. As shown, the Gateway replaces the transactions in the block with SIDs from the transaction cache. If a transaction is not found in the transaction cache, it is not replaced. After compression, the Gateway sends the compressed block to its Block Relay which propagates the block throughout the BDN.
The process of reconstructing the original block by the Gateway includes the steps of: For each SID in the compressed block, the Gateway looks up the SID in the transaction cache. If the SID is found in the transaction cache, the SID is replaced with the corresponding transaction. If a SID is not found in the transaction cache, the Gateway requests the missing SID/transaction pair from its Transaction Relay. If the relay provides the SID/transaction pair, the Gateway replaces the SID with the newly received transaction. If the relay does not provide the SID/transaction pair, the Gateway discards the compressed block. In the case that the Gateway was able to decompress the block, the decompressed block is then sent to the blockchain full node.
Without bloXroute’s BDN, each hop in the block propagation checks the validity of the block it is receiving before sending that block on. A node will transmit blocks to its peer only when the block is fully received and validated. The bloXroute BDN does not wait until the entire block is received before it sends the block to a peer node. Instead, it immediately streams each packet of data as it is received through a well-provisioned dedicated network infrastructure. This technique, known as cut-through routing, allows bloXroute to broadcast data quicker. Only once the blocks are received by the blockchain node through the Gateway, are they validated.
The figure above illustrates cut-through routing. The node on the left is a Gateway, the node in the middle is a bloXroute Block Relay, and the node on the right is a receiving Gateway. The figure shows that the bloXroute Block Relay indeed starts streaming data before the entire data message (e.g., a block) is received. As a result, and as could be seen in the figure, the receiving Gateway starts receiving first pieces of the message at the moment when the sending Gateway still didn’t finish sending the entire message, thanks to cut-through routing applied by the Block Relay.
Another advantage of the BDN is its optimized topology, contrary to a peer-to-peer (p2p) network deployed by blockchain nodes. In particular, in such p2p networks, peers find out about each other by querying a set of hard-coded DNS servers. The DNS servers provide joining nodes with their initial peer list to connect to and from there, new blockchain nodes can crawl through the network. The result is a web of random connections where data is not propagated throughout the network in the most optimal route.
Conversely, bloXroute has strategically placed servers, i.e. relays, around the world to send data as efficiently as possible to the geographically dispersed set of nodes that comprise the various blockchain networks.
Furthermore, the BDN Control Plane will dynamically select the optimal relays based on network latency and server load. In most cases, the Control Plane will connect the Gateway to the closest relay server in the network sense, i.e., in terms of latency.
In addition to providing direct connections to Gateways, the BDN Control Plane works to maintain low latency between relays of the BDN. This includes generating routing tables that govern the connections between relays to ensure that data is transmitted between relays with low latency. Additionally, the BDN Control Plane monitors redundant routes between relays in the BDN to ensure that even if primary routes fail, backup redundant routes can ensure delivery of messages across the BDN.