Vitalik prend en charge l'époque et le créneau de l'itinéraire : offrant un temps de confirmation de transaction plus rapide pour Ethereum

Auteur : Vitalik Compilé par : Nan Zhi, Odaily Planet Daily L'un des attributs importants d'une bonne expérience utilisateur blockchain est le temps de confirmation rapide des transactions. Aujourd’hui, Ethereum est bien amélioré par rapport à ce qu’il était il y a cinq ans. Grâce à EIP-1559 et au temps de blocage stable après le passage au PoS (The Merge), les transactions envoyées par les utilisateurs sur L1 peuvent généralement être confirmées dans un délai de 5 à 20 secondes, ce qui équivaut à peu près à l'expérience d'un paiement avec une carte de crédit. Cependant, il est utile d’améliorer encore l’expérience utilisateur, et certaines applications nécessitent même des latences de plusieurs centaines de millisecondes ou moins. Cet article explorera quelques options pratiques pour améliorer les délais de confirmation des transactions dans Ethereum. Aperçu des idées et technologies existantes Finalité à emplacement unique Actuellement, le consensus Gasper d'Ethereum utilise une architecture à emplacement unique (Slot) et Epoch. Toutes les 12 secondes par créneau, un sous-ensemble de validateurs votent en tête de chaîne, et toutes les 32 créneaux (6,4 minutes), tous les validateurs ont la possibilité de voter une fois. Ces votes sont ensuite réinterprétés sous forme de messages dans un algorithme de consensus similaire au PBFT, donnant une garantie économique très forte appelée finalité après deux époques (12,8 minutes). Au cours des dernières années, nous sommes devenus de plus en plus insatisfaits de notre approche actuelle. Il y a deux raisons principales à cela. Premièrement, cette méthode est compliquée et il existe de nombreuses erreurs d'interaction entre le mécanisme de vote d'emplacement à emplacement et le mécanisme de finalité d'époque à époque. Deuxièmement, 12,8 minutes, c'est trop long et personne ne veut. attendre aussi longtemps. Single Slot Finality (SSF) remplace cette architecture par un mécanisme similaire au consensus Tendermint, où le bloc N est finalisé avant la génération du bloc N+1. La principale différence avec Tendermint est que nous conservons le mécanisme de « fuite d'inactivité », qui permet à la chaîne de continuer à fonctionner et de récupérer si plus d'1/3 des validateurs sont hors ligne. (Remarque : la fuite d'inactivité est un mécanisme dans PoS conçu pour punir les validateurs qui sont inactifs depuis longtemps. Une fois marqués comme inactifs, leur ETH promis continuera à être puni. Tendermint est un algorithme de consensus byzantin efficace et sécurisé, tolérant aux pannes, qui permet des confirmations de transaction rapides et garantit que le système blockchain peut toujours fonctionner correctement dans le cas où certains nœuds sont malveillants ou hors ligne. Le principal défi avec la finalité à emplacement unique est que cela signifie que toutes les 12 secondes pour chaque jalonnant Ethereum, deux messages doivent être envoyés. être publié, ce qui représente une lourde charge sur la chaîne. Il existe des idées intelligentes pour atténuer ce problème, notamment la récente proposition Orbit SSF. Bien que cela accélère considérablement la « finalité » pour améliorer l’expérience utilisateur, cela ne change rien au fait que les utilisateurs doivent attendre 5 à 20 secondes. (Remarque : la finalité et la transaction regroupée dans un bloc et confirmée ne sont pas le même événement. Lorsque la transaction est confirmée mais que la finalité n'est pas atteinte, un fork ou un rollback peut se produire.)

Pré-confirmation de rollup

Depuis plusieurs années, Ethereum suit une feuille de route centrée sur le rollup, en concevant la couche de base Ethereum (L1) pour prendre en charge la disponibilité des données et d'autres fonctionnalités, qui sont ensuite mises à la disposition des protocoles L2 tels que les rollups, les validiums et les plasmas pour permettre utilisateurs avec le même niveau de sécurité qu’Ethereum à plus grande échelle.

Cela crée une séparation des préoccupations au sein de l'écosystème Ethereum : Ethereum L1 se concentre sur la résistance à la censure, la fiabilité, la stabilité, ainsi que sur le maintien et l'amélioration des fonctions de base d'une certaine couche de base, tandis que L2 se concentre sur la mise à jour à travers différentes cultures et technologies. directement. Mais si vous suivez cette voie, un problème inévitable surgit : L2 souhaite fournir aux utilisateurs des confirmations plus rapides que 5 à 20 secondes.

Jusqu’à présent, du moins en théorie, il est de la responsabilité de L2 de créer son propre réseau de « séquenceurs décentralisés ». Un petit groupe de validateurs peut signer des blocs toutes les quelques centaines de millisecondes et miser sur ces blocs. Finalement, les fichiers d'en-tête de ces morceaux L2 sont publiés sur L1.

1. Il y a un risque de "fraude" dans l'ensemble du validateur L2 : signez d'abord le bloc B1, puis signez le bloc B2 en conflit et soumettez-le d'abord à la chaîne.

2. Rollup a mis du temps à mettre en place un réseau de tri décentralisé.
3. Exiger un tri décentralisé de toutes les L2 est déraisonnable et équivaut à exiger que le rollup fasse le même travail que la création d'une nouvelle L1.
4. Justin Drake a proposé d'utiliser un mécanisme de pré-confirmation de base qui permettrait à tous les L2 (et L1) de partager les pré-confirmations à l'échelle d'Ethereum.

Pré-Confirmation de base

La Pré-Confirmation de base suppose que les proposants d'Ethereum sont des acteurs très sophistiqués liés au MEV. L'approche exploite cette complexité en incitant les proposants à accepter la responsabilité de fournir des services de pré-confirmation.

L'idée de base de cette approche est de créer un protocole standardisé dans lequel les utilisateurs peuvent fournir des frais supplémentaires pour garantir une garantie instantanée qu'une transaction sera incluse dans le bloc suivant, ainsi qu'une déclaration sur les résultats de l'exécution. cette transaction. Si un proposant ne respecte pas une promesse faite à un utilisateur, celui-ci peut être réduit.

Comme indiqué, les transactions L1 sont garanties sur la base d'une pré-confirmation. Si les cumuls sont « basés », alors tous les blocs L2 sont des transactions L1, donc le même mécanisme peut être utilisé pour fournir une pré-confirmation pour n'importe quel L2.

(Remarque : les proposants d'Ethereum peuvent regrouper une série de transactions en lots et les regrouper en blocs via le mécanisme de frais, garantissant ainsi l'exécution et l'ordre des transactions. Par exemple, la pince bien connue garantit que l'achat et la vente avant une certaine transaction Vendre ​​plus tard. Vitalik La solution proposée ici est conceptuellement cohérente, ce proposant verrouillant les résultats de trading à l'avance et accélérant l'exécution)

Que regardons-nous réellement ?

Supposons que nous atteignions la finalité d'un seul emplacement. Nous utilisons une technologie similaire à Orbit pour réduire le nombre de validateurs signant par emplacement, mais pas trop afin que nous puissions également progresser sur l'objectif clé de réduire le minimum de mise de 32 ETH. La durée du créneau peut être augmentée à 16 secondes, puis nous utilisons une pré-confirmation cumulative ou une pré-confirmation de base pour fournir aux utilisateurs une confirmation plus rapide. Ce que nous avons obtenu au final : une architecture de slot d’époque. fenyeLa raison philosophique de l'architecture d'époque et de créneau

architecture d'époque et de créneauLa raison pour laquelle l'architecture d'époque et de créneau est si inévitable est qu'il faut moins de temps pour parvenir à un consensus approximatif que pour parvenir à un accord sur le finalité économique de quelque chose.

Nombre de nœuds et temps supplémentaire

Le nombre de nœuds est un facteur clé :

• Un consensus approximatif ne nécessite que quelques nœuds, tandis que la finalité économique nécessite la participation d'une majorité de nœuds.
• Une fois que le nombre de nœuds dépasse une certaine échelle, le temps nécessaire à la collecte des signatures augmentera.

Optimisation du temps de créneau dans Ethereum

Le temps de créneau de 12 secondes dans Ethereum peut être divisé en trois sous-créneaux :

• Libération et distribution de blocs
• Preuve de production de blocs
• Agrégation de preuves

Réussi En réduisant le nombre de prouveurs et en exploitant un sous-ensemble spécialisé de nœuds, le temps de créneau peut être réduit à environ 2 secondes.

L'amélioration de l'architecture d'époque et d'emplacement

L'architecture d'époque et d'emplacement est raisonnable, mais cela vaut la peine d'explorer une conception plus optimisée :

• Séparation des préoccupations et réduction du couplage entre les mécanismes.

La stratégie de L2

L2 a actuellement trois stratégies raisonnables :

• Natif d'Ethereum : Optimiser la technologie et les valeurs d'Ethereum.
• Architecture du serveur : Utilisez l'échafaudage blockchain pour trouver un équilibre entre l'efficacité du serveur et la sécurité de la blockchain.
• Commerce : Chaîne rapide, sécurité assurée par Ethereum.

slot time et SSF

Certaines applications ont un slot time de 12 secondes ce qui est suffisant. Pour d'autres applications, une architecture d'époque et d'emplacement est requise. Trois types de slots :

• Architecture native d'époque et de slot d'Ethereum
• Pré-confirmation du serveur
• Pré-confirmation du comité

Conclusion

Il est important d'explorer l'espace de conception de l'architecture d'époque et de slot pour optimiser l’expérience utilisateur L1 et L2 et simplifier le développement L2.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!