$DUSK $aDUSK #dusk — 開発者の採用を前提に構築されたレイヤーは、透過的でありプライベートではありません。
多くの「プライベート」チェーンでは、コンプライアンスは公開台帳に後付けされた“おまけ”のように扱われています——ミキサー、任意のシールド、プロトコルの外側に置かれたKYCゲートです。Duskの提案はそれと違いました。プライバシーを、決済そのものに埋め込んでいるのです。Dusk自身のドキュメントによると、ネイティブのDuskDSでは2つのトランザクションモデル——Moonlight（透過的で残高が見える）またはPhoenix（シールドされたノート、デフォルトでゼロ知識）——が提供されます。@DuskFoundationは、そのデフォルトを“アドオン”ではなく基盤としてコンプライアンスの物語を組み立てました。
そして私はDuskEVMを見ました。Solidity互換レイヤーで、実際に開発者を取り込むことを意図しているものです。ドキュメントではHedger——同型暗号／ZKプライバシーのモジュール——を「適切な場面で使うためのツール」として説明しています。DuskEVM上のプレーンなコントラクトは、どこでも普通のEVMコントラクトと同様にふるまい、誰かが明示的にHedgerを組み込まない限り透過のままです。他のチェーンでDuskが批判する「後付け」のパターンが、その成長面にも現れているわけです。
私にとって変わった点：ここで「プライバシー・バイ・デザイン」は1つの性質ではなく、2つのデフォルトがつながれてできています。そして、実際に触れる可能性が高いレイヤーが、より弱い方を継承しています。テーゼを否定するほどではありませんが、成立する範囲を狭めます。確認すべきこと：初期のDuskEVMデプロイは本当にHedgerを統合しているのか、それとも他のEVMチェーンと同様に透過のまま出荷しているのか？
#dusk $DUSK @Dusk
多くの「プライベート」チェーンでは、コンプライアンスは公開台帳に後付けされた“おまけ”のように扱われています——ミキサー、任意のシールド、プロトコルの外側に置かれたKYCゲートです。Duskの提案はそれと違いました。プライバシーを、決済そのものに埋め込んでいるのです。Dusk自身のドキュメントによると、ネイティブのDuskDSでは2つのトランザクションモデル——Moonlight（透過的で残高が見える）またはPhoenix（シールドされたノート、デフォルトでゼロ知識）——が提供されます。@DuskFoundationは、そのデフォルトを“アドオン”ではなく基盤としてコンプライアンスの物語を組み立てました。
そして私はDuskEVMを見ました。Solidity互換レイヤーで、実際に開発者を取り込むことを意図しているものです。ドキュメントではHedger——同型暗号／ZKプライバシーのモジュール——を「適切な場面で使うためのツール」として説明しています。DuskEVM上のプレーンなコントラクトは、どこでも普通のEVMコントラクトと同様にふるまい、誰かが明示的にHedgerを組み込まない限り透過のままです。他のチェーンでDuskが批判する「後付け」のパターンが、その成長面にも現れているわけです。
私にとって変わった点：ここで「プライバシー・バイ・デザイン」は1つの性質ではなく、2つのデフォルトがつながれてできています。そして、実際に触れる可能性が高いレイヤーが、より弱い方を継承しています。テーゼを否定するほどではありませんが、成立する範囲を狭めます。確認すべきこと：初期のDuskEVMデプロイは本当にHedgerを統合しているのか、それとも他のEVMチェーンと同様に透過のまま出荷しているのか？
#dusk $DUSK @Dusk
