La feuille de route d'Ethereum comprenait initialement deux stratégies d'extension : le sharding et les protocoles de couche 2. Avec l'approfondissement des recherches, ces deux voies se sont 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 les Rollups propose une division simple : 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 destinée à rechercher une super vitesse et efficacité, mais à protéger les contrats et la propriété, tandis que les entrepreneurs (L2) doivent construire sur cette couche de base solide pour faire progresser le développement humain.
Cette année, la feuille de route centrée sur Rollup a obtenu des résultats importants : avec le lancement des blobs EIP-4844, la bande passante des données d'Ethereum L1 a considérablement augmenté, plusieurs machines virtuelles Ethereum (EVM) Rollup ont atteint la première étape. Chaque L2 existe comme un "fragment" avec ses propres règles et logiques internes, et la diversité et la pluralité des méthodes de mise en œuvre des fragments sont désormais une réalité. Mais comme nous l'avons vu, suivre ce chemin présente également des défis uniques. Par conséquent, notre tâche actuelle est de finaliser la feuille de route centrée sur Rollup et de résoudre ces problèmes tout en maintenant la robustesse et la décentralisation propres à 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 ont complètement hérité des propriétés fondamentales d'Ethereum, ( la confiance, l'ouverture, 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 du triangle de la scalabilité
Avancées supplémentaires sur l'échantillonnage de la disponibilité des données
Compression des données
Plasma généralisé
Système de preuve L2 mature
Amélioration de l'interopérabilité entre les L2
Étendre l'exécution sur L1
Paradoxe de la triade de l'évolutivité
Le paradoxe de la triangle de la scalabilité est une idée proposée en 2017, qui soutient qu'il existe une contradiction 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é (, le nombre élevé de transactions traitées ) 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 à noter que le paradoxe du triangle n'est pas un théorème, et les posts présentant le paradoxe du triangle ne sont pas accompagnés de preuves mathématiques. Il fournit effectivement un argument mathématique heuristique : si un nœud amical et décentralisé ( par exemple, un ordinateur portable grand public ) 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'aurait qu'à compromettre un petit nombre de nœuds pour réussir à effectuer 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 que briser le paradoxe du triangle est impossible ; 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 dans cet argument.
Pendant des années, certaines chaînes à haute performance ont souvent affirmé qu'elles résolvaient le trilemme de manière fondamentale sans changer leur architecture, généralement en optimisant les nœuds grâce à des techniques d'ingénierie logicielle. Cela s'avère toujours trompeur, car faire fonctionner un nœud sur ces chaînes est beaucoup plus difficile que de faire fonctionner un nœud sur Ethereum. Cet article explorera pourquoi cela est le cas et pourquoi l'ingénierie logicielle du client 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 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 ne téléchargeant qu'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 a un modèle de confiance subtil few-of-N, mais il conserve les caractéristiques fondamentales des chaînes non extensibles, c'est-à-dire qu'une attaque à 51 % ne peut pas forcer les blocs défectueux à être acceptés par le réseau.
Une autre méthode pour résoudre le dilemme des trois difficultés 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 ne disposions que de 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 popularité des preuves succinctes non interactives à connaissance nulle SNARKs(, l'architecture Plasma est devenue plus viable pour un plus large éventail de scénarios d'utilisation que jamais.
![Vitalik nouvel article : futur possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
Progrès supplémentaire sur l'échantillonnage de la disponibilité des données
) Nous résolvons quel problème ?
Le 13 mars 2024, lors de la mise à niveau Dencun, la blockchain Ethereum aura 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. Si les données de transaction sont publiées directement sur la chaîne, un transfert ERC20 fait environ 180 octets, donc le maximum de TPS pour Rollup sur Ethereum est : 375000 / 12 / 180 = 173,6 TPS.
Si nous ajoutons la valeur maximale théorique du calldata d'Ethereum### : 30 millions de Gas par slot / 16 gas par octet = 1 875 000 octets par slot(, 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. 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 ~58000 TPS.
) Qu'est-ce que c'est ? Comment ça fonctionne ?
PeerDAS est une implémentation relativement simple du "1D sampling". Dans Ethereum, chaque blob est un polynôme de 4096 degrés dans un champ premier de 253 bits ###. Nous diffusons les parts du polynôme, chacune contenant 16 valeurs évaluées sur 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 valeurs évaluées, n'importe quel 4096 ( peuvent être récupérés selon les paramètres proposés : n'importe quel 64 parmi 128 échantillons possibles ) peut restaurer le blob.
Le fonctionnement de PeerDAS permet à chaque client d'écouter un petit nombre de sous-réseaux, où le i-ème sous-réseau diffuse le i-ème échantillon de tout blob, et en interrogeant les pairs dans le réseau p2p mondial concernant ( qui écoutera différents sous-réseaux ) pour demander les blobs nécessaires sur 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 d'enjeu utilisent SubnetDAS, tandis que les autres nœuds (, c'est-à-dire les clients ), utilisent PeerDAS.
Théoriquement, nous pouvons étendre l'échelle d'un "échantillonnage 1D" assez largement : si nous augmentons le nombre maximal de blobs à 256( avec un objectif de 128), nous pouvons atteindre un objectif de 16 Mo, et dans l'échantillonnage de la disponibilité des données, chaque nœud a 16 échantillons * 128 blobs * chaque blob chaque échantillon 512 octets = 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 à 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 les coûts de reconstruction.
Ainsi, nous voulons finalement aller plus loin et effectuer un échantillonnage 2D (2D sampling). Cette méthode 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 par un ensemble de nouveaux blobs virtuels, qui codent de manière redondante les mêmes informations.
Ainsi, finalement, nous voulons aller plus loin et effectuer un échantillonnage 2D, qui ne se limite pas à l'intérieur des blobs, mais effectue également un échantillonnage aléatoire entre les blobs. La propriété linéaire des engagements KZG est utilisée pour étendre un ensemble de blobs dans un bloc, qui contient une nouvelle liste de blobs virtuels codés de manière redondante contenant les mêmes informations.
Il est crucial de noter que l'extension 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 réellement les blocs n'ont besoin que de posséder l'engagement blob KZG, 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 amical pour la construction de blocs distribués.
( Que faut-il encore faire ? Quelles sont les compensations ?
La prochaine étape consiste à 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é, c'est un processus progressif. Dans le même temps, nous espérons qu'il y aura 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 fork.
À un stade futur plus éloigné, nous devons faire davantage 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 du KZG à une alternative qui soit sécurisée quantiquement et ne nécessite pas de paramétrage de confiance. Actuellement, nous ne savons pas encore quelles sont les solutions candidates favorables à la construction de blocs distribués. Même avec des techniques coûteuses de "force brute", c'est-à-dire 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() utilisant le hachage ( avec STIR(, en réalité, le STARK est presque de la même taille que l'ensemble du blob.
Je pense que le chemin réaliste à long terme est :
Mettre en œuvre un DAS 2D idéal;
Continuer à utiliser 1D DAS, sacrifiant l'efficacité de la bande passante d'échantillonnage, pour la simplicité et la robustesse, en acceptant une limite de données inférieure.
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 sur la couche L1, cette option existe également. Cela est dû au fait que si la couche 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 sur la couche L1 des technologies similaires à Rollup) 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 sera réduite, ou du moins 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.
![Nouvel article de Vitalik : L'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
Compression des données
) Quel problème résolvons-nous ?
Chaque transaction dans un Rollup occupe un espace de données en chaîne considérable : 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 molécules, mais aussi celui des dénominateurs, permettant à 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 tiré parti des propriétés spécifiques des transactions :
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Ethereum La Surge : De 100 000 TPS à la voie de l'expansion d'un écosystème unifié
Ethereum : The Surge
La feuille de route d'Ethereum comprenait initialement deux stratégies d'extension : le sharding et les protocoles de couche 2. Avec l'approfondissement des recherches, ces deux voies se sont 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 les Rollups propose une division simple : 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 destinée à rechercher une super vitesse et efficacité, mais à protéger les contrats et la propriété, tandis que les entrepreneurs (L2) doivent construire sur cette couche de base solide pour faire progresser le développement humain.
Cette année, la feuille de route centrée sur Rollup a obtenu des résultats importants : avec le lancement des blobs EIP-4844, la bande passante des données d'Ethereum L1 a considérablement augmenté, plusieurs machines virtuelles Ethereum (EVM) Rollup ont atteint la première étape. Chaque L2 existe comme un "fragment" avec ses propres règles et logiques internes, et la diversité et la pluralité des méthodes de mise en œuvre des fragments sont désormais une réalité. Mais comme nous l'avons vu, suivre ce chemin présente également des défis uniques. Par conséquent, notre tâche actuelle est de finaliser la feuille de route centrée sur Rollup et de résoudre ces problèmes tout en maintenant la robustesse et la décentralisation propres à 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 ont complètement hérité des propriétés fondamentales d'Ethereum, ( la confiance, l'ouverture, 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 triade de l'évolutivité
Le paradoxe de la triangle de la scalabilité est une idée proposée en 2017, qui soutient qu'il existe une contradiction 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é (, le nombre élevé de transactions traitées ) 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 à noter que le paradoxe du triangle n'est pas un théorème, et les posts présentant le paradoxe du triangle ne sont pas accompagnés de preuves mathématiques. Il fournit effectivement un argument mathématique heuristique : si un nœud amical et décentralisé ( par exemple, un ordinateur portable grand public ) 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'aurait qu'à compromettre un petit nombre de nœuds pour réussir à effectuer 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 que briser le paradoxe du triangle est impossible ; 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 dans cet argument.
Pendant des années, certaines chaînes à haute performance ont souvent affirmé qu'elles résolvaient le trilemme de manière fondamentale sans changer leur architecture, généralement en optimisant les nœuds grâce à des techniques d'ingénierie logicielle. Cela s'avère toujours trompeur, car faire fonctionner un nœud sur ces chaînes est beaucoup plus difficile que de faire fonctionner un nœud sur Ethereum. Cet article explorera pourquoi cela est le cas et pourquoi l'ingénierie logicielle du client 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 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 ne téléchargeant qu'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 a un modèle de confiance subtil few-of-N, mais il conserve les caractéristiques fondamentales des chaînes non extensibles, c'est-à-dire qu'une attaque à 51 % ne peut pas forcer les blocs défectueux à être acceptés par le réseau.
Une autre méthode pour résoudre le dilemme des trois difficultés 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 ne disposions que de 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 popularité des preuves succinctes non interactives à connaissance nulle SNARKs(, l'architecture Plasma est devenue plus viable pour un plus large éventail de scénarios d'utilisation que jamais.
![Vitalik nouvel article : futur possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
Progrès supplémentaire sur l'échantillonnage de la disponibilité des données
) Nous résolvons quel problème ?
Le 13 mars 2024, lors de la mise à niveau Dencun, la blockchain Ethereum aura 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. Si les données de transaction sont publiées directement sur la chaîne, un transfert ERC20 fait environ 180 octets, donc le maximum de TPS pour Rollup sur Ethereum est : 375000 / 12 / 180 = 173,6 TPS.
Si nous ajoutons la valeur maximale théorique du calldata d'Ethereum### : 30 millions de Gas par slot / 16 gas par octet = 1 875 000 octets par slot(, 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. 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 ~58000 TPS.
) Qu'est-ce que c'est ? Comment ça fonctionne ?
PeerDAS est une implémentation relativement simple du "1D sampling". Dans Ethereum, chaque blob est un polynôme de 4096 degrés dans un champ premier de 253 bits ###. Nous diffusons les parts du polynôme, chacune contenant 16 valeurs évaluées sur 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 valeurs évaluées, n'importe quel 4096 ( peuvent être récupérés selon les paramètres proposés : n'importe quel 64 parmi 128 échantillons possibles ) peut restaurer le blob.
Le fonctionnement de PeerDAS permet à chaque client d'écouter un petit nombre de sous-réseaux, où le i-ème sous-réseau diffuse le i-ème échantillon de tout blob, et en interrogeant les pairs dans le réseau p2p mondial concernant ( qui écoutera différents sous-réseaux ) pour demander les blobs nécessaires sur 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 d'enjeu utilisent SubnetDAS, tandis que les autres nœuds (, c'est-à-dire les clients ), utilisent PeerDAS.
Théoriquement, nous pouvons étendre l'échelle d'un "échantillonnage 1D" assez largement : si nous augmentons le nombre maximal de blobs à 256( avec un objectif de 128), nous pouvons atteindre un objectif de 16 Mo, et dans l'échantillonnage de la disponibilité des données, chaque nœud a 16 échantillons * 128 blobs * chaque blob chaque échantillon 512 octets = 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 à 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 les coûts de reconstruction.
Ainsi, nous voulons finalement aller plus loin et effectuer un échantillonnage 2D (2D sampling). Cette méthode 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 par un ensemble de nouveaux blobs virtuels, qui codent de manière redondante les mêmes informations.
Ainsi, finalement, nous voulons aller plus loin et effectuer un échantillonnage 2D, qui ne se limite pas à l'intérieur des blobs, mais effectue également un échantillonnage aléatoire entre les blobs. La propriété linéaire des engagements KZG est utilisée pour étendre un ensemble de blobs dans un bloc, qui contient une nouvelle liste de blobs virtuels codés de manière redondante contenant les mêmes informations.
Il est crucial de noter que l'extension 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 réellement les blocs n'ont besoin que de posséder l'engagement blob KZG, 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 amical pour la construction de blocs distribués.
( Que faut-il encore faire ? Quelles sont les compensations ?
La prochaine étape consiste à 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é, c'est un processus progressif. Dans le même temps, nous espérons qu'il y aura 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 fork.
À un stade futur plus éloigné, nous devons faire davantage 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 du KZG à une alternative qui soit sécurisée quantiquement et ne nécessite pas de paramétrage de confiance. Actuellement, nous ne savons pas encore quelles sont les solutions candidates favorables à la construction de blocs distribués. Même avec des techniques coûteuses de "force brute", c'est-à-dire 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() utilisant le hachage ( avec STIR(, en réalité, le STARK est presque de la même taille 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 sur la couche L1, cette option existe également. Cela est dû au fait que si la couche 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 sur la couche L1 des technologies similaires à Rollup) 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 sera réduite, ou du moins 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.
![Nouvel article de Vitalik : L'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
Compression des données
) Quel problème résolvons-nous ?
Chaque transaction dans un Rollup occupe un espace de données en chaîne considérable : 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 molécules, mais aussi celui des dénominateurs, permettant à 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 tiré parti des propriétés spécifiques des transactions :
Agrégation de signatures : nous venons de