Kiko奇科
21.7k 投稿
Kiko奇科
Traders League Badge Beginner
取引を発注
超高頻度トレーダー
4.5年
2.6K+ フォロー
23.8K+ フォロワー
46.2K+ いいね
1 バッジ
投稿
ポートフォリオ
すべて
引用
ライブ
PINNED
翻訳参照
DuskVM vs DuskEVM: Two Paths for Developers
Does a blockchain need to force every developer into the same execution environment?
Dusk takes a different approach by offering two smart contract paths each designed around a different development model.
DuskVM is the native path. Developers write contracts in Rust compile them to WASM and execute them directly on the Dusk L1. This gives contracts direct access to Dusk’s L1 execution model transaction models protocol contracts and capabilities that need to sit close to the base layer including privacy and zero knowledge functionality.
DuskEVM takes a compatibility focused route. Developers can use Solidity or Vyper along with familiar EVM wallets libraries and tooling. Settlement and data availability are provided through DuskDS while DUSK serves as the native gas token.
The distinction is therefore less about choosing which environment is better and more about matching architecture to application requirements DuskVM favors direct L1 execution and Dusk-native capabilities. DuskEVM lowers the barrier for developers already working within the Ethereum ecosystem.
For Dusk providing both paths creates an interesting balance between native functionality and developer familiarity.
Could supporting both native execution and EVM compatibility be a stronger developer strategy than forcing one universal environment?
$DUSK
#dusk @Dusk
Does a blockchain need to force every developer into the same execution environment?
Dusk takes a different approach by offering two smart contract paths each designed around a different development model.
DuskVM is the native path. Developers write contracts in Rust compile them to WASM and execute them directly on the Dusk L1. This gives contracts direct access to Dusk’s L1 execution model transaction models protocol contracts and capabilities that need to sit close to the base layer including privacy and zero knowledge functionality.
DuskEVM takes a compatibility focused route. Developers can use Solidity or Vyper along with familiar EVM wallets libraries and tooling. Settlement and data availability are provided through DuskDS while DUSK serves as the native gas token.
The distinction is therefore less about choosing which environment is better and more about matching architecture to application requirements DuskVM favors direct L1 execution and Dusk-native capabilities. DuskEVM lowers the barrier for developers already working within the Ethereum ecosystem.
For Dusk providing both paths creates an interesting balance between native functionality and developer familiarity.
Could supporting both native execution and EVM compatibility be a stronger developer strategy than forcing one universal environment?
$DUSK
#dusk @Dusk
PINNED
翻訳参照
Staking on Dusk: How DUSK Secures the Network.
What does staking actually contribute to a blockchain beyond earning rewards?
On Dusk staking is directly connected to consensus. Provisioners stake DUSK and participate in the process of proposing and validating blocks. Active provisioners can earn rewards from token emissions and transaction fees making staking part of the network’s security mechanism rather than a separate yield product.
The selection process is also important. Dusk’s deterministic sortition selects block generators and voting committee members through a process weighted by stake. The mechanism is designed so selection frequency is proportional to a provisioner’s stake while remaining reproducible and unpredictable ahead of time.
Consensus then moves through proposal validation and ratification. A selected provisioner proposes a candidate block a committee evaluates it and another committee confirms the validation result. A supermajority of valid votes can produce a successful outcome.
But participation carries responsibility. The current Dusk documentation distinguishes between soft penalties for failed participation and hard penalties for provably invalid consensus behavior including conflicting signatures.
This creates an important relationship between economic stake and network responsibility DUSK is not merely locked it gives participants an economic reason to operate consensus infrastructure correctly.
For @Dusk staking is therefore part of the security architecture itself.
$DUSK #dusk
Does tying economic stake directly to consensus responsibility create a stronger incentive for reliable network participation?
What does staking actually contribute to a blockchain beyond earning rewards?
On Dusk staking is directly connected to consensus. Provisioners stake DUSK and participate in the process of proposing and validating blocks. Active provisioners can earn rewards from token emissions and transaction fees making staking part of the network’s security mechanism rather than a separate yield product.
The selection process is also important. Dusk’s deterministic sortition selects block generators and voting committee members through a process weighted by stake. The mechanism is designed so selection frequency is proportional to a provisioner’s stake while remaining reproducible and unpredictable ahead of time.
Consensus then moves through proposal validation and ratification. A selected provisioner proposes a candidate block a committee evaluates it and another committee confirms the validation result. A supermajority of valid votes can produce a successful outcome.
But participation carries responsibility. The current Dusk documentation distinguishes between soft penalties for failed participation and hard penalties for provably invalid consensus behavior including conflicting signatures.
This creates an important relationship between economic stake and network responsibility DUSK is not merely locked it gives participants an economic reason to operate consensus infrastructure correctly.
For @Dusk staking is therefore part of the security architecture itself.
$DUSK #dusk
Does tying economic stake directly to consensus responsibility create a stronger incentive for reliable network participation?
翻訳参照
dusk
Kiko奇科
·
--
DuskVM vs DuskEVM: Two Paths for Developers
Does a blockchain need to force every developer into the same execution environment?
Dusk takes a different approach by offering two smart contract paths each designed around a different development model.
DuskVM is the native path. Developers write contracts in Rust compile them to WASM and execute them directly on the Dusk L1. This gives contracts direct access to Dusk’s L1 execution model transaction models protocol contracts and capabilities that need to sit close to the base layer including privacy and zero knowledge functionality.
DuskEVM takes a compatibility focused route. Developers can use Solidity or Vyper along with familiar EVM wallets libraries and tooling. Settlement and data availability are provided through DuskDS while DUSK serves as the native gas token.
The distinction is therefore less about choosing which environment is better and more about matching architecture to application requirements DuskVM favors direct L1 execution and Dusk-native capabilities. DuskEVM lowers the barrier for developers already working within the Ethereum ecosystem.
For Dusk providing both paths creates an interesting balance between native functionality and developer familiarity.
Could supporting both native execution and EVM compatibility be a stronger developer strategy than forcing one universal environment?
$DUSK
#dusk @Dusk
Does a blockchain need to force every developer into the same execution environment?
Dusk takes a different approach by offering two smart contract paths each designed around a different development model.
DuskVM is the native path. Developers write contracts in Rust compile them to WASM and execute them directly on the Dusk L1. This gives contracts direct access to Dusk’s L1 execution model transaction models protocol contracts and capabilities that need to sit close to the base layer including privacy and zero knowledge functionality.
DuskEVM takes a compatibility focused route. Developers can use Solidity or Vyper along with familiar EVM wallets libraries and tooling. Settlement and data availability are provided through DuskDS while DUSK serves as the native gas token.
The distinction is therefore less about choosing which environment is better and more about matching architecture to application requirements DuskVM favors direct L1 execution and Dusk-native capabilities. DuskEVM lowers the barrier for developers already working within the Ethereum ecosystem.
For Dusk providing both paths creates an interesting balance between native functionality and developer familiarity.
Could supporting both native execution and EVM compatibility be a stronger developer strategy than forcing one universal environment?
$DUSK
#dusk @Dusk
翻訳参照
dusk
Kiko奇科
·
--
Staking on Dusk: How DUSK Secures the Network.
What does staking actually contribute to a blockchain beyond earning rewards?
On Dusk staking is directly connected to consensus. Provisioners stake DUSK and participate in the process of proposing and validating blocks. Active provisioners can earn rewards from token emissions and transaction fees making staking part of the network’s security mechanism rather than a separate yield product.
The selection process is also important. Dusk’s deterministic sortition selects block generators and voting committee members through a process weighted by stake. The mechanism is designed so selection frequency is proportional to a provisioner’s stake while remaining reproducible and unpredictable ahead of time.
Consensus then moves through proposal validation and ratification. A selected provisioner proposes a candidate block a committee evaluates it and another committee confirms the validation result. A supermajority of valid votes can produce a successful outcome.
But participation carries responsibility. The current Dusk documentation distinguishes between soft penalties for failed participation and hard penalties for provably invalid consensus behavior including conflicting signatures.
This creates an important relationship between economic stake and network responsibility DUSK is not merely locked it gives participants an economic reason to operate consensus infrastructure correctly.
For @Dusk staking is therefore part of the security architecture itself.
$DUSK #dusk
Does tying economic stake directly to consensus responsibility create a stronger incentive for reliable network participation?
What does staking actually contribute to a blockchain beyond earning rewards?
On Dusk staking is directly connected to consensus. Provisioners stake DUSK and participate in the process of proposing and validating blocks. Active provisioners can earn rewards from token emissions and transaction fees making staking part of the network’s security mechanism rather than a separate yield product.
The selection process is also important. Dusk’s deterministic sortition selects block generators and voting committee members through a process weighted by stake. The mechanism is designed so selection frequency is proportional to a provisioner’s stake while remaining reproducible and unpredictable ahead of time.
Consensus then moves through proposal validation and ratification. A selected provisioner proposes a candidate block a committee evaluates it and another committee confirms the validation result. A supermajority of valid votes can produce a successful outcome.
But participation carries responsibility. The current Dusk documentation distinguishes between soft penalties for failed participation and hard penalties for provably invalid consensus behavior including conflicting signatures.
This creates an important relationship between economic stake and network responsibility DUSK is not merely locked it gives participants an economic reason to operate consensus infrastructure correctly.
For @Dusk staking is therefore part of the security architecture itself.
$DUSK #dusk
Does tying economic stake directly to consensus responsibility create a stronger incentive for reliable network participation?
翻訳参照
write ✍️ your idea
Kiko奇科
·
--
DuskVM vs DuskEVM: Two Paths for Developers
Does a blockchain need to force every developer into the same execution environment?
Dusk takes a different approach by offering two smart contract paths each designed around a different development model.
DuskVM is the native path. Developers write contracts in Rust compile them to WASM and execute them directly on the Dusk L1. This gives contracts direct access to Dusk’s L1 execution model transaction models protocol contracts and capabilities that need to sit close to the base layer including privacy and zero knowledge functionality.
DuskEVM takes a compatibility focused route. Developers can use Solidity or Vyper along with familiar EVM wallets libraries and tooling. Settlement and data availability are provided through DuskDS while DUSK serves as the native gas token.
The distinction is therefore less about choosing which environment is better and more about matching architecture to application requirements DuskVM favors direct L1 execution and Dusk-native capabilities. DuskEVM lowers the barrier for developers already working within the Ethereum ecosystem.
For Dusk providing both paths creates an interesting balance between native functionality and developer familiarity.
Could supporting both native execution and EVM compatibility be a stronger developer strategy than forcing one universal environment?
$DUSK
#dusk @Dusk
Does a blockchain need to force every developer into the same execution environment?
Dusk takes a different approach by offering two smart contract paths each designed around a different development model.
DuskVM is the native path. Developers write contracts in Rust compile them to WASM and execute them directly on the Dusk L1. This gives contracts direct access to Dusk’s L1 execution model transaction models protocol contracts and capabilities that need to sit close to the base layer including privacy and zero knowledge functionality.
DuskEVM takes a compatibility focused route. Developers can use Solidity or Vyper along with familiar EVM wallets libraries and tooling. Settlement and data availability are provided through DuskDS while DUSK serves as the native gas token.
The distinction is therefore less about choosing which environment is better and more about matching architecture to application requirements DuskVM favors direct L1 execution and Dusk-native capabilities. DuskEVM lowers the barrier for developers already working within the Ethereum ecosystem.
For Dusk providing both paths creates an interesting balance between native functionality and developer familiarity.
Could supporting both native execution and EVM compatibility be a stronger developer strategy than forcing one universal environment?
$DUSK
#dusk @Dusk
翻訳参照
Support
Kiko奇科
·
--
DuskVM vs DuskEVM: Two Paths for Developers
Does a blockchain need to force every developer into the same execution environment?
Dusk takes a different approach by offering two smart contract paths each designed around a different development model.
DuskVM is the native path. Developers write contracts in Rust compile them to WASM and execute them directly on the Dusk L1. This gives contracts direct access to Dusk’s L1 execution model transaction models protocol contracts and capabilities that need to sit close to the base layer including privacy and zero knowledge functionality.
DuskEVM takes a compatibility focused route. Developers can use Solidity or Vyper along with familiar EVM wallets libraries and tooling. Settlement and data availability are provided through DuskDS while DUSK serves as the native gas token.
The distinction is therefore less about choosing which environment is better and more about matching architecture to application requirements DuskVM favors direct L1 execution and Dusk-native capabilities. DuskEVM lowers the barrier for developers already working within the Ethereum ecosystem.
For Dusk providing both paths creates an interesting balance between native functionality and developer familiarity.
Could supporting both native execution and EVM compatibility be a stronger developer strategy than forcing one universal environment?
$DUSK
#dusk @Dusk
Does a blockchain need to force every developer into the same execution environment?
Dusk takes a different approach by offering two smart contract paths each designed around a different development model.
DuskVM is the native path. Developers write contracts in Rust compile them to WASM and execute them directly on the Dusk L1. This gives contracts direct access to Dusk’s L1 execution model transaction models protocol contracts and capabilities that need to sit close to the base layer including privacy and zero knowledge functionality.
DuskEVM takes a compatibility focused route. Developers can use Solidity or Vyper along with familiar EVM wallets libraries and tooling. Settlement and data availability are provided through DuskDS while DUSK serves as the native gas token.
The distinction is therefore less about choosing which environment is better and more about matching architecture to application requirements DuskVM favors direct L1 execution and Dusk-native capabilities. DuskEVM lowers the barrier for developers already working within the Ethereum ecosystem.
For Dusk providing both paths creates an interesting balance between native functionality and developer familiarity.
Could supporting both native execution and EVM compatibility be a stronger developer strategy than forcing one universal environment?
$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 の実行環境全体での活動を含み、DuskEVM では DUSK が明確にネイティブのガストークンとして使われます。
2つ目の役割は、さらに根本的なステーキングです。
Dusk はプロビジョナーを用いてコンセンサスに参加し、ブロックを提案し検証するために、アクティブなプロビジョナーが選定されます。現行ドキュメントによれば、直接ステーキングにはプロビジョナーノードの運用が必要であり、報酬はコンセンサス参加とアクティブなステークに基づきます。
DUSK はまた、エコシステムのさまざまな部分をつなぎます。ドキュメントでは Dusk L1 と DuskEVM 間での移動が説明されており、開発者は、実行やツール要件に応じて DuskVM または DuskEVM を通じて構築できます。
つまり重要なのは、単に DUSK がネットワークのネイティブ資産であるということではありません。そのユーティリティは、ネットワークが機能するための仕組みに組み込まれているのです。
@Dusk にとって、トークンのユーティリティはインフラと密接に結びついていると言えます。
$DUSK #dusk
ネイティブトークンは、そのユーティリティがネットワークの中核の運用と切り離せないとき、より意味のあるものになるのでしょうか？
シタデル：デジタル・アイデンティティのための選択的開示
デジタル・アイデンティティは、多くの場合「すべてを開示して自分が誰かを証明するか」「アプリケーションの要件を満たすには十分すぎるほどには開示しないか」という難しい選択を生みます。
Duskは、そのドキュメントでシタデルを「選択的開示のためのネットワークのアイデンティティおよびアクセス・レイヤー」として説明し、この問題に取り組んでいます。
この違いは重要です。選択的開示は、単にアイデンティティ情報を非公開に保つことだけを意味しません。特定のやり取りにおいて実際に開示する必要がある情報に基づいて、アクセスを設計することです。
これはDuskのより広範なアーキテクチャにも自然に当てはまります。ネットワークはすでに、公的アカウントとシールドされたアカウントを区別しており、取引を異なる可視性レベルで動作させられるようになっています。シタデルは、その考え方を取引データだけでなく、アイデンティティとアクセスへと拡張します。
またDuskのドキュメントには、シタデル・セルフ・ソブリン・アイデンティティが、ゼロ知識システムや属性のブラインディングによる認証に関連する技術的取り組みと並んで、Dusk Network上の専用の研究論文として掲載されています。
ここで私が注目しているのは、アイデンティティは、ユーザーが何かを証明する必要があるからといって、必ずしも恒久的な公開記録になる必要はない、というアーキテクチャ上の原則です。
@Dusk における選択的開示は、プライバシーと実践的なアクセス制御を結びつけており、とりわけブロックチェーンの基盤が、アイデンティティや認可が重要になるアプリケーションと連携するときに、特に関係性が高いです。
#dusk $DUSK
選択的開示は、デジタル・プライバシーと、規制された金融システムにおけるアイデンティティ要件との間にある「欠けたレイヤー」になり得るのでしょうか？
デジタル・アイデンティティは、多くの場合「すべてを開示して自分が誰かを証明するか」「アプリケーションの要件を満たすには十分すぎるほどには開示しないか」という難しい選択を生みます。
Duskは、そのドキュメントでシタデルを「選択的開示のためのネットワークのアイデンティティおよびアクセス・レイヤー」として説明し、この問題に取り組んでいます。
この違いは重要です。選択的開示は、単にアイデンティティ情報を非公開に保つことだけを意味しません。特定のやり取りにおいて実際に開示する必要がある情報に基づいて、アクセスを設計することです。
これはDuskのより広範なアーキテクチャにも自然に当てはまります。ネットワークはすでに、公的アカウントとシールドされたアカウントを区別しており、取引を異なる可視性レベルで動作させられるようになっています。シタデルは、その考え方を取引データだけでなく、アイデンティティとアクセスへと拡張します。
またDuskのドキュメントには、シタデル・セルフ・ソブリン・アイデンティティが、ゼロ知識システムや属性のブラインディングによる認証に関連する技術的取り組みと並んで、Dusk Network上の専用の研究論文として掲載されています。
ここで私が注目しているのは、アイデンティティは、ユーザーが何かを証明する必要があるからといって、必ずしも恒久的な公開記録になる必要はない、というアーキテクチャ上の原則です。
@Dusk における選択的開示は、プライバシーと実践的なアクセス制御を結びつけており、とりわけブロックチェーンの基盤が、アイデンティティや認可が重要になるアプリケーションと連携するときに、特に関係性が高いです。
#dusk $DUSK
選択的開示は、デジタル・プライバシーと、規制された金融システムにおけるアイデンティティ要件との間にある「欠けたレイヤー」になり得るのでしょうか？
実用性を損なわないプライバシー。
ブロックチェーン上でのプライバシーは、情報を保護することがシステムの利用のしにくさにつながり、検証や統合まで難しくしてしまうため、実現が困難になります。
Duskは、この問題に対し、さまざまな取引の可視性レベルをネットワークのアーキテクチャの一部として組み込むことで対応しています。
そのMoonlightモデルでは、公開アカウントに基づく取引を提供します。残高の公開アドレスや取引のアクティビティは透明性を保てるため、可視性や分かりやすい検証が必要な場面で有用です。
一方、Phoenixは取引の機密性が重要である場合に逆のアプローチを取ります。これは、ノートのnullifierとゼロ知識証明を中心に構築された、シールドされたUTXOベースの取引を使用します。ネットワークは、送信者、受信者、送金額を公開せずに、取引が有効であることを検証できます。
しかし、Phoenixにおけるプライバシーは単に「誰からも情報を隠す」ことだけではありません。このプロトコルには、ユーザーが自分宛ての取引を識別できる一方で、支出の権限は保護されたままにするためのビューキーが含まれています。ホワイトペーパーでは、ビューキーによって、委任された当事者にノートを支出する権限を与えることなく、委任先による取引スキャンを可能にする方法についても説明されています。
この違いは重要です。実務における金融インフラでの機密性は、情報への制御されたアクセスを放棄することを必ずしも意味しません。
したがって、@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で最も興味深い選択の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
予測可能で検証可能な最終性は、単にトランザクション処理能力（スループット）を最大化することより、金融向けブロックチェーンにとってより重要なのでしょうか？
ブロックチェーンは、実際にトランザクションを最終確定（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
ブロックチェーン・ネットワークがスケールするにつれて、通信アーキテクチャはコンセンサスそのものと同じくらい重要になっていくのでしょうか？
ネットワークはまず、ノード間で情報を確実にやり取りする方法を必要とします。
そこで、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の答えは、単一の特徴にあるのではありません。複数の層がどのように連携して設計されているかにあります。
基盤には、ネットワークのコンセンサス最終性とデータ可用性レイヤーである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
ブロックチェーン基盤は、本当に規模に応じて、機関のコンプライアンスとユーザーのプライバシーの両方を同時に満たせるのでしょうか？
課題は、単に金融資産をオンチェーンに載せることではありません。金融市場には、プライバシーの監査可能性、規制への適合、スケーラビリティ、そして信頼できる最終確定性を、同時に満たすことが求められます。Dusk のホワイトペーパーでは、これを中核となるインフラの問題として位置づけています。機微な金融情報は、常に公開することはできない一方で、機関側には監督とコンプライアンスを支える仕組みが必要です。
そこで @Dusk
は、別のアーキテクチャアプローチを採用します。
プライバシーを外部のレイヤーとして扱うのではなく、Dusk は取引モデルを通じてネットワークに組み込んでいます。Moonlight は透明な、口座ベースのモデルを提供し、Phoenix はシールド取引に対して UTXO ベースの設計を採用します。ホワイトペーパーでは、さらに、Succinct Attestation を最終確定性を数秒で実現するための合意メカニズムとして説明しており、金融市場の低遅延要件をターゲットにしています。
重要な点は、Dusk がブロックチェーン導入を純粋に技術的な問題として提示していないことです。実際にオンチェーンで金融インフラが運用できるかどうかを左右する、機関の要件に取り組もうとしているのです。
そのため $DUSK は、トークンの役割を超えて研究する価値があります。真の問いは、プライバシーのコンプライアンスとブロックチェーンネイティブの実行が、それぞれについて機関がどちらかを犠牲にすることなく共存できるかどうかです。
#dusk
ブロックチェーン基盤は、本当に規模に応じて、機関のコンプライアンスとユーザーのプライバシーの両方を同時に満たせるのでしょうか？
ログインして、さらにコンテンツを読む