J’ai examiné les détails des dernières itérations du réseau de test DuskEVM et de l’ancienne machine virtuelle Piecrust, et plus j’y réfléchis, plus je découvre un paradoxe d’ingénierie assez subtil.
Puisqu’on construit une blockchain de couche fondamentale destinée à la conformité européenne et à la tokenisation des actifs financiers (RWA), l’argument central se résume à « des règlements déterministes sous protection de la confidentialité ». Mais en regardant attentivement sa trajectoire technique : d’un côté, il faut utiliser des circuits ZK natifs pour exécuter des contrats financiers extrêmement exigeants ; de l’autre, pour attirer l’écosystème développeur, on pousse fortement une couche d’exécution compatible EVM.
Le contraste se trouve précisément là. Le mécanisme d’Ethereum basé sur le modèle de compte et sur l’état global ouvert est, par nature, transparent et « résistant à la confidentialité ». Si on importe à la lettre l’écosystème Solidity, pour être compatible avec les outils Ethereum, les développeurs écriront très probablement, par réflexe, une série de variables d’état publiées. Au final, les « dark pools » et protocoles de confidentialité prévus à l’origine pour éviter les fuites de données, et pour s’intégrer à des institutions régulées comme NPEX afin de mettre des actifs on-chain, est-ce que cette couche de compromis pour satisfaire l’écosystème grand public EVM ne finirait pas par les neutraliser ?
Regardons aussi les seuils de mise des nœuds et le mécanisme de consensus. En mettant en avant un règlement de conformité à l’échelle des entreprises, les nœuds doivent souvent disposer de performances matérielles très élevées pour traiter des validations de preuves ZK à haute fréquence. Si on rend le seuil de vérification trop élevé, le réseau finit facilement par devenir un jeu d’alliances pour un petit nombre d’institutions autorisées ; si au contraire on le baisse trop, les nœuds des particuliers, face à une énorme quantité de règlements concurrents de niveau « titres », risquent de ne pas pouvoir tenir non plus : la latence de génération des preuves et le débit ne suivront probablement pas la réalité des opérations.
On veut à la fois l’argent et la conformité des institutions traditionnelles, tout en ne supportant pas le récit décentralisé des développeurs de chaînes publiques et des nœuds de la communauté. Ce type de design « vouloir les deux bouts » paraît très séduisant pendant la phase de réseau de test, mais une fois arrivé le jour où il faudra porter un volume de vrais actifs de plusieurs centaines de millions d’euros, les coûts de performance et les interfaces de conformité ne vont-ils pas forcer l’architecture à retomber dans un compromis ? Tant que je n’ai pas vu, avant tout, des flux de liquidité importants provenant d’institutions réelles circuler sur la chaîne de façon stable pendant un cycle d’audit, j’ai plutôt tendance à considérer ces schémas d’architecture comme des échantillons de laboratoire à la fois précis et fragiles.
Dans la trajectoire de développement des chaînes financières de conformité, quel problème vous semble le plus difficile à concilier ? #dusk $DUSK @Dusk $AAPLB