XRPLとEVMの比較

1. はじめに

最近 XRP Ledger (XRPL) のことを調べました。もともとEVMの経験しかないので、本記事では、XRPL を EVM と比較しながら解説します。

EVM ではDeFi や NFT など多様なユースケースを支えています。一方、XRP Ledger は決済・送金特化型の分散型台帳として設計されており、金融機関間の高速かつ低コストな資金移動を実現することに焦点を当てています。

Ethereum との比較を通して、XRPL の「なぜそのように設計されているのか」という思想的背景にも触れていきます。

XRP Ledger 概要

XRP Ledger の基本構造

XRP Ledger (XRPL) は、Ripple Labs によって開発された分散型台帳（Distributed Ledger Technology, DLT）です。
主な目的は、高速で低コストな国際送金や価値の移転を可能にすることです。
Ethereum のようにブロックを生成するのではなく、XRPL では「レジャー（ledger）」と呼ばれる状態のスナップショットが連続的に合意され、更新されていきます。

• レジャー構造
  XRPL はアカウント情報や残高、発行資産（Issued Currencies）などの状態データを保持します。
  各レジャーは前のレジャーに対する 差分（diff） を元に構築され、これにより軽量かつ迅速な更新が可能です。

• トランザクション検証
  各トランザクションはコンセンサスアルゴリズムによって承認され、すべてのノードが同一のレジャー状態を共有します。

ネイティブ通貨 XRP

XRP は XRPL のネイティブ通貨であり、次のような役割を持ちます。

• 手数料支払い（Transaction Fee）
  ネットワークスパムを防ぐため、トランザクションには少額の XRP を消費します。
  Ethereum の「ガス代」に似ていますが、ガス市場ではなく固定的かつ極めて低コストです（通常は 0.00001 XRP 程度）。

• リザーブ要件（Reserve Requirement）
  アカウントを開設したり、発行資産（Issued Currency）のトラストラインを設定する際に、一定量の XRP を担保として保持する必要があります。
  これにより、ネットワーク上でのリソースの乱用を防止します。

• 価値転送の媒介
  XRP は中間通貨として、異なる通貨ペア間のブリッジ（例：USD ⇄ JPY）に利用されます。
  特に「オンデマンド流動性 (ODL)」という仕組みを通じて、国際送金をリアルタイムで実現します。

開発元とエコシステムの位置づけ

• Ripple Labs と XRP Ledger Foundation
  Ripple Labs は XRPL の初期開発を主導した企業ですが、現在はオープンソース化が進み、XRP Ledger Foundation が標準仕様や改善提案（amendments）を管理しています。
  Ripple 社自体は XRPL を利用した国際送金サービス「RippleNet」を提供しています。

• 開発コミュニティ
  開発者は XRPL 用の SDK（xrpl.js, xrpl-py）やツールを利用してアプリケーションを構築できます。
  近年では「Hooks」や「EVM Sidechain」など、スマートコントラクト互換性を拡張する動きも活発です。

• 主な特徴まとめ

  項目	XRP Ledger	Ethereum
  コンセンサス	XRP Ledger Consensus Protocol	Proof of Stake
  取引速度	約3〜5秒	約12秒〜数分
  手数料	極めて低い（0.00001 XRP 程度）	変動（ガス市場依存）
  スマートコントラクト	限定的（Hooks / Sidechain）	完全対応（Solidity）
  用途	決済・送金	DeFi・NFT・DAO など汎用的

アーキテクチャ比較

アカウントモデルの違い

Ethereum と XRP Ledger はどちらもアカウントベースの台帳ですが、その構造と状態管理に大きな違いがあります。

• Ethereum

  • アカウントには「外部所有アカウント（EOA）」と「コントラクトアカウント」が存在します。
  • 状態は「World State」としてすべてのアカウントのバランスやストレージを保持します。
  • 状態は Merkle Patricia Trie によってハッシュ化され、ブロックチェーン全体の整合性を保証します。

• XRP Ledger

  • XRPL ではすべてのアカウントが一様に扱われ、EOA とコントラクトの区別がありません。というかコントラクトという概念が存在しないです。
  • 状態は「Ledger State」として key-value 形式で管理され、各レジャーごとに完全なスナップショットが存在します。
  • アカウントには最低保有額（Reserve Requirement）があり、リソースの過剰消費を防止します。

この設計の結果、Ethereum は汎用的な状態遷移を可能にする一方で、XRPL は送金処理を極限まで高速化することに最適化されています。

---

トランザクション処理の違い

Ethereumではトランザクションはブロックに含まれ、マイナー（または PoS ではバリデータ）が順次処理します。
XRPLではブロックという用語ではなく、レジャーと呼ばれる単位で取り込まれますが、基本的にはブロックと同様なものと見做して問題ありません。

• Ethereum: ガスコスト + ブロック生成時間が処理速度に影響。
• XRPL: **レジャークロージングタイム（約3〜5秒）**で確定。
  レジャー単位で状態が即時更新され、確定後の再編（reorg）は実用上ほぼ発生しません。

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

XRP Ledger Consensus Protocol (RPCA)

• PoW/PoS のようなマイニングやステーキングを行わず、信頼できるノードリスト（UNL: Unique Node List） に基づいてコンセンサスを形成します。
• 各ノードは自分が信頼するバリデータ集合の署名を集め、80%以上の一致が得られるとレジャーを承認。
• 即時的な最終性（deterministic finality）を持ち、再組成（reorg）が基本的には起こらないのが特徴です。

ここでUNLというのは、信頼できるバリデータのリストのことで、事前にバリデータを選んでおきます。
このリストの中のバリデータは自由に選べるのですが、それぞれが勝手に選んでしまうとフォークする可能性があるので、推奨バリデータリストというものが存在します。

これがXRPLが中央集権的と言われる所以なのかなと思います。
ドキュメントにもありますが、フォークを防ぐためには90%以上の重複が必要だそうです。

手数料とガスモデルの違い

Ethereum のガスモデルは柔軟ですが、混雑時に手数料が高騰します。
一方、XRPL では固定的で極めて低い手数料により安定した取引を実現しています。

項目	Ethereum	XRP Ledger
手数料単位	gas × gasPrice (ETH)	固定手数料 (XRP)
計算リソース依存	あり（スマートコントラクト次第）	ほぼなし
市場変動	あり（混雑に応じて上昇）	ほぼ一定
最小手数料例	数十円〜数百円	約0.00001 XRP（1円未満）

XRPL では手数料はバーン（消滅） されるため、長期的には供給量がわずかに減少する設計です。

ファイナリティ

• Ethereum

  • 理論上、再編（reorg）が起こる可能性があります。
  • 完全なファイナリティまで数分かかる場合があります（大体12分くらい）。

• XRP Ledger

  • コンセンサスが成立した時点で即時確定。
  • 確定後の巻き戻しは発生しません。
  • この性質により、金融取引や国際送金での利用に適しています。

このように、XRP Ledger は「高いスループットと即時確定性を重視した設計」であり、Ethereum が目指す「汎用計算プラットフォーム」とは明確に異なる思想に基づいています。

スマートコントラクトと拡張性

XRP Ledger における「Hooks」と「Sidechains」

XRP Ledger は、もともと スマートコントラクトをサポートしない設計でした。
これは XRPL が「信頼性と決済速度を最優先」とする金融システム向け台帳であるためです。
しかし、開発者の需要に応じて、徐々にプログラマブルな拡張機能が導入されつつあります。

Hooks

• Hooks は XRPL にネイティブに追加可能な「軽量スマートコントラクト機構」です。
• 各アカウントに小さな WebAssembly（WASM）コードをフックとして設定でき、トランザクション実行時に自動的に呼び出されます。
• Ethereum のような複雑なロジック（例：DEXやDeFiプロトコル）は実装できませんが、条件付き送金や自動化されたバランス監視などの用途には有効です。

Hooks の実装イメージ:

Account A sends XRP → Hook attached to Account B triggers:
  - Validate sender or amount
  - Reject or modify transaction
  - Emit custom event or store small state

特徴的なのは、Hooks がレジャー内に安全に統合される点です。
外部状態を参照せず、トランザクション処理と同一コンセンサス内で実行されるため、セキュリティと決済確定性を損ないません。

2026年2月現在はまだこの機能はdevnetのみに提供されており、mainnetでは使えません。

Sidechains

• XRPL の Sidechain 概念は、独自ルールやスマートコントラクト環境を持つ並列ネットワークを構築するものです。
• メインネット（XRP Ledger Mainnet）と Sidechain はブリッジを通じて XRP や資産を転送できます。
• 開発者は Sidechain 上で自由にスマートコントラクトや新しい機能を実験できます。

サイドチェーンとしては、EVMサイドチェーンとXahauというチェーンが存在します。

EVMサイドチェーンは名前の通り、EVM互換であるためSolidityで記述することができます。
Xahauは前述したHooksを利用できるチェーンです。

コントラクト実行環境の制約と設計思想

Ethereum と比較すると、XRPL は「金融グレードの安全性とシンプルさ」を重視しています。
これにより、次のような設計方針の違いが生まれています。

項目	Ethereum	XRP Ledger
実行環境	Turing 完全（EVM）	制限付き WASM（devnetのみ）または Sidechain
状態保存	任意のストレージ操作可	極めて制限的（一定領域のみ）
外部コール	可能（call, delegatecall）	不可（外部依存を排除）
セキュリティリスク	高（reentrancy, overflow 等）	低（単純なロジックのみ許可）
目的	汎用計算・DeFi/DApp	高速決済・条件付き送金

XRPLは基本的に後述する組み込みのNFTの機能であったり、コントラクト拡張は限定的（少なくともMainnetには存在しない）です。完全な Turing 完全性を求めるのではなく、用途特化型の拡張性を重視しているのだと考えられます。

トークンと資産管理

XRPL 発行資産

Ethereum では、トークンはスマートコントラクトによって実装されます。
たとえば、ERC-20 は代替トークン（FT）、ERC-721 は非代替トークン（NFT）を表現します。

一方、XRP Ledger ではトークン発行はスマートコントラクトを必要とせず、プロトコルレベルでサポートされています。
XRPLにおけるERC20相当のトークンは「IOUs」と呼ばれ、発行者（Issuer）と受取者の間で**信頼関係（Trust Line）**を構築することによって機能します。
また、ERC721相当のNFTはXLS-20という規格で表現されます。

項目	Ethereum	XRP Ledger
トークン実装	コントラクト単位 (ERC-20/ERC-721)	ネイティブ (IOU/XLS-20)
トークン作成	コントラクトデプロイ	トランザクション発行のみ
手数料	コントラクト実行に依存	固定的で低コスト
セキュリティ	コード監査必須	プロトコルで保証
トークン間相互運用性	標準（ERC準拠）に依存	プロトコルで統一的に管理

この仕組みにより、XRPL では開発者がスマートコントラクトを書くことなく、
安定的かつガスコストを抑えたトークン発行が可能です。

まとめ

XRP Ledger の資産管理は、Ethereum のような「プログラムで定義するトークン」ではなく、
プロトコルレベルで保証された信用ベースの発行モデルです。
そのため、銀行・金融機関・国際送金プラットフォームなど、
信頼を前提とするユースケースに非常に適しています。