From 244de31263cab8539e1c3955af78068dc6c5cf76 Mon Sep 17 00:00:00 2001 From: Camembear Date: Thu, 8 Jan 2026 09:02:50 -0500 Subject: [PATCH 1/2] add draft of self-managed RPC --- apps/core/content/nodes/self-rpc.md | 88 +++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 apps/core/content/nodes/self-rpc.md diff --git a/apps/core/content/nodes/self-rpc.md b/apps/core/content/nodes/self-rpc.md new file mode 100644 index 00000000..f2c2298b --- /dev/null +++ b/apps/core/content/nodes/self-rpc.md @@ -0,0 +1,88 @@ +## Introduction + +Berachain operates public RPCs at rpc.berachain.com. These serve normal everyday usage by end-users. Even so, some commercial projects route their backend transaction traffic through these public services. This poses reliability and performance risks to those projects. This article explains how to make your systems efficient, and cost-effectively build or rent a substitute for [public RPCs](https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers). + +1. How to use an RPC efficiently + +You can transmit queries through two mechanisms. The most common is ETH-RPC, which involves looking up the server address, establishing a TCP connection to the server, negotiating SSL connection parameters, transmitting the RPC call, then closing the connection. If you're transmitting a few queries and then signing a transaction, this is a reasonable approach. + +However, if you are performing dozens or hundreds of queries per second, this connection overhead adds up quickly. There's a better way: [websockets](https://ethereum.org/bs/developers/tutorials/using-websockets/). WebSocket connections are, in principle, permanent. After you establish them, they can last for seconds or hours. + +In addition to regular ETH-RPC queries, a new category of RPC call becomes available: `eth_subscribe`. You can subscribe for a variety of events: + +- when new transactions enter the transaction pool +- when new blocks appear +- when transactions log events matching given criteria + +Putting this together, we can identify anti-patterns and what to replace them with: + +| Antipattern | Do this instead | +| ---------------------------------------- | -------------------------------------------- | +| Dozens or more connections every second | Persistent websocket connection | +| Polling `eth_blockNumber` for new blocks | `eth_subscribe` to `newHeads` over websocket | +| Calling `eth_getLogs` frequently | `eth_subscribe` for events over websocket | + +Using `eth_subscribe` as a substitute for `eth_getLogs` provides immediate notification of events, dramatically more efficient processing, and suffers fewer transient connection failures. + +2. Inexpensive paid services + +Paid services vary in their approach to pricing, but generally work on a model where you purchase a given amount of API credits, and providers price ETH-RPC calls according to their computational cost. You might expect to see costs of around $1-$2 per 100,000 requests. + +We have a useful list of paid RPC providers on our [developer tools page](https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers). + +3. Running your own RPC + +Running a Berachain node requires two software components - the consensus layer (Beacon-Kit) and the execution layer (bera-reth or bera-geth). These are separate processes, each with their own database and configuration. Berachain provides simple node setup and launch scripts that support this combination, using one of two approaches: + +1. individual "setup" and "run" commands for each of the chain's components + ``` + ./fetch-berachain-params.sh + ./setup-beacond.sh + ./setup-reth.sh + ./run-beacond.sh & + ./run-reth.sh & + ``` +2. a complete "launch a node for me" command that downloads appropriate executables for Beacon-Kit and the execution layer, configures them, installs a chain-state snapshot, and prepares `systemd` units, ready to start. + ``` + mkberanode.sh --chain mainnet --el reth --mode pruned + sudo systemctl start berachain-el + sudo systemctl start berachain-cl + ``` + +You can find both approaches in the Guides repository, and the Quickstart [describes them](https://docs.berachain.com/nodes/quickstart). + +Another common choice is to operate in Docker/Kubernetes. + +## 4. Reliability + +Berachain is setting its RPCs to commercially normal public RPC use limits. The use case enables end users to send transactions, not for running the backend of a service. + +Use RPCs efficiently by caching receipts and logs, and avoiding repeated `eth_getLogs` / `eth_blockNumber` / `'latest'` calls every N seconds. Instead, use websockets and subscribe. + +--- + + - Berachain is setting its RPCs to commercially normal public RPC use limts + + - Use case enables end users to send transactions. + + - Not for running the backend of a service + +- Use RPCs efficiently + - cache receipts and logs + - repeatede getLogs / eth_blockNumber / ('latest') every N seconds + - use websockets / subscribe + +- Options are: + - Free services from Bera community + https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers + + - Public paid services + $42/mo at Quicknode gets you 40M requests + 30 requests/sec all month long + + - Private RPC service you manage + $100/mo basically unlimited, hundreds of request/sec depending on what you provision + + - What about failover? SKIP THIS + Paid services include a lot of redundancy + Roll your own with eRPC https://github.com/erpc/erpc From 91e08cf3a8735868eca5712565e86b3bbed8c8a4 Mon Sep 17 00:00:00 2001 From: Camembear Date: Fri, 23 Jan 2026 15:16:17 -0500 Subject: [PATCH 2/2] rename self-rpc to self-hosted, add frontmatter and sidebar --- apps/core/.vitepress/sidebar.ts | 1 + .../nodes/{self-rpc.md => self-hosted.md} | 55 ++++++++----------- 2 files changed, 23 insertions(+), 33 deletions(-) rename apps/core/content/nodes/{self-rpc.md => self-hosted.md} (66%) diff --git a/apps/core/.vitepress/sidebar.ts b/apps/core/.vitepress/sidebar.ts index d4b78d54..fc8b365a 100644 --- a/apps/core/.vitepress/sidebar.ts +++ b/apps/core/.vitepress/sidebar.ts @@ -311,6 +311,7 @@ const SIDEBAR = { }, { text: "EVM Execution Layer", link: "/nodes/evm-execution" }, { text: "Quickstart: Run A Node", link: "/nodes/quickstart" }, + { text: "Self-Hosted RPC Guide", link: "/nodes/self-hosted" }, { text: "Production Checklist", link: "/nodes/production-checklist" }, { text: "Monitoring", link: "/nodes/monitoring" }, { diff --git a/apps/core/content/nodes/self-rpc.md b/apps/core/content/nodes/self-hosted.md similarity index 66% rename from apps/core/content/nodes/self-rpc.md rename to apps/core/content/nodes/self-hosted.md index f2c2298b..ef733558 100644 --- a/apps/core/content/nodes/self-rpc.md +++ b/apps/core/content/nodes/self-hosted.md @@ -1,8 +1,23 @@ +--- +head: + - - meta + - property: og:title + content: Self-Hosted RPC Guide + - - meta + - name: description + content: How to efficiently use RPCs and set up self-hosted RPC infrastructure for Berachain + - - meta + - property: og:description + content: How to efficiently use RPCs and set up self-hosted RPC infrastructure for Berachain +--- + +# Self-Hosted RPC Guide + ## Introduction Berachain operates public RPCs at rpc.berachain.com. These serve normal everyday usage by end-users. Even so, some commercial projects route their backend transaction traffic through these public services. This poses reliability and performance risks to those projects. This article explains how to make your systems efficient, and cost-effectively build or rent a substitute for [public RPCs](https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers). -1. How to use an RPC efficiently +## 1. How to Use an RPC Efficiently You can transmit queries through two mechanisms. The most common is ETH-RPC, which involves looking up the server address, establishing a TCP connection to the server, negotiating SSL connection parameters, transmitting the RPC call, then closing the connection. If you're transmitting a few queries and then signing a transaction, this is a reasonable approach. @@ -24,13 +39,13 @@ Putting this together, we can identify anti-patterns and what to replace them wi Using `eth_subscribe` as a substitute for `eth_getLogs` provides immediate notification of events, dramatically more efficient processing, and suffers fewer transient connection failures. -2. Inexpensive paid services +## 2. Inexpensive Paid Services Paid services vary in their approach to pricing, but generally work on a model where you purchase a given amount of API credits, and providers price ETH-RPC calls according to their computational cost. You might expect to see costs of around $1-$2 per 100,000 requests. We have a useful list of paid RPC providers on our [developer tools page](https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers). -3. Running your own RPC +## 3. Running Your Own RPC Running a Berachain node requires two software components - the consensus layer (Beacon-Kit) and the execution layer (bera-reth or bera-geth). These are separate processes, each with their own database and configuration. Berachain provides simple node setup and launch scripts that support this combination, using one of two approaches: @@ -53,36 +68,10 @@ You can find both approaches in the Guides repository, and the Quickstart [descr Another common choice is to operate in Docker/Kubernetes. -## 4. Reliability - -Berachain is setting its RPCs to commercially normal public RPC use limits. The use case enables end users to send transactions, not for running the backend of a service. - -Use RPCs efficiently by caching receipts and logs, and avoiding repeated `eth_getLogs` / `eth_blockNumber` / `'latest'` calls every N seconds. Instead, use websockets and subscribe. - ---- - - - Berachain is setting its RPCs to commercially normal public RPC use limts - - - Use case enables end users to send transactions. - - - Not for running the backend of a service - -- Use RPCs efficiently - - cache receipts and logs - - repeatede getLogs / eth_blockNumber / ('latest') every N seconds - - use websockets / subscribe - -- Options are: - - Free services from Bera community - https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers +## 4. Reliability and Pricing - - Public paid services - $42/mo at Quicknode gets you 40M requests - 30 requests/sec all month long +Berachain sets its public RPCs to commercially normal use limits. These endpoints are designed for end users sending transactions, not for running the backend of a service. Commercial projects should provision their own infrastructure or use paid services. - - Private RPC service you manage - $100/mo basically unlimited, hundreds of request/sec depending on what you provision +When choosing an RPC solution, you have several options. Free services from the Berachain community are available and listed on our [developer tools page](https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers). Public paid services typically cost around $42/month for 40M requests, providing roughly 30 requests per second sustained over the month. For a private RPC service you manage yourself, expect costs around $100/month for essentially unlimited requests, with hundreds of requests per second depending on your infrastructure provisioning. - - What about failover? SKIP THIS - Paid services include a lot of redundancy - Roll your own with eRPC https://github.com/erpc/erpc +Paid providers build redundancy into their offerings, but if you're assembling your own multi-provider setup, you'll want a layer that handles failover automatically. [eRPC](https://github.com/erpc/erpc) is one such tool: a fault-tolerant RPC proxy that sits in front of multiple upstreams and manages retries, circuit breakers, failovers, and hedged requests. It routes traffic to the fastest healthy provider, caches responses to reduce upstream load, and provides a single endpoint for your application regardless of how many backends you're actually using.