@Dusk_Foundation $DUSK

私はゼロ知識証明は「すべてを確認するか、まったく検証しないか」のどちらかだと考えていました。部分的な信頼はないはずです。ところが判明したのは、dusk自身の証明コードが4つの数値を完全に未チェックのまま残しており、それだけで不正な証明からお金を作れてしまうという点でした。

最初にこれを見たとき、私は本当に「偽造された証明には実際の暗号を破る必要があるのだろう」と思いました。けれど本当の欠陥は、想像していたよりずっと単純でした。

理由はこうです。シールドされたduskの各取引には証明が含まれていて、その証明は、所有権や正しい残高、妥当な入力などの事柄についてネットワークを納得させなければなりません。その証明のほとんどの数値は、検証者が単に嘘をつけないように、信頼できるコミットメントに紐づけて厳密に固定されています。ところが、取引のロジックが検証される方法に結びついた「特定の4つの数値」だけは、そのようには制約されていませんでした。つまりそれらは証明の中に存在し、最終計算で使われるのに、誰もそれらが表すべき値と整合しているかを検証していなかったのです。

そのため悪意ある証明者は、欠けている値を直接解くことができます。手順はたった「1回の割り算」です。セキュリティ研究者はこの問題をduskノードに対して実証し、何もないところから2000 DUSKを生成して、通常の取引を通じてそれを一般のウォレットに1337 DUSK送金しました。そのノードは両方を有効として受け入れました。

私にとってこの件がさらに厄介だったのは、この問題が見つかる前にduskのコードがすでに3回の別々の監査を通過していたことです。

tゼロ知識証明を強力にするのと同じ設計、つまり「すべての主張をあなた自身が再検証する」のではなく「最後の1つの判定を信じる」ことができる仕組みが、そのまま、制約されない4つの数値が長い間、見過ごされたままにできてしまう原因になっていました。

duskは通知を受けてから1日以内に問題を修正しましたが、ほぼ同時期に別チームの証明システムでも、独立してまったく同様のバグが発見されました。無関係な2つの実装が同じ盲点を出荷してしまうなら、まだ他にも同じように見つかっていないものがどれだけあるのか分かりません。

#dusk $TUT $ZRO
#zkProofs