$DUSK #dusk — DuskEVMは、Duskが実際に何かを決済する前に確認を表示します。@Dusk自身の開発者ドキュメントは明確です。トランザクションの「投入（inclusion）」は速いが、「投入」と「決済（settlement）」は別の段階であり、DuskEVMとL1の間で価値を移すアプリは、最終状態を知るために経過時間ではなく、プロトコルまたはウォレットのステータスを確認するよう求められています。シーケンサーは即時に実行し、バッチャーがデータをブロブとしてDuskDSに投稿し、その後プロポーザーがステートのコミットメントを投稿します。3人のアクター、3つの瞬間――あなたが目にするのは常に最初のものです。
文脈を確認するためGitHubを見ました：dusk-network/duskevm-genesis。これはDuskEVMの実際のジェネシスブロックとロールアップ設定を含むリポジトリで、最終更新は8月8日。さらに2日後の8月10日の更新でも、DuskEVMをテストネットとして説明しており――HardhatとSolidityでデプロイしてテストする（deploy-and-test）内容でした。別の場所では1月にすでに「メインネットローンチ（"mainnet launch"）」と呼ぶ投稿があったにもかかわらずです。ジェネシス設定が8月にもなお触れられているのは、メインネット段階というよりテストネット段階に一致します。
二重の手数料（L2の実行に加え、別のDuskDSのデータ可用性手数料）があるため、ステージングが現実のものとして見えます――順序立った作業に対して、1つではなく2層を支払っている。これは、ジェネシス・リポジトリとドキュメントの両方が指しているのと同じレイヤリングです。決済（settlement）は、コードレベルでも発表レベルでも、実行（execution）とは別の、より後の出来事です。
私にとって変わったこと：DuskEVMとDuskVMが言語の選択の違い（SolidityかRustか）ではない点です。アプリが実際に依拠して作られている「最終性（finality）のどの段階か」の違いです。DuskVMの実行と決済は同じイベントです。DuskEVMではそうではありません。今DuskEVMを統合する誰かが――あなたのアプリは決済ステータスを読み取っていますか？それとも投入（inclusion）を待つだけですか？
次は：ロールアップ設定に触れることが止まった最初のコミットを、duskevm-genesisで確認することです。どんな発表よりも、メインネット準備完了のよりクリーンな合図になります。
#dusk $DUSK @Dusk