Améliorer la vitesse de confirmation des transactions Ethereum : explorer l'architecture epoch-slot
Le temps de confirmation des transactions rapide est l'un des éléments clés de l'expérience utilisateur de la blockchain. 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 comparable à l'expérience de paiement par carte de crédit. Cependant, réduire davantage le temps de confirmation reste précieux, 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
Le mécanisme de consensus Gasper actuellement utilisé par Ethereum est basé sur des structures de slot et d'epoch. Un slot toutes les 12 secondes, les validateurs votent à tour de rôle sur le head de la chaîne. Après deux epochs (12,8 minutes), les transactions atteignent un état de finalité.
Cette méthode présente deux problèmes principaux : d'une part, la complexité est élevée, et l'interaction entre le vote au niveau des slots et la finalité au niveau des époques est sujette à des erreurs ; d'autre part, le temps de confirmation finale de 12,8 minutes est trop long.
La finalité à un seul slot (SSF) propose de remplacer l'architecture existante par un mécanisme similaire à Tendermint, permettant la confirmation finale du 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 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 importante au réseau. Bien qu'il existe certaines solutions d'atténuation, comme la proposition Orbit SSF, les utilisateurs doivent toujours attendre entre 5 et 20 secondes pour que la transaction soit confirmée.
Préconfirmation de Rollup
Ethereum adopte une feuille de route centrée sur le rollup, 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. Cette architecture à plusieurs niveaux permet au L1 de se concentrer sur l'anticonformisme, la fiabilité et les fonctionnalités de base, tandis que le L2 est plus proche des besoins des utilisateurs.
L2 espère offrir aux utilisateurs une vitesse de confirmation plus rapide. 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. Cependant, exiger que tous les L2 mettent en œuvre un classement décentralisé semble un peu injuste.
Pré-confirmation de base
Le mécanisme de pré-confirmation de base suppose que les proposeurs d'Ethereum sont des participants MEV complexes. Il tire parti de leur expertise en incitant ces proposeurs à fournir des services de pré-confirmation.
Les utilisateurs peuvent payer des frais supplémentaires pour garantir que la transaction sera incluse dans le prochain bloc. Si le proposeur viole cette promesse, il sera sanctionné. Ce mécanisme s'applique à la fois aux transactions L1 et aux transactions L2 basées sur L1.
Perspectives de l'architecture epoch-slot
Si nous réalisons une finalité à un seul slot et utilisons une technologie similaire à Orbit pour réduire le nombre de validateurs par slot tout en maintenant une décentralisation suffisante, nous pourrions obtenir une architecture epoch-slot :
époque : utiliser le mécanisme SSF, confirmer définitivement un bloc toutes les 16 secondes.
slot : Utiliser le rollup pour des pré-confirmations ou des pré-confirmations de base, offrant une confirmation de transaction plus rapide.
Cette architecture reflète une raison philosophique profonde : atteindre un consensus approximatif nécessite moins de temps que d'atteindre le maximum d'"économie finale". Les principales raisons comprennent :
Nombre de 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.
Temps de collecte des signatures : l'augmentation du nombre de nœuds prolongera le temps de collecte des signatures.
Qualité des nœuds : Un sous-ensemble de nœuds spécialisés peut atteindre un accord approximatif plus rapidement.
Par conséquent, l'architecture epoch-slot semble inévitable, mais il pourrait y avoir des différences significatives entre les différentes implémentations. Il vaut la peine d'explorer davantage l'espace de conception, en particulier pour réaliser une séparation des préoccupations plus forte entre les deux mécanismes.
Choix de stratégie L2
L2 a actuellement trois stratégies principales :
"Basé sur" Ethereum : optimiser la technologie et les valeurs de la couche de base d'Ethereum.
"Serveur avec échafaudage blockchain" : allie l'efficacité du serveur et la sécurité de la blockchain.
Solution de compromis : combinaison de la rapidité de la chaîne et de la sécurité supplémentaire offerte par Ethereum.
Pour différents scénarios d'application, ces trois stratégies ont chacune leurs avantages. La question clé est de savoir à quel point l'architecture epoch-slot native d'Ethereum peut être efficace. Si le temps de slot peut être réduit à environ 1 seconde, l'espace pour la troisième stratégie pourrait être considérablement réduit.
Actuellement, nous sommes encore loin des réponses finales à ces questions. Le niveau de complexité des proposeurs de blocs reste incertain. De nouvelles conceptions comme Orbit SSF offrent des opportunités pour des explorations supplémentaires. Plus nous avons d'options, meilleure sera l'expérience pour les utilisateurs de L1 et 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.
12 J'aime
Récompense
12
4
Partager
Commentaire
0/400
MEVHunter
· 08-04 10:34
Chercheurs d'opportunités d'Arbitrage MEV, chercheurs de Prêts Flash, architectes de Bots d'arbitrage, écosystème Ethereum actif.
Voir l'originalRépondre0
Layer2Arbitrageur
· 08-04 10:19
mdr 12,8 min de finalité... je ne vais pas y arriver avec ces guerres de gas tbh
Voir l'originalRépondre0
YieldHunter
· 08-04 10:16
techniquement parlant, la finalité de 20 secondes est toujours nulle pour les degens, pour être honnête.
Voir l'originalRépondre0
BlockchainFries
· 08-04 10:15
Lève-toi vite ! L1 attend jusqu'à ce qu'il perde ses cheveux.
Explorer l'architecture epoch-slot d'Ethereum : une nouvelle direction pour accélérer la confirmation des transactions
Améliorer la vitesse de confirmation des transactions Ethereum : explorer l'architecture epoch-slot
Le temps de confirmation des transactions rapide est l'un des éléments clés de l'expérience utilisateur de la blockchain. 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 comparable à l'expérience de paiement par carte de crédit. Cependant, réduire davantage le temps de confirmation reste précieux, 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
Le mécanisme de consensus Gasper actuellement utilisé par Ethereum est basé sur des structures de slot et d'epoch. Un slot toutes les 12 secondes, les validateurs votent à tour de rôle sur le head de la chaîne. Après deux epochs (12,8 minutes), les transactions atteignent un état de finalité.
Cette méthode présente deux problèmes principaux : d'une part, la complexité est élevée, et l'interaction entre le vote au niveau des slots et la finalité au niveau des époques est sujette à des erreurs ; d'autre part, le temps de confirmation finale de 12,8 minutes est trop long.
La finalité à un seul slot (SSF) propose de remplacer l'architecture existante par un mécanisme similaire à Tendermint, permettant la confirmation finale du 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 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 importante au réseau. Bien qu'il existe certaines solutions d'atténuation, comme la proposition Orbit SSF, les utilisateurs doivent toujours attendre entre 5 et 20 secondes pour que la transaction soit confirmée.
Préconfirmation de Rollup
Ethereum adopte une feuille de route centrée sur le rollup, 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. Cette architecture à plusieurs niveaux permet au L1 de se concentrer sur l'anticonformisme, la fiabilité et les fonctionnalités de base, tandis que le L2 est plus proche des besoins des utilisateurs.
L2 espère offrir aux utilisateurs une vitesse de confirmation plus rapide. 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. Cependant, exiger que tous les L2 mettent en œuvre un classement décentralisé semble un peu injuste.
Pré-confirmation de base
Le mécanisme de pré-confirmation de base suppose que les proposeurs d'Ethereum sont des participants MEV complexes. Il tire parti de leur expertise en incitant ces proposeurs à fournir des services de pré-confirmation.
Les utilisateurs peuvent payer des frais supplémentaires pour garantir que la transaction sera incluse dans le prochain bloc. Si le proposeur viole cette promesse, il sera sanctionné. Ce mécanisme s'applique à la fois aux transactions L1 et aux transactions L2 basées sur L1.
Perspectives de l'architecture epoch-slot
Si nous réalisons une finalité à un seul slot et utilisons une technologie similaire à Orbit pour réduire le nombre de validateurs par slot tout en maintenant une décentralisation suffisante, nous pourrions obtenir une architecture epoch-slot :
Cette architecture reflète une raison philosophique profonde : atteindre un consensus approximatif nécessite moins de temps que d'atteindre le maximum d'"économie finale". Les principales raisons comprennent :
Par conséquent, l'architecture epoch-slot semble inévitable, mais il pourrait y avoir des différences significatives entre les différentes implémentations. Il vaut la peine d'explorer davantage l'espace de conception, en particulier pour réaliser une séparation des préoccupations plus forte entre les deux mécanismes.
Choix de stratégie L2
L2 a actuellement trois stratégies principales :
Pour différents scénarios d'application, ces trois stratégies ont chacune leurs avantages. La question clé est de savoir à quel point l'architecture epoch-slot native d'Ethereum peut être efficace. Si le temps de slot peut être réduit à environ 1 seconde, l'espace pour la troisième stratégie pourrait être considérablement réduit.
Actuellement, nous sommes encore loin des réponses finales à ces questions. Le niveau de complexité des proposeurs de blocs reste incertain. De nouvelles conceptions comme Orbit SSF offrent des opportunités pour des explorations supplémentaires. Plus nous avons d'options, meilleure sera l'expérience pour les utilisateurs de L1 et L2, tout en simplifiant le travail des développeurs de L2.