初めまして。
CryptoGamesというブロックチェーンゲーム企業でエンジニアをしている cardene（かるでね） です！
ERCについてひたすらまとめたり、スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。
以下でも情報発信しているので、興味ある記事があればぜひ読んでみてください！
https://twitter.com/cardene777
https://chaldene.net/
https://qiita.com/cardene
https://zenn.dev/heku
https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58
https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4
また、これからも情報を見逃したくないという方はぜひ以下の購読ボタンを教えてください。
更新があった時、登録しているメールアドレス宛に通知が飛ぶようになります。
今回はXRP LEDGERについての第3回の記事になります。
第1回と第2回の記事は以下になります。
https://cardene.substack.com/p/xrp-ledger-introduction
https://cardene.substack.com/p/xrp-ledger-usecase
XRP LEDGERのコンセプトの1つである「ネットワークとサーバー」についてまとめていきます。
この記事は以下の公式ドキュメントを参考にまとめていきます。
https://xrpl.org/docs/concepts/
ネットワークとサーバー
XRP Ledgerを動かすサーバソフトウェアには以下の２種類があります。
rippledコアサーバ。
トランザクションを処理してコンセンサスを得るピアツーピアネットワークを実行します。
ClioAPIサーバ。
レジャーからデータをフェッチしたりクエリしたりするためのインターフェイス。
独自のサーバーを運用し、処理を自身でコントロールすることも可能です。
rippled サーバーモード
rippledサーバーソフトウェアは、設定によっていくつかの異なるモードで運用できます。
P2Pモード（ピア・ツー・ピアモード）
主要なサーバーモードであり、ピアツーピアネットワークに従ってトランザクションを処理し、一定量のレジャー履歴を保持します。rippledサーバのメインかつデフォルトのモードで、サーバが行える全てのことを処理可能です。
バリデータ
合意形成に参加することでネットワークを安全に保ちます。
APIサーバー
レジャーからのデータ読み取り、トランザクションの送信、レジャーの監視のためのAPIアクセスを提供します。
オプションで全履歴サーバーに設定することができ、トランザクションおよびレジャー履歴の完全な記録を保持します。
ハブサーバー
多くの他のネットワークメンバー間でメッセージをリレーします。
公開ハブ
他のサーバへのピアプロトコル接続が多数あるストックサーバのことで、XRP Ledgerネットワークの効率的な接続を維持でき、「十分な帯域幅」、「信頼できる複数ピアとの接続」、「メッセージを確実に中継」などの特徴を持ちます。
ピアプロトコルは、XRP Ledgerのサーバ間のメイン通信モードです。XRP Ledgerの動作、進捗状況、接続に関するすべての情報がピアプロトコルを通じて伝達されます。
https://xrpl.org/ja/docs/concepts/networks-and-servers/peer-protocol/
レポートモード
P2Pモードで動作する別のrippledサーバから最新の検証済みレジャーデータを取得し、リレーショナルデータベースにロードします。
保存したデータをAPIリクエストによって提供します。
ピアツーピアネットワークには参加せず、信頼できるgRPC接続を使用してP2Pモードサーバーと接続する必要があります。
スタンドアロンモード
テスト用のオフラインモードで、ピアツーピアネットワークに接続せず、コンセンサスプロセスにも参加しないため、以下のようなことが可能になります。
新しいレジャーを1から作成。
特定のトランザクションを再現する。
クラスタリング
1つのデータセンター内で複数のrippledサーバーを運用している場合、それらのサーバーをクラスターに設定することで効率を最大化できます。
rippledサーバーをクラスターで運用することには以下のような利点があります。
暗号化作業の共有
クラスター内のrippledサーバーは暗号化作業を共有します。
1つのサーバーがメッセージの真正性を確認すれば、クラスター内の他のサーバーはその結果を信頼し、再検証を行いません。
情報共有
クラスター化されたサーバーは、ネットワークを不正使用しているピアやAPIクライアントに関する情報を共有します。
これにより、クラスター内のすべてのサーバーを一度に攻撃することが難しくなります。
トランザクションの伝搬
クラスター内のサーバーは、トランザクションが一部のサーバーで現在の負荷ベースのトランザクション手数料を満たしていなくても、クラスター全体にトランザクションを常に伝搬します。
バリデータとプライベートピア
プライベートピアとしてバリデータを運用している場合、Rippleはプロキシサーバーとしてrippledサーバーのクラスターを使用することを推奨しています。
これにより、セキュリティと効率が向上します。
レジャー履歴
レジャー履歴
rippledサーバーは、コンセンサスプロセスによって生成された検証済みのレジャーバージョンのチェーンを作成します。
各レジャーバージョンは前のものからトランザクションのセットを適用して導出されます。
各rippledサーバーは、ローカルにレジャーバージョンとトランザクション履歴を保管します。
サーバーがオンラインになっている期間と、どれだけの履歴を取得・保持するかによって、保管するトランザクション履歴の量が決まります。
データベース
サーバーは、レジャー状態データとトランザクションを「レジャーストア」と呼ばれるキーバリューストアに保持します。
また、トランザクション履歴などに柔軟にアクセスするために、いくつかのSQLiteデータベースファイルを維持しています。
利用可能な履歴
XRPレジャー内のすべてのデータとトランザクションは公開されており、誰でも検索またはクエリを実行できます。
しかし、サーバーはローカルに利用可能なデータのみを検索でき、必要な履歴を持つサーバーは同じクエリの実行が成功し、履歴を持っていないサーバーはデータが見つからないと応答します。
履歴の取得
XRPレジャーのサーバーが起動すると、最初に最新の検証済みレジャーの完全なコピーを取得します。
その後、レジャーの進行に追随しています。
サーバーは同期後に発生する履歴のギャップを埋め、同期前の履歴も後から補完することができます。
履歴のダウンロード時に、サーバーはピアサーバーから欠落データを要求し、暗号ハッシュを使用してデータの完全性を検証します。
履歴の補完
サーバーがダウンロードしようとする履歴の量は、その設定によって異なります。
サーバーは自動的にギャップを埋めるために、すでに利用可能な最も古いレジャーまで履歴をダウンロードしようとします。[ledger_history]設定を使用して、それ以降の履歴を補完するようにサーバーを設定することができます。
履歴のシャーディング
XRPレジャーの完全な履歴を単一の高価なマシンに保存する代わりに、多くのサーバーを設定して各サーバーがレジャー履歴の一部を保持することができます。
履歴シャーディング機能により、サーバーは「シャードストア」と呼ばれる別のストレージ領域にレジャー履歴の範囲を保存し、リクエストがあったときは保存したデータを使用してレスポンスできます。
オンライン削除ではシャードストアーのデータは削除されません。
ただし、32768個以上のレジャーバージョンをサーバのレジャーストアーに保持するようにオンライン削除が設定されていれば、レジャーストアーからデータが自動的に削除される前に、サーバはレジャーストアーからシャードストアーにすべてのシャードをコピーできます。
オンライン削除機能により、
rippledサーバはレジャーの古いバージョンのローカルコピーを削除できます。これにより、時間とともにディスク使用量が急増しないようにできます。
ピアプロトコル
ピアプロトコル
XRPレジャー内のサーバー同士は、XRPレジャーのピアプロトコルを使用して通信します。
サーバー間の主要な通信手段であり、XRPレジャーの動作、進行、接続性に関するすべての情報がピアプロトコルを通じて伝えられます。
ピア間の通信には、接続のリクエスト、トランザクションの共有、過去のレジャーデータの要求や提供、合意形成のためのトランザクションセットの提案などが含まれます。
ピアの検出
「ゴシップ」プロトコルを使用して、サーバーは他のサーバーを見つけて接続することができます。
サーバーは起動時に以前に接続したピアに再接続し、接続に成功するとそのピアから他のサーバーの接続情報を要求します。
このプロセスを通じて、サーバーはネットワーク全体と安定して接続できる十分なピア接続を確立します。
ピアプロトコルポート
rippledサーバーは、ピアプロトコルを使用して任意のピアと接続します。
デフォルトでは51235番ポートでリッスンしています。
サーバーはこのポートをファイアウォール越しにフォワードする必要があります。
[port_peer]
port = 51235
ip = 0.0.0.0
protocol = peer「ファイアウォール越しにフォワードする」というのは、ネットワーク上で特定のポートを通して外部の通信が内部のサーバーやシステムと接続できるように設定するプロセスを指します。これは、ファイアウォールによる保護が施されたネットワーク内にあるサーバーが外部からアクセスを受け入れられるようにするために必要です。
ファイアウォールとは？
ファイアウォールは、不正アクセスや望ましくないネットワークトラフィックからネットワークを保護するために使用されるセキュリティシステムです。このシステムは、特定のルールやポリシーに基づいて、入ってくる（そして出ていく）ネットワークトラフィックを許可または拒否します。
ポートフォワーディングとは？
ポートフォワーディング（またはポートマッピング）は、外部のデバイスが特定の通信ポートを通じてファイアウォール内のサーバーやデバイスに直接アクセスできるように、ファイアウォールで特定のポートを開放し、トラフィックを内部の特定のIPアドレスとポートに転送するプロセスです。
実装方法
ファイアウォールの設定
ファイアウォールにログインし、ポートフォワーディングセクションにアクセスします。
ポートの指定
外部からアクセスを許可したいポート番号を指定します（例：TCP 2459）。
内部IPアドレスの指定
トラフィックを転送する内部ネットワーク上のデバイスのIPアドレスを指定します。
ルールの適用
設定を保存し、ファイアウォールが新しいルールを適用するようにします。
このプロセスにより、指定されたポートを通じて外部のリクエストが内部の特定のサーバーやサービスに直接到達できるようになります。これは、特にウェブサーバー、ゲームサーバー、または特定のアプリケーションサーバーなど、外部からのアクセスが必要なサービスで一般的に用いられます。
ノードキーペア
サーバーは起動時にノードキーペアを生成し、ピアプロトコル通信での署名に使用して信頼できる方法で別サーバーを識別するために使用します。
このキーペアはデータベースに保存され、サーバーが再起動したときに再利用されます。
固定ピアとピア予約
通常、rippledサーバーは信頼性の低いピア最大数のピアと自動接続され、接続を維持するには以下の方法があります。
固定ピア
IPアドレスに基づき特定の他のピアへの接続を維持します。
ピアリザベーション
特定のピアに優先順位を付け、サーバに特定のピアのピアリザベーションがある場合、最大数のピアが接続されていても常にそのピアからの接続リクエストを受け入れます。
プライベートピア
rippledサーバーを「プライベート」サーバーとして設定することで、そのIPアドレスを非公開にできます。
これは重要なサーバー（例えば信頼されたバリデーター）をDoS攻撃などから守るための有効な予防策です。
ピアツーピアネットワークに参加するには、1つ以上の非プライベートサーバに接続する必要があります。
ピア接続設定の利点と欠点
XRPレジャーに参加するためには以下の3種類の構成があります。
検出されたピアを使用
最もシンプルでメンテナンスが低い。
多くの直接ピア接続が可能。
ピアが不正行為を起こす可能性がある。
ピアの接続が頻繁に変更される可能性がある。
同じ人物または組織によって運営されるプロキシを使用する
最も安全で信頼性が高い。
プライベートサーバーのパフォーマンスを最適化することができる。
複数のサーバーを運営するコストとメンテナンスの負担が増加する。
公共のハブを使用する
メンテナンスの負担が少なく、少量の設定で安全なネットワーク接続が可能。
公共のハブに依存するため、それらが忙しい場合にはサーバーがネットワークから切断される可能性がある。
取引検閲の検知
XRP Ledgerが高い検閲体制を実現できるように設計されていることをサポートするもので、全てのrippledサーバーで利用可能です。
これにより、ネットワーク上の全参加者によって検閲がネットワークに影響を与えているかどうかを確認できます。
仕組み
検知機能はサーバーの最初のコンセンサス提案に含まれる全てのトランザクションをトラッカーに追加します。
コンセンサスラウンドの終了時に、検知機能によって検証済みのレジャーに含まれている全てのトランザクションをトラッカーから削除します。
15レジャー後もトラッカーに残っている取引に対して、検閲されている可能性があるとして警告メッセージをログに発行します。
取引がさらに15レジャー後もトラッカーに残る場合、別の警告メッセージがログに発行されます。取引がトラッカーに残り続ける限り、検出器は15レジャーごとに最大5回の警告メッセージを発行し続けます。
5回目の警告メッセージの後、検出器は最終的なエラーメッセージをログに発行し、それ以降の警告とエラーメッセージの発行を停止します。
警告メッセージの例
LedgerConsensus:WRN Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851545.エラーメッセージの例
LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605. Additional warnings suppressed.誤検知の可能性
取引検閲検知機能は特定の状況でご検知が発生する可能性があります。
例えば、サーバーがネットワークと異なるコードを実行している場合、サーバーがネットワークと同期していない場合、またはネットワーク内の他のサーバーが取引を不整合に中継しているバグがある場合などです。
これらの誤検知を防ぐために、XRP Ledgerサーバーの互換性のあるバージョンを実行することが重要です。
並列ネットワーク
XRP Ledger上の取引は、本番環境のピアツーピアネットワーク（メインネット）内で行われます。
メインネットに影響を与えることなく、XRP Ledgerとやりとりができる代替ネットワーク（別名：アルトネット）が存在します。
公開されているアルトネットの概要
メインネット
分散型暗号化レジャーであり、ピアツーピアサーバーのネットワークによって駆動されます。
テストネット
XRP Ledger上で構築されたソフトウェアのテスト場として機能するネットワークで、本番XRP Ledgerユーザーに影響を与えず実際のお金も使用されません。
メインネットの機能は、わずかな誤差はありますが反映さます。
デブネット
まだメインネットで有効にされていない予定の新しいXRP Ledger機能や改正をテストするための場所で、開発者がこれらの新機能と相互作用し、学ぶことができます。
Hooks V3 テストネット
Hooksを使用したオンチェーンのスマートコントラクト機能のプレビュー。
サイドチェーン-デブネット
クロスチェーンブリッジ機能をテストするためのサイドチェーン。
各アルトネットは独自のテストXRPトークンを持ち無料で提供されます。
テストXRPには実世界での価値はありませんし、ネットワークがリセットされたときに失われます。
注意点として、XRP Ledgerのメインネットと異なり、テストネットワークは通常中央集権化されており、これらのネットワークの安定性や可用性については保証がありません。
これらはサーバー構成、ネットワークトポロジー、およびネットワークパフォーマンスのさまざまな特性をテストするために使用されてきました。
Rippleはテストネットとデブネットの主要サーバーを運営しており、これらのネットワークに自身のrippledサーバーを接続することも可能です。
テストネットとデブネットは、多様で検閲に抵抗するバリデーターセットを使用していないため、Rippleは定期的にリセットできます。
Amendment
Amendment
XRP Ledgerでは、Amendmentシステムがトランザクション処理に影響を与える変更を承認するためにコンセンサスプロセスを使用します。
トランザクション処理の変更を導入する改正は、バリデーターによって投票されます。
Amendmentが2週間にわたって80%以上の支持を受けると、Amendmentは通過し、その変更はその後のすべてのレジャーバージョンに恒久的に適用されます。
承認されたAmendmentを無効にするには、新たなAmendmentが必要です。
Amendmentプロセス
Amendmentのコードがソフトウェアリリースに組み込まれた後、その有効化のプロセスはXRP Ledgerネットワーク内で行われ、各フラッグレジャー（通常は約15分ごと）でAmendmentの状態をチェックします。
フラッグレジャーと投票
フラッグレジャーでは、バリデーターは検証メッセージを送信する時にAmendment投票も行います。
サーバーは信頼できるバリデーターからの投票を解釈し、次のフラッグレジャーでEnableAmendment疑似トランザクションを挿入します。
これにより、改正が80%以上の支持を得た場合には「tfGotMajority」フラグが、支持が80%以下に減少した場合には「tfLostMajority」フラグが立てられます。
フラグが有効な場合は、このレジャー以降のトランザクションに適用され、フラグがない場合は改正が有効化されたとみなされます。
Amendment投票
rippledの各バージョンは、既知のAmendmentとそれらを実装するコードとともにコンパイルされます。rippledバリデーターの運営者は、各Amendmentに対して投票する設定を行い、いつでも変更することができます。
Amendmentが有効になるには、信頼できるバリデータの80%以上から2週間支持を得る必要があり、支持率が80%以下となるとそのAmendmentは一時的に却下され、再び2週間の支持が必要になります。
Amendmentは、有効になるまで、何度でも過半数を獲得したり失ったりすることができます。
Amendmentのブロック
Amendmentが有効化されると、Amendmentのソースコードを含まない以前のバージョンのrippledサーバーはネットワークのルールを理解できなくなり、Amendmentブロックとなります。
これにより、レジャーの妥当性を判断したり、トランザクションを処理したり、コンセンサスプロセスに参加したりできなくなります。
Amendmentの削除
Amendmentがメインネットで有効化されて2年が経過すると、そのコードを削除できます。
Amendmentを削除させるとコアプロトコルの一部となり、Amendmentとして追跡または扱われず、すべてのコードが削除されます。
Clio サーバー
Clioは、XRP LedgerのためのAPIサーバーで、WebSocketまたはHTTP APIを通じて検証済みのレジャーデータに最適化されています。
Clioサーバーはピアツーピアネットワークには接続せず、指定されたrippledサーバーからデータを抽出します。
API呼び出しを効率的に処理することで、P2Pモードで動作するrippledサーバーの負荷を軽減することができます。
Clioは、検証済みのレジャー履歴とトランザクションデータをスペース効率の良い形式で保存し、rippledよりも最大4倍少ないスペースを使用します。
ClioはCassandraまたはScyllaDBを使用し、スケーラブルな読み取りスループットを提供します。
複数のClioサーバーは同じデータセットにアクセスを共有できるため、冗長なデータストレージや計算を必要としません。
Clioはrippledサーバーにアクセスする必要があり、それはClioと同じマシン上で実行することも、別々に実行することもできます。
Clioは完全なHTTP / WebSocket APIを提供しますが、デフォルトでは検証済みデータのみを返します。
P2Pネットワークへのアクセスを必要とするリクエストに対しては、Clioは自動的にそのリクエストをP2Pネットワーク上のrippledサーバーに転送し、応答を返します。
なぜClioサーバーを運用するのか？
Clioサーバーを運用する理由はいくつかあります。
P2Pネットワークに接続された
rippledサーバーへの負荷を軽減。より低いメモリ使用量とストレージオーバーヘッド。
複数のClioサーバが同じデータセットへのアクセスを共有することによる、水平スケーリングが容易さ。
1つ以上の信頼できる
rippledサーバから検証済みのデータを抽出し、そのデータを効率的に保存しているため、APIリクエストのスループットが高い。
Clioサーバーの動作方法
Clioサーバーは、トランザクションメタデータ、アカウント状態、レジャーヘッダーなどの検証済みレジャーデータを永続データストアに保存します。
APIリクエストを受け取ると、これらのデータストアからデータを検索します。
P2Pネットワークからのデータが必要なリクエストの場合、ClioサーバーはリクエストをP2Pサーバーに転送し、クライアントにレスポンスを返します。
以下の条件のいずれかに該当する場合、Clioは常にrippledにリクエストを転送します。
ledger_indexがcurrentまたはclosedに設定されている場合。レジャーAPIで
accounts、queue、fullがtrueに設定されている場合。account_infoAPIでqueueがtrueに設定されている場合。リクエストされたAPIメソッド（"command"）が
submit、submit_multisigned、fee、ledger_closed、ledger_current、ripple_path_find、manifest、channel_authorize、channel_verifyのいずれかである場合。
最後に
今回はXRP LEDGERのコンセプトの1つである「ネットワークとサーバー」についてまとめました。
これからも他のブロックチェーンやサービスについてもまとめていきます。
情報を見逃したくないという方はぜひ以下の購読ボタンを教えてください。
更新があった時、登録しているメールアドレス宛に通知が飛ぶようになります。
また、拡散もしてくれると嬉しいです🙇♂️