Zunächst nahm ich an, dass DuskEVM einfach Dusk um eine EVM-Umgebung erweitert, damit Entwickler Solidity-Verträge bereitstellen können.
Das ist nur die Ausführungsseite.
Die wichtigere Designentscheidung ist, wo diese Anwendungen sich „einfinden“.
DuskEVM ist als eine EVM-äquivalente Umgebung gebaut, sodass Entwickler vertraute Verträge, Wallets und Ethereum-Tooling nutzen können. Aber anstatt die EVM-Schicht als endgültige Quelle der Wahrheit zu behandeln, fließen deren Daten und Abrechnung über DuskDS.
Ich sehe die Rollen so:
DuskEVM beantwortet, wie die Anwendung ausgeführt wird.
DuskDS entscheidet, wann sein Zustand endgültig wird.
Im Hintergrund liefert DuskDS Konsens, Datenverfügbarkeit und deterministische Endgültigkeit durch „Succinct Attestation“. Ein Block wird vorgeschlagen, validiert und ratifiziert, bevor er zu einem endgültigen Netzwerkzustand wird.
Diese Trennung ist gerade für die Finanzanwendungen @Dusk wichtig, die unterstützt werden sollen.
Ein Entwickler möchte beim Aufbau einer Plattform für tokenisierte Anleihen oder einer regulierten Handelsanwendung möglicherweise Ethereum-Kompatibilität. Aber der Markt hinter dieser Anwendung braucht außerdem eine vorhersehbare Abrechnung. Eigentumsübertragungen, Zahlungskoordination und compliance-gesteuerte Transaktionen dürfen nicht offen bleiben für ungewisse Finalität.
Dusk sorgt dafür, dass Entwickler nicht zwischen vertrautem Tooling und einer Abrechnungsschicht wählen müssen, die auf Anforderungen von Finanzmärkten ausgelegt ist.
Sie können Solidity in DuskEVM nutzen und dabei DuskDS als Grundlage unterhalb der Ausführung verwenden.
Außerdem macht das DuskEVM mehr als nur eine weitere isolierte EVM-Kette.
Die Oberfläche kann vertraut wirken, aber der finale Zustand ist in Duks eigener Konsens- und Abrechnungsarchitektur verankert.
Das ist der Unterschied, den ich beobachte: vertraute Ausführung oben, Dusk-eigene Endgültigkeit darunter.
#dusk $DUSK
Das ist nur die Ausführungsseite.
Die wichtigere Designentscheidung ist, wo diese Anwendungen sich „einfinden“.
DuskEVM ist als eine EVM-äquivalente Umgebung gebaut, sodass Entwickler vertraute Verträge, Wallets und Ethereum-Tooling nutzen können. Aber anstatt die EVM-Schicht als endgültige Quelle der Wahrheit zu behandeln, fließen deren Daten und Abrechnung über DuskDS.
Ich sehe die Rollen so:
DuskEVM beantwortet, wie die Anwendung ausgeführt wird.
DuskDS entscheidet, wann sein Zustand endgültig wird.
Im Hintergrund liefert DuskDS Konsens, Datenverfügbarkeit und deterministische Endgültigkeit durch „Succinct Attestation“. Ein Block wird vorgeschlagen, validiert und ratifiziert, bevor er zu einem endgültigen Netzwerkzustand wird.
Diese Trennung ist gerade für die Finanzanwendungen @Dusk wichtig, die unterstützt werden sollen.
Ein Entwickler möchte beim Aufbau einer Plattform für tokenisierte Anleihen oder einer regulierten Handelsanwendung möglicherweise Ethereum-Kompatibilität. Aber der Markt hinter dieser Anwendung braucht außerdem eine vorhersehbare Abrechnung. Eigentumsübertragungen, Zahlungskoordination und compliance-gesteuerte Transaktionen dürfen nicht offen bleiben für ungewisse Finalität.
Dusk sorgt dafür, dass Entwickler nicht zwischen vertrautem Tooling und einer Abrechnungsschicht wählen müssen, die auf Anforderungen von Finanzmärkten ausgelegt ist.
Sie können Solidity in DuskEVM nutzen und dabei DuskDS als Grundlage unterhalb der Ausführung verwenden.
Außerdem macht das DuskEVM mehr als nur eine weitere isolierte EVM-Kette.
Die Oberfläche kann vertraut wirken, aber der finale Zustand ist in Duks eigener Konsens- und Abrechnungsarchitektur verankert.
Das ist der Unterschied, den ich beobachte: vertraute Ausführung oben, Dusk-eigene Endgültigkeit darunter.
#dusk $DUSK