A decentralized application (dApp) consistently requires data from the blockchain to complete user requests such as sending transactions, retrieving block data, or evaluating the state of the blockchain. Nodes enable this function through Remote Procedure Calls (RPC) which connect dApps to the blockchain. RPC nodes enable web3 applications to interact with the blockchain and access user data easily. 

In this article, we will dive into what an RPC node is and how they work. By the end, you will have a firm understanding of RPC nodes, endpoints, and how to use an RPC node provider.

What is a remote procedure call (RPC)?

A Remote Procedure Call, or RPC, is a lightweight software communication protocol, which allows a program (the client), to communicate with a remote program (the server) hosted on a different network without needing details about the server’s network.

For example, you may use an RPC from your local computer to request resources from a remote server system. Once the client makes a request, it prompts the server to execute a procedure, called a subroutine. 

In blockchain, a dApp requires blockchain data to function correctly. As such, in the RPC client-server model, the dApp is the client and the server is an RPC node.

What is an RPC node?

An RPC node is a computer running blockchain client software — for example, a server running both an Execution Layer (EL) and Consensus Layer (CL) infrastructure for the Ethereum blockchain. 

There are multiple types of Ethereum nodes including light nodes, full nodes, and archival nodes. In contrast, on Solana, developers can run both validator and RPC nodes. While the validator nodes run the Solana consensus protocol and earn rewards on block validation, Solana RPC nodes merely serve as a gateway for a Solana dApp to obtain blockchain information.

For the purposes of this article, we will consider any node that has the ability to respond to RPC requests as an RPC node.

What is an RPC endpoint?

An RPC endpoint is the network location where a program sends its RPC requests to access the server’s data. For example, after connecting your dApp to an Ethereum RPC endpoint, you can easily perform operations that make use of blockchain data in real-time.

A node with the proper software installed will have the ability to respond to RPC requests. An RPC endpoint running on a node refers to the service through which your dApp will retrieve blockchain information for its users. Accordingly, all RPC endpoints run on RPC nodes, and all RPC nodes are nodes with RPC endpoints. Thus, we will use the terms RPC node and RPC endpoint interchangeably. 

What are the different types of RPC endpoints?

Node RPC endpoints are categorized into two main infrastructure offerings: public and private. Alternative RPC endpoints support these two by helping applications maintain fault-tolerant backups for their RPC endpoints.

1. Public RPC Endpoint

Public RPC Endpoints are shared, rate-limited resources which run on RPC nodes available for any person to make requests to. Blockchains offer public RPC endpoints because they allow anybody to send and receive data from the blockchain (e.g. make a transaction).

Public endpoints are free and ready to use at any time, and because they are not meant to support production-grade applications, they are often rate-limited. Further, public RPC endpoints have no customer support, lack active developer infrastructure, and do not scale to the demands of running dApps.

2. Private RPC Endpoint

Private RPC endpoints are those that operate in order to service your dApp’s needs alone, avoiding request congestion created by other programs and benefiting from a fast and consistent RPC service. 

Private RPC nodes run at your request. Additionally, if you’re using a node provider, private RPC endpoints often maintain explicit service-level agreements (SLAs), guaranteeing your dApp performant service, whenever you need it.

For example, Alchemy offers free RPC nodes for Optimism.

3. Alternative RPC Endpoint

If your RPC endpoints experience downtime, an alternative RPC endpoint act as backup endpoints that help your dApp maintain a smooth user experience. 

Without an alternative RPC endpoint available, if your primary RPC endpoint fails, so will all of your user’s transactions. Building a dApp with an alternative RPC endpoint is a great practice to guarantee there is no single point of failure.

How do RPC nodes work?

RPC nodes function by connecting a dApp to all of the blockchain’s information. When a program initiates a subroutine, an RPC node is able to retrieve the necessary requests through the blockchain and send its payload back to the dApp. 

In this section, we will briefly unpack the technology behind blockchain RPC requests.

The JSON-RPC Protocol

The standard RPC specification used in blockchains is called JSON-RPC. It is notable for its ability to receive and process requests for data quickly. 

Recalling the client-server model, your dApp is the client, your RPC endpoint is the server, and JSON-RPC is the specific methods through which you request services from the RPC endpoint.

Using methods outlined by each blockchain’s JSON-RPC API, you can request essentially any type of blockchain data your dApp could possibly need.

As an illustration of the diversity of JSON-RPC methods, Ethereum denotes a set of core methods that get data from the Ethereum network. These methods are divided into three categories: gossip methods, state methods, and history methods.

1. Gossip Methods - tracks the head of the blockchain and is used for finding blocks
2. State Methods - returns reports on the current state of all the blockchain’s data
3. History Methods - retrieves historical records of any block on the chain

Whenever a user’s action relies on blockchain data, the application (client) will use JSON-RPC methods to make calls (subroutines) through the RPC node (server) which will return information to be used by the application.

How to Access RPC Nodes

There are three main ways for developers to access RPC nodes: using a private RPC endpoint from an RPC node provider, running their own node (i.e. a self-hosted node), or by sending traffic through a public RPC node.

1. Use an RPC Node Provider

RPC node providers handle all node setup, management and maintenance for your dApp and ensure that it’s running smoothly, and is the best practice for the majority of web3 builders.

Therefore, by choosing a node provider, all node setup and maintenance responsibility is relieved from the developer. The top blockchain node providers have these features integrated natively, saving developers time and energy to focus on building innovative end-user products.

Node providers are available for most leading blockchains such as Ethereum and Solana and also Layer-2s like

How to Get Started Using Alchemy’s RPC Node Infrastructure

Alchemy offers Ethereum, Solana and Arbitrum RPC node endpoints among others. You can get sted with a high-performing, Alchemy RPC node in a just a few clicks.

1. Create an Alchemy account.

2. Create your first app by using the Create App button on the dashboard.

3. Name your app, select the desired blockchain, and network.

4. Use the "View Key" button on the dashboard and copy your new node’s URL to begin sending it RPC requests

How to Run Your Own RPC Node

While there are benefits and tradeoffs of running your own node, it is an option for technical developers and web3 teams that need complete control over how their node is configured. Here, we will describe, at a high-level, the steps to starting your own node on the Ethereum blockchain. 

1. Choose Your RPC Node Configuration

Ethereum nodes are composed of three components: client implementation (e.g. consensus client and execution client), hardware and system environments, and settings. Let's review these at a high level.

Client Implementation

This means choosing node client software for your execution layer (EL) and for your consensus layer (CL). ELs include node clients such as Besu, Erigon, and Geth. Consensus Layer clients include those such as Lighthouse, Teku, and Lodestar.

Hardware and System Environments

You need to install your client software on hardware capable of running the clients. Your hardware needs will vary depending on the clients you choose and the blockchain on which you are building. For example, running Solana nodes have higher hardware clients than Ethereum. To see hardware specifications, refer to the blockchain's documentation. 

Developers can either choose to build their own machines, or purchase hardware from a provider of hardware systems designed specifically for running nodes. The cheapest general node machine by an industry leading hardware provider, dAppNode, costs over $1,500.

Client Settings

One of the main benefits of running your own node is the level of customizability. You can easily configure the node during setup based on your hardware and software requirements and any specific client requests.

2. Spin Up an RPC Node

Once you have made all your hardware and software decisions, it is time to start up your node. You can either select a guided setup service, which will give you a user-friendly user interface (UI) to make your client setup decisions through, or set the node up manually using a Command Line Interface (CLI).

The high level steps are:

1. Install both pieces of client software (EL and CL)
2. Start both clients, completing the setting configurations you decided upon

Afterwards, your node will sync with the blockchain. Depending on the speed of your hardware and the size of the blockchain's historical state, this can take anywhere from a few days to several weeks.

The lengthy sync process is one tradeoff of running your own node. If you need more capacity, it can take days or weeks to spin up a new node, whereas a node provider can provide extra capacity on demand.

3. Maintain Your RPC Node

Maintenance costs is another tradeoff of running your own node. Nodes are intermittent and can go down, fall out of sync, and fail for a number of reasons. Additionally, the execution layer and consensus layer software will constantly be upgrade by node client software developers.

Why is an RPC node provider better than running your own RPC node?

Aside from saving you time and resources spent on node management, node providers can guarantee 24/7, reliable, low-latency node access. Your node will be serviced by an experienced team dedicated solely to the high-performance of your RPC node. 

Deciding to run your own node is a great choice for extremely high levels of customizability, but not for a smooth and painless developer experience. 

How to Send Traffic Through a Public Node

Depending on which blockchain you’re using, you can send requests by referencing your network’s documentation for public RPC endpoint offerings and routing traffic through that URL. Some blockchains, such as Solana, offer access to a limited number of public RPC nodes.

Below is an example of a curl request made using a Solana public RPC node.

curl /* Solana public RPC endpoint URL here */ -X POST -H "Content-Type: application/json" -d' 
{  
"jsonrpc": "2.0",    
"id": 1,    
"method": "getBalance",    
"params": ["83astBRguLMdt2h5U1Tpdq5tjFoJ6noeGwaY3mDLVcri"]  
}

Note, however, that your requests will be rate-limited on public endpoints, and it is not a recommended practice for developers.

Start Building with Alchemy's Free RPC Nodes

There are three ways to connect to RPC nodes: using a node provider like Alchemy, running your own nodes, and sending traffic through public nodes. Because running your own node requires a lot of unnecessary overhead, and public nodes are heavily rate limited, taking advantage of Alchemy's large free RPC node tier is the best option for the majority of web3 builders.

Ready to start using managed RPC nodes to make your development experience smoother? Sign up for Alchemy and get started with a free RPC node!

‍