Discussion sur les améliorations du temps de confirmation des transactions Blockchain
Dans le domaine de la Blockchain, un temps de confirmation des transactions rapide est l'un des facteurs clés pour améliorer l'expérience utilisateur. Ethereum a réalisé des progrès significatifs au cours des cinq dernières années, et maintenant les transactions envoyées par les utilisateurs sur L1 peuvent généralement être confirmées en 5 à 20 secondes, ce qui est comparable à l'expérience de paiement par carte de crédit. Cependant, réduire davantage le temps de confirmation a encore de la valeur, en particulier pour les scénarios d'application nécessitant une latence inférieure à une seconde. Cet article explorera certaines options viables pour Ethereum afin d'améliorer le temps de confirmation des transactions.
Aperçu des technologies et idées existantes
finalité de slot unique
Actuellement, le mécanisme de consensus Gasper d'Ethereum adopte une architecture à un seul Slot et Epoch. Un Slot toutes les 12 secondes, certains validateurs votent sur la tête de la chaîne, et dans 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 similaires à ceux de l'algorithme de consensus PBFT, et après deux Epochs (12,8 minutes), ils fournissent une garantie économique forte appelée finalité.
Cependant, cette méthode présente deux problèmes majeurs : la complexité et un temps de confirmation finale plus long. Pour résoudre ces problèmes, le concept de finalité à un seul emplacement (Single Slot Finality, SSF) a été proposé, remplaçant l'architecture existante par un mécanisme de consensus similaire à Tendermint, permettant au bloc N d'être définitivement établi avant la génération du bloc N+1.
Le principal défi de la finalité à slot unique est qu'elle exige que chaque staker Ethereum publie deux messages toutes les 12 secondes, ce qui impose une charge énorme au réseau. Bien qu'il existe certaines solutions innovantes comme Orbit SSF qui tentent d'atténuer ce problème, les utilisateurs doivent encore attendre entre 5 et 20 secondes pour confirmer une transaction.
Préconfirmation Rollup
Avec le développement centré sur les rollups d'Ethereum, les solutions L2 telles que les rollups, les validiums et les plasmas peuvent offrir aux utilisateurs un niveau de sécurité équivalent à celui d'Ethereum à une plus grande échelle. Cette architecture permet à Ethereum L1 de se concentrer sur des fonctionnalités clés telles que la résistance à la censure, la fiabilité et la stabilité, tandis que L2 s'engage à répondre directement aux besoins des utilisateurs grâce à différentes technologies et cultures.
En théorie, L2 peut créer son propre réseau de "classificateurs décentralisés", où un petit groupe de validateurs signe des blocs toutes les quelques centaines de millisecondes et met en garantie ses actifs stakés. Cependant, cette méthode fait face au risque que les validateurs agissent de manière malveillante, comme signer des blocs conflictuels. Bien que nous ayons déjà vu des applications pratiques de versions centralisées, L2 progresse lentement dans le développement de réseaux de classement décentralisés.
Confirmation préalable de base
Pour résoudre les problèmes mentionnés ci-dessus, le concept de préconfirmations de base (Based preconfirmations) a été proposé. Cette méthode suppose que les proposeurs d'Ethereum sont des participants complexes hautement sensibles au MEV, et vise à tirer parti de leur expertise en incitant ces proposeurs à accepter la responsabilité de fournir des services de préconfirmation.
La préconfirmation de base a créé un protocole standardisé, permettant aux utilisateurs d'obtenir une garantie instantanée que la transaction sera incluse dans le prochain Bloc en payant des frais supplémentaires. Si le proposeur ne respecte pas ses engagements, il sera pénalisé. Ce mécanisme s'applique non seulement aux transactions L1, mais peut également fournir des services de préconfirmation pour les L2 basés sur Ethereum.
Les directions de développement futures
Supposons que nous ayons réalisé la finalité à un seul bloc et que nous utilisions une technologie similaire à Orbit pour réduire le nombre de validateurs par bloc, tout en maintenant un degré de décentralisation suffisant. La durée du bloc pourrait augmenter à 16 secondes, puis nous pourrions utiliser des pré-confirmations de rollup ou des pré-confirmations de base pour offrir une confirmation plus rapide aux utilisateurs. Cette architecture est essentiellement une structure d'epoch-slot.
La raison pour laquelle cette structure est difficile à éviter est que le temps nécessaire pour parvenir à un consensus général sur une question est bien inférieur au temps nécessaire pour atteindre le "finalité économique" maximale. Cette différence provient principalement du nombre et de la qualité des nœuds participants.
Pour L2, il existe actuellement trois stratégies raisonnables :
À la fois sur le plan technique et conceptuel, "basé sur" Ethereum, en optimisant ses attributs fondamentaux et ses valeurs.
Devenir un "serveur avec échafaudage Blockchain", tirer pleinement parti de l'efficacité centralisée tout en conservant les avantages clés de la décentralisation.
Solution de compromis : établir une chaîne rapide composée d'environ une centaine de nœuds, tout en utilisant Ethereum pour fournir une interopérabilité et une sécurité supplémentaires.
La question clé pour l'avenir est de savoir dans quelle mesure nous pouvons améliorer l'architecture epoch-and-slot native d'Ethereum. Si nous pouvons réduire le temps des slots à environ 1 seconde, la nécessité de la troisième stratégie sera considérablement réduite.
Actuellement, nous sommes encore loin des réponses finales à ces questions. La complexité des propositions de blocs, le potentiel de nouveaux designs tels qu'Orbit SSF, entre autres facteurs, présentent des incertitudes. Continuer à explorer et à optimiser ces solutions aidera à offrir une meilleure 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.
12 J'aime
Récompense
12
4
Partager
Commentaire
0/400
MemeCurator
· 08-05 20:08
L'amélioration de l'efficacité n'est pas encore assez rapide.
Explorer les solutions d'optimisation du temps de confirmation des transactions Ethereum : finalité à un seul slot et techniques de pré-confirmation
Discussion sur les améliorations du temps de confirmation des transactions Blockchain
Dans le domaine de la Blockchain, un temps de confirmation des transactions rapide est l'un des facteurs clés pour améliorer l'expérience utilisateur. Ethereum a réalisé des progrès significatifs au cours des cinq dernières années, et maintenant les transactions envoyées par les utilisateurs sur L1 peuvent généralement être confirmées en 5 à 20 secondes, ce qui est comparable à l'expérience de paiement par carte de crédit. Cependant, réduire davantage le temps de confirmation a encore de la valeur, en particulier pour les scénarios d'application nécessitant une latence inférieure à une seconde. Cet article explorera certaines options viables pour Ethereum afin d'améliorer le temps de confirmation des transactions.
Aperçu des technologies et idées existantes
finalité de slot unique
Actuellement, le mécanisme de consensus Gasper d'Ethereum adopte une architecture à un seul Slot et Epoch. Un Slot toutes les 12 secondes, certains validateurs votent sur la tête de la chaîne, et dans 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 similaires à ceux de l'algorithme de consensus PBFT, et après deux Epochs (12,8 minutes), ils fournissent une garantie économique forte appelée finalité.
Cependant, cette méthode présente deux problèmes majeurs : la complexité et un temps de confirmation finale plus long. Pour résoudre ces problèmes, le concept de finalité à un seul emplacement (Single Slot Finality, SSF) a été proposé, remplaçant l'architecture existante par un mécanisme de consensus similaire à Tendermint, permettant au bloc N d'être définitivement établi avant la génération du bloc N+1.
Le principal défi de la finalité à slot unique est qu'elle exige que chaque staker Ethereum publie deux messages toutes les 12 secondes, ce qui impose une charge énorme au réseau. Bien qu'il existe certaines solutions innovantes comme Orbit SSF qui tentent d'atténuer ce problème, les utilisateurs doivent encore attendre entre 5 et 20 secondes pour confirmer une transaction.
Préconfirmation Rollup
Avec le développement centré sur les rollups d'Ethereum, les solutions L2 telles que les rollups, les validiums et les plasmas peuvent offrir aux utilisateurs un niveau de sécurité équivalent à celui d'Ethereum à une plus grande échelle. Cette architecture permet à Ethereum L1 de se concentrer sur des fonctionnalités clés telles que la résistance à la censure, la fiabilité et la stabilité, tandis que L2 s'engage à répondre directement aux besoins des utilisateurs grâce à différentes technologies et cultures.
En théorie, L2 peut créer son propre réseau de "classificateurs décentralisés", où un petit groupe de validateurs signe des blocs toutes les quelques centaines de millisecondes et met en garantie ses actifs stakés. Cependant, cette méthode fait face au risque que les validateurs agissent de manière malveillante, comme signer des blocs conflictuels. Bien que nous ayons déjà vu des applications pratiques de versions centralisées, L2 progresse lentement dans le développement de réseaux de classement décentralisés.
Confirmation préalable de base
Pour résoudre les problèmes mentionnés ci-dessus, le concept de préconfirmations de base (Based preconfirmations) a été proposé. Cette méthode suppose que les proposeurs d'Ethereum sont des participants complexes hautement sensibles au MEV, et vise à tirer parti de leur expertise en incitant ces proposeurs à accepter la responsabilité de fournir des services de préconfirmation.
La préconfirmation de base a créé un protocole standardisé, permettant aux utilisateurs d'obtenir une garantie instantanée que la transaction sera incluse dans le prochain Bloc en payant des frais supplémentaires. Si le proposeur ne respecte pas ses engagements, il sera pénalisé. Ce mécanisme s'applique non seulement aux transactions L1, mais peut également fournir des services de préconfirmation pour les L2 basés sur Ethereum.
Les directions de développement futures
Supposons que nous ayons réalisé la finalité à un seul bloc et que nous utilisions une technologie similaire à Orbit pour réduire le nombre de validateurs par bloc, tout en maintenant un degré de décentralisation suffisant. La durée du bloc pourrait augmenter à 16 secondes, puis nous pourrions utiliser des pré-confirmations de rollup ou des pré-confirmations de base pour offrir une confirmation plus rapide aux utilisateurs. Cette architecture est essentiellement une structure d'epoch-slot.
La raison pour laquelle cette structure est difficile à éviter est que le temps nécessaire pour parvenir à un consensus général sur une question est bien inférieur au temps nécessaire pour atteindre le "finalité économique" maximale. Cette différence provient principalement du nombre et de la qualité des nœuds participants.
Pour L2, il existe actuellement trois stratégies raisonnables :
La question clé pour l'avenir est de savoir dans quelle mesure nous pouvons améliorer l'architecture epoch-and-slot native d'Ethereum. Si nous pouvons réduire le temps des slots à environ 1 seconde, la nécessité de la troisième stratégie sera considérablement réduite.
Actuellement, nous sommes encore loin des réponses finales à ces questions. La complexité des propositions de blocs, le potentiel de nouveaux designs tels qu'Orbit SSF, entre autres facteurs, présentent des incertitudes. Continuer à explorer et à optimiser ces solutions aidera à offrir une meilleure expérience aux utilisateurs L1 et L2, tout en simplifiant le travail des développeurs L2.