Viele Menschen verstehen „Dusk-Node laufen“ so: staken, am Konsens teilnehmen und so weiter, ein Charakter deckt alles ab. Als ich die offiziellen Betriebsdokumente wirklich durchgelesen habe, wurde mir klar, dass dieses vage Bild das tatsächliche Node-System von Dusk nicht mehr fassen kann.
Die grundlegende Infrastruktur von Dusk ist in drei Arten von Rollen aufgeteilt. Der Configurator Node muss DUSK verpfänden, um an Konsensabstimmungen teilzunehmen; das ist die Kategorie, die wir im Alltag meist „Validierungs-Node“ nennen. Der Archive Node nimmt nicht am Blockproduzieren teil, sondern speichert die vollständige Historie der On-Chain-Daten, um Abfragen und forensische Prüfungen zu unterstützen. Der Prover Node ist auf die Erzeugung von Beweisen spezialisiert – also einen rechenintensiven, konzentrierten Task. Damit werden die Rechenanforderungen für Zero-Knowledge-Proofs vom normalen Validierungs-Node getrennt und in einem eigenen Laufumfeld abgearbeitet. Das ist anders als das Design vieler PoS-Ketten, bei dem „ein Node alles übernimmt“: Hier werden unterschiedliche Wartungs- und Betriebsaufwände auf verschiedene Rollen verteilt.
Anfangs fand ich diese Aufteilung ziemlich klug – die Beweisgenerierung verbraucht sehr viel Rechenleistung. Wenn jeder Node, der am Konsens teilnimmt, diese Last ebenfalls selbst tragen müsste, würde die Hardwarehürde noch höher steigen, und Menschen, die überhaupt am Konsens teilnehmen wollen, würden eher weniger. Wenn man den Prover Node als eigenständige Rolle ausgliedert, entkoppelt man „am Konsens teilnehmen“ von „schwere Rechenleistung tragen“ – zumindest theoretisch.
Doch das Zerlegen der Rollen bedeutet auch, dass der Grad der Dezentralisierung nicht nur anhand eines einzigen Aspekts beurteilt werden kann. Man kann nicht einfach nur die „Anzahl der Nodes“ betrachten und daraus Schlussfolgerungen ziehen. Wenn der Prover-Node wegen der hohen Rechenhürde in den Händen einiger weniger spezialisierter Anbieter konzentriert ist, dann könnte die tatsächliche Dezentralisierung beim Schritt „Beweisgenerierung“ deutlich geringer sein als man es anhand der oberflächlichen Zahlen vermuten würde – das ist leicht zu übersehen.
Mein größter Eindruck nach dem Durcharbeiten der Dokumente ist: Die offiziellen Betriebsrichtlinien – Netzwerkwahl, Node-Konfiguration, Wallet-Einstellungen, Versions-Upgrades, Synchronisationswiederherstellung, Fehlerdiagnose – sind zwar recht vollständig. Aber diese Dokumente richten sich an Menschen, die bereits beschlossen haben, Nodes zu betreiben. Für die vorgelagerte Entscheidung „Soll ich überhaupt einen Node laufen lassen, und welchen Rollen soll ich übernehmen?“ liefern sie nicht genügend Informationen. Man muss selbst externe Daten wie die Verteilung der Nodes oder die jeweiligen Rechenhürden nachschlagen, um ein vollständiges Urteil zusammenzubauen.
Wie dezentral jede der drei Rollen jeweils wirklich ist, möchte ich deshalb möglichst bald anhand der Daten gesondert prüfen. Ich möchte nicht nur aufgrund eines pauschalen „Node-Zahlen“-Blicks allein die Sicherheit dieser Kette bewerten.
@Dusk_Foundation #dusk $DUSK
Die grundlegende Infrastruktur von Dusk ist in drei Arten von Rollen aufgeteilt. Der Configurator Node muss DUSK verpfänden, um an Konsensabstimmungen teilzunehmen; das ist die Kategorie, die wir im Alltag meist „Validierungs-Node“ nennen. Der Archive Node nimmt nicht am Blockproduzieren teil, sondern speichert die vollständige Historie der On-Chain-Daten, um Abfragen und forensische Prüfungen zu unterstützen. Der Prover Node ist auf die Erzeugung von Beweisen spezialisiert – also einen rechenintensiven, konzentrierten Task. Damit werden die Rechenanforderungen für Zero-Knowledge-Proofs vom normalen Validierungs-Node getrennt und in einem eigenen Laufumfeld abgearbeitet. Das ist anders als das Design vieler PoS-Ketten, bei dem „ein Node alles übernimmt“: Hier werden unterschiedliche Wartungs- und Betriebsaufwände auf verschiedene Rollen verteilt.
Anfangs fand ich diese Aufteilung ziemlich klug – die Beweisgenerierung verbraucht sehr viel Rechenleistung. Wenn jeder Node, der am Konsens teilnimmt, diese Last ebenfalls selbst tragen müsste, würde die Hardwarehürde noch höher steigen, und Menschen, die überhaupt am Konsens teilnehmen wollen, würden eher weniger. Wenn man den Prover Node als eigenständige Rolle ausgliedert, entkoppelt man „am Konsens teilnehmen“ von „schwere Rechenleistung tragen“ – zumindest theoretisch.
Doch das Zerlegen der Rollen bedeutet auch, dass der Grad der Dezentralisierung nicht nur anhand eines einzigen Aspekts beurteilt werden kann. Man kann nicht einfach nur die „Anzahl der Nodes“ betrachten und daraus Schlussfolgerungen ziehen. Wenn der Prover-Node wegen der hohen Rechenhürde in den Händen einiger weniger spezialisierter Anbieter konzentriert ist, dann könnte die tatsächliche Dezentralisierung beim Schritt „Beweisgenerierung“ deutlich geringer sein als man es anhand der oberflächlichen Zahlen vermuten würde – das ist leicht zu übersehen.
Mein größter Eindruck nach dem Durcharbeiten der Dokumente ist: Die offiziellen Betriebsrichtlinien – Netzwerkwahl, Node-Konfiguration, Wallet-Einstellungen, Versions-Upgrades, Synchronisationswiederherstellung, Fehlerdiagnose – sind zwar recht vollständig. Aber diese Dokumente richten sich an Menschen, die bereits beschlossen haben, Nodes zu betreiben. Für die vorgelagerte Entscheidung „Soll ich überhaupt einen Node laufen lassen, und welchen Rollen soll ich übernehmen?“ liefern sie nicht genügend Informationen. Man muss selbst externe Daten wie die Verteilung der Nodes oder die jeweiligen Rechenhürden nachschlagen, um ein vollständiges Urteil zusammenzubauen.
Wie dezentral jede der drei Rollen jeweils wirklich ist, möchte ich deshalb möglichst bald anhand der Daten gesondert prüfen. Ich möchte nicht nur aufgrund eines pauschalen „Node-Zahlen“-Blicks allein die Sicherheit dieser Kette bewerten.
@Dusk_Foundation #dusk $DUSK