#dusk $DUSK @Dusk Dusk のホワイトペーパーを読んでいると、見落とされがちな細部に気づきました。契約ごとの説明で、使われている時制が異なるのです。
Section 6.2 では、Genesis、Transfer、Stake Contracts を説明する際、主にそれらが現在担っている機能、つまり送金、Gas の控除、ステーキングなどを述べています。これらは Dusk ネットワークを稼働させるために必要な基盤インフラに当たります。
一方、Section 6.3 では、Zedger と Citadel を紹介するとき、明らかにより未来志向の表現が増えています。たとえば「designed to be deployed」「will allow」などです。
時制だけでは、ある機能が「まだ実装されていない」ことを証明することはできません。しかし技術文書のシグナルとしては、少なくとも次のことを私たちに思い出させます。ホワイトペーパーにおけるアーキテクチャ設計、既にデプロイされたプロトコル、そして現在実際に利用できるプロダクトの能力は、同じ概念ではないということです。
次に Dusk 公式サイトを見ると、異なる製品の状態が Live、Building、Testnet としてすでに明示されています。これはむしろ、より具体的な参照枠を与えてくれます。ある能力を議論するとき、それは「設計されたもの」なのか、「すでにデプロイ済み」なのか、あるいは「実際に検証・利用できる」ものなのかを区別すべきではないのでしょうか？
また今日の Dusk による、規制されたオンチェーン金融に関する議論も、投資家のアクセス許可、管理された譲渡、プライバシーの開示、そして決済など、完全なプロセス全体にますます集中しています。
すると、問題はより具体的になります。
Zedger、XSC、Citadel といったこれらの能力は、現時点で「設計、デプロイ、検証可能な利用」のそれぞれどの段階にありますか？
もし Dusk の目標が、実在する規制済みの金融市場を支えることにあるなら、ホワイトペーパー上の設計から実際の市場利用へ移行するにあたり、外部から最も検証される必要がある重要な段階は何でしょうか？#dusk $DUSK @Dusk
Section 6.2 では、Genesis、Transfer、Stake Contracts を説明する際、主にそれらが現在担っている機能、つまり送金、Gas の控除、ステーキングなどを述べています。これらは Dusk ネットワークを稼働させるために必要な基盤インフラに当たります。
一方、Section 6.3 では、Zedger と Citadel を紹介するとき、明らかにより未来志向の表現が増えています。たとえば「designed to be deployed」「will allow」などです。
時制だけでは、ある機能が「まだ実装されていない」ことを証明することはできません。しかし技術文書のシグナルとしては、少なくとも次のことを私たちに思い出させます。ホワイトペーパーにおけるアーキテクチャ設計、既にデプロイされたプロトコル、そして現在実際に利用できるプロダクトの能力は、同じ概念ではないということです。
次に Dusk 公式サイトを見ると、異なる製品の状態が Live、Building、Testnet としてすでに明示されています。これはむしろ、より具体的な参照枠を与えてくれます。ある能力を議論するとき、それは「設計されたもの」なのか、「すでにデプロイ済み」なのか、あるいは「実際に検証・利用できる」ものなのかを区別すべきではないのでしょうか？
また今日の Dusk による、規制されたオンチェーン金融に関する議論も、投資家のアクセス許可、管理された譲渡、プライバシーの開示、そして決済など、完全なプロセス全体にますます集中しています。
すると、問題はより具体的になります。
Zedger、XSC、Citadel といったこれらの能力は、現時点で「設計、デプロイ、検証可能な利用」のそれぞれどの段階にありますか？
もし Dusk の目標が、実在する規制済みの金融市場を支えることにあるなら、ホワイトペーパー上の設計から実際の市場利用へ移行するにあたり、外部から最も検証される必要がある重要な段階は何でしょうか？#dusk $DUSK @Dusk
