Rippleの元最高技術責任者（CTO）であるデイビッド・シュワーツ氏が、XRP Ledger（XRPL）のフロントランニングやサンドイッチ攻撃を巡る懸念に反論した。予約取引の導入案と手数料設計によって攻撃コストを引き上げれば、たとえ資金力のある主体であっても継続的な悪用は難しいとの立場を示している。

ブロックチェーンメディアのThe Crypto Basicが6月30日（現地時間）に報じたところによると、論点となっているのは、シュワーツ氏が以前に提案したXRPLの予約取引の仕組みだ。決済やオファー・クロッシングの過程で生じ得るフロントランニングやサンドイッチ攻撃を抑えることを狙う。

これに対し、X（旧Twitter）の一部利用者からは、サービス拒否攻撃（DoS）への耐性が十分ではなく、国家の支援を受けたような資金力のある主体であれば、ネットワークに継続的な負荷をかけられるのではないかとの指摘が出ていた。

シュワーツ氏はこうした見方を退け、「そうなれば攻撃コストを引き上げればよい」と説明した。攻撃が続くほど手数料負担は攻撃者側に積み上がり、実質的にはXRP保有者への大規模な資金移転に等しくなるというのが同氏の考えだ。

また、手数料の引き上げ幅を固定する必要はないとも指摘した。XRPLに既にある投票手続きを通じて関連パラメータを調整できるようにし、バリデーターが予約手数料の上昇ペースを決める値を変更できるようにする案を示した。一般利用者に過度な負担を課さず、乱用だけを抑える設計を想定している。

さらに同氏は、政府支援の攻撃者が、現行と同水準のセキュリティを備えたネットワークに対して巨額資金を継続投入するとの前提自体にも疑問を呈した。XRPLを現状以上にフロントランニングやサンドイッチ攻撃にさらせるわけでもないのに、1時間当たり数千ドルの負担を続けることを懸念するのは不自然だ、との認識を示した。

提案の中核となるのが、新たな「予約取引」構造の導入だ。具体的には、台帳オブジェクト「ReservedTxns」と取引タイプ「TxnReserve」を追加する。利用者は通常の取引手数料の最低2倍を支払うことで、将来の台帳で実行される取引スロットを事前に確保できる。

予約は最大16台帳先まで有効で、当初は各台帳につき最大32件の予約取引スロットを割り当てる想定だ。処理の流れも従来と異なる。利用者がスロットを予約した後、実際の取引は直前の台帳についてコンセンサスがほぼ固まった段階でネットワークに送信される。この仕組みにより、攻撃者が取引内容を事前に把握して先回りの競合取引を差し込むことを難しくする。

実行段階では、予約取引は通常取引より先に処理され、処理後すぐに予約リストから削除される。このため、意図した順序での執行を維持しやすいとしている。

一方で、同氏はこの仕組みの限界も認めている。攻撃者が複数の将来台帳にわたって予約スロットをすべて押さえた場合、他の利用者が保護機構を使えなくなる可能性があるためだ。

この対策として、残りスロットが減るほど予約手数料を段階的に引き上げる方式を提案した。例として、32スロットのうち16件が埋まった時点で手数料の引き上げを始め、30件が埋まった段階では基本の予約手数料の3倍まで線形に上昇させる設計を挙げている。需要が高まれば、予約上限自体を32から64へ引き上げることも可能だという。

その場合、攻撃者が全スロットを継続的に占有し続けるには、一般利用者が支払うコストを大きく上回る負担が必要になる。シュワーツ氏は、それでも攻撃者が支出を続けるなら、その手数料は最終的にXRPLのエコシステムとXRP保有者側に還流するとの見方を示した。

今回の議論は、XRPLが取引順序の悪用をどう防ぐかという問題に加え、そのための費用構造をどう設計するかという論点も浮き彫りにしている。保護機構の実効性と一般利用者の負担をどう両立させるかが、今後の焦点となりそうだ。