Optimisation du temps de confirmation des transactions Ethereum : explorer une expérience utilisateur plus rapide
L'un des points clés de l'expérience utilisateur sur la blockchain est la vitesse de confirmation des transactions. Ces dernières années, Ethereum a réalisé des progrès significatifs à cet égard. Actuellement, les transactions sur L1 peuvent généralement être confirmées en 5 à 20 secondes, ce qui est à peu près équivalent aux paiements par carte de crédit. Cependant, il est toujours précieux d'améliorer davantage l'expérience utilisateur, certaines applications nécessitant même un temps de réponse inférieur à une seconde. Cet article discutera de plusieurs solutions viables pour améliorer la vitesse de confirmation des transactions sur Ethereum.
Aperçu de la technologie existante
finalité unique
Le mécanisme de consensus Gasper actuellement utilisé par Ethereum est basé sur une structure de slots et d'époques. Un slot toutes les 12 secondes, certains validateurs votent sur le bloc de tête de la chaîne. Après 32 slots (6,4 minutes), tous les validateurs ont la possibilité de voter une fois. Ces votes sont interprétés comme des messages dans un algorithme de consensus de type PBFT, offrant une finalité forte avec des garanties économiques après deux époques (12,8 minutes).
Cette méthode présente deux problèmes principaux : une complexité élevée et un temps de confirmation final de 12,8 minutes qui est trop long. La finalité à un seul slot (SSF) remplace l'architecture existante 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 inactif", permettant à la chaîne de continuer à fonctionner et de se rétablir même si plus d'un tiers des validateurs sont hors ligne.
Le principal défi du SSF est d'exiger que tous les stakers publient deux messages toutes les 12 secondes, ce qui représente une charge importante pour le réseau. Bien qu'il existe certaines solutions d'atténuation, comme l'Orbit SSF récemment proposé, les utilisateurs doivent toujours attendre de 5 à 20 secondes pour confirmer une transaction.
Préconfirmation de Rollup
Ethereum a récemment adopté une approche de développement centrée sur les rollups, où le L1 fournit des fonctionnalités de base telles que la disponibilité des données pour les protocoles L2. Cela a conduit à une séparation des points d'attention : le L1 se concentre sur la résistance à la censure, la fiabilité et l'amélioration des fonctionnalités de base, tandis que le L2 s'adresse plus directement aux besoins des utilisateurs.
Théoriquement, la création d'un réseau d'ordonnanceur décentralisé est de la responsabilité de L2. Un petit groupe de validateurs peut signer des blocs toutes les quelques centaines de millisecondes et miser des actifs comme garantie. Ces en-têtes de blocs L2 seront finalement publiés sur L1.
Cependant, il semble peu raisonnable d'exiger que tous les L2 mettent en œuvre un tri décentralisé, ce qui équivaut à créer un tout nouveau L1. Par conséquent, l'idée a été proposée de faire en sorte que tous les L2 (et même L1) partagent un mécanisme de pré-confirmation : la pré-confirmation de base.
Préconfirmation de base
La préconfirmation de base utilise la complexité des proposeurs d'Ethereum pour les inciter à assumer la responsabilité de 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 un proposeur ne respecte pas son engagement, il sera puni.
Ce mécanisme s'applique non seulement aux transactions L1, mais également aux rollups "basés sur" Ethereum, où tous les blocs L2 sont en essence des transactions L1, et peuvent donc bénéficier des mêmes services de pré-confirmation.
Perspectives d'avenir
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 augmentant la durée du slot à 16 secondes. En combinant la pré-confirmation de rollup ou la pré-confirmation de base, nous pouvons offrir aux utilisateurs une expérience de confirmation plus rapide. Cette architecture peut être appelée structure "époque-slot".
L'émergence de cette structure a des raisons profondes : le temps nécessaire pour parvenir à un consensus approximatif sur une question est généralement inférieur au temps nécessaire pour atteindre le "finalité économique" maximale. Les facteurs influents incluent le nombre de nœuds participants et la "qualité" des nœuds.
Pour L2, il existe actuellement trois stratégies viables :
Sur le plan technique et conceptuel, entièrement "basé" sur Ethereum, cela peut être considéré comme un "fragment de marque" ou une innovation technologique plus audacieuse.
En tant que "serveur avec échafaudage blockchain", combinant des technologies telles que la preuve de validité STARK, tout en préservant l'efficacité du serveur et en obtenant les principaux avantages de la chaîne.
Solution de compromis : établir une chaîne rapide composée d'environ cent nœuds, s'appuyant sur Ethereum pour fournir une interopérabilité et une sécurité supplémentaires.
Pour différents cas d'application, un temps de bloc de 12 secondes peut être suffisant. Pour les applications nécessitant des confirmations plus rapides, l'architecture "Époque - Fente" semble être la seule solution. La clé réside dans la mesure dans laquelle nous pouvons optimiser cette architecture, en particulier si nous pouvons réduire le temps de fente à 1 seconde, alors l'attrait de la troisième stratégie sera considérablement réduit.
Actuellement, nous sommes encore loin des réponses finales à ces questions. La complexité des proposeurs de blocs reste encore très incertaine. De nouveaux designs tels qu'Orbit SSF offrent des opportunités pour une exploration plus approfondie. Plus nous avons d'options, mieux nous pouvons servir les utilisateurs de L1 et de 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.
16 J'aime
Récompense
16
4
Partager
Commentaire
0/400
GasFeeCryer
· Il y a 1h
Cette fois, les frais de gas vont enfin être moins chers.
Accélération de la confirmation des transactions Ethereum : exploration de la finalité en un seul bloc à un mécanisme de pré-confirmation
Optimisation du temps de confirmation des transactions Ethereum : explorer une expérience utilisateur plus rapide
L'un des points clés de l'expérience utilisateur sur la blockchain est la vitesse de confirmation des transactions. Ces dernières années, Ethereum a réalisé des progrès significatifs à cet égard. Actuellement, les transactions sur L1 peuvent généralement être confirmées en 5 à 20 secondes, ce qui est à peu près équivalent aux paiements par carte de crédit. Cependant, il est toujours précieux d'améliorer davantage l'expérience utilisateur, certaines applications nécessitant même un temps de réponse inférieur à une seconde. Cet article discutera de plusieurs solutions viables pour améliorer la vitesse de confirmation des transactions sur Ethereum.
Aperçu de la technologie existante
finalité unique
Le mécanisme de consensus Gasper actuellement utilisé par Ethereum est basé sur une structure de slots et d'époques. Un slot toutes les 12 secondes, certains validateurs votent sur le bloc de tête de la chaîne. Après 32 slots (6,4 minutes), tous les validateurs ont la possibilité de voter une fois. Ces votes sont interprétés comme des messages dans un algorithme de consensus de type PBFT, offrant une finalité forte avec des garanties économiques après deux époques (12,8 minutes).
Cette méthode présente deux problèmes principaux : une complexité élevée et un temps de confirmation final de 12,8 minutes qui est trop long. La finalité à un seul slot (SSF) remplace l'architecture existante 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 inactif", permettant à la chaîne de continuer à fonctionner et de se rétablir même si plus d'un tiers des validateurs sont hors ligne.
Le principal défi du SSF est d'exiger que tous les stakers publient deux messages toutes les 12 secondes, ce qui représente une charge importante pour le réseau. Bien qu'il existe certaines solutions d'atténuation, comme l'Orbit SSF récemment proposé, les utilisateurs doivent toujours attendre de 5 à 20 secondes pour confirmer une transaction.
Préconfirmation de Rollup
Ethereum a récemment adopté une approche de développement centrée sur les rollups, où le L1 fournit des fonctionnalités de base telles que la disponibilité des données pour les protocoles L2. Cela a conduit à une séparation des points d'attention : le L1 se concentre sur la résistance à la censure, la fiabilité et l'amélioration des fonctionnalités de base, tandis que le L2 s'adresse plus directement aux besoins des utilisateurs.
Théoriquement, la création d'un réseau d'ordonnanceur décentralisé est de la responsabilité de L2. Un petit groupe de validateurs peut signer des blocs toutes les quelques centaines de millisecondes et miser des actifs comme garantie. Ces en-têtes de blocs L2 seront finalement publiés sur L1.
Cependant, il semble peu raisonnable d'exiger que tous les L2 mettent en œuvre un tri décentralisé, ce qui équivaut à créer un tout nouveau L1. Par conséquent, l'idée a été proposée de faire en sorte que tous les L2 (et même L1) partagent un mécanisme de pré-confirmation : la pré-confirmation de base.
Préconfirmation de base
La préconfirmation de base utilise la complexité des proposeurs d'Ethereum pour les inciter à assumer la responsabilité de 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 un proposeur ne respecte pas son engagement, il sera puni.
Ce mécanisme s'applique non seulement aux transactions L1, mais également aux rollups "basés sur" Ethereum, où tous les blocs L2 sont en essence des transactions L1, et peuvent donc bénéficier des mêmes services de pré-confirmation.
Perspectives d'avenir
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 augmentant la durée du slot à 16 secondes. En combinant la pré-confirmation de rollup ou la pré-confirmation de base, nous pouvons offrir aux utilisateurs une expérience de confirmation plus rapide. Cette architecture peut être appelée structure "époque-slot".
L'émergence de cette structure a des raisons profondes : le temps nécessaire pour parvenir à un consensus approximatif sur une question est généralement inférieur au temps nécessaire pour atteindre le "finalité économique" maximale. Les facteurs influents incluent le nombre de nœuds participants et la "qualité" des nœuds.
Pour L2, il existe actuellement trois stratégies viables :
Pour différents cas d'application, un temps de bloc de 12 secondes peut être suffisant. Pour les applications nécessitant des confirmations plus rapides, l'architecture "Époque - Fente" semble être la seule solution. La clé réside dans la mesure dans laquelle nous pouvons optimiser cette architecture, en particulier si nous pouvons réduire le temps de fente à 1 seconde, alors l'attrait de la troisième stratégie sera considérablement réduit.
Actuellement, nous sommes encore loin des réponses finales à ces questions. La complexité des proposeurs de blocs reste encore très incertaine. De nouveaux designs tels qu'Orbit SSF offrent des opportunités pour une exploration plus approfondie. Plus nous avons d'options, mieux nous pouvons servir les utilisateurs de L1 et de L2, tout en simplifiant le travail des développeurs de L2.