4つの台帳では、発行上限を支える仕組みがそれぞれ異なる。XRPは総量を1,000億枚に固定し、コインが勝手に増えないようにする不変条件で支えている。ビットコインの上限2,100万枚は、コンセンサス層の半減期の計算式に定められ、4年ごとに半減することがプロトコルで固定されている。イーサリアムには固定上限がなく、年間の新規発行率はコミュニティのガバナンスによって調整される。Solanaのインフレ率も投票で決まるパラメーターで、年を追うごとに1.5%へ近づいていく。4者を分けるのは、上限を何が支えているか、そして問題が起きたときに誰が最初に気づくかだ。
今回問題が起きたのは、XRPを支えるその不変条件だった。決済エンジンが内蔵プラットフォームの注文を集計する際に使っていたのは64ビットのカウンターで、2017年に追加された「XRPNotCreated」も同じ64ビットのカウンターに結びついていた。カウンターがオーバーフローすると、先行する合計処理と後段の不変条件が同時に機能しなくなった。RippleXは9月25日、xrpld 3.4.1の緊急パッチを公開し、「80%のバリデーターによる2週間の投票」を迂回した。これは、その仕組みが導入されて以来初めてのことだった。
この不変条件をたどって調べると、注文の集計を担うロジックと同じ64ビットのカウンターを共有していた。パッチで変更されたのはビット幅を64から128に広げたことだけで、カウンターを2本に分けたわけではない。オーバーフローは防げるようになったが、上限を支えるカウンターと業務上の合計処理は依然として同じ場所に結びついている。別の形で同じ問題が起きたとき、今回のように何事もなく収まるとは限らない。
機能不全による実害は、実のところ大きくなかった。再現に必要だったのは数百枚のXRPにすぎず、公開された発行記録も確認されていない。今回の対応では、もう1件、fixBatchV1_2のバッチ処理が10月9日に有効化された。緊急パッチは通常の投票を迂回し、安全対応と分散型ガバナンスを別々のものとして扱った。迅速な対応はチームが決め、時間のかかる部分だけをバリデーターの投票に委ねた。
今回機能しなかったのは上限そのものではなく、それを支える基盤だった。上限には「増えてはならない」と書かれているだけだが、それを支えるカウンターは業務上の合計処理と同じ場所を共有している。見落とされたのは単独の数値ではなく、そのカウンターだ。今後、別の独立したカウンターを持つ台帳でも同種のオーバーフローが起きるか、あるいはXRPの供給量が1,000億枚の上限から逸脱すれば、私の見立ては白紙に戻す必要がある。どちらも起きていない間は、ひとまず今の見立てを維持しておく。このカウンターの推移はXRPの日足に沿って追える。バイナンスのどの画面で確認できるか――現物の欄には日々の数値がすべて表示されており、修正の経緯をさかのぼれば照合できる。本稿は見解の記録であり、投資助言ではない。$ZEC
$LUMIA
$ERA
#xrp账本修复可增发xrp的漏洞