この状況に心当たりはありますか？あなたは取引ボットを運用しています。ミリ秒ごとに重要で——RPC呼び出しを行うたびにお金がかかります。
あなたは、取引を即時に実行できる高速RPCプロバイダーにプレミアムを支払っています。しかし問題はこうです：RPC呼び出しの90%は書き込みではなく読み取りです。価格を問い合わせ、残高を確認し、メンプールをスキャンするたびに、毎回同じ高額な料金を支払っています。
高速書き込みパスを完全にそのまま維持しつつ、すべての読み取りトラフィックをより安価な一部のチャネルに集約したら、どうなりますか？
これは仮定ではありません。このパターンは「読み書き分離」と呼ばれ、真剣なdApp、ボット、またはインデクサにとって、最も効果的なコスト削減アーキテクチャの一つです。
みんなが感じている課題
正直に言うと、今日ほとんどのプロジェクトは RPC をこう使っています。
while True:
price = web3.eth.call(price_feed_contract) # 読み取り
balance = web3.eth.get_balance(user_wallet) # 読み取り
# ... 条件をチェック ...
tx_hash = web3.eth.send_raw_transaction(signed) # 書き込み
典型的な取引サイクルでは、1 回の取引あたり 10〜50 回の読み取りが行われます。ただし多くの開発者は、すべてのリクエストを単一の RPC エンドポイントにルーティングしてしまいます。多くの場合、それは取引送信スピード向けに最適化されているためコストが高いエンドポイントです。
取引加速 RPC に $X を支払っていて、呼び出しの 95% が読み取りなら、実際には、はるかに安いプロバイダーが同じように処理できたデータ問い合わせに対して $0.95X を無駄に払っていることになります。
これは本質的に価格の問題ではなく、アーキテクチャの問題です——しかも修正策は驚くほどシンプルです。これから詳しく分解して説明します。👇
私たちの解決策：読み書き分離
アーキテクチャはとてもシンプルです：
読み取りクエリ（eth_call、eth_getBalance……） ➡️ BlockPI（安い、安定、アーカイブ対応）
書き込み取引（取引加速 RPC） ➡️ あなたの取引加速 RPC（低遅延での送信）
コードに 2 つのプロバイダーを残して、リクエストを賢くルーティングするだけで、すぐに RPC コストを 60–80% 削減できます。
コード上での動作
実装は非常に簡単。以下は実用的な Python の例です：
web3 から Web3 をインポート
web3.middleware から geth_poa_middleware をインポート
import os
READ_RPC_URL = os.getenv("BLOCKPI_RPC_URL")
WRITE_RPC_URL = os.getenv("TRANSACTION_ACCELERATION_RPC_URL")
w3_read = Web3(Web3.HTTPProvider(READ_RPC_URL))
w3_write = Web3(Web3.HTTPProvider(WRITE_RPC_URL))
w3_read.middleware_onion.inject(geth_poa_middleware, layer=0)
w3_write.middleware_onion.inject(geth_poa_middleware, layer=0)
def get_eth_price():
price_feed = w3_read.eth.contract(
address="0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419",
abi=[{"inputs":[],"name":"latestAnswer","outputs":[{"internalType":"int256","name":"","type":"int256"}],"stateMutability":"view","type":"function"}]
)
return price_feed.functions.latestAnswer().call()
def execute_swap(signed_tx):
return w3_write.eth.send_raw_transaction(signed_tx)
def wait_for_receipt(tx_hash):
return w3_read.eth.wait_for_transaction_receipt(tx_hash)
あるいは、よりすっきりした方法として、リクエストを自動ルーティングできる Web3 ラッパーを使う：
class SmartWeb3:
"""読み取りと書き込みリクエストを異なるプロバイダーにルーティングするための Web3 ラッパー。"""
def __init__(self, read_rpc: str, write_rpc: str):
self._read = Web3(Web3.HTTPProvider(read_rpc))
self._write = Web3(Web3.HTTPProvider(write_rpc))
@property
def eth(self):
return self._routed_eth()
def _routed_eth(self):
class RoutedEth:
def __init__(self, read, write):
self._read = read.eth
self._write = write.eth
def get_balance(self, address, block=None):
return self._read.get_balance(address, block)
def call(self, transaction, block=None):
return self._read.call(transaction, block)
def get_logs(self, filter_params):
return self._read.get_logs(filter_params)
def send_raw_transaction(self, signed_tx):
return self._write.send_raw_transaction(signed_tx)
def estimate_gas(self, transaction):
return self._write.estimate_gas(transaction)
def get_transaction_count(self, address, block=None):
return self._write.get_transaction_count(address, block)
def block_number(self):
return self._read.block_number()
def wait_for_transaction_receipt(self, tx_hash, timeout=120):
return self._read.wait_for_transaction_receipt(tx_hash, timeout)
return RoutedEth(self._read, self._write)
w3 = SmartWeb3(
read_rpc=os.getenv("BLOCKPI_RPC_URL"),
write_rpc=os.getenv("TRANSACTION_ACCELERATION_RPC_URL")
)
balance = w3.eth.get_balance("0x...")
price = w3.eth.call(tx)
tx_hash = w3.eth.send_raw_transaction(signed_tx)
業務ロジックに行動の変更は不要です。唯一変わるのは請求です。
なぜ BlockPI は読み取り密集型のシナリオに最適化されているのか
読み取りと書き込みを分離した後、読み取り側プロバイダーには次の 3 点が必要です：
大規模な信頼性
あなたのロボットや dApp は 1 ブロックも落とせません。BlockPI のインフラは、本番ワークロードのために設計されています——分散ノード、自動フェイルオーバー、そして本当に機能するレート制限のバッファ。
アーカイブ対応 —— 読み取りでは履歴データが必要になることが多いため
多くの読み取りパターンでは履歴データが必要です——先週のログを取得する、古い LP ポジションを確認する、再起動後にイベントを再生する。BlockPI は Ethereum と Base でアーカイブモード（創世ブロックから）をサポートし、eth_getLogs は 5,000 ブロックの範囲に対応。任意の深さまでページングしてクエリできます。
差が出るコスト効率があること
BlockPI は RU ベースの課金で競争力があります。そのため、高容量の読み取りをルーティングしても、毎回の呼び出しごとにどこにするかの判断を何度も天秤にかける必要がありません。1 回あたりのコストは、実行に用いるハイエンドなプロバイダーに支払う料金のごく一部です。
呼び出し量 読み取り（取引加速 RPC） 読み取り（BlockPI）
1M calls/day $XX–$XXX 60–80% less
10M calls/day $XXX–$XXXX ギャップはさらに拡大
読み書き分離は誰に向いている？
以下は、典型的な MEV またはアービトラージボットが JavaScript で構成を行う方法の例です：
const { Web3 } = require('web3');
const web3Read = new Web3('https://base.blockpi.network/v1/rpc/{YOUR_API_KEY}');
const web3Write = new Web3(process.env.TRANSACTION_ACCELERATION_RPC_URL);
async function tradingCycle() {
// ステップ 1：チャンスをスキャン（すべての読み取りは BlockPI）
const currentPrice = await web3Read.eth.call({
to: '0x...',
priceFeed.encodeABI()
});
const poolReserves = await web3Read.eth.call({
to: poolAddress,
poolAbi.encodeReserves()
});
const profit = calculateProfit(currentPrice, poolReserves);
// ステップ 2：利益が出るなら実行（高速な RPC へ書き込み）
if (profit > threshold) {
const nonce = await web3Write.eth.getTransactionCount(wallet.address);
const gasPrice = await web3Write.eth.getGasPrice();
const tx = {
from: wallet.address,
to: routerAddress,
swapData,
gas: 300000,
gasPrice: gasPrice * 2,
nonce: nonce,
chainId: 8453
};
const signed = await wallet.signTransaction(tx);
const txHash = await web3Write.eth.sendRawTransaction(signed);
// ステップ 3：確認を待つ（読み取りは BlockPI）
const receipt = await web3Read.eth.getTransactionReceipt(txHash);
return receipt;
}
}
ロボットは各ブロックでチャンスをスキャンするために数百回の読み取りを実行しますが、見つかったときに送るのは 1〜2 件の取引だけです。読み書き分離がないと、これらのスキャンコストが毎回の eth_call に上乗せされ、高価な RPC の料金率で支払うことになります。
BlockPI が開発者に提供するもの：
• 競争力のある RU 価格——読み取り密集型ワークロードを本当に手頃に
• Beacon API + blob_sidecars：L2 のデータ分析用
• マルチチェーン対応——単一コンソール、多数のチェーン、統一課金
• 5,000 ブロックの getLogs 範囲 —— 任意の深さまでページング可能
これがあなたのプロジェクトに意味すること：
• 取引ボット —— 低コストでメンプールとオンチェーンデータをスキャンし、素早くプロバイダーで取引を実行
• ポートフォリオトラッカー —— 数百回の残高/呼び出しクエリを一括実行。請求に驚かされません
• インデクサー——アーカイブ深度で履歴データをリプレイし、必要に応じて取引を転送
• DeFi ダッシュボード —— チェーン上のデータを継続的にポーリングしても財務的に持続可能
🛡️ 読み取りだけではない。より柔軟な取引インフラへ
読み書き分離は、BlockPI が読み取り専用であることを意味しません。アプリが BlockPI 経由で取引も送信する場合、MEV 保護を有効にでき、挟み撃ち攻撃やその他のメンプールの抽出行為のリスクを下げられます。機密性の高い取引は保護された送信経路でルーティングされ、デフォルトでは公開メンプールに露出しません。
実際には、多くのチームが BlockPI を高容量な eth_call、残高、ログ、レシート照会の主要な読み取り層として使い、タスクに応じて書き込み経路を選択しています：超低遅延でのオンチェーン化が最優先なら取引加速 RPC を使用。元の速度よりも安全な実行品質が重要なら、MEV 保護付きの BlockPI を使用します。こうすることで、開発者は単一のプロバイダー間の板挟みを迫られるのではなく、柔軟なアーキテクチャを得られます。
🔒 MEV 保護を有効にすると、BlockPI はチームが本来オンチェーンで得たい価値をより多く保持できるよう支援します。特に、スワップ、清算、価格に敏感なその他の取引に適しています。同時に、高コスパな読み取りインフラを手放す必要はありません。機密性の高い取引を送信するときに、アービトラージャーに奪われないようにすることもできます。
数分で読み書き分離を開始
移行に大幅なコード変更は不要：
1. https://dashboard.blockpi.io に登録してエンドポイントを取得
2. コード内で BlockPI を指す読み取り専用の Web3 インスタンスを設定
3. それを使って読み取りリクエストをルーティング——eth_call、eth_getBalance、eth_getLogs、eth_blockNumber、eth_getTransactionReceipt……
4. 既存の書き込みプロバイダーを、取引加速 RPC 用に残す。あるいは MEV サービスを利用
コードを書き直す必要も、アーキテクチャを根本的に作り替える必要もありません。より賢いルーティング判断を行うだけです。
実際のコスト比較
仮にプロジェクトが毎日 100,000 回呼び出すとします：
• そのうち 95,000 回は読み取り（eth_call、getBalance、getLogs、blockNumber）
• 5,000 回が書き込み（取引加速 RPC）
項目 読み取りコスト 書き込みコスト 合計
All through accelerated transaction RPC High x 95K High x 5K $$$$
Read-write split with BlockPI Low x 95K High x 5K ~60–80% less
削減額は、読み取り量に対して線形に増えていきます。読み取り密度の高いワークロード——それが多くのプロジェクトの実態——においては、読み書き分離は単なる賢い選択ではなく、経済的に必須です。
あなたに合ったプランを選択
あなたのアプリは、すべての操作で同じ RPC 経路を使う必要はありません。重要なのは、各種ワークロードが本当に必要とするインフラ特性に合わせることです：
読み取り：容量、安定性、アーカイブ深度 ➡️ BlockPI
書き込み：取引速度 ➡️ あなたの取引加速 RPC
これは既存の RPC を置き換える話ではなく、すでにやっていることに対して余計にお金を払わないようにする話です。
BlockPI はこの等式の読み取り側を提供します——価格が手頃で、アーカイブ対応で、本番レベルのインフラ。読み取り規模を拡大しても、コストを同じだけ増やす必要がありません。
ワークロードに合う購入モードを選択：
1️⃣ RU プラン —— 事前に定義された RPC リソースパックを購入。予測可能なワークロードに適しており、予算がより明確になり、約束された利用量の水準でより良いユニット経済性が得られます。
2️⃣ 従量課金（PAYG）—— 固定プランなしで始められ、実際の利用量に応じて支払います。トラフィック変動が大きいことのあるケース、テスト、そして柔軟な拡張が必要なワークロードに適しています。
今すぐ読み書き分離を体験 ➡️ https://dashboard.blockpi.io
BLOCKPI に注目：
公式 X：https://x.com/RealBlockPI
YouTube：https://www.youtube.com/@BlockPINetwork
Telegram：@BlockPIdaily
コンソール：https://dashboard.blockpi.io/