Ich habe einen Abend damit verbracht, Dusk-Dokumentation mit dem abzugleichen, wie sein Konsens in der Praxis tatsächlich funktioniert, und das Detail, das bei mir hängen geblieben ist, ist nicht die Privacy-Schicht — sondern dass Dusk @Dusk $DUSK #dusk die Blockerzeugung vom Blockratifizieren in zwei separate Komitees aufteilt, statt dass ein einzelner Validator-Set beide Aufgaben übernimmt. Die meisten Ketten behandeln den Konsens als eine einzige Rolle, die zwei Hüte trägt. Hier optimiert der Generator auf Durchsatz, der Ratifizierer auf Finality-Sicherheit, und diese zwei Ziele sind nicht automatisch aufeinander abgestimmt. Was ich weder in den Dokus noch anhand der Testnet-Aktivitäten zu finden konnte, ist, was passiert, wenn die beiden Komitees sich wirklich uneinig sind — nicht einfach ein Validator, der offline geht, sondern eine tatsächliche Spaltung in der Beurteilung zwischen Erzeugung und Ratifizierung. Die Architektur hat eindeutig einen Auflösungsweg eingebaut, da die Kette unter normalen Bedingungen nicht angehalten hat, aber „hat noch nicht angehalten“ und „löst sich bei adversärem Dissens sauber auf“ sind unterschiedliche Behauptungen. Kaum eine aktuelle Nutzung strapaziert diesen Pfad, weil die meisten Aktivitäten nach wie vor leicht und kooperativ sind. Es ist eine Designentscheidung, die derzeit unsichtbar ist und erst verständlich wird, wenn jemand sie unter Druck testet. Bin gespannt, wie das in der Praxis aussieht.