これらのモジュラー構成において、実際のリスクが合意が決して触れないどこかに潜んでいることを、私はよく見かけるようになりました。

十分なサイクルを見てきたので、物語がいつもきれいに始まるのは分かっています。決定論的な決済、資産がEVMへ移動すること、実行レイヤーが変わるだけ。ところがその後、アーキテクチャが分岐します。DuskDSは合意、データ可用性、決済を担います。DuskVMはネイティブのコントラクトを動かします。DuskEVMはOP Stack上に載り、結果を返します。セキュリティ境界が増殖していくのです。

この感覚はどこか懐かしい気がします。1月のブリッジ事故で、それが具体化しました。公式な説明は明確でした。合意やコアプロトコルの妥協ではない、と。ブリッジサービスが使用していた署名ウォレットの問題だっただけです。資金は移動し、サービスは停止したものの、プロトコルの失敗はありませんでした。それでも、ユーザーの実際の移動経路には依然として、そのエクスポージャーが含まれていたのです。

AEGISはその後、39件の問題を修正し、そのうち7件は重大でした。VMにおけるサンドボックスのエイリアシング、危険なデシリアライゼーション、Phoenixでの手数料と払い戻しのバインド、BLSの問題などです。このリストは、実行、トランザクション、合意、そして周辺の要素にまたがっています。

私は同じトレードオフを繰り返し目にしています。セキュリティ境界を外へ押し出すほど、各レイヤーをまたぐ呼び出しに対する責任の所在が、より見つけにくくなります。合意は保たれていても、実際に資産が通っていく経路が無傷とは限らない。私はこのパターンを何度も見てきたので、人々が語る「きれいな分離」そのものを、私は完全には信用できません。ラベルが整然としていても、摩擦は残ります。@Dusk #dusk $DUSK