L'avenir possible d'Ethereum : The Surge

The Surge : Objectifs clés

1. L'avenir d'Ethereum via L2 peut atteindre plus de 100 000 TPS ;

2. Maintenir la décentralisation et la robustesse de L1 ;

3. Au moins certains L2 ont complètement hérité des propriétés fondamentales d'Ethereum (sans confiance, ouvert, résistant à la censure) ;

4. Ethereum devrait se sentir comme un écosystème unifié, et non comme 34 blockchains différentes.

Contenu de ce chapitre

1. Paradoxe du triangle de la scalabilité
2. Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
3. Compression des données
4. Plasma généralisé
5. Système de preuve L2 mature
6. Améliorations de l'interopérabilité entre L2
7. Étendre l'exécution sur L1

Paradoxe de la triangle de la scalabilité

Le paradoxe de la triangle de la scalabilité est une idée proposée en 2017, qui soutient qu'il existe des contradictions entre trois caractéristiques de la blockchain : la décentralisation (plus précisément : le faible coût de fonctionnement des nœuds), la scalabilité (un grand nombre de transactions traitées) et la sécurité (les attaquants doivent compromettre une grande partie des nœuds du réseau pour faire échouer une transaction unique).

Il convient de noter que le paradoxe du triangle n'est pas un théorème, et les publications présentant le paradoxe du triangle ne sont pas accompagnées de preuves mathématiques. Il fournit en effet un argument mathématique heuristique : si un nœud amical décentralisé (comme un ordinateur portable grand public) peut vérifier N transactions par seconde, et que vous avez une chaîne capable de traiter k*N transactions par seconde, alors (i) chaque transaction ne peut être vue que par 1/k nœuds, ce qui signifie qu'un attaquant n'a besoin de compromettre que quelques nœuds pour réussir une transaction malveillante, ou (ii) vos nœuds deviendront puissants, tandis que votre chaîne ne sera pas décentralisée. L'objectif de cet article n'est pas de prouver qu'il est impossible de briser le paradoxe du triangle ; au contraire, il vise à montrer que briser le paradoxe ternaire est difficile et qu'il nécessite, dans une certaine mesure, de sortir du cadre de pensée implicite de cet argument.

Depuis des années, certaines chaînes à haute performance affirment qu'elles ont résolu le trilemme de la blockchain sans changer fondamentalement l'architecture, généralement en utilisant des techniques d'ingénierie logicielle pour optimiser les nœuds. Cela est toujours trompeur, car faire fonctionner des nœuds sur ces chaînes est beaucoup plus difficile que sur Ethereum. Cet article explorera pourquoi c'est le cas et pourquoi l'ingénierie logicielle des clients L1 à elle seule ne peut pas faire évoluer Ethereum.

Cependant, la combinaison de l'échantillonnage de la disponibilité des données et des SNARKs résout effectivement le paradoxe triangulaire : elle permet au client de vérifier qu'un certain nombre de données sont disponibles et qu'un certain nombre d'étapes de calcul ont été correctement exécutées, tout cela en téléchargeant uniquement une petite quantité de données et en effectuant un très faible nombre de calculs. Les SNARKs sont sans confiance. L'échantillonnage de la disponibilité des données a un modèle de confiance subtil few-of-N, mais il conserve les caractéristiques fondamentales des chaînes non extensibles, à savoir qu'une attaque à 51 % ne peut pas forcer les blocs malveillants à être acceptés par le réseau.

Une autre méthode pour résoudre le trilemme est l'architecture Plasma, qui utilise des techniques astucieuses pour transférer la responsabilité de la disponibilité des données surveillées aux utilisateurs de manière incitative. Déjà entre 2017 et 2019, lorsque nous n’avions que la preuve de fraude comme moyen d'étendre la capacité de calcul, Plasma était très limité en matière d'exécution sécurisée, mais avec la popularisation des SNARKs (preuves succinctes non interactives à connaissance nulle), l'architecture Plasma est devenue plus viable pour un éventail d'applications plus large que jamais.

Progrès supplémentaires sur l'échantillonnage de la disponibilité des données

Quels problèmes sommes-nous en train de résoudre ?

Le 13 mars 2024, lors de la mise à niveau de Dencun, chaque slot de 12 secondes contiendra 3 blobs d'environ 125 kB, ou une bande passante de données d'environ 375 kB par slot. En supposant que les données transactionnelles sont publiées directement sur la chaîne, un transfert ERC20 fait environ 180 octets, donc le TPS maximum sur Rollup est : 375000 / 12 / 180 = 173,6 TPS.

Si nous ajoutons le calldata (valeur théorique maximale : 30 millions de Gas par slot / 16 gas par octet = 1 875 000 octets par slot), cela devient 607 TPS. Avec PeerDAS, le nombre de blobs pourrait augmenter à 8-16, ce qui fournirait 463-926 TPS pour le calldata.

C'est une amélioration significative pour L1, mais ce n'est pas suffisant. Nous voulons plus de scalabilité. Notre objectif à moyen terme est de 16 Mo par slot, ce qui, combiné aux améliorations de compression des données Rollup, permettra d'atteindre environ 58000 TPS.

Qu'est-ce que c'est ? Comment ça fonctionne ?

PeerDAS est une implémentation relativement simple de "1D sampling". Dans celle-ci, chaque blob est un polynôme de degré 4096 dans un corps premier de 253 bits. Nous diffusons les parts du polynôme, chacune contenant 16 valeurs d'évaluation sur 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 valeurs d'évaluation, n'importe quel ensemble de 4096 (selon les paramètres proposés actuellement : n'importe quel 64 parmi 128 échantillons possibles) peut restaurer le blob.

Le fonctionnement de PeerDAS consiste à faire en sorte que chaque client écoute un petit nombre de sous-réseaux, où le ième sous-réseau diffuse le ième échantillon de tout blob et demande les blobs nécessaires sur d'autres sous-réseaux en interrogeant les pairs dans le réseau p2p mondial (qui écouteront différents sous-réseaux). Une version plus conservatrice, SubnetDAS, utilise uniquement le mécanisme de sous-réseau, sans interroger la couche de pairs supplémentaire. La proposition actuelle est de permettre aux nœuds participant à la preuve de participation d'utiliser SubnetDAS, tandis que les autres nœuds (c'est-à-dire les clients) utilisent PeerDAS.

En théorie, nous pouvons étendre une "échantillonnage 1D" à une échelle assez grande : si nous augmentons le nombre maximal de blobs à 256 (l'objectif étant 128), alors nous pourrons atteindre l'objectif de 16 Mo, tandis que pour l'échantillonnage de la disponibilité des données, chaque nœud a 16 échantillons * 128 blobs * chaque blob ayant 512 octets par échantillon = 1 Mo de bande passante de données par slot. Cela se situe à peine dans notre plage de tolérance : c'est faisable, mais cela signifie que les clients à bande passante limitée ne peuvent pas échantillonner. Nous pouvons optimiser cela dans une certaine mesure en réduisant le nombre de blobs et en augmentant la taille des blobs, mais cela augmentera le coût de reconstruction.

Ainsi, nous voulons finalement aller plus loin et effectuer un échantillonnage 2D (2D sampling), une méthode qui effectue non seulement un échantillonnage aléatoire à l'intérieur des blobs, mais également entre les blobs. En utilisant les propriétés linéaires des engagements KZG, nous étendons un ensemble de blobs dans un bloc à l'aide d'un nouvel ensemble de blobs virtuels, ces blobs virtuels codant de manière redondante les mêmes informations.

Ainsi, finalement, nous voulons aller plus loin en effectuant un échantillonnage 2D, qui effectue un échantillonnage aléatoire non seulement dans les blobs mais également entre les blobs. Les propriétés linéaires des engagements KZG sont utilisées pour étendre un ensemble de blobs dans un bloc, qui contient une nouvelle liste de blobs virtuels codés de manière redondante pour les mêmes informations.

Il est crucial de noter que l'extension des engagements de calcul ne nécessite pas de blob, donc cette solution est fondamentalement favorable à la construction de blocs distribués. Les nœuds qui construisent effectivement les blocs n'ont besoin que d'un engagement KZG de blob, et ils peuvent compter sur l'échantillonnage de disponibilité des données (DAS) pour vérifier la disponibilité des blocs de données. L'échantillonnage de disponibilité des données unidimensionnel (1D DAS) est également intrinsèquement favorable à la construction de blocs distribués.

Que faut-il encore faire ? Quelles sont les compromis ?

Ensuite, il s'agit de finaliser l'implémentation et le lancement de PeerDAS. Par la suite, nous augmenterons progressivement le nombre de blobs sur PeerDAS, tout en surveillant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité, ce qui est un processus progressif. Parallèlement, nous espérons qu'il y aura davantage de travaux académiques pour normaliser PeerDAS et d'autres versions de DAS ainsi que leurs interactions avec des questions de sécurité telles que les règles de choix de fork.

À un stade plus éloigné dans le futur, nous devons faire plus de travail pour déterminer la version idéale du DAS 2D et prouver ses propriétés de sécurité. Nous espérons également pouvoir finalement passer d'un KZG à une alternative qui soit sécurisée contre les attaques quantiques et qui ne nécessite pas de configuration de confiance. Pour l'instant, nous ne savons pas encore quelles options sont amicales pour la construction de blocs distribués. Même en utilisant une technologie "brute force" coûteuse, c'est-à-dire en utilisant des STARKs récursifs pour générer des preuves de validité pour reconstruire les lignes et les colonnes, cela ne suffit pas à répondre aux besoins, car bien qu'en théorie, un STARK ait une taille de O(log(n) * log(log(n)) hash (en utilisant STIR), en réalité, le STARK est presque aussi grand que tout le blob.

Je pense que le chemin de réalité à long terme est :

1. Mettre en œuvre un DAS 2D idéal ;
2. Persister à utiliser 1D DAS, sacrifiant l'efficacité de la bande passante d'échantillonnage, acceptant une limite de données inférieure pour la simplicité et la robustesse.
3. Abandonner DA et accepter complètement Plasma comme notre principale architecture Layer2.

Veuillez noter que même si nous choisissons d'étendre l'exécution directement au niveau L1, cette option est également disponible. Cela est dû au fait que si le niveau L1 doit traiter un grand nombre de TPS, les blocs L1 deviendront très volumineux, et le client souhaitera avoir une méthode efficace pour vérifier leur exactitude. Par conséquent, nous devrons utiliser au niveau L1 la même technologie que celle utilisée dans les Rollups (comme ZK-EVM et DAS).

Comment interagir avec les autres parties de la feuille de route ?

Si la compression des données est réalisée, la demande pour le DAS 2D diminuera, ou du moins sera retardée. Si Plasma est largement utilisé, la demande diminuera encore davantage. Le DAS pose également des défis aux protocoles et mécanismes de construction de blocs distribués : bien que le DAS soit théoriquement amical pour la reconstruction distribuée, cela nécessite en pratique une combinaison avec la proposition de liste d'inclusion de paquets et le mécanisme de sélection de forks qui l'entoure.

Compression de données

Quel problème résolvons-nous ?

Chaque transaction dans un Rollup occupe beaucoup d'espace de données sur la chaîne : un transfert ERC20 nécessite environ 180 octets. Même avec un échantillonnage idéal de la disponibilité des données, cela limite l'évolutivité des protocoles de Layer. Chaque slot fait 16 Mo, nous obtenons :

16000000 / 12 / 180 = 7407 TPS

Que se passerait-il si nous pouvions non seulement résoudre les problèmes de numérateur, mais aussi ceux de dénominateur, permettant ainsi à chaque transaction dans un Rollup d'occuper moins de bytes sur la chaîne ?

Qu'est-ce que c'est et comment ça marche ?

À mon avis, la meilleure explication est cette image d'il y a deux ans :

Dans la compression des zéros, chaque longue séquence de zéros est remplacée par deux octets, indiquant combien de zéros sont présents. De plus, nous avons tiré parti des propriétés spécifiques des transactions :

Agrégation de signatures : nous passons de la signature ECDSA à la signature BLS. La caractéristique de la signature BLS est que plusieurs signatures peuvent être combinées en une seule signature, qui peut prouver la validité de toutes les signatures originales. Au niveau L1, même avec l'agrégation, le coût de calcul de la vérification reste élevé, donc l'utilisation de la signature BLS n'est pas envisagée. Mais dans un environnement comme L2, où les données sont rares, utiliser la signature BLS a du sens. La fonctionnalité d'agrégation d'ERC-4337 offre un moyen d'implémenter cette capacité.