なぜ、コードを仕様書に対して検証することはできるのに、仕様書そのものを検証することはできないのでしょうか?
機会
スマートコントラクトの形式検証は、コードが記述された仕様を満たしていることを証明しますが、その仕様が実際にコントラクトの意図した動作を正確に捉えているかどうかを判断することはできません。 2025年にMDPIが実施した、最先端の自動監査ツールを対象とした調査によると、これらのツールは本番環境で発見された悪用可能なバグのわずか8~20パーセントしか検出できていない一方で、低レベルの構文パターンについては90パーセント以上のカバレッジを報告していることが判明した。 このギャップは仕様に起因している。論理的な誤り、資産のロック条件、オラクルの仮定などは、エクスプロイトによってその必要性が明らかになるまでは、エンジニアがそれらを列挙する方法を知らないため、仕様書にほとんど記載されない。NDSS 2025のPropertyGPT論文は、効果的な形式検証のための包括的なプロパティの自動生成が、コミュニティにおいて依然として欠如していることを明確に述べている。 不完全な仕様に基づいて契約を承認するあらゆる監査は、安全性を保証するのではなく、誤った安心感を生み出してしまう。
重要な理由
契約コード、ビジネスコンテキスト、および過去のエクスプロイトデータベースから候補となる不変式を生成するツールがあれば、形式検証は単なる正しさのチェックから、真のセキュリティ保証へと変わるだろう。
機会をどう評価するか
Opportunity Scoreは測定値ではなく、私自身の見解です。どれほど痛みを伴うか、どれほど頻繁に影響を与えるか、そして今日時点で解決策がいかに少ないか。スコアが高いほど、構築する価値が高いと私は考えています。
それが現れたときにどれほどの痛みをもたらすか。
実際にどれほど頻繁に人々がそれに直面するか。
今日時点で、それに対する優れたツールがいかに少ないか。