歴史があり、十分に監査されたプロトコルであるBalancerが最近「ハッキング」された。同様に十分に監査されたYearn Financeもハッキングされた。数年前、Euler Financeは以前の監査に応じて導入された機能を介して「ハッキング」された。USPDは展開前に監査されたが、その後、監査されていない展開プロセス自体がハッキングされ、ローンチから約3ヶ月以内に完全な償却となった。注目している人は誰も、監査が何かが安全であることを保証するものだとは信じていない。多くの人が、監査に価値があるのかどうかさえ疑問視している。
これは新しいことではない。これはweb3の問題ではない。そして実際、これは特に深い観察ではない。しかし、監査は依然として非常に重要なものである。プロジェクトは監査にお金を払う。プロジェクトは監査を誇示する。人々は監査を読むふりをする。監査された製品が悪用されたとき、人々はなぜ、どのようにそれが起こったのかをよく尋ねる。
それに直接答えるのではなく、最近ローンチされた製品のいくつかの最近の監査を検討していく。ここでの目的は、誰かをからかったり批判したりすることではない。これらはランダムに選ばれたもので、主に最近のものに焦点を当てているからだ。それは特に悪いという意味ではない。それほど悪くもない!
ここでのポイントは、監査人が何か間違ったことをしているということではない。監査人は、彼らを雇うプロジェクトが求めることを行っている。監査範囲はプロジェクトによって設定される。極端な例として:もしDo Kwonが彼のステーブルコインスキームのために監査人を雇っていたら、彼らはそれが潜在的に不安定であることを指摘しただろう。その問題は「承認済み」とマークされ、何も行われなかったか、何も変わらなかっただろう。
この問題は、DoのTerra-LUNAエコシステムが非常に堅牢であると主張した研究とは全く関係がない。将来を予測することは難しく、そのような研究は自己利益のためのマーケティングと正しく見なされ、極端な場合、中核的な問題を認めている。プロジェクトが支援する調査は、物事を肯定的に描写することが期待されている。監査の全体的なポイントは、客観的な第三者の視点を提供することである。誇大宣伝は信頼されるべきではなく、監査は保証や保険ではない。それが人生だ。
この調査のポイントは、ここでの本当の問題は、監査人が特定するのに適しており、監査プロセスが解決するように設計されているタイプの基本的なプログラミングエラーではないということを強調することである。監査人はそれらを見つけるのがかなり得意だ。そしてそれはそもそもこれらのものを構築しているプログラマーにも当てはまる。経験的に、この種のフィードバックは適切な人々に届き、狭い問題は修正される。
いいえ、本当の問題は、意図したとおりに正確に機能し、既知の「リスク」が実現してすべてをダウンさせる製品である。これから見るのは、監査人が既知の未知の問題のすべてから自分自身を守ろうとしていることである。責任と嘲笑からの保護の演習としては、これは価値のあることかもしれない。しかし、一般的な意味では、誰も助けない。
そして最後に、さまざまな関係者が、助けになり、自分たちの狭い自己利益に役立つことができることについて議論する。監査を改善する方法についての処方箋が利他主義を含む場合、まあ、それはあまり役に立たない。
Jovayは、Ant FinancialまたはAlibabaまたはその一般的な領域に関連するL2である。しかし、Jovayが何をするかは実際には重要ではない。それは大規模で資金が豊富な組織からソフトウェアで構築されたものである。この監査は8つの問題をリストしている:
これらのうち、実際の問題は1つだけである。はい、ドキュメントがトラストレスであると述べている場合、製品自体がトラストレスではないことを指摘する価値はある。しかし、この製品はその点でかなり問題ない。量子コンピューティングが潜在的に将来のリスクをもたらし、スマートコントラクトがリスクを伴う可能性があることを指摘すること...これらは、でっち上げた問題を見つけることでレポートを長くしようとする試みか、何かが最終的にハッキングされた場合の「それは私たちのせいではない」という種類を提供しようとする試みである。おそらく両方の混合だ。
これらのポイントの精神に基づいて、9番目の問題として、私たちが星間種になり、どういうわけか光より速い通信を理解しない限り、太陽が死ぬときにネットワークがダウンすることを提案する。そうでなければ、相対性理論はこのシステムの有用な寿命を約50億年に制限する。正直なところ、太陽が死んだ後でもどこかで悪いコードが実行されているため、コードの品質を改善できると述べるよりもより有用である。しかし、冗談だ。
Hyperliquidはいくつかのスマートコントラクト監査報告書を公開している。最初のスマートコントラクト監査報告書は6つの問題を発見し、2番目のレポートはそれらが解決されたことを確認した。しかし、監査の範囲は除外された:
これらは潜在的な問題領域のように見える!監査されたのは、単一のブリッジコントラクトだけだった。しかし、システムは、まあ、それよりもはるかに複雑である。
いくつかの厳密に定義されたことだけを行うシステムの小さな隅を監査することはかなり無駄である。Hyperliquidが設計されている方法では、監査されたコントラクトはすべての人にとって外部の入口と出口ポイントである。したがって、そのコントラクトがエラーで満たされている場合、それは深刻な問題になるだろう。しかし、コントラクトが機能することを確認しても、ほとんどまたはまったく安心感を提供しない。
この監査は、チームが認めた「信頼されたエンティティと役割の集中化リスク」を強調している。レポートではそのように大文字で書かれている。そうだ。
この監査は、関与するステーブルコインが激しくデペグした場合、システムが崩壊する可能性があることを指摘している。彼らはそれを、システムが「USDCデペグイベント中に過剰なOUSGトークンミントを許可する」とフレーズしている。最終的に彼らが導入した「解決策」は、Chainlinkオラクルへの参照と、価格が低すぎると報告された場合のオフスイッチだった。したがって、価値が暴落して崩壊するのではなく、プロトコルは価値が暴落して停止する。そうだ。これは、USDCが爆発した場合に価値を失う結果を回避するメカニズムがないという点で、解決可能な問題ではない。そしてその事実に沿って、解決策は実際には何も修正しない。
これらの監査は比較的最近のものである。しかし、文脈を提供するために、2022年10月のこのスマートコントラクト監査報告書は多くの実際の問題を特定している。ほぼ200個。ほとんどが修正され、いくつかは上記と同様で、単に承認された。ポイントは、監査がかつて具体的で実質的なことを行っていたということである:プログラマーの意図ではあり得なかったプログラミングエラーを探すこと。プログラマーは、製品に組み込まれた疑わしい設計決定ではなく、本当の間違いであるため、これらのエラーを修正していた。
そして2024年までに、比較的少ない技術的問題を発見し、金融関連の攻撃を範囲外として宣言する監査が見られる。この時間の経過に伴う変化を解釈する唯一の合理的な方法は、プログラマー、および監査人としてのプログラマーが、機能するコードが唯一のリスクではないことを認識したということである。確かに、プログラミングバグは時々悪用された。しかし、2024年半ばまでに、誰もが欠陥のある経済メカニズムも大きなリスクであることを見ることができた。それらは最大のリスクだった。
意図したとおりに正確に機能したプロジェクト - 夢見たとおりではなく、現実に意図したとおりに - は、設計者の安定性の夢が現実世界に直面したときに壊れるため、時々爆発する。
この1つのプロジェクトの監査でこの進化を見ることができる。
今、私たちは監査の背理法を持っている。これは単一の問題を特定している:
問題は、初期トークン配布に関する透明性の欠如と、それが集中化の問題にどのように関連する可能性があるかである。それは「緩和」されている:
次に、多くのマルチシグの詳細がある。そして最後に監査人の回答:
したがって、プロジェクトのリスクは、小さなチームがすべてをコントロールし、そのコントロールが分散される方法、または分散されない可能性がある方法が完全に不透明であるということである。そして、彼らの意図を明確にするためにブログ投稿を書くというチームの提案された解決策は、厳密な意味では、これを修正しない。
記録のために、チームはトークンがいつどこに行くかの詳細なリストを公開している。そして彼らは、「ブロックごとまたは週次配布モデルのいずれかを検討している」などのコメントでこれが不完全であることを認めている。彼らはまた、すべてが手動のマルチシグから管理されることを認めている。したがって、彼らは正直である。それは正直さが「ええ、私たちはまだ私たちが望むことを何でもできる、そしてあなたは私たちを信頼しなければならない」ということに相当するというだけである。
この監査の目的は何か?コードに識別可能なバグがない場合、監査人はそれを書くことができる。医者や整備士への訪問が健康診断書を生成することがある。したがって、私たちは、わずかな量のコードのみが監査されたのか疑問に思っている?それともプロジェクト自体がわずかな量のコードなのか?監査人は、それがあまりにも空虚だったので、レポートに何かを入れる必要があると感じたのか?なぜ誰もがこれらのいずれかに悩まされたのか?
繰り返しになるが、私たちはここで監査人を本当に非難していない。ここで誰かが何か間違ったことをしている範囲では、それはほぼ確実に監査を依頼した人のインセンティブの問題である。そして彼らがマーケティング目的のためにほとんど無用な文書を作成するために投資家のお金を使っているという事実。それは監査人の行為ではない!
より多くのバグが捕捉され、より少ない壊れたコードが本番環境にリリースされ、より多くの提案された修正が実装されることは、明確に良いことである。そして、私たちは、ユーザーと投資家が、たとえば、あまり意味のない監査に価値と信頼を置くなど、間違ったことを気にかけているという問題を示唆するほど未熟ではない。人々は自分が気にすることを気にかけ、それを変えようとするのは愚かな行為である。
しかし、私たちが提案できる実際の改善がいくつかある。Ethenaは、製品の多くの障害モードのいくつかを前もって説明することで道を開いた。チームは、USDeがリスクゼロではないというメッセージで一貫していた。そして彼らは問題を抱える可能性のある方法を概説した。製品はいくつかの障害を抱えて生き残り、今日は非常に大きい。これは投資家のための行動ポイントを与える:存在する可能性のある「金融関連の攻撃」について正直であることをプロジェクトに主張する。
Ethenaは、正直であることがプロジェクトを運命づけないことを示している!より正直であることによって、プロジェクトがより多くの関心を引き付けたと主張できる。正直さには、何か問題が起こった場合により多くの法的カバーを提供するという追加のボーナスもある。プロジェクトはすでにこれをやりたいはずである。
監査人も、自分たちの仕事をより有用にするために分析を行う方法を再配置できる。または少なくともより無用ではなく、潜在的に誤解を招くことが少ない。経済的インセンティブの問題や量子安全性のような一般的な懸念をバグと同じセクションに入れないでください。現時点では、これらは通常、コーディングエラーとわずかに区別する方法でラベル付けされている。または、「クリティカル」ではなく「情報提供」としてリストされている。
しかし、これはポイントを見逃している。量子安全性は、システムにとって「クリティカル」なリスクである可能性がある - しかし、それは悪い署名チェックや誤ったマイナス記号とは全く異なる性質のものである!これらのことを別々のセクションに入れてください。同様に、「このステーブルコインスキームは合理的に可能性の高い条件下で不安定である」は、コードのロジックバグとは何も似ていない。この混乱を解消することは、スマートコントラクト監査報告書の外観を改善し、監査人の評判を磨くはずである。
最後に、取引所はこれを助けることができる。大規模な取引所は、ひどいプロジェクトをリストしたり、人々にお金を失わせる激しく変動するリスクのあるミームコインをリストしたり、その他のあらゆる種類の損失を与える奇妙なビジネス上の決定について多くの批判を受けている。取引所が経済的安定性を正直にカバーし、「スマートコントラクトは脆弱である可能性がある」のようなリスクを実際のロジックチェックと混同しない合理的な監査を主張したらどうなるか?
監査人がこの種のフィラーで結果を埋めることを解釈する1つの方法は、誰も空の監査結果を真剣に受け取らないということである。そのような文書が疑問を提起するのは十分に公平である。しかし、主要な取引所が、プロジェクト固有の問題を含まない2つの一致する「空の」監査結果を持つトークンをリストし、これが良いことだという立場を取った場合...それは少しボールをフィールドの下に動かすのに役立つかもしれない。私たちはまた、より「正直」で「合理的な」取引所であることが、ばかげた月への行くマーケティングの欠如があなたに費用をかけるよりも多くの顧客を得るべきサイクルのポイントにいる。
同様に、プロジェクトを監査して問題ないと言うことに汚名が付けられるべきではない。これは監査人にかかっている。おそらく、多くの監査人がこの分野でいくつかの共同声明を発行できる。はい、私たちは監査人が契約が始まったときに範囲外と判断された潜在的な問題に対する注意事項を入れたいと理解している。また十分に公平である。しかし、無意味な一般的な潜在的問題で結果を埋めることは答えではない。また、チームが、まもなく、まだ決定されていないスケジュールで手動でソートアウトするつもりのトークン配布についてブログ投稿を作成することによって集中化リスクを軽減したと言うこともない。
監査は有用である可能性がある。監査は助けになる可能性がある。そして真実は、web3監査が実際の問題を捕捉し、かなりの期間、有用で興味深いコンテンツで満たされていたということである。しかし、エンジニアは時間の経過とともに改善してきた、なぜなら彼らは、あなたが知っているように、エンジニアであり、それが彼らがすることだからである。監査人はペースを維持する必要があり、言葉を借りれば、少し革新する必要がある。そして、取引所のようなエコシステムの多くの大きな部分も、これを進めるのに役立つ。


