Centralization Vulnerabilities in Crypto Infrastructure
0xA334
August 4th, 2022

Decentralization is one of the main selling points crypto has to offer, but few talk about (or turn a blind eye to) the fact that a large portion of the space, infrastructure in particular, is centralized or relies on centralized services.

Essentially how a dApp communicates with a blockchain
Essentially how a dApp communicates with a blockchain

A dApp that wants to communicate with an external blockchain network (Ethereum) would need something called Remote Procedure Call (RPC) Nodes. The process goes like this:

The dApp sends RPC requests to the nodes, and the nodes submits the RPC request execution to the external blockchain. The external blockchain sends the RPC response back to the dApp, through the nodes. This is what a decentralized process would look like, but for this to happen you would need full nodes, and running full nodes is costly and takes up a lot of effort.

This is where external RPC providers like Infura come in. Infura hosts their own full nodes and anyone that uses Infura gains access to Infura’s full nodes. So a dApp can just opt to use Infura instead of running and maintaining their own full nodes.

dApp using Infura to communicate with an external blockchain
dApp using Infura to communicate with an external blockchain

The diagram above is meant to show how a dApp can use Infura’s full nodes to communicate with an external blockchain network. It’s a similar process to what was described before. The dApp sends RPC requests to Infura’s nodes, Infura’s nodes submits the RPC request execution to the external blockchain, the external blockchain then sends back the RPC response to the dApp, through infura’s nodes.

The problem lies in the fact that Infura itself is not fully decentralized and is reliant on Amazon Web Services. This opens up the possibility for the compromisation of data and a lack of privacy as data has to go through Infura’s RPC nodes.

A large portion of crypto infrastructure is reliant on centralized services like Infura and AWS. Per 2019, about 25% of Ethereum nodes were run on AWS, while 5.5% were on Alibaba Cloud, 5.4% on Google Cloud and another 16.6% on other different cloud computing services. That’s over half of Ethereum nodes dependent on centralized services at the time.

source: ethernodes.org
source: ethernodes.org

Today, its 59.6% on AWS, 2.1% on Alibaba Cloud and 3.6% on Google Cloud. That’s more than half of Ethereum nodes dependent on a single centralized entity.

This not only goes against decentralization, but it presents a potential single point of failure. Back in late 2021 when AWS servers went down, “decentralized” exchange dYdX went down with it.

Or 2020 when Infura suffered outages and Ethereum dApps suffering alongside it

A lot of dApps on Ethereum rely on Infura while Infura itself relies on AWS servers, so if either one of the two goes down, so do all those dApps.

If decentralized applications are dependent on centralized services, then they’re not decentralized

What is the solution?


Pocket Network

Pocket Network is an interesting proposition and one of many possible solutions to the centralization conundrum

Pocket network is a decentralized, middleware relay protocol that provides dApps access to communicate with external blockchains.

TCP/IP is what allows your computer to communicate with the internet.

Middleware is software that helps developers build applications more efficiently. More on middleware can be read here:

How Pocket Network is Different to Infura

What differentiates Pocket Network to Infura is:

  • Decentralization
  • Resistance to network down times and censorship

What makes it decentralized?

Infura runs their nodes “in-house” and dApps use Infura services to gain access to their nodes.

Pocket Network don’t actually own a lot of nodes that are running on their network. The large majority of nodes running in Pocket Network are external, third-party node runners or validators that are incentivized to run and maintain their own nodes.

Largest node runners in Pocket Network per block #55807. source: poktscan.com
Largest node runners in Pocket Network per block #55807. source: poktscan.com

By using Infura, data goes through Infura itself which presents potential privacy issues as a compromising third party could view and abuse the data.

Pocket Network avoids this by relaying small different chunks of data through different, randomly selected nodes. By doing this, since a single node can only view a small random chunk of the data, no single node will be able to view the entire data thus addressing potential privacy and security issues.

What makes it resistant to down times?

Geographical distribution of Pocket nodes runners in the world. source: poktscan.com
Geographical distribution of Pocket nodes runners in the world. source: poktscan.com

There are multiple different, independent external Pocket node runners that are scattered all over the world. If one set of nodes goes down, the protocol will reroute your RPC request to other available nodes.

In a scenario where all nodes in North America go down, dApps reliant on Pocket Network will continue to be live as they can connect and rely on Pocket node runners located in Europe and/or Asia.


How Pocket Network Works

It’s an identical process to what was discussed before. The dApp sends RPC requests to Pocket nodes, Pocket nodes submits the RPC request execution to the external blockchain, the external blockchain then sends back the RPC response to the dApp, through Pocket nodes.

What’s different this time is that Pocket network names their mechanism of regulating communication between dApps and nodes as sessions. When a dApp wants to use Pocket nodes, they would be put into a session where they are then pseudo-randomly connected to a set of nodes based on an algorithm for a limited time period. After this limited time period, the nodes connected to the dApp are tumbled and switched up to other nodes to promote privacy and security, while avoiding dependency on one particular set of nodes


Incentives and Tokenomics

Incentives are the bread and butter on how Pocket Network works. It’s what attracts validators to want to run their nodes in Pocket Network.

For validators/node runners:

  • To run a Pocket node you need to stake 15,000 $POKT
  • They need to stake $POKT to run nodes because it keeps them honest about servicing relay requests
  • Pocket node runners then earn rewards in $POKT based on the number of relay requests they service

For dApps:

  • dApps wanting to access pocket nodes would need to stake $POKT, however, the amount they stake will depend on the amount of RPC relay requests they would need.
  • More $POKT staked = more amount of RPC relays you can request
  • So the larger, more congested the network, the more RPC relay requests you’d need, the more $POKT you’d need to stake

There’s a chain of events where the more POKT staked by a dApp, more RPC relays the dApp can request per session. The more RPC relays requested, the more rewards for node runners. More rewards for node runners attracts and incentivizes even more node runners which theoretically creates more demand for $POKT which is needed to be staked by validators.


Conclusion

Centralized node providers like Infura are similar to SaaS companies where you pay a recurring subscription fee to access its services. In Pocket Network, you need to stake POKT tokens to access their services.

It’s a “stake to subscribe” model, where staking $POKT is a “membership” to Pocket Network and its nodes (from dApp’s POV) and it’s rewards (from validator’s POV). As long as you stake $POKT, you have membership or “one-time subscription” and once you un-stake $POKT, you lose access to pocket network.

In a landscape that’s constantly scaling, to remove centralized authorities and fulfill the promise of full decentralization, protocols like Pocket Network could be a possible step towards a truly decentralized space.


Thanks for reading. If you want to get notified about future posts or give any input/feedback, subscribe and follow me on Twitter. Or don’t. It’s up to you.

This article was first published on 12 April 2022 in Substack. Minor edits were made for formatting, updating data and any mentions of “Web3” were replaced. Thank you and goodbye.

Subscribe to knarb
Receive new entries directly to your inbox.
Collectors
View
#1
#2
#3
View collectors
This entry has been permanently stored on-chain and signed by its creator.