以前ずっと、「あるチェーンが『EVMに対応している』と言うのは、要するにSolidityを動かして、ウォレットが接続できればそれで成立する」くらいに思っていました。ところが、@Dusk のDuskEVMアダプターを真面目に読み進めてみると、互換性の中でいちばん正直なのは、実は最初に「両者はそもそも互換ではない」と認める部分なのだと感じました。私はそれを「互換性のパラドックス」と名づけました。表面上はイーサリアムに似ているほど、内部ではその違いをむしろ露出させる必要がある、ということです。

DuskEVMは表面上、おなじみのOPコンポーネントとしてop-geth、op-node、op-batcher、op-proposer、op-challengerを使っていますが、決済を担っているのはイーサリアムL1ではなくDuskです。つまり、その間には「翻訳レイヤー」が必須になります。DuskのGraphQL / RUESの状態を、イーサリアムのツールが理解できるJSON-RPCへ変換し、ブロック、レシート、ログ、ストレージ、トランザクションのマッピングを、相手が期待する形にして渡さなければなりません。これはまさに同時通訳のようなもので、言葉を裏返すだけでなく、語順、単位、指示対象まで揃えないと相手は聞き違えてしまうのです。#dusk

$DUSK の役割には、もう一つの細部が隠れています。L1上ではより小さい単位であるLUXが使われている一方、EVMツールはデフォルトでWEIを前提に世界を理解しています。アダプターは単位換算を処理するだけでなく、Duskのコントラクトが呼び出し元を識別する方法が、イーサリアムと違う部分を補う必要があります。言い換えると、DUSKは実行層の燃料であり、二つの意味論の間で最も精密に換算されるべきものでもあります。

私はこう考えています。これこそが「互換性」が本当に難しいところです。単に別のプログラミング言語をもう一つ多くサポートする、という話ではありません。確定性、状態、最終性までを、きちんと翻訳しなければならないのです。表面がどれほど滑らかでも、内部では両者が同じだとごまかしてはいけない。もしこの接合部をいい加減にしてしまうと、ユーザーが見ている「正常」が、最も危険な錯覚になりうる。課題は自分で調べてください、私のこの一口だけを信じないで。