J’ai une habitude que je pense que beaucoup de gens partagent : avant d’interagir avec un contrat intelligent, je vérifie d’abord l’adresse. Je pensais que cela suffisait, mais en lisant Dusk, j’ai remarqué quelque chose de simple : l’adresse me dit quel contrat j’appelle, tandis que ce qui exécute réellement est le code qui se trouve derrière. Avant le déploiement, Dusk utilise BLAKE3 pour hacher l’intégralité du bytecode et le comparer à la valeur de hachage stockée, ce qui aide à se protéger contre la malléabilité du bytecode. En termes simples, Dusk ne se contente pas de demander : « Est-ce le bon contrat ? ». Il vérifie aussi si le code derrière cette identité est bien le code qui a été identifié en réalité. Je trouve cela particulièrement précieux pour l’infrastructure financière, car lorsque des contrats intelligents commencent à contrôler des actifs et la logique financière, l’intégrité du code devient elle-même une partie du modèle de confiance. L’adresse identifie le contrat ; le hachage du bytecode protège l’intégrité du code qui se trouve derrière. Et il me reste une question : si davantage de règles financières sont intégrées dans des contrats intelligents, le code lui-même aura-t-il un jour besoin d’une identité que l’on puisse tout autant faire confiance que les personnes et les actifs qu’il contrôle ?
#dusk $BTW $RICE $DUSK @Dusk