Sei is a high-performance blockchain that aims to power modern decentralized applications. The network is designed to facilitate thousands of transactions per second, and web 2-like user experiences. However, in order to read and write data to the blockchain and operate high performance applications, developers need access to  something called an “RPC”.

An RPC node is a computer that lets anyone “communicate” with the blockchain. For example, it lets you read data (e.g. how many NFTs do I have in my wallet?) and it lets you write data (e.g. send my friend some SEI tokens).

Importantly: the RPC node succeeding or failing is independent of the stability or liveness of the underlying blockchain network; these are two separate things.

A good analogy was proposed recently by Twitter power user and Solana infrastructure provider @0xMert_ :

“think of the blockchain as your mobile network, and the RPC node as your phone. If you suddenly stop getting reception because your mobile network went down, it is not due to your phone”

Similarly, if your phone overheats and the battery expands in the sun, your screen cracks or your phone runs out of power, that doesn’t mean that there’s a problem with the mobile network.

Some things high performance RPCs can help with: 

• speed of reading data, 
• reliability/accuracy/freshness of data, 
• writing data faster

On Sei, various third-party providers operate RPC endpoints that allow developers to communicate with Sei nodes without needing to set up their own infrastructure. The RPCs act as messengers that relay information between the Sei blockchain and applications.

For a more in depth discussion, keep reading:

What is an RPC?

Remote procedure calls (RPCs) are a key building block of blockchain networks. Without RPCs, Web3 apps would have no way to query account balances, submit transactions, or retrieve on-chain data to provide services to users. 

At its core, a RPC enables seamless communication between two programs - a client and a server. The program making the call is referred to as the client, while the program running the procedure is known as the server.

The client program can request the server to execute code functions and procedures, without needing to understand the precise details of the server environment. This abstraction is what makes RPCs a lightweight, flexible communication protocol.

In the blockchain context, decentralized applications play the client role, as they need to frequently query chain data to function. RPC nodes, running software that interacts with the blockchain, act as servers - receiving requests and running procedures on behalf of the calling dApp client. 

This allows the dApp code to focus on front-end logic and user experience, trusting RPC nodes to handle back-end blockchain interactions unseen.

From a dApp developer perspective, calling a procedure on-chain via RPC closely resembles calling a local library function. The networking, execution, and return value handling details are encapsulated. 

How Blockchain RPC Nodes Work

RPC nodes communicate via the JSON-RPC protocol. This allows for fast sending and processing of blockchain data requests. Nodes can provide data on the current state of the chain, transaction history, and so on.

Any node —  whether light, full or archival — that is capable of responding to RPC requests, could be seen as an RPC node.

Types of Node RPC Endpoints

RPC Nodes and RPC Endpoints serve related but distinct roles.

RPC Nodes are servers running complete blockchain nodes that process transactions and maintain the network. Besides this primary function, nodes also surface endpoints that applications can query for data.

RPC Endpoints are those access points provided by RPC nodes that apps leverage to submit requests and read on-chain information without deploying their own full nodes.

There are a few primary kinds of RPC endpoints that applications use to interact with blockchains:

• Public Endpoints are made available by blockchain networks and node operators to enable anyone to access on-chain data. Since they are shared access points, limits are often set to prevent overuse.
• Private Endpoints are configured for a single application by infrastructure providers. They offer better performance, reliability and support compared to crowded public options.
• Some apps also employ Alternative Endpoints as secondary connections that take over if the main endpoint experiences downtime. This serves as a backup against potential failure.

Advantages of RPCs

Abstraction and Transparency

One of the most remarkable benefits of RPCs lies in their ability to access procedures on remote servers by calling them like local functions. 

Developers can call remote functions using familiar procedural syntax, abstracting the complexities of distributed networking. This simplifies coding distributed applications without the need to manage low-level communication details. 

Minimized Code Changes

Distributing existing functions using RPCs requires few changes. Code rewritten for RPC libraries keep the same syntax for local/remote procedure calls.

Programmers are then able to deploy program logic across machines without learning specialized networking protocols.

Decoupling Application Logic and Infrastructure

RPCs decouple application functional code from distributed computing infrastructure. 

With this, dApp developers can focus on business logic. The RPC framework will handle networking mechanisms like sockets, serialization, and error handling behind the scenes.

Disadvantages of RPCs

Performance Overhead

RPCs have more performance overhead versus direct function calls within the same process. 

Every remote call must serialize/deserialize data, send it over the wire, then have the receiving end deserialize and process it. For small bits of data this may be negligible, but for larger payloads it can become quite costly. 

For example, trying to send multi-megabyte packets of data via frequent RPCs would incur a major bottleneck. Optimizations like batching can help, but that adds complexity.

Reliability Challenges

Because RPCs rely on networking protocols, they are more prone to potential failures compared to direct function calls within a single program. 

There are more failure points — networks can drop packets, run into congestion issues, or have cascading problems that would not affect in-process calls. 

This forces developers to implement resiliency patterns like retries, heartbeats, failovers, etc. All this complicates application logic, and is especially problematic when trying to transfer large volumes of data between the client and server.

Simple function calls within the same process are inherently more reliable.  

Lack of a Uniform RPC Standard

Unlike protocols like HTTP and WebSockets, RPC frameworks have no uniform standard. Popular options like gRPC, Thrift, Avro, and others are not compatible. A gRPC client, for example, can not easily call a Thrift server. At least not until there’s a clear, widely used RPC standard.

This can create vendor lock-in and make it hard to write reusable code — limiting the ability to write code that works across different platforms.

Tight Coupling

RPCs tightly couple the client to the server APIs. Tying the client and server together so closely reduces flexibility in reconfiguring one or the other independently. As a result, adding or altering RPC endpoints requires coordinating changes across both sides rather than just modifying a standalone microservice.  

Thankfully, loose coupling approaches like asynchronous message passing can isolate services more. This allows for more modular architectures.

TLDR?

It's important to distinguish between the Sei blockchain itself and Sei's RPC endpoints. Ultimately, the Sei chain will keep running even if all RPCs fail.

The Sei blockchain is the foundation of the network — an ultra-fast decentralized ledger. It maintains consensus, security, and data integrity independent of any applications built on it.

Sei RPCs are interfaces provided by nodes that allow external applications to read data from the chain and write transactions to it. They act as messengers that relay requests and information between dApps and the underlying Sei blockchain.

While the Sei chain itself keeps running, the RPCs are necessary for applications to pull data on-chain. So RPC outages prevent dApps from reading or writing info, but don't halt the core network.