#dusk $DUSK @Dusk I当初は、セキュリティ監査とはリリース前に形式的な承認印をもらうことが主な目的だと思っていました。Duskを深く調べるほど、その前提はどんどん複雑になっていきました。監査は、コンセンサスやネットワーキングから、Piecrust VM、PLONKの証明システム、トークン・コントラクトまで、非常に異なる複数の層をカバーしており、調査結果は単にレポートに収まるのではなく、開発へとフィードバックされます。

私の注意を引いたのは、これらの発見がどれほど具体的かという点でした。以前のPLONKの研究では、公的入力が証明ハッシュに正しく含まれていないことが見つかり、それによって偽造された証明につながる経路が生まれていました。修正は技術的ではあるものの、概念としてはシンプルでした。つまり、それらの公的入力をハッシュ計算プロセスに結び付けることです。

私は、外部のセキュリティ作業の本当の価値は「完璧さを証明すること」ではなく、「開発者が見落としがちな前提をあぶり出すこと」だと考え始めました。

これは重要です。ブロックチェーンのセキュリティは、たいていは単一のスマートコントラクトだけが問題ではないからです。実行、コンセンサス、暗号、あるいはインフラにおける弱点は、まったく異なる種類の障害を生みうる一方で、責任ある開示の連携や繰り返しのレビューは、開発プロセスにコストと時間を加える要因にもなります。

バグバウンティの問いも興味深いです。Duskは以前、まだバウンティプログラムがないことを認めていましたが、その後のセキュリティ作業や公開された監査レポートからは、継続的な精査へのより広い重点が示されています。

規制された金融アプリケーションをターゲットにするネットワークにとっては、そのような考え方が重要だと思います。ただし、監査はそれでもスナップショットであって保証ではありません。実運用での利用、普及、将来のアップグレード、そして稼働中のメインネットに伴うプレッシャーが、最終的にDuskのセキュリティ論がどれほど耐久力のあるものかを試すことになるでしょう。