Discussion sur l'optimisation du temps de confirmation des transactions Ethereum : comparaison entre SSF, Rollup et le schéma de pré-confirmation de base.
Discuter des solutions pour optimiser le temps de confirmation des transactions sur Ethereum
Un aspect important de l'expérience utilisateur sur la blockchain est le temps de confirmation rapide des transactions. Au cours des dernières années, Ethereum a fait des progrès significatifs à cet égard. Grâce à l'EIP-1559 et à une durée 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 est essentiellement comparable à l'expérience de paiement par carte de crédit. Cependant, il reste utile d'améliorer davantage l'expérience utilisateur, certaines applications nécessitant même des délais inférieurs à une seconde. Cet article explorera quelques options 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 adopte une architecture de slots et d'Epochs. Un slot toutes les 12 secondes, où certains validateurs votent sur le bloc de tête, et tous les validateurs ont l'opportunité de voter une fois dans 32 slots. Ces votes sont réinterprétés comme des messages similaires à l'algorithme de consensus PBFT, offrant une finalité avec des garanties économiques solides après deux Epochs.
Ces dernières années, les gens sont de plus en plus mécontents de cette méthode, pour deux raisons principales : d'une part, la complexité est élevée, il existe de nombreux problèmes d'interaction entre le mécanisme de vote de slot à slot et le mécanisme de finalité Epoch à Epoch ; d'autre part, le temps de finalité de 12,8 minutes est trop long.
La finalité à unité de slot (SSF) a remplacé cette architecture par un mécanisme similaire à Tendermint, le bloc N pouvant être définitivement déterminé avant la génération du bloc N+1. La principale différence avec Tendermint est la préservation du mécanisme de "fuite inactif", permettant à la chaîne de continuer à fonctionner et de se rétablir même lorsque plus d'1/3 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 impose une charge énorme sur la chaîne. Bien qu'il existe certaines solutions d'atténuation, comme la récente proposition Orbit SSF, cela n'a pas changé le fait que les utilisateurs doivent attendre entre 5 et 20 secondes.
Préconfirmation de Rollup
Ethereum a suivi ces dernières années une feuille de route centrée sur les rollups, concevant le L1 comme une couche de base pour soutenir la disponibilité des données et d'autres fonctionnalités, à utiliser par les protocoles L2. Cela a créé une séparation des préoccupations au sein de l'écosystème : le L1 se concentre sur l'anti-censure, la fiabilité et l'amélioration des fonctionnalités de base, tandis que le L2 répond plus directement aux besoins des utilisateurs.
Théoriquement, il est de la responsabilité de L2 de créer un réseau de tri décentralisé. Un petit groupe de validateurs pourrait signer des blocs toutes les quelques centaines de millisecondes et publier les en-têtes de ces blocs sur L1. Cependant, exiger que tous les L2 effectuent un tri décentralisé semble peu équitable, car cela équivaut à créer un tout nouveau L1.
Confirmation préliminaire de base
L'hypothèse de pré-confirmation de base suppose que les proposeurs Ethereum sont des participants MEV hautement complexes. Cette méthode exploite leur complexité en incitant ces proposeurs à accepter la responsabilité de fournir des services de pré-confirmation.
Son idée fondamentale est de créer un protocole standardisé, permettant aux utilisateurs de 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. Si le proposeur ne respecte pas son engagement, il sera pénalisé.
Ce mécanisme s'applique non seulement aux transactions L1, mais peut également fournir une pré-confirmation pour les rollups "basés sur".
Perspectives d'avenir
Supposons que la finalité à un seul slot soit réalisée et que l'on utilise une technologie similaire à Orbit pour réduire le nombre de validateurs par slot. La durée du slot pourrait être augmentée à 16 secondes, puis utiliser un pré-confirmation par rollup ou une pré-confirmation de base pour offrir aux utilisateurs des confirmations plus rapides. Finalement, nous pourrions obtenir une architecture epoch-slot.
L'architecture epoch-slot semble inévitable, car le temps nécessaire pour parvenir à un consensus approximatif sur quelque chose est inférieur à celui requis pour parvenir à un accord de "finalité économique" maximale. Les raisons incluent le nombre de nœuds et la "qualité" des nœuds.
Dans l'Ethereum actuel, un slot de 12 secondes est divisé en trois sous-slots. Si le nombre de validateurs est considérablement réduit, il pourrait passer à deux sous-slots et utiliser un temps de slot de 8 secondes. Si un sous-ensemble de nœuds spécialisés parvient à un protocole approximatif, cela pourrait être encore réduit à environ 2 secondes.
Suggestions de stratégie L2
Actuellement, il existe trois stratégies raisonnables pour L2 :
Techniquement et spirituellement "basé" sur Ethereum, optimisant ses attributs technologiques fondamentaux et ses valeurs.
Devenir un "serveur avec échafaudage blockchain", en tirant pleinement parti de l'efficacité du serveur tout en bénéficiant des avantages de la chaîne.
Méthode de compromis : une chaîne rapide avec environ une centaine de nœuds, l'Éthereum 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 epoch-slot. La question clé est de savoir à quel point l'architecture epoch-slot native d'Ethereum peut performer, ce qui influencera la pertinence d'autres solutions.
Nous sommes encore loin des réponses finales à ces questions. Il existe encore une grande incertitude quant à la complexité des proposeurs de blocs. Des conceptions novatrices comme Orbit SSF méritent d'être explorées davantage. Plus nous avons d'options, mieux nous pouvons servir les utilisateurs L1 et L2, et simplifier 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.
22 J'aime
Récompense
22
8
Partager
Commentaire
0/400
ShibaMillionairen't
· 07-21 14:39
Trading des cryptomonnaies c'est comme faire du somnambulisme, je rigole. Attends, si le temps de confirmation est trop court, ça veut dire qu'on ne peut pas se faire prendre pour des cons.
Voir l'originalRépondre0
DefiPlaybook
· 07-20 15:55
C'est vraiment incroyable, j'ai juste passé un peu trop de temps à faire des petits boulots.
Voir l'originalRépondre0
GasFeeCryer
· 07-20 01:55
L'ancienne époque de L1 confirme lentement à en pleurer, maintenant c'est à peine utilisable.
Voir l'originalRépondre0
CryptoTherapist
· 07-20 01:48
l'anxiété liée au trading est réelle fam... méditons sur ces temps de confirmation et libérons-nous de l'état d'esprit fomo tbh
Voir l'originalRépondre0
MissedTheBoat
· 07-20 01:47
Une carte de crédit n'est pas si lente, n'est-ce pas... Dépêche-toi.
Voir l'originalRépondre0
AllInAlice
· 07-20 01:46
Confirmation rapide, 5 secondes c'est déjà incroyable, d'accord ?
Voir l'originalRépondre0
AirdropHunterZhang
· 07-20 01:28
Je conseille à tout le monde de ne pas s'attacher au gas, si c'est bas, faites un All in.
Voir l'originalRépondre0
FUD_Vaccinated
· 07-20 01:26
C'est drôle, pourquoi se prendre la tête avec ça ? L2 est bien non ?
Discussion sur l'optimisation du temps de confirmation des transactions Ethereum : comparaison entre SSF, Rollup et le schéma de pré-confirmation de base.
Discuter des solutions pour optimiser le temps de confirmation des transactions sur Ethereum
Un aspect important de l'expérience utilisateur sur la blockchain est le temps de confirmation rapide des transactions. Au cours des dernières années, Ethereum a fait des progrès significatifs à cet égard. Grâce à l'EIP-1559 et à une durée 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 est essentiellement comparable à l'expérience de paiement par carte de crédit. Cependant, il reste utile d'améliorer davantage l'expérience utilisateur, certaines applications nécessitant même des délais inférieurs à une seconde. Cet article explorera quelques options 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 adopte une architecture de slots et d'Epochs. Un slot toutes les 12 secondes, où certains validateurs votent sur le bloc de tête, et tous les validateurs ont l'opportunité de voter une fois dans 32 slots. Ces votes sont réinterprétés comme des messages similaires à l'algorithme de consensus PBFT, offrant une finalité avec des garanties économiques solides après deux Epochs.
Ces dernières années, les gens sont de plus en plus mécontents de cette méthode, pour deux raisons principales : d'une part, la complexité est élevée, il existe de nombreux problèmes d'interaction entre le mécanisme de vote de slot à slot et le mécanisme de finalité Epoch à Epoch ; d'autre part, le temps de finalité de 12,8 minutes est trop long.
La finalité à unité de slot (SSF) a remplacé cette architecture par un mécanisme similaire à Tendermint, le bloc N pouvant être définitivement déterminé avant la génération du bloc N+1. La principale différence avec Tendermint est la préservation du mécanisme de "fuite inactif", permettant à la chaîne de continuer à fonctionner et de se rétablir même lorsque plus d'1/3 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 impose une charge énorme sur la chaîne. Bien qu'il existe certaines solutions d'atténuation, comme la récente proposition Orbit SSF, cela n'a pas changé le fait que les utilisateurs doivent attendre entre 5 et 20 secondes.
Préconfirmation de Rollup
Ethereum a suivi ces dernières années une feuille de route centrée sur les rollups, concevant le L1 comme une couche de base pour soutenir la disponibilité des données et d'autres fonctionnalités, à utiliser par les protocoles L2. Cela a créé une séparation des préoccupations au sein de l'écosystème : le L1 se concentre sur l'anti-censure, la fiabilité et l'amélioration des fonctionnalités de base, tandis que le L2 répond plus directement aux besoins des utilisateurs.
Théoriquement, il est de la responsabilité de L2 de créer un réseau de tri décentralisé. Un petit groupe de validateurs pourrait signer des blocs toutes les quelques centaines de millisecondes et publier les en-têtes de ces blocs sur L1. Cependant, exiger que tous les L2 effectuent un tri décentralisé semble peu équitable, car cela équivaut à créer un tout nouveau L1.
Confirmation préliminaire de base
L'hypothèse de pré-confirmation de base suppose que les proposeurs Ethereum sont des participants MEV hautement complexes. Cette méthode exploite leur complexité en incitant ces proposeurs à accepter la responsabilité de fournir des services de pré-confirmation.
Son idée fondamentale est de créer un protocole standardisé, permettant aux utilisateurs de 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. Si le proposeur ne respecte pas son engagement, il sera pénalisé.
Ce mécanisme s'applique non seulement aux transactions L1, mais peut également fournir une pré-confirmation pour les rollups "basés sur".
Perspectives d'avenir
Supposons que la finalité à un seul slot soit réalisée et que l'on utilise une technologie similaire à Orbit pour réduire le nombre de validateurs par slot. La durée du slot pourrait être augmentée à 16 secondes, puis utiliser un pré-confirmation par rollup ou une pré-confirmation de base pour offrir aux utilisateurs des confirmations plus rapides. Finalement, nous pourrions obtenir une architecture epoch-slot.
L'architecture epoch-slot semble inévitable, car le temps nécessaire pour parvenir à un consensus approximatif sur quelque chose est inférieur à celui requis pour parvenir à un accord de "finalité économique" maximale. Les raisons incluent le nombre de nœuds et la "qualité" des nœuds.
Dans l'Ethereum actuel, un slot de 12 secondes est divisé en trois sous-slots. Si le nombre de validateurs est considérablement réduit, il pourrait passer à deux sous-slots et utiliser un temps de slot de 8 secondes. Si un sous-ensemble de nœuds spécialisés parvient à un protocole approximatif, cela pourrait être encore réduit à environ 2 secondes.
Suggestions de stratégie L2
Actuellement, il existe trois stratégies raisonnables pour L2 :
Pour certaines applications, un temps de bloc de 12 secondes est suffisant. Pour d'autres applications, la seule solution est l'architecture epoch-slot. La question clé est de savoir à quel point l'architecture epoch-slot native d'Ethereum peut performer, ce qui influencera la pertinence d'autres solutions.
Nous sommes encore loin des réponses finales à ces questions. Il existe encore une grande incertitude quant à la complexité des proposeurs de blocs. Des conceptions novatrices comme Orbit SSF méritent d'être explorées davantage. Plus nous avons d'options, mieux nous pouvons servir les utilisateurs L1 et L2, et simplifier le travail des développeurs L2.