#dusk $DUSK @Dusk Ich habe eine Sache lange nicht ganz durchschaut: Dusk verfügt über eine eigene native Laufzeitumgebung für Smart Contracts – sie ist darauf ausgelegt, Contracts zu betreiben, die in Rust geschrieben sind. Gleichzeitig hat man eine Ausführungsschicht entwickelt, die mit Ethereum kompatibel ist, sodass man seine Contracts mit der gewohnten Sprache schreiben kann. Zwei Umgebungen parallel zu pflegen wirkt wie eine zusätzliche Wartungsbelastung – und genau deshalb wollte ich diesmal herausfinden, worauf diese Entscheidung eigentlich abzielt.
Nachdem ich recheriert habe, habe ich verstanden: Das sind im Grunde zwei völlig unterschiedliche Gruppen von Entwicklern, die beide gleichzeitig berücksichtigt werden. Die native Umgebung richtet sich an Teams, die bereit sind, direkt Rust zu lernen, und die die Fähigkeiten ganz auf der untersten Ebene des Protokolls nutzen wollen (z. B. direkt mit dieser Art verschlüsselter, verbergender Konten zu arbeiten). Dort sind Leistung und Flexibilität höher, aber die Einstiegshürde ist auch größer – denn es gibt ohnehin viel weniger Entwickler, die Rust-Smart-Contracts schreiben, als solche, die Contracts mit der Ethereum-Sprache schreiben. Die Ethereum-kompatible Schicht zielt dagegen auf den „Bestand“ ab: Draußen existiert bereits eine große Zahl an Entwicklern und eine Fülle an etablierten Tools, die rund um das Ethereum-Ökosystem aufgebaut wurden. Wenn Dusk keinen kompatiblen Einstieg anbietet, wäre diese große Gruppe ziemlich sicher nicht bereit, für eine neue Kette das gesamte Tooling noch einmal separat zu erlernen – sie würde lieber dort entwickeln, wo die Kompatibilität ohnehin gegeben ist.
Am Anfang dachte ich, das sei ein „Beides ist gewollt“ – also dass man versucht, beide Seiten zufrieden zu stellen, und am Ende beide Bereiche nur halb macht. Später habe ich jedoch die offizielle Einordnung zu diesen zwei Ebenen gelesen, und da wurde mir klar: Man hatte gar nicht vor, dass beide Ebenen in ihrer Funktion vollständig gleichwertig sind. Die native Schicht ist für protokollnahe Anwendungsfälle gedacht, bei denen eine enge Bindung an Datenschutz- und Abrechnungsfähigkeiten erforderlich ist. Die Ethereum-kompatible Schicht dient dagegen vor allem dazu, schnell an das externe Ökosystem und vorhandene Anwendungen anzudocken. In dieser Aufteilung ist das am Ende wohl keine doppelte Erfindung des Rads, sondern eher so, als würde man verschiedenen Bedürfnissen jeweils eine passende Tür öffnen – nicht dieselbe Sache zweimal bauen.
Allerdings habe ich auch keine konkreten Daten zur Verteilung der Entwicklergruppen gefunden. Zum Beispiel: Wie groß ist das Verhältnis der Anwendungen, die in der Praxis entweder den nativen Weg oder den Ethereum-kompatiblen Weg wählen? Hier fehlen mir aktuell verifizierbare Zahlen. Man kann nur sagen, dass die Architektur-idee plausibel ist; ob sich nach dem Rollout tatsächlich eher der eine oder der andere Pfad durchsetzt, wird man erst anhand der später tatsächlich bereitgestellten Anwendungsanzahl sehen müssen.
Nachdem ich recheriert habe, habe ich verstanden: Das sind im Grunde zwei völlig unterschiedliche Gruppen von Entwicklern, die beide gleichzeitig berücksichtigt werden. Die native Umgebung richtet sich an Teams, die bereit sind, direkt Rust zu lernen, und die die Fähigkeiten ganz auf der untersten Ebene des Protokolls nutzen wollen (z. B. direkt mit dieser Art verschlüsselter, verbergender Konten zu arbeiten). Dort sind Leistung und Flexibilität höher, aber die Einstiegshürde ist auch größer – denn es gibt ohnehin viel weniger Entwickler, die Rust-Smart-Contracts schreiben, als solche, die Contracts mit der Ethereum-Sprache schreiben. Die Ethereum-kompatible Schicht zielt dagegen auf den „Bestand“ ab: Draußen existiert bereits eine große Zahl an Entwicklern und eine Fülle an etablierten Tools, die rund um das Ethereum-Ökosystem aufgebaut wurden. Wenn Dusk keinen kompatiblen Einstieg anbietet, wäre diese große Gruppe ziemlich sicher nicht bereit, für eine neue Kette das gesamte Tooling noch einmal separat zu erlernen – sie würde lieber dort entwickeln, wo die Kompatibilität ohnehin gegeben ist.
Am Anfang dachte ich, das sei ein „Beides ist gewollt“ – also dass man versucht, beide Seiten zufrieden zu stellen, und am Ende beide Bereiche nur halb macht. Später habe ich jedoch die offizielle Einordnung zu diesen zwei Ebenen gelesen, und da wurde mir klar: Man hatte gar nicht vor, dass beide Ebenen in ihrer Funktion vollständig gleichwertig sind. Die native Schicht ist für protokollnahe Anwendungsfälle gedacht, bei denen eine enge Bindung an Datenschutz- und Abrechnungsfähigkeiten erforderlich ist. Die Ethereum-kompatible Schicht dient dagegen vor allem dazu, schnell an das externe Ökosystem und vorhandene Anwendungen anzudocken. In dieser Aufteilung ist das am Ende wohl keine doppelte Erfindung des Rads, sondern eher so, als würde man verschiedenen Bedürfnissen jeweils eine passende Tür öffnen – nicht dieselbe Sache zweimal bauen.
Allerdings habe ich auch keine konkreten Daten zur Verteilung der Entwicklergruppen gefunden. Zum Beispiel: Wie groß ist das Verhältnis der Anwendungen, die in der Praxis entweder den nativen Weg oder den Ethereum-kompatiblen Weg wählen? Hier fehlen mir aktuell verifizierbare Zahlen. Man kann nur sagen, dass die Architektur-idee plausibel ist; ob sich nach dem Rollout tatsächlich eher der eine oder der andere Pfad durchsetzt, wird man erst anhand der später tatsächlich bereitgestellten Anwendungsanzahl sehen müssen.