Explorer des solutions viables pour améliorer la vitesse de confirmation des transactions sur Ethereum

Un facteur clé de l'expérience utilisateur de la blockchain est le temps de confirmation des transactions. Ethereum a déjà fait des progrès significatifs à cet égard, les transactions sur L1 étant généralement confirmées en 5 à 20 secondes, ce qui est comparable aux paiements par carte de crédit. Cependant, il reste encore de la valeur à réduire davantage le temps de confirmation, certaines applications nécessitant même des délais de sous-seconde. Cet article explorera plusieurs options possibles pour améliorer le temps de confirmation des transactions sur Ethereum.

Aperçu de la technologie existante

finalité de slot unique

Le mécanisme de consensus Gasper d'Ethereum utilise une structure de créneaux et de cycles, avec un créneau toutes les 12 secondes, et 32 créneaux formant un cycle. Les validateurs votent sur la tête de la chaîne à chaque créneau, atteignant la finalité après deux cycles. Cette méthode présente des problèmes de complexité, et le temps de confirmation final de 12,8 minutes est trop long.

La proposition de finalité de slot unique (SSF) adopte un mécanisme similaire à celui de Tendermint, où chaque bloc peut atteindre la finalité avant la génération du bloc suivant. Cependant, cela exige que chaque validateurs publie deux messages toutes les 12 secondes, ce qui impose une charge importante au réseau. Bien qu'il existe certaines solutions d'optimisation, comme Orbit SSF, les utilisateurs doivent encore attendre entre 5 et 20 secondes pour confirmer une transaction.

Pré-confirmation de Rollup

Ethereum adopte une feuille de route centrée sur les rollups, où les protocoles L2 peuvent offrir des temps de confirmation plus rapides aux utilisateurs. En théorie, les L2 peuvent établir leur propre réseau de séquenceurs décentralisés, signant des blocs toutes les quelques centaines de millisecondes. Mais cela représente un énorme travail pour les L2.

Pré-confirmation de base

La pré-confirmation de base utilise la complexité des proposeurs d'Ethereum pour créer un protocole standardisé, permettant aux utilisateurs de payer des frais supplémentaires pour obtenir une garantie instantanée que leur transaction sera incluse dans le prochain bloc. Si le proposeur ne respecte pas son engagement, il sera sanctionné. Ce mécanisme peut fournir des pré-confirmations pour les transactions L1 et L2.

Architecture possible dans le futur

Supposons que la finalité à un seul slot soit réalisée et que le nombre de validateurs par slot soit réduit à l'aide de technologies similaires à Orbit, tout en prolongeant le temps des slots à 16 secondes. En combinant des pré-confirmations de rollup ou des pré-confirmations de base, nous pourrions obtenir une nouvelle architecture d'epoch-slot.

Cette architecture reflète une raison philosophique profonde : le temps nécessaire pour parvenir à un consensus approximatif est inférieur à celui requis pour atteindre le "finalité économique" maximale. Cela est principalement dû aux différences de nombre de nœuds et de "qualité" des nœuds.

Choix de stratégie pour L2

L2 a actuellement trois stratégies principales :

1. Entièrement basé sur la technologie et les valeurs d'Ethereum
2. En tant que "serveur avec échafaudage blockchain"
3. Solution de compromis : une chaîne rapide avec environ 100 nœuds, bénéficiant d'une sécurité supplémentaire grâce à Ethereum.

Pour différents scénarios d'application, ces trois stratégies ont chacune leurs avantages. La question clé est de savoir à quel point l'architecture d'epoch-and-slot native d'Ethereum peut être efficace, en particulier si le temps de slot peut être réduit à 1 seconde, alors l'espace pour la troisième stratégie sera considérablement réduit.

Conclusion

Actuellement, nous sommes encore loin des réponses finales à ces questions. La complexité des proposeurs de blocs reste incertaine. De nouveaux designs comme Orbit SSF offrent plus de possibilités pour l'architecture epoch-and-slot. Explorer davantage d'options peut non seulement améliorer l'expérience des utilisateurs L1 et L2, mais aussi simplifier le travail des développeurs L2.