Ne te fais pas avoir par le « zéro connaissance » : les contrats intelligents de Dusk sont-ils réellement coincés dans la mémoire de qui ?

La courbe du rêve a un peu monté, mais BTC reste solide !

À force de regarder les performances, on finit par comprendre : beaucoup de chaînes qui affichent « confidentialité ZK » tournent, lors des tests de mise en œuvre, comme une connexion haut débit façon années 80. Tout le monde fait l’éloge des preuves à connaissance nulle, tellement “magiques”, et de la protection de la vie privée, tellement “implacable”. Mais moi, quand je fixe les nœuds de test, mon inquiétude n’est pas d’abord de savoir si les circuits calculent assez vite : c’est plutôt le fait que, une fois que les contraintes cryptographiques font gonfler la taille de la preuve, le nœud subit ce “micro-hésitation” au moment de traiter la transaction.

Ceux qui travaillent au niveau de l’architecture le savent : que ce soit des ZK-SNARKs ou du PLONK, la génération de preuve suppose toujours qu’il y ait quelqu’un pour la vérifier. Dans son architecture, Dusk introduit Piecrust, une machine virtuelle WASM : le raisonnement est très clair. D’une part, il faut faire passer les transitions d’état à connaissance nulle des contrats de confidentialité. D’autre part, il ne faut pas faire exploser la mémoire des nœuds ordinaires. La feuille de route technique officielle fait rêver : la vérification de la connaissance nulle peut s’effectuer à l’échelle de la milliseconde. Mais quand je lance chez moi des tests de charge sur un nœud local, un doute persiste en permanence : oui, une vérification unique est rapide. Mais dès qu’on rencontre un règlement d’actifs à haute fréquence, si le temps de résidence de la preuve de confidentialité en mémoire n’augmente ne serait-ce que d’un tout petit peu, puis que le mécanisme de récupération de place (GC) fait un à-coup, la latence apparaît immédiatement dans la réponse du nœud.

Ce type de “bégaiement” invisible à l’échelle de l’ingénierie, on ne le voit généralement pas dans les livres blancs. La plus grande peur des chaînes de confidentialité n’est pas que les formules mathématiques ne tiennent pas la route, mais que, dans la réalité, le matériel des nœuds soit inégal. Si la stratégie d’allocation de calcul n’est pas bien réglée, ou si la file de vérification s’accumule, ce fameux “règlement de confidentialité en secondes” devient, en un rien de temps, “transfert : veuillez patienter”. En fin de compte, ce qui détermine si un réseau public de confidentialité peut supporter des actifs de niveau institutionnel, ce n’est pas le niveau de sécurité qu’il annonce, mais sa capacité, lors de pics de concurrence imprévus, à maintenir l’occupation mémoire sur une ligne extrêmement stable et lisse.

La technologie, au fond, n’est pas faite pour qu’on vienne la vénérer. Tout le monde parie sur l’avenir de la couche confidentialité Layer1 ; moi, je me soucie surtout de savoir si, lorsque la puissance de calcul fluctue et que les performances matérielles des nœuds sont hétérogènes, cette machine virtuelle saura vraiment tenir la limite de “ne pas exploser la mémoire”. Selon toi, quel côté de l’équilibre entre confidentialité et performance pourra être réglé de façon totalement satisfaisante au prochain cycle ? #dusk $DUSK @Dusk