私は今回、@Dusk のアーキテクチャを改めて辿り、Transfer Contract の層に到達したところで逆に一度立ち止まりました。規制対象の資産をオンチェーンに載せる上で、本当に難しいのは「送金」だけではなく、プライバシー・検証可能性・決済の確定性を同時に成立させることです。私がDuskで気になったのは、この矛盾をアプリ層に丸投げしていない点です。
DuskDS が鍵です。公式にはそれを「決済およびデータ可用性層」と定義しています。Moonlight も Phoenix もここで決済します。Moonlight は公開アカウントモデルで、残高、送信者、受信者、金額が見えます。Phoenix は一方で、暗号化 note に資金を入れ、ZKP で資金が十分であることや二重支払いがないことを証明しつつ、送金額を隠し、観測者に対して送信者や特定の note の関連も隠します。さらに viewing key によって選択的な開示も可能です。私が引っかかって、でも整理できたのは Transfer Contract です。これは2種類のトランザクション payload を受け取り、それぞれに検証ロジックを別経路でルーティングし、最後にグローバルな状態の整合性を保ちます。つまり、公開とプライバシーは別々の無関係な道ではない、ということです。
さらに上を見ると、DuskEVM は OP Stack に基づく EVM 実行環境で、決済とデータ可用性は引き続き DuskDS が提供します。そして DuskEVM 上で動く Hedger は、同態暗号と ZKP により機密トランザクションを実現し、規制対象の金融シーンを想定しています。こうして繋がって見えてくるのは、Dusk がしているのは単に「資産を隠す」ことではなく、情報の露出度が異なる取引を同一の基盤インフラに載せることだ、という点です。
$DUSK は gas と staking に使われ、将来36年で5億枚を払い出して質押報酬に充てます。私にとって本当に注視すべきは、物語ではなく、これらの技術と経済メカニズムが、実際の資産取引で回るのかどうかです。
私が今いちばん見たいのは、次の4つだけです。誰が見られるのか、誰が証明できるのか、誰が実行するのか、そして最終状態がいつ確定するのか。
#dusk $DUSK @Dusk
DuskDS が鍵です。公式にはそれを「決済およびデータ可用性層」と定義しています。Moonlight も Phoenix もここで決済します。Moonlight は公開アカウントモデルで、残高、送信者、受信者、金額が見えます。Phoenix は一方で、暗号化 note に資金を入れ、ZKP で資金が十分であることや二重支払いがないことを証明しつつ、送金額を隠し、観測者に対して送信者や特定の note の関連も隠します。さらに viewing key によって選択的な開示も可能です。私が引っかかって、でも整理できたのは Transfer Contract です。これは2種類のトランザクション payload を受け取り、それぞれに検証ロジックを別経路でルーティングし、最後にグローバルな状態の整合性を保ちます。つまり、公開とプライバシーは別々の無関係な道ではない、ということです。
さらに上を見ると、DuskEVM は OP Stack に基づく EVM 実行環境で、決済とデータ可用性は引き続き DuskDS が提供します。そして DuskEVM 上で動く Hedger は、同態暗号と ZKP により機密トランザクションを実現し、規制対象の金融シーンを想定しています。こうして繋がって見えてくるのは、Dusk がしているのは単に「資産を隠す」ことではなく、情報の露出度が異なる取引を同一の基盤インフラに載せることだ、という点です。
$DUSK は gas と staking に使われ、将来36年で5億枚を払い出して質押報酬に充てます。私にとって本当に注視すべきは、物語ではなく、これらの技術と経済メカニズムが、実際の資産取引で回るのかどうかです。
私が今いちばん見たいのは、次の4つだけです。誰が見られるのか、誰が証明できるのか、誰が実行するのか、そして最終状態がいつ確定するのか。
#dusk $DUSK @Dusk
