Are centralized relay networks a suitable L0 scaling solution?

Summary. This article describes the limitations of using a single centralized relay network for layer 0 scaling - the relay network inherently becomes the focal point of trust enabling double spends, 51% attacks and censorship. We examine the shortcomings in Bloxroute Labs’s approach to avoiding such pitfalls which ultimately relies on the reputation of the relay network’s operator for correct operation. We argue that it’s simply better to rely on banks and centralized web 2.0 companies instead of using expensive decentralized web 3.0 protocols when security hinges on a similar for-profit company. Enumerating such issues and analyzing existing solutions provide insights into the design trajectory of Marlin, a layer-0 scaling protocol being developed to align with the ethos of decentralization through adequate redundancy, randomness and incentivization of the P2P layer.

Layer 0 scaling: Has everyone yielded?

The network layer (layer 0) has long been considered a critical bottleneck to blockchain scaling. Peer-to-Peer networking, a requirement deemed necessary to ensure censorship-resistance since the death of Napster and rise of more decentralized architectures like Gnutella and BitTorrent, is often accepted as a necessary compromise that trades off performance from efficient centralized architectures in favour of better security. Alas! There has to be a cost to decentralization, they say. Also at the forefront of the blocksize debate, setting the minimum bandwidth requirements of nodes in a P2P network which determines the largest size of blocks that can efficiently propagate through it while maintaining a low fork rate and adequate decentralization has remained an open question in the space. 

Protocol developers have tried to overcome the networking bottleneck in a variety of ways, either by designing consensus algorithms that do not lead to orphans (structured DAGs), increasing resource requirements (Solana), limiting consensus nodes (EOS) or by moving transactions out of the P2P network (Lightning). In Bitcoin, the most well known measures to accelerate block propagation remain to be compact blocks, Graphene, FIBRE (a protocol as well as a homonymous relay network voluntarily maintained by Matt Corallo), Falcon and several such full-mesh spynets run privately by mining pools. However, none of these solutions have been able to securely solve the fundamental problems at the networking layer to significantly improve the throughput of blockchains, the crux of layer 0 scaling.

The relay network

Centralized Relay Networks (CRNs) inspired by Content Delivery Networks (CDNs) in web 2.0 are often used to accelerate block delivery. They replace P2P communication with a cloud-based overlay to obtain an optimal low-latency multicast topology with global reach. 

In brief, CRNs are a bunch of servers run across the globe. Miners and full nodes are required to transmit and receive blocks from the closest CRN server. Setting up servers at good locations enables usage of optimal Internet links saving in-network communication from the vagaries of the public Internet. Centralized control on the nodes also enables sophisticated devops which ensures high-reliability. Propagation can be further optimized using techniques like compression and cut-through routing. 

CRNs are often used by miners to increase mining efficiency. However relying on CRNs to scale blockchains introduces several undesirable properties, not to mention, centralization, censorship and increased vulnerability to 51% attacks. As the permissionless peer-to-peer propagation of blocks via gossip protocols no longer remains a viable fallback in conjunction with CRN-accelerated chains, CRNs are required to take several extra measures to prevent changing the adversarial models of protocols that use them. 

Bloxroute Labs, an operator of such a CRN, proposes a set of measures it calls provable neutrality to justify the trustlessness of their system. We examine those measures below, check whether the mechanisms succeed in proving trustlessness and conclude that CRNs can always be biased and are thus an extremely insecure scaling solution in isolation. We list a few elementary and fairly well known critical attack scenarios that should serve as a checklist for future designers of layer 0 scaling solutions and inspire the design of Marlin.

Examining provable neutrality

Bloxroute’s approach to maintaining trustlessness by preventing blacklist-based censorship (the act of censoring blocks based on their content and/or source) requires miners to first publish encrypted blocks over the CRN and then gossip the decryption key through the P2P network once the miner believes that the encrypted block has reached a major part of the network. In addition, miners can send garbage blocks (test-blocks) to check if the CRN is censoring them using their IP address and if so, use an anonymity network to send their real blocks. Unfortunately, these measures as we show below fail to prove the trustlessness of the system and additionally expose blockchains using them to a new range of attacks. 

Whitelist-based censorship: Sell out to the highest bidder

Censorship-resistance, the property which ensures that transactions can’t be prevented from being included in the ledger based on their purpose or the parties involved is crucial to a blockchain’s objective of providing financial freedom. Block producers should, thus, be able to operate without fear of being retaliated against for including a blacklisted transaction. Blockchains ensure this property today by designing consensus algorithms that require an adversary to coordinate a large subset of the network in order to be able to censor a block from being included in the blockchain provided it propagates through a major part of the network soon enough. Gossip and full nodes are crucial to ensuring the latter requirement.

Whitelisting: Any centralized relay network can, however, impose an IP address based whitelist. The relay network can either prioritize blocks from whitelisted IP addresses (in the benign profit-driven case) or can completely exclude transmission of blocks from non-whitelisted miners (as per instructions given by the government authorities that CRNs will be required to comply with). 

Miners build on the first valid block they receive. When competing miners produce blocks at around the same time, the one that takes longer to propagate has a higher probability of getting orphaned. Under the current system parameters, it’s fairly rare for blocks to be mined at around the same time. However, the probability of such instances occurring increases significantly in a network that uses ambitious system parameters to increase throughput. 

Whitelist-based censorship, thus, makes networks relying on CRNs for scaling severely vulnerable. Not only can certain accounts and users be prevented from interacting with the blockchain and effectively have their accounts frozen but several dapps too can be suddenly made dysfunctional contrary to Web 3’s goal of enabling censorship resistance platforms. 

Implicit centralization: Drive small miners out of business

Preferential propagation is lost revenue for the miner being discriminated against. Mining operates at margin. Hence, miners are required to win block rewards in proportion to their hash power (fairness property). Races at the network layer augmented by manipulation from a centralized relayer disturb this fairness property by providing miners who are able to secure preferential propagation (through bribing or some sort of threat) a higher probability of winning block rewards than their share of the total hash power would warrant. This would slowly drive victims out of business.

Races at the network layer are hard to detect as it is. To make it worse, such preferential propagations can be further disguised by letting a disadvantaged miner’s block get a higher priority once in a while (high enough to not make the bias apparent but low enough to make the victim’s operations economically infeasible).

Extortion: Threaten miners of their existence

The CRN, thus, has the ability to extort miners for a greater share of their profits. Else, they risk being driven out of business with little push back from the community as it is impossible to generate proofs of such discrimination (except for some sort of an off-band sting operation which isn’t a very reassuring failover). A cunning CRN can in effect play a long-term strategy where it initially resorts to predatory pricing to drive out competitors and then raises prices once dapps building on blockchains can’t afford the blockchain to suddenly lose its high throughput. This scenario is further delved into further below.

Explicit centralization: Bringing decentralized protocols under the jurisdiction of governments with a regulated and compliant network layer

Public blockchains effectively become permissioned with a CRN becoming the gatekeeper for blockchain networks. While a CRN can sneakily centralize blockchains and quietly threaten to drive miners out of business for commercial reasons, government authorities can also compel a CRN to ensure that only KYC’ed miners registered with them can transmit blocks through their network. Note that it’s impossible to ensure censorship resistance through technological solutions if having a centralized operator is a necessary constraint. Just as a bank can’t get away by claiming that its users register using fake IDs and make anonymous deposits into each other’s accounts through cash, it would be impossible for a CRN operator to claim immunity from regulators under the context that the blocks it receives are encrypted and sent through Tor.

How secure is the blacklist-resistance anyway?

The censorship-resistance mechanism described previously relies heavily on the miner producing the block not gossiping the decryption key too soon. This is a questionable assumption as miners are incentivized to have their blocks propagated as soon as possible (the very premise of such relay networks). In the scenario where the relay network is not biased towards any particular miner, the race for block propagation changes to a race of propagation of the decryption key. 

As a result, miners are more likely to exclude censored transactions and have their blocks decrypted as soon as possible by quickly propagating their decryption keys instead of taking the risk of including censored transactions and delaying the propagation of the decryption key with the possibility that another miner front runs it in the propagation of the decryption key for a competing block. This race is further exacerbated by the fact that the propagation of decryption keys through the network takes a while. Since nodes would most likely not propagate decryption keys without verifying if they validly decrypt an encrypted block first (to avoid DoS attacks), miners would be even more incentivized to try to get their decryption keys propagated through different paths as soon as possible instead of delaying it on their end. Such inherently contradictory incentives (based on the assumption that miners care more about their revenue than including blacklisted transactions) would automatically break the blacklist-resistance mechanism based on encryption of blocks.

Cripple unfavoured chains through (D)DoS 

In a normal gossip network, the validity of blocks is first checked and invalid blocks are prevented from being propagated to avoid DoSing the network. Encryption of blocks, however, opens a new (D)DoS attack vector on networks using a CRN that was absent before. Since encrypted blocks cannot be checked for their validity, they are blindly forwarded to all subscribing miners. This in fact has been described as a feature earlier (cf. test-block). As a consequence, CRNs are susceptible to propagating numerous spammy invalid blocks, in effect, DDoSing miners and full nodes of networks using it. 

While a simple DoS attack is easy to prevent by rate-limiting nodes, any geography or IP based heuristic to prevent DDoS on CRNs is unlikely to be fair. Since a permissionless network can have any miner join the network and produce blocks without any sort of subscription and given miners are required to use Tor to prevent censorship, any identity-based heuristic to prevent DDoS makes the system unfair towards miners with no prior ‘reputation’ registered with the CRN. Since CRNs effectively enable multicast, a DDoS attack on CRNs does not only decrease the Quality of Service of the CRN but also consumes the resources of every miner increasing the potency of the attack.

Double-spending by partitioning 

Any entity having a monopolistic control on the network layer makes not just censorship but also double spends and 51% attacks possible in blockchains by partitioning them. Partitions are situations where faults in networks divide them into multiple sub-networks that cannot communicate with one another. While partitions can occur due to natural reasons, they are also often induced by AS-level adversaries (ISPs) or through BGP poisoning. A succinct description of the attack can be found in https://btc-hijack.ethz.ch/#attack. Detailed descriptions of such routing attacks and associated hazards can be found in the works of Maria A. et al and Muoi T. et al. A related attack known as eclipse attack has been studied by Ethan H. et al.

In short, partitioning of decentralized networks can lead to:

Node level attacks

1. Significant wastage of mining power which could have been spent on securing the main chain
2. Miners of the smaller partition losing revenue as their chain gets orphaned
3. Slashing in the case of Proof-of-Stake protocols
4. Double spends with a transaction T made in the smaller partition replaced by a conflicting transaction T’ in the bigger partition
5. Merchants being eclipsed and effectively DoSed 

Network level attacks

1. Splitting mining power making 51% attack easier
2. Slow throughput making dapps built on affected blockchains unusable for the duration of the partition as difficulty adjustment takes time to accommodate the sudden fall in hash power (for example, a 50% reduction in hash power will increase block times to 20 minutes on average and will take roughly 2 weeks to rectify)
3. Increased susceptibility to selfish mining attacks
4. Increase in fork rate
5. Loss of trust in the network leading to a fall in the value of the network’s native token which can be aggravated by the attacker taking a short position before the attack

As noted by Maria in her work, AS level adversaries are also capable of carrying out such attacks. Mining pools protect themselves against potential misfortunes by resorting to a high degree of multi-homing (by connecting through multiple ISPs). However, CRNs as a single entity having control of the overlay network possess the potential of carrying out such an attack by themselves either under compulsion from governments or due to commercial reasons. Coupled with preferential propagation, chain reorganizations become even easier.

The implications

As can be seen, CRNs are capable of acutely weakening the security model of blockchains. While the DDoS attack vector is specific to a particular CRN design, the ability to partition and control the system to wreak havoc is inherent to the design goal of a CRN: utilizing centralized infrastructures to speed up communication between nodes. This enables the CRN to act as an adversary itself or be an easy target for other adversaries.

Predatory pricing to rent-seeking trojan

In the case where the CRN acts as an adversary itself, it first seeks to establish a monopoly in the domain. The traditional approach to achieving such goals is to protect the technology through patents and eliminate competition through predatory pricing. Bloxroute Labs, for example, has made 7 patent applications. It further charges little to no fees. Nevertheless, such tactics could be useful to entice blockchain developers to rely on them to increase throughput under the impression that it’s delivering higher throughput for free with no apparent drawbacks.

Once entrenched, the CRN could then later on, proceed to increase its fees and extract rent out of the very protocols that wish to disrupt rent-seekers.

Displacing the entrenched: An option?

A misbehaving CRN should be easy to deal with, right? Let’s consider a victim blockchain community’s options.

(i) Completely eliminate their reliance on CRNs: Community sentiment against CRNs could lead to protocol developers completely doing away with CRNs from their architecture. Blockchains that increased their throughput by (10^n)x could suddenly see their throughput fall by (10^n)x. Applications built on such blockchains would come to a crashing halt until they are able to migrate all state and logic onto a new high-throughput chain that doesn’t rely on CRNs. Imagine the state of Youtube, Facebook, Instagram in the case where Internet bandwidth reduces from over 100 mbps to a maximum of 10 kbps! Moreover, undoing a CRN integration would require a hardfork! Given such an extreme but credible possibility, application developers building for the long-term might possibly never choose to build on chains that rely on CRNs.

(ii) Replace the CRN with another: To avoid a hardfork and effectively killing the dapp ecosystem built on the blockchain, protocol developers might consider replacing the CRN with another more ‘trusted’ one or run one of their own. However, if Bloxroute is any clue, it takes more than 10 million USD in funding and more than two years of development to set one up. Thus, if blockchains don’t begin with integrating multiple CRNs from the start, they are likely to have little recourse at times of distress.

Eventually, the CRN ecosystem, if it turns out to be profitable to run one, is most likely going to replicate the growth of mining pools and staking infrastructure providers with a few major players dominating the market. However, the failure case for CRNs is very different and comparatively much more detrimental to blockchain protocols. While blockchains can function normally even as pools and infrastructure providers fail by running nodes at homes and remote locations, the CRN architecture described earlier fails to offer an alternative that would not affect the Quality of Service in the face of failure of the CRN.

The honeypot: Goldfinger attacks

Kroll et al. introduce the Goldfinger attack where:

“the attacker’s motivation is based on some incentive outside the Bitcoin economy. Such an adversary might, for example, be a law enforcement or intelligence agency which wishes to see Bitcoin holdings weakened. Equally, an adversary might have significant short positions in Bitcoin exchange markets.”

While Kroll introduces the attack specifically for the Bitcoin blockchain, the attack is valid for any decentralized network. Given the damage CRNs can cause to blockchain networks, they become attractive targets for adversaries seeking to harm such networks. BCH supporters could attack CRNs in an attempt to harm BTC, scammers could collude with CRNs to double spend on some blockchains, governments could use CRNs to impose censorship or even worse ban BDNs to throttle blockchains. In contrast to breaking a truly decentralized network, controlling or killing a CRN and inevitably the blockchains using it is relatively easy (PRISM?). If the CRN is used for propagating transactions as well, companies like Chain Analysis, Elliptic and CipherTrace could work with the CRN to receive additional data to deanonymize transactions. 

Stripping governance

A post by Dragonfly Research had caught everyone’s attention on how the ecosystem built over MakerDAO has made Ethereum unforkable. CRNs could be a similar dominant force in maneuvering discussions around forks. We have discussed earlier the shortcomings in a CRN’s ability to be neutral to a network’s participants. What’s even more certain is a CRN’s ability to censor a complete network. Consider the situation where Ethereum achieves a throughput of 15,000 tps using a CRN and conversations around a contentious hard fork start to arise. If the shareholders of the CRN support (naturally or through some off-band incentivization) a particular fork ECH of ETH, the choice community members, dapp developers and users would have is to tag on to ETH with a throughput of 15 abandoned by the CRN or migrate to ECH delivering the experience everyone was used to.

So, are relay networks fundamentally bad? 

Quite the opposite! Centralized relay networks are great. They ensure that a larger fraction of hashpower is spent securing the main chain. In fact, there’s little that can be done to avoid the existence of private relay networks. Most protocols indirectly incentivize their creation. Large bitcoin mining pools have the ability to transmit blocks to one another in a single packet irrespective of their size through private coordination. This unfair advantage is grave enough that Matt altruistically runs a relay network at his own expense (to allow for a more diverse topology), actively encourages other operators to run independent FIBRE networks while Bitcoin limits the block size to ensure that the efficiency gains through such centralized schemes are minimal (there are many more reasons for imposition of such a limit such as initial sync time, full node storage and validation requirements etc. that are beyond the scope of this article). 

The deficiencies lie in the mechanisms used to guarantee trustlessness when such private relay networks are promoted as scaling solutions of radical magnitude. It's under such circumstances that the relay networks become the difference between a chain being centralized or decentralized as the permissionless peer-to-peer propagation of blocks via gossip protocols no longer remains a viable alternative. 

The way forward

Careful optimizations at the network layer have the potential to significantly improve the performance of blockchains. However, such performance improvements are inconsequential if  they come at the cost of security and decentralization, the very tenets that make blockchains unique from high performance databases. Issues mentioned with respect to CRNs above stem primarily from their centralized control which gives them the capability to censor, partition, double-spend, snoop on and ultimately destroy blockchain networks and their users. 

Just as developers can anonymously contribute to codebases, for miners and full nodes to anonymously verify transactions, we require a network layer that allows unrestricted communication between such parties. In an age where protocols like Handshake and Rightmesh seek to replace existing centralized naming systems and ISPs, building centralized CRNs with an intention to monopolize is anachronistic. 

Marlin is being built on the premise that several CRNs would have to co-exist, if at all, in order to provide the randomization and redundancy necessary to ensure security, censorship-resistance and avoid monopolistic or oligopolistic control by any one actor or coalition. Swarms of such CRNs would benefit by cooperating with one another rather than competing, eventually forming one large mesh. Incentivization will be necessary to prevent misbehaviour and ensure that nodes are distributed as widely as possible. Such networks would charge the marginal cost of providing the service offering maximum utility to its users, just as decentralized networks are meant to be.

You can dig deeper by checking the first iteration of the architecture here. Subscribe to our blog to stay tuned with the developments at Marlin. 

Make sure to follow us on Twitter to not miss our future blog posts and other announcements.

Lastly, the best channel to learn about our progress towards the launch is to subscribe to our newsletter.

Twitter | Telegram Announcements | Telegram Chat | Discord | Website