実はこの@Dusk スタックには、関連しているが異なる2つの台帳があります。1つはDuskEVMの実行台帳で、外部にはEthereumのJSON-RPCとして説明されます。もう1つはDusk L1の決済台帳で、外部にはGraphQL / RUESとして説明されます。DUSKはこの2つの台帳では同じ数として読み取られなければなりませんが、時計、単位、小数桁は同じではありません。

DuskEVMはOP StackスタイルのEVM実行レイヤーで、標準のEVM形状のブロック、ログ、領収（レシート）を返します。その最終的な決済とデータ可用性は、さらにバッチャー、状態コミットメント、ブリッジングを通じてDuskDSにアンカーされます。つまり「GraphQLをリアルタイムにJSON-RPCへ翻訳する」アダプターではなく、2つのレイヤー間でブリッジと状態コミットメントによって最終的な整合性を保つ構造です。真に注意すべきはレイヤーをまたぐ状況です。DuskEVM上のinclusionは速い一方で、完全な決済とブリッジの確認にはさらに数ステップかかり、その間は双方で見える状態が一時的に異なる可能性があります。

$DUSK の役割が、このリスクをより具体的にします。L1ネイティブ側ではLUXで表現され、1 DUSKは10の9乗LUXに等しいです。DuskEVMはEthereumのツールチェーンとの互換性のために、DUSKを18桁小数として公開します。ブリッジの際に換算や精度処理を誤ると、同じ価値が2つの台帳で短期間一致しないことがあります。一般の送金なら表示上の誤差にとどまるかもしれませんが、規制対象の決済では「片方は入金表示されているが、もう片方はまだ最終確認されていない」誤操作ウィンドウになり得ます。

私が読んだ後の判断はこうです。#dusk を評価するにあたり、「EVMと互換」であることだけを見てはいけません。L1の決済台帳と、EVM実行台帳の間で一貫性を保証する仕組みを見る必要があります。資料には、権威あるデータソースの優先順位、競合検出、修復（リカバリ）メカニズムについて十分な説明がありません。そしてDUSKこそが、この2つの台帳で絶対に間違えてはいけない数字です。DYOR。