#dusk Ein Detail in Dusk’ Konsensarchitektur macht das Ganze noch interessanter. Anstatt die Stimme jedes Validators separat zu speichern, aggregiert das Netzwerk BLS-Signaturen zu einem einzigen Nachweis. In einer herkömmlichen Konfiguration benötigt jede Validator-Signatur individuellen Speicherplatz im Block. In Dusk werden Hunderte von Ausschussabstimmungen in eine einzige konstant große Signatur komprimiert, während dennoch jeder Teilnehmer verifiziert wird.
Ich denke, die nützliche Idee dabei ist die Skalierbarkeit. Dusk hat Knoten nicht dazu gezwungen, jede unabhängige Signatur zu speichern, weil ein dauerhaftes Anwachsen der Validatoren (Validator Bloat) das Betreiben eines Knotens mit der Zeit zu teuer macht.
Es gibt sogar einen praktischen Interessenausgleich: Das Aggregieren von BLS-Signaturen erfordert etwas mehr kryptografische Rechenleistung, spart jedoch massive Bandbreite und On-Chain-Speicher. Das hilft dabei, die Hardwareanforderungen für Node-Runner niedrig zu halten.
Die bessere Frage ist also nicht „Wie viele Validatoren können signieren?“ sondern „Wie effizient kann die Chain ihren Konsens aufzeichnen?“ $DUSK @Dusk
Ich denke, die nützliche Idee dabei ist die Skalierbarkeit. Dusk hat Knoten nicht dazu gezwungen, jede unabhängige Signatur zu speichern, weil ein dauerhaftes Anwachsen der Validatoren (Validator Bloat) das Betreiben eines Knotens mit der Zeit zu teuer macht.
Es gibt sogar einen praktischen Interessenausgleich: Das Aggregieren von BLS-Signaturen erfordert etwas mehr kryptografische Rechenleistung, spart jedoch massive Bandbreite und On-Chain-Speicher. Das hilft dabei, die Hardwareanforderungen für Node-Runner niedrig zu halten.
Die bessere Frage ist also nicht „Wie viele Validatoren können signieren?“ sondern „Wie effizient kann die Chain ihren Konsens aufzeichnen?“ $DUSK @Dusk
