Eine Zahl hat mich aufgehalten: Kapazität für über 17 Milliarden Blätter, von einem Baum, der nur 34 Ebenen tief ist.
Dusk's Phoenix-Modell verwendet einen binären Merkle-Baum, um den Beweis für jede Notiz zu halten—und dort sitzt der eigentliche Trick: Die Kapazität wächst exponentiell, während der Einschlusspfad nur linear wächst. Von Tiefe 34 auf 35: Die Kapazität verdoppelt sich, aber der Beweispfad wird nur um ein paar Prozent länger. Diese Asymmetrie ist für eine datenschutzorientierte Kette besonders wichtig, denn jede Transaktion trägt einen Zero-Knowledge-Beweis, und je kleiner der Beweis bleibt, desto besser.
Doch die Größe der Zahl ist nur eine theoretische Obergrenze. Was tatsächlich bestimmt, wie lange diese Kapazität hält, ist, wie schnell in der Praxis neue Notizen erstellt werden. Bei geringer Transaktionsdurchsatzrate könnte der Baum Jahrzehnte brauchen, um sich zu füllen. Wenn die Akzeptanz stark anzieht, könnte dieselbe Kapazität in wenigen Monaten unter echten Druck geraten.
Das wirft die spannendere Frage auf – was passiert, wenn der Baum voll wird? Archivspeicher, Beweiskosten, State-Sync: Skalieren diese Dinge reibungslos mit der Notiz-Erstellung, oder wird zuerst etwas anderes zum Engpass? Eine riesige Zahl sieht auf dem Papier beeindruckend aus, aber die langfristige Nutzbarkeit hängt davon ab, wie diese Zahl verwendet wird—nicht nur davon, wie groß sie ist.
Ist eine mathematisch enorme Kapazität dasselbe wie über Jahre realer Nutzung bequem im Betrieb zu bleiben?

#dusk $DUSK @Dusk