Accélérer la confirmation des transactions Ethereum : explorer de nouvelles solutions pour améliorer l'expérience utilisateur
Un élément clé de l'expérience utilisateur de la blockchain est le temps de confirmation des transactions rapide. Au cours des dernières années, Ethereum a réalisé des progrès significatifs à cet égard. Grâce à l'EIP-1559 et à la stabilisation des temps de bloc après le passage à la preuve d'enjeu, les transactions envoyées par les utilisateurs sur le réseau principal sont généralement confirmées dans un délai de 5 à 20 secondes, atteignant ainsi essentiellement le niveau d'expérience des paiements par carte de crédit. Cependant, il reste de la valeur à réduire davantage le temps de confirmation, certaines applications nécessitant même des délais inférieurs à une seconde. Cet article explorera plusieurs solutions viables pour améliorer le temps de confirmation des transactions sur Ethereum.
Aperçu de la technologie existante
finalité à un seul slot
Actuellement, le consensus Gasper d'Ethereum utilise une structure à deux niveaux de slots et d'époques. Un slot toutes les 12 secondes, où une partie des validateurs vote sur la tête de la chaîne, 32 slots (6,4 minutes ) tous les validateurs ont l'opportunité de voter une fois. Ces votes sont ensuite interprétés comme des messages dans l'algorithme de consensus de type PBFT, deux époques (12,8 minutes ) fournissent une finalité avec une forte garantie économique.
Ces dernières années, les limites de cette méthode sont de plus en plus évidentes. Tout d'abord, la complexité est élevée, et il existe de nombreux problèmes d'interaction entre le vote au niveau des fentes et la finalité au niveau des époques. Ensuite, le temps d'attente de 12,8 minutes est trop long, ce qui nuit à l'expérience utilisateur.
La finalité à un seul slot ( SSF ) remplace cette architecture par un mécanisme de type Tendermint, permettant la confirmation finale d'un bloc N avant la génération du bloc N+1. La principale différence avec Tendermint réside dans la conservation du mécanisme de "fuite inactive", 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 de SSF est que chaque staker doit publier deux messages toutes les 12 secondes, ce qui impose une charge considérable à la chaîne. Bien qu'il existe quelques solutions astucieuses pour atténuer ce problème, comme l'Orbit SSF récemment proposé, les utilisateurs doivent néanmoins attendre entre 5 et 20 secondes.
Pré-confirmation Rollup
Ces dernières années, Ethereum a suivi une feuille de route centrée sur les rollups, concevant la couche de base pour prendre en charge la disponibilité des données et d'autres fonctionnalités, à utiliser par les protocoles L2, afin de fournir une plus grande sécurité aux utilisateurs.
Cela a conduit à une séparation des points d'attention au sein de l'écosystème Ethereum : L1 se concentre sur la résistance à la censure, la fiabilité et l'amélioration des fonctionnalités de base, tandis que L2 sert directement les utilisateurs à travers différentes cultures et technologies. Cependant, L2 souhaite offrir aux utilisateurs des confirmations plus rapides que 5 à 20 secondes.
Théoriquement, la création d'un réseau de classificateurs 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 mettre en jeu des actifs. Les en-têtes de ces blocs L2 seront finalement publiés sur L1.
Les validateurs de L2 peuvent tricher : signer d'abord le bloc B1, puis signer le bloc B2 en conflit et le soumettre à la chaîne avant B1. Mais faire cela les exposera et ils perdront leurs actifs stakés. Bien qu'il existe déjà des cas pratiques de versions centralisées, le rollup progresse lentement dans le développement de réseaux de tri décentralisés.
Il semble peu raisonnable d'exiger que tous les L2 effectuent un tri décentralisé, ce qui équivaut à demander aux rollups de faire 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 (et L1) utilisent un mécanisme de pré-confirmation partagé dans le cadre d'Ethereum : la pré-confirmation de base.
Pré-confirmation de base
L'hypothèse de base de préconfirmation suppose que les proposeurs d'Ethereum sont des participants complexes traitant le MEV. Cette méthode tire parti de leur expertise en les incitant à assumer la responsabilité de fournir des services de préconfirmation.
Son idée principale est de créer un protocole standard, permettant aux utilisateurs de payer des frais supplémentaires pour obtenir une garantie instantanée que leur transaction sera incluse dans le prochain bloc, ainsi qu'une déclaration sur le résultat de l'exécution. Si le proposeur ne respecte pas ses engagements, il sera sanctionné.
Ce mécanisme s'applique non seulement aux transactions L1, mais pour les rollups "basés sur", tous les blocs L2 sont des transactions L1, ce qui permet également de fournir une pré-confirmation pour n'importe quel L2.
Perspectives d'avenir
Supposons que la finalité à un seul slot soit réalisée, et que le nombre de validateurs signant chaque slot soit réduit grâce à une technologie similaire à Orbit, tout en visant à abaisser le seuil de mise de 32 ETH. La durée du slot pourrait augmenter à 16 secondes, et en combinant cela avec des pré-confirmations de rollup ou des pré-confirmations de base, cela offrirait des confirmations plus rapides aux utilisateurs. Finalement, nous pourrions obtenir une architecture d'époque-slot.
Cette architecture semble inévitable, car le temps nécessaire pour parvenir à un consensus approximatif sur quelque chose est bien inférieur au temps nécessaire pour atteindre le maximum de "finalité économique". Les raisons incluent le nombre de nœuds et la "qualité" des nœuds. Si nous pouvons compter sur un sous-ensemble de nœuds spécialisés pour parvenir à un accord approximatif, tout en utilisant l'ensemble complet des validateurs pour déterminer la finalité, le temps de confirmation pourrait être réduit à environ 2 secondes.
Ainsi, l'architecture Epoch-Slot semble être la bonne direction, mais il existe des différences entre les différentes mises en œuvre. Il vaut la peine d'explorer l'établissement d'une séparation des préoccupations plus forte entre les deux mécanismes, plutôt que d'être étroitement couplé comme avec Gasper.
Choix de stratégie L2
L2 a actuellement trois stratégies raisonnables :
Sur le plan technique et conceptuel, "basé sur" Ethereum, optimisant ses attributs fondamentaux et ses valeurs.
Devenir un "serveur avec échafaudage blockchain", en tirant pleinement parti de l'efficacité du serveur.
Solution 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-Emplacement. Dans les trois cas, l'"Époque" est le SSF d'Ethereum, mais les "Emplacements" sont différents :
Architecture des epochs-natives d'Ethereum
Pré-confirmation du serveur
Préconfirmation du comité
La question clé est de savoir à quel point la première solution peut bien fonctionner. Si l'effet est significatif, la signification de la troisième solution pourrait être réduite. La deuxième solution existera toujours, car les solutions "basées sur" ne s'appliquent pas à certaines données hors chaîne L2. Si l'architecture d'époque-fente native d'Ethereum peut réduire le temps de fente à 1 seconde, l'espace pour la troisième solution sera considérablement réduit.
Actuellement, les réponses finales à ces questions ne sont pas encore déterminées. Une incertitude clé est la complexité croissante des proposeurs de blocs. Des conceptions novatrices comme Orbit SSF offrent des opportunités pour des explorations supplémentaires, par exemple en les utilisant comme des époques dans les époques - créneaux. Plus il y a d'options, mieux nous pouvons servir les utilisateurs L1 et L2, tout en simplifiant le travail des développeurs 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.
21 J'aime
Récompense
21
5
Partager
Commentaire
0/400
RektDetective
· Il y a 14h
Ce tps a augmenté la latence, c'est même pas aussi bon qu'Alipay, tsk tsk.
Voir l'originalRépondre0
BlockchainBard
· 07-20 19:09
Ne traîne pas, c'est même plus rapide de courir sur L2.
Voir l'originalRépondre0
HallucinationGrower
· 07-18 21:22
Ce serait mieux si ça pouvait aller plus vite, mais j'ai l'impression que ça va encore prendre longtemps.
Voir l'originalRépondre0
SandwichHunter
· 07-18 21:18
Ah, pourquoi courir si vite ? Un homme qui n'aime pas la stabilité ne mérite pas d'être un Complice pour la vie.
Voir l'originalRépondre0
MechanicalMartel
· 07-18 21:07
Vous recherchez encore plus de rapidité ? 20 secondes, c'est déjà assez rapide, non ?
Nouvelle solution d'accélération d'Ethereum : de la finalité à un seul slot à l'architecture époque-slot
Accélérer la confirmation des transactions Ethereum : explorer de nouvelles solutions pour améliorer l'expérience utilisateur
Un élément clé de l'expérience utilisateur de la blockchain est le temps de confirmation des transactions rapide. Au cours des dernières années, Ethereum a réalisé des progrès significatifs à cet égard. Grâce à l'EIP-1559 et à la stabilisation des temps de bloc après le passage à la preuve d'enjeu, les transactions envoyées par les utilisateurs sur le réseau principal sont généralement confirmées dans un délai de 5 à 20 secondes, atteignant ainsi essentiellement le niveau d'expérience des paiements par carte de crédit. Cependant, il reste de la valeur à réduire davantage le temps de confirmation, certaines applications nécessitant même des délais inférieurs à une seconde. Cet article explorera plusieurs solutions viables pour améliorer le temps de confirmation des transactions sur Ethereum.
Aperçu de la technologie existante
finalité à un seul slot
Actuellement, le consensus Gasper d'Ethereum utilise une structure à deux niveaux de slots et d'époques. Un slot toutes les 12 secondes, où une partie des validateurs vote sur la tête de la chaîne, 32 slots (6,4 minutes ) tous les validateurs ont l'opportunité de voter une fois. Ces votes sont ensuite interprétés comme des messages dans l'algorithme de consensus de type PBFT, deux époques (12,8 minutes ) fournissent une finalité avec une forte garantie économique.
Ces dernières années, les limites de cette méthode sont de plus en plus évidentes. Tout d'abord, la complexité est élevée, et il existe de nombreux problèmes d'interaction entre le vote au niveau des fentes et la finalité au niveau des époques. Ensuite, le temps d'attente de 12,8 minutes est trop long, ce qui nuit à l'expérience utilisateur.
La finalité à un seul slot ( SSF ) remplace cette architecture par un mécanisme de type Tendermint, permettant la confirmation finale d'un bloc N avant la génération du bloc N+1. La principale différence avec Tendermint réside dans la conservation du mécanisme de "fuite inactive", 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 de SSF est que chaque staker doit publier deux messages toutes les 12 secondes, ce qui impose une charge considérable à la chaîne. Bien qu'il existe quelques solutions astucieuses pour atténuer ce problème, comme l'Orbit SSF récemment proposé, les utilisateurs doivent néanmoins attendre entre 5 et 20 secondes.
Pré-confirmation Rollup
Ces dernières années, Ethereum a suivi une feuille de route centrée sur les rollups, concevant la couche de base pour prendre en charge la disponibilité des données et d'autres fonctionnalités, à utiliser par les protocoles L2, afin de fournir une plus grande sécurité aux utilisateurs.
Cela a conduit à une séparation des points d'attention au sein de l'écosystème Ethereum : L1 se concentre sur la résistance à la censure, la fiabilité et l'amélioration des fonctionnalités de base, tandis que L2 sert directement les utilisateurs à travers différentes cultures et technologies. Cependant, L2 souhaite offrir aux utilisateurs des confirmations plus rapides que 5 à 20 secondes.
Théoriquement, la création d'un réseau de classificateurs 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 mettre en jeu des actifs. Les en-têtes de ces blocs L2 seront finalement publiés sur L1.
Les validateurs de L2 peuvent tricher : signer d'abord le bloc B1, puis signer le bloc B2 en conflit et le soumettre à la chaîne avant B1. Mais faire cela les exposera et ils perdront leurs actifs stakés. Bien qu'il existe déjà des cas pratiques de versions centralisées, le rollup progresse lentement dans le développement de réseaux de tri décentralisés.
Il semble peu raisonnable d'exiger que tous les L2 effectuent un tri décentralisé, ce qui équivaut à demander aux rollups de faire 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 (et L1) utilisent un mécanisme de pré-confirmation partagé dans le cadre d'Ethereum : la pré-confirmation de base.
Pré-confirmation de base
L'hypothèse de base de préconfirmation suppose que les proposeurs d'Ethereum sont des participants complexes traitant le MEV. Cette méthode tire parti de leur expertise en les incitant à assumer la responsabilité de fournir des services de préconfirmation.
Son idée principale est de créer un protocole standard, permettant aux utilisateurs de payer des frais supplémentaires pour obtenir une garantie instantanée que leur transaction sera incluse dans le prochain bloc, ainsi qu'une déclaration sur le résultat de l'exécution. Si le proposeur ne respecte pas ses engagements, il sera sanctionné.
Ce mécanisme s'applique non seulement aux transactions L1, mais pour les rollups "basés sur", tous les blocs L2 sont des transactions L1, ce qui permet également de fournir une pré-confirmation pour n'importe quel L2.
Perspectives d'avenir
Supposons que la finalité à un seul slot soit réalisée, et que le nombre de validateurs signant chaque slot soit réduit grâce à une technologie similaire à Orbit, tout en visant à abaisser le seuil de mise de 32 ETH. La durée du slot pourrait augmenter à 16 secondes, et en combinant cela avec des pré-confirmations de rollup ou des pré-confirmations de base, cela offrirait des confirmations plus rapides aux utilisateurs. Finalement, nous pourrions obtenir une architecture d'époque-slot.
Cette architecture semble inévitable, car le temps nécessaire pour parvenir à un consensus approximatif sur quelque chose est bien inférieur au temps nécessaire pour atteindre le maximum de "finalité économique". Les raisons incluent le nombre de nœuds et la "qualité" des nœuds. Si nous pouvons compter sur un sous-ensemble de nœuds spécialisés pour parvenir à un accord approximatif, tout en utilisant l'ensemble complet des validateurs pour déterminer la finalité, le temps de confirmation pourrait être réduit à environ 2 secondes.
Ainsi, l'architecture Epoch-Slot semble être la bonne direction, mais il existe des différences entre les différentes mises en œuvre. Il vaut la peine d'explorer l'établissement d'une séparation des préoccupations plus forte entre les deux mécanismes, plutôt que d'être étroitement couplé comme avec Gasper.
Choix de stratégie L2
L2 a actuellement trois stratégies raisonnables :
Pour certaines applications, un temps de bloc de 12 secondes est suffisant. Pour d'autres applications, la seule solution est l'architecture Époque-Emplacement. Dans les trois cas, l'"Époque" est le SSF d'Ethereum, mais les "Emplacements" sont différents :
La question clé est de savoir à quel point la première solution peut bien fonctionner. Si l'effet est significatif, la signification de la troisième solution pourrait être réduite. La deuxième solution existera toujours, car les solutions "basées sur" ne s'appliquent pas à certaines données hors chaîne L2. Si l'architecture d'époque-fente native d'Ethereum peut réduire le temps de fente à 1 seconde, l'espace pour la troisième solution sera considérablement réduit.
Actuellement, les réponses finales à ces questions ne sont pas encore déterminées. Une incertitude clé est la complexité croissante des proposeurs de blocs. Des conceptions novatrices comme Orbit SSF offrent des opportunités pour des explorations supplémentaires, par exemple en les utilisant comme des époques dans les époques - créneaux. Plus il y a d'options, mieux nous pouvons servir les utilisateurs L1 et L2, tout en simplifiant le travail des développeurs L2.