BOOSTRY Tech Blog

株式会社BOOSTRY の技術ブログです

トップ > XRPL > XRPL 技術調査（2026/3時点）

XRPL 技術調査（2026/3時点）

XRPL ブロックチェーン

こんにちは。BOOSTRY CTO の麻生です。

今回は、決済・送金ユースケースで広く知られる XRP Ledger（XRPL）について、設計思想から鍵・アドレス、コンセンサス、Ledger 構造、トランザクション、ステート構造までを体系的に解説します。

xrpl.org

本記事は 2026年3月時点の公開情報をもとに作成しています。リンク先の仕様や挙動は、将来変更される可能性があります。

なお、本ページで引用しているドキュメントは以下の公式サイトから抜粋させていただいております。 xrpl.org

1. 概要

1-1. 設計コンセプト

XRPL（XRP Ledger）は、Ripple が 2012 年に公開した高速・低コスト・高スループットを重視した分散型台帳（DLT）です。ネイティブ資産として XRP を持ち、特に国際送金・決済インフラ用途を主眼に設計されています。

観点 XRPL Bitcoin Ethereum
主目的 決済・送金の高速化 デジタルゴールド／価値保存 汎用スマートコントラクト基盤
設計思想 金融インフラ向け 非中央集権通貨 dApps
代表的用途 国際送金、ブリッジ通貨 （BTCの）価値移転 様々なトークン、DeFi、DAO など

1-2. コンセンサスアルゴリズム・処理性能

XRPL はパブリックネットワークですが、コンセンサスには XRP Ledger Consensus Protocol（BFTベース）が採用されています。BFTベースであるため、高スループットでトランザクションを処理できます。

観点 XRPL Bitcoin Ethereum
アルゴリズム XRP Ledger Consensus Protocol PoW PoS
TPS（理論値） 約1,500 約7 約15–30
確定時間 3–5秒 ブロック生成間隔は約10分/ブロックで確率的。数ブロック待機が一般的 ブロック生成は約12秒、ファイナライズは約12〜15分

1-3. ネイティブトークンとインセンティブ設計

XRPL にはネイティブトークンとして XRP が存在し、トランザクション手数料は XRP で支払われます。ただし、この手数料は Ledger 取り込み時に Burn されます。

そのため、XRPL の Validator には Bitcoin や Ethereum のような直接的な金銭インセンティブはありません。主な動機は、

  • エコシステム価値の維持
  • ガバナンス的影響力の確保

の2点と整理できます。

1-4. 組み込み型スマートコントラクト

XRPL は EVM チェーンのような汎用コントラクト実装とは異なり、組み込み型スマートコントラクトを採用しています。ネットワーク参加者が任意ロジックを自由にデプロイする方式ではありませんが、金融システムのニーズに対応する多機能なプロトコル機能が L1 に組み込まれています。

2. 秘密鍵とアドレス

参考：

xrpl.org

2-1. 秘密鍵と鍵導出

鍵タイプ

XRPL では署名アルゴリズムとして、secp256k1 と Ed25519 の2種類をサポートします。

キータイプ アルゴリズム 説明
secp256k1 楕円曲線 secp256k1 を使う ECDSA Bitcoin、Ethereumと同様。rippled では既定で利用される（クライアントライブラリによっては Ed25519 が既定の場合もある）
Ed25519 楕円曲線 Ed25519 を使う EdDSA オプションで利用。公開鍵は secp256k1 より 1 byte 短く、rippled では先頭に 0xED を追加

鍵導出（secp256k1）

公開鍵の導出は、おおむね次の流れです。

seed（16byte） -> SHA512Half -> Root Private Key -> Child Key 派生 -> 秘密鍵 -> 公開鍵

secp256k1鍵の公開鍵の導出フロー（公式ドキュメントより）

直接乱数から鍵を作るのではなく、seed ベースで導出する点が Bitcoin / Ethereum と異なります。なお Child Key は HD Wallet のような階層導出ではなく、index 加算ベースのシンプルな決定論的導出です。

実運用上は、1つの seed に対して1つのマスター鍵を使う前提が基本です。XRPL はアカウントモデルであり、UTXO モデルの Bitcoin ほど大量アドレス運用を前提としない点が背景にあります。

鍵導出（Ed25519）

Ed25519 鍵の公開鍵の導出は比較的シンプルで、以下の図のように行われます。

ed25519鍵の公開鍵の導出フロー （公式ドキュメントより）

2-2. アドレスのエンコーディング

base58 エンコード

XRPL のアドレスエンコードには base58 を使用します。方式は Bitcoin と近いものの、辞書が異なります。

  • Bitcoin の辞書
    123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz
  • XRPL の辞書
    rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz

参考：

特別な意味を持つアドレス

XRPL には公開鍵由来とは別に、特別用途の予約アドレスがあります。

アドレス 名称 意味 ブラックホール
rrrrrrrrrrrrrrrrrrrrrhoLvTp ACCOUNT_ZERO 値0のbase58エンコード。ゼロアドレス相当。P2P通信上でXRPの発行者表現として利用 Yes
rrrrrrrrrrrrrrrrrrrrBZbvji ACCOUNT_ONE 値1のbase58エンコード。Trust Line残高の発行者プレースホルダー Yes
rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh Genesis Account シード値 masterpassphrase から生成。ノードにハードコード No

エンコード処理

secp256k1 / Ed25519 いずれの公開鍵からも、辞書の違いを除けば Bitcoin と同様の流れでアドレスがエンコードされます。

2-3. 鍵の種類

XRPL では複数種のキーペア形式を使い分けられます。

マスター鍵

通常の秘密鍵・公開鍵セットで、原則オフライン（コールド）管理が推奨されます。

主に以下のような操作に使用されます。

  • アカウント最初のトランザクション送信
  • マスター鍵ペアの無効化

レギュラー鍵

マスター鍵とは別に、日常運用用の鍵を設定可能です。

  • 生成方法はマスター鍵と同様（親子関係ではなく独立生成）
  • SetRegularKey トランザクションで登録
  • 登録後は、マスター鍵専用操作を除きレギュラー鍵で署名可能

参考：SetRegularKey

マルチシグ

レギュラー鍵と同様の思想で、複数署名によるアカウント管理が可能です。

  • 各署名鍵の生成方法はマスター鍵と同様
  • SignerListSet トランザクションで署名者リストを登録

3. コンセンサスアルゴリズム

参考：

xrpl.org

XRPL は、選任された Validator による BFT コンセンサスを採用しています。信頼する Validator 群のリストは UNL（Unique Node List） と呼ばれ、各ノードが独自に UNL を定義します。

  • 各ノードは信頼する Validator を UNL として持つ
  • UNL 内 Validator の 80%以上 の合意で Ledger が確定

コンセンサスの基本フローは次の通りです。

  1. トランザクション収集
  2. 候補セット作成
  3. 投票ラウンド（複数回）
  4. Ledger 確定
  5. 次 Ledger へ

各Validatorごとのコンセンサスの流れ（公式ドキュメントより）

このとき、トランザクションの候補セットは各 Validator が提案するため、各ノードの Pool の状況などによって内容に差が生じます。こうした不整合は、提案と投票を繰り返すことで解消されます。初回ラウンドで提案した候補セットに対して、信頼している他ノード（UNL）の多数が採用しているトランザクション集合を次ラウンドで再提案することで、全体として徐々に整合したセットへ収束します。最終的に有効水準（80%）に達した時点で Ledger が確定されます。

トランザクションセットの選別プロセス（公式ドキュメントより）

この高い閾値により、ブロック再編成（Re-Org）は起きにくい設計です。

一般的な BFT が「単一 Proposer の提案ブロック」に対する合意を行うのに対し、XRPL は「各 Validator が提案し、反復で収束する」方式です。単一ラウンドの効率は下がる一方で、Validator のスケール性に優れた設計といえます。

4. ブロック（Ledger）構造

xrpl.org

XRPL では一般的なブロックを Ledger と呼びます。Ledger は次の3要素で構成されます。

  • Ledger Header（ブロックヘッダ相当）
  • Transaction Tree（トランザクションセット）
  • State Tree（ステートデータ）

Ledgerの基本構造（公式ドキュメントより）

4-1. Ledger Header

xrpl.org

主なフィールドは以下の通りです。

フィールド 説明
ledger_index Ledger番号（単調増加）
ledger_hash 当該Ledgerのハッシュ
account_hash State TreeのMerkle Root
close_flags ファイナライズ状態
close_time ファイナライズ時刻
close_time_resolution ファイナライズ時刻の分解能
closed true の場合、新規Txを受け付けない
parent_hash 前Ledgerのハッシュ
total_coins XRP総量（手数料徴収後）
transaction_hash Transaction TreeのMerkle Root

Ledger Header の構成要素（公式ドキュメントより）

XRPL のステートは Account Model ですが、EVM チェーンとは内部データ構造が大きく異なります（後述）。

5. トランザクション構造

XRPL には、単純な XRP 送金に加えて、L1 組み込み機能を活用する多様なトランザクション型があります。

5-1. 共通フィールド

xrpl.org

フィールド 型 説明
Account String (Address) 送信元アカウント（rアドレス）
TransactionType String トランザクション種別（例: Payment）
Fee String (Number) 手数料（drop単位）
Sequence Number アカウントごとの連番（リプレイ防止）
AccountTxnID String (Hash) 送信元の直前Txハッシュ条件
Flags Number 振る舞い制御ビット
LastLedgerSequence Number 有効期限（このLedger番号まで）
Memos Array 任意メタデータ
SigningPubKey String (Hex) 署名に利用した公開鍵
TxnSignature String (Hex) トランザクション署名

※ 1 drop = 0.000001 XRP

5-2. 代表的なトランザクション型

Payment（送金）

参考：Payment

{
  "TransactionType": "Payment",
  "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
  "Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
  "DeliverMax": {
    "currency": "USD",
    "value": "1",
    "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
  },
  "Fee": "12",
  "Flags": 2147483648,
  "Sequence": 2
}

主な追加フィールド：

フィールド 説明
Destination 受取アカウント
Amount XRPまたはIOU
DestinationTag 取引所等での識別子
SendMax 最大支払額（Path Payment）
Paths 自動ルーティング（DEX経由）

SignerListSet（マルチシグ設定）

参考：SignerListSet

{
  "Flags": 0,
  "TransactionType": "SignerListSet",
  "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
  "Fee": "12",
  "SignerQuorum": 3,
  "SignerEntries": [
    {
      "SignerEntry": {
        "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
        "SignerWeight": 2
      }
    },
    {
      "SignerEntry": {
        "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
        "SignerWeight": 1
      }
    },
    {
      "SignerEntry": {
        "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
        "SignerWeight": 1
      }
    }
  ]
}

主な追加フィールド：

フィールド 説明
SignerQuorum 必要署名重み（削除時は 0）
SignerEntries 署名者アカウントと重み（最大32アカウント）

TrustSet（Trust Line 設定）

参考：TrustSet

{
  "TransactionType": "TrustSet",
  "Account": "rHolder...",
  "LimitAmount": {
    "currency": "USD",
    "issuer": "rIssuer...",
    "value": "10000"
  }
}

IOU を扱ううえで必須のトランザクションで、「どの発行体の、どの IOU を、いくらまで信頼するか」を登録します。

OfferCreate / OfferCancel（DEX注文）

XRPL では中央指値注文板（CLOB）型 DEX をネイティブで持ち、AMM はその DEX に統合される形でサポートされます。

オンチェーンDEX（公式ドキュメントより）

主な追加項目は TakerGets（支払うトークン）と TakerPays（受領するトークン）です。

許可型DEX

最新の XRPL では、従来のオープン DEX に加えて、許可型 DEX（Permissioned DEX） の仕組みが追加されています。これは、許可型ドメイン（Permissioned Domain）と資格情報（Credential）によって、特定の参加者だけが取引できるようにする仕組みです。規制対応や KYC/AML 要件のある参加者が、相手方を一定範囲に限定して DEX を利用することを目的としています。

xrpl.org

許可型DEXでは、オファーは以下の3種類に分かれます。

  • オープンオファー：従来どおり、オープンDEX上で誰とでもマッチング可能
  • 許可型オファー：DomainID を指定し、同じ DomainID を持つ許可型オーダーブック内でのみマッチング可能
  • ハイブリッドオファー：許可型DEXとオープンDEXの両方で追跡されるオファー

また、クロスカレンシー Payment でも DomainID を指定することで、対応する許可型 DEX の流動性だけを利用できます。

その他のトランザクション型

その他にも、以下のようなトランザクション型が存在しています。

TransactionType 例 用途
AccountSet アカウントメタデータ登録
EscrowCreate / Finish / Cancel 時間条件付き送金
PaymentChannelCreate オフチェーン決済チャネル
NFTokenMint / Burn / CreateOffer NFT関連
AMMCreate / Deposit / Withdraw AMM関連

XRPL では非常に多くのトランザクション型をネイティブでサポートしており、現在サポートされているトランザクション型は以下から確認できます。

Transaction Types

5-3. 署名・マルチシグ

通常署名は次の流れです。

  1. JSON を Canonical Binary Format にシリアライズ
  2. トランザクションID（ハッシュ）計算
  3. SigningPubKey 対応秘密鍵で署名
  4. TxnSignature を付与して提出

これに対し、ウォレットをマルチシグで管理する場合は、事前準備として前述の SignerListSet トランザクションで重みを登録する必要があります。マルチシグトランザクションは、通常署名のトランザクションと次の点で異なります。

項目 通常署名 マルチシグ
SigningPubKey 公開鍵を設定 空文字
TxnSignature あり なし
Signers なし 複数署名を設定

例（Payment + マルチシグ）：

{
  "TransactionType": "Payment",
  "Account": "rSourceAccount...",
  "Destination": "rDestination...",
  "Amount": "1000000",
  "Fee": "30000",
  "Sequence": 10,
  "SigningPubKey": "",
  "Signers": [
    {
      "Signer": {
        "Account": "rSigner1...",
        "SigningPubKey": "ED....",
        "TxnSignature": "3045..."
      }
    },
    {
      "Signer": {
        "Account": "rSigner2...",
        "SigningPubKey": "ED....",
        "TxnSignature": "3044..."
      }
    }
  ]
}

EVMチェーンのマルチシグとの主な違い：

観点 XRPL Ethereum
実装層 L1プロトコル コントラクトウォレット等
署名検証 コンセンサス内 コントラクト実行
署名生成 オフチェーンで各署名を集約し1Txで送信 複数Tx + コントラクト閾値制御

5-4. トークン（IOU）

Ethereum の ERC20 に近い資産モデルとして、XRPL では従来から Trust Line Token（いわゆる IOU）が使われます（加えて、近年は MPT：Multi-Purpose Tokens も導入されています）。

例として、任意の米ドル連動ステーブルコインを発行する場合は、次の2ステップになります。

STEP1. 受取者が TrustSet を作成

{
  "TransactionType": "TrustSet",
  "Account": "rHolder...",
  "LimitAmount": {
    "currency": "USD",
    "issuer": "rStablecoinIssuer...",
    "value": "1000000"
  }
}
  • 新規IOU受取の前提条件を定義
  • issuer は発行者アドレス
  • この時点では当該ステーブルコイン残高は未発生

STEP2. 発行体が Payment でIOUを発行

{
  "TransactionType": "Payment",
  "Account": "rStablecoinIssuer...",
  "Destination": "rHolder...",
  "Amount": {
    "currency": "USD",
    "issuer": "rStablecoinIssuer...",
    "value": "1000"
  }
}

この Payment の実行により、XRPL 上で当該ステーブルコイン残高（実体としては IOU）が発生します。

6. ステート構造

XRPL のステートは Account Model ですが、EVM のような単一アカウント構造ではなく、用途別に型分割された Ledger Object の集合として管理されます。

参考：Ledger Entry Types

6-1. AccountRoot

アカウント設定・XRP残高などを保持します。

{
  "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
  "AccountTxnID": "0D5FB50FA65C9FE1538FD7E398FFFE9D1908DFA4576D8D7A020040686F93C77D",
  "Balance": "148446663",
  "Domain": "6D64756F31332E636F6D",
  "EmailHash": "98B4375E1D753E5B91627516F6D70977",
  "Flags": 8388608,
  "LedgerEntryType": "AccountRoot",
  "MessageKey": "0000000000000000000000070000000300",
  "OwnerCount": 3,
  "PreviousTxnID": "0D5FB50FA65C9FE1538FD7E398FFFE9D1908DFA4576D8D7A020040686F93C77D",
  "PreviousTxnLgrSeq": 14091160,
  "Sequence": 336,
  "TransferRate": 1004999999,
  "index": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8"
}

主なフィールド：

フィールド 必須 説明
Account はい 当該アカウントのクラシックアドレス
Flags はい 有効フラグ
LedgerEntryType はい AccountRoot であることを示す
OwnerCount はい 準備金対象オブジェクト数
Sequence はい 次に有効なTxシーケンス番号
PreviousTxnID はい 最終更新Txハッシュ
PreviousTxnLgrSeq はい 最終更新Ledger番号
AccountTxnID いいえ 直近送信Txハッシュ
Balance いいえ XRP残高（drop）
EmailHash いいえ メールアドレスのmd5
MessageKey いいえ 暗号化メッセージ送信用公開鍵
RegularKey いいえ レギュラー鍵アドレス
AMMID いいえ 対応AMMエントリID
NFTokenMinter いいえ 代理NFTミント許可アカウント
MintedNFTokens いいえ ミント済みNFT総数
BurnedNFTokens いいえ バーン済みNFT総数
Domain いいえ ドメイン（16進ASCII）
TicketCount いいえ 保有チケット数
TickSize いいえ オファー為替レートの有効桁数
TransferRate いいえ 発行通貨の送金手数料率
WalletLocator いいえ 任意の256bit値
WalletSize いいえ 未使用フィールド

参考：Tickets

6-2. RippleState

Trust Line（IOU）の設定・残高を保持するオブジェクトです。

{
  "Balance": {
    "currency": "USD",
    "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
    "value": "-10"
  },
  "Flags": 393216,
  "HighLimit": {
    "currency": "USD",
    "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "value": "110"
  },
  "HighNode": "0000000000000000",
  "LedgerEntryType": "RippleState",
  "LowLimit": {
    "currency": "USD",
    "issuer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
    "value": "0"
  },
  "LowNode": "0000000000000000",
  "PreviousTxnID": "E3FE6EA3D48F0C2B639448020EA4F03D4F4F8FFDB243A852A0F59177921B4879",
  "PreviousTxnLgrSeq": 14090896,
  "index": "9CA88CDEDFF9252B3DE183CE35B038F57282BC9503CDFA1923EF9A95DF0D6F7B"
}

Balance.value に負値が入るのは、IOU 残高が「発行者との相対関係」で表現されるためです。保有者視点では実保有数量が正であっても、レコード上は負値となる場合があります。

参考：High vs. Low Account

この他にも DEX のオーダー情報など、用途別に多様な Ledger Object が存在します。

7. その他情報

7-1. XRPの生成・消滅メカニズム

生成

  • XRP は全量発行済みで、新規発行はありません
  • 2012年の立ち上げ時に 1,000億 XRP が作成されました
  • 上限供給量は固定（1,000億 XRP）です
  • Ripple 社は保有 XRP の一部（2017年に設定された 550億 XRP のエスクロー）をエスクロー管理しています
  • エスクローは定期的にリリースされ、未使用分を再エスクローする運用が行われている

供給上限は固定ですが、市場流通量は Ripple 社のエスクロー運用の影響を受けます。

消滅

  • すべてのトランザクション手数料は Burn されます
  • 実際の Burn 量は 基本手数料 × 負荷係数 で決まります
  • 基本手数料は通常 0.00001 XRP（10 drops） です
  • 高負荷時は各 Validator が負荷係数を引き上げる

7-2. ノードクライアント

7-3. クライアントライブラリ

XRPL では複数言語向けにクライアントライブラリが提供されています。

8. まとめ

XRPL は、BFTベースの高速コンセンサス、手数料 Burn を前提としたトークン設計、そして金融ユースケースを重視した組み込み型機能群を備えた、独自性の強いパブリック DLT です。

特に、

  • 3〜5秒程度の高速確定
  • Trust Line / IOU を軸にした資産モデル
  • L1プロトコルとしてのマルチシグやDEX/AMM機能

といった点は、EVM系チェーンとは大きく異なるアーキテクチャ上の特徴です。

本記事の内容は、社内勉強会資料をもとに再整理したものです。BOOSTRY では毎週、社内で技術勉強会を開催し、ブロックチェーンをはじめとする先端技術の知見をメンバー間で共有しています。

この記事を通じて、BOOSTRY の技術への取り組みやブロックチェーン技術の可能性に、少しでも興味を持っていただければ幸いです。今後も研究開発およびプロダクト開発を通じて、より効率的で機能性の高い先進的な金融市場の実現に向けて取り組んでまいります。引き続き BOOSTRY の活動にご注目ください。

ご興味のある方は、ぜひ採用情報もご覧ください！

〒101-0032 東京都千代田区岩本町3丁目9-2 PMO岩本町4F