duskvm

#dusk $DUSK @Dusk
Duskのモジュラー・スタック：3つのレイヤー、1つの目的

ブロックチェーンのアーキテクチャで、決済と実行を別の仕事として扱うとしたらどうなるでしょう？

@Dusk は、そのアプローチを3つのコンポーネントを中心にしたモジュラー設計で実現しています：

1. DuskDS — 決済の基盤
コンセンサス、ファイナリティ、データ可用性、そしてDuskのネイティブなトランザクションモデルを扱います。公開送金にはMoonlight、秘匿送金にはPhoenixが含まれます。

2. DuskEVM — EVMの道
開発者はSolidityとおなじみのEthereumツールを使えますが、アプリケーションの決済はDuskDSを通じて行われます。これにより、EVMベースのDeFiやトークン化アセットのアプリケーションにとって、環境がより利用しやすくなります。

3. DuskVM — ダイレクトなL1実行
DuskVMはRust/WASMのスマートコントラクトをDusk L1上で直接実行します。Duskのトランザクションモデルへのより深いアクセス、プライバシー、またはゼロ知識の機能を必要とするアプリケーションに適しています。

面白いのは、その分離自体です。基盤となる決済レイヤーを置き換えることなく、必要な実行環境を異なるアプリケーションが選べるようになります。

$DUSK にとって、EVM互換性、ダイレクトL1実行、プライバシー、そして決定論的な決済が、同じより広いアーキテクチャの中で機能するための土台ができます。

#DUSK #DuskEVM #DuskVM

投票：🏗️ Duskのモジュラー・アーキテクチャのうち、あなたが最も関心を持っているのはどの部分ですか？

ムーンライトとフェニックスについて考えを巡らせる中で、ひとつのことをずっと間違え続けていた：状態の形が最終性（finality）も決めるのだと扱ってしまっていた。
その前提が気になり始めた。
ムーンライトは公開アカウントモデルを携えて #DuskVM で到着する：Balances（残高）、Sender（送信者）、Receiver（受信者）、Amount（金額）、そしてNonceの進行。
フェニックスはまったく別のトレースを中心に構築されている：Encrypted Notes（暗号化ノート）、Shielded Outputs（秘匿出力）、Nullifiers（無効化子）、そしてPrivate State（秘密状態）。
最初の直感では、こんなにも異なる2つのシステムなら、最終化に至るための方法も2通り必要だろうと思った。
でも、そこで私が実際には必要ない複雑さを足してしまっていたのかもしれない。
ムーンライトはアカウントの形のままでいい。フェニックスはノートの形のままでいい。#DuskVM は、どちらかを普遍的な状態フォーマットに平坦化して、実行がいつ完了したと判断する必要はない。
それにより、私は #DuskDS も考え直すことになった。
私はそれが、2つのモデルの下に共通の $DUSK 状態をひとつ作る必要があると想定していたが、今はその確信が薄れている。
実行ロジックは特化したままでよい一方で、Dusk L1 は得られた状態に対して、1つの決定的な最終性の境界を与えることができる。
そして正直に言えば、その切り分けは、個々の状態モデルそのものより私には面白い。
状態を表す方法が異なるからといって、その状態が最終的に完了したとみなされる“いつ”の答えまで必ず変わる必要はない。
私がまだ気になっているのは、ムーンライトとフェニックスがより複雑になっていくにつれて、この切り分けがどれほどきれいに保たれるのか、という点だ。

#dusk $DUSK @Dusk

@Dusk は何かを構築しており、DeFiとトークン化された金融は今後ますます「コンプライアンスを失わずにプライバシーを実現する」ことを必要とするでしょう。パブリック・ブロックチェーンは、取引を透明かつ検証可能にできますが、規制された金融市場では、あらゆる残高、ポジション、投資家情報、取引を公開するわけにはいきません。@Dusk は、この課題に対し、ゼロ知識技術、機密（コンフィデンシャル）転送、選択的開示、アクセス制御、決定論的（デターミニスティック）な決済を組み合わせることで取り組みます。 �
Dusk +1
このアプローチの面白さは、「プライバシー＝すべてを隠すこと」ではなくてよいという発想にあります。認可された参加者は必要な情報を受け取る一方で、機微なデータは不必要な公開から保護されます。これは、トークン化された有価証券、不動産・現実資産（RWA）、機関投資家向けのDeFi、そして資格要件、レポーティング、譲渡制限、決済ルールが重要になるその他の金融ワークフローに特に関係してくる可能性があります。 �
DOCS +1
さらにDuskはモジュール型アーキテクチャを採用しており、#DuskDS は決済とデータ可用性に、#DuskVM はネイティブのRust/WASM実行に、#DuskEVM はEVM互換アプリケーションにフォーカスしています。これにより、開発者は、アプリケーションがネイティブなプライバシーを優先するのか、馴染みのあるEVMツールを優先するのか、あるいは規制された決済インフラを優先するのかに応じて、異なる開発ルートを選べます。 �
DOCS
私にとってDuskの面白い点は、単に「プライバシー」だけではありません。それは、1つの金融インフラの中で、プライバシーとコンプライアンス、そして予測可能な決済が組み合わさっていることです。より多くの現実資産や機関市場がオンチェーンへ移行していくなら、これらの能力はますます重要になっていくかもしれません。 #dusk $DUSK