Inhalte wie dieser müssen geschätzt werden 👍
Veröffentlichen
precious Zarmalaa
·
--
$DUSK @Dusk #dusk
früher habe ich angenommen, dass „EVM-kompatibel“ bedeutet, dass einfach eine Kette EVM ausführt und fertig.
Dusk macht das nicht.
ich habe nachverfolgt, was DuskVM tatsächlich ist: Auf Wasmtime basierend, laufen Rust/WASM-Verträge direkt auf Dusk's L1 — vollständig getrennt von DuskEVM. Das ist keine Kompatibilitätsschicht, die an EVM angeflanscht wurde — es ist eine zweite, unabhängige Ausführungsumgebung, die daneben existiert.
Hmm.
also warum eine komplette separate VM bauen, statt nur EVM-Support mitzuliefern?
ich habe weiter gegraben. DuskVM existiert speziell für Verträge, die direkten Zugriff auf L1-Assets brauchen, Dusk's native Transaktionsmodelle, Privatsphäre oder Zero-Knowledge-Fähigkeiten — Dinge, für die das EVM-Ausführungsmodell nicht von vornherein ausgelegt war, sie nativ freizulegen. Piecrust, die Engine darunter, ist ungefähr zehnmal schneller als ihr Vorgänger und bringt ZK-freundliche Host-Funktionen mit — PLONK, Groth16 und BLS — direkt in die Laufzeit eingebaut.
ich habe geprüft, was DuskEVM stattdessen abdeckt. Vollständige EVM-Äquivalenz, Standard-Tooling, Abwicklung über DuskDS — die Ebene für Entwickler, die vertraute Solidity-Workflows haben wollen, ohne dafür privatsphären-native Primitiven zu benötigen.
also „native VM statt nur EVM“ ist keine echte Absage an EVM. es ist Dusk, das Privatsphäre- und ZK-native Verträge nicht durch ein Ausführungsmodell routen lassen will, das nie dafür gebaut wurde, damit effizient umzugehen.
macht das Ausführen von zwei getrennten Ausführungsumgebungen Dusk leistungsfähiger — oder teilt es einfach die Aufmerksamkeit der Entwickler auf zwei Systeme auf, die sich mit überlappenden Aufgaben beschäftigen?
#dusk $DUSK
früher habe ich angenommen, dass „EVM-kompatibel“ bedeutet, dass einfach eine Kette EVM ausführt und fertig.
Dusk macht das nicht.
ich habe nachverfolgt, was DuskVM tatsächlich ist: Auf Wasmtime basierend, laufen Rust/WASM-Verträge direkt auf Dusk's L1 — vollständig getrennt von DuskEVM. Das ist keine Kompatibilitätsschicht, die an EVM angeflanscht wurde — es ist eine zweite, unabhängige Ausführungsumgebung, die daneben existiert.
Hmm.
also warum eine komplette separate VM bauen, statt nur EVM-Support mitzuliefern?
ich habe weiter gegraben. DuskVM existiert speziell für Verträge, die direkten Zugriff auf L1-Assets brauchen, Dusk's native Transaktionsmodelle, Privatsphäre oder Zero-Knowledge-Fähigkeiten — Dinge, für die das EVM-Ausführungsmodell nicht von vornherein ausgelegt war, sie nativ freizulegen. Piecrust, die Engine darunter, ist ungefähr zehnmal schneller als ihr Vorgänger und bringt ZK-freundliche Host-Funktionen mit — PLONK, Groth16 und BLS — direkt in die Laufzeit eingebaut.
ich habe geprüft, was DuskEVM stattdessen abdeckt. Vollständige EVM-Äquivalenz, Standard-Tooling, Abwicklung über DuskDS — die Ebene für Entwickler, die vertraute Solidity-Workflows haben wollen, ohne dafür privatsphären-native Primitiven zu benötigen.
also „native VM statt nur EVM“ ist keine echte Absage an EVM. es ist Dusk, das Privatsphäre- und ZK-native Verträge nicht durch ein Ausführungsmodell routen lassen will, das nie dafür gebaut wurde, damit effizient umzugehen.
macht das Ausführen von zwei getrennten Ausführungsumgebungen Dusk leistungsfähiger — oder teilt es einfach die Aufmerksamkeit der Entwickler auf zwei Systeme auf, die sich mit überlappenden Aufgaben beschäftigen?
#dusk $DUSK
Haftungsausschluss: Enthält Meinungen von Drittanbietern. Keine Beratung. Binance AI wird ohne Gewähr bereitgestellt. Siehe AGB.