@Dusk Ich wühlte mich durch die technischen Updates von Dusk, um zu verstehen, wie Succinct Attestation tatsächlich einen Block finalisiert—nicht nur die Marketingzeile über „schnelle probabilistische Finalität“. Der Teil, der mich stoppte: Jedes Komiteemitglied bekommt eine oder mehrere Stimmen, sogenannte Credits. Und die gesamte Stimmenmenge in einer Runde ist fest; die Stimmen des Komitees heißen Credits. Außerdem heißt die Anzahl der Stimmen im Komitee „Committee Credits“. Klingt erstmal einfach nach gewichteter Abstimmung nach Anteil. Nicht überraschend.

Was ich nicht bedacht hatte, ist, was mit all diesen einzelnen Stimmen danach passiert. Sie liegen nicht einfach als einzelne Signaturen herum. Der Blockgenerator sammelt sie ein und erstellt daraus ein Zertifikat—eine gültige Bestätigung für einen Block, die im folgenden Kindblock enthalten ist. Also ist „der Beweis, dass ein Block legitim ist“, nicht das Wort eines einzelnen Validators, sondern jede vergebene Stimme wird in ein einziges, per BLS aggregiertes Objekt gepackt. Und genau auf dieses Objekt verweist der zukünftige Konsens.

Dort verschwindet das Uniktheitsproblem still und leise. Die Aggregation zwingt jeden Credit dazu, auf genau einen Kandidaten pro Runde zu zeigen. Du kannst nicht dafür sorgen, dass deine Stimme doppelt gezählt wird oder für zwei konkurrierende Blöcke zählt, weil das Zertifikat nur Platz für einen kanonischen Satz hat. Kein UX-Feature. Das ist die Sache, die Finalität überhaupt erst Bedeutung verleiht im $DUSK #dusk Konsens. Ich bin mir immer noch nicht sicher, wie es sich bei starken Iterations-Timeouts verhält.