Remplacer BLAKE2b par SHA3, juste parce que tous deux sont appelés « hash » : à première vue, il s’agit d’un petit changement, mais en réalité on risque d’envoyer un objet dans une voie de reconnaissance erronée. Pour ce type d’interface, la première question n’est pas « quel algorithme est le plus puissant », mais « à qui cette chaîne de résultat est-elle destinée ? »
Dans la documentation de développement de Dusk, BLAKE2b apparaît dans des chemins comme l’ID de contrat, l’ID de transaction et des opérations de hash-to-scalar. Ces éléments répondent aux besoins de reconnaissance et de calcul propres aux contrats, aux transactions et aux conversions de scalaires. SHA3, lui, est utilisé pour des identifiants de blocs, de Merkle ou de consensus : il sert une autre famille d’objets. Le fait que les noms contiennent « hash » ne signifie pas que l’objet d’entrée, l’usage de sortie ou l’emplacement d’appel sont identiques. Mettre SHA3 à la place de BLAKE2b peut faire perdre la correspondance sémantique d’origine, même si les maillons en aval récupèrent toujours une chaîne de longueur correcte ; et l’inverse est également vrai. L’apparence d’une compatibilité d’interface ne remplace pas l’« engagement » contractuel de l’objet.
Regardons ensuite DuskDS. Il remplit des fonctions d’infrastructure liées au règlement et à la disponibilité des données ; ce n’est pas un alias de quelque hash que ce soit, et ce n’est pas non plus une capacité globale du réseau qu’on peut déduire en voyant un certain hash. Lors du diagnostic, il faut donc écrire « objet — algorithme — composant » en trois colonnes : d’abord marquer les identifiants de contrat, de transaction, de scalaire, de bloc, de Merkle ou de consensus, puis vérifier le hash que chacun utilise, et enfin confirmer à quel niveau le résultat est transmis. Si l’une des colonnes manque, le « remplacement » devient une simple supposition.
Le jugement vraiment fiable consiste à poser la question le long des limites de l’interface : ce changement modifie quel objet ? L’objet est-il toujours interprété par le même composant ? Ce que le système en aval attend, ce sont des ID/identifiants, ou bien d’autres résultats encodés ? Les discussions de développement autour de @Dusk et $DUSK ne peuvent pas être résolues en remplaçant par un nom de fonction familier. Dans l’écosystème #dusk , ce qui est vérifiable, ce sont des chemins précis, pas l’intuition « tous les hash se valent ». Un nom de hash n’indique qu’une responsabilité locale : il ne peut pas conclure automatiquement en termes de règlement, de disponibilité des données ou de chaîne d’exécution complète.
Dans la documentation de développement de Dusk, BLAKE2b apparaît dans des chemins comme l’ID de contrat, l’ID de transaction et des opérations de hash-to-scalar. Ces éléments répondent aux besoins de reconnaissance et de calcul propres aux contrats, aux transactions et aux conversions de scalaires. SHA3, lui, est utilisé pour des identifiants de blocs, de Merkle ou de consensus : il sert une autre famille d’objets. Le fait que les noms contiennent « hash » ne signifie pas que l’objet d’entrée, l’usage de sortie ou l’emplacement d’appel sont identiques. Mettre SHA3 à la place de BLAKE2b peut faire perdre la correspondance sémantique d’origine, même si les maillons en aval récupèrent toujours une chaîne de longueur correcte ; et l’inverse est également vrai. L’apparence d’une compatibilité d’interface ne remplace pas l’« engagement » contractuel de l’objet.
Regardons ensuite DuskDS. Il remplit des fonctions d’infrastructure liées au règlement et à la disponibilité des données ; ce n’est pas un alias de quelque hash que ce soit, et ce n’est pas non plus une capacité globale du réseau qu’on peut déduire en voyant un certain hash. Lors du diagnostic, il faut donc écrire « objet — algorithme — composant » en trois colonnes : d’abord marquer les identifiants de contrat, de transaction, de scalaire, de bloc, de Merkle ou de consensus, puis vérifier le hash que chacun utilise, et enfin confirmer à quel niveau le résultat est transmis. Si l’une des colonnes manque, le « remplacement » devient une simple supposition.
Le jugement vraiment fiable consiste à poser la question le long des limites de l’interface : ce changement modifie quel objet ? L’objet est-il toujours interprété par le même composant ? Ce que le système en aval attend, ce sont des ID/identifiants, ou bien d’autres résultats encodés ? Les discussions de développement autour de @Dusk et $DUSK ne peuvent pas être résolues en remplaçant par un nom de fonction familier. Dans l’écosystème #dusk , ce qui est vérifiable, ce sont des chemins précis, pas l’intuition « tous les hash se valent ». Un nom de hash n’indique qu’une responsabilité locale : il ne peut pas conclure automatiquement en termes de règlement, de disponibilité des données ou de chaîne d’exécution complète.