Auteur original |Vitalik

Compilation | Odaily Planet Daily Nan Zhi

L’un des attributs importants d’une bonne expérience utilisateur Blockchain est la rapidité des délais de confirmation des transactions. Aujourd’hui, Ethereum est une grande amélioration par rapport à il y a cinq ans. Grâce à EIP-1559 et à un temps de bloc stable après PoS (The Merge), 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 comparable à l’expérience de paiement par carte de crédit. Cependant, il est utile d’améliorer encore l’expérience utilisateur, et certaines applications nécessitent même une latence de centaines de millisecondes ou moins. Cet article explorera quelques options pratiques pour Ethereum (pour améliorer les délais de confirmation des transactions).

Aperçu des idées et des technologies existantes

Finalité du Slot Unique

Actuellement, le consensus Gasper d'Ethereum utilise une architecture de slot unique et d'Epoch. Toutes les 12 secondes, un slot est attribué, et une partie des validateurs votent pour la tête de la chaîne. Dans les 32 slots (6,4 minutes), tous les validateurs ont une opportunité de voter une fois. Ces votes sont ensuite interprétés comme des messages dans un algorithme de consensus similaire au PBFT, et après deux Epochs (12,8 minutes), ils fournissent une garantie économique très forte appelée finalité.

Au cours des dernières années, nous avons été de plus en plus insatisfaits des méthodes actuelles. Les principales raisons en sont deux : premièrement, ces méthodes sont très complexes, avec de nombreuses erreurs d'interaction entre le mécanisme de vote de slot à slot et le mécanisme de finalité d'Epoch à Epoch ; deuxièmement, 12,8 minutes, c'est trop long, personne ne veut attendre aussi longtemps.

La finalité unique de la fente (Single Slot Finaty, SSF) remplace cette architecture par un mécanisme similaire au consensus Tendermint, où le bloc N est définitivement dé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 d'inactivité', ce qui permet à la chaîne de continuer à fonctionner et à se rétablir lorsque plus d'un tiers des validateurs sont hors ligne.

Le principal défi de la finalité unique est que cela signifie que chaque validateur Ethereum doit publier deux messages toutes les 12 secondes, ce qui représente une charge importante pour le réseau. Il existe quelques idées astucieuses 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 pas le fait que les utilisateurs doivent attendre de 5 à 20 secondes.

Confirmation anticipée de Rollup

Au cours des dernières années, Ethereum a suivi une feuille de route centrée sur rollups, concevant la couche de base d'Ethereum (L1) pour prendre en charge la disponibilité des données et d'autres fonctionnalités, puis rendant ces fonctionnalités disponibles pour les protocoles L2 (tels que rollups, validiums et plasmas), capable de fournir aux utilisateurs une sécurité équivalente à celle d'Ethereum à une plus grande échelle.

Cela a entraîné une séparation des points d'attention dans l'écosystème Ethereum: Ethereum L1 se concentre sur la résistance à la censure, la fiabilité, la stabilité, ainsi que sur la maintenance et l'amélioration d'une fonctionnalité centrale de couche de base, tandis que L2 se concentre sur une interaction plus directe avec les utilisateurs grâce à des cultures et des technologies différentes. Mais si l'on continue sur cette voie, un problème inévitable se pose: L2 souhaite offrir des confirmations plus rapides que 5 à 20 secondes pour les utilisateurs.

Jusqu'à présent, du moins en théorie, il incombe à L2 de créer son propre réseau de «tri décentralisé». Un petit groupe de validateurs peut signer un bloc toutes les quelques centaines de millisecondes et engager leurs actifs de mise dans ces blocs. Finalement, les en-têtes de ces blocs L2 seront publiés sur L1.

Cependant, les validateurs L2 peuvent "frauder" : ils peuvent d'abord signer le bloc B1, puis signer un bloc B2 en conflit et le soumettre off-chain avant B1. Mais s'ils le font, ils seront détectés et perdront leur mise. En réalité, nous avons déjà vu des cas concrets de versions centralisées, mais d'autre part, le rollup progresse lentement dans le développement de réseaux de tri décentralisés. On pourrait dire qu'il est injuste de demander à tous les L2 de faire un tri décentralisé : cela revient à demander au rollup de faire un travail presque identique à la création d'un tout nouveau L1. Par conséquent, Justin Drake promeut depuis longtemps une méthode permettant à tous les L2 (et L1) d'utiliser un mécanisme de pré-validation partagé à l'échelle d'Ethereum : la pré-validation de base.

Confirmation de base préalable

La méthode de préconfirmation basée suppose que les proposants d'Ethereum sont des participants extrêmement complexes liés à la MEV. Cette méthode basée sur la préconfirmation incite ces proposants complexes à accepter la responsabilité de fournir des services de préconfirmation pour exploiter cette complexité.

L'idée fondamentale de cette méthode est de créer un protocole standardisé, où les utilisateurs peuvent fournir des frais supplémentaires pour garantir que la transaction sera incluse dans le prochain bloc, avec une garantie immédiate, ainsi qu'une déclaration sur le résultat de l'exécution de cette transaction. Si le proposant viole toute promesse faite à n'importe quel utilisateur, il peut être pénalisé.

Comme indiqué, garantir les transactions L1 pré-confirmées. Si les rollups sont "basés sur", alors tous les blocs L2 sont des transactions L1, donc le même mécanisme peut être utilisé pour garantir toutes les L2.

Que voyons-nous réellement ?

Suppose that we implement finality in a single slot. We use a technology similar to Orbit to reduce the number of validators signing in each slot, but not too much so that we can also make progress in reducing the minimum stake of 32 ETH. The slot time may increase to 16 seconds, and then we use rollup pre-confirmation or basic pre-confirmation to provide faster confirmation for users. In the end, what do we get: an epoch-slot architecture.

Il y a une raison philosophique profonde pour laquelle l'architecture epoch-and-slot semble si difficile à éviter : il faut moins de temps pour parvenir à un consensus approximatif sur quelque chose que pour parvenir à un accord maximal sur une chose en particulier en termes d '« économie finale ».

Une raison simple est le nombre de nœuds. Bien que grâce à l'agrégation BLS super-optimisée et aux futurs ZK-STARKs, les anciens compromis linéaires de décentralisation/temps de finalité/coûts semblent maintenant modérés, les raisons suivantes ne doivent pas être négligées :

• "Approximate consensus" requires only a few nodes, while economic finality requires a majority of nodes.
• Une fois que le nombre de nœuds dépasse un certain seuil, vous devez passer plus de temps à collecter des signatures.

Dans Ethereum aujourd'hui, les 12 slots sont divisés en trois sous-slots : publication et distribution des blocs, preuve, agrégation des preuves. Si le nombre de validateurs diminue considérablement, nous pouvons passer à deux sous-slots et utiliser un intervalle de 8 secondes. Un autre facteur plus important est la « qualité » des nœuds. Si nous pouvons également compter sur un sous-ensemble de nœuds spécialisés pour parvenir à un consensus approximatif (et toujours utiliser l'ensemble complet de validateurs pour déterminer la finalité), nous pouvons le réduire à environ 2 secondes.

Par conséquent, à mon avis, l'architecture epoch-and-slot est clairement la bonne, mais ce n'est pas parce que toutes les architectures epoch-and-slot sont égales, il est précieux d'explorer plus pleinement l'espace de conception. La direction qui mérite une étude approfondie n'est pas une intégration étroite comme Gasper, mais une plus grande attention à la séparation des deux mécanismes.

Comment devrait L2 faire?

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

• Ils sont "basés" à la fois techniquement et spirituellement. Cela signifie qu'ils optimisent les caractéristiques techniques et les valeurs fondamentales d'Ethereum (décentralisation élevée, résistance à la censure, etc.). Dans sa forme la plus simple, vous pouvez considérer ces rollups comme des "shardings" de marque, mais ils peuvent également avoir des ambitions plus grandes et mener de nombreuses expériences sur la conception d'une nouvelle machine virtuelle et d'autres améliorations technologiques.
• Devenez un “serveur avec une infrastructure de blockchain” et exploitez-le pleinement. Si vous commencez par un serveur, puis ajoutez une preuve de validité STARK pour vous assurer que le serveur respecte les règles ; assurez-vous du droit des utilisateurs à sortir ou à forcer les transactions ; liberté de sélection collective, soit par une sortie à grande échelle coordonnée, soit par un changement de vote des ordonnateurs, alors vous avez déjà obtenu la plupart des avantages de la mise en chaîne, tout en conservant la plupart de l'efficacité du serveur.
• Méthode de compromis : Une chaîne rapide avec cent nœuds, Ethereum offre une interopérabilité et une sécurité supplémentaires. C'est la feuille de route réelle de nombreux projets L2 actuellement.

Pour certaines applications (telles que ENS, le stockage de clés, certains protocoles de paiement), un temps de bloc de 12 secondes est suffisant. Pour les applications qui ne conviennent pas, la seule solution est l'architecture epoch-and-slot. Dans les trois cas, « epoch » est le SSF d'Ethereum, mais le slot est différent dans les trois cas susmentionnés :

• Une architecture epoch-and-slot native d'Ethereum
• Pré-confirmation du serveur
• Confirmation préalable du comité

Une question clé est de savoir à quel point nous pouvons être performants dans la première catégorie ? En particulier, si elle devient très performante, alors la signification de la troisième catégorie sera réduite. Étant donné que tous les schémas « basés » ne s'appliquent pas aux données L2 hors chaîne, telles que les plasmas et les validiums, la deuxième catégorie existera pour toujours. Si une architecture d'epoch-and-slot native d'Ethereum peut réduire le temps de slot à 1 seconde, l'espace de la troisième catégorie deviendra beaucoup plus petit.

Aujourd'hui, nous sommes encore loin des réponses finales à ces questions. Une question clé est de savoir à quel point les proposants de blocs deviendront complexes, ce qui reste un domaine avec une grande incertitude. Des conceptions telles que Orbit SSF sont très novatrices, il est donc encore intéressant d'explorer pleinement les espaces de conception tels que l'utilisation d'Orbit SSF dans l'époque d'epoch-and-slot, par exemple. Plus nous avons d'options, mieux nous pouvons servir les utilisateurs de L1 et L2, et simplifier le travail des développeurs de L2.