La plupart des développeurs se tournent vers Solidity et la machine virtuelle EVM par réflexe — les outils, les bibliothèques, les années d’habitudes y sont ancrés. Mais l’EVM a une particularité qui la rend presque inutilisable pour la finance réglementée : elle tout révèle. L’état du contrat est public par défaut. Chaque solde, chaque contrepartie, lisible par n’importe qui.
Pour un DEX, c’est parfait. Pour une obligation tokenisée avec un tableau des détenteurs confidentiel et des positions sensibles, cette transparence est inacceptable. Alors les équipes s’engagent dans une bifurcation peu élégante. Abandonner entièrement l’EVM et perdre toute la chaîne d’outils et le vivier de talents. Ou ajouter la confidentialité “hors chaîne” — et réintroduire discrètement le médiateur de confiance que l’on était venu supprimer.
DuskEVM est la tentative de Dusk d’éviter cette bifurcation : conserver la voie Solidity familière, mais ajouter la confidentialité nativement grâce à Hedger, son module de confidentialité. Le mécanisme est le point intéressant — chiffrement homomorphe plus preuves à divulgation nulle, pour qu’un contrat puisse calculer sur des données qu’il n’expose jamais tout en prouvant qu’il a bien exécuté le calcul. Vérifiable, pas seulement caché.
Je reste sceptique. Le chiffrement FHE a historiquement été lent et coûteux, et la génération des preuves ZK n’est pas gratuite. Une “EVM confidentielle” a déjà été promise par le passé et a cédé sous la charge réelle. La confidentialité vérifiable n’a d’intérêt que si elle est assez rapide pour permettre de construire.
Qui l’utiliserait ? Des équipes qui veulent la familiarité de l’EVM mais ne peuvent pas, légalement, divulguer. Pourquoi ça pourrait fonctionner : ça s’adresse aux développeurs là où ils se trouvent déjà. Ce qui le met à mal : l’overhead qui rend les applications réelles peu praticables.
À surveiller. Le goulot d’étranglement, c’est la performance, pas l’idée.
@Dusk_Foundation $DUSK #dusk
Pour un DEX, c’est parfait. Pour une obligation tokenisée avec un tableau des détenteurs confidentiel et des positions sensibles, cette transparence est inacceptable. Alors les équipes s’engagent dans une bifurcation peu élégante. Abandonner entièrement l’EVM et perdre toute la chaîne d’outils et le vivier de talents. Ou ajouter la confidentialité “hors chaîne” — et réintroduire discrètement le médiateur de confiance que l’on était venu supprimer.
DuskEVM est la tentative de Dusk d’éviter cette bifurcation : conserver la voie Solidity familière, mais ajouter la confidentialité nativement grâce à Hedger, son module de confidentialité. Le mécanisme est le point intéressant — chiffrement homomorphe plus preuves à divulgation nulle, pour qu’un contrat puisse calculer sur des données qu’il n’expose jamais tout en prouvant qu’il a bien exécuté le calcul. Vérifiable, pas seulement caché.
Je reste sceptique. Le chiffrement FHE a historiquement été lent et coûteux, et la génération des preuves ZK n’est pas gratuite. Une “EVM confidentielle” a déjà été promise par le passé et a cédé sous la charge réelle. La confidentialité vérifiable n’a d’intérêt que si elle est assez rapide pour permettre de construire.
Qui l’utiliserait ? Des équipes qui veulent la familiarité de l’EVM mais ne peuvent pas, légalement, divulguer. Pourquoi ça pourrait fonctionner : ça s’adresse aux développeurs là où ils se trouvent déjà. Ce qui le met à mal : l’overhead qui rend les applications réelles peu praticables.
À surveiller. Le goulot d’étranglement, c’est la performance, pas l’idée.
@Dusk_Foundation $DUSK #dusk