Discuter des solutions pratiques pour améliorer le temps de confirmation des transactions sur Ethereum

Un aspect important de l'expérience utilisateur de la blockchain est le temps de confirmation des transactions. Ces dernières années, Ethereum a réalisé des progrès significatifs à cet égard. Actuellement, les transactions envoyées par les utilisateurs sur L1 peuvent généralement être confirmées en 5 à 20 secondes, ce qui est comparable à l'expérience de paiement par carte de crédit. Cependant, il reste utile de réduire davantage le temps de confirmation, certaines applications nécessitant même des délais de l'ordre de la milliseconde. Cet article explorera certaines options viables pour Ethereum à cet égard.

Aperçu des solutions existantes

finalité à slot unique

Actuellement, le consensus Gasper d'Ethereum adopte une architecture de slots et d'époques. Un slot toutes les 12 secondes, les validateurs votent sur la tête de la chaîne, et tous les validateurs ont la possibilité de voter une fois dans 32 slots (6,4 minutes). Ces votes sont interprétés comme des messages similaires à l'algorithme de consensus PBFT, fournissant une finalité avec de fortes garanties économiques après deux époques (12,8 minutes).

Cependant, cette méthode présente des problèmes de complexité et de durée excessive. La finalité à slot unique (SSF) remplace cette architecture par un mécanisme similaire à Tendermint, permettant de finaliser le bloc N avant la génération du bloc N+1. Le SSF conserve le mécanisme de "fuite inactive", permettant à la chaîne de continuer à fonctionner lorsque plus d'1/3 des validateurs sont hors ligne.

Le principal défi du SSF est que chaque staker doit publier deux messages toutes les 12 secondes, ce qui impose une charge considérable à la chaîne. Bien qu'il existe certaines solutions d'atténuation, comme la proposition Orbit SSF, les utilisateurs doivent néanmoins attendre entre 5 et 20 secondes.

Pré-confirmation Rollup

Ethereum adopte une feuille de route centrée sur les rollups, L1 fournissant la disponibilité des données et d'autres fonctionnalités, tandis que les protocoles L2 offrent des services à plus grande échelle aux utilisateurs sur cette base. Cela a conduit à une séparation des points de concentration : L1 se concentre sur la résistance à la censure, la fiabilité et les fonctionnalités de base, tandis que L2 s'adresse directement aux besoins des utilisateurs.

Théoriquement, les L2 peuvent créer leur propre réseau de "classificateurs décentralisés", signant des blocs toutes les quelques centaines de millisecondes. Mais cela exige que les L2 effectuent un travail presque identique à celui de la création d'un nouveau L1, ce qui ralentit les progrès. Par conséquent, certains ont proposé de faire en sorte que tous les L2 partagent un mécanisme de pré-confirmation à l'intérieur de l'Éther : la pré-confirmation de base.

Préconfirmation de base

La pré-confirmation de base utilise la complexité des proposeurs d'Ethereum pour les inciter à fournir des services de pré-confirmation. Les utilisateurs peuvent payer des frais supplémentaires pour obtenir une garantie instantanée que la transaction sera incluse dans le prochain bloc. Si le proposeur ne respecte pas son engagement, il sera sanctionné. Ce mécanisme s'applique non seulement aux transactions L1, mais également aux blocs L2 basés sur des rollups.

Directions possibles pour l'avenir

Supposons qu'une finalité à un seul slot soit réalisée, en utilisant une technologie similaire à Orbit pour réduire le nombre de validateurs signant chaque slot, tout en abaissant le seuil de mise. La durée du slot pourrait augmenter à 16 secondes, combinée à une préconfirmation de rollup ou à une préconfirmation de base pour offrir aux utilisateurs une confirmation plus rapide. Cela forme en réalité une architecture epoch-slot.

La raison pour laquelle cette architecture est difficile à éviter est que parvenir à un accord approximatif prend moins de temps que d'atteindre un "finalité économique" maximale. Les facteurs influents incluent le nombre de nœuds et la "qualité" des nœuds. Si nous pouvons nous fier à un sous-ensemble de nœuds spécialisés pour parvenir à un accord approximatif, tout en utilisant un ensemble de validateurs complet pour déterminer la finalité, nous pourrions réduire le temps de confirmation à environ 2 secondes.

Par conséquent, il est précieux d'explorer l'espace de conception de l'architecture epoch-slot avec une séparation des préoccupations plus forte.

Choix de stratégie L2

Il existe actuellement trois stratégies raisonnables pour L2 :

1. Techniquement et spirituellement "basé" sur Ethereum, optimisant ses attributs techniques et ses valeurs.
2. Devenir un "serveur avec échafaudage blockchain", combinant l'efficacité des serveurs et la sécurité de la blockchain.
3. Méthode de compromis : la chaîne rapide associée à Ethereum offre une interopérabilité et une sécurité supplémentaires.

Pour certaines applications, un temps de bloc de 12 secondes est suffisant. Pour d'autres applications, la seule solution est l'architecture epoch-slot. La question clé est de savoir à quel point l'architecture epoch-slot native d'Ethereum peut être performante, ce qui influencera la signification des autres solutions.

Actuellement, nous sommes encore loin des réponses finales à ces questions. Le degré de complexité des proposeurs de blocs reste incertain. De nouvelles conceptions comme Orbit SSF offrent de l'espace pour explorer davantage de possibilités. Plus nous avons d'options, mieux nous pouvons servir les utilisateurs L1 et L2 et simplifier le travail des développeurs L2.