Transmettre le titre original 'Époques et créneaux jusqu'au bout : moyens de donner aux utilisateurs d'Éthereum des temps de confirmation de transaction plus rapides'

Une des propriétés importantes d'une bonne expérience utilisateur de la blockchain est la rapidité des temps de confirmation des transactions. Aujourd'hui, Ethereum s'est déjà beaucoup amélioré par rapport à il y a cinq ans. Merci à la combinaison de EIP-1559et des temps de blocs stables aprèsla Fusion, les transactions envoyées par les utilisateurs sur L1 se confirment de manière fiable en 5 à 20 secondes. C'est approximativement compétitif avec l'expérience de payer avec une carte de crédit. Cependant, il y a un intérêt à améliorer davantage l'expérience utilisateur, et il existe des applications qui nécessitent carrément des latences de l'ordre de centaines de millisecondes voire moins. Ce post passera en revue certaines des options pratiques qu'Ethereum propose.

Vue d'ensemble des idées et techniques existantes

Finalité d'un seul slot

Aujourd'hui, Ethereum’s Gasper le consensus utilise une architecture de créneau et d'époque. Chaque créneau de 12 secondes, un sous-ensemble de validateurs publie un vote sur la tête de la chaîne, et sur la durée de 32 créneaux (6,4 min), tous les validateurs ont une chance de voter une fois. Ces votes sont ensuite réinterprétés comme étant des messages dans un vague De type PBFTalgorithme de consensus, qui après deux époques (12,8 min) donne une assurance économique très solide appelée finalité.

Au cours des dernières années, nous sommes de plus en plus mal à l'aise avec l'approche actuelle. Les principales raisons sont que (i) c'est compliqué et qu'il y a de nombreux bugs d'interaction entre le mécanisme de vote slot-par-slot et le mécanisme de finalité époque-par-époque, et (ii) 12,8 minutes, c'est beaucoup trop long et personne ne veut attendre aussi longtemps.

La finalité d'un seul slot remplace cette architecture par un mécanisme beaucoup plus similaire àConsensus Tendermint, dans lequel le bloc N est finalisé avant que le bloc N+1 ne soit créé. La principale différence avec Tendermint est que nous conservons le “fuite d'inactivitémécanisme, qui permet à la chaîne de continuer et de récupérer si plus d'un tiers des validateurs se déconnectent.

Un diagramme de la principale proposition conception de finalité à un seul emplacement_

Le principal défi avec SSF est qu'à première vue, il semble impliquer que chaque validateur d'Ethereum doit publier deux messages toutes les 12 secondes, ce qui représenterait une charge importante pour la chaîne à gérer. Il y a idées intelligentespour savoir comment atténuer cela, y compris le très récentOrbit SSFproposition. Mais même ainsi, bien que cela améliore considérablement l'UX en accélérant la "finalité", cela ne change pas le fait que les utilisateurs doivent attendre 5 à 20 secondes.

Préconfirmations Rollup

Depuis quelques années, Ethereum suit une feuille de route centrée sur Rollup, concevoir la couche de base d'Ethereum (le «L1») autour du soutiendisponibilité des donnéeset d'autres fonctionnalités qui peuvent ensuite être utilisées par des protocoles de couche 2 comme rollups (mais aussi validiumsetplasmas) qui peut offrir aux utilisateurs le même niveau de sécurité que Ethereum, mais à une échelle beaucoup plus élevée.

Cela crée un séparation-des-concernsau sein de l'écosystème Ethereum : l'Ethereum L1 peut se concentrer sur la résistance à la censure, la fiabilité, la stabilité, et le maintien et l'amélioration d'un certain noyau de fonctionnalités de base, et les L2 peuvent se concentrer sur une approche plus directe pour atteindre les utilisateurs - à la fois à travers différentesculturelet les compromis technologiques. Mais si vous empruntez cette voie, une question inévitable se pose : les L2 veulent servir les utilisateurs qui souhaitent des confirmations beaucoup plus rapides que 5 à 20 secondes.

Jusqu'à présent, du moins dans la rhétorique, il a été de la responsabilité des L2 de créer leurs propres réseaux de "séquençage décentralisé". Un plus petit groupe de validateurs approuverait les blocs, peut-être une fois tous les quelques centaines de millisecondes, et ils engageraient leur "mise" derrière ces blocs. Finalement, les en-têtes de ces blocs L2 sont publiés sur L1.

Les ensembles de validateurs L2 pourraient tricher : ils pourraient d'abord signer le bloc B1, puis signer ultérieurement un bloc contradictoire B2 et le valider sur la chaîne avant B1. Mais s'ils le font, ils se feraient prendre et perdraient leurs dépôts. En pratique, nous avons vu des versions centralisées de cela, mais les rollups ont été lents à développer des réseaux de séquençage décentralisés. Et on peut soutenir que demander à tous les L2 de faire du séquençage décentralisé est un marché injuste : nous demandons essentiellement aux rollups de faire la plupart du travail comme pour créer un tout nouveau L1. Pour cette raison et d'autres, Justin Drake fait la promotion d'un moyen de donner à tous les L2 (ainsi qu'au L1) l'accès à un mécanisme de pré-confirmation partagé à l'échelle d'Ethereum : préconfirmations basées.

Préconfirmations basées

L'approche de préconfirmation basée suppose que les proposants d'Ethereum deviendront des acteurs très sophistiqués pour des raisons liées à l'EMV (voir icipour mon explication de MEV, et voir aussi le billets d'exécutionLa méthode de préconfirmation basée sur les propositions profite de cette sophistication en incitant ces proposeurs sophistiqués à accepter la responsabilité d'offrir des préconfirmations en tant que service.

L'idée de base est de créer un protocole standardisé selon lequel un utilisateur peut offrir des frais supplémentaires en échange d'une garantie immédiate que la transaction sera incluse dans le prochain bloc, avec éventuellement une déclaration sur les résultats de l'exécution de cette transaction. Si le proposant viole une promesse faite à un utilisateur, il peut être pénalisé.

Comme décrit, les préconfirmations basées fournissent des garanties aux transactions L1. Si les rollups sont « basé », alors tous les blocs L2 sont des transactions L1, et le même mécanisme peut être utilisé pour fournir des préconfirmations pour n'importe quel L2.

Qu'est-ce que nous regardons réellement ici ?

Supposons que nous implémentions la finalité d'un seul slot. Nous utilisonsOrbit-like techniques to reduce the number of validators signing per slot, but not too much, so that we can also make progress on the key goal of reducing the 32 ETH staking minimum. As a result, perhaps the slot time creeps upward, to 16 sec. We then use either rollup preconfirmations, or based preconfirmations, to give users faster assurances. What do we have now? An epoch-and-slot architecture.

Le mème "ce sont les mêmes images" est devenu assez utilisé à ce stade, alors je vais simplement mettre un vieux diagramme que j'ai dessiné il y a des années pour décrire l'architecture de slot et d'époque de Gasper et un diagramme des préconfirmations de L2 côte à côte, et espérons que cela fera passer le message.

Il y a une raison philosophique profonde pour laquelle les architectures d’époque et de fente semblent si difficiles à éviter : il faut intrinsèquement moins de temps pour arriver à un accord approximatif sur quelque chose, que pour parvenir à un accord de « finalité économique » au maximum.

Une simple raison pour laquelle est le nombre de nœuds. Alors que l'ancien linéaire @VitalikButerin/paramétrage-casper-le-trade-off-de-décentralisation / finalité / surcharge semble maintenant plus doux grâce à une agrégation BLS hyper-optimisée et, dans un avenir proche, les ZK-STARKs, il est toujours fondamentalement vrai que:

1. "L'accord approximatif" ne nécessite que quelques nœuds, tandis que la finalité économique nécessite une fraction significative de tous les nœuds.
2. Une fois que le nombre de nœuds dépasse une certaine taille, vous devez passer plus de temps à rassembler des signatures.

Aujourd'hui sur Ethereum, une tranche de 12 secondes est divisée en trois sous-tranches, pour (i) la publication et la distribution de blocs, (ii) l'attestation, et (iii) l'agrégation d'attestations. Si le nombre d'attestants était beaucoup plus faible, nous pourrions passer à deux sous-tranches et avoir un temps de tranche de 8 secondes. Un autre facteur, et réaliste plus important, est la "qualité" des nœuds. Si nous pouvions également compter sur un sous-ensemble professionnalisé de nœuds pour faire des accords approximatifs (et toujours utiliser l'ensemble complet de validateurs pour la finalité), nous pourrions raisonnablement réduire cela à environ 2 secondes.

Par conséquent, il me semble que (i) les architectures de slot et d'époque sont évidemment correctes, mais aussi (ii) que toutes les architectures de slot et d'époque ne se valent pas, et qu'il est précieux d'explorer plus pleinement l'espace de conception. En particulier, il vaut la peine d'explorer des options qui ne sont pas étroitement entrelacées comme Gasper, et où au contraire il existe une plus forte séparation des préoccupations entre les deux mécanismes.

Que devraient faire les L2s?

À mon avis, il existe trois stratégies raisonnables que les L2 doivent adopter pour le moment :

1. Être «basé», à la fois technologiquement et spirituellement. C'est-à-dire, ils optimisent pour être des conduits de passage pour les propriétés techniques de la couche de base d'Éthereum et ses valeurs (grande décentralisation, résistance à la censure, etc). Dans leur forme la plus simple, vous pourriez penser à ces rollups comme étant des «shards» de marque, mais ils peuvent aussi être beaucoup plus ambitieux que cela, et expérimenter assez lourdement avec de nouveaux designs de machine virtuelle et d'autres améliorations techniques.
2. Fièrement être un “serveur avec une structure de blockchain”, et en tirer le meilleur parti. Si vous commencez par un serveur, puis ajoutez (i) des preuves de validité STARK pour vous assurer que le serveur respecte les règles, (ii) des droits garantis pour l'utilisateur de sortir ou de forcer des transactions, et éventuellement (iii) la liberté de choix collective, que ce soit par une sortie de masse coordonnée ou par la capacité de voter pour changer le séquenceur, alors vous avez déjà obtenu bon nombre des avantages d'être onchain, tout en conservant la plupart des efficacités d'un serveur.
3. L'approche de compromis : une chaîne rapide de cent nœuds, avec Ethereum assurant une interopérabilité et une sécurité supplémentaires. C'est la feuille de route actuelle de facto de nombreux projets L2.

Pour certaines applications, (par exemple, ENS, keystores), certains paiements), un temps de bloc de 12 secondes suffit. Pour les applications qui ne le sont pas, la seule solution est une architecture slot-and-epoch. Dans les trois cas, les « époques » sont le SSF d’Ethereum (peut-être pouvons-nous retracer cet acronyme pour qu’il signifie autre chose que « machine à sous unique », par exemple, il pourrait s’agir de « Secure Speedy Finality »). Mais les « créneaux » sont quelque chose de différent dans chacun des trois cas ci-dessus :

1. Une architecture de créneau et d'époque native d'Ethereum
2. Préconfirmations du serveur
3. Préconfirmations du comité

Une question clé est de savoir à quel point pouvons-nous rendre quelque chose de bon dans la catégorie (1)? En particulier, s'il devient vraiment bon, alors on a l'impression que la catégorie (3) cesse d'avoir autant de sens. La catégorie (2) existera toujours, au moins parce que tout ce qui est "basé" ne fonctionne pas pour les L2 de données hors chaîne telles que les plasmas et les validiums. Mais si une architecture de créneaux et d'époques native d'Ethereum peut descendre à des créneaux de 1 seconde (c'est-à-dire pré-confirmation), alors l'espace pour la catégorie (3) devient un peu plus restreint.

Aujourd'hui, nous sommes loin d'avoir des réponses finales à ces questions. Une question clé - à quel point les proposants de blocs vont-ils devenir sophistiqués - reste un domaine où il y a encore beaucoup d'incertitude. Des conceptions comme Orbit SSFsont très récents, ce qui suggère que l'espace de conception des designs slot-and-epoch où quelque chose comme Orbit SSF est l'époque est encore largement inexploré. Plus nous avons d'options, mieux nous pouvons faire pour les utilisateurs à la fois sur L1 et sur L2, et plus nous pouvons simplifier le travail des développeurs L2.

Avertissement：

1. Cet article est repris de [Vitalik]. Transmettre le titre original « Epochs and slots all the way down: ways to give Ethereum users faster transaction confirmation times ». Tous les droits d'auteur appartiennent à l'auteur original [Vitalik]. Si vous avez des objections à cette réimpression, veuillez contacter le Porte Apprendrel'équipe s'en chargera rapidement.
2. Responsabilité de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.