La plupart des gens jugent une plateforme de smart-contracts au nombre de développeurs qu’elle peut attirer.
Je pensais pareil.
Puis Piecrust m’a fait remettre en question cette hypothèse.
Dusk a choisi un parcours d’exécution basé sur le WASM plutôt que de simplement suivre la foule de l’EVM. Au début, cela ressemblait à un sacrifice de compatibilité. Pourquoi emprunter une route différente alors qu’Ethereum dispose déjà des outils et de la familiarité des développeurs ?
Mais en creusant, j’ai vu qu’il s’agissait d’une autre priorité.
Piecrust est conçu pour exécuter des contrats Rust/WASM dans l’environnement contrôlé de Dusk, avec une architecture de machine virtuelle pensée en fonction des besoins de l’infrastructure financière axée sur la confidentialité de Dusk. C’est important, car les contrats financiers ne se limitent pas à l’exécution d’instructions. Ils peuvent nécessiter de la confidentialité, une exécution prévisible et une interaction directe avec la machinerie de transaction et de preuve à connaissance nulle (zéro connaissance) propre au réseau.
Cela change ma façon de voir la décision liée au WASM.
La question intéressante n’est pas de savoir si le WASM peut battre l’EVM dans l’imaginaire des développeurs.
La question, c’est plutôt si le fait de choisir un environnement d’exécution adapté au véritable cas d’usage financier du réseau peut créer quelque chose que la seule compatibilité EVM ne peut pas.
Mais il y a un risque évident.
Une machine virtuelle techniquement cohérente a encore besoin de développeurs, d’outils, d’audits, d’applications et d’utilisateurs réels. Le Mainnet Beta peut prouver que l’architecture fonctionne ; l’adoption doit prouver que les gens ont réellement envie de construire autour de celle-ci.
Du coup, je me retrouve avec une question plus difficile :
Piecrust est-il une contrainte que Dusk a choisie d’accepter pour mieux contrôler — ou bien une base qui pourrait, à terme, rendre cette contrainte valable ?
@DuskNetwork $DUSK #Dusk @Dusk
Je pensais pareil.
Puis Piecrust m’a fait remettre en question cette hypothèse.
Dusk a choisi un parcours d’exécution basé sur le WASM plutôt que de simplement suivre la foule de l’EVM. Au début, cela ressemblait à un sacrifice de compatibilité. Pourquoi emprunter une route différente alors qu’Ethereum dispose déjà des outils et de la familiarité des développeurs ?
Mais en creusant, j’ai vu qu’il s’agissait d’une autre priorité.
Piecrust est conçu pour exécuter des contrats Rust/WASM dans l’environnement contrôlé de Dusk, avec une architecture de machine virtuelle pensée en fonction des besoins de l’infrastructure financière axée sur la confidentialité de Dusk. C’est important, car les contrats financiers ne se limitent pas à l’exécution d’instructions. Ils peuvent nécessiter de la confidentialité, une exécution prévisible et une interaction directe avec la machinerie de transaction et de preuve à connaissance nulle (zéro connaissance) propre au réseau.
Cela change ma façon de voir la décision liée au WASM.
La question intéressante n’est pas de savoir si le WASM peut battre l’EVM dans l’imaginaire des développeurs.
La question, c’est plutôt si le fait de choisir un environnement d’exécution adapté au véritable cas d’usage financier du réseau peut créer quelque chose que la seule compatibilité EVM ne peut pas.
Mais il y a un risque évident.
Une machine virtuelle techniquement cohérente a encore besoin de développeurs, d’outils, d’audits, d’applications et d’utilisateurs réels. Le Mainnet Beta peut prouver que l’architecture fonctionne ; l’adoption doit prouver que les gens ont réellement envie de construire autour de celle-ci.
Du coup, je me retrouve avec une question plus difficile :
Piecrust est-il une contrainte que Dusk a choisie d’accepter pour mieux contrôler — ou bien une base qui pourrait, à terme, rendre cette contrainte valable ?
@DuskNetwork $DUSK #Dusk @Dusk