ある数が私を止めた——17 billion超のリーフを収容できる容量が、深さ34段までの木から成り立っていること。
DuskのPhoenixモデルは、すべてのノートの証明を保持するためにバイナリ・メルクルツリーを使っていて、肝となる「本当の仕掛け」はそこにある——容量は指数関数的に増える一方で、包含（インクルージョン）経路は線形にしか伸びない。深さ34から35に上げれば容量は2倍になるが、証明経路はほんの数パーセントだけ長くなるにとどまる。この非対称性が、プライバシー重視のチェーンにとって非常に重要なのは、すべての取引がゼロ知識証明を運ぶからで、その証明が小さく保たれるほど良い。

しかし、その数の大きさは理論上の上限にすぎない。実際にどれくらいの期間その容量が持つかを決めるのは、現場でどれだけ新しいノートが作られているかの速さだ。取引のスループットが低ければ、ツリーが満杯になるまで数十年かかる可能性もある。もし導入が急増すれば、その同じ容量が現実の圧力に晒されるのは、数か月のうちの話になりうる。

それよりも面白い問いは——ツリーが満たされていくとどうなるのか？ アーカイブ用ストレージ、証明コスト、ステート同期などは、ノート作成とともにうまくスケールしていくのだろうか。それとも、まずどこかに歪みが出始めるのか？ 紙の上では巨大な数は見栄えがするが、長期的な使い勝手は、その数の大きさそのものではなく、実際にどのように使われるかにかかっている。

数学的に途方もなく巨大な容量を持つことは、何年もの実運用の中でずっと快適に運用できることと同じなのだろうか？

#dusk $DUSK @Dusk