XRPLのAMMが日本時間で3月23日の朝5時にリリースされた翌朝いきなり、 AMMにバグが見つかった。 これによってAMMの機能は完全停止、 少なくとも今後半年程度は再稼働は見込めない状況となっている。

正直、XRPは終わったと思う。 XRPLの導入はSECの邪魔によりかなり遅れてると言われており、 それが価格上昇の悪さの原因となっているが、 ここにきてさらに遅延は話になってない。

We’ve identified a discrepancy in a few AMM pools, in which transactions are not executing as intended. Our engineering team is working to resolve the issue alongside community participants. Out of an abundance of caution, it’s best not to deposit new funds into AMM pools for…

— RippleX (@RippleXDev) March 23, 2024

おれはXRPLが失敗するとしたら、 SECによる訴訟問題やビジネスの問題ではなく、 ソフトウェアのクオリティが低いことによるものだと考えていた。 凍結されてしまったツイッターアカウントを見ていた人ならばわかるだろうが、 おれは度々、「XRPLはゴミソフ」というディスを繰り返していた。

どうしてそう感じるかというと、 rippledのソースを眺めると、拙さを感じるからだ。 ちょうど、大学の研究室レベルのソフトウェアのような印象を持った。 とても何兆ドルもの価値を運ぶための基盤を目指してるようには見えなかった。

実際にAMMに関してはリリース前に重大な性能問題が一件ブロッカーとして存在し、 それが解決したあとに一度Voteが集まったもののまたバグが見つかってVoteは取り下げ、 順調ならば2月14日にはリリースされるはずだったAMMは3月23日を待つこととなった。

最初のVote後にバグが見つかった時、 Rippleの文系人間はXRPのクオリティは高いという 主張をするために、 「バグが見つかったのは優秀なテストチームのおかげだ」 と言っていた。

しかしどうだろう。 今回のAMMリリース後、どうして一日で簡単に見つかるようなバグが 見つからなかったのだろうか。それはテストチームが無能だからに他ならない。

AMMのリリース後には、XRPLの進歩が遅いことについて、 「高い質のソフトウェアを作るためには コミュニティで活発な議論を行うことが必要であり、 そのため時間がかかる」 という説明をしていたが、 残念ながらこれは嘘である。 よく知られた事実は、「馬鹿が何万時間議論しようが大して意味はなく、 リリース後１日で破綻するようなゴミしか生み出せない」 である。

今回、日本のTeQuという開発者がバグの特定に貢献したことが 称賛されているが、このTeQuはバグが発見された当日、 「用事があって夜まで調査に参加出来そうもない」ということを言っている。 つまり、用事があって夜から調査を始めたら秒でわかるような 簡単なバグだったということだ。 では一体、何を議論していたのだろうか。 Rippleは内部的に腐敗してる可能性がある。

調査したいところですが、用事で夜まで帰れそうにないです

— tequ {X}🪝 (@_tequ_) March 24, 2024

また、Ripple社員であるMayukhaも 「There aren’t very many people in the XRPL ecosystem with enough knowledge of C++（XRPLはC++で書かれているが、XRPLエコシステムにいるのはC++の素人ばかりだ）」 ということを言っている。

First, rippled is written in C++, a fairly advanced language. There aren’t very many people in the XRPL ecosystem with enough knowledge of C++ and rippled itself to propose/review changes to the code (several of them work at Ripple). The number is growing every day, though!

— Mayukha Vadari (@msvadari) March 4, 2024

このMayukha自体も、MITを卒業後にいくつかのインターンを経て Rippleに入社したような人間であり、 ソフトウェア開発の経歴としてはそこまで長くないし、 そのほかの開発者やテスターの経歴を見ても、 どうもシステムソフトウェアの素人っぽさ（つまり、ウェブ臭）を感じる。 こういった微妙な人間が集まって適当なコードを書いているから、 今回、リリース後一日で発現し、日本人が夜中にちょこっと調べてた 原因が特定出来るようなバグを平気で作り出してしまうのだと思う。 CTOのデイビッドはどうだろうか。デイビッド自体も ウィンドウズ開発者のデイビッドカトラーに比べるとかなり見劣りするように思う。 しかし見劣ってはいけないのだ。それだけのものを作ろうとしてるのだから。

今後どうなるかだが。 今回見つかったバグについてはおそらく治るだろう。 しかし、また新たなバグが見つかり、その度にAMMが停止することは明白である。 これは「どんなソフトウェアでもバグがないことを100%保証することは不可能」 というレベルの問題ですらなく、 上に述べたように、 単にソフトウェアの質や議論がお粗末であることが原因だからだ。 XRPLが本格運用されると今よりもTPSが高まることが予想されるが、 その時にはまたポロポロとバグが見つかり、 場合によっては再現不能・原因特定不能に陥る可能性もあると思う。 というか、そうなる可能性はかなり高いと読む。

ではどうすればいいか？ 今からでもXPRLをRustで書き直したらどうだろうか？ その方がクオリティの高いソフトウェアを作れるし、 C++で書くとどうしても紛れこんでしまうようなバグを静的に 排除することも出来る。 Rustで作り直す過程においても、重大なバグを発見出来ると思う。 また、Rust製にすれば、より有能なエンジニアの注目を引くことが出来る。

XRPホルダーとしては、一度全売りをして、 全財産をイーサリアムに移すことが自らの資産を守ることに繋がると思う。