Rippleは、XRP Ledger上のネイティブブリッジ機能であるXChainBridge（提案XLS-38）の撤回を提案し、代わりに外部クロスチェーンネットワークであるAxelarを活用し、XRPLと他のブロックチェーンの接続を図る方針を示しました。
XLS-38は、XRPLが外部企業に依存せずに他のチェーンとアセットをやり取りできるよう設計されていました。この仕組みは「witness server」ネットワークにより、複数チェーン間のトランザクションを監視し、正しく行われたかを確認します。この仕組みによってプライベートチェーンや許可型ネットワーク、そして最終的にはXRPL EVM SidechainをXRPLメインネットへ接続することが想定されていました。
EVM Sidechainがローンチされた際、Rippleはそのブリッジ部分にXLS-38ではなくAxelarを採用しました。Rippleは、witness serverモデルには難しいバランスがあり、より運営グループが分散化されていれば安全性は増しますが、同時に調整やガバナンスが困難になると述べています。
Rippleは、複数のブロックチェーン間ブリッジの構築や運用には専門的な知識が必要であり、安全かつ大規模に運用するための十分な専門性がないと判断しています。対照的にAxelarは既に75を超えるバリデータを運用し、55以上のブロックチェーン間を安全に接続した実績を持っています。
Rippleは、XRPLコミュニティに対し1年以上にわたりXLS-38への明確な需要の提示を求めましたが、特に必要とする本格的なプロジェクトは現れなかったと述べています。
(adsbygoogle = window.adsbygoogle || []).push({});| Security | 安全性はwitness serverグループの分散度に依存。 | 長年の運用歴を持つ広範で確立されたバリデータネットワークを提供。 |
| Attack Surface | 未使用のコードがシステム内に残ることで、脆弱性を含む可能性のあるコード（推定1万行）が増加。 | 外部クロスチェーンネットワーク方式により、XRPLメインネットに余分なコードを追加しない。 |
| Decentralization | XRPLに完全ネイティブな形になる設計。 | 独立した外部ネットワーク。XRPLは他プロジェクトのインフラに依存。 |
| Maintenance | 実際の利用がない中での保守作業は、明確なメリットなしに継続的な負担となる。 | メンテナンスはAxelar自身のチームが担当。 |
| Third-Party Dependency | 外部企業への依存を回避。 | 今後は外部ネットワークのバリデータや技術への信頼が必要となる。 |
Rippleは、これは最終決定ではなく提案だと強調しており、XRPLバリデータのうち投票権は1つしか持っていないと説明しています。コミュニティが合意した場合、まず改正が非アクティブとしてマークされ、その後バリデータのアップグレードに伴い徐々にサポートが減少、最終的にコードから完全削除される流れになります。
