Ich dachte, dass DuskEVM von dem Dusk-Team aus dem Nichts komplett selbst handgestrickt als eine EVM-kompatible Schicht gebaut wurde. Erst als ich tiefer recherchiert habe, habe ich herausgefunden, dass darunter direkt OP Stack genutzt wird – also dieses quelloffene Rollup-Framework, das Optimism selbst entwickelt hat. Diese Erkenntnis hat mein Verständnis von der Positionierung von DuskEVM grundlegend verändert.
OP Stack ist ein modularer Framework-Ansatz im Ethereum-Ökosystem, der bereits vielfach verifiziert und von mehreren Layer-2-Ketten breit eingesetzt wird (u. a. Optimism selbst, Base usw.). Er ist speziell dafür ausgelegt, eine EVM-kompatible Ausführungsschicht schnell aufzubauen. Dusk hat sich dagegen entschieden, das Rad neu zu erfinden, sondern ist stattdessen direkt auf diese bereits in großem Maßstab im Einsatz erprobte Grundlage aufgesprungen und hat darauf die eigene Ausführungsumgebung gebaut. Am Ende wird der Zustandsabschluss wieder auf die darunterliegende DuskDS zurückgeführt.
Ich finde diese Entscheidung ziemlich pragmatisch: Von Grund auf eine komplett neue EVM-kompatible virtuelle Maschine zu bauen ist mit hohen Risiken und erheblichen Zeitkosten verbunden. Insbesondere sollte die Kernenergie des Dusk-Teams eigentlich stärker in Bereiche fließen, die wirklich differenzierend sind – etwa Kryptografie und Compliance. Indem man auf OP Stack setzt, eine bereits im Ethereum-Ökosystem breit geprüfte und ausgereifte Lösung, kann man große Mengen an Engineering-Aufwand für das wiederholte „Rad-Neuerfinden“ sparen. Gleichzeitig kann man von den Vorteilen profitieren, dass die Rollup-Toolchains im Ethereum-Ökosystem kontinuierlich iterieren – auch OP Stack selbst entwickelt sich ständig weiter. Wenn Dusk den Aktualisierungsrhythmus des Upstream-Ökosystems mitverfolgt, kann es theoretisch dauerhaft von diesen technischen Vorteilen profitieren, ohne eine gesamte VM-Technik-Stack-Lösung komplett eigenständig warten zu müssen.
Das bedeutet aber auch, dass die Sicherheits- und Performance-Eigenschaften von DuskEVM in gewissem Maße eng mit der Robustheit dieses Upstream-Frameworks von OP Stack verknüpft sind. Wenn im Upstream ein Sicherheitslückenproblem auftaucht oder es architektonische Anpassungen gibt, muss Dusk in der Regel ebenfalls nachziehen, sich anpassen und reparieren. Es ist also kein vollständig autonom steuerbarer, unabhängiger Technik-Stack. Diese Abhängigkeit ist – vereinfacht gesagt – der „Preis“ dafür, dass man „auf den Schultern von Riesen steht“: Man spart viel Kraft, aber die eigene Kontrolle wird dadurch etwas reduziert. $DUSK
Bei der technischen Auswahl – also der Abwägung „Mature Framework übernehmen oder selbst neu erfinden“ – gibt es kein absolutes Richtig oder Falsch. Aber wenn man erst einmal klar versteht, ob das Underlying einer Kette selbst entwickelt wurde oder auf einer Drittanbieter-Architektur basiert, kann man zumindest viel genauer beurteilen, wessen historische Aufzeichnungen als Referenz für die technischen Risiken herangezogen werden sollten. @Dusk #dusk
OP Stack ist ein modularer Framework-Ansatz im Ethereum-Ökosystem, der bereits vielfach verifiziert und von mehreren Layer-2-Ketten breit eingesetzt wird (u. a. Optimism selbst, Base usw.). Er ist speziell dafür ausgelegt, eine EVM-kompatible Ausführungsschicht schnell aufzubauen. Dusk hat sich dagegen entschieden, das Rad neu zu erfinden, sondern ist stattdessen direkt auf diese bereits in großem Maßstab im Einsatz erprobte Grundlage aufgesprungen und hat darauf die eigene Ausführungsumgebung gebaut. Am Ende wird der Zustandsabschluss wieder auf die darunterliegende DuskDS zurückgeführt.
Ich finde diese Entscheidung ziemlich pragmatisch: Von Grund auf eine komplett neue EVM-kompatible virtuelle Maschine zu bauen ist mit hohen Risiken und erheblichen Zeitkosten verbunden. Insbesondere sollte die Kernenergie des Dusk-Teams eigentlich stärker in Bereiche fließen, die wirklich differenzierend sind – etwa Kryptografie und Compliance. Indem man auf OP Stack setzt, eine bereits im Ethereum-Ökosystem breit geprüfte und ausgereifte Lösung, kann man große Mengen an Engineering-Aufwand für das wiederholte „Rad-Neuerfinden“ sparen. Gleichzeitig kann man von den Vorteilen profitieren, dass die Rollup-Toolchains im Ethereum-Ökosystem kontinuierlich iterieren – auch OP Stack selbst entwickelt sich ständig weiter. Wenn Dusk den Aktualisierungsrhythmus des Upstream-Ökosystems mitverfolgt, kann es theoretisch dauerhaft von diesen technischen Vorteilen profitieren, ohne eine gesamte VM-Technik-Stack-Lösung komplett eigenständig warten zu müssen.
Das bedeutet aber auch, dass die Sicherheits- und Performance-Eigenschaften von DuskEVM in gewissem Maße eng mit der Robustheit dieses Upstream-Frameworks von OP Stack verknüpft sind. Wenn im Upstream ein Sicherheitslückenproblem auftaucht oder es architektonische Anpassungen gibt, muss Dusk in der Regel ebenfalls nachziehen, sich anpassen und reparieren. Es ist also kein vollständig autonom steuerbarer, unabhängiger Technik-Stack. Diese Abhängigkeit ist – vereinfacht gesagt – der „Preis“ dafür, dass man „auf den Schultern von Riesen steht“: Man spart viel Kraft, aber die eigene Kontrolle wird dadurch etwas reduziert. $DUSK
Bei der technischen Auswahl – also der Abwägung „Mature Framework übernehmen oder selbst neu erfinden“ – gibt es kein absolutes Richtig oder Falsch. Aber wenn man erst einmal klar versteht, ob das Underlying einer Kette selbst entwickelt wurde oder auf einer Drittanbieter-Architektur basiert, kann man zumindest viel genauer beurteilen, wessen historische Aufzeichnungen als Referenz für die technischen Risiken herangezogen werden sollten. @Dusk #dusk
