最も危険な結果は、ノード同士が殴り合うことではなく、すべてのノードが同じ検証コードを呼び出し、その結果を整然と間違って検証してしまうことだ。
私は @Dusk の歴史的なホワイトペーパーと、現在のドキュメントを突き合わせた。旧資料ではこの Rust/WASM ランタイムを Piecrust と呼んでいたが、現行ドキュメントでは DuskVM としている。名称は進化しているが、重要な設計は変わっていない。つまり、コントラクトは PLONK、Groth16、BLS などの暗号学的検証を、ホスト層の共通のエントリポイントに委ねることができ、各自で個別に実装する必要はない。
利点はとても現実的だ。開発者は、ミスが起きやすい暗号コードをさらに1セット書かずに済むし、ノードも WASM サンドボックス内で基盤となる演算を繰り返す必要がない。結果としてアプリケーションは軽くなり、検証ルールもより統一しやすい。
代償も同様に集約される。アプリケーションのコントラクトが誤ると、まず自分自身が先に傷つく。一方で、共有バリデータが入力解析、バージョン選択、または境界条件で誤りを起こすと、それに依存するすべてのコントラクトに影響が及ぶ可能性がある。全網で一致してしまい、「皆が同じルールを実行した」ということしか証明できなくなる。
Dusk は 2026年3月の Aegis アップグレードで PLONK V3 と新しい BLS の挙動を有効化し、コントラクトで使用する BLS host query もブロック高に応じて切り替わる。過去のブロックは旧バリデータを呼び、新しいデータは新バージョンを使用する。高さの選び間違いがあると、取引の有効性について異なる結論になり得る。
だから私は監査レポートの数字を眺めるだけではなく、バリデータのバージョン、アップグレードの高さ、テストベクタ、キャッシュ無効化、そしてロールバック演習まで監視する。$DUSK が Gas とコンセンサスの安全性を担うが、金融アプリを支えているのはそれ以外にもこうした公共の検証エントリポイントだ。速さはシステムがどれだけ走るかを決め、バリデータは、それが間違いまでどれだけ速く走らせてしまうかを決める。
#dusk
私は @Dusk の歴史的なホワイトペーパーと、現在のドキュメントを突き合わせた。旧資料ではこの Rust/WASM ランタイムを Piecrust と呼んでいたが、現行ドキュメントでは DuskVM としている。名称は進化しているが、重要な設計は変わっていない。つまり、コントラクトは PLONK、Groth16、BLS などの暗号学的検証を、ホスト層の共通のエントリポイントに委ねることができ、各自で個別に実装する必要はない。
利点はとても現実的だ。開発者は、ミスが起きやすい暗号コードをさらに1セット書かずに済むし、ノードも WASM サンドボックス内で基盤となる演算を繰り返す必要がない。結果としてアプリケーションは軽くなり、検証ルールもより統一しやすい。
代償も同様に集約される。アプリケーションのコントラクトが誤ると、まず自分自身が先に傷つく。一方で、共有バリデータが入力解析、バージョン選択、または境界条件で誤りを起こすと、それに依存するすべてのコントラクトに影響が及ぶ可能性がある。全網で一致してしまい、「皆が同じルールを実行した」ということしか証明できなくなる。
Dusk は 2026年3月の Aegis アップグレードで PLONK V3 と新しい BLS の挙動を有効化し、コントラクトで使用する BLS host query もブロック高に応じて切り替わる。過去のブロックは旧バリデータを呼び、新しいデータは新バージョンを使用する。高さの選び間違いがあると、取引の有効性について異なる結論になり得る。
だから私は監査レポートの数字を眺めるだけではなく、バリデータのバージョン、アップグレードの高さ、テストベクタ、キャッシュ無効化、そしてロールバック演習まで監視する。$DUSK が Gas とコンセンサスの安全性を担うが、金融アプリを支えているのはそれ以外にもこうした公共の検証エントリポイントだ。速さはシステムがどれだけ走るかを決め、バリデータは、それが間違いまでどれだけ速く走らせてしまうかを決める。
#dusk
