Hegotá est deux mises à niveau sous un seul nom

Comme les précédents noms Dencun, Pectra, Fusaka et Glamsterdam, Hegotá désigne en réalité l’association de deux mises à niveau coordonnées. Bogotá concerne l’Execution Layer, où s’exécutent transactions et smart contracts. Heze concerne la Consensus Layer, chargée notamment de la coordination des validateurs et de la finalité du réseau.

Le choix du nom ne préjuge pas du contenu technique. Les développeurs Ethereum sélectionnent séparément les Ethereum Improvement Proposals qui pourront entrer dans les deux parties du fork. Une proposition discutée pour Hegotá n’est donc pas automatiquement une fonctionnalité promise aux utilisateurs.

Glamsterdam a déplacé une partie du travail hors du chemin critique

Le contexte de Hegotá vient directement des forks précédents. Ethereum cherche depuis plusieurs mises à niveau à augmenter le débit du Layer 1 tout en laissant davantage de capacité aux rollups de Layer 2. Cette progression passe à la fois par l’augmentation de certaines limites et par la réduction du travail que chaque nœud doit effectuer pour vérifier la chaîne.

Glamsterdam a poursuivi cette logique en travaillant notamment sur la manière dont les blocs sont construits et propagés. La feuille de route Ethereum ne repose plus sur une seule transformation spectaculaire : plusieurs modifications plus spécialisées sont déployées successivement afin de retirer des goulets d’étranglement avant de relever encore les capacités.

Le prochain mur est l’état d’Ethereum

Augmenter le gas limit permet de faire entrer davantage de calcul dans chaque bloc, mais les transactions ne consomment pas uniquement du temps CPU. Elles peuvent aussi ajouter ou modifier des comptes, contrats et emplacements de stockage que les nœuds doivent ensuite conserver.

Cette accumulation constitue l’état d’Ethereum. Contrairement aux données historiques qu’un nœud peut parfois externaliser ou supprimer selon son rôle, une grande partie de l’état courant doit rester rapidement accessible pour vérifier les nouvelles transactions. Une chaîne plus rapide qui laisse cet ensemble grossir sans contrôle déplace donc simplement son problème de scalabilité vers le stockage et les accès disque.

Les discussions autour de Hegotá s’inscrivent notamment dans cette tension entre davantage de débit et un état soutenable. Plusieurs mécanismes de long terme étudiés dans la feuille de route Ethereum cherchent à rendre la gestion de cet état moins coûteuse pour les nœuds.

Les EIP candidates ne sont pas encore toutes des fonctions de Hegotá

À ce stade du cycle de développement, les équipes Ethereum examinent différentes propositions susceptibles d’être intégrées à Bogotá ou Heze. Leur statut peut évoluer : une EIP peut être considérée, retenue comme candidate, reportée vers un fork ultérieur ou abandonnée.

Cette mécanique est importante pour suivre la feuille de route sans transformer chaque discussion de développeurs en annonce de produit. Le contenu définitif d’un hard fork se précise au fil des réunions All Core Developers, des implémentations dans les clients, des devnets puis des testnets.

Une proposition techniquement séduisante peut donc disparaître de Hegotá simplement parce que son implémentation est trop complexe, qu’elle dépend d’un autre changement ou que les équipes clientes ne disposent pas du temps nécessaire pour la tester avec suffisamment de sécurité.

La cadence des forks est devenue une contrainte d’ingénierie

Ethereum cherche désormais à livrer des mises à niveau plus régulièrement plutôt qu’à concentrer trop de changements dans un seul fork. Cette approche raccourcit le délai entre une EIP suffisamment mûre et son arrivée sur le réseau, mais elle oblige également à fermer plus tôt la liste des fonctionnalités.

Le bénéfice est qu’une proposition reportée n’a plus nécessairement à attendre plusieurs années. Le coût est une feuille de route moins spectaculaire à lire : certaines fonctions attendues migrent d’un nom de fork au suivant et les listes publiées très en amont vieillissent rapidement.

Plus de débit signifie toujours plus de contraintes pour les nœuds

Les performances du Layer 1 ne peuvent pas être évaluées uniquement en transactions par seconde. Un relèvement de capacité doit rester compatible avec le temps nécessaire pour exécuter un bloc, le propager, vérifier son état et permettre à suffisamment d’opérateurs de faire tourner un nœud.

Cette contrainte explique pourquoi Ethereum combine optimisation du protocole, améliorations de la propagation, travail sur l’état et développement des Layer 2. Doubler une limite dans un paramètre est facile ; conserver les propriétés de vérification du réseau après ce doublement est la partie qui occupe les équipes clientes.

Hegotá n’a pas encore de fiche technique définitive

Le nom du prochain cycle est établi, son orientation générale se dessine et les propositions techniques sont en cours de sélection. Cela ne suffit pas encore à traiter chaque EIP discutée comme une fonctionnalité confirmée.

Les étapes les plus utiles à surveiller seront donc la stabilisation des EIP retenues, leur intégration simultanée dans plusieurs clients Ethereum puis leur passage sur les réseaux de test. C’est à ce moment que Hegotá cessera progressivement d’être une liste de possibilités pour devenir une mise à niveau précisément définie.

La continuité avec Glamsterdam est déjà plus claire : Ethereum tente d’augmenter sa capacité par étapes sans faire payer chaque gain de débit par une augmentation équivalente des exigences imposées aux nœuds. Hegotá devra poursuivre ce travail avec une ressource particulièrement difficile à compresser : l’état accumulé par une blockchain qui fonctionne depuis plus d’une décennie.