L’année dernière, à cette heure-là, je m’écharpais encore avec des gens — « Faire valider une logique en dehors du bac à sable WASM ? N’est-ce pas vous-même en train de creuser votre propre tombe ? ». À l’époque, je venais juste de finir un rapport de rétroaction concernant une certaine chaîne, vidée à cause de failles de smart contract, et j’avais la tête pleine de « moins il y a de code, plus c’est sûr ».

Le « grand gâteau » des points de rappel : le BTC a encore une marge de hausse ?

Puis je l’ai fait tourner moi-même, en passant aux nœuds Dusk, et là j’ai compris que ce n’était pas si simple.

J’ai fouillé le code de test de leur système Piecrust, et j’ai aussi été vérifier l’article de performance souvent cité — le but, c’était de mesurer l’overhead du WASM par rapport au code natif sous différents jeux d’instructions ; dans les scénarios cryptographiques, la perte pouvait grimper jusqu’à 255 %. Tu vois le genre : les signatures BLS et les preuves ZK que Dusk traite chaque jour, lesquels ne sont pas des « gros mangeurs » de calcul ? Chaque transaction y est interprétée dans le WASM : c’est comme conduire avec une consommation de carburant de 25 L pour 100 km… et là, le patron de la station-service rigole à s’en décrocher la mâchoire, avant même que ton portefeuille ne tienne.

Du coup, ils ont transformé les opérations de calcul cryptographique à haute fréquence en host function, en appelant directement l’implémentation native. En clair : sur les routes que l’on emprunte souvent, on ne met pas de barrières ; sur celles qu’on prend parfois, on vérifie à fond.

Il y a évidemment un risque : le « rayon de confiance » passe de « tout le bac à sable WASM » à « les quelques lignes de code en C ». Le premier, c’est une sécurité de niveau isolation physique ; le second dépend surtout de la précision et de la rigueur de l’ingénieur. J’ai justement été fouiller, dans un coin du site officiel, leur rapport d’audit T3 2024 — au moins, à l’époque, les cas limites testés n’ont pas explosé. Mais à vrai dire, ce genre de vulnérabilité ne se « trouve » jamais vraiment : on la laisse apparaître en nourrissant les systèmes de données. Un jour, si quelqu’un injecte une preuve soigneusement forgée et déclenche un débordement d’entier passé inaperçu dans un host function… pff, j’aimerais ne pas voir ça de mes propres yeux pour l’instant.

Par contre, si tu cherches l’infaillible, autant ne pas jouer sur les blockchains publiques : retour à l’écriture de programmes en local, c’est beaucoup plus tranquille. Les gens de Dusk font un autre calcul : la contrainte de performance, c’est pour aujourd’hui ; les problèmes de sécurité, on pourra les corriger demain. J’ai tourné trois ans des nœuds, et j’ai vu mourir des chaînes dans neuf cas sur dix à cause de frais de gas trop élevés, personne n’en voulait ; et celles qui étaient brisées de façon brutale ont fini à zéro directement — en tout cas, je n’ai pas vu ces choses de mes propres yeux.

Donc aujourd’hui, je suis moins catégorique. Avant, en dînant avec des amis, je têtais encore le clou en disant « attendons de voir » ; puis en rentrant, j’ai discrètement suivi et mis à jour la version du nœud jusqu’à la dernière. Les projets qui percent le bac à sable, il n’y en a pas tant que ça ; Dusk en fait partie. #dusk $DUSK @Dusk