Le crépuscule déploie une couche compatible EVM
en plus de sa chaîne native, et la logique affichée est
simple : abaisser la barrière pour les développeurs, laisser les outils Solidity existants
s’y brancher plutôt que de demander à chaque constructeur d’
apprendre une nouvelle pile depuis zéro.
À première vue, c’est le choix évident : la familiarité EVM
est le plus grand vivier de développeurs dans la crypto,
et refuser d’y aller à mi-chemin, c’est ainsi que des L1 prometteuses restent durablement marginales.
Ce qui me retient toutefois, c’est une question plus ciblée :
est-ce qu’une couche compatible EVM hérite des garanties
de confidentialité réelles de Dusk,
ou bien est-ce qu’elle hérite de la transparence par défaut d’EVM et se contente de coexister à côté de la couche
de confidentialité de Dusk, sans rien modifier ?
Ce ne sont pas la même chose, et la nuance
compte davantage ici que pour la plupart des L1
ajoutant une compatibilité EVM,
parce que la confidentialité et la divulgation consciente de la conformité sont la raison d’être de Dusk.
Si un contrat déployé sur la couche EVM se comporte
comme n’importe quel autre contrat EVM — état public, public
calldata, modèle de transparence standard — alors « Dusk prend en charge EVM » et « Le modèle de confidentialité de Dusk s’étend à EVM » sont deux affirmations distinctes,
et seule la communication marketing tend à les avancer simultanément.
La version honnête de ce compromis est que la compatibilité EVM
et le calcul confidentiel natif sont, d’une certaine manière, structurellement opposés.
Le modèle d’exécution d’EVM n’a pas été conçu pour la divulgation sélective ;
la proposition de valeur centrale de Dusk a été construite précisément autour de ce besoin.
Faire le pont entre les deux correctement —
permettre des outils familiers tout en obtenant
des transactions confidentielles et des contrats intelligents
conscients de la conformité — est un véritable problème d’intégration, pas une simple case à cocher.
Il est possible que Dusk l’ait résolu de façon élégante.
Il est aussi possible que « compatible EVM » signifie discrètement
« compatible EVM pour la moitié transparente de la chaîne »,
tandis que les contrats qui préservent réellement la confidentialité nécessitent encore la pile native, XSC,
et la courbe d’apprentissage que la compatibilité EVM était censée supprimer.
@Dusk #dusk $DUSK
en plus de sa chaîne native, et la logique affichée est
simple : abaisser la barrière pour les développeurs, laisser les outils Solidity existants
s’y brancher plutôt que de demander à chaque constructeur d’
apprendre une nouvelle pile depuis zéro.
À première vue, c’est le choix évident : la familiarité EVM
est le plus grand vivier de développeurs dans la crypto,
et refuser d’y aller à mi-chemin, c’est ainsi que des L1 prometteuses restent durablement marginales.
Ce qui me retient toutefois, c’est une question plus ciblée :
est-ce qu’une couche compatible EVM hérite des garanties
de confidentialité réelles de Dusk,
ou bien est-ce qu’elle hérite de la transparence par défaut d’EVM et se contente de coexister à côté de la couche
de confidentialité de Dusk, sans rien modifier ?
Ce ne sont pas la même chose, et la nuance
compte davantage ici que pour la plupart des L1
ajoutant une compatibilité EVM,
parce que la confidentialité et la divulgation consciente de la conformité sont la raison d’être de Dusk.
Si un contrat déployé sur la couche EVM se comporte
comme n’importe quel autre contrat EVM — état public, public
calldata, modèle de transparence standard — alors « Dusk prend en charge EVM » et « Le modèle de confidentialité de Dusk s’étend à EVM » sont deux affirmations distinctes,
et seule la communication marketing tend à les avancer simultanément.
La version honnête de ce compromis est que la compatibilité EVM
et le calcul confidentiel natif sont, d’une certaine manière, structurellement opposés.
Le modèle d’exécution d’EVM n’a pas été conçu pour la divulgation sélective ;
la proposition de valeur centrale de Dusk a été construite précisément autour de ce besoin.
Faire le pont entre les deux correctement —
permettre des outils familiers tout en obtenant
des transactions confidentielles et des contrats intelligents
conscients de la conformité — est un véritable problème d’intégration, pas une simple case à cocher.
Il est possible que Dusk l’ait résolu de façon élégante.
Il est aussi possible que « compatible EVM » signifie discrètement
« compatible EVM pour la moitié transparente de la chaîne »,
tandis que les contrats qui préservent réellement la confidentialité nécessitent encore la pile native, XSC,
et la courbe d’apprentissage que la compatibilité EVM était censée supprimer.
@Dusk #dusk $DUSK