The Control Plane orchestrates the BDN by suggesting connections between Relays and Gateways and dynamically adjusting the topology of the network to achieve high performance.
When attempting to connect to the bloXroute BDN, Gateways register with the BDN Control Plane. The Control Plane then checks for a geographic region of the Gateway’s IP address. The Control Plane uses the IP address and region to determine suggested Relays for the Gateway to connect to. The Gateway selects from the provided Relays to determine the Block and Transaction Relays to connect to.
The Control Plane also provides the Gateway with IP addresses of other Gateways it is aware of, so that the Gateways can form an independent p2p network. Gateways are designed to maintain the p2p network even if the Control Plane fails.
The bloXroute Gateway is an application that connects your blockchain full node to the bloXroute BDN. Using the Gateway, the BDN is designed to propagate blocks and transactions to your full node faster than the traditional peer-to-peer blockchain network. The Gateway software is written in a combination of Python and C++. It may be installed by downloading a Docker Container with the Gateway already installed, or via installation using pip. While the Gateway software communicates using the blockchain protocols, it does not maintain the blockchain state. Accordingly, the Gateway will connect to a remote blockchain node maintained by bloXroute to proxy messages when requested by the user’s blockchain node.
Gateways are responsible for determining which Relay to connect to from a list provided by the Control Plane.
When starting a Gateway, a User may specify the IP address of the Gateway as a command line parameter. If the User does not specify an IP address at startup, the Gateway will attempt to determine its own IP address by reaching out to a remote IP detection service. If the Gateway cannot determine its IP address, it terminates itself with an error instructing the user to provide the IP address at the command line.
After determining it’s IP address, the Gateway connects to the Control Plane and provides its IP address. The Control Plane then looks up the geographic region of the IP address using an IP geolocation service. Based on the determined geolocation of the IP, the Control Plane returns a list of potential Relays for the Gateway to connect to. The list of potential Relays contains the top Relays closest to the Gateway, sorted by distance. If no location is returned by the IP geolocation service, the Control Plane will send the Gateway a list of potential Relays including two Relays from North America, and three Relays from other regions.
Using the list of potential Relays, the Gateway checks the latency of the provided Relays and connects to the Block and Transaction Relays with the lowest latency. Latency is measured using ping latency between the Gateway and each Relay. In addition to connecting to the Relay with the lowest ping, the Gateway additionally stores at the second lowest latency pair of Transaction and Block Relays as a backup in case the initial Relay connections are lost. If the Gateway loses a connection with a Relay, the Gateway connects to a different Relay to maintain its connection with the bloXroute BDN.
Relays form the backbone of the bloXroute BDN. Gateways connect to Relays to receive notifications of new transactions and blocks faster. bloXroute Relays are located around the globe at points optimized to provide faster propagation of transactions and blocks between Gateways.
In order to provide improved block propagation, bloXroute uses a split Relay design. In the split Relay design, the BDN includes two types of Relays, 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, and vice versa.
When registering with the Control Plane, the Gateway receives the IP and port for a pair of Relays. The Gateway opens a socket connection with both the Block Relay and the Transaction Relay.
bloXroute Gateways communicate with blockchain nodes using their native peer-to-peer protocols but are not themselves full blockchain nodes. Thus, while a Gateway can, for example, send and receive Bitcoin blocks from a Bitcoin full node, it cannot validate that the block is valid.
However, blockchain nodes frequently make requests to a connected Gateway that the Gateway cannot fulfill because it does not fully validate the chain. In order to permit the Gateway to respond, bloXroute Gateways may connect to remote blockchain nodes, run by bloXroute, to fulfill certain requests by its blockchain node.