Letztesg Nacht habe ich ein @Dusk weißes Buch durchgeblättert, eigentlich wollte ich etwas Makroökonomisches finden, aber ich bin direkt in Kapitel 8 reingestürzt: „Concrete Protocol“, also das konkrete Protokoll. Dieses Kapitel hat keine große Erzählung, sondern ist reine Anatomie.
Wie genau ein Block aussieht
und was genau in ihm steckt
Zuerst: Wie die Blöcke miteinander verkettet sind. Das Whitepaper ist ziemlich direkt: Die Blöcke folgen aufeinander; sie sind durch Hashes „nach unten verriegelt“. Im Header des aktuellen Blocks steht der Blake2b-Hash des vorherigen Blockheaders, und die Höhe steigt streng um 1. Block 0 ist der Genesis-Block; dessen previousBlockHash ist einfach fest auf 0 codiert.
In den Genesis-Block sind vier Genesis-Contracts gepackt, außerdem eine vorab festgelegte Liste von Generatoren und Verifizierern sowie zwei fest eincodierte Seeds – jeweils für Epoch 0 und Epoch 1. Anders gesagt: Das ist die Geburtsurkunde dieser Kette, selbstgeschrieben.
Ein Block besteht aus drei Teilen: Header, Body und Certificate. Der Header hat acht Felder: Version, Höhe, Zeitstempel, Hash des vorherigen Blocks, Seed, Blockreward, Transaktions-Root und State-Root. Diese Feld-Tabelle habe ich ziemlich lange angestarrt, denn sie ist gewissermaßen der „Ausweis“ der gesamten Kette. Ändert man ein einziges Byte, verändert sich der Hash der gesamten Kette.
Und dann das Certificate (Zertifikat). Es enthält die Blockausbeute/-punktzahl, die PLONK-Zero-Knowledge-Proof des Blockerstellers und die BLS-Aggregationssignatur des Komitees.
Die binäre Abbildung von validatorSeq markiert, welche Validatoren-Signaturen in diese Aggregation tatsächlich eingeflossen sind. Wirklich spannend ist, dass das Whitepaper extra einen Satz dazu schreibt: Das Zertifikat wird von jedem Konsens-Teilnehmer lokal selbst konstruiert. Deshalb gibt es in derselben Konsensrunde keine einzige, einheitliche Version eines Zertifikats. Ich musste da kurz zweimal hinschauen.
Andere Ketten wollen das Zertifikat am liebsten zu etwas machen, das im ganzen Netz eindeutig ist, und dann irgendwo ein Siegel draufkleben. Dusk geht aber genau andersherum: Jeder Knoten hat seine eigene selbst zusammengebaute Bescheinigung. Ich vermute, dahinter steckt ein Trade-off: Statt dem ganzen Netz dieselbe „autoritative“ Zertifikatsversion zu geben, ermöglicht man jedem Knoten, sich unabhängig selbst zu verifizieren. Das passt sehr gut zu seiner Datenschutz-„Privacy-first“-Ausrichtung.
Das spezielle Feld von Crossover – es ist die Brücke, die DUSK auf der Ebene zwischen der Transaktionsschicht und der allgemeinen Compute-Schicht verbindet.
Mein Fazit nach dem Lesen: Die ersten Kapitel erzählen größtenteils das „Warum“, dieses Kapitel ist komplett „Wie es aussieht“. Datenschutz, Konsens und Compliance müssen am Ende alle in eine konkrete Bytefolge hineinpassen, erst dann ist es wirklich umgesetzt.#dusk $DUSK @Dusk
Wie genau ein Block aussieht
und was genau in ihm steckt
Zuerst: Wie die Blöcke miteinander verkettet sind. Das Whitepaper ist ziemlich direkt: Die Blöcke folgen aufeinander; sie sind durch Hashes „nach unten verriegelt“. Im Header des aktuellen Blocks steht der Blake2b-Hash des vorherigen Blockheaders, und die Höhe steigt streng um 1. Block 0 ist der Genesis-Block; dessen previousBlockHash ist einfach fest auf 0 codiert.
In den Genesis-Block sind vier Genesis-Contracts gepackt, außerdem eine vorab festgelegte Liste von Generatoren und Verifizierern sowie zwei fest eincodierte Seeds – jeweils für Epoch 0 und Epoch 1. Anders gesagt: Das ist die Geburtsurkunde dieser Kette, selbstgeschrieben.
Ein Block besteht aus drei Teilen: Header, Body und Certificate. Der Header hat acht Felder: Version, Höhe, Zeitstempel, Hash des vorherigen Blocks, Seed, Blockreward, Transaktions-Root und State-Root. Diese Feld-Tabelle habe ich ziemlich lange angestarrt, denn sie ist gewissermaßen der „Ausweis“ der gesamten Kette. Ändert man ein einziges Byte, verändert sich der Hash der gesamten Kette.
Und dann das Certificate (Zertifikat). Es enthält die Blockausbeute/-punktzahl, die PLONK-Zero-Knowledge-Proof des Blockerstellers und die BLS-Aggregationssignatur des Komitees.
Die binäre Abbildung von validatorSeq markiert, welche Validatoren-Signaturen in diese Aggregation tatsächlich eingeflossen sind. Wirklich spannend ist, dass das Whitepaper extra einen Satz dazu schreibt: Das Zertifikat wird von jedem Konsens-Teilnehmer lokal selbst konstruiert. Deshalb gibt es in derselben Konsensrunde keine einzige, einheitliche Version eines Zertifikats. Ich musste da kurz zweimal hinschauen.
Andere Ketten wollen das Zertifikat am liebsten zu etwas machen, das im ganzen Netz eindeutig ist, und dann irgendwo ein Siegel draufkleben. Dusk geht aber genau andersherum: Jeder Knoten hat seine eigene selbst zusammengebaute Bescheinigung. Ich vermute, dahinter steckt ein Trade-off: Statt dem ganzen Netz dieselbe „autoritative“ Zertifikatsversion zu geben, ermöglicht man jedem Knoten, sich unabhängig selbst zu verifizieren. Das passt sehr gut zu seiner Datenschutz-„Privacy-first“-Ausrichtung.
Das spezielle Feld von Crossover – es ist die Brücke, die DUSK auf der Ebene zwischen der Transaktionsschicht und der allgemeinen Compute-Schicht verbindet.
Mein Fazit nach dem Lesen: Die ersten Kapitel erzählen größtenteils das „Warum“, dieses Kapitel ist komplett „Wie es aussieht“. Datenschutz, Konsens und Compliance müssen am Ende alle in eine konkrete Bytefolge hineinpassen, erst dann ist es wirklich umgesetzt.#dusk $DUSK @Dusk