duskds

ムーンライトとフェニックスについて考えを巡らせる中で、ひとつのことをずっと間違え続けていた：状態の形が最終性（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

今日はこのあたりで、DuskDSについてお話しします。これは @Dusk のアーキテクチャの中でも、たぶん最も分かりにくい層のひとつです 🌒 。でも、できるだけ専門用語を使わずに、なるべく分かりやすく説明してみます。

前回の投稿では、DuskEVM は EVM と互換性のあるアプリケーションやスマートコントラクトを開発・実行する層だと見ました。一方で、DuskDS は DuskEVM で行われるデータや処理を管理するための、インフラの別の層です。

簡単に言うと、DuskDS は DuskEVM で行われた処理を記録し、Dusk の主要インフラ（Dusk L1）とつなげる役割を担っていて、清算やデータの उपलब्ध性を助けます。

ここで大事なのは、DuskEVM と DuskDS は別々のトークンでも、互いに競合する 2 つのブロックチェーンでもないということです。どちらも $DUSK のアーキテクチャの中で、それぞれ異なる役割を果たす別の層なのです。

次の投稿では、Dusk L1 と、それがこれまで見てきた各層とどう関係しているのかについてお話しします。

#dusk #DuskEVM #DuskDS

今日は小さな$DUSK のポジションを追加しましたが、今はDuskEVMを別の観点で見ています。

私を引きつけたのは、EVMの互換性だけではありません。Hedgerが同型暗号とZKプルーフを使ってプライベートトランザクションをレビュー可能にする仕組みです。以前はプライバシーをユーザー向けの機能だと思っていましたが、今は規制のあるアプリの導入を促す仕組みとして捉えています。

@Dusk は実行にも対応しており、DuskDSは決済とデータ可用性を担います。この分離は重要だと感じます。

実際のユーザーがどれくらい早くそれを採用するかはまだ不確かですが、アーキテクチャが私の見方を変えました。

$ATM $BANK #DUSK #DUSKEVM #DuskDS #Web3

DUSKにとって、最も重要だと思うのは何ですか？

橋はまだ停止していて、それが一定期間、私が何度も立ち戻る理由です。

@Dusk は、運用上の通常状態とは一致しない活動を監視で検知した後、プロトコルではなくチームが管理する運用ウォレットが原因だとして、1月16日にブリッジサービスを一時停止しました。DuskDSのブロックは決して止まりませんでした。しかし、彼らがハードニング作業を終えるまでブリッジはなお停止したままで、すでに出荷済みの軽減策はWeb Wallet上の受信者ブロックリストです。悪いアドレスをフラグ付けし、警告を出して、送信を止めます。

以上です。これが安全網。

そして、私がどうしても考え続けてしまうのはこういうことです。Rusk CLIや自前のツールを使っているなら、この警告は決して発火しません。あなたは完全に主権を持っていますが、同時に完全にさらされてもいる。下層にあるZK暗号は、まさに本気で取り組むべき重要な作業です。それでも、今週の実際のリスク領域には何も触れていません。

ブロックリストが誤りだとは思いません。現実的には正しいです。最も多くのユーザーを最速でカバーして、アーキテクチャは後で直す。

ただし、$DUSK は規制された機関投資家市場に対して明確にポジショニングしています。最も目に見える安全策が、プロトコルそのものではなくWeb Walletにあるなら、コンプライアンスチームが実際にそのスタックをストレステストしたときに何が起きるのか、という疑問が残ります。

私が見ているのは、そのギャップです。暗号ではありません。保護が実際にどこに存在するか、そのガバナンスです。

もし機関がフロントエンドの警告ではなく、プロトコルレベルの保証を必要としているなら、Duskの現在のロードマップは、それに向けて十分に速く進んでいるのでしょうか？

#Dusk #DeFi #ZeroKnowledge #Bridge #DuskDS