Curve Finance の最近の臨死体験(および回避された伝播) は、Web3 のバックミラーではぼんやりと映っているように見えるかもしれませんが、実際には業界で起き続けていることです。分散型金融プロトコル、さらに言えば分散型アプリが、そのコード内で完全に合法な攻撃の影響を受けるのはこれが初めてではありません。さらに言えば、オンチェーンのリスク管理が存在していれば危機は防げたはずだ。

これらはすべて、Web3 におけるより広範な問題を示しています。それは、開発環境に存在する表現力とリソースが限られていることと、それがセキュリティ全体にどのように影響するかという問題です。

ハッキングか悪用か？

Curve Finance の攻撃者が Curve Finance のスマート コントラクトから 6,170 万米ドルの資産を引き出すことができたとき、多くのメディアや評論家がこのイベントを「ハッキング」と呼びました。しかし、これはハッキングではなく、悪用でした。ここの違いが重要です。

この文脈では、攻撃者が何らかの方法で既存のセキュリティ対策を回避または破っていれば、ハッキングが行われたことになります。しかし、Curve への攻撃は悪用でした。プロトコルの Vyper コードが許可していることに関して、異常なことは何も起こりませんでした。略奪者は単にプロトコルの設計の仕組みを利用しただけです。

これの責任は誰にあるのでしょうか？誰も。Curve の Vyper コードは、Web3 アプリケーションで使用されているほとんどの (Solidity) コードと同様、比較的単純なトランザクション ロジックを超える複雑さを表現する能力が大幅に制限されています。

このため、この攻撃やその他の攻撃を防ぐセキュリティ対策を設計するのは誰にとっても困難になります。さらに憂慮すべきは、DeFi の広大で構成可能な流動性環境全体への拡散を防ぐためのツールを適切に設計することが誰にとっても困難になることです。

オンチェーンのリスク分析

しかし、この攻撃とDeFi全体への拡散を防ぐためにカーブができることが何もなかったというわけではないです。ソリューションの簡単な例は、オンチェーンのリスク分析です。

解決できる問題のあるパターンの一般化バージョンは、次のような仮説的な状況に要約できます。

• 悪役のボブは、ある方法で 500 万ドル相当の非常に不安定な $RISKY トークンを購入します。フラッシュローンです。
• $RISKY トークンの価値は、購入後にボブによって効果的に汲み上げられます。
• ボブは、$RISKY を裏付けとした Naive Finance で 1 億ドルの融資を実行します。
• Naive Finance は $RISKY の価格をチェックし、Bob がその金額に「適している」ことを確認します。
• ボブは走ります。
• Naive Finance が $RISKY を清算すると、その価値はわずか 500 万ドルになります。

(この一般的なパターンの別の例は、オイラーハック3月から）

従来、この問題は、資産がどの程度保証できるかを判断するリスク分析ソリューションによって解決されてきました。それらがオンチェーンに存在する場合、Naive Finance はローンを承認する前に、トークンの過去の価格に基づいて統計的推定をチェックできます。プロトコルはポンプを見破って、ボブへの1億ドルの受け取りを拒否したでしょう。

DeFiにはこの種のオンチェーンリスク分析と管理が欠けています。

Curve Finance の話に戻ると、Aave と Frax が担保トークンの流通供給量の一定の割合を通過する際にローン承認に自動化されたオンチェーン制限を設けていれば、スプレッドは防げたはずです。これは誰にとってもより安全でストレスの少ない状況だったでしょう。

表現力とリソースが限られている

ここでの本当の問題は、現在の Web3 エコシステムがこのオンチェーン リスク分析ソリューションのようなものをサポートできないことです。これらは、イーサリアム仮想マシンなどの仮想マシンで利用できるライブラリやフレームワークの種類によって制限されます。また、自由に使えるリソースも限られています。

このリスク分析および管理ソリューションのようなものを開発するには、分散型アプリは少なくとも対数などの基本的な数学的概念の関数を備えたコーディング ライブラリを利用する必要があります。

Web3 では、dApps にはアクセスできないため、これは当てはまりません。ナムピーたとえば、Python の数学モジュールです。典型的なツールボックスは存在せず、開発者は代わりに車輪を再発明する必要があります。

次に、別の問題が発生します。たとえこれらのライブラリがあったとしても、コーディングするにはコストがかかりすぎます。文字通り高価です。イーサリアム仮想マシンは、すべての計算に料金が発生するように設計されています。

これには、無限ループの防止などの正当な理由がありますが、不当なコストをかけずに計算的に拡張する必要がある dApp のリソース制限も生じます。リスク管理ソリューションの運用コストが、節約できる資金よりも高額になることは簡単にわかります。

適切な問題に焦点を当てる

局地的なレベルでは、オンチェーンのリスク管理があれば、カーブ・ファイナンスの行き詰まりの拡大を防ぐことができたはずです。一般的なレベルでは、このクラスの攻撃全体は、Web3 の表現力とリソースを強化すれば防ぐことができます。

これらはブロックチェーンのスケーラビリティの 2 つの側面ですが、dApp により多くの共有ブロック スペースを提供するだけではないため、長い間見落とされてきました。実際には、Web2 の開発環境をエミュレートする Web3 での開発環境の作成が含まれます。これらは、オンチェーンで利用可能なデータ量を拡張するだけではなく、計算のスケーラビリティとプログラマビリティに関するものです。

おそらく、Curve、Aave、または Frax のプロトコル開発者が、より優れたツールボックスとより多くのリソースを頼りにする能力を持っていれば、これらおよび将来の悪用は完全に回避できるでしょう。おそらく、オンチェーンのリスク管理から始めることができるでしょう。