Explorer des solutions pratiques pour améliorer la vitesse de confirmation des transactions sur Ethereum
Ethereum a réalisé des progrès significatifs en matière de vitesse de confirmation des transactions ces dernières années. Actuellement, les transactions envoyées par les utilisateurs sur L1 peuvent généralement être confirmées en 5 à 20 secondes, ce qui équivaut à l'expérience de paiement par carte de crédit. Cependant, il est encore nécessaire d'améliorer l'expérience utilisateur, certaines applications nécessitant même de réduire le délai à quelques centaines de millisecondes. Cet article examinera certaines options viables pour améliorer le temps de confirmation des transactions sur Ethereum.
Aperçu des technologies et des idées existantes
finalité de slot unique
Le mécanisme de consensus Gasper actuellement utilisé par Ethereum adopte une architecture à un seul slot et Epoch. Chaque slot dure 12 secondes, et certains validateurs votent sur l'état de la chaîne. Dans les 32 slots (6,4 minutes), tous les validateurs ont l'occasion de voter une fois. Ces votes sont ensuite interprétés comme des messages similaires à ceux de l'algorithme de consensus PBFT, et après deux Epochs (12,8 minutes), ils fournissent une garantie économique forte appelée finalité.
Cependant, cette méthode présente deux problèmes majeurs : une complexité élevée et un temps de confirmation final de 12,8 minutes trop long. Pour résoudre ces problèmes, la finalité à un seul slot (Single Slot Finality, SSF) a proposé un mécanisme similaire au consensus Tendermint, qui consiste à finaliser le bloc actuel avant de générer le bloc suivant.
Le principal défi du SSF réside dans le fait que chaque staker doit publier deux messages toutes les 12 secondes, ce qui impose une énorme charge au réseau. Bien qu'il existe quelques idées innovantes, comme la proposition Orbit SSF, qui tentent d'atténuer ce problème, les utilisateurs doivent toujours attendre de 5 à 20 secondes pour confirmer une transaction.
Pré-confirmation de Rollup
Avec l'adoption d'une approche centrée sur les rollups par Ethereum, les protocoles L2 (tels que les rollups, validiums et plasmas) peuvent offrir aux utilisateurs des services à grande échelle avec une sécurité équivalente à celle d'Ethereum. Cela a conduit à une répartition des responsabilités au sein de l'écosystème Ethereum : L1 se concentre sur la résistance à la censure, la fiabilité et la maintenance et l'amélioration des fonctionnalités de base, tandis que L2 s'efforce de répondre directement aux besoins des utilisateurs grâce à différentes technologies et cultures.
Théoriquement, les L2 peuvent créer leur propre réseau de "classificateurs décentralisés", où un petit groupe de validateurs signe les blocs toutes les quelques centaines de millisecondes, en utilisant leurs actifs stakés comme garantie. Ces en-têtes de blocs L2 seront finalement publiés sur L1.
Cependant, demander à tous les L2 d'établir un réseau de tri décentralisé semble peu réaliste, ce qui revient à demander aux rollups 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) partagent un mécanisme de pré-confirmation à l'échelle d'Ethereum : la pré-confirmation de base.
Pré-confirmation de base
La méthode de pré-confirmation de base suppose que les proposeurs d'Ethereum sont des participants hautement qualifiés. Cette méthode utilise leur expertise en incitant ces proposeurs à accepter la responsabilité de fournir des services de pré-confirmation.
L'idée centrale est de créer un protocole standardisé, où les utilisateurs peuvent payer 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 le résultat de l'exécution de la transaction. Si le proposeur ne respecte pas son engagement, il sera sanctionné.
Ce mécanisme s'applique non seulement aux transactions L1, mais pour les rollups "basés sur" Ethereum, tous les blocs L2 sont essentiellement des transactions L1, donc le même mécanisme peut également fournir des services de pré-confirmation pour n'importe quel L2.
Direction de développement futur
Supposons que nous ayons réalisé une finalité à un seul slot, et que nous utilisions une technologie similaire à Orbit pour réduire le nombre de validateurs par slot, tout en maintenant un niveau de décentralisation suffisant pour abaisser le seuil de mise. La durée des slots pourrait augmenter à 16 secondes, puis nous pourrions utiliser des pré-confirmations de rollup ou des pré-confirmations de base pour offrir des confirmations plus rapides aux utilisateurs. Ainsi, nous obtenons finalement une architecture epoch-slot.
Cette architecture est difficile à éviter principalement parce que le temps nécessaire pour parvenir à un consensus approximatif sur une certaine question est bien inférieur au temps requis pour atteindre un "caractère économique final" maximal. Les principales raisons incluent :
"Consensus approximatif" nécessite la participation d'un petit nombre de nœuds, tandis que la finalité économique nécessite la participation de la majorité des nœuds.
Une fois que le nombre de nœuds dépasse une certaine échelle, le temps nécessaire pour collecter les signatures augmente de manière significative.
Ainsi, l'architecture epoch-and-slot semble être la bonne direction de développement, mais les différentes méthodes de mise en œuvre peuvent avoir des effets variés. Il vaut la peine d'explorer davantage la possibilité d'établir une séparation plus forte des préoccupations entre les deux mécanismes, plutôt que d'être étroitement couplés comme avec Gasper.
Stratégie de développement de L2
Pour L2, il existe actuellement trois stratégies de développement raisonnables :
Sur le plan technique et conceptuel, "basé sur" Ethereum, optimisant ses caractéristiques techniques fondamentales et ses valeurs.
Devenir un "serveur avec une structure en blockchain", en tirant pleinement parti de l'efficacité des serveurs centralisés, tout en garantissant la sécurité et la décentralisation grâce à l'intégration d'éléments de blockchain.
Solution de compromis : établir une chaîne rapide avec environ une centaine de nœuds, tout en utilisant Ethereum pour fournir une interopérabilité et une sécurité supplémentaires.
Pour différents scénarios d'application, ces trois stratégies ont chacune leurs avantages. Une question clé est de savoir dans quelle mesure nous pouvons optimiser l'architecture epoch-and-slot native d'Ethereum. Si nous pouvons réduire le temps de slot à 1 seconde, alors l'espace de la troisième stratégie pourrait être considérablement réduit.
Actuellement, nous sommes encore loin des réponses finales à ces questions. La complexité des proposeurs de blocs, le potentiel de nouvelles conceptions comme Orbit SSF, et d'autres facteurs présentent une grande incertitude. Poursuivre l'exploration et l'amélioration de ces solutions contribuera à offrir une meilleure expérience aux utilisateurs de L1 et L2, tout en simplifiant le travail des développeurs de L2.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
15 J'aime
Récompense
15
4
Reposter
Partager
Commentaire
0/400
NotAFinancialAdvice
· Il y a 6h
Il faut encore accélérer le tps.
Voir l'originalRépondre0
BugBountyHunter
· Il y a 6h
La vitesse de transaction n'est toujours pas assez rapide.
Voir l'originalRépondre0
AirdropF5Bro
· Il y a 6h
Pas de tendance, donc airdrop agressif.
Voir l'originalRépondre0
pvt_key_collector
· Il y a 6h
À quoi bon aller vite ? D'abord, il faut survivre.
Discussion sur les solutions d'accélération d'Ethereum : finalité à un seul slot, pré-confirmation Rollup et pré-confirmation de base
Explorer des solutions pratiques pour améliorer la vitesse de confirmation des transactions sur Ethereum
Ethereum a réalisé des progrès significatifs en matière de vitesse de confirmation des transactions ces dernières années. Actuellement, les transactions envoyées par les utilisateurs sur L1 peuvent généralement être confirmées en 5 à 20 secondes, ce qui équivaut à l'expérience de paiement par carte de crédit. Cependant, il est encore nécessaire d'améliorer l'expérience utilisateur, certaines applications nécessitant même de réduire le délai à quelques centaines de millisecondes. Cet article examinera certaines options viables pour améliorer le temps de confirmation des transactions sur Ethereum.
Aperçu des technologies et des idées existantes
finalité de slot unique
Le mécanisme de consensus Gasper actuellement utilisé par Ethereum adopte une architecture à un seul slot et Epoch. Chaque slot dure 12 secondes, et certains validateurs votent sur l'état de la chaîne. Dans les 32 slots (6,4 minutes), tous les validateurs ont l'occasion de voter une fois. Ces votes sont ensuite interprétés comme des messages similaires à ceux de l'algorithme de consensus PBFT, et après deux Epochs (12,8 minutes), ils fournissent une garantie économique forte appelée finalité.
Cependant, cette méthode présente deux problèmes majeurs : une complexité élevée et un temps de confirmation final de 12,8 minutes trop long. Pour résoudre ces problèmes, la finalité à un seul slot (Single Slot Finality, SSF) a proposé un mécanisme similaire au consensus Tendermint, qui consiste à finaliser le bloc actuel avant de générer le bloc suivant.
Le principal défi du SSF réside dans le fait que chaque staker doit publier deux messages toutes les 12 secondes, ce qui impose une énorme charge au réseau. Bien qu'il existe quelques idées innovantes, comme la proposition Orbit SSF, qui tentent d'atténuer ce problème, les utilisateurs doivent toujours attendre de 5 à 20 secondes pour confirmer une transaction.
Pré-confirmation de Rollup
Avec l'adoption d'une approche centrée sur les rollups par Ethereum, les protocoles L2 (tels que les rollups, validiums et plasmas) peuvent offrir aux utilisateurs des services à grande échelle avec une sécurité équivalente à celle d'Ethereum. Cela a conduit à une répartition des responsabilités au sein de l'écosystème Ethereum : L1 se concentre sur la résistance à la censure, la fiabilité et la maintenance et l'amélioration des fonctionnalités de base, tandis que L2 s'efforce de répondre directement aux besoins des utilisateurs grâce à différentes technologies et cultures.
Théoriquement, les L2 peuvent créer leur propre réseau de "classificateurs décentralisés", où un petit groupe de validateurs signe les blocs toutes les quelques centaines de millisecondes, en utilisant leurs actifs stakés comme garantie. Ces en-têtes de blocs L2 seront finalement publiés sur L1.
Cependant, demander à tous les L2 d'établir un réseau de tri décentralisé semble peu réaliste, ce qui revient à demander aux rollups 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) partagent un mécanisme de pré-confirmation à l'échelle d'Ethereum : la pré-confirmation de base.
Pré-confirmation de base
La méthode de pré-confirmation de base suppose que les proposeurs d'Ethereum sont des participants hautement qualifiés. Cette méthode utilise leur expertise en incitant ces proposeurs à accepter la responsabilité de fournir des services de pré-confirmation.
L'idée centrale est de créer un protocole standardisé, où les utilisateurs peuvent payer 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 le résultat de l'exécution de la transaction. Si le proposeur ne respecte pas son engagement, il sera sanctionné.
Ce mécanisme s'applique non seulement aux transactions L1, mais pour les rollups "basés sur" Ethereum, tous les blocs L2 sont essentiellement des transactions L1, donc le même mécanisme peut également fournir des services de pré-confirmation pour n'importe quel L2.
Direction de développement futur
Supposons que nous ayons réalisé une finalité à un seul slot, et que nous utilisions une technologie similaire à Orbit pour réduire le nombre de validateurs par slot, tout en maintenant un niveau de décentralisation suffisant pour abaisser le seuil de mise. La durée des slots pourrait augmenter à 16 secondes, puis nous pourrions utiliser des pré-confirmations de rollup ou des pré-confirmations de base pour offrir des confirmations plus rapides aux utilisateurs. Ainsi, nous obtenons finalement une architecture epoch-slot.
Cette architecture est difficile à éviter principalement parce que le temps nécessaire pour parvenir à un consensus approximatif sur une certaine question est bien inférieur au temps requis pour atteindre un "caractère économique final" maximal. Les principales raisons incluent :
Ainsi, l'architecture epoch-and-slot semble être la bonne direction de développement, mais les différentes méthodes de mise en œuvre peuvent avoir des effets variés. Il vaut la peine d'explorer davantage la possibilité d'établir une séparation plus forte des préoccupations entre les deux mécanismes, plutôt que d'être étroitement couplés comme avec Gasper.
Stratégie de développement de L2
Pour L2, il existe actuellement trois stratégies de développement raisonnables :
Pour différents scénarios d'application, ces trois stratégies ont chacune leurs avantages. Une question clé est de savoir dans quelle mesure nous pouvons optimiser l'architecture epoch-and-slot native d'Ethereum. Si nous pouvons réduire le temps de slot à 1 seconde, alors l'espace de la troisième stratégie pourrait être considérablement réduit.
Actuellement, nous sommes encore loin des réponses finales à ces questions. La complexité des proposeurs de blocs, le potentiel de nouvelles conceptions comme Orbit SSF, et d'autres facteurs présentent une grande incertitude. Poursuivre l'exploration et l'amélioration de ces solutions contribuera à offrir une meilleure expérience aux utilisateurs de L1 et L2, tout en simplifiant le travail des développeurs de L2.