Kathmandu : les changements apportés à Tezos en septembre 2022

Tezos (XTZ) se distingue par son mécanisme de modification du protocole et son fonctionnement en preuve d’enjeu. En septembre 2022, le réseau a activé Kathmandu, sa onzième grande mise à niveau. Il s’agit d’une étape historique de son développement, et non de la version la plus récente aujourd’hui. Son efficacité énergétique ne signifie pas non plus une absence de consommation sur l’ensemble de son fonctionnement.

https://twitter.com/tezos/status/1573415873129463824

Quels changements apportait Kathmandu ?

Kathmandu poursuivait la série de noms de villes utilisée depuis Athens, le protocole 004. Babylon, Carthage, Delphi, Edo, Florence, Granada, Hangzhou, Ithaca et Jakarta l’avaient précédé. Kathmandu constituait alors l’étape suivante, et d’autres modifications ont suivi. Présenter tous ces noms comme ceux de cités exclusivement antiques serait réducteur.

Les changements comprenaient l’environnement de protocole V6, des travaux sur la validation en plusieurs étapes, la journalisation des événements de contrats et une génération d’aléa renforcée par des fonctions de délai vérifiables, ou VDF. Les notes de version mentionnaient aussi des travaux en cours sur les rollups optimistes exécutant des contrats intelligents et sur la couche de disponibilité des données. Leur présence dans ces notes ne signifiait pas leur activation complète sur le réseau principal avec Kathmandu : les Smart Rollups y ont été activés plus tard, avec Mumbai en mars 2023. D’autres éléments concernaient les changements incompatibles, les reçus d’opération, les RPC, les correctifs, le nom de l’encodage round_overflow et la délégation des comptes implicites lors de l’initialisation. La rubrique « Invoice » désignait ici une rémunération de 3 000 tez pour une contribution au code, et non un nouveau service de facturation des clients.

Dans le compte rendu initial, Kathleen Breitman, cofondatrice de Tezos, mettait en avant le mécanisme de modification du réseau. Celui-ci permet d’adopter de manière coordonnée des changements approuvés, sans devoir créer une branche concurrente à chaque mise à niveau. Il peut réduire les difficultés de coordination, mais ne supprime ni tout risque de scission ni les risques techniques liés aux nouvelles versions.

Le rôle du mécanisme de modification de Tezos

Tezos a été conçu pour évoluer selon une procédure formalisée. Les propositions, les tests, les votes et l’activation restent nécessaires : les développeurs ne peuvent pas imposer automatiquement n’importe quel changement. Selon le compte rendu de l’époque, Breitman évoquait deux changements majeurs du consensus et plusieurs améliorations de capacité. Il s’agissait d’une observation historique, pas d’une faculté de modifier le système indéfiniment sans risque. Elle soulignait aussi que l’augmentation de capacité restait un défi pour d’autres réseaux, dont Ethereum.

Son argument était qu’une demande dépassant les ressources disponibles pouvait entraîner congestion et hausse des frais. Cela ne constitue pas une règle identique pour toutes les chaînes à tout moment. Le coût réel dépend notamment de l’activité du réseau, des ressources disponibles, des applications et des solutions de mise à l’échelle utilisées.

Kathmandu était présenté comme une étape préparant le réseau à accueillir davantage d’utilisateurs. Les progrès sur la validation, l’aléa et les outils de développement n’offraient toutefois ni capacité illimitée ni frais nécessairement très bas dans toutes les situations. Il faut distinguer les fonctions alors en préparation des capacités activées lors de mises à niveau ultérieures.

Pour approfondir, consultez notre guide Investir dans Tezos.