カスタム RPC URL を Web3 ウォレットに追加する方法

Web3 ウォレットの RPC エンドポイントについて

1. RPC エンドポイントは、ウォレット インターフェイスとブロックチェーン ノード間の通信ゲートウェイとして機能します。

2. サポートされている各ネットワーク (Ethereum Mainnet、Polygon、Solana Devnet) には、ライブ ノード インスタンスを指す専用の HTTP または HTTPS URL が必要です。

3. MetaMask、Phantom、Trust Wallet などのウォレットはネットワーク設定を介して RPC 構成を公開し、カスタム URL を手動で入力できます。

4. RPC URL は JSON-RPC 2.0 仕様に準拠し、 eth_blockNumber 、 eth_getBalance 、 eth_callなどの標準メソッドに応答する必要があります。

5. エンドポイントの構成が間違っている、または到達できない場合、トランザクション ブロードキャストの失敗、不正確な残高表示、および契約のやり取りの停止が発生します。

段階的な手動構成

1. ウォレット拡張機能またはモバイル アプリを開き、[設定] → [ネットワーク] → [ネットワークの追加] (または同等のパス) に移動します。

2. ネットワーク名 (例: Base Sepolia ) を入力し、チェーン ID (例: 84532)を割り当てます。

3. プロトコル、ドメイン、オプションの API キーを含む完全な RPC URL を指定されたフィールドに貼り付けます。例: https://base-sepolia.infura.io/v3/YOUR_INFURA_KEY 。

4. ネイティブ通貨記号 (ETH など) とその小数精度 (通常は 18) を入力します。

5. 提出を確認します。ウォレットは、設定を保存する前にテストeth_chainIdリクエストを発行して接続を検証します。

Solana 固有の RPC 処理

1. Solana ウォレットには、EVM チェーンとは異なる RPC セマンティクスが必要です。 getBalanceやgetlatestBlockhashなどのメソッドは、従来のConnectionオブジェクトではなくsolana-kitのRpcクライアントを使用して呼び出されます。

2. AppKit の Solana アダプターは、同じrpcUrlからConnection クライアントとRpcクライアントの両方を同時に初期化し、残高読み取りとトランザクション確認の一貫性を確保します。

3. ネットワークを切り替えるとき、アダプターはターゲット チェーンのrpcUrls.default.http[0]を使用して両方のクライアントを再構築し、RPC 状態が古くなったり不一致になったりするのを防ぎます。

4. @reown/appkit-adapter-solanaを統合する開発者は、新しいRpcインターフェイスとのメソッド署名の互換性を保証するために@solana/kit@8.3.0を固定する必要があります。

5. dApp の完全な機能を有効にするには、カスタム Solana RPC URL がgetFeeForMessage 、 sendTransaction 、およびgetSignatureStatuses をサポートする必要があります。

カスタム RPC のセキュリティに関する考慮事項

1. Infura、Alchemy、QuickNode などのパブリック RPC プロバイダーは、レート制限と API キー認証を強制します。認証情報を省略すると、リクエストがスロットリングまたは拒否される可能性があります。

2. セルフホスト ノードは、CORS ヘッダーを信頼できるオリジンのみに制限する必要があります。寛容なAccess-Control-Allow-Origin: *構成では、フロントランニングやデータ漏洩の危険が高まります。

3. ウォレットは、既知のチェーン ID に対して RPC 応答を検証し、ハッシュ形式をブロックします。不正な形式または一貫性のないペイロードは、内部整合性チェックをトリガーし、ネットワーク エントリを無効にする可能性があります。

4. 稼働時間履歴が検証されていないサードパーティ RPC サービスは、単一障害点を引き起こします。フォールバック URL は、コードレベルの変更を行わない限り、ほとんどのウォレット UI でネイティブにサポートされません。

5. dApp コードに埋め込まれた RPC エンドポイント ( viemのhttp()トランスポートに渡されるエンドポイントなど) は、トランザクション署名中の署名の不一致を防ぐために、ウォレットの設定されたチェーン ID と一致する必要があります。

よくある質問

Q: 複数のウォレット拡張機能で同じカスタム RPC URL を使用できますか? A: はい、URL がクロスオリジンリクエストをサポートし、ウォレットがプロバイダー固有の制限を強制しない場合に限ります。ただし、一部のウォレットでは、同時使用パターンに影響を与える可能性のあるキャッシュまたは接続プーリングが適用されます。

Q:curl が有効な JSON を返しても、ウォレットに「無効な RPC」と表示されるのはなぜですか? A: ウォレットは、HTTP ステータス コード以外にも追加の検証を実行します。応答構造、 jsonrpcバージョンなどの必須フィールド、および JSON-RPC 2.0 仕様に従った正しいエラー コード形式を検証します。

Q: カスタム RPC を追加するには、秘密キーをエンドポイントに公開する必要がありますか? A: いいえ。RPC エンドポイントは秘密キーを受け取ることはありません。署名はウォレット内でローカルに行われます。署名されたトランザクションと読み取りクエリのみが送信されます。

Q: カスタム RPC を追加した後にオフラインになった場合はどうなりますか? A: ウォレットはリアルタイム データの取得を停止し、キャッシュされた残高をデフォルトにするか、タイムアウトまたはネットワーク到達不能エラーでトランザクションの送信に失敗します。