L’accélération d’Ethereum se heurte depuis toujours à un nœud gordien : pour faire tourner la chaîne plus vite, il faut généralement sacrifier la décentralisation ou la résistance à la censure.
L’EIP-8198 (Quick Slots) proposé par l’auteur #Ethlabs tente de contourner ce dilemme, et l’approche est plutôt intelligente.
La méthode consiste en deux étapes : d’abord, réduire progressivement le temps de génération des blocs de 12 secondes à 10 secondes, mais sans le modifier d’un coup ; au lieu de cela, en faire une « montée en vitesse contrôlée, testable progressivement » ; en parallèle, ajuster aussi les paramètres de capacité, de Gas et de Blob.
Le point clé est dans les mots « progressivement ». Les mises à niveau d’Ethereum redoutent le plus le changement « d’un seul coup » : une fois les paramètres modifiés, s’il y a un problème, c’est tout le réseau qui en paie le prix. En concevant une vitesse variable, on répartit le risque en petites parts : à chaque fois, on ne touche qu’un peu, et on continue seulement après avoir vérifié que tout va bien.
Cela explique aussi pourquoi l’évolution d’Ethereum donne toujours l’impression d’avancer lentement : ce qu’il recherche n’est pas le « plus rapide », mais « devenir plus rapide sans perdre le contrôle ». La vitesse peut augmenter petit à petit, mais si la décentralisation est abandonnée, on ne la récupère plus.
Les véritables difficultés techniques ne consistent donc jamais à savoir s’il est possible d’aller vite, mais plutôt à savoir si, une fois plus rapide, on reste toujours sur la même chaîne que celle d’origine.
L’EIP-8198 (Quick Slots) proposé par l’auteur #Ethlabs tente de contourner ce dilemme, et l’approche est plutôt intelligente.
La méthode consiste en deux étapes : d’abord, réduire progressivement le temps de génération des blocs de 12 secondes à 10 secondes, mais sans le modifier d’un coup ; au lieu de cela, en faire une « montée en vitesse contrôlée, testable progressivement » ; en parallèle, ajuster aussi les paramètres de capacité, de Gas et de Blob.
Le point clé est dans les mots « progressivement ». Les mises à niveau d’Ethereum redoutent le plus le changement « d’un seul coup » : une fois les paramètres modifiés, s’il y a un problème, c’est tout le réseau qui en paie le prix. En concevant une vitesse variable, on répartit le risque en petites parts : à chaque fois, on ne touche qu’un peu, et on continue seulement après avoir vérifié que tout va bien.
Cela explique aussi pourquoi l’évolution d’Ethereum donne toujours l’impression d’avancer lentement : ce qu’il recherche n’est pas le « plus rapide », mais « devenir plus rapide sans perdre le contrôle ». La vitesse peut augmenter petit à petit, mais si la décentralisation est abandonnée, on ne la récupère plus.
Les véritables difficultés techniques ne consistent donc jamais à savoir s’il est possible d’aller vite, mais plutôt à savoir si, une fois plus rapide, on reste toujours sur la même chaîne que celle d’origine.