私はDUSKのようなチェーンを判断するとき、TPS単体ではあまり有用だとは感じたことがありません。

チャート上では見栄えがします。

しかし、実際の負荷がやって来ると話は別です。

プライバシー。証明生成。コントラクトの実行。状態の成長。同期を保とうとするノード。

まさにここが面白くなるところです。

DUSKは、多くのものよりもこの点をよく理解しているようです。

すべてを1つのレイヤーにやらせるのではなく、ネットワークが仕事を分割します。

DuskDSはコンセンサス、決済、データ利用可能性を扱います。

DuskVMはネイティブ・コントラクトを扱います。

DuskEVMはSolidityベースのアプリにおなじみの実行環境を提供します。

アーキテクチャの話に聞こえるかもしれません。

でも重要なのは、どのワークロードも遅くなる経路がそれぞれ違うからです。

そして、もうひとつ静かな要素があります。Kadcastです。

ランダムな相手に延々とブロックをゴシップするのではなく、伝播には構造化されたネットワークを使います。重複したトラフィックが減り、配信がより予測可能になります。

それは派手なマーケティング図にはならないかもしれません。

でもネットワークが混雑すると、無駄な帯域は現実のコストになります。

そして、次に多くの人が見落としがちな部分があります：

プライバシーは計算コストを要する、ということです。

ゼロ知識証明は実際に作業です。コンセンサスを速くできても、証明生成がボトルネックになれば壁にぶつかります。

だから、私が思うDUSKの本当のスケーラビリティの問いはこうです。

「大量のトランザクションを処理できるか？」

それではなく、

それらのトランザクションが高コストになったとき、どうなるのか？

ファイナリティは予測可能なままでいられるのか？

ノードは追いつけるのか？

プライベートなトランザクションは、通常のスマートコントラクトの活動と共存できるのか？

それが難しいテストです。

正直に言うと、細かなエンジニアリング上の判断が、大きな数字よりも私には多くを語ってくれます。

データがどう動くのか。状態がどう参照されるのか。ノードがどう同期するのか。証明がどう生成されるのか。実行が決済からどう切り離されるのか。

どれもワクワクする話には聞こえません。

でも、だいたいの場合、そこでこそ本当のスケーラビリティが決まります。

壊れにくいチェーンとは、すべてのコンポーネントがとんでもなく速いものではありません。

高コストな処理が、自分の持ち場を分かっているものです。

私は、その点をDUSKがどれだけできているかを、ずっと見続けています。

#dusk $DUSK @Dusk