Confirmation de transaction rapide : une nouvelle direction pour améliorer l'expérience utilisateur d'Ethereum
Un aspect important de l'expérience utilisateur de la blockchain est la vitesse de confirmation des transactions. Ces dernières années, Ethereum a réalisé d'importants progrès à cet égard. Grâce à l'EIP-1559 et à un temps de bloc stable après le passage au PoS, les transactions envoyées par les utilisateurs sur L1 peuvent généralement être confirmées en 5 à 20 secondes, ce qui correspond à peu près à l'expérience de paiement par carte de crédit. Cependant, il est encore précieux de réduire davantage le temps de confirmation, certaines applications exigeant même des délais inférieurs à la seconde. Cet article explorera plusieurs solutions viables pour améliorer la vitesse de confirmation des transactions Ethereum.
Aperçu de la technologie existante
finalité à un seul slot
Actuellement, le consensus Gasper d'Ethereum adopte l'architecture des slots (Slot) et des époques (Epoch). Un slot toutes les 12 secondes, certains validateurs votent sur le chef de chaîne, et tous les 32 slots (6,4 minutes ), tous les validateurs votent à tour de rôle une fois. Ces votes sont interprétés comme des messages dans un algorithme de consensus de type PBFT, et deux époques (12,8 minutes ) après fournissent une finalité avec de fortes garanties économiques.
Ces dernières années, cette méthode a progressivement révélé des défauts : d'une part, la complexité est élevée, et l'interaction entre le mécanisme de niveau de slot et de niveau d'époque est sujette à des erreurs ; d'autre part, le temps d'attente de 12,8 minutes est trop long. La finalité à slot unique (Single Slot Finality, SSF) a remplacé cette architecture par un mécanisme de type Tendermint, permettant la confirmation finale du bloc N avant la génération de N+1. Le SSF conserve le 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 du SSF est que chaque staker doit publier deux messages toutes les 12 secondes, ce qui entraîne une charge énorme sur la chaîne. Bien qu'il existe certaines solutions d'atténuation, comme la récente proposition Orbit SSF, les utilisateurs doivent toujours attendre de 5 à 20 secondes pour confirmer une transaction.
Préconfirmation de Rollup
Ces dernières années, Ethereum a suivi une feuille de route centrée sur les rollups, concevant le L1 pour supporter des fonctionnalités de base telles que la disponibilité des données, à utiliser par les protocoles L2 ( comme les rollups, validiums et plasmas ), afin d'offrir une sécurité équivalente aux utilisateurs à une plus grande échelle.
Cela a conduit à une spécialisation au sein de l'écosystème Ethereum : L1 se concentre sur l'anti-censure, la fiabilité et l'amélioration des fonctionnalités de base, tandis que L2 sert plus directement les besoins des utilisateurs. Cependant, L2 souhaite offrir aux utilisateurs des confirmations plus rapides que 5 à 20 secondes.
En théorie, la création d'un réseau de classificateurs décentralisés est de la responsabilité de L2. Un petit groupe de validateurs pourrait signer un bloc toutes les quelques centaines de millisecondes et mettre en jeu des actifs comme garantie. Les en-têtes de ces blocs L2 seront finalement publiés sur L1.
Mais il se peut que le groupe de validateurs L2 agisse de manière malveillante : signer d'abord le bloc B1, puis signer le conflit B2 et le soumettre à l'avance. Une fois découvert, ils perdront leurs actifs stakés. Il existe déjà des exemples de versions centralisées, mais le rollup progresse lentement dans le développement de réseaux de tri décentralisés. Exiger que tous les L2 mettent en œuvre un tri décentralisé semble injuste, cela revient presque à créer un tout nouveau L1. Par conséquent, il a été proposé que tous les L2( et L1) partagent un mécanisme de préconfirmation au sein de l'Éther : la préconfirmation de base.
Pré-confirmation de base
L'hypothèse de pré-confirmation de base suppose que les proposeurs d'Ethereum sont des participants hautement complexes liés à l'MEV, en les incitant à assumer la responsabilité des services de pré-confirmation afin de tirer parti de cette complexité.
Son principe de base est de créer un protocole standardisé, permettant aux utilisateurs de payer des frais supplémentaires pour obtenir immédiatement une garantie que la transaction sera incluse dans le prochain bloc, ainsi qu'une déclaration sur le résultat de la transaction. En cas de défaut de l'initiateur, celui-ci sera sanctionné.
Ce mécanisme peut être utilisé à la fois pour les transactions L1 et pour les blocs L2 "basés sur" des rollups.
Perspectives d'avenir
Supposons que nous ayons réalisé la finalité à un seul slot, en utilisant une technologie similaire à Orbit pour réduire le nombre de validateurs de signature par slot, tout en progressant vers l'objectif de réduire le seuil de mise à 32 ETH. La durée des slots pourrait être augmentée à 16 secondes, puis utiliser la pré-confirmation par rollup ou la pré-confirmation de base pour offrir une confirmation plus rapide aux utilisateurs. Au final, nous obtenons une nouvelle ère - l'architecture de slot.
La raison profonde de cette architecture, difficile à éviter, est que le temps nécessaire pour parvenir à un consensus approximatif sur une question est bien inférieur au temps requis pour atteindre le "finalité économique" maximale.
Les principales raisons incluent le nombre de nœuds et la "qualité" des nœuds. Le "consensus approximatif" nécessite seulement un petit nombre de nœuds, tandis que la finalité économique nécessite la participation de la majorité des nœuds. Un sous-ensemble de nœuds spécialisés peut réduire le temps de protocole approximatif à environ 2 secondes.
Ainsi, l'architecture Epoch-Slot semble être la bonne direction, mais il existe des différences entre les différentes implémentations. 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és comme Gasper.
Choix de L2
Actuellement, il existe trois stratégies raisonnables pour L2 :
Techniquement et conceptuellement "basé" sur Ethereum, optimisant ses attributs fondamentaux et ses valeurs. Peut être considéré comme un "fragment de marque", tout en osant innover dans des domaines tels que la conception de nouveaux VM.
Devenir un "serveur avec un échafaudage blockchain", tirer pleinement parti des avantages de la centralisation tout en garantissant la sécurité grâce à des preuves d'efficacité, des mécanismes de sortie, etc.
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. C'est la voie actuelle de nombreux projets L2.
Pour certaines applications ( comme ENS, le stockage de clés et certains protocoles de paiement ), un temps de bloc de 12 secondes est suffisant. D'autres cas nécessitent une architecture d'ère - de créneau, où "ère" est le SSF d'Ethereum et où "créneau" varie selon l'application.
La question clé est de savoir dans quelle mesure l'architecture d'époque et de fente native d'Ethereum peut fonctionner. Si le temps de fente peut être réduit à 1 seconde, l'espace de la troisième solution sera considérablement réduit.
Nous sommes encore loin des réponses finales à ces questions. L'évolution de la complexité des proposeurs de blocs reste très incertaine. Des conceptions novatrices comme Orbit SSF offrent un large espace pour l'exploration. Plus il y a d'options, mieux nous pouvons fournir une expérience aux 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.
8 J'aime
Récompense
8
8
Partager
Commentaire
0/400
MEVSandwich
· Il y a 18h
Les transactions de verrouillage sont trop lentes, je suis désespéré.
Voir l'originalRépondre0
CryptoMotivator
· 07-18 23:17
Toute la journée, tout est lent, tout est en hausse.
Voir l'originalRépondre0
DegenWhisperer
· 07-18 09:24
Le gaz est trop cher, quand va-t-il baisser ?
Voir l'originalRépondre0
SelfCustodyBro
· 07-18 08:50
Courir plus vite que gwei.
Voir l'originalRépondre0
HashRateHermit
· 07-18 08:42
Pourquoi tout le monde trouve ça lent ?
Voir l'originalRépondre0
GasFeeCrybaby
· 07-18 08:41
Pourquoi ça ne va pas plus vite ?
Voir l'originalRépondre0
RugDocDetective
· 07-18 08:34
La confirmation prend trop de temps, n'est-ce pas ? J'attends d'être chauve.
Accélération de la confirmation des transactions Ethereum : exploration de la finalité à un seul slot et des mécanismes de pré-confirmation
Confirmation de transaction rapide : une nouvelle direction pour améliorer l'expérience utilisateur d'Ethereum
Un aspect important de l'expérience utilisateur de la blockchain est la vitesse de confirmation des transactions. Ces dernières années, Ethereum a réalisé d'importants progrès à cet égard. Grâce à l'EIP-1559 et à un temps de bloc stable après le passage au PoS, les transactions envoyées par les utilisateurs sur L1 peuvent généralement être confirmées en 5 à 20 secondes, ce qui correspond à peu près à l'expérience de paiement par carte de crédit. Cependant, il est encore précieux de réduire davantage le temps de confirmation, certaines applications exigeant même des délais inférieurs à la seconde. Cet article explorera plusieurs solutions viables pour améliorer la vitesse de confirmation des transactions Ethereum.
Aperçu de la technologie existante
finalité à un seul slot
Actuellement, le consensus Gasper d'Ethereum adopte l'architecture des slots (Slot) et des époques (Epoch). Un slot toutes les 12 secondes, certains validateurs votent sur le chef de chaîne, et tous les 32 slots (6,4 minutes ), tous les validateurs votent à tour de rôle une fois. Ces votes sont interprétés comme des messages dans un algorithme de consensus de type PBFT, et deux époques (12,8 minutes ) après fournissent une finalité avec de fortes garanties économiques.
Ces dernières années, cette méthode a progressivement révélé des défauts : d'une part, la complexité est élevée, et l'interaction entre le mécanisme de niveau de slot et de niveau d'époque est sujette à des erreurs ; d'autre part, le temps d'attente de 12,8 minutes est trop long. La finalité à slot unique (Single Slot Finality, SSF) a remplacé cette architecture par un mécanisme de type Tendermint, permettant la confirmation finale du bloc N avant la génération de N+1. Le SSF conserve le 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 du SSF est que chaque staker doit publier deux messages toutes les 12 secondes, ce qui entraîne une charge énorme sur la chaîne. Bien qu'il existe certaines solutions d'atténuation, comme la récente proposition Orbit SSF, les utilisateurs doivent toujours attendre de 5 à 20 secondes pour confirmer une transaction.
Préconfirmation de Rollup
Ces dernières années, Ethereum a suivi une feuille de route centrée sur les rollups, concevant le L1 pour supporter des fonctionnalités de base telles que la disponibilité des données, à utiliser par les protocoles L2 ( comme les rollups, validiums et plasmas ), afin d'offrir une sécurité équivalente aux utilisateurs à une plus grande échelle.
Cela a conduit à une spécialisation au sein de l'écosystème Ethereum : L1 se concentre sur l'anti-censure, la fiabilité et l'amélioration des fonctionnalités de base, tandis que L2 sert plus directement les besoins des utilisateurs. Cependant, L2 souhaite offrir aux utilisateurs des confirmations plus rapides que 5 à 20 secondes.
En théorie, la création d'un réseau de classificateurs décentralisés est de la responsabilité de L2. Un petit groupe de validateurs pourrait signer un bloc toutes les quelques centaines de millisecondes et mettre en jeu des actifs comme garantie. Les en-têtes de ces blocs L2 seront finalement publiés sur L1.
Mais il se peut que le groupe de validateurs L2 agisse de manière malveillante : signer d'abord le bloc B1, puis signer le conflit B2 et le soumettre à l'avance. Une fois découvert, ils perdront leurs actifs stakés. Il existe déjà des exemples de versions centralisées, mais le rollup progresse lentement dans le développement de réseaux de tri décentralisés. Exiger que tous les L2 mettent en œuvre un tri décentralisé semble injuste, cela revient presque à créer un tout nouveau L1. Par conséquent, il a été proposé que tous les L2( et L1) partagent un mécanisme de préconfirmation au sein de l'Éther : la préconfirmation de base.
Pré-confirmation de base
L'hypothèse de pré-confirmation de base suppose que les proposeurs d'Ethereum sont des participants hautement complexes liés à l'MEV, en les incitant à assumer la responsabilité des services de pré-confirmation afin de tirer parti de cette complexité.
Son principe de base est de créer un protocole standardisé, permettant aux utilisateurs de payer des frais supplémentaires pour obtenir immédiatement une garantie que la transaction sera incluse dans le prochain bloc, ainsi qu'une déclaration sur le résultat de la transaction. En cas de défaut de l'initiateur, celui-ci sera sanctionné.
Ce mécanisme peut être utilisé à la fois pour les transactions L1 et pour les blocs L2 "basés sur" des rollups.
Perspectives d'avenir
Supposons que nous ayons réalisé la finalité à un seul slot, en utilisant une technologie similaire à Orbit pour réduire le nombre de validateurs de signature par slot, tout en progressant vers l'objectif de réduire le seuil de mise à 32 ETH. La durée des slots pourrait être augmentée à 16 secondes, puis utiliser la pré-confirmation par rollup ou la pré-confirmation de base pour offrir une confirmation plus rapide aux utilisateurs. Au final, nous obtenons une nouvelle ère - l'architecture de slot.
La raison profonde de cette architecture, difficile à éviter, est que le temps nécessaire pour parvenir à un consensus approximatif sur une question est bien inférieur au temps requis pour atteindre le "finalité économique" maximale.
Les principales raisons incluent le nombre de nœuds et la "qualité" des nœuds. Le "consensus approximatif" nécessite seulement un petit nombre de nœuds, tandis que la finalité économique nécessite la participation de la majorité des nœuds. Un sous-ensemble de nœuds spécialisés peut réduire le temps de protocole approximatif à environ 2 secondes.
Ainsi, l'architecture Epoch-Slot semble être la bonne direction, mais il existe des différences entre les différentes implémentations. 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és comme Gasper.
Choix de L2
Actuellement, il existe trois stratégies raisonnables pour L2 :
Techniquement et conceptuellement "basé" sur Ethereum, optimisant ses attributs fondamentaux et ses valeurs. Peut être considéré comme un "fragment de marque", tout en osant innover dans des domaines tels que la conception de nouveaux VM.
Devenir un "serveur avec un échafaudage blockchain", tirer pleinement parti des avantages de la centralisation tout en garantissant la sécurité grâce à des preuves d'efficacité, des mécanismes de sortie, etc.
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. C'est la voie actuelle de nombreux projets L2.
Pour certaines applications ( comme ENS, le stockage de clés et certains protocoles de paiement ), un temps de bloc de 12 secondes est suffisant. D'autres cas nécessitent une architecture d'ère - de créneau, où "ère" est le SSF d'Ethereum et où "créneau" varie selon l'application.
La question clé est de savoir dans quelle mesure l'architecture d'époque et de fente native d'Ethereum peut fonctionner. Si le temps de fente peut être réduit à 1 seconde, l'espace de la troisième solution sera considérablement réduit.
Nous sommes encore loin des réponses finales à ces questions. L'évolution de la complexité des proposeurs de blocs reste très incertaine. Des conceptions novatrices comme Orbit SSF offrent un large espace pour l'exploration. Plus il y a d'options, mieux nous pouvons fournir une expérience aux utilisateurs L1 et L2, tout en simplifiant le travail des développeurs L2.