Auteur original |Vitalik

Compilation | Odaily Planet Quotidien Nan Zhi

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 techniques existantes

finalité à emplacement unique

Actuellement, le consensus Gasper d’Ethereum utilise un seul slot (Slot) et une architecture 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.

Le principal défi de la finalité à emplacement unique est que cela signifie que chaque participant à Ethereum doit publier deux messages toutes les 12 secondes, ce qui représente une charge importante 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.

Pré-confirmation de cumul

Ethereum a suivi une feuille de route centrée sur le cumul au cours des dernières années, 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 cumuls, les validiums et les plasmas. offrir aux utilisateurs 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é et le maintien et l'amélioration des fonctionnalités de base d'une certaine couche de base, tandis que L2 se concentre sur la communication plus directe à travers différentes cultures et technologies. aux utilisateurs. 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, en théorie du moins, il incombait à 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.

Mais l'ensemble des validateurs L2 peut commettre une « fraude » : ils peuvent d'abord signer le bloc B1, puis signer un bloc B2 en conflit et le valider dans la chaîne avant B1. Mais s’ils le font, ils se feront surprendre et perdront les actifs promis. Nous avons effectivement vu des exemples pratiques de versions centralisées, mais le rollup, en revanche, a mis du temps à développer des réseaux de commande décentralisés. On pourrait dire qu'il est injuste d'exiger que toutes les L2 soient décentralisées : nous demandons au rollup de faire presque le même travail que de créer une toute nouvelle L1. En tant que tel, Justin Drake a promu un moyen pour tous les L2 (ainsi que L1) d'utiliser un mécanisme de pré-confirmation partagé à l'échelle d'Ethereum : la pré-confirmation de base.

Pré-confirmation de base

L’approche des préconfirmations basées suppose que les proposants d’Ethereum sont des participants hautement sophistiqués associés au MEV. Les approches basées sur la préconfirmation exploitent cette complexité en incitant ces proposants complexes à 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 instantanément qu'une transaction sera incluse dans le bloc suivant, ainsi qu'une réclamation sur les résultats de l'exécution de 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.

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.

Il y a une raison philosophique profonde pour laquelle l'architecture d'époque et de créneau semble si difficile à éviter : il faut moins de temps pour se mettre d'accord sur quelque chose que pour parvenir à un accord sur quelque chose avec le plus grand degré de « finalité économique ».

Une raison simple est le nombre de nœuds. Bien que l'ancien compromis entre décentralisation linéaire, temps de finalité et frais généraux semble désormais modéré en raison de l'agrégation BLS ultra-optimisée et des prochains ZK-STARK, les raisons suivantes ne peuvent être ignorées :

  • Le « consensus approximatif » ne nécessite qu’un petit nombre de nœuds, tandis que la finalité économique nécessite une grande majorité de nœuds.

  • Une fois que le nombre de nœuds dépasse une certaine taille, vous devez consacrer plus de temps à collecter des signatures.

Dans l'Ethereum actuel, le créneau de 12 secondes est divisé en trois sous-créneaux : publication et distribution en bloc, attestation et agrégation d'attestation. Si le nombre de prouveurs est considérablement réduit, nous pouvons le réduire à deux sous-créneaux et utiliser un créneau de 8 secondes. Un autre facteur, plus réaliste et plus important, est la « qualité » du nœud. Un autre facteur plus important est la « qualité » du nœud. Si nous pouvions également nous appuyer sur un sous-ensemble spécialisé de nœuds pour parvenir à un accord approximatif (tout en utilisant l'ensemble complet des validateurs pour déterminer la finalité), nous pourrions réduire ce résultat à environ 2 secondes.

Donc, à mon avis, l'architecture d'époque et d'emplacement est clairement correcte, mais toutes les architectures d'époque et d'emplacement ne sont pas créées égales, et il est utile d'explorer plus complètement l'espace de conception. Une direction digne de recherches plus approfondies n'est pas aussi étroitement couplée que dans Gasper, mais avec une séparation plus forte des préoccupations entre les deux mécanismes.

Que doit faire L2 ?

À mon avis, L2 dispose actuellement de trois stratégies raisonnables :

  • "Basé" à la fois techniquement et spirituellement. C’est-à-dire qu’ils optimisent les propriétés techniques de la couche de base d’Ethereum et ses valeurs (forte décentralisation, résistance à la censure, etc.). Dans leur forme la plus simple, vous pouvez considérer ces rollups comme des « fragments de marque », mais ils peuvent également être beaucoup plus ambitieux, expérimentant massivement de nouvelles conceptions de machines virtuelles et d'autres améliorations techniques.

  • Devenez un « serveur avec échafaudage blockchain » et profitez-en au maximum. Si vous commencez avec un serveur et ajoutez ensuite des preuves de validité STARK pour vous assurer que le serveur respecte les règles ; pour garantir le droit des utilisateurs de retirer ou de forcer les transactions et la liberté de choix collectif, soit par des retraits massifs coordonnés, soit en modifiant ceux du donneur d'ordre ; votez, alors vous l'avez. Il permet d'obtenir la plupart des avantages de la liaison montante tout en conservant l'essentiel de l'efficacité du serveur.

  • Le juste milieu : une chaîne rapide avec une centaine de nœuds, Ethereum offre une interopérabilité et une sécurité supplémentaires. Il s’agit de la feuille de route de facto actuelle pour de nombreux projets L2.

Pour certaines applications (par exemple ENS, stockage de clés, certains protocoles de paiement), un temps de bloc de 12 secondes est suffisant. Pour les applications où cela n’est pas applicable, la seule solution est une architecture à époque et slot. Dans trois cas, « l’époque » est le SSF d’Ethereum, mais le slot est différent dans chacun des trois cas ci-dessus :

  • Une architecture d'époque et de slot native d'Ethereum

  • Pré-confirmation du serveur

  • préconfirmation du comité

Une question clé est la suivante : dans quelle mesure pouvons-nous être bons dans la catégorie 1 ? En particulier, si les choses deviennent vraiment bonnes, il semble que la catégorie 3 ne signifiera pas grand-chose. Parce que toutes les solutions « basées » ne fonctionnent pas avec des données L2 hors chaîne telles que les plasmas et les validiums, la catégorie 2 existera toujours. Si une architecture d’époque et de slot native d’Ethereum peut être réduite à un créneau de 1 seconde, alors l’espace pour la catégorie 3 deviendra beaucoup plus petit.

Aujourd’hui, nous sommes loin d’avoir des réponses définitives à ces questions. Une question clé est de savoir dans quelle mesure les propositions de blocs deviendront complexes, ce qui reste un domaine d’incertitude considérable. Les conceptions comme Orbit SSF sont très nouvelles, de sorte que l'espace de conception de schémas tels que l'utilisation d'Orbit SSF comme époque dans l'époque et l'emplacement mérite toujours une exploration approfondie. Plus nous avons d'options, mieux nous pouvons faire pour les utilisateurs de L1 et L2, et nous pouvons faciliter la vie des développeurs L2.