Discussion sur les solutions d'optimisation de la vitesse de confirmation des transactions Ethereum
Dans l'expérience utilisateur de la blockchain, le temps de confirmation des transactions est un facteur clé. Ethereum a réduit le temps de confirmation des transactions à 5-20 secondes au cours des dernières années grâce à des mesures telles que l'EIP-1559 et la transition vers le PoS, ce qui est comparable aux paiements par carte de crédit. Cependant, il reste utile de réduire encore le temps de confirmation, certaines applications nécessitant même des délais de l'ordre de la sous-seconde. Cet article explorera les solutions possibles pour optimiser davantage le temps de confirmation des transactions sur Ethereum.
Aperçu de la technologie existante
finalité single-slot
Actuellement, Ethereum utilise le mécanisme de consensus Gasper, avec un créneau toutes les 12 secondes, et 32 créneaux composent un Epoch. Les validateurs votent sur le sommet de la chaîne, et la finalité est atteinte après deux Epochs. Ce mécanisme présente des problèmes tels qu'une complexité élevée et un temps de finalité long (12.8 minutes).
La finalité à un seul emplacement (SSF) est similaire au consensus Tendermint, chaque bloc peut atteindre la finalité avant la génération du bloc suivant. Le principal défi est la charge importante sur le réseau, nécessitant que chaque validateur publie deux messages toutes les 12 secondes. Bien qu'il existe quelques solutions d'optimisation comme Orbit SSF, les utilisateurs doivent toujours attendre 5 à 20 secondes pour confirmer une transaction.
Pré-confirmation de Rollup
Ethereum adopte une approche d'évolutivité centrée sur les rollups. Les solutions L2 doivent fournir aux utilisateurs des confirmations plus rapides. En théorie, L2 peut établir son propre réseau de "classificateurs décentralisés", signant des blocs toutes les quelques centaines de millisecondes. Mais cela exige que L2 effectue un travail presque identique à celui de la création d'un nouveau L1, ce qui ralentit réellement les progrès.
Préconfirmation de base
Cette solution utilise la complexité des proposeurs de blocs d'Ethereum pour les inciter à fournir des services de pré-confirmation. Les utilisateurs peuvent payer des frais supplémentaires pour obtenir une garantie immédiate que leurs transactions seront incluses dans le prochain bloc. Si le proposeur ne respecte pas son engagement, il sera puni. Ce mécanisme peut offrir des pré-confirmations pour les L1 et les L2 basés sur Ethereum.
Solutions d'architecture possibles
Supposons que la finalité à un seul slot soit réalisée, et que nous utilisions une technologie similaire à Orbit pour réduire le nombre de validateurs de signature par slot, tout en utilisant des pré-confirmations par rollup ou des pré-confirmations de base pour fournir une confirmation plus rapide. Finalement, nous obtenons une architecture epoch-slot :
Époque : 16 secondes, garantie par le mécanisme de finalité à un seul slot
Slot: environ 2 secondes, atteint un consensus approximatif par un sous-ensemble de nœuds spécialisés
Cette architecture peut équilibrer les besoins de décentralisation, de finalité et de confirmation rapide. L2 peut adopter les stratégies suivantes :
Entièrement basé sur Ethereum, optimisation des attributs et des valeurs de la couche de base
Semblable à "serveur avec échafaudage blockchain", tout en préservant l'efficacité du serveur tout en obtenant les avantages de la chaîne.
Compromis : une chaîne rapide avec environ 100 nœuds, dotée d'une sécurité supplémentaire fournie par Ethereum.
Pour différents scénarios d'application, vous pouvez choisir différents mécanismes de slot :
Architecture epoch-slot native à Ethereum
Préconfirmation du serveur
Préconfirmation du comité
Si l'architecture native d'Ethereum peut réduire le temps de slot à 1 seconde, la signification de la troisième solution diminuera. Mais les données hors chaîne L2( comme les plasmas et les validiums) nécessitent toujours la deuxième solution.
Nous avons encore un certain chemin à parcourir avant d'arriver à la solution finale. Les questions clés comprennent la complexité des proposeurs de blocs, le potentiel de nouveaux designs comme Orbit SSF, etc. Explorer davantage d'options aide à améliorer l'expérience utilisateur de L1 et L2, et à simplifier le développement 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.
17 J'aime
Récompense
17
4
Partager
Commentaire
0/400
LazyDevMiner
· 08-05 12:26
On s'en fiche si ça prend une ou deux secondes de plus.
Voir l'originalRépondre0
ValidatorVibes
· 08-05 12:18
j'ai passé la nuit à réfléchir... ssf pourrait être cool mais qu'en est-il des récompenses des validateurs ?
Voir l'originalRépondre0
AirdropHunterWang
· 08-05 12:17
Dépêche-toi, fais vite, c'est trop lent.
Voir l'originalRépondre0
OnchainGossiper
· 08-05 12:08
Ce n'est qu'une question de modifier le mécanisme de consensus, pourquoi être si pressé ?
Optimisation de la vitesse de confirmation des transactions Ethereum : exploration des solutions de latence sub-seconde
Discussion sur les solutions d'optimisation de la vitesse de confirmation des transactions Ethereum
Dans l'expérience utilisateur de la blockchain, le temps de confirmation des transactions est un facteur clé. Ethereum a réduit le temps de confirmation des transactions à 5-20 secondes au cours des dernières années grâce à des mesures telles que l'EIP-1559 et la transition vers le PoS, ce qui est comparable aux paiements par carte de crédit. Cependant, il reste utile de réduire encore le temps de confirmation, certaines applications nécessitant même des délais de l'ordre de la sous-seconde. Cet article explorera les solutions possibles pour optimiser davantage le temps de confirmation des transactions sur Ethereum.
Aperçu de la technologie existante
finalité single-slot
Actuellement, Ethereum utilise le mécanisme de consensus Gasper, avec un créneau toutes les 12 secondes, et 32 créneaux composent un Epoch. Les validateurs votent sur le sommet de la chaîne, et la finalité est atteinte après deux Epochs. Ce mécanisme présente des problèmes tels qu'une complexité élevée et un temps de finalité long (12.8 minutes).
La finalité à un seul emplacement (SSF) est similaire au consensus Tendermint, chaque bloc peut atteindre la finalité avant la génération du bloc suivant. Le principal défi est la charge importante sur le réseau, nécessitant que chaque validateur publie deux messages toutes les 12 secondes. Bien qu'il existe quelques solutions d'optimisation comme Orbit SSF, les utilisateurs doivent toujours attendre 5 à 20 secondes pour confirmer une transaction.
Pré-confirmation de Rollup
Ethereum adopte une approche d'évolutivité centrée sur les rollups. Les solutions L2 doivent fournir aux utilisateurs des confirmations plus rapides. En théorie, L2 peut établir son propre réseau de "classificateurs décentralisés", signant des blocs toutes les quelques centaines de millisecondes. Mais cela exige que L2 effectue un travail presque identique à celui de la création d'un nouveau L1, ce qui ralentit réellement les progrès.
Préconfirmation de base
Cette solution utilise la complexité des proposeurs de blocs d'Ethereum pour les inciter à fournir des services de pré-confirmation. Les utilisateurs peuvent payer des frais supplémentaires pour obtenir une garantie immédiate que leurs transactions seront incluses dans le prochain bloc. Si le proposeur ne respecte pas son engagement, il sera puni. Ce mécanisme peut offrir des pré-confirmations pour les L1 et les L2 basés sur Ethereum.
Solutions d'architecture possibles
Supposons que la finalité à un seul slot soit réalisée, et que nous utilisions une technologie similaire à Orbit pour réduire le nombre de validateurs de signature par slot, tout en utilisant des pré-confirmations par rollup ou des pré-confirmations de base pour fournir une confirmation plus rapide. Finalement, nous obtenons une architecture epoch-slot :
Cette architecture peut équilibrer les besoins de décentralisation, de finalité et de confirmation rapide. L2 peut adopter les stratégies suivantes :
Pour différents scénarios d'application, vous pouvez choisir différents mécanismes de slot :
Si l'architecture native d'Ethereum peut réduire le temps de slot à 1 seconde, la signification de la troisième solution diminuera. Mais les données hors chaîne L2( comme les plasmas et les validiums) nécessitent toujours la deuxième solution.
Nous avons encore un certain chemin à parcourir avant d'arriver à la solution finale. Les questions clés comprennent la complexité des proposeurs de blocs, le potentiel de nouveaux designs comme Orbit SSF, etc. Explorer davantage d'options aide à améliorer l'expérience utilisateur de L1 et L2, et à simplifier le développement de L2.