Ich komme immer wieder auf dieses Bild eines Stausees hinter einer alten Staumauer zurück: Das Wasser fließt das ganze Jahr über, und irgendjemand muss entscheiden, wann das Tor aufgeht. Der 10%-Cut von Dusk in den DNDF funktioniert genauso. Das ist kein Erlös, der in ein Unternehmensbürtokonto verschwindet – es ist Wasser, das sich hinter einem Tor sammelt, das die Gemeinschaft kontrolliert. Das eigentliche Risiko ist nicht das Sammeln, sondern dass das Tor nie aufgeht: Ein Fonds, der nur dasteht und wächst, wird zu einem Hebel, und Bauleute, die von Grants abhängen, richten ihr Verhalten danach aus, wer den Veröffentlichungszeitplan kontrolliert. Ich würde lieber die Auszahlungs-Geschwindigkeit beobachten als den Prozentsatz selbst.

Der Credit-Burn-Mechanismus ist eine andere Art von Ventil. Das Verbrennen nicht beanspruchter Credits entfernt das naheliegende Motiv für einen Generator, auf einem früheren Iterations-Block ein sauberes Design „sitzen zu bleiben“ – da gibt es keinen Streit. Aber es schließt nur die Tür dessen, was man freiwillig betreten würde. Nichts hindert einen Angreifer daran, die Weitergabe einfach direkt zu blockieren. Das ist ein Kadcast- und Timeout-Problem, kein Anreizproblem – und ich glaube auch nicht, dass das Whitepaper das in die eine oder andere Richtung endgültig klärt. Dafür bräuchte man verpasste-Slot-Daten, nach Iteration aufgeschlüsselt, um zu wissen, ob es ökonomisch real ist oder nur theoretisch.

Was mich jedoch weitaus mehr beunruhigt, ist das Nullifier-Set. Es ist aus Notwendigkeit „append-only“: Das Löschen einer verbrauchten Notiz würde verraten, welche verbraucht wurde, also wächst es nur weiter, für immer, per Design. Andere Privacy-Chains stützen sich auf spärliche Bäume oder Epochentrennung, um das handhabbar zu halten. Ich habe Dusk’s Antwort nirgends in den Dokumenten finden können. Das wäre die Frage, die ich ihren Ingenieuren direkt stellen würde – nicht die Treasury-Frage, die alle anderen immer wieder stellen.

#dusk $DUSK @Dusk