#dusk $DUSK @Dusk En lisant les notes de publication de Boreas, je me suis arrêté sur un petit changement : DUSK ne chiffre plus SHA-256, Keccak et le hachage générique comme si chaque entrée coûtait la même chose.

Un hachage de 32 octets et un appel de hachage multi-kilo-octets sollicitent la même requête d’hôte, mais n’exigent pas un travail équivalent. Boreas ajoute une tarification proportionnelle à la taille pour ces trois opérations, tandis que la vérification des multisignatures BLS évolue avec le nombre de clés. La vérification KZG et la récupération secp256k1 ne sont pas décrites comme étant facturées en fonction de la longueur d’entrée. Chercher quelle requête est « la plus coûteuse » sans fixer la longueur d’entrée et le nombre de clés, c’est presque une mauvaise question.

La comparaison oppose une tarification forfaitaire par appel d’API à un calcul imposé aux validateurs. DUSK s’est rapproché de la seconde approche.

Il y a toutefois une complication. Boreas est conscient des forks : l’exécution historique conserve les sémantiques antérieures au fork, tandis que les contrats actuels reçoivent le nouveau barème. Un calcul équivalent peut donc entraîner des coûts en gaz différents selon le contexte d’exécution nécessaire pour la relecture, ce qui est peu pratique pour les développeurs qui anticipent les coûts.

Pour DUSK, une meilleure précision du gaz devrait réduire les charges cryptographiques sous-tarifées et rendre l’exécution plus cohérente entre les nœuds. Cela ne prouve pas que les transitions d’état réussies seraient devenues moins chères. Peut-être sont-elles simplement devenues plus honnêtement tarifées, même si le montant augmente.

J’attends encore des données de benchmark par tranche d’entrée. La comptabilité déterministe n’est convaincante que lorsque le gaz facturé correspond au travail CPU réel.
@Dusk #dusk #Dusk