Le contenu comme celui-ci doit être apprécié 👍
Publier
precious Zarmalaa
·
--
$DUSK @Dusk #dusk
auparavant, je pensais que « compatible avec l’EVM » voulait simplement dire qu’une chaîne exécute l’EVM et que c’est réglé.
Dusk ne fait pas ça.
j’ai retracé ce qu’est vraiment DuskVM : basé sur Wasmtime, exécutant directement des contrats Rust/WASM sur la L1 de Dusk, entièrement séparé de DuskEVM. ce n’est pas une couche de compatibilité greffée à l’EVM — c’est un second environnement d’exécution indépendant, placé à côté.
Hmm.
alors, pourquoi construire une VM séparée complète plutôt que de se contenter d’ajouter uniquement le support EVM ?
j’ai continué à creuser. DuskVM existe spécifiquement pour les contrats qui ont besoin d’un accès direct aux actifs de la L1, aux modèles de transactions natifs de Dusk, à la confidentialité, ou à des capacités de preuve à divulgation nulle — des choses que le modèle d’exécution de l’EVM n’était pas conçu pour exposer nativement. Piecrust, le moteur en dessous, tourne à peu près dix fois plus vite que son prédécesseur, et est livré avec des fonctions hôtes compatibles avec la ZK — PLONK, Groth16 et BLS — intégrées directement dans l’exécution.
j’ai vérifié ce que couvre plutôt DuskEVM. Équivalence EVM complète, outils standards, règlement via DuskDS — la couche pour les développeurs qui veulent conserver des flux de travail Solidity familiers, sans avoir besoin de primitives natives pour la confidentialité.
donc « une VM native plutôt que l’EVM uniquement » n’est pas vraiment un rejet de l’EVM. c’est Dusk qui refuse d’acheminer des contrats natifs en confidentialité et ZK via un modèle d’exécution qui n’a jamais été conçu pour les gérer efficacement.
le fait d’exécuter deux environnements d’exécution séparés rend-il Dusk plus performant, ou est-ce que ça fait juste qu’on divise l’attention des développeurs entre deux systèmes qui accomplissent des tâches qui se chevauchent ?
#dusk $DUSK
auparavant, je pensais que « compatible avec l’EVM » voulait simplement dire qu’une chaîne exécute l’EVM et que c’est réglé.
Dusk ne fait pas ça.
j’ai retracé ce qu’est vraiment DuskVM : basé sur Wasmtime, exécutant directement des contrats Rust/WASM sur la L1 de Dusk, entièrement séparé de DuskEVM. ce n’est pas une couche de compatibilité greffée à l’EVM — c’est un second environnement d’exécution indépendant, placé à côté.
Hmm.
alors, pourquoi construire une VM séparée complète plutôt que de se contenter d’ajouter uniquement le support EVM ?
j’ai continué à creuser. DuskVM existe spécifiquement pour les contrats qui ont besoin d’un accès direct aux actifs de la L1, aux modèles de transactions natifs de Dusk, à la confidentialité, ou à des capacités de preuve à divulgation nulle — des choses que le modèle d’exécution de l’EVM n’était pas conçu pour exposer nativement. Piecrust, le moteur en dessous, tourne à peu près dix fois plus vite que son prédécesseur, et est livré avec des fonctions hôtes compatibles avec la ZK — PLONK, Groth16 et BLS — intégrées directement dans l’exécution.
j’ai vérifié ce que couvre plutôt DuskEVM. Équivalence EVM complète, outils standards, règlement via DuskDS — la couche pour les développeurs qui veulent conserver des flux de travail Solidity familiers, sans avoir besoin de primitives natives pour la confidentialité.
donc « une VM native plutôt que l’EVM uniquement » n’est pas vraiment un rejet de l’EVM. c’est Dusk qui refuse d’acheminer des contrats natifs en confidentialité et ZK via un modèle d’exécution qui n’a jamais été conçu pour les gérer efficacement.
le fait d’exécuter deux environnements d’exécution séparés rend-il Dusk plus performant, ou est-ce que ça fait juste qu’on divise l’attention des développeurs entre deux systèmes qui accomplissent des tâches qui se chevauchent ?
#dusk $DUSK
Avertissement : ce contenu inclut des opinions de tiers. Il ne constitue pas un conseil. Binance Ai peut être utilisée, sans garantie de résultat. Consultez les CG.