ヴィーナスとマンゴーのエクスプロイトは、非常に異なる市場環境のもとで同じエンジニアリング上の問題が露呈したことを示している

一方は崩壊の際に陳腐化したオラクルの床に依存し、もう一方は薄い流動性によって膨らんだ価格に依存していた

どちらのプロトコルも、スマートコントラクトが誤って計算したわけではないため失敗しなかった

実行レイヤーは内部的に一貫した状態のままだった

失敗したのは、「有効な価格」と「信頼できる市場シグナル」が同一であるという前提だった

この区別は、市場環境が不変コードよりも速く変化するようになると、コストの高いものになる

ほとんどのプロトコルは、回路ブレーカー、フォールバック・オラクル、追加のバリデーション・ロジックを実行に組み込むことで対応する

各セーフガードはある種のリスクを減らす一方で、新たな失敗モードが現れるたびに、システムの監査・アップグレード・調整がより複雑になる

このトレードオフのせいで、私は「契約にあらゆる市場の例外を理解させる」ことではなく、ポリシーと実行を分離するアーキテクチャにより注意を払うようになった

Newton Protocolは、その方向性を探る一例であり、契約ロジックを拡張するのではなく、実行前に評価されるプログラマブルなRegoポリシーを通じて実現しようとしている

オラクルの乖離、デペッグ状態、あるいは流動性の質は、恒久的な仮定として不変コードの内部に埋め込まれるのではなく、ポリシー判断になる

もしそれらの条件が失敗すれば、暗号学的なアテステーションは生成されず、実行は単に停止する

このアプローチが一般化するかどうかは、まだ不確かだ

それは追加の調整レイヤーをもたらし、多くのチームは、より単純なアーキテクチャのほうがリリースや保守が容易だとして、文脈を考慮しない実行を引き続き受け入れるかもしれない

しかし、自律エージェントが最終的に人間の継続的な監督なしに資本を配分するようになれば、「実行を正しく行う」という難しいインフラの問題は、取引を正確に実行することではなく、ポリシーとして何をコード化し、何を決してコードにすべきではないかを決める問題として現れる可能性がある
@NewtonProtocol $NEWT #newt $LAB $EVAA