Discussion sur des solutions pratiques pour améliorer le temps de confirmation des transactions Ethereum
Ces dernières années, Ethereum a réalisé des progrès significatifs en matière de vitesse de confirmation des transactions. Grâce à l'EIP-1559 et à la stabilité du temps de bloc après le passage au mécanisme PoS, les transactions envoyées par les utilisateurs sur L1 peuvent généralement être confirmées en 5 à 20 secondes, ce qui est à peu près équivalent à l'expérience de paiement par carte de crédit. Cependant, il est encore précieux d'améliorer l'expérience utilisateur, certaines applications exigeant même un temps de réponse en dessous de la seconde. Cet article explorera plusieurs solutions viables pour améliorer la vitesse de confirmation des transactions sur Ethereum.
Aperçu de la technologie existante
finalité à slot unique
Actuellement, le consensus Gasper d'Ethereum adopte une architecture de créneaux et de périodes. Un créneau toutes les 12 secondes, certains validateurs votent sur la tête de la chaîne, et tous les validateurs ont la possibilité de voter une fois dans 32 créneaux (6,4 minutes). Ces votes sont interprétés comme des messages dans un algorithme de consensus de type PBFT, et après deux périodes (12,8 minutes), cela offre une finalité avec de fortes garanties économiques.
Cette méthode présente deux problèmes majeurs : d'une part, la complexité est élevée, il existe de nombreux problèmes d'interaction entre le mécanisme de vote par fente et le mécanisme de finalité par cycle ; d'autre part, le temps de confirmation finale de 12,8 minutes est trop long et ne correspond pas aux attentes des utilisateurs.
La finalité à un seul slot (SSF) remplace cette architecture par un mécanisme similaire à Tendermint, permettant d'atteindre la confirmation finale avant la génération du bloc 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 lorsque plus d'un tiers des validateurs sont hors ligne.
Le principal défi du SSF réside dans le fait que chaque validateurs doit publier deux messages toutes les 12 secondes, ce qui constitue une lourde charge pour la chaîne. Bien qu'il existe quelques solutions d'atténuation, comme la récente proposition Orbit SSF, les utilisateurs doivent encore attendre entre 5 et 20 secondes pour confirmer une transaction.
Préconfirmation Rollup
Ethereum a suivi ces dernières années 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 (comme les rollups, validiums et plasmas) pour offrir des services avec un niveau de sécurité équivalent à celui d'Ethereum à plus grande échelle.
Cela a entraîné 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 la stabilité, ainsi que sur la maintenance et l'amélioration des fonctionnalités de base ; L2, quant à lui, sert les utilisateurs de manière plus directe à travers différentes cultures et technologies. Cependant, L2 souhaite offrir aux utilisateurs des temps de confirmation plus rapides que 5 à 20 secondes.
Théoriquement, la création d'un réseau de tri décentralisé est de la responsabilité de L2. Un petit groupe de validateurs pourrait signer des blocs toutes les quelques centaines de millisecondes et mettre en jeu des actifs comme garantie. Ces en-têtes de blocs L2 seront finalement publiés sur L1.
Cependant, exiger que tous les L2 mettent en œuvre un tri décentralisé semble un peu injuste, c'est comme demander aux rollups de réaliser 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) partagent un mécanisme de pré-confirmation à l'intérieur de l'Éther : la pré-confirmation de base.
Préconfirmation de base
La méthode de pré-confirmation de base suppose que les proposeurs d'Ethereum sont des participants complexes liés au MEV. Elle exploite cette complexité en incitant ces proposeurs à accepter la responsabilité de fournir des services de pré-confirmation.
Cette méthode crée 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'un engagement sur le résultat de l'exécution de cette transaction. Si le proposant viole cet engagement, il sera soumis à des pénalités.
Ce mécanisme s'applique non seulement aux transactions L1, mais pour les rollups "basés sur" Ethereum, tous les blocs L2 sont en réalité des transactions L1, donc le même mécanisme peut fournir un service de pré-confirmation pour n'importe quel L2.
Architecture potentielle future
Supposons que nous ayons réalisé une finalité de slot unique et que nous utilisions une technologie similaire à Orbit pour réduire le nombre de validateurs signant chaque slot, tout en maintenant une décentralisation suffisante pour abaisser le seuil de mise. La durée des slots pourrait être augmentée à 16 secondes, puis nous utilisons une pré-confirmation par rollup ou une pré-confirmation de base pour fournir des confirmations plus rapides aux utilisateurs. Au final, nous obtenons une architecture de cycle-slot.
Cette architecture est difficile à éviter parce que le temps nécessaire pour parvenir à un consensus approximatif sur une chose est bien inférieur au temps nécessaire pour atteindre le "finalité économique" maximale. Les raisons incluent :
"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.
Lorsque le nombre de nœuds dépasse une certaine taille, le temps nécessaire pour collecter les signatures augmente de manière significative.
Dans l'Ethereum actuel, le slot de 12 secondes est divisé en trois sous-slots : publication et distribution des blocs, preuve, agrégation des preuves. Si nous réduisons considérablement le nombre de validateurs, nous pouvons passer à deux sous-slots, réalisant un temps de slot de 8 secondes. Si nous pouvons compter sur un sous-ensemble de nœuds spécialisés pour atteindre un protocole approximatif (tout en utilisant toujours l'ensemble complet des validateurs pour déterminer la finalité), il est même possible de réduire le temps à environ 2 secondes.
Ainsi, l'architecture cycle-slot semble inévitable, mais il existe des différences entre les différentes implementations. Une direction intéressante à explorer serait d'établir une séparation des préoccupations plus forte entre les deux mécanismes, plutôt que d'être étroitement couplés comme avec Gasper.
Choix de stratégie L2
Actuellement, il existe trois stratégies raisonnables pour L2 :
Sur le plan technique et conceptuel, ils sont tous "basés" sur Ethereum. Ces rollups peuvent être considérés comme des "shards de marque", et pourraient également faire l'objet de nombreuses expérimentations sur la conception de nouvelles machines virtuelles et d'autres améliorations technologiques.
Devenir un "serveur avec une structure de blockchain". En ajoutant des preuves de validité STARK, en garantissant les droits de sortie des utilisateurs, en soutenant le choix collectif, etc., obtenir la plupart des avantages de la mise en chaîne tout en conservant les avantages d'efficacité du serveur.
Méthode de compromis : établir une chaîne rapide avec cent nœuds, tout en utilisant Ethereum pour fournir une interopérabilité et une sécurité supplémentaires. C'est la feuille de route actuelle de nombreux projets L2.
Pour certaines applications (comme ENS, le stockage de clés, certains protocoles de paiement), un temps de bloc de 12 secondes est suffisant. Pour d'autres applications, la seule solution est l'architecture cycle-slot. Dans cette architecture, "cycle" est le SSF d'Ethereum, tandis que le "slot" varie selon les différentes situations :
Architecture de cycle et de créneau native 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 elle performe exceptionnellement, la signification de la troisième solution sera réduite. La deuxième solution existera toujours, car toutes les solutions "basées sur" Ethereum ne s'appliquent pas aux données off-chain L2 telles que plasmas et validiums. Si l'architecture natale d'Ethereum avec ses cycles et slots peut réduire le temps de slot à 1 seconde, l'espace pour la troisième solution sera considérablement réduit.
Actuellement, nous sommes encore loin des réponses finales à ces questions. Une incertitude clé est de savoir à quel point les proposeurs de blocs deviendront complexes. Des conceptions novatrices comme Orbit SSF nous offrent plus d'espace d'exploration, comme l'utilisation d'Orbit SSF comme période dans une architecture à périodes et créneaux. Plus nous avons d'options, mieux nous pouvons servir 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.
17 J'aime
Récompense
17
5
Partager
Commentaire
0/400
¯\_(ツ)_/¯
· Il y a 14h
Cette vitesse n'est même pas aussi rapide que le pow ?
Voir l'originalRépondre0
LightningAllInHero
· 08-02 19:40
Encore à jouer avec la vitesse de confirmation... ça ne sert à rien.
Voir l'originalRépondre0
rekt_but_resilient
· 08-02 19:33
L2 est fait pour être plus rapide.
Voir l'originalRépondre0
ValidatorViking
· 08-02 19:30
ces délais de finalité font encore paraître ragnarök rapide... l'infrastructure des nœuds a besoin d'un test de résistance sérieux avant d'apporter des ajustements sophistiqués au consensus, à vrai dire
Solution pour accélérer la confirmation des transactions Ethereum : une discussion complète sur le passage de SSF à la pré-confirmation L2
Discussion sur des solutions pratiques pour améliorer le temps de confirmation des transactions Ethereum
Ces dernières années, Ethereum a réalisé des progrès significatifs en matière de vitesse de confirmation des transactions. Grâce à l'EIP-1559 et à la stabilité du temps de bloc après le passage au mécanisme PoS, les transactions envoyées par les utilisateurs sur L1 peuvent généralement être confirmées en 5 à 20 secondes, ce qui est à peu près équivalent à l'expérience de paiement par carte de crédit. Cependant, il est encore précieux d'améliorer l'expérience utilisateur, certaines applications exigeant même un temps de réponse en dessous de la seconde. Cet article explorera plusieurs solutions viables pour améliorer la vitesse de confirmation des transactions sur Ethereum.
Aperçu de la technologie existante
finalité à slot unique
Actuellement, le consensus Gasper d'Ethereum adopte une architecture de créneaux et de périodes. Un créneau toutes les 12 secondes, certains validateurs votent sur la tête de la chaîne, et tous les validateurs ont la possibilité de voter une fois dans 32 créneaux (6,4 minutes). Ces votes sont interprétés comme des messages dans un algorithme de consensus de type PBFT, et après deux périodes (12,8 minutes), cela offre une finalité avec de fortes garanties économiques.
Cette méthode présente deux problèmes majeurs : d'une part, la complexité est élevée, il existe de nombreux problèmes d'interaction entre le mécanisme de vote par fente et le mécanisme de finalité par cycle ; d'autre part, le temps de confirmation finale de 12,8 minutes est trop long et ne correspond pas aux attentes des utilisateurs.
La finalité à un seul slot (SSF) remplace cette architecture par un mécanisme similaire à Tendermint, permettant d'atteindre la confirmation finale avant la génération du bloc 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 lorsque plus d'un tiers des validateurs sont hors ligne.
Le principal défi du SSF réside dans le fait que chaque validateurs doit publier deux messages toutes les 12 secondes, ce qui constitue une lourde charge pour la chaîne. Bien qu'il existe quelques solutions d'atténuation, comme la récente proposition Orbit SSF, les utilisateurs doivent encore attendre entre 5 et 20 secondes pour confirmer une transaction.
Préconfirmation Rollup
Ethereum a suivi ces dernières années 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 (comme les rollups, validiums et plasmas) pour offrir des services avec un niveau de sécurité équivalent à celui d'Ethereum à plus grande échelle.
Cela a entraîné 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 la stabilité, ainsi que sur la maintenance et l'amélioration des fonctionnalités de base ; L2, quant à lui, sert les utilisateurs de manière plus directe à travers différentes cultures et technologies. Cependant, L2 souhaite offrir aux utilisateurs des temps de confirmation plus rapides que 5 à 20 secondes.
Théoriquement, la création d'un réseau de tri décentralisé est de la responsabilité de L2. Un petit groupe de validateurs pourrait signer des blocs toutes les quelques centaines de millisecondes et mettre en jeu des actifs comme garantie. Ces en-têtes de blocs L2 seront finalement publiés sur L1.
Cependant, exiger que tous les L2 mettent en œuvre un tri décentralisé semble un peu injuste, c'est comme demander aux rollups de réaliser 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) partagent un mécanisme de pré-confirmation à l'intérieur de l'Éther : la pré-confirmation de base.
Préconfirmation de base
La méthode de pré-confirmation de base suppose que les proposeurs d'Ethereum sont des participants complexes liés au MEV. Elle exploite cette complexité en incitant ces proposeurs à accepter la responsabilité de fournir des services de pré-confirmation.
Cette méthode crée 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'un engagement sur le résultat de l'exécution de cette transaction. Si le proposant viole cet engagement, il sera soumis à des pénalités.
Ce mécanisme s'applique non seulement aux transactions L1, mais pour les rollups "basés sur" Ethereum, tous les blocs L2 sont en réalité des transactions L1, donc le même mécanisme peut fournir un service de pré-confirmation pour n'importe quel L2.
Architecture potentielle future
Supposons que nous ayons réalisé une finalité de slot unique et que nous utilisions une technologie similaire à Orbit pour réduire le nombre de validateurs signant chaque slot, tout en maintenant une décentralisation suffisante pour abaisser le seuil de mise. La durée des slots pourrait être augmentée à 16 secondes, puis nous utilisons une pré-confirmation par rollup ou une pré-confirmation de base pour fournir des confirmations plus rapides aux utilisateurs. Au final, nous obtenons une architecture de cycle-slot.
Cette architecture est difficile à éviter parce que le temps nécessaire pour parvenir à un consensus approximatif sur une chose est bien inférieur au temps nécessaire pour atteindre le "finalité économique" maximale. Les raisons incluent :
Dans l'Ethereum actuel, le slot de 12 secondes est divisé en trois sous-slots : publication et distribution des blocs, preuve, agrégation des preuves. Si nous réduisons considérablement le nombre de validateurs, nous pouvons passer à deux sous-slots, réalisant un temps de slot de 8 secondes. Si nous pouvons compter sur un sous-ensemble de nœuds spécialisés pour atteindre un protocole approximatif (tout en utilisant toujours l'ensemble complet des validateurs pour déterminer la finalité), il est même possible de réduire le temps à environ 2 secondes.
Ainsi, l'architecture cycle-slot semble inévitable, mais il existe des différences entre les différentes implementations. Une direction intéressante à explorer serait d'établir une séparation des préoccupations plus forte entre les deux mécanismes, plutôt que d'être étroitement couplés comme avec Gasper.
Choix de stratégie L2
Actuellement, il existe trois stratégies raisonnables pour L2 :
Sur le plan technique et conceptuel, ils sont tous "basés" sur Ethereum. Ces rollups peuvent être considérés comme des "shards de marque", et pourraient également faire l'objet de nombreuses expérimentations sur la conception de nouvelles machines virtuelles et d'autres améliorations technologiques.
Devenir un "serveur avec une structure de blockchain". En ajoutant des preuves de validité STARK, en garantissant les droits de sortie des utilisateurs, en soutenant le choix collectif, etc., obtenir la plupart des avantages de la mise en chaîne tout en conservant les avantages d'efficacité du serveur.
Méthode de compromis : établir une chaîne rapide avec cent nœuds, tout en utilisant Ethereum pour fournir une interopérabilité et une sécurité supplémentaires. C'est la feuille de route actuelle de nombreux projets L2.
Pour certaines applications (comme ENS, le stockage de clés, certains protocoles de paiement), un temps de bloc de 12 secondes est suffisant. Pour d'autres applications, la seule solution est l'architecture cycle-slot. Dans cette architecture, "cycle" est le SSF d'Ethereum, tandis que le "slot" varie selon les différentes situations :
La question clé est de savoir à quel point la première solution peut bien fonctionner. Si elle performe exceptionnellement, la signification de la troisième solution sera réduite. La deuxième solution existera toujours, car toutes les solutions "basées sur" Ethereum ne s'appliquent pas aux données off-chain L2 telles que plasmas et validiums. Si l'architecture natale d'Ethereum avec ses cycles et slots peut réduire le temps de slot à 1 seconde, l'espace pour la troisième solution sera considérablement réduit.
Actuellement, nous sommes encore loin des réponses finales à ces questions. Une incertitude clé est de savoir à quel point les proposeurs de blocs deviendront complexes. Des conceptions novatrices comme Orbit SSF nous offrent plus d'espace d'exploration, comme l'utilisation d'Orbit SSF comme période dans une architecture à périodes et créneaux. Plus nous avons d'options, mieux nous pouvons servir les utilisateurs de L1 et L2, tout en simplifiant le travail des développeurs de L2.