#dusk $DUSK @Dusk
Ich bin diese Woche genau durchgegangen, wie ein Dusk-Block tatsächlich zertifiziert wird, weil ich verstehen wollte, was eine „Beglaubigung“ ("attestation") inhaltlich enthält – nicht nur, dass das Quorum erreicht wurde, sondern wie der Beweis strukturell aussieht.
Das Konsensdesign hat eine zweistufige Bestätigung, nachdem ein Blockkandidat vorgeschlagen wurde: Validierung, bei der die Komiteemitglieder Valid oder Invalid abstimmen, und Ratifizierung, bei der ein zweites Komitee das Validierungsergebnis bestätigt. Wenn beide Schritte das Quorum erreichen, wird eine erfolgreiche Beglaubigung erzeugt.
Was in einer Beglaubigung steckt: der Abstimmungstyp, der das Quorum erreicht (Valid, Invalid, NoCandidate oder NoQuorum), plus aggregierte BLS-Signaturen aus beiden Schritten (Validierung und Ratifizierung). Und außerdem ein Bitset. Das Bitset war der Teil, der in Zusammenfassungen nirgends erklärt worden war.
Das Bitset gibt an, welche Komiteemitglieder’ Signaturen in der Aggregation enthalten sind. Wenn das Komitee [P0, P1, P2, P3] ist und das Bitset [0, 1, 0, 1] lautet, bedeutet das: P1 und P3 haben signiert.
Dieser Teil ist solide. Eine kompakte Beglaubigung trägt alles, was zur Verifikation des Quorums nötig ist – die Abstimmung, den aggregierten Beweis und den Mitgliedschaftseintrag – ohne dass die Größe linear mit der Komiteegröße skaliert.
Schwieriger nachzuvollziehen ist, was passiert, wenn Beglaubigungen sich ansammeln. Ein Block, der „bestätigt“ ist, benötigt ausreichende Folgeb-Blocks mit eigenen Beglaubigungen. Wenn Beglaubigungen in der Praxis groß sind oder wenn Knoten vollständige Beglaubigungs-Historien für den Sync speichern müssen, entstehen Speicher- und Bandbreitenkosten, die in der reinen Quorum-Beschreibung allein nicht sichtbar werden.
Ich denke tatsächlich, dass das Bitset der wirklich clevere Teil ist – es macht BLS-Aggregation praktisch, wenn man später genau prüfen muss, wer unterschrieben hat, und nicht nur, dass eine Schwelle erreicht wurde.
Was ich noch nicht herausgefunden habe: Tragen fehlerhafte Beglaubigungen dieselbe zweistufige aggregierte Struktur wie erfolgreiche Beglaubigungen – oder reicht ein Fehlschlag aus nur einem Schritt, um die Iteration abzuschließen, ohne dass beide Schritte abgeschlossen sein müssen. @Dusk
$DUSK #dusk
Ich bin diese Woche genau durchgegangen, wie ein Dusk-Block tatsächlich zertifiziert wird, weil ich verstehen wollte, was eine „Beglaubigung“ ("attestation") inhaltlich enthält – nicht nur, dass das Quorum erreicht wurde, sondern wie der Beweis strukturell aussieht.
Das Konsensdesign hat eine zweistufige Bestätigung, nachdem ein Blockkandidat vorgeschlagen wurde: Validierung, bei der die Komiteemitglieder Valid oder Invalid abstimmen, und Ratifizierung, bei der ein zweites Komitee das Validierungsergebnis bestätigt. Wenn beide Schritte das Quorum erreichen, wird eine erfolgreiche Beglaubigung erzeugt.
Was in einer Beglaubigung steckt: der Abstimmungstyp, der das Quorum erreicht (Valid, Invalid, NoCandidate oder NoQuorum), plus aggregierte BLS-Signaturen aus beiden Schritten (Validierung und Ratifizierung). Und außerdem ein Bitset. Das Bitset war der Teil, der in Zusammenfassungen nirgends erklärt worden war.
Das Bitset gibt an, welche Komiteemitglieder’ Signaturen in der Aggregation enthalten sind. Wenn das Komitee [P0, P1, P2, P3] ist und das Bitset [0, 1, 0, 1] lautet, bedeutet das: P1 und P3 haben signiert.
Dieser Teil ist solide. Eine kompakte Beglaubigung trägt alles, was zur Verifikation des Quorums nötig ist – die Abstimmung, den aggregierten Beweis und den Mitgliedschaftseintrag – ohne dass die Größe linear mit der Komiteegröße skaliert.
Schwieriger nachzuvollziehen ist, was passiert, wenn Beglaubigungen sich ansammeln. Ein Block, der „bestätigt“ ist, benötigt ausreichende Folgeb-Blocks mit eigenen Beglaubigungen. Wenn Beglaubigungen in der Praxis groß sind oder wenn Knoten vollständige Beglaubigungs-Historien für den Sync speichern müssen, entstehen Speicher- und Bandbreitenkosten, die in der reinen Quorum-Beschreibung allein nicht sichtbar werden.
Ich denke tatsächlich, dass das Bitset der wirklich clevere Teil ist – es macht BLS-Aggregation praktisch, wenn man später genau prüfen muss, wer unterschrieben hat, und nicht nur, dass eine Schwelle erreicht wurde.
Was ich noch nicht herausgefunden habe: Tragen fehlerhafte Beglaubigungen dieselbe zweistufige aggregierte Struktur wie erfolgreiche Beglaubigungen – oder reicht ein Fehlschlag aus nur einem Schritt, um die Iteration abzuschließen, ohne dass beide Schritte abgeschlossen sein müssen. @Dusk
$DUSK #dusk