#dusk $DUSK @Dusk
Ich ging früher davon aus, dass es, sobald der Code einer Blockchain Open Source ist, nicht wirklich darauf ankommt, wie viele Teams ihn implementieren. Das Protokoll ist das Protokoll. Wenn die Regeln öffentlich sind, könnte jeder eine zweite Version schreiben, und die Tatsache, dass sich bisher noch niemand dazu berufen gefühlt hat, ist nur eine Detailfrage.
Dann habe ich mir die Node-Software von Dusk angesehen und etwas gefunden, das meine Sicht auf das gesamte Projekt verändert hat.
Es gibt genau einen Client. Rusk, geschrieben in Rust. Die frühere Go-Implementierung liegt zwar noch auf GitHub, ist öffentlich als veraltet markiert und wird nicht mehr gewartet — mit einem Hinweis, der alle stattdessen auf Rusk verweist.
Damit läuft in jedem Node im Netzwerk derselbe Code.
Das lohnt es sich, kurz innezuhalten, denn es gibt für den alternativen Ansatz einen Grund. Ethereum fördert viele unabhängige Clients, sodass ein Bug in einem davon die Kette nicht stoppt — die anderen produzieren weiter Blöcke, während er behoben wird. Das ist bewusst teuer, langsam und redundant. Die Redundanz ist die Sicherheitsfunktion.
Mit einem einzigen Client ist ein Konsens-Bug nicht „nur teilweise“. Er betrifft das Netzwerk.
Ich glaube nicht, dass das ein Versehen ist. Für ein kleines Team ist ein einziger exzellenter Client eine weitaus bessere Nutzung von Ressourcen als zwei mittelmäßige — und Rusk wurde wiederholt auditiert: die Node-Bibliothek, die Konsensschicht, das Netzwerkprotokoll — alles von externen Firmen geprüft. Die Konzentration der Anstrengungen ist eine gut begründbare Ingenieursentscheidung.
Aber das bedeutet auch, dass eine Chain, die für regulierte Abwicklung gebaut wurde, derzeit keine Client-Diversität hat. Genau die Dinge, denen traditionelle Marktinfrastruktur-Träger zwanghaft nachgehen — Redundanz, unabhängige Fehlerpfade, kein Single Point of Failure — sind gerade das, was noch nicht vorhanden ist.
Was ich von außen nicht sagen kann, ist, ob überhaupt eine zweite Implementierung geplant ist oder ob man sie in diesem Stadium des Netzwerklebens als unnötig erachtet. Beide Antworten wären plausibel. Ich würde nur gern wissen, welche zutrifft.
Von dort an habe ich „Open Source“ nicht mehr so gelesen, als würde es automatisch für Widerstandsfähigkeit stehen. Offener Code ist eine Einladung. Client-Diversität entsteht dann, wenn jemand sie aktiv akzeptiert.
Ich ging früher davon aus, dass es, sobald der Code einer Blockchain Open Source ist, nicht wirklich darauf ankommt, wie viele Teams ihn implementieren. Das Protokoll ist das Protokoll. Wenn die Regeln öffentlich sind, könnte jeder eine zweite Version schreiben, und die Tatsache, dass sich bisher noch niemand dazu berufen gefühlt hat, ist nur eine Detailfrage.
Dann habe ich mir die Node-Software von Dusk angesehen und etwas gefunden, das meine Sicht auf das gesamte Projekt verändert hat.
Es gibt genau einen Client. Rusk, geschrieben in Rust. Die frühere Go-Implementierung liegt zwar noch auf GitHub, ist öffentlich als veraltet markiert und wird nicht mehr gewartet — mit einem Hinweis, der alle stattdessen auf Rusk verweist.
Damit läuft in jedem Node im Netzwerk derselbe Code.
Das lohnt es sich, kurz innezuhalten, denn es gibt für den alternativen Ansatz einen Grund. Ethereum fördert viele unabhängige Clients, sodass ein Bug in einem davon die Kette nicht stoppt — die anderen produzieren weiter Blöcke, während er behoben wird. Das ist bewusst teuer, langsam und redundant. Die Redundanz ist die Sicherheitsfunktion.
Mit einem einzigen Client ist ein Konsens-Bug nicht „nur teilweise“. Er betrifft das Netzwerk.
Ich glaube nicht, dass das ein Versehen ist. Für ein kleines Team ist ein einziger exzellenter Client eine weitaus bessere Nutzung von Ressourcen als zwei mittelmäßige — und Rusk wurde wiederholt auditiert: die Node-Bibliothek, die Konsensschicht, das Netzwerkprotokoll — alles von externen Firmen geprüft. Die Konzentration der Anstrengungen ist eine gut begründbare Ingenieursentscheidung.
Aber das bedeutet auch, dass eine Chain, die für regulierte Abwicklung gebaut wurde, derzeit keine Client-Diversität hat. Genau die Dinge, denen traditionelle Marktinfrastruktur-Träger zwanghaft nachgehen — Redundanz, unabhängige Fehlerpfade, kein Single Point of Failure — sind gerade das, was noch nicht vorhanden ist.
Was ich von außen nicht sagen kann, ist, ob überhaupt eine zweite Implementierung geplant ist oder ob man sie in diesem Stadium des Netzwerklebens als unnötig erachtet. Beide Antworten wären plausibel. Ich würde nur gern wissen, welche zutrifft.
Von dort an habe ich „Open Source“ nicht mehr so gelesen, als würde es automatisch für Widerstandsfähigkeit stehen. Offener Code ist eine Einladung. Client-Diversität entsteht dann, wenn jemand sie aktiv akzeptiert.