Les différences fondamentales entre Glamsterdam, Dencun et Fusaka proviennent de leurs domaines de problématique propres : Dencun vise des améliorations progressives de capacité, Fusaka cible les transitions collaboratives à moyen terme, et Glamsterdam se concentre sur la restructuration de la collaboration pour la production de blocs et les contraintes d’exécution. Considérer ces mises à niveau comme interchangeables risque de fausser l’évaluation de leur valeur et de la complexité de leur mise en œuvre.
Le panorama de la mise à niveau Glamsterdam positionne Glamsterdam dans la feuille de route Lean Ethereum. Nous comparons ci-dessous ces mises à niveau : quels problèmes spécifiques chacune résout-elle ? Pourquoi Glamsterdam est-il perçu comme une étape décisive dans cette feuille de route ?
Dencun marque une étape clé en matière de capacité et de disponibilité dans la séquence des mises à niveau d’Ethereum, avec pour objectif central une optimisation progressive de l’expérience. Son mécanisme principal, le proto-danksharding (EIP-4844), vise à réduire les coûts de disponibilité des données L2 et à améliorer la structure des frais pour la montée en charge. Pour les utilisateurs et l’écosystème L2, l’impact de Dencun est concret — il se traduit généralement par une variation des coûts de transaction L2 et de l’efficacité de la soumission des données.
Dencun n’aborde pas les frontières de collaboration pour la production de blocs ni les prérequis à l’exécution parallèle. Sa valeur réside dans l’accumulation d’expérience en matière de capacité pour les prochaines mises à niveau et dans le test de l’adaptabilité de l’écosystème aux évolutions du protocole. Évaluer Glamsterdam à l’aune des critères de réussite de Dencun serait une erreur d’appréciation.
Fusaka constitue une phase d’optimisation collaborative qui fait le lien entre les mises à niveau précédentes et suivantes, en se concentrant sur la fluidité de la transition entre plusieurs composants à moyen terme. Il s’agit d’une phase de « réglage de l’articulation du système », et non d’une orientation architecturale indépendante. Sa valeur réside dans la réduction des écarts entre les mises à niveau, offrant aux équipes clients, infrastructure et applications une fenêtre d’adaptation continue.
Fusaka et Glamsterdam ne sont pas en concurrence : ce sont deux relais successifs. Fusaka réduit les frictions collaboratives pour les évolutions structurelles à venir, tandis que Glamsterdam lance une refonte plus profonde des frontières du protocole. Comprendre le rôle transitoire de Fusaka permet de saisir pourquoi les discussions sur Glamsterdam portent davantage sur les mécanismes d’ingénierie que sur de simples métriques de frais.
Glamsterdam s’attaque à des enjeux structurels majeurs : les frontières de collaboration pour la production de blocs (mécanisme ePBS (EIP-7732)) et les contraintes préalables à l’exécution (BAL (EIP-7928) et exécution parallèle). Selon la feuille de route Ethereum.org, Glamsterdam marque une étape d’avancement du mainnet, mais les discussions sur ses mécanismes reposent sur la validation en testnet et la maturité des clients, et non sur un calendrier fixé.
| Phase de mise à niveau | Focus technique | Thèmes principaux de discussion |
|---|---|---|
| Dencun | Expérience de disponibilité et de montée en charge | Variations de capacité et de coût |
| Fusaka | Optimisation collaborative et gestion de la transition | Liaison des composants et migration fluide |
| Glamsterdam | Refonte de la production de blocs et de la structure d’exécution | Frontières de collaboration, contraintes de conflit, cohérence de la mise en œuvre |
Ce tableau montre que les discussions sur Glamsterdam sont intrinsèquement axées sur les mécanismes. La question n’est pas seulement « sera-t-il plus rapide ? », mais aussi « pourquoi sera-t-il plus stable, qui en porte la responsabilité et comment s’effectue la validation ? »
Figure 1. Tableau comparatif des objectifs et des mécanismes de Dencun, Fusaka et Glamsterdam.
Avec Dencun, les utilisateurs perçoivent directement l’évolution des coûts de transaction et de la disponibilité L2. L’impact de Fusaka est plus subtil, se traduisant surtout par une stabilité accrue du système et une transition plus fluide. Les améliorations de Glamsterdam peuvent se traduire par une plus grande prévisibilité lors des pics de charge, mais leur ampleur et leur rythme dépendent de la capacité d’adaptation de l’écosystème.
L’expérience utilisateur ne se manifeste pas de façon identique à chaque mise à niveau. Adopter un modèle de « réduction des frais » pour toutes les mises à niveau occulte les objectifs propres à chacune. Il est plus judicieux pour l’utilisateur de privilégier la stabilité des confirmations et la lisibilité en période de pointe, plutôt que de se focaliser sur une unique promesse de frais.
Avec Dencun, les développeurs se concentrent sur les stratégies de coûts et de disponibilité. Fusaka met l’accent sur la compatibilité et la coordination de la migration. Pour Glamsterdam, l’enjeu est de valider les hypothèses d’exécution, d’actualiser les systèmes de monitoring et de segmenter les stratégies de lancement.
Les fournisseurs d’infrastructure doivent approfondir leur compréhension des mécanismes avec Glamsterdam. Les changements structurels affectent la conception des alertes, le diagnostic des incidents et les stratégies de retour arrière. La check-list de préparation à la mise à niveau des nœuds propose un cadre pour le déploiement par couches, la surveillance des métriques et la gestion des retours arrière ; l’impact de Glamsterdam sur les DApps complète la réinitialisation des métriques côté application et le rythme des releases, offrant des repères concrets pour une adaptation coordonnée.
| Rôle | Focus Dencun | Focus Glamsterdam |
|---|---|---|
| Développeur d’application | Stratégies de coût et L2 | Hypothèses d’exécution et schémas d’accès à l’état |
| Opérateur de nœud | Synchronisation de version et compatibilité | Monitoring par couches et retour arrière d’urgence |
| Fournisseur d’infrastructure | Capacité et latence | Métriques segmentées et réinitialisation des SLA |
Ce tableau permet aux équipes d’allouer les ressources d’adaptation par rôle et évite de transposer directement l’expérience Dencun à la préparation de Glamsterdam.
Lean Ethereum définit l’orientation à long terme, tandis que Glamsterdam fournit les outils d’ingénierie concrets. Il traduit la vision de long terme en tâches vérifiables : les frontières de collaboration sont-elles claires ? Les contraintes d’état sont-elles imposées en amont ? Le comportement d’exécution est-il prédictible ? Tant que ces points sont validés, la feuille de route reste solide.
L’intérêt croissant pour Glamsterdam s’explique par ce déplacement du débat, de la vision abstraite vers des tâches d’ingénierie concrètes. Les équipes peuvent bâtir des check-lists, des métriques de monitoring et des modèles de revue autour de ePBS et BAL, rendant les discussions sur la mise à niveau opérationnelles et évaluables.
Chaque mise à niveau comporte des risques quant à son calendrier, sa qualité et la synchronisation de l’écosystème, mais leur nature diffère. Dencun présente un risque de décalage entre attentes et capacité réelle, Fusaka un risque de rupture de lien collaboratif, et Glamsterdam un risque d’incohérence dans les changements structurels.
La comparaison des risques doit porter sur la nature plutôt que sur la quantité. Chaque mise à niveau a ses propres modes d’échec, nécessitant des stratégies de monitoring et de réponse distinctes. Les ajustements de calendrier de la feuille de route en fonction des retours de test relèvent de la gouvernance technique — ils ne signifient pas nécessairement un changement de cap sur les mécanismes.
Dencun, Fusaka et Glamsterdam sont trois étapes successives d’une même feuille de route, et non des versions concurrentes. Comprendre ce parcours, c’est replacer chaque mise à niveau dans son domaine de problématique : expérience de capacité, transition collaborative, gouvernance structurelle. L’originalité de Glamsterdam est d’amener la discussion sur les mises à niveau d’Ethereum au plus près des mécanismes et de la vérifiabilité technique.
Elles portent sur des axes différents. Dencun traite de la disponibilité progressive et de la montée en charge, tandis que Glamsterdam cible la refonte structurelle de la collaboration pour la production de blocs et des contraintes d’exécution.
Fusaka constitue une phase de transition à moyen terme, axée sur la collaboration multi-composants et la migration fluide, afin d’établir des conditions stables pour les futures évolutions structurelles.
Parce qu’il traite de mécanismes spécifiques et de listes de contrôle d’exécution, en recentrant le débat de la vision abstraite vers des tâches concrètes d’ingénierie et une recherche ciblée.
Surveiller les mises à jour des mécanismes, l’avancement des implémentations clients et les retours du testnet, puis aligner ces éléments avec la feuille de route de votre application pour les vérifications de compatibilité et le rythme de lancement.
Non. Dencun teste les voies de capacité et l’adaptabilité de l’écosystème, tandis que Glamsterdam porte sur des changements structurels d’un autre ordre. Les types de risques et les priorités de préparation sont différents.
En général, aucune migration supplémentaire on-chain n’est requise. Il est essentiel de consulter les annonces publiques de mise à niveau des portefeuilles, des plateformes d’échange et d’Ethereum.org, et de rester informé sur les nouvelles versions des clients.





