Nouvel article de Vitalik : Comment réduire le temps de confirmation des transactions sur Ethereum ?
TechFlow SélectionTechFlow Sélection
Nouvel article de Vitalik : Comment réduire le temps de confirmation des transactions sur Ethereum ?
La seule solution pour les applications nécessitant des temps de confirmation plus courts est l'architecture basée sur les slots et les époques.
Dédié à des analyses Web3 approfondiesRédaction : Vitalik Buterin, cofondateur d'Ethereum
Traduction : Luffy, Foresight News
Une caractéristique essentielle d'une bonne expérience utilisateur sur les blockchains est un temps de confirmation rapide des transactions. Ethereum a fait d'énormes progrès par rapport à il y a cinq ans grâce à EIP-1559 et au passage à la preuve d'enjeu (PoS), offrant désormais des intervalles réguliers entre les blocs. Les transactions envoyées par les utilisateurs sur la couche 1 (L1) peuvent être confirmées de manière fiable en 5 à 20 secondes, ce qui se rapproche déjà de l'expérience utilisateur des paiements par carte bancaire. Cependant, l'expérience utilisateur d'Ethereum nécessite encore des améliorations, car certaines applications exigent effectivement des délais transactionnels de quelques centaines de millisecondes voire moins. Cet article présente plusieurs solutions pratiques pour accélérer le temps de confirmation des transactions sur Ethereum.
Aperçu des idées et technologies existantes
Finalité en un seul slot
Actuellement, le consensus Gasper d’Ethereum repose sur une architecture composée de slots et d’epochs. Toutes les 12 secondes (durée d’un slot), un sous-ensemble de validateurs émet des votes sur le dernier bloc de la blockchain. Pendant chaque epoch (32 slots, soit 6,4 minutes), tous les validateurs ont l’occasion de voter une fois. Ces votes sont ensuite interprétés comme des messages dans un algorithme de consensus similaire au PBFT, qui fournit des garanties économiques très strictes après deux epochs (12,8 minutes). Ce délai marque la finalité.
Ces dernières années, nous sommes de plus en plus insatisfaits de cette approche. Les raisons principales sont : (i) sa complexité, avec de nombreuses interactions problématiques entre le mécanisme de vote slot par slot et le mécanisme de finalité par epoch ; (ii) 12,8 minutes est trop long — personne ne veut attendre aussi longtemps.
La finalité en un seul slot (single slot finality, SSF) remplace cette architecture par un mécanisme similaire au consensus Tendermint, où le bloc N est définitivement validé avant même que le bloc N+1 ne soit généré. La principale différence avec Tendermint réside dans le maintien du mécanisme de « fuite d’inactivité » (inactivity leak), qui permet à la blockchain de continuer à fonctionner et de se rétablir même si plus d’un tiers des validateurs sont hors ligne.
Schéma conceptuel de la solution de finalité en un seul slot
Le principal défi de la SSF semble être qu’elle impliquerait que chaque staker d’Ethereum doive publier deux messages toutes les 12 secondes, ce qui constitue un fardeau important pour la blockchain. Des idées ingénieuses ont été proposées pour atténuer cela, notamment la proposition récente Orbit SSF (https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928). Malgré tout, bien que cette solution améliore significativement l’expérience utilisateur en accélérant la « finalité », elle ne réduit pas le délai d’attente actuel de 5 à 20 secondes ressenti par les utilisateurs.
Pré-confirmations via Rollup
Ces dernières années, Ethereum a suivi une feuille de route centrée sur les rollups, concevant la couche fondamentale (L1) autour du soutien à la disponibilité des données et d'autres fonctionnalités. Ces fonctionnalités sont exploitées par des protocoles de niveau 2 (L2) tels que les rollups, les Validiums et les Plasmas, qui peuvent offrir aux utilisateurs un niveau de sécurité équivalent à celui d’Ethereum, mais avec des capacités transactionnelles bien supérieures à celles de la L1.
Cela conduit à une séparation claire des responsabilités dans l’écosystème Ethereum : la L1 peut se concentrer sur la résistance à la censure, la fiabilité, la stabilité et l’amélioration de certaines fonctions fondamentales, tandis que les L2 peuvent privilégier l’expérience utilisateur à travers des compromis culturels et techniques différents. Mais en suivant cette voie, une question inévitable émerge : les L2 devraient pouvoir servir les utilisateurs souhaitant des confirmations plus rapides, en moins de 5 à 20 secondes.
Jusqu’à présent, créer son propre réseau de « triage décentralisé » est devenu une obligation incontournable pour les L2. En pratique, un petit groupe de validateurs signe probablement un bloc toutes les quelques centaines de millisecondes, en engageant leurs jetons sur ces blocs. À terme, les en-têtes de ces blocs L2 sont publiés sur la L1.
L’ensemble des validateurs L2 pourrait tricher : ils pourraient signer d’abord le bloc B1, puis signer un bloc B2 en conflit avec B1, et soumettre B2 en premier sur la chaîne. Mais s’ils font cela, ils encourent une pénalité entraînant la perte de leur dépôt. En pratique, nous avons déjà vu des versions centralisées de cette approche, mais les rollups progressent lentement vers le triage décentralisé. On peut considérer qu’exiger de chaque L2 la mise en place d’un triage décentralisé revient à leur imposer un travail équivalent à la création d’une nouvelle L1 — une exigence injuste. Pour diverses raisons, Justin Drake, chercheur à la Fondation Ethereum, milite depuis longtemps pour une méthode permettant à tous les L2 (et même la L1) d’accéder à un mécanisme partagé de pré-confirmation Ethereum : les based preconfirmations.
Based preconfirmations (pré-confirmations basées)
L’approche des based preconfirmations suppose que les proposants de blocs Ethereum deviendront des participants hautement sophistiqués en raison des incitations liées au MEV (voir ici pour mon explication du MEV, ainsi que cette proposition). Cette méthode exploite cette sophistication pour inciter ces proposants avancés à fournir un service de pré-confirmation.
L'idée de base consiste à créer un protocole standardisé permettant aux utilisateurs de payer des frais supplémentaires en échange d'une garantie immédiate d'inclusion de leur transaction dans le prochain bloc, accompagnée d'une déclaration sur le résultat de son exécution. Si un proposant viole cet engagement vis-à-vis d’un utilisateur, il subit une pénalité.
Comme indiqué ci-dessus, le mécanisme de based preconfirmations offre des garanties pour les transactions L1. Si un rollup est un « Based Rollup » (terme introduit par Justin Drake en mars 2023, désignant un rollup dont le triage est entièrement géré par la L1), alors tous ses blocs L2 sont eux-mêmes des transactions L1, et le même mécanisme peut donc être utilisé pour fournir des pré-confirmations à n’importe quel L2.
Que voyons-nous concrètement ?
Supposons que nous mettions en œuvre la finalité en un seul slot. Nous utilisons des techniques similaires à Orbit pour réduire le nombre de validateurs devant signer à chaque slot, ce qui nous permet également de diminuer le seuil minimum de mise en jeu de 32 ETH — un double avantage. En conséquence, la durée du slot pourrait progressivement passer à 16 secondes. Ensuite, nous utilisons les pré-confirmations via rollup ou les based preconfirmations pour offrir aux utilisateurs des garanties plus rapides. Qu’obtenons-nous alors ? Une architecture slot-and-epoch.
Le meme « c’est la même image » est trop utilisé, donc je vais simplement juxtaposer ici un ancien schéma que j’avais dessiné il y a quelques années avec un diagramme de pré-confirmation L2 illustrant l’architecture slot-and-epoch de Gasper, dans l’espoir d’être suffisamment clair.
Il existe une raison philosophique profonde expliquant pourquoi les gens retombent inévitablement sur une architecture epoch-and-slot : parvenir à un accord approximatif sur un événement prend intrinsèquement moins de temps que d’atteindre un consensus maximal en termes de « finalité économique ».
Une raison simple est le nombre de nœuds impliqués. Bien que l’ancien compromis progressif entre décentralisation, temps de finalité et surcoût, autrefois sévère, apparaisse maintenant plus modéré grâce à l’agrégation BLS fortement optimisée et aux ZK-STARKs à venir, le point fondamental reste valable :
-
Un « accord approximatif » requiert seulement un petit nombre de nœuds, tandis que la finalité économique exige une fraction substantielle de tous les nœuds.
-
Dès que le nombre de nœuds dépasse un certain seuil, plus de temps est nécessaire pour collecter les signatures.
Sur Ethereum actuel, le slot de 12 secondes est divisé en trois sous-slots destinés à (i) la publication et distribution du bloc, (ii) les attestations, (iii) l’agrégation des attestations. Si le nombre d’attestateurs était nettement plus faible, on pourrait réduire cela à deux sous-slots, aboutissant à un slot de 8 secondes. Un autre facteur, encore plus important en pratique, est la « qualité » des nœuds. Si nous pouvons compter sur un sous-ensemble spécialisé de nœuds pour atteindre un accord approximatif (tout en conservant l’ensemble complet des validateurs pour la finalité), nous pourrions raisonnablement descendre à environ 2 secondes.
Par conséquent, je pense que (i) l’architecture slot-and-epoch est clairement la bonne direction, mais que (ii) toutes les architectures slot-and-epoch ne se valent pas, et que nous devons explorer plus pleinement l’espace de conception. En particulier, les schémas moins étroitement imbriqués que Gasper méritent d’être explorés.
Que devraient faire les L2 ?
À mon avis, les L2 disposent actuellement de trois stratégies raisonnables :
-
Être « based », tant techniquement que philosophiquement. Autrement dit, les L2 doivent servir de canal supérieur pour transmettre les propriétés techniques et les valeurs fondamentales d’Ethereum (décentralisation élevée, résistance à la censure, etc.). Sous sa forme la plus simple, on peut voir ces rollups comme des « shards de marque », mais ils peuvent aussi être plus ambitieux, expérimentant intensivement de nouveaux designs de machines virtuelles et d’autres améliorations techniques.
-
Devenir un « serveur doté d’un squelette blockchain », et tirer parti de cet avantage. Si vous partez d’un serveur, puis ajoutez (i) des preuves de validité STARK pour garantir que le serveur respecte les règles, (ii) le droit pour les utilisateurs de sortir ou d’imposer des transactions, ainsi que potentiellement (iii) une capacité collective de choix — via une sortie massive coordonnée ou un vote pour changer de séquenceur — vous obtenez alors de nombreux bénéfices d’une blockchain tout en conservant l’efficacité d’un serveur.
-
Une solution intermédiaire : une blockchain rapide avec 100 nœuds, s’appuyant sur Ethereum pour une interopérabilité et une sécurité supplémentaires. C’est la feuille de route actuelle de facto de nombreux projets L2.
Pour certaines applications (comme ENS, les coffres-forts de clés ou certains cas de paiement), un temps de bloc de 12 secondes est suffisant. Pour celles nécessitant des temps de confirmation plus courts, la seule solution viable est l’architecture slot-and-epoch. Dans les trois cas, l’« epoch » correspond à la SSF d’Ethereum (peut-être pourrions-nous redéfinir cet acronyme autrement que par « single slot », par exemple « Secure Speedy Finality »). Toutefois, dans les trois scénarios, le « slot » diffère :
-
L’architecture native slot-and-epoch d’Ethereum
-
Pré-confirmation par serveur
-
Pré-confirmation par comité
Une question clé est : jusqu’où pouvons-nous améliorer la première catégorie ? En particulier, si elle devient excellente, la troisième option semble perdre tout intérêt. La deuxième catégorie subsistera toujours, car toute solution « based » ne convient pas aux L2 utilisant des données hors chaîne, comme Plasma ou Validium. Mais si l’architecture native slot-and-epoch d’Ethereum parvient à réduire le temps du « slot » (c’est-à-dire la pré-confirmation) à 1 seconde, alors l’espace disponible pour la troisième catégorie devient beaucoup plus restreint.
Aujourd’hui, nous sommes loin d’avoir les réponses définitives à ces questions. À quel point les proposants de blocs deviendront-ils complexes ? Cette question clé reste entourée d’une grande incertitude. Des conceptions comme Orbit SSF sont très nouvelles, et l’espace de conception des schémas slot-and-epoch inspirés d’Orbit SSF mérite encore une exploration approfondie. Plus nous aurons d'options, mieux nous pourrons servir les utilisateurs sur la L1 et la L2, et plus nous simplifierons le travail des développeurs de L2.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@VitalikButerin
