Fournir un temps de confirmation des transactions plus rapide pour ETH, améliorant ainsi l'expérience utilisateur

Un temps de confirmation des transactions rapide est l'une des caractéristiques importantes d'une bonne expérience utilisateur sur la blockchain. Ces dernières années, Ethereum a réalisé des progrès significatifs dans ce domaine. Grâce à l'EIP-1559 et à la stabilité des temps de bloc après le passage au PoS, les transactions envoyées par les utilisateurs sur L1 peuvent généralement être confirmées en 5 à 20 secondes, ce qui est essentiellement comparable à l'expérience de paiement par carte de crédit. Cependant, il est toujours utile d'améliorer davantage l'expérience utilisateur, certaines applications exigeant même des latences inférieures à une seconde. Cet article explorera certaines options viables pour Ethereum afin d'améliorer le temps de confirmation des transactions.

Aperçu de la technologie existante

finalité unique

Actuellement, le consensus Gasper d'Ethereum adopte une architecture de slots et d'époques. Un slot toutes les 12 secondes, certains validateurs votent pour le tête de chaîne, et tous les validateurs ont l'occasion de voter une fois dans 32 slots (6,4 minutes). Ces votes sont réinterprétés comme des messages similaires à ceux de l'algorithme de consensus PBFT, et après deux époques (12,8 minutes), cela fournit une garantie économique forte appelée finalité.

Ces dernières années, cette méthode est de moins en moins populaire, pour deux raisons principales : d'abord, elle est trop complexe, il existe de nombreux problèmes d'interaction entre le mécanisme de vote par slot et le mécanisme de finalité par époque ; ensuite, le temps d'attente de 12,8 minutes est trop long.

La finalité à un seul slot (SSF) a remplacé cette architecture par un mécanisme similaire à Tendermint, où le bloc N est finalisé avant la génération du bloc N+1. La principale différence avec Tendermint est la conservation du mécanisme de "fuite inactif", qui permet à la chaîne de continuer à fonctionner et de se rétablir 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 représente une lourde charge pour la chaîne. Bien qu'il existe quelques idées innovantes comme Orbit SSF qui pourraient atténuer ce problème, les utilisateurs doivent tout de même attendre entre 5 et 20 secondes.

Préconfirmation Rollup

Ethereum a toujours suivi une feuille de route centrée sur les rollups, concevant la couche de base (L1) pour supporter la disponibilité des données et d'autres fonctionnalités à utiliser par les protocoles L2. Cela a créé une séparation des préoccupations au sein de l'écosystème : L1 se concentre sur l'anti-censure, la fiabilité et la stabilité, tandis que L2 s'adresse plus directement aux utilisateurs.

En théorie, la création d'un réseau de classeurs décentralisés est de la responsabilité de L2. Un petit groupe de validateurs peut signer des blocs toutes les quelques centaines de millisecondes et engager des actifs de mise après ces blocs. Les en-têtes de ces blocs L2 seront finalement publiés sur L1.

Cependant, exiger que tous les L2 effectuent un classement décentralisé semble un peu injuste, car cela équivaut à demander à un rollup d'accomplir un travail presque identique à celui de la création d'un tout nouveau L1. Par conséquent, il a été proposé que tous les L2 (ainsi que les L1) utilisent un mécanisme de pré-confirmation partagé dans la portée d'Ethereum : la pré-confirmation de base.

Pré-Confirmation de Base

La méthode de préconfirmation de base suppose que le proposeur Ethereum est un participant hautement complexe lié au MEV. Elle exploite cette complexité en incitant ces proposeurs à accepter la responsabilité de fournir des services de préconfirmation.

Cette méthode crée un protocole standardisé, permettant aux utilisateurs de fournir des frais supplémentaires pour obtenir une garantie instantanée que la transaction sera incluse dans le prochain bloc, ainsi qu'une déclaration sur les résultats de l'exécution de cette transaction. Si le proposeur viole ses engagements, il peut être pénalisé.

Ce mécanisme garantit non seulement les transactions L1, mais pour les rollups "basés sur", tous les blocs L2 sont des transactions L1, donc il peut également fournir une pré-confirmation pour n'importe quel L2.

Perspectives d'avenir

Supposons que la finalité de slot unique soit réalisée, en utilisant des technologies similaires à Orbit pour réduire le nombre de validateurs signant chaque slot, tout en progressant également vers une réduction du minimum de staking de 32 ETH. La durée des slots pourrait être augmentée à 16 secondes, puis en utilisant des pré-confirmations de rollup ou des pré-confirmations de base pour fournir des confirmations plus rapides aux utilisateurs. Au final, nous avons obtenu une nouvelle ère - l'architecture des slots.

Cette architecture semble inévitable, car le temps nécessaire pour parvenir à un consensus approximatif sur une chose est plus court que le temps nécessaire pour atteindre un "finalité économique" maximale. Les raisons incluent le nombre de nœuds et la "qualité" des nœuds. Si nous pouvons nous appuyer sur un sous-ensemble de nœuds spécialisés pour parvenir à un accord approximatif (tout en utilisant l'ensemble complet de validateurs pour déterminer la finalité), nous pouvons réduire le temps de confirmation à environ 2 secondes.

Ainsi, explorer l'espace de conception reste précieux, en particulier dans une direction où il y a une séparation plus forte des points d'attention entre les deux mécanismes.

Choix de stratégie L2

L2 a actuellement trois stratégies raisonnables :

1. Sur les plans technique et conceptuel, "basé sur" Ethereum, optimisant ses attributs technologiques de base et ses valeurs.
2. Devenir un "serveur avec une structure de blockchain", en tirant pleinement parti de l'efficacité des serveurs et de la sécurité de la blockchain.
3. Méthode de compromis : une chaîne rapide avec environ une centaine de nœuds, 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 époque-slot. La question clé est : à quel point l'architecture époque-slot native d'Ethereum peut-elle être efficace ? Si elle peut être réduite à un temps de slot de 1 seconde, alors l'espace pour la troisième stratégie deviendra très limité.

Actuellement, nous sommes encore loin des réponses finales à ces questions. Le degré de complexité des proposeurs de blocs reste incertain, et de nouveaux designs comme Orbit SSF méritent également d'être explorés davantage. Plus nous avons d'options, mieux nous pourrons servir les utilisateurs L1 et L2, et simplifier le travail des développeurs L2.