@Dusk Während ich merkte, dass das modulare Bit nicht nur darum geht, mehr Komponenten zu haben. $DUSK Es trennt tatsächlich den Ort, an dem Abrechnung stattfindet, von dem Ort, an dem Ausführung stattfindet, und das verändert, wie ich über die Chain denke.

Während ich die neuesten Dusk-Dokumente prüfte, hielt ich immer wieder inne und verglich DuskDS mit DuskEVM. DuskDS übernimmt Konsens, Finalität und Datenverfügbarkeit, während DuskEVM die EVM-Ausführungsschicht ist, die über sie abrechnet.

DuskVM ist eine weitere Ausführungsumgebung direkt auf dem L1. Das Interessante daran ist, dass sie alle auf dieselbe Abrechnungsgrundlage setzen können, statt jede Anwendung in ein einziges Ausführungsmodell zu zwingen.

Zuerst las ich das als standardmäßige Sprache für modulare Architektur und hätte es beinahe übergangen. Dann schaute ich genauer darauf, wie Dusk mit echten Transaktionen umgeht: Moonlight und Phoenix zahlen beide über DuskDS ab, während die Ausführung von Smart Contracts auch anderswo sitzen kann. Dadurch fühlte sich die Trennung viel praktischer an, als das Diagramm vermuten lässt.

Trotzdem bin ich neugierig auf den Trade-off. Wenn Anwendungen zwischen diesen Ausführungsumgebungen zu wechseln beginnen, reduziert die Modularität dann tatsächlich die Komplexität für Builder – oder verlagert sie nur diese Komplexität in die Schnittstellen zwischen ihnen…

@Dusk $DUSK #dusk