- Rubrique
2k Popularité
4k Popularité
32k Popularité
29k Popularité
496 Popularité
111k Popularité
26k Popularité
26k Popularité
7k Popularité
14k Popularité
- Épingler
2k Popularité
4k Popularité
32k Popularité
29k Popularité
496 Popularité
111k Popularité
26k Popularité
26k Popularité
7k Popularité
14k Popularité
Ethereum Le plan de The Surge : surmonter les trois défis de l'évolutivité pour améliorer les performances de L2 à 100 000 TPS
L'avenir possible d'Ethereum : The Surge
La feuille de route d'Ethereum comprenait à l'origine deux stratégies d'extension : le sharding et les protocoles Layer 2. Ces deux voies ont finalement fusionné pour former une feuille de route centrée sur le Rollup, qui reste la stratégie d'extension actuelle d'Ethereum.
La feuille de route centrée sur le 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 prend en charge 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) est destinée à protéger les contrats et les droits de propriété, tandis que les entrepreneurs (L2) construisent sur cette base, stimulant le développement.
Cette année, la feuille de route centrée sur les Rollups a fait d'importants progrès : avec le lancement des blobs EIP-4844, la bande passante des données d'Ethereum L1 a considérablement augmenté, et plusieurs Rollups de la machine virtuelle Ethereum ont atteint la première phase. Chaque L2 existe en tant que "fragment" avec ses propres règles et logiques, et la diversité et la pluralité des méthodes de mise en œuvre des fragments sont désormais une réalité. Mais ce chemin fait également face à certains défis uniques. Notre tâche actuelle est de finaliser la feuille de route centrée sur les Rollups, de résoudre ces problèmes, tout en maintenant la robustesse et la décentralisation d'Ethereum L1.
The Surge : objectifs clés
L'avenir d'Ethereum pourra atteindre plus de 100 000 TPS grâce à L2;
Maintenir la décentralisation et la robustesse de L1;
Au moins certains L2 héritent complètement des propriétés fondamentales d'Ethereum, (, de la confiance, de l'ouverture et de la résistance à la censure, );
Ethereum devrait se sentir comme un écosystème unifié, et non comme 34 blockchains différentes.
Contenu de ce chapitre
Paradoxe de la triangle de l'évolutivité
Le paradoxe des triangles de la scalabilité soutient qu'il existe une contradiction entre les trois caractéristiques de la blockchain : la décentralisation (, le faible coût des nœuds opérationnels ), la scalabilité (, qui traite un grand nombre de transactions ), et la sécurité (, où un attaquant doit compromettre une grande partie des nœuds du réseau pour faire échouer une seule transaction ).
Il est important de noter que le paradoxe du triangle n'est pas un théorème, et les articles présentant le paradoxe du triangle ne sont pas accompagnés de preuves mathématiques. Il présente un argument mathématique heuristique : si un nœud amical et décentralisé 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 qu'un petit nombre de nœuds pour passer 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 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 prétendent avoir résolu le trilemme sans changer fondamentalement l'architecture, généralement en optimisant les nœuds à l'aide de techniques d'ingénierie logicielle. Cela est toujours trompeur, car faire fonctionner des nœuds sur ces chaînes est beaucoup plus difficile que de faire fonctionner des nœuds sur Ethereum.
Cependant, la combinaison de l'échantillonnage de la disponibilité des données et des SNARKs résout effectivement le paradoxe triangulaire : 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 sont correctement exécutées, en téléchargeant seulement une petite quantité de données et en effectuant très peu de calculs. Les SNARKs sont sans confiance. L'échantillonnage de la disponibilité des données présente 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 un bloc malveillant à être accepté par le réseau.
Une autre méthode pour résoudre le trilemme est l'architecture Plasma, qui utilise une technologie astucieuse pour transférer la responsabilité de la disponibilité des données de surveillance aux utilisateurs de manière incitative et compatible. Entre 2017 et 2019, lorsque nous n'avions que la preuve de fraude comme moyen d'étendre notre capacité de calcul, Plasma était très limité en termes d'exécution sécurisée, mais avec la popularité des SNARKs, l'architecture Plasma est devenue plus viable pour un éventail d'applications plus large qu'auparavant.
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
Quel problème résolvons-nous ?
Le 13 mars 2024, lorsque la mise à niveau Dencun sera en ligne, la blockchain Ethereum aura 3 blobs d'environ 125 kB par slot toutes les 12 secondes, ou une bande passante de données disponible d'environ 375 kB par slot. Si les données de transaction sont publiées directement sur la chaîne, un transfert ERC20 est d'environ 180 octets, donc le TPS maximum des Rollups sur Ethereum est : 375000 / 12 / 180 = 173,6 TPS.
Si nous ajoutons la valeur maximale théorique de calldata d'Ethereum ( : 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 majeure de l'Ethereum L1, mais ce n'est pas suffisant. Nous voulons plus d'évolutivité. Notre objectif à moyen terme est de 16 Mo par slot, ce qui, combiné avec des améliorations de compression des données Rollup, permettra d'atteindre ~58000 TPS.
Qu'est-ce que c'est ? Comment ça fonctionne ?
PeerDAS est une implémentation relativement simple de l'"échantillonnage 1D". Dans Ethereum, chaque blob est un polynôme de degré 4096 sur un champ premier de 253 bits. Nous diffusons les parts du polynôme, où chaque part contient 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 4096 de ( selon les paramètres proposés actuellement : n'importe quel 64 parmi 128 échantillons possibles de ) peut restaurer le blob.
Le fonctionnement de PeerDAS consiste à faire écouter chaque client 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 ( qui écoutera les différents sous-réseaux ) pour demander le blob dont il a besoin sur d'autres sous-réseaux. Une version plus conservatrice, SubnetDAS, n'utilise que le mécanisme des sous-réseaux, sans requêtes supplémentaires au niveau des pairs. La proposition actuelle est de faire utiliser SubnetDAS aux nœuds participant à la preuve d'enjeu, tandis que les autres nœuds (, c'est-à-dire les clients ), utilisent PeerDAS.
En théorie, nous pouvons étendre une "échantillonnage 1D" à une taille assez grande : si nous augmentons le nombre maximal de blobs à 256( avec un objectif de 128), alors nous pouvons atteindre un objectif de 16 Mo, et dans l'échantillonnage de disponibilité des données, chaque nœud a 16 échantillons * 128 blobs * 512 octets par blob et par échantillon = 1 Mo de bande passante de données par slot. C'est juste à la limite de notre 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 rendra le coût de reconstruction plus élevé.
Ainsi, nous voulons finalement aller plus loin en effectuant un échantillonnage 2D, une méthode qui non seulement effectue un échantillonnage aléatoire à l'intérieur des blobs, mais aussi entre les blobs. En utilisant les propriétés linéaires de l'engagement 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 souhaitons aller plus loin et effectuer un échantillonnage 2D, qui se fait non seulement à l'intérieur des 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, rendant ainsi cette solution fondamentalement amicale pour la construction de blocs distribués. Les nœuds qui construisent réellement les blocs n'ont besoin que d'un engagement KZG 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 fondamentalement amical pour la construction de blocs distribués.
Que faut-il encore faire ? Quels compromis y a-t-il ?
La prochaine étape est de finaliser la mise en œuvre et le lancement de PeerDAS. Ensuite, 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. En même temps, nous espérons qu'il y aura plus 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.
À des étapes futures encore plus lointaines, nous devrons faire plus de travail pour déterminer la version idéale du 2D DAS et prouver ses propriétés de sécurité. Nous espérons également pouvoir finalement passer de KZG à une alternative quantiquement sécurisée et sans configuration de confiance. Pour l'instant, nous ne savons pas quelles solutions candidates sont amicales pour la construction de blocs distribués. Même en utilisant la coûteuse technologie "brute force", c'est-à-dire en utilisant STARK récursif 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 que techniquement, la taille d'un STARK soit O(log(n) * log(log(n)) valeur de hachage ( utilisant STIR), en réalité, un STARK est presque aussi grand que l'ensemble du blob.
Je pense que le chemin réaliste à long terme est :
Veuillez noter que même si nous choisissons 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 volumineux, et les clients souhaiteront avoir un moyen efficace de vérifier leur validité. Par conséquent, nous devrons utiliser au niveau L1 des technologies similaires à celles des Rollup( telles que ZK-EVM et DAS).
Comment interagir avec d'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 amical pour la reconstruction distribuée, cela nécessite en pratique une combinaison avec la proposition de liste d'inclusion de paquets et les mécanismes de choix de forks qui l'entourent.
Compression des données
Quel problème essayons-nous de résoudre ?
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 Layer. Chaque slot de 16 Mo, nous obtenons :
16000000 / 12 / 180 = 7407 TPS
Que se passerait-il si nous pouvions non seulement résoudre le problème des numérateurs, mais aussi celui des dénominateurs, permettant à chaque transaction dans un Rollup de prendre moins de bytes sur la chaîne?
Qu'est-ce que c'est, comment ça fonctionne ?
À 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 il y a. De plus, nous avons utilisé 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, cette signature pouvant 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 après agrégation, l'utilisation de la signature BLS n'est donc pas envisagée. Cependant, dans un environnement L2 où les données sont rares, l'utilisation de la signature BLS a du sens. La fonctionnalité d'agrégation de l'ERC-4337 fournit un moyen de réaliser cela.
Utiliser po