#dusk $DUSK @Dusk 私は「Duskのコアコンポーネント」ページを開き、ZedgerとHedgerが同じプライバシー・システムの、より古い／より新しいバージョンであることを期待した。

しかし違う。

このページでは、ZedgerをDuskのネイティブL1にそのまま置き、DuskVMのコントラクト経由で動かしている。そのハイブリッドUTXO/アカウント設計は、プライベートな保有が必要で、準拠した送受信、投票、配当、保有制限といった要件を満たすために作られた規制対象資産向けだ。

一方、Hedgerは別のルートを取る。

HedgerはDuskEVM上にあり、同型暗号とゼロ知識証明を組み合わせる。契約が取引の有効性を証明する間、値は暗号化されたままでもよい。Solidityや標準的なEthereumの開発ツールを捨てることなく実現できる。

そして私は、Duskが率直に示すトレードオフを見つけた。EVMアカウント・モデルでは、HedgerがZedgerで提供できる完全な匿名性を提供できない、という点だ。

そのことで、私はアーキテクチャの読み方を変えた。

Hedgerは単にZedgerのほうが優れているわけではない。EVM環境の中で機密性のあるファイナンスを使えるようにするために、ネイティブ層の匿名性の一部を手放している。

Solidityを前提にすでに構築されたトークン化債券プラットフォームなら、その互換性によって統合作業が減るかもしれない。だが、より深いプライバシーと、Duskのネイティブなトランザクション・モデルへの直接アクセスが必要なアプリケーションにとっては、Zedgerは別ルートのままだ。

Hedgerはまだテストネット上なので、主張されるブラウザでの証明スピードや暗号化ワークフローが、実際の市場活動の中で本当に通用するかは、まだ証明されていない。

Duskは、すべてに対して1つのプライバシー・モデルを選んだわけではない。

ネイティブL1のプライバシーとEVMのプライバシーを分けて保持しているのは、開発者の馴染みやすさと最大限の匿名性が、同じアーキテクチャの中にきれいに収まらないからだ。