- Rubrique
77k Popularité
33k Popularité
10k Popularité
4k Popularité
4k Popularité
29k Popularité
16k Popularité
22k Popularité
13k Popularité
3k Popularité
- Épingler
77k Popularité
33k Popularité
10k Popularité
4k Popularité
4k Popularité
29k Popularité
16k Popularité
22k Popularité
13k Popularité
3k Popularité
Ethereum : Analyse approfondie de la feuille de route The Surge pour l'extension
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 approches ont finalement été fusionnées pour former une feuille de route centrée sur les Rollups, qui reste la stratégie d'extension actuelle d'Ethereum.
La feuille de route centrée sur Rollup propose une division simple du travail : 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) est destinée à protéger les contrats et la propriété, tandis que les entrepreneurs (L2) construisent sur cette base et propulsent le développement humain.
Cette année, la feuille de route centrée sur le Rollup a fait des progrès importants : avec le lancement des blobs EIP-4844, la bande passante des données de l'Ethereum L1 a considérablement augmenté, plusieurs Rollup de la machine virtuelle Ethereum (EVM) sont entrés dans la première phase. Chaque L2 existe en tant que "fragment" avec ses propres règles et logiques internes. 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 à des défis uniques. Ainsi, notre tâche actuelle est de finaliser la feuille de route centrée sur le Rollup et de résoudre ces problèmes, tout en maintenant la robustesse et la décentralisation propres à l'Ethereum L1.
The Surge: Objectif clé
L'avenir d'Ethereum via L2 peut atteindre plus de 100 000 TPS.
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 confiance, ouvertes, résistantes à 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 la scalabilité
Le paradoxe de la triangle de la scalabilité stipule qu'il existe une contradiction entre trois caractéristiques de la blockchain : la décentralisation, le coût faible des nœuds opérationnels (, la scalabilité, le grand nombre de transactions pouvant être traitées ), et la sécurité, où un attaquant doit compromettre une grande partie des nœuds du réseau pour faire échouer une transaction (.
![Vitalik nouveau document : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
Il est important de noter que le paradoxe triangulaire n'est pas un théorème et n'a pas de preuve mathématique. Il présente un argument mathématique heuristique : si un nœud amical décentralisé peut valider 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 qu'à compromettre 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. Le but de cet article n'est pas de prouver qu'il est impossible de briser le paradoxe triangulaire ; au contraire, il vise à montrer que briser le paradoxe ternaire est difficile, nécessitant dans une certaine mesure de sortir du cadre de pensée implicite dans cet argument.
Depuis des années, certaines chaînes haute performance prétendent résoudre le trilemme de la blockchain sans changer fondamentalement leur architecture, souvent 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 de faire fonctionner des nœuds sur Ethereum. Cet article explorera pourquoi c'est le cas et pourquoi l'ingénierie logicielle des clients L1 à elle seule ne peut pas étendre Ethereum.
Cependant, la combinaison d'échantillonnage de disponibilité des données et de SNARKs résout effectivement le paradoxe du triangle : elle permet aux clients de vérifier qu'une certaine quantité de données est disponible 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 disponibilité des données présente un modèle de confiance subtil de type few-of-N, mais il conserve les caractéristiques fondamentales des chaînes non extensibles, à savoir qu'une attaque à 51 % ne peut pas forcer des blocs défectueux à être acceptés 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 pour étendre la capacité de calcul, Plasma était très limité en termes d'exécution sécurisée. Cependant, avec la popularité des SNARKs) et des preuves non interactives succinctes de connaissance nulle(, l'architecture Plasma est devenue beaucoup plus viable pour un éventail d'utilisations plus large que jamais.
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
) Quels problèmes essayons-nous de résoudre ?
Le 13 mars 2024, lorsque la mise à niveau Dencun sera en ligne, la blockchain Ethereum aura 3 blobs d'environ 125 kB par slot de 12 secondes, soit une bande passante de données d'environ 375 kB par slot. Si les données de transaction sont publiées directement sur la chaîne, alors un transfert ERC20 fait environ 180 octets, donc le TPS maximal pour Rollup 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 de scalabilité. Notre objectif à moyen terme est de 16 Mo par slot, ce qui, combiné avec des améliorations de compression des données Rollup, pourrait permettre d'atteindre ~58000 TPS.
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
) 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, où chaque part contient 16 évaluations sur 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 évaluations, n'importe quel 4096 ) peut être récupéré selon les paramètres proposés actuellement : n'importe quel 64 parmi 128 échantillons possibles ### peut récupérer 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 n'importe quel blob et demande aux pairs dans le réseau p2p mondial ( qui écoutera les différents sous-réseaux ) pour récupérer les blobs nécessaires d'autres sous-réseaux. Une version plus conservatrice, SubnetDAS, utilise uniquement le mécanisme de sous-réseau, sans requêtes supplémentaires au niveau des pairs. 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 (, c'est-à-dire les clients ), utilisent PeerDAS.
Théoriquement, nous pouvons étendre l'échelle d'un "1D sampling" assez largement : si nous augmentons le nombre maximal de blobs à 256( avec un objectif de 128), nous pouvons atteindre l'objectif de 16 Mo, tandis que dans l'échantillonnage de la 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. Cela est juste à la limite de notre tolérance : c'est faisable, mais cela signifie que les clients avec une 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 aller plus loin en effectuant un échantillonnage 2D (2D sampling). Cette méthode ne se limite pas à un échantillonnage aléatoire à l'intérieur des blobs, mais effectue également un échantillonnage aléatoire entre les blobs. En utilisant les propriétés linéaires des engagements KZG, nous élargissons un ensemble de blobs dans un bloc à l'aide d'un ensemble de nouveaux blobs virtuels, ces blobs virtuels codant de manière redondante les mêmes informations.
Ainsi, finalement, nous souhaitons aller plus loin en effectuant un échantillonnage 2D, qui non seulement se fait à l'intérieur des blobs, mais aussi entre les blobs. L'attribut linéaire des engagements KZG est utilisé pour étendre un ensemble de blobs dans un bloc, qui contient une nouvelle liste de blobs virtuels codés en redondance pour les mêmes informations.
Il est crucial de noter que l'extension de l'engagement 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 réellement les blocs n'ont besoin que de l'engagement KZG du blob, et ils peuvent s'appuyer 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 favorable à la construction de blocs distribués.
( Que faut-il encore faire ? Quelles sont les compromis ?
La prochaine étape est la mise en œuvre et le lancement de PeerDAS. Ensuite, nous augmenterons constamment le nombre de blobs sur PeerDAS, tout en surveillant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité, cela est un processus progressif. Parallèlement, nous espérons avoir davantage de travaux académiques pour normaliser PeerDAS et d'autres versions de DAS ainsi que leurs interactions avec des questions telles que la sécurité des règles de choix de fork.
À un stade plus éloigné dans le futur, nous devons faire davantage de travail pour déterminer la version idéale du DAS 2D et prouver ses attributs de sécurité. Nous espérons également pouvoir finalement passer du KZG à une alternative qui soit sécurisée contre les quantiques et sans configuration de confiance. Actuellement, nous ne savons pas encore quelles solutions candidates sont favorables à la construction de blocs distribués. Même en utilisant la coûteuse technologie de "force brute", même en utilisant des STARK récursifs pour générer des preuves de validité pour reconstruire les lignes et les colonnes, cela ne suffit pas à répondre à la demande, car bien que techniquement, la taille d'un STARK soit O)log(n) * log(log)n###( hash ( utilisant STIR), en réalité, le 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 décidons d'étendre l'exécution directement au niveau L1, cette option existe. Cela est dû au fait que 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 des technologies similaires à celles de 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 amical envers la reconstruction distribuée, cela nécessite en pratique d'être associé à la proposition de liste d'inclusion de paquets et aux mécanismes de choix de forks qui l'entourent.
Compression des 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 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 des numérateurs, mais aussi ceux des dénominateurs, permettant ainsi à chaque transaction dans un Rollup d'occuper 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 sommes passés 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 est élevé, donc l'utilisation de signatures BLS n'est pas envisagée.