今週はDuskEVMのアダプタ層について気になっていて、たいていのEVMチェーンが前面に出してくる「Solidityに対応しています」という定型句より、ずっと面白いです。
ここで実際の問題を説明します。DuskのネイティブチェーンはGraphQLと、イベントと状態に関する「RUES」と呼ばれるものを話します。Ethereumのツール群はそれを把握できません。すると、すべてのエクスプローラ／ウォレット／インデクサは、ブロック、レシート、ログ、そして証明が、特定のEthereum流の形になっていることを前提にしています。つまり、Duskのネイティブな状態と、その期待される形の間に何かが必ず存在し、毎回正しく変換しなければならないのです。フィールドが1つでも不整合だと、下流のスタック全体が静かに壊れ、誰もすぐには気づきません。
この点を具体的に示すと、いくつかの不一致があります。Duskは基盤層で価値をLUXで表す一方、EVMツールはweiを想定します。したがって、RPCレスポンスは単なるラベル付けではなく、実際の変換が必要です。Dusk L1からDuskEVMへ移動する入金は、ブリッジやバリューのピックアップを実際にどのコントラクトがトリガーしたのかをネイティブに識別する手段がないため、OPスタイルのアドレスエイリアシングを使います。そのため、誰が本当に送ったのかを復元するにはtx.originにまたがるドメインメッセージングが必要になります。そして、決済がEthereumではなくDuskDSで完了するため、OP Stackから借用した紛争ゲームやフォルトプルーフは、EthereumのものではなくDusk独自のコンセンサスに合わせて作り直す必要がありました。
これが私の中で「なるほど」とつながりました。OP Stackをフォークするのは大変なことではありません。シーケンサやブロック生成は、op-gethとして見慣れた形のままです。しかし、プルーフの決済や価値のセマンティクスは、Duskネイティブとして作り直さなければならなかった。どこにその境界線を引くか—それがこの本質的なエンジニアリング作業です。
#dusk $DUSK @Dusk
$ETH
ここで実際の問題を説明します。DuskのネイティブチェーンはGraphQLと、イベントと状態に関する「RUES」と呼ばれるものを話します。Ethereumのツール群はそれを把握できません。すると、すべてのエクスプローラ／ウォレット／インデクサは、ブロック、レシート、ログ、そして証明が、特定のEthereum流の形になっていることを前提にしています。つまり、Duskのネイティブな状態と、その期待される形の間に何かが必ず存在し、毎回正しく変換しなければならないのです。フィールドが1つでも不整合だと、下流のスタック全体が静かに壊れ、誰もすぐには気づきません。
この点を具体的に示すと、いくつかの不一致があります。Duskは基盤層で価値をLUXで表す一方、EVMツールはweiを想定します。したがって、RPCレスポンスは単なるラベル付けではなく、実際の変換が必要です。Dusk L1からDuskEVMへ移動する入金は、ブリッジやバリューのピックアップを実際にどのコントラクトがトリガーしたのかをネイティブに識別する手段がないため、OPスタイルのアドレスエイリアシングを使います。そのため、誰が本当に送ったのかを復元するにはtx.originにまたがるドメインメッセージングが必要になります。そして、決済がEthereumではなくDuskDSで完了するため、OP Stackから借用した紛争ゲームやフォルトプルーフは、EthereumのものではなくDusk独自のコンセンサスに合わせて作り直す必要がありました。
これが私の中で「なるほど」とつながりました。OP Stackをフォークするのは大変なことではありません。シーケンサやブロック生成は、op-gethとして見慣れた形のままです。しかし、プルーフの決済や価値のセマンティクスは、Duskネイティブとして作り直さなければならなかった。どこにその境界線を引くか—それがこの本質的なエンジニアリング作業です。
#dusk $DUSK @Dusk
$ETH