C’est à cela que je reviens sans cesse quand je regarde @Dusk_Foundation : ce n’est pas seulement la façon dont une transaction passe d’une adresse à une autre.
C’est ce qui se passe en dessous de ce transfert.
Une transaction n’est jamais qu’un simple message disant « envoyez cet actif de A à B ». Le réseau doit valider ce qui est demandé, vérifier que les règles pertinentes sont respectées, exécuter la logique requise, potentiellement déployer ou interagir avec des contrats, mettre à jour l’état qui en résulte, et s’assurer que les ressources de calcul utilisées pendant ce processus sont prises en compte.
C’est là que le rôle du contrat de transfert devient intéressant.
Le contrat de transfert est chargé de valider les transactions conformément aux règles applicables, de gérer le déploiement de contrats ou les appels de contrats lorsque nécessaire, et de déduire le gas pour couvrir le travail de calcul lié à l’exécution.
Le gas n’est donc pas simplement un nombre supplémentaire associé à une transaction.
Cela représente une opération que le réseau doit réellement effectuer.
Chaque appel de contrat nécessite des calculs. Chaque changement d’état nécessite un traitement. Chaque couche supplémentaire de logique de transaction peut entraîner un coût en ressources additionnel que les validateurs et le réseau doivent prendre en charge.
Dans cette perspective, la comptabilisation des ressources de calcul semble intuitive.
Si l’exécution consomme des ressources, son coût devrait pouvoir être mesuré.
Sinon, le réseau autoriserait en pratique les utilisateurs à demander des calculs toujours plus complexes sans tenir directement compte des ressources nécessaires pour les effectuer.
Cela pose un problème évident.
La capacité de calcul d’une blockchain est limitée.
Si les transactions étaient tarifées uniquement en fonction de la valeur transférée, plutôt que du travail nécessaire à leur traitement, deux transactions pourraient théoriquement mobiliser des ressources de calcul complètement différentes tout en semblant similaires du point de vue de l’utilisateur.
On pourrait simplement transférer un actif.
Une autre pourrait déclencher plusieurs interactions avec des contrats, modifier plusieurs éléments d’état et nécessiter beaucoup plus de calculs.
Les traiter comme équivalentes masquerait le coût réel de l’exécution.
Mais c’est là que commence le véritable compromis.
Plus le système de transactions est expressif, plus il peut être difficile de rendre les coûts de calcul prévisibles.
En général, les utilisateurs veulent que les transactions leur paraissent simples.
Ils veulent savoir ce qu’ils signent, combien cela leur coûtera et ce qui se passera ensuite.
Les développeurs, quant à eux, veulent disposer d’une flexibilité suffisante pour créer des applications sophistiquées, sans devoir réduire chaque interaction à l’opération la plus simple possible.
Le réseau doit se situer quelque part entre ces deux attentes.
Une comptabilisation insuffisante des ressources de calcul peut encourager une utilisation inefficace ou abusive des ressources du réseau.
Une trop grande complexité du modèle de tarification peut rendre les transactions plus difficiles à comprendre pour les utilisateurs ordinaires.
Et cela soulève une question plus vaste pour la conception de la couche d’exécution.
Où devrait se situer la complexité ?
Devrait-on s’attendre à ce que les utilisateurs comprennent le coût de calcul de transactions de plus en plus sophistiquées ?
Les développeurs devraient-ils masquer la majeure partie de cette complexité ?
Ou le protocole devrait-il continuer à faire évoluer son modèle de comptabilisation afin que l’utilisation des ressources reste mesurable, sans compliquer inutilement l’expérience utilisateur ?
Je pense que c’est l’un des aspects les plus intéressants à suivre avec Dusk.
Car une exécution durable ne consiste pas seulement à rendre les transactions plus rapides ou moins coûteuses.
Il s’agit aussi de créer un système permettant de mesurer, de tarifer et de gérer le travail de calcul requis par les transactions, à mesure que le réseau gagne en expressivité.
Le défi consiste à trouver le juste équilibre.
Si le calcul a un coût réel, ignorer ce coût n’est pas viable.
Mais si le calcul de ce coût devient si compliqué que les utilisateurs ne comprennent plus ce qu’ils paient, le système de comptabilisation peut lui-même devenir un problème d’utilisabilité.
La question à laquelle je reviens sans cesse est donc :
La comptabilisation explicite des ressources de calcul rend-elle le modèle d’exécution de Dusk plus durable, ou la complexité croissante de la tarification du calcul finit-elle par devenir un défi pour l’expérience utilisateur ?
