Your dApp Is Vulnerable - Here’s What’s Causing It

RPC (Remote Procedure Call) Nodes are critical components of the blockchain infrastructure. They handle the communication between the decentralized immutable ledger and front-end applications. These intermediary infrastructures act as the messenger facilitating the requests and responses between nodes and services built on a blockchain.

RPC nodes are just like the United States Postal Service (USPS), which facilitates the movement of information from the dApp to the blockchain and back. Just as you rely on the postal service to get your mail from one point to another, dApps depend on RPC nodes to access the blockchain. And without these nodes, decentralized applications will struggle to function.

RPC nodes have evolved significantly over the last 10 years, but the centralization of the infrastructure has introduced a hidden vulnerability. This article aims to explore the role of RPC nodes, the danger of centralization, and the alternatives that can protect your dApps from vulnerabilities.

Evolution of RPC Infrastructure

The idea of remote procedure calls dates back to the 1970s when computer scientists sought ways to communicate between different machines to make distributed computers transparent to developers.

In the 1980s, the first RPC was developed by Sun Microsystem called Network File System. Sun Microsystem developed the Open Network Computing RPC protocol, and this has become a standard for communication between different programs on a network.

However, in the early 1990s, Microsoft developed and implemented its version of RPC to enable communication between processes on Windows-based systems. In the early 2000s, JSON RPC, which uses JSON  for data encoding, was introduced. It became infamous among developers and programmers because of the easiness to transfer standardized data.

Over the past decade, dApps have become an important part of the blockchain industry and RPC has been a perfect infrastructure needed to complete the maze.

Why?

1. Its ability to make a remote function call on another computer like a local function call is perfect for the blockchain architecture.
2. Its statelessness and lightweight empower the blockchain and are helpful in bandwidth and compute constraint situations.

Because of the benefits, RPC quickly became widely used. RPC was proposed to enable applications written in different languages to connect and communicate. The basic idea behind RPC is to make a remote function call on another computer or server as if it were a local function call.

Over the years, there have been three main types of RPCs (Centralized, Decentralized, and Self-Hosted) and each is unique in its way.

The Danger of Centralized RPC Nodes

Centralized RPC nodes are nodes managed and controlled by a single entity. These centralized nodes have models that resemble web2 cloud hosting services like AWS (Amazon Web Services), Microsoft Azure, and Google Cloud Protocol (GCP).

Although these centralized web3 RPC providers maintain node infrastructure for decentralized applications, a deep look into the system revealed how centralized they are. These web3 infrastructure providers are ironically also depending on the web2 cloud hosting server infrastructure to maintain their services.

So, when these cloud providers experience outages, the web3 services, which are meant to be decentralized, also experience downtime. Here are examples of centralized RPC nodes: Alchemy, Infura, Quicknode, etc.

Let’s check out the dangers posed by centralized RPC nodes to web3 infrastructure.

1. Single Point of Failure: Having a single point of failure always impacts system reliability. A single server or a network of servers controlled by a single entity will introduce a critical point that could lead to the failure of your dApp.

   
   

   

   
   

   If the server the data is routed through fails, the link between the blockchain and the dApp becomes broken and the system fails. A single point of failure will affect the reliability of the system especially in financial-related apps like DeFi platforms.

2. Scalability Issue: Centralized RPC nodes can become bottlenecks in times of high traffic and this limits the scalability of the dApp. When a network is congested because of reliance on a single node, it affects the efficiency of dApps and increases latency, which affects users.

   
   

   Because it’s a centralized system, increasing the scalability of the dApp is impossible.

3. Security Risk and Vulnerability: A centralized or dedicated node is open to vulnerability and can be an easy target for unscrupulous individuals. Data can be exposed and manipulated, and ultimately affect decision-making in dApps.

   
   

   Moreover, a coordinated attack on the provider can also be easily implemented, ultimately exposing the users of the Dapp. A single entity can be forced by government agencies to shut down an application.

   
   

   Here is an example:

   
   

   In 2022, MetaMask allegedly blocked users with Venezuelan and Iranian IP addresses from conducting transactions on the blockchain.

   
   

   This was possible because of the centralized RPC (Infura)used by the web3 wallet.

Case Studies of Centralized RPC Nodes Failures and Vulnerabilities

Centralized RPC may look like they’re safe but they are not. Still, in doubt about this, let’s check out some case studies about past failures of centralized RPCs.

The Case of Infura

Infura is one of the first blockchain Backend Infrastructure as a Service (IaaS) providers in web3, brought to you by consensus. The infrastructure is claimed to be available for 99.9% uptime and available to 16 blockchain EVMs.

Up until 2020, Infura has been considered a hero, as one of the frontiers for dApp developments and leading the mass adoption of crypto/blockchain.

On November 11, 2020, Infura experienced a service interruption due to a bug affecting the version of GEth run by Infura.

The main issue here is that the Infura system was down and all Infura infrastructure users couldn't connect to the blockchain. Servers were disrupted because of a bug, and the risk of centralization behind a decentralized network was revealed.

Metamask, the largest consumer-facing Ethereum wallet with millions of active users was disrupted. All because they rely on Infura, a centralized RPC provider.

Centralization Concerns During Network Upgrades

During network upgrades/hardforks, there are usually concerns about service failures especially concerning dAapps relying on centralized infrastructure providers. These concerns include:

Single point of failure, which can disrupt activities and lead to downtime.

Here are some past examples:

• During the Ethereum Istanbul hardfork in 2019, many centralized RPC providers experienced downtime. Some of these downtimes are as a result of the network going through upgrades. DeFi Apps are unable to process transactions, leaving users in limbo.

  
  

• During the Polygon Heimdall Upgrade, RPC service providers faced connectivity issues and weren't synchronized with the blockchain network. Users couldn't access DeFi dApps for several hours, so, transactions were delayed or failed.

Solana RPC Overload in 2021

Solana experienced many outages in 2021. One of the infamous outages is caused by the overloading of centralized RPC services during peak periods. As the public nodes became overwhelmed, users couldn't interact with Solana Blockchain for several hours and the network faced a full-service halt for many hours.

These cases of facepalms and countless others reveal the importance of RPC providers to blockchain utility.  While centralized providers are still used by many dApps (maybe out of ignorance or thoughtlessness), over the years there have been alternatives.

In the next sections, we’ll walk you through the other alternatives and how they’ve been a great option for blockchain developments.

Decentralizing Your DApp: Top Alternatives to Centralized RPC Nodes

Self-Hosted RPC Nodes

As its name implies, self-hosted RPC nodes are nodes you host or manage on your own hardware or cloud infrastructure. Instead of relying on third-party RPC providers, you can host your own RPC nodes. You gain direct access to the blockchain network, validate transactions, query blockchain data directly, and interact with the dApps.

Benefits of a Self-hosted RPC Nodes include:

1. Autonomy/Control: running your nodes means you have full control over the nodes’ configurations. You can customize the software to suit your needs, apply updates at your discretion, and manage security.

2. Reliability: you don't have to look for service outages, or failure due to provider issues, common to third-party centralized nodes.

3. Direct Network Access: running nodes on your infrastructure means you are responsible for their services, you have low latency access to the blockchain network.

While self-hosted nodes look to be more reliable than their centralized alternatives, they have their disadvantages. And here they are:

1. High Resource Requirements. Hosting an RPC node requires significant disk space to store the blockchain history. The storage, bandwidth, and processing power needed to run RPC nodes can be overwhelming.

   
   

   Moreover, you need constant synchronization with the blockchain, and this can consume a large amount of bandwidth which can be overwhelming. The processing power required can also be overwhelming, especially when processing information during high-traffic situations.

   
   

2. Expensive to Manage: setting up self-hosted nodes seems to be a better option, but it isn’t. The hardware cost, operational cost, and opportunity cost can be overwhelming.

   
   

   The operational costs such as electricity, internet bandwidth, and cloud service fees (if you use cloud infrastructure) can be overwhelming. To run a successful node, you need a dedicated team of experts to be on standby to fix any problem or you risk outages for several hours.

3. Complex Setup and Maintenance: You need a solid understanding of blockchain technology, server management, and security best practices. Regular maintenance to avoid outages like software updates, security patches, and hardware upgrades to keep nodes working properly.

4. Limited Scalability and No Support for Multichain: Unlike third-party providers with the models to handle this problem, to interact with multiple blockchains, you need to host nodes for each blockchain which can be resource-intensive and unsustainable.

   
   

   Self-hosted nodes provide independence, great control of blockchain interaction, and privacy. They require significant resources, technology expertise, and maintenance, which can be impossible for even the strongest blockchain development team available.

Decentralized RPC Nodes

Decentralized RPCs are the blockchain servers that allow dApps to communicate with the blockchain in a decentralized manner. The decentralized RPC providers distribute their infrastructure across multiple nodes. This reduces single point of failure, enhances network stability and scalability, and reduces latency.

Benefits of Decentralized RPC nodes over others include

1. Distributed Network: the distributed network of node providers are working to process requests, respond to queries, and interact with the blockchain.

2. Operations are Trustless: Not trusting a single provider. Requests are distributed across multiple providers ensuring no single party has complete control over data or requests made.

3. Censorship Resistance: Since RPC nodes are not located in the same jurisdiction, the entity/authority can’t easily censor, block, or restrict access to the blockchain. If an RPC infrastructure shuts down due to policies from a jurisdiction, the dApp’s requests can be routed to other RPC nodes from a different jurisdiction.

4. Fault Tolerance: The decentralized model of RPC services makes them resistant to outages. If a node is brought down, another will replace the service. This reduces downtime and ensures consistent availability.

Challenges include:

1. Latency: If not set up properly, decentralized RPC services can introduce latency as it could be routed through several nodes. The decentralization of the RPC nodes can easily become redundant, and as a result of this, data can be routed through multiple servers increasing latency.

2. Security: since nodes are managed by different entities, nodes may not be equally secured.

3. Consensus Among Nodes: ensuring consistent and reliable data can be challenging. Mechanisms need to be in place to detect and mitigate malicious/faulty nodes.

Examples of Decentralized RPC nodes include:

dRPC, Pocket network, and Ankr

Best Practices to Avoid Centralization Risk in dApp Development

1. Diversification of Node Providers

With the selection of decentralized RPC node providers like dRPC, you can avoid centralization risks. Decentralized RPC providers have systems in place to ensure nodes work as required features like load balancers, node provider monitoring, and incentives for good actors.

For example, dRPC provides you access to a dashboard for monitoring the diversification of your node infrastructure. Even though you don’t have direct control over what nodes you use and how decentralized it is, the dashboard lets you see how decentralized the nodes are.

A look into the above image showed that the connection is decentralized between four different RPC node providers (Besked, drpc-free, drpc-public-multiregion, p2p-validator-optimism-free). An 0.563 decentralization index showed a cumulative number of the level of decentralization with “one” being the most decentralized and “zero” being the most centralized.

2. Monitoring and Managing Node Health

Developers should be able to monitor RPC nodes used by their dApp. This ensures the reliability of the dApp. Even though you may not be able to control how the RPC providers manage their systems, decentralized RPC providers like dRPC have systems in place to monitor RPC node providers.

dRPC’s SaaS dashboard gives you access to comprehensive analytics to monitor how your dApp interacts with the infrastructure. In the dRPC dashboard, for example, you can monitor the total number of requests made by your dApp over selected days, monitor RPC node decentralization, and request distribution based on the API key. You even have access to monitor error logs from the dashboard.

Apart from the dRPC analytics dashboard, dRPC has a backend mechanism to monitor node providers and prevent them from going rogue. Read more about these backend mechanisms here.

Conclusion

RPC nodes play a significant role in facilitating the communication between a decentralized application and the blockchain. However, the centralization of RPCs poses a significant risk to your dApp and the blockchain network at large. As seen in the previous failures from the case studies discussed above, relying on centralized RPC providers poses the risk of a single point of failure and can lead to critical service disruption of web3 services.

Developers are not without alternatives. Self-hosted and decentralized RPCs offer reliable solutions that can help build resilient applications. By embracing decentralized RPCs like dRPC, developers can mitigate the risk of centralization and build powerful, resilient, censorship-resistant, and secured applications.