@Dusk_Foundation DUSK NetworkのPhoenixの注記ツリーを見つめることになりました。深さ34という数字は小さな実装上の選択に見えるかもしれませんが、その背後にあるスケーリング挙動は小さくありません。
明らかな数は17,179,869,184通りの可能なリーフです。私は、その数字自体がほとんど注意をそらすものだと思っています。Phoenixは深さ34で二分Merkleツリーを定義しているため、収容力（キャパシティ）は指数的に増えますが、包含（インクルージョン）パスは線形にしか伸びません。使った各入力（spent input）には、アンカーに対する有効なMerkleパスがそれでも必要です。
深さ32では約4.29Bリーフ、深さ34では17.18B、深さ36では68.72Bです。追加のレベルが2つ増えると、収容力は4倍になります。34から35へ進むと再び収容力は2倍になりますが、パスの深さは34ステップから35ステップへ増えるだけで、上昇は約2.9%です。
これはDUSKにとって効率的に見えます。しかし理論上の収容力は、実際の履歴（history）管理と同じではありません。
本当の試験は、注記の作成率と、証明（proof）およびストレージ管理の規律（ディシプリン）とのバランスです。
ツリーは実際にどれくらいの速さで埋まるのでしょうか？履歴が成長するにつれて、証明コスト、ウィットネス（証拠データ）の取り扱い、アーカイブストレージ、状態アクセスはどうなりますか？
ある程度のオーバーヘッドは正常です。プライバシーには構造が必要です。
私が確信できないのは、DUSK Networkが、数学的に巨大なだけでなく、実運用でも快適に保てる深さを選んだのかどうかです。
#dusk $DUSK #dusk $DUSK @Dusk
明らかな数は17,179,869,184通りの可能なリーフです。私は、その数字自体がほとんど注意をそらすものだと思っています。Phoenixは深さ34で二分Merkleツリーを定義しているため、収容力（キャパシティ）は指数的に増えますが、包含（インクルージョン）パスは線形にしか伸びません。使った各入力（spent input）には、アンカーに対する有効なMerkleパスがそれでも必要です。
深さ32では約4.29Bリーフ、深さ34では17.18B、深さ36では68.72Bです。追加のレベルが2つ増えると、収容力は4倍になります。34から35へ進むと再び収容力は2倍になりますが、パスの深さは34ステップから35ステップへ増えるだけで、上昇は約2.9%です。
これはDUSKにとって効率的に見えます。しかし理論上の収容力は、実際の履歴（history）管理と同じではありません。
本当の試験は、注記の作成率と、証明（proof）およびストレージ管理の規律（ディシプリン）とのバランスです。
ツリーは実際にどれくらいの速さで埋まるのでしょうか？履歴が成長するにつれて、証明コスト、ウィットネス（証拠データ）の取り扱い、アーカイブストレージ、状態アクセスはどうなりますか？
ある程度のオーバーヘッドは正常です。プライバシーには構造が必要です。
私が確信できないのは、DUSK Networkが、数学的に巨大なだけでなく、実運用でも快適に保てる深さを選んだのかどうかです。
#dusk $DUSK #dusk $DUSK @Dusk