Auteur : Vitalik, fondateur d'Ethereum Traduction : 0xjs@金财经 ;

Une caractéristique importante d’une bonne expérience utilisateur blockchain est la rapidité des délais de confirmation des transactions. Aujourd’hui, Ethereum a parcouru un long chemin par rapport à ce qu’il était il y a cinq ans. Grâce au temps de blocage stable après EIP -1559 et Merge, les transactions envoyées par les utilisateurs sur L1 peuvent être confirmées de manière fiable dans un délai de 5 à 20 secondes. Cela équivaut à peu près à l’expérience de payer avec une carte de crédit. Cependant, il est utile d’améliorer encore l’expérience utilisateur, et certaines applications nécessitent des latences de plusieurs centaines de millisecondes, voire moins. Cet article présentera quelques options pratiques pour Ethereum.

Aperçu des idées et technologies existantes

Finalité à emplacement unique

Aujourd’hui, le consensus Gasper d’Ethereum adopte une architecture de slot et d’époque. Toutes les 12 secondes, un sous-ensemble de validateurs publie un vote sur l'en-tête du bloc de chaîne, et dans un délai de 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, qui fournit une garantie économique très stricte 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. Les principales raisons sont : (i) c'est complexe, avec de nombreux bugs d'interaction entre le mécanisme de vote slot par slot et le mécanisme de finalité époque par époque (ii) 12,8 minutes, c'est trop long, et personne ne veut attendre cela ; long.

La finalité à emplacement unique remplace cette architecture par un mécanisme plus similaire au consensus Tendermint, où le bloc N est terminé avant la génération du bloc N+1. La principale différence avec Tendermint est que nous conservons le mécanisme de « fuite inactive », qui permet à la chaîne de continuer à fonctionner et de récupérer si plus d'un tiers des validateurs se déconnectent.

Dessin de conception finale d'un seul réservoir

Le principal défi de SSF est qu’il semble naïvement impliquer que chaque acteur d’Ethereum doit publier deux messages toutes les 12 secondes, ce qui représente une charge importante pour la blockchain. Il existe des idées intelligentes pour atténuer ce problème, notamment la récente proposition Orbit SSF. Mais même ainsi, même si cela améliore considérablement l'expérience utilisateur en accélérant la « finalité », cela ne change rien au fait que les utilisateurs doivent attendre 5 à 20 secondes.

Pré-confirmation de cumul

Au cours des dernières années, Ethereum a suivi une feuille de route centrée sur le cumul, en concevant la couche de base Ethereum (« L1 ») autour de la prise en charge de la disponibilité des données et d'autres fonctionnalités qui peuvent ensuite être regroupées (avec les validiums et les plasmas), qui peuvent fournir utilisateurs avec le même niveau de sécurité qu’Ethereum, mais à une échelle beaucoup plus grande.

Cela crée une séparation des préoccupations au sein de l'écosystème Ethereum : Ethereum L1 peut se concentrer sur la résistance à la censure, la fiabilité, la stabilité et le maintien et l'amélioration de certains noyaux fonctionnels sous-jacents, tandis que L2 peut se concentrer sur l'atteinte des utilisateurs plus directement - via différents compromis culturels et techniques. . Mais si vous suivez cette voie, un problème inévitable surgit : L2 veut servir les utilisateurs qui souhaitent des confirmations plus rapides, dans un délai de 5 à 20 secondes.

Jusqu'à présent, L2 a été responsable, du moins rhétoriquement, de la création de son propre réseau de « commande décentralisée ». Un petit groupe de validateurs signent des blocs, peut-être toutes les quelques centaines de millisecondes, et mettent leur « enjeu » derrière ces blocs. Finalement, les en-têtes de ces blocs L2 sont publiés vers L1.

L'ensemble des validateurs L2 peut tricher : ils peuvent signer le bloc B1 avant de signer le bloc en conflit B2 et le valider dans la chaîne avant B1. Mais s’ils le font, ils se feront prendre et perdront leur mise. Nous avons vu des versions centralisées de cette approche dans la pratique, mais les rollups ont mis du temps à développer des réseaux de commande décentralisés. On pourrait dire qu'exiger que L2 effectue des commandes décentralisées est une affaire difficile : nous demandons aux cumuls de faire essentiellement le même travail que la création d'un tout nouveau L1. Pour cette raison et d’autres, Justin Drake a promu un moyen de donner à tous les L2 (ainsi que les L1) l’accès à un mécanisme de préconfirmation partagé à l’échelle d’Ethereum : la préconfirmation basée.

Basé sur une pré-confirmation

L’approche basée sur la pré-confirmation suppose que les proposants d’Ethereum seront des participants très sophistiqués pour des raisons liées au MEV. L'approche basée sur la pré-confirmation exploite cette complexité en incitant ces proposants matures à accepter la responsabilité de fournir la pré-confirmation en tant que service.

L'idée de base est de créer un protocole standardisé grâce auquel les utilisateurs peuvent fournir des frais supplémentaires en échange d'une garantie immédiate que la transaction sera incluse dans le bloc suivant et éventuellement obtenir une déclaration sur les résultats de l'exécution de la transaction. Si un proposant ne respecte pas une promesse faite à un utilisateur, il est puni.

Comme mentionné ci-dessus, le mécanisme de pré-confirmation Based offre une protection pour les transactions L1. Si le cumul est "basé", 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 voit-on réellement ici ?

Supposons que nous implémentions une finalité à emplacement unique. Nous utilisons une technologie de type 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 la mise minimale de 32 ETH. En conséquence, la durée du créneau peut progressivement augmenter jusqu’à 16 secondes. Ensuite, nous utilisons la pré-confirmation Rollup ou la pré-confirmation basée pour fournir aux utilisateurs des garanties plus rapides. Qu'avons-nous maintenant ? Une architecture d’époque et de slot.

Le mème « c'est le même graphique » est devenu galvaudé à ce stade, je vais donc simplement rassembler un vieux graphique que j'ai créé il y a quelques années aux côtés du graphique de pré-confirmation L2 pour décrire l'architecture des emplacements et des époques de Gasper et j'espère que cela fera comprendre le point.

Il y a une raison philosophique profonde pour laquelle il semble difficile d'éviter d'utiliser une architecture d'époque et de créneau : parvenir à un accord approximatif sur quelque chose prend intrinsèquement moins de temps que parvenir à un accord de « finalité économique » de force maximale sur quelque chose.

Une raison simple est le nombre de nœuds. Même si l'ancien compromis entre décentralisation linéaire, temps éventuel et frais généraux semble désormais plus doux grâce à l'agrégation BLS ultra-optimisée et à ZK-STARK dans un avenir proche, les points suivants restent fondamentalement vrais :

1. Un « accord approximatif » ne nécessite que quelques nœuds, tandis que la finalité économique nécessite une partie importante de tous les nœuds.

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

Dans l'Ethereum actuel, le créneau de 12 secondes est divisé en trois sous-créneaux pour (i) la publication et la distribution en bloc, (ii) l'attestation et (iii) l'agrégation des attestations. Si le nombre de prouveurs était beaucoup plus petit, nous pourrions le réduire à deux sous-créneaux et réduire la durée du créneau à 8 secondes. Un autre facteur qui est en réalité 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 la finalité), nous pourrions réduire ce délai à environ 2 secondes.

Par conséquent, je pense que (i) les architectures à emplacements et époques sont clairement correctes, mais (ii) toutes les architectures à emplacements et époques ne sont pas créées égales, et il est utile d'explorer plus complètement l'espace de conception. En particulier, il vaut la peine d'explorer des options qui ne sont pas aussi étroitement liées que celle de Gasper, mais qui présentent plutôt une séparation plus forte des préoccupations entre les deux mécanismes.

Que doit faire L2 ?

À mon avis, il existe actuellement trois stratégies raisonnables que L2 peut adopter :

1. Qu'il s'agisse d'un niveau technique ou d'un niveau spirituel, il doit être « basé ». Autrement dit, ils sont optimisés en tant que canaux de livraison pour les propriétés techniques de la couche de base d’Ethereum et sa valeur (forte décentralisation, résistance à la censure, etc.). Dans leur forme la plus simple, vous pouvez considérer ces cumuls comme des « fragments de marque », mais ils peuvent aussi être plus ambitieux que cela et impliquer une expérimentation approfondie de nouvelles conceptions de machines virtuelles et d'autres améliorations techniques.

2. Soyez fier d'être un « serveur avec un échafaudage blockchain » et profitez-en au maximum. Si vous commencez par le serveur, ajoutez alors (i) une preuve de validité STARK pour garantir que le serveur respecte les règles, (ii) garantir le droit de l'utilisateur de se retirer ou de forcer une transaction, et éventuellement (iii) la liberté de choix collectif, que ce soit via une sortie coordonnée à grande échelle ou la possibilité de changer de commande via le vote, vous avez alors bénéficié de nombreux avantages en chaîne tout en conservant l'essentiel de l'efficacité du serveur.

3. Compromis : Chaîne rapide avec 100 nœuds, Ethereum offre une interopérabilité et une sécurité supplémentaires. Il s’agit de la feuille de route actuelle de facto pour de nombreux projets L2.

Pour certaines applications (par exemple ENS, keystores, certains paiements), un temps de blocage de 12 secondes est suffisant. Pour les applications où cela ne suffit pas, la seule solution est une architecture slot-and-epoch. Dans les trois cas, « époque » est le SSF d'Ethereum (peut-être pourrions-nous redéfinir cet acronyme pour signifier autre chose que « emplacement unique », par exemple, cela pourrait être la finalité « Secure Speedy Finality »). Mais dans les trois cas ci-dessus, le « slot » est différent :

1. L’architecture native de slot et d’époque d’Ethereum

2. Pré-confirmation du serveur

3. Pré-confirmation par le comité

Une question clé est la suivante : dans quelle mesure pouvons-nous créer quelque chose dans la catégorie (1) ? En particulier, si les choses deviennent vraiment bonnes, la catégorie (3) ne semble plus avoir beaucoup de sens. La catégorie (2) existera toujours, au moins parce que tout ce qui est « basé » ne s'applique pas aux données hors chaîne L2, telles que Plasma et validium. Mais si l’architecture native de slot et d’époque d’Ethereum peut être raccourcie à un temps de « slot » (c’est-à-dire de pré-confirmation) d’une seconde, alors l’espace pour la catégorie (3) devient beaucoup plus petit.

Aujourd’hui, nous sommes loin d’avoir des réponses définitives à ces questions. Une question clé – à quel point les proposants de blocs deviendront sophistiqués – reste un domaine où règne une incertitude considérable. Les conceptions comme l'Orbit SSF sont très nouvelles, ce qui montre que les conceptions comme l'Orbit SSF appartiennent à une époque où l'espace de conception pour les conceptions à emplacements et à époques est encore sous-exploré. Plus nous avons d'options, mieux nous pouvons faire pour les utilisateurs de L1 et L2, et plus nous pouvons faciliter la vie des développeurs L2.