Ich nutze jeden Tag WLAN, ohne an den Router zu denken. Ich denke erst daran, wenn etwas nicht mehr lädt. Dann schaue ich plötzlich nach Lichtern, Einstellungen, Kabeln … all den Dingen, die vor fünf Minuten noch unsichtbar waren.

So beginne ich, über DuskEVM nachzudenken. Ein Entwickler kann sich in vertrautem Terrain aufhalten: Solidity, Wallets und normales EVM-Tooling, während <a>@Dusk </a> unter der Ausführungsebene DuskDS betreibt und für Settlement sowie Datenverfügbarkeit sorgt. Wenn alles funktioniert, ist genau diese Abstraktion das, was man will. Niemand möchte sich zusätzliche Infrastruktur im Kopf behalten.

Aber Abstraktion schafft auch Abhängigkeit. Die Aktivität von DuskEVM wird gebündelt und unter der Ausführungsebene verankert. <a>$DUSK </a> wechselt außerdem zwischen L1 und DuskEVM über eine Bridge. Wenn sich das Settlement also unerwartet verhält, wird das Bridging kompliziert, oder der Zustand sieht nicht so aus, wie ein Entwickler es erwartet – dann spielt die Basisebene plötzlich eine Rolle.

Das ist der Teil, den ich glaube, dass @dusk irgendwann beweisen muss. Können Entwickler diese Grenzen debuggen, ohne zu DuskDS-Spezialisten zu werden? Wenn es zu oft nötig wird, die versteckte Ebene zu verstehen, verschwindet ein Teil der Einfachheit, die die EVM-Kompatibilität bietet.

Vielleicht geht gute Architektur nicht darum, die Basisebene bedeutungslos zu machen.

Sondern darum, Entwicklern zu ermöglichen, sie an den meisten Tagen zu ignorieren – und sie am Tag, an dem es nicht geht, schnell zu verstehen.$DUSK

#dusk