Als ich PoS-Konzepten früher begegnet bin, war ich daran gewöhnt, es wie eine Art „Validator“-Rolle hin und her zu drehen. Vor ein paar Tagen habe ich dann das SBA-Consensus-Whitepaper von @dusk_network gelesen und merkwürdigerweise hat mich genau diese Art, ein Wort auseinanderzunehmen, gepackt. $GRVT
Ich dachte anfangs, dass ein PoS im Ausschussformat einfach nur eine Gruppe von Knoten zusammenstellt, damit sie abstimmt. Als ich dann Generator und Provisioner diese beiden Abschnitte gegeneinander habe durcharbeiten müssen, wurde mir klar: Dusk zerlegt die Rollen im Konsens bewusst in zwei Kategorien, mit einer erzwungenen Trennung der Verantwortlichkeiten. Das ist anders als bei den meisten PoS-Ansätzen: Nicht dieselbe Gruppe macht sowohl den Vorschlag als auch die endgültige Bestätigung, sondern der Generator ist für das Erzeugen der Blöcke zuständig, und mittels einer blinden Auktion wird der Blockerzeuger per Ziehung ausgewählt; der Provisioner ist ein öffentlich gelistetes Prüfgremium auf der Basis von Einsätzen und kümmert sich nur um die Block-Reduktion und die letzte Runde dieser binären Übereinstimmung. Im Whitepaper steht Block Generation → Block Reduction → Block Agreement in drei Phasen: schwache Synchronisation gemischt mit Asynchronität. Das soll statistische Determiniertheit und schnelle Abrechnungs-Endgültigkeit ermöglichen – das ist etwas völlig anderes als die probabilistische Bestätigung, wie bei Ethereum. Heißt: Die Person, die Blöcke erstellt, und die Person, die letztlich abnickt, sind nicht dieselbe. Der Spielraum für Fehlverhalten durch Einzelne wird so stark eingegrenzt. $AEON
Später hatte ich den Eindruck, dass Dusk nicht primär „den Konsens nur schneller machen“ will, sondern dass nach der Trennung von Blockierrecht und Bestätigungsrecht das Ausmaß an Schaden, das eine einzelne Rolle verursachen könnte, klar begrenzt wird.
Aber das heißt nicht, dass alles sorgenfrei ist. Unter der Annahme schwacher Synchronisation: Wenn das Netzwerk länger aus dem Tritt gerät, können sich Block-Reduktion und -Bestätigung dann wirklich stabil nahtlos anschließen? In den öffentlich verfügbaren Informationen wird das Verhalten bei extremen Forks nicht im Detail erklärt – das muss man noch beobachten.
Ob dieser Weg aufgeht, muss man anhand der Zeit verifizieren. Aber zumindest macht Dusk die Trennung der Verantwortlichkeiten zum „erstklassigen Bürger“ des Konsens. Was ist dir wichtiger: die Effizienz beim Blockieren oder dass eine einzelne Rolle so weit wie möglich durch Constraints gebunden wird? Schreib’s in den Kommentaren.
@Dusk_Foundation #dusk $DUSK ；
Ich dachte anfangs, dass ein PoS im Ausschussformat einfach nur eine Gruppe von Knoten zusammenstellt, damit sie abstimmt. Als ich dann Generator und Provisioner diese beiden Abschnitte gegeneinander habe durcharbeiten müssen, wurde mir klar: Dusk zerlegt die Rollen im Konsens bewusst in zwei Kategorien, mit einer erzwungenen Trennung der Verantwortlichkeiten. Das ist anders als bei den meisten PoS-Ansätzen: Nicht dieselbe Gruppe macht sowohl den Vorschlag als auch die endgültige Bestätigung, sondern der Generator ist für das Erzeugen der Blöcke zuständig, und mittels einer blinden Auktion wird der Blockerzeuger per Ziehung ausgewählt; der Provisioner ist ein öffentlich gelistetes Prüfgremium auf der Basis von Einsätzen und kümmert sich nur um die Block-Reduktion und die letzte Runde dieser binären Übereinstimmung. Im Whitepaper steht Block Generation → Block Reduction → Block Agreement in drei Phasen: schwache Synchronisation gemischt mit Asynchronität. Das soll statistische Determiniertheit und schnelle Abrechnungs-Endgültigkeit ermöglichen – das ist etwas völlig anderes als die probabilistische Bestätigung, wie bei Ethereum. Heißt: Die Person, die Blöcke erstellt, und die Person, die letztlich abnickt, sind nicht dieselbe. Der Spielraum für Fehlverhalten durch Einzelne wird so stark eingegrenzt. $AEON
Später hatte ich den Eindruck, dass Dusk nicht primär „den Konsens nur schneller machen“ will, sondern dass nach der Trennung von Blockierrecht und Bestätigungsrecht das Ausmaß an Schaden, das eine einzelne Rolle verursachen könnte, klar begrenzt wird.
Aber das heißt nicht, dass alles sorgenfrei ist. Unter der Annahme schwacher Synchronisation: Wenn das Netzwerk länger aus dem Tritt gerät, können sich Block-Reduktion und -Bestätigung dann wirklich stabil nahtlos anschließen? In den öffentlich verfügbaren Informationen wird das Verhalten bei extremen Forks nicht im Detail erklärt – das muss man noch beobachten.
Ob dieser Weg aufgeht, muss man anhand der Zeit verifizieren. Aber zumindest macht Dusk die Trennung der Verantwortlichkeiten zum „erstklassigen Bürger“ des Konsens. Was ist dir wichtiger: die Effizienz beim Blockieren oder dass eine einzelne Rolle so weit wie möglich durch Constraints gebunden wird? Schreib’s in den Kommentaren.
@Dusk_Foundation #dusk $DUSK ；