EVM互換ということは、EVMの監視だけで十分だという意味ではありません。
@Dusk のブリッジフローにある一点が、「EVM互換」が実際に何を保証しているのかを考え直すきっかけになりました。
出金はDuskEVMで開始されます。
しかし、それで終わりではありません。
ユーザーはEVM側で開始しますが、その後、出金はDusk L1で証明され、完了させる必要があります。
準備状況は、公開された状態、証明の成熟度、紛争（ディスピュート）チェックに左右されます——単に経過時間の長さではありません。
その結果、ブリッジの速度よりも、私がより面白いと感じる問題が生まれます：
実行互換性 ≠ 運用上の可視性。
あるチームは、Solidity、EVMウォレット、RPCツール群、そして既に知っている監視習慣を持ち込むかもしれません。
それで開発は進めやすくなります。
しかし同時に、危険な前提も生み得ます。もしEVMトランザクションが完了して見えるなら、経済的なアクションも完了しているはずだ——と。
クロスレイヤーの出金では、それが常に重要な状態とは限りません。
EVM側は、アクションがどこで始まったかを教えてくれます。
一方で、Dusk側が、出金が実際に「証明して完了できる準備が整った」タイミングを決めます。
だから、取引所やインフラチームに私が尋ねたいのは次の問いではありません。
「既存のEVMスタックでDuskEVMを見られますか？」
そうではなく：
そのスタックは、Dusk特有の状態監視を追加せずに、クロスレイヤーのアクションが本当に完了した時点を伝えられますか？
答えが「いいえ」なら、DuskEVMは興味深いトレードオフを生み出します。
互換性は、開発者の乗り換えコストを下げる一方で、馴染みのあるツールの下に新しい可観測性（オブザーバビリティ）の要件を隠してしまう可能性があります。
それが、実アプリが到来したときに私が見届けたい部分です。
最も危険な互換性のギャップは、「互換に見えるので誰も監視の仕方を変える必要があると思わない」類のものかもしれません。
#dusk $DUSK @Dusk
$ZEC
$ENA
@Dusk のブリッジフローにある一点が、「EVM互換」が実際に何を保証しているのかを考え直すきっかけになりました。
出金はDuskEVMで開始されます。
しかし、それで終わりではありません。
ユーザーはEVM側で開始しますが、その後、出金はDusk L1で証明され、完了させる必要があります。
準備状況は、公開された状態、証明の成熟度、紛争（ディスピュート）チェックに左右されます——単に経過時間の長さではありません。
その結果、ブリッジの速度よりも、私がより面白いと感じる問題が生まれます：
実行互換性 ≠ 運用上の可視性。
あるチームは、Solidity、EVMウォレット、RPCツール群、そして既に知っている監視習慣を持ち込むかもしれません。
それで開発は進めやすくなります。
しかし同時に、危険な前提も生み得ます。もしEVMトランザクションが完了して見えるなら、経済的なアクションも完了しているはずだ——と。
クロスレイヤーの出金では、それが常に重要な状態とは限りません。
EVM側は、アクションがどこで始まったかを教えてくれます。
一方で、Dusk側が、出金が実際に「証明して完了できる準備が整った」タイミングを決めます。
だから、取引所やインフラチームに私が尋ねたいのは次の問いではありません。
「既存のEVMスタックでDuskEVMを見られますか？」
そうではなく：
そのスタックは、Dusk特有の状態監視を追加せずに、クロスレイヤーのアクションが本当に完了した時点を伝えられますか？
答えが「いいえ」なら、DuskEVMは興味深いトレードオフを生み出します。
互換性は、開発者の乗り換えコストを下げる一方で、馴染みのあるツールの下に新しい可観測性（オブザーバビリティ）の要件を隠してしまう可能性があります。
それが、実アプリが到来したときに私が見届けたい部分です。
最も危険な互換性のギャップは、「互換に見えるので誰も監視の仕方を変える必要があると思わない」類のものかもしれません。
#dusk $DUSK @Dusk
$ZEC
$ENA
