Kiko奇科

#dusk $DUSK @Dusk

DuskEVM: Bringing EVM Development to Dusk.

What happens when an L1 designed around privacy and financial infrastructure also gives developers access to the Ethereum development model?

That is the role of DuskEVM.

Dusk’s documentation describes DuskEVM as an EVM-compatible execution environment where developers can build with Solidity or Vyper while using familiar Ethereum tooling and infrastructure. This includes standard EVM wallets JSON-RPC and development frameworks such as Foundry Hardhat viem and ethers.

The important architectural detail is that DuskEVM does not operate as an isolated environment. Its settlement and data availability come through DuskDS while DUSK serves as the native gas asset.

That creates a practical development path for applications already designed around the EVM ecosystem. Dusk specifically identifies use cases such as tokenized asset applications DeFi protocols AMMs and lending.

The significance is therefore less about simply adding EVM compatibility. It is about reducing the tooling gap between established Ethereum development practices and Dusk’s underlying infrastructure.

For @Dusk this gives developers a familiar entry point without requiring them to abandon the network’s native architecture.

Could EVM compatibility become one of the most important bridges between Dusk’s specialized infrastructure and a much larger developer ecosystem?

DuskVM vs DuskEVM：開発者のための2つの道

ブロックチェーンは、すべての開発者を同じ実行環境に強制する必要があるのでしょうか？

Duskは、異なる開発モデルに合わせて設計された2つのスマートコントラクト・パスを提供することで、別のアプローチを取っています。

DuskVMはネイティブのパスです。開発者はRustでコントラクトを書き、WASMにコンパイルして、Dusk L1上で直接実行します。これにより、コントラクトはDuskのL1実行モデル、トランザクションモデル、プロトコル・コントラクト、そしてプライバシーやゼロ知識機能など、ベースレイヤーの近くに置く必要がある機能へダイレクトにアクセスできます。

DuskEVMは互換性重視のルートです。開発者はSolidityまたはVyperを、馴染みのあるEVMウォレット、ライブラリ、ツールとともに利用できます。決済とデータ可用性はDuskDSが提供し、DUSKはネイティブのガストークンとして機能します。

したがって、この違いは「どちらの環境がより優れているか」を選ぶというより、アーキテクチャをアプリケーション要件に合わせることにあります。DuskVMは、L1の直接実行とDuskネイティブの機能を支持します。DuskEVMは、すでにEthereumエコシステム内で作業している開発者のハードルを下げます。

Duskが両方のパスを提供することで、ネイティブ機能と開発者にとってのなじみやすさの間に、興味深いバランスが生まれます。

ネイティブな実行とEVM互換性の両方をサポートすることは、1つのユニバーサル環境に強制するよりも、強力な開発者戦略になり得るでしょうか？

$DUSK

#dusk @Dusk

comment your idea

Duskでのステーキング：DUSKがネットワークをどのように守るのか。

ステーキングは、報酬を得ること以外に、ブロックチェーンに何を実際に貢献するのでしょうか？

Duskのステーキングでは、コンセンサスに直接つながっています。プロビジョナ（提供者）はDUSKをステークし、ブロックの提案と検証のプロセスに参加します。アクティブなプロビジョナは、トークンのインフレ（エミッション）や取引手数料から報酬を得られるため、ステーキングは別個の利回り商品というより、ネットワークのセキュリティメカニズムの一部になります。

また、選定プロセスも重要です。Duskの決定論的ソーティション（deterministic sortition）は、ステークに応じて重み付けされたプロセスによって、ブロック生成者と投票委員会のメンバーを選び出します。この仕組みは、選定の頻度がプロビジョナのステークに比例しつつ、事前には再現可能である一方、予測できないように設計されています。

その後、コンセンサスは提案の検証と、承認（ラティフィケーション）へと進みます。選ばれたプロビジョナが候補ブロックを提案し、委員会がそれを評価し、別の委員会が検証結果を確認します。有効票の多数決（スーパーマジョリティ）で成功した結果を得られます。

しかし、参加には責任が伴います。現在のDuskドキュメントでは、失敗した参加に対するソフトペナルティと、矛盾する署名を含む、証明可能な無効なコンセンサス挙動に対するハードペナルティが区別されています。

これにより、経済的ステークとネットワークの責任の間に重要な関係が生まれます。DUSKは単にロックされるだけではなく、参加者がコンセンサス・インフラを正しく運用するための経済的な理由を提供します。

@Dusk にとって、ステーキングはまさにセキュリティ・アーキテクチャそのものの一部です。

$DUSK #dusk

経済的ステークを、コンセンサス責任と直接結びつけることは、信頼性の高いネットワーク参加へのインセンティブをより強くするのでしょうか？

DUSK：単なるトークン以上の価値。

ネイティブ・ブロックチェーンのトークンに、単に売買されるだけではない「実際のユーティリティ」とは何を与えるのでしょうか？

Dusk DUSK は、ネットワークの運用そのものに直接統合されています。公式ドキュメントでは、取引手数料とステーキングに用いられるネイティブトークンであり、アセットをネットワークの活動とコンセンサス参加の両方に結びつけるものだと定義されています。

すべての取引にはネットワークリソースが必要であり、DUSK はそれらの処理に対して支払うためのガス資産として機能します。これは、Dusk の実行環境全体での活動を含み、DuskEVM では DUSK が明確にネイティブのガストークンとして使われます。

2つ目の役割は、さらに根本的なステーキングです。

Dusk はプロビジョナーを用いてコンセンサスに参加し、ブロックを提案し検証するために、アクティブなプロビジョナーが選定されます。現行ドキュメントによれば、直接ステーキングにはプロビジョナーノードの運用が必要であり、報酬はコンセンサス参加とアクティブなステークに基づきます。

DUSK はまた、エコシステムのさまざまな部分をつなぎます。ドキュメントでは Dusk L1 と DuskEVM 間での移動が説明されており、開発者は、実行やツール要件に応じて DuskVM または DuskEVM を通じて構築できます。

つまり重要なのは、単に DUSK がネットワークのネイティブ資産であるということではありません。そのユーティリティは、ネットワークが機能するための仕組みに組み込まれているのです。

@Dusk にとって、トークンのユーティリティはインフラと密接に結びついていると言えます。

$DUSK #dusk

ネイティブトークンは、そのユーティリティがネットワークの中核の運用と切り離せないとき、より意味のあるものになるのでしょうか？

シタデル：デジタル・アイデンティティのための選択的開示

デジタル・アイデンティティは、多くの場合「すべてを開示して自分が誰かを証明するか」「アプリケーションの要件を満たすには十分すぎるほどには開示しないか」という難しい選択を生みます。

Duskは、そのドキュメントでシタデルを「選択的開示のためのネットワークのアイデンティティおよびアクセス・レイヤー」として説明し、この問題に取り組んでいます。

この違いは重要です。選択的開示は、単にアイデンティティ情報を非公開に保つことだけを意味しません。特定のやり取りにおいて実際に開示する必要がある情報に基づいて、アクセスを設計することです。

これはDuskのより広範なアーキテクチャにも自然に当てはまります。ネットワークはすでに、公的アカウントとシールドされたアカウントを区別しており、取引を異なる可視性レベルで動作させられるようになっています。シタデルは、その考え方を取引データだけでなく、アイデンティティとアクセスへと拡張します。

またDuskのドキュメントには、シタデル・セルフ・ソブリン・アイデンティティが、ゼロ知識システムや属性のブラインディングによる認証に関連する技術的取り組みと並んで、Dusk Network上の専用の研究論文として掲載されています。

ここで私が注目しているのは、アイデンティティは、ユーザーが何かを証明する必要があるからといって、必ずしも恒久的な公開記録になる必要はない、というアーキテクチャ上の原則です。

@Dusk における選択的開示は、プライバシーと実践的なアクセス制御を結びつけており、とりわけブロックチェーンの基盤が、アイデンティティや認可が重要になるアプリケーションと連携するときに、特に関係性が高いです。

#dusk $DUSK

選択的開示は、デジタル・プライバシーと、規制された金融システムにおけるアイデンティティ要件との間にある「欠けたレイヤー」になり得るのでしょうか？

実用性を損なわないプライバシー。

ブロックチェーン上でのプライバシーは、情報を保護することがシステムの利用のしにくさにつながり、検証や統合まで難しくしてしまうため、実現が困難になります。

Duskは、この問題に対し、さまざまな取引の可視性レベルをネットワークのアーキテクチャの一部として組み込むことで対応しています。

そのMoonlightモデルでは、公開アカウントに基づく取引を提供します。残高の公開アドレスや取引のアクティビティは透明性を保てるため、可視性や分かりやすい検証が必要な場面で有用です。

一方、Phoenixは取引の機密性が重要である場合に逆のアプローチを取ります。これは、ノートのnullifierとゼロ知識証明を中心に構築された、シールドされたUTXOベースの取引を使用します。ネットワークは、送信者、受信者、送金額を公開せずに、取引が有効であることを検証できます。

しかし、Phoenixにおけるプライバシーは単に「誰からも情報を隠す」ことだけではありません。このプロトコルには、ユーザーが自分宛ての取引を識別できる一方で、支出の権限は保護されたままにするためのビューキーが含まれています。ホワイトペーパーでは、ビューキーによって、委任された当事者にノートを支出する権限を与えることなく、委任先による取引スキャンを可能にする方法についても説明されています。

この違いは重要です。実務における金融インフラでの機密性は、情報への制御されたアクセスを放棄することを必ずしも意味しません。

したがって、@Dusk にとってのプライバシーは、利用しやすさの障害ではなく、取引の設定可能な性質として理解されるべきです。

$DUSK #dusk

選択的な可視性は、ブロックチェーンの金融において、完全な透明性と完全な匿名性のどちらかを選ぶよりも、より実用的なモデルになり得るのでしょうか？

月明かり vs フェニックス：2つのトランザクションモデル。

Duskで最も興味深い選択の1つは、プライバシーが「すべてか、何もか」の決定として扱われない点です。

その代わりDuskは、目的の異なる2つのトランザクションモデルを提供します：MoonlightとPhoenixです。
MoonlightはDuskの公開アカウントベースのモデルで、各アカウントは公開鍵に関連付けられ、ネットワークは残高と取引のnonceを管理します。取引はデジタル署名によって認可されますが、アカウントの状態はネットワークに対して透明なままです。
Phoenixは本質的に異なるアプローチを取ります。これはシールドされたUTXOベースのモデルで、UTXOはMerkleツリー内のノートとして表現されます。ノートが消費されると、nullifierによって二重支払いを防ぎますが、どの特定のノートが消費されたかは明かしません。Phoenixの取引ではゼロ知識証明を使用するため、ネットワークは基礎となる取引の詳細を直接公開せずに、その取引がプロトコル規則に従っていることを検証できます。

この違いが重要なのは、さまざまな金融活動が異なるレベルの可視性を必要とし得るからです。
公開アカウントは分かりやすい透明性を提供できる一方で、Phoenixはより強い取引プライバシーを提供できます。Duskのドキュメントでは、これらを「競合するシステム」ではなく「補完関係にあるモデル」として説明しています。

@Dusk におけるより深いアーキテクチャ上の考え方は、柔軟性です。ユーザーは、完全に透明なブロックチェーンと完全にプライベートなブロックチェーンの間で選ばなくてよいのです。

$DUSK #dusk

ユーザーに、透明な取引モデルとシールドされた取引モデルの両方を用意することが、本格的なオンチェーン金融インフラにとって重要な要件になり得るのでしょうか？

簡潔なアテステーション：Duskが最終性に到達するまで。

ブロックチェーンは、実際にトランザクションを最終確定（final）させるために何を必要とするのでしょうか？

Duskの場合、その答えは、ステーク・プルーフ（Proof-of-Stake）コンセンサス・プロトコルである「Succinct Attestation（簡潔なアテステーション）」から始まります。この仕組みは、ランダムに選ばれた委員会（committee）と、提案の検証および追認（ratification）の一連のステップを中心に構成されています。

提供者（provisioner）はDUSKをステークとしてロックし、その後コンセンサス参加の対象となり得ます。Duskの決定論的ソーティション（deterministic sortition）は、ステークに応じて重み付けされたプロセスによってブロック生成者と投票委員会のメンバーを選出します。これにより、プロトコルのシード（seed）を通じて一定の予測不可能性を保ちながら、選出を再現可能にします。

面白いのは、ブロックが提案された後に何が起こるかです。ある委員会がそれを検証し、別の委員会が検証結果を追認します。有効な投票が多数（スーパー・マジョリティ）を満たすと成功した結果となり、BLS署名によって投票をコンパクトなアテステーションへ集約できます。

その後Duskは、受理されたすべてのブロックをただちに不可逆（irreversible）として扱うのではなく、ローリング・ファイナリティ（rolling finality）を採用します。ブロックは、accepted（受理された）→ attested（アテステーションされた）→ confirmed（確定した）→ finally final（最終確定した）という状態を経て進行します。最終確定したブロックは、最終性ルールの下では置き換えられません。

このアーキテクチャは、最終性が単に「速さ」だけの問題ではないことを示しています。重要なのは、ネットワーク参加者が合意していることを示しつつ、チェーンへの確信を段階的に高めていくための調整（coordination）です。

@Dusk はそのため、合意形成を単なるセキュリティ機構ではなく、金融インフラの一部としての建築要素（architectural component）にしているのです。

$DUSK #dusk

予測可能で検証可能な最終性は、単にトランザクション処理能力（スループット）を最大化することより、金融向けブロックチェーンにとってより重要なのでしょうか？

ブロックチェーンがコンセンサスに到達するまでに、何が起こるのでしょうか？

ネットワークはまず、ノード間で情報を確実にやり取りする方法を必要とします。
そこで、KadcastがDuskのアーキテクチャにおける重要な要素となります。
Duskのホワイトペーパーによると、Kadcastはブロック、トランザクション、そしてコンセンサス投票をブロードキャストするためのピアツーピア通信レイヤーです。これは、XOR距離を用いてノード間の通信の仕方を整理するKademliaの分散ハッシュテーブル（DHT）の上に構築されています。
注目すべきは、そのブロードキャスト設計です。すべてのノードが自身のすべての近隣ノードへメッセージを転送する代わりに、Kadcastは距離を段階的に広げていく形で選択されたピアを用い、マルチキャストツリーを通じて伝播を組織化します。目的は、冗長な送信を減らしつつネットワーク全体のカバレッジを広げることです。

これは、通信効率が分散型ネットワーク内で情報がどれだけ速く流れるかに直結するため重要です。Duskは、ネットワークリソースや低遅延の通信が重要となる環境を想定してKadcastを設計しました。またホワイトペーパーでは、その構造によって直接的なピアツーピア接続を避けることで、メッセージの起点を自然に秘匿できる可能性にも触れています。

つまりKadcastは、単なるネットワークの詳細以上のものです。Duskのトランザクションレイヤーと、そのコンセンサスメカニズムをつなぐ基盤の一部なのです。

@Dusk 効率的な通信とは、最終的にネットワーク全体で信頼性の高い協調を実現する条件を作ることだと言えます。

$DUSK
#dusk

ブロックチェーン・ネットワークがスケールするにつれて、通信アーキテクチャはコンセンサスそのものと同じくらい重要になっていくのでしょうか？

ブロックチェーン・アーキテクチャは実際に何が違うのか？
Duskの答えは、単一の特徴にあるのではありません。複数の層がどのように連携して設計されているかにあります。
基盤には、ネットワークのコンセンサス最終性とデータ可用性レイヤーであるDuskDSがあります。その上にDuskは、2つの異なる実行パスをサポートします。Rust/WASMのコントラクトがDusk L1上で直接実行されるDuskVMと、決済とデータ可用性にはDuskDSを用いながらEVM環境を提供するDuskEVMです。
また、ネットワーキング・レイヤーも重要です。DuskはKadcastを使ってブロック、トランザクション、コンセンサス投票を伝播します。構造化されたアプローチにより、メッセージの冗長性を減らし、ネットワーク通信の効率を高めるよう設計されています。
さらにトランザクション・レイヤーがあります。Moonlightは公開アカウントベースのトランザクションを提供し、PhoenixはシールドされたUTXOベースのモデルを提供します。つまり、プライバシーは「後付け」ではなく、プロトコルのトランザクション・アーキテクチャの一部として扱われます。
その組み合わせが、@Dusk
を分析するうえで興味深いものにしています。すべてのアプリケーションを1つの実行モデルに押し込むのではなく、Duskは、ネットワーキング、コンセンサス、決済、実行、トランザクションのプライバシーを、補完し合うコンポーネントとして分離しています。
$DUSK sitsは、このアーキテクチャ内で、取引手数料とステーキングのためのネイティブ資産として機能しています。
より深い問いは、このモジュール型アーキテクチャはブロックチェーン基盤が進化していく中で、Duskに意味のある優位性をもたらすのか？
#dusk

なぜ従来型の金融には、最初から別の設計思想で作られたブロックチェーンが必要なのか？

課題は、単に金融資産をオンチェーンに載せることではありません。金融市場には、プライバシーの監査可能性、規制への適合、スケーラビリティ、そして信頼できる最終確定性を、同時に満たすことが求められます。Dusk のホワイトペーパーでは、これを中核となるインフラの問題として位置づけています。機微な金融情報は、常に公開することはできない一方で、機関側には監督とコンプライアンスを支える仕組みが必要です。

そこで @Dusk
は、別のアーキテクチャアプローチを採用します。

プライバシーを外部のレイヤーとして扱うのではなく、Dusk は取引モデルを通じてネットワークに組み込んでいます。Moonlight は透明な、口座ベースのモデルを提供し、Phoenix はシールド取引に対して UTXO ベースの設計を採用します。ホワイトペーパーでは、さらに、Succinct Attestation を最終確定性を数秒で実現するための合意メカニズムとして説明しており、金融市場の低遅延要件をターゲットにしています。
重要な点は、Dusk がブロックチェーン導入を純粋に技術的な問題として提示していないことです。実際にオンチェーンで金融インフラが運用できるかどうかを左右する、機関の要件に取り組もうとしているのです。

そのため $DUSK は、トークンの役割を超えて研究する価値があります。真の問いは、プライバシーのコンプライアンスとブロックチェーンネイティブの実行が、それぞれについて機関がどちらかを犠牲にすることなく共存できるかどうかです。

#dusk

ブロックチェーン基盤は、本当に規模に応じて、機関のコンプライアンスとユーザーのプライバシーの両方を同時に満たせるのでしょうか？