最初に「合計で作成されたノート」という誤った指標からDUSKのプライベート状態を見始めてしまいました。これはストレージの話としては一見すると当然のように聞こえますが、描き出されるのは曲線が1本だけです。@Dusk
ノートツリーは、出力が作成されると成長します。ヌリファイア集合（nullifier set）は、ノートが消費（spent）されると成長します。これらは関連していますが、同じ振る舞いではありません。
すでに60M消費済みの、100MのPhoenixノートを考えてみてください。DUSKは「作成されたノート」の履歴をまだ保持しています。一方でヌリファイア側は、すでに60M件のエントリに到達しています。最終的に70%が消費されるなら、ヌリファイアは70Mになります。ノートが1Bで、ヌリファイアが750Mのときには、問いはさらに居心地が悪くなります。長期的な状態の負担が重くなるのは、どちらの構造でしょうか？
4-in/1-out（4入力/1出力）トランザクションを見れば、より明確になります。ライブラーノート（live notes）は3だけ純減するのに対し、4つの新しいヌリファイアが追加されます。ライブノート数が少ないことは、歴史的な状態が少ないことを意味しません。
ある程度の増加は正常です。プライベートなシステムには、コミットメント（commitments）と、消費済みノートの保護（spent-note protection）が必要です。
本当の試験は、DUSKが利用が積み重なる中で、この2本の曲線を効率よく維持できるかどうかです。プルーニング（pruning）、インデックス（indexing）、証明（proving）、同期（sync）のコストを適切に抑え続けられるでしょうか？ それとも、プライバシーがじわじわとインフラコストの税金になっていくのでしょうか？
DUSKの活動量が難しい指標なのではありません。重要なのは、状態管理の規律（state discipline）です。
#dusk $DUSK
ノートツリーは、出力が作成されると成長します。ヌリファイア集合（nullifier set）は、ノートが消費（spent）されると成長します。これらは関連していますが、同じ振る舞いではありません。
すでに60M消費済みの、100MのPhoenixノートを考えてみてください。DUSKは「作成されたノート」の履歴をまだ保持しています。一方でヌリファイア側は、すでに60M件のエントリに到達しています。最終的に70%が消費されるなら、ヌリファイアは70Mになります。ノートが1Bで、ヌリファイアが750Mのときには、問いはさらに居心地が悪くなります。長期的な状態の負担が重くなるのは、どちらの構造でしょうか？
4-in/1-out（4入力/1出力）トランザクションを見れば、より明確になります。ライブラーノート（live notes）は3だけ純減するのに対し、4つの新しいヌリファイアが追加されます。ライブノート数が少ないことは、歴史的な状態が少ないことを意味しません。
ある程度の増加は正常です。プライベートなシステムには、コミットメント（commitments）と、消費済みノートの保護（spent-note protection）が必要です。
本当の試験は、DUSKが利用が積み重なる中で、この2本の曲線を効率よく維持できるかどうかです。プルーニング（pruning）、インデックス（indexing）、証明（proving）、同期（sync）のコストを適切に抑え続けられるでしょうか？ それとも、プライバシーがじわじわとインフラコストの税金になっていくのでしょうか？
DUSKの活動量が難しい指標なのではありません。重要なのは、状態管理の規律（state discipline）です。
#dusk $DUSK
