L'avenir possible d'Ethereum : The Surge

La feuille de route d'Ethereum avait initialement deux stratégies d'extension : le sharding et les protocoles Layer 2. Au fur et à mesure que la recherche avançait, ces deux voies se sont fusionnées pour former une feuille de route centrée sur les Rollups, qui demeure la stratégie d'extension actuelle d'Ethereum.

La feuille de route centrée sur Rollup propose une division simple des tâches : Ethereum L1 se concentre sur le fait d'être une couche de base puissante et décentralisée, tandis que L2 assume la tâche d'aider l'écosystème à s'étendre. Ce modèle est courant dans la société : l'existence du système judiciaire (L1) n'est pas pour poursuivre l'efficacité, mais pour protéger les contrats et la propriété, tandis que les entrepreneurs (L2) construisent sur cette base solide, propulsant le développement humain.

Cette année, la feuille de route centrée sur Rollup a réalisé des progrès importants : le lancement des blobs EIP-4844 a considérablement augmenté la bande passante des données de l'Ethereum L1, et plusieurs EVM Rollup ont atteint la première phase. Chaque L2 existe comme un "fragment" avec ses propres règles et logiques, et la diversité des implémentations de fragments est désormais une réalité. Mais ce chemin fait également face à des défis uniques. Notre tâche actuelle est de finaliser la feuille de route centrée sur Rollup, de résoudre ces problèmes tout en préservant la robustesse et la décentralisation propres à Ethereum L1.

The Surge: Objectifs clés

1. L'avenir d'Ethereum pourrait atteindre plus de 100 000 TPS grâce à L2;
2. Maintenir la décentralisation et la robustesse de L1;
3. Au moins certains L2 héritent complètement des propriétés fondamentales d'Ethereum ( de la confiance, de l'ouverture, de la résistance à la censure );
4. Ethereum devrait se sentir comme un écosystème unifié, et non comme 34 blockchains différentes.

Paradoxe du triangle de la scalabilité

Le paradoxe de la trinité de la scalabilité postule qu'il existe une contradiction entre les trois caractéristiques de la décentralisation, de la scalabilité et de la sécurité dans la blockchain. Ce n'est pas un théorème, mais un point de vue heuristique. Au fil des ans, certaines chaînes de haute performance ont prétendu résoudre le paradoxe trinaire, mais cela est souvent trompeur.

Cependant, la combinaison d'échantillonnage de la disponibilité des données et des SNARKs résout effectivement le paradoxe du triangle : elle permet aux clients 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 en ne téléchargeant qu'une petite quantité de données et en exécutant très peu de calculs.

Une autre méthode pour résoudre le trilemme est l'architecture Plasma, qui transfère la responsabilité de la disponibilité des données à l'utilisateur de manière incitative. Avec la popularité des SNARKs, l'architecture Plasma devient de plus en plus viable pour des cas d'utilisation plus larges.

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

Quels problèmes résolvons-nous ?

Après la mise à jour Dencun le 13 mars 2024, Ethereum disposera de 3 blobs d'environ 125 kB par slot toutes les 12 secondes, soit une bande passante de données d'environ 375 kB par slot. Supposons que les données de transaction soient publiées directement sur la chaîne, un transfert ERC20 fait environ 180 octets, donc le TPS maximum pour les Rollups sur Ethereum est de 173,6 TPS.

Avec le calldata d'Ethereum, cela devient 607 TPS. En utilisant PeerDAS, le nombre de blobs pourrait augmenter à 8-16, ce qui fournirait 463-926 TPS pour le calldata.

C'est une amélioration majeure pour Ethereum L1, mais ce n'est pas suffisant. Notre objectif à moyen terme est de 16 Mo par slot, ce qui, combiné aux améliorations de la compression des données Rollup, entraînera ~58000 TPS.

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

PeerDAS est une implémentation relativement simple de "1D sampling". Dans Ethereum, chaque blob est un polynôme de degré 4096 dans un champ premier de 253 bits. Nous diffusons les parts du polynôme, chaque part 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 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 aux pairs dans le réseau p2p mondial les blobs nécessaires sur d'autres sous-réseaux. Une version plus conservatrice, SubnetDAS, n'utilise que le mécanisme de sous-réseau, sans interroger la couche de pair supplémentaire. La proposition actuelle est de faire en sorte que les nœuds participant à la preuve de participation utilisent SubnetDAS, tandis que les autres nœuds utilisent PeerDAS.

En théorie, nous pouvons étendre l'échelle du "1D sampling" assez largement : si nous augmentons le nombre maximal de blobs à 256, nous pouvons atteindre l'objectif de 16 Mo, tandis que chaque nœud dans l'échantillonnage de disponibilité des données n'a besoin que d'1 Mo de bande passante par slot. Cela est juste à peine dans notre marge de tolérance : c'est faisable, mais cela signifie que les clients à bande passante limitée ne peuvent pas échantillonner. Nous pouvons optimiser en réduisant le nombre de blobs et en augmentant la taille des blobs, mais cela rendra les coûts de reconstruction plus élevés.

Ainsi, nous souhaitons finalement aller plus loin en effectuant un échantillonnage 2D, qui ne se fait pas seulement à l'intérieur des blobs, mais aussi entre les blobs. En utilisant la propriété linéaire des engagements KZG, nous étendons un ensemble de blobs dans un bloc avec un nouvel ensemble de blobs virtuels, ces blobs virtuels codent de manière redondante la même information.

Il est crucial de noter que l'expansion des engagements de calcul ne nécessite pas de blob, donc cette approche est fondamentalement amicale pour la construction de blocs distribués. Les nœuds qui construisent effectivement des blocs n'ont besoin que de la promesse KZG du blob, et ils peuvent s'appuyer sur l'échantillonnage de la disponibilité des données (DAS) pour vérifier la disponibilité des blocs de données. L'échantillonnage de la disponibilité des données unidimensionnel (1D DAS) est également fondamentalement amical pour la construction de blocs distribués.

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

Ensuite, il s'agit de finaliser la mise en œuvre et le lancement de PeerDAS. Par la suite, le nombre de blobs sur PeerDAS sera progressivement augmenté, tout en surveillant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité, ce qui est un processus progressif. En même temps, nous espérons voir davantage de travaux académiques pour réglementer PeerDAS et d'autres versions de DAS ainsi que leurs interactions avec des questions de sécurité telles que les règles de sélection de forks.

À un stade futur plus éloigné, nous devrons faire davantage de travaux pour déterminer la version idéale du DAS 2D et prouver ses attributs de sécurité. Nous espérons également pouvoir finalement passer d'un KZG à une alternative sécurisée quantiquement et sans configuration de confiance. Pour l'instant, nous ne savons pas clairement quelles sont les solutions candidates amicales pour la construction de blocs distribués.

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

1. Mettre en œuvre un DAS 2D idéal;
2. Maintenir l'utilisation de 1D DAS, sacrifiant l'efficacité de la bande passante d'échantillonnage, afin d'accepter une limite de données plus basse 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 décidons d'étendre l'exécution directement au niveau L1, cette option existe. En effet, si le niveau L1 doit traiter un grand nombre de TPS, les blocs L1 deviendront très grands, et les clients souhaiteront avoir une méthode efficace pour vérifier leur validité. Par conséquent, nous devrons utiliser au niveau L1 les mêmes technologies que Rollup(, telles que 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 sera réduite, ou du moins retardée, et 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 favorable à la reconstruction distribuée, cela nécessite en pratique d'être combiné avec la proposition de liste d'inclusion de paquets et les mécanismes de choix de fork qui l'entourent.

Compression de données

Quels problèmes résolvons-nous ?

Chaque transaction dans un Rollup occupe une grande quantité d'espace de données on-chain : 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 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 à chaque transaction dans un Rollup d'occuper moins de bytes sur la chaîne ?

Qu'est-ce que c'est, comment ça fonctionne ?

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

Agrégation de signatures : nous avons changé de signatures ECDSA à des signatures BLS. La caractéristique des signatures 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, en raison du coût de calcul élevé de la vérification, même avec l'agrégation, l'utilisation de signatures BLS n'est pas envisagée. Mais dans un environnement L2 où les données sont rares, l'utilisation de signatures BLS a un sens. La caractéristique d'agrégation d'ERC-4337 offre une voie pour réaliser cette fonctionnalité.

Remplacer l'adresse par des pointeurs : si une adresse a été utilisée auparavant, nous pouvons remplacer l'adresse de 20 octets par un pointeur de 4 octets pointant vers un emplacement dans l'historique.

Sérialisation personnalisée des valeurs de transaction : la plupart des valeurs de transaction ont peu de chiffres, par exemple, 0,25 Éther est représenté par 250 000 000 000 000 000 wei. Les frais de base maximum et les frais prioritaires sont similaires. Par conséquent, nous pouvons utiliser un format décimal flottant personnalisé pour représenter la plupart des valeurs monétaires.

Que faut-il encore faire, quels sont les compromis?

La prochaine étape consiste principalement à mettre en œuvre le plan ci-dessus. Les principaux compromis incluent :

1. Passer à la signature BLS nécessite un effort considérable et réduira la compatibilité avec les puces matérielles de confiance qui peuvent renforcer la sécurité. Il est possible d'utiliser un encapsulage ZK-SNARK d'autres schémas de signature comme alternative.

2. Compression dynamique ( Par exemple, remplacer les adresses ) par des pointeurs rendra le code client plus complexe.

3. Publier les différences d'état sur la chaîne plutôt que dans les transactions réduira l'auditabilité et rendra de nombreux logiciels (, comme les explorateurs de blocs ), inopérants.

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

L'adoption de l'ERC-4337 et l'intégration de certaines de ses fonctionnalités dans l'EVM de L2 peuvent considérablement accélérer le déploiement de la technologie d'agrégation. Placer certaines parties de l'ERC-4337 sur L1 peut accélérer son déploiement sur L2.

Plasma généralisé

Quels problèmes résolvons-nous ?

Même avec un blob de 16 Mo et une compression des données, 58 000 TPS ne suffisent peut-être pas à répondre entièrement aux besoins des paiements des consommateurs, des réseaux sociaux décentralisés ou d'autres domaines à forte bande passante, surtout lorsque nous commençons à prendre en compte les facteurs de confidentialité, ce qui pourrait réduire la scalabilité de 3 à 8 fois. Pour les scénarios d'application à fort volume de transactions et à faible valeur, actuellement