Nouveau texte de Vitalik : l'avenir possible d'Ethereum, The Surge
La feuille de route d'Ethereum comprenait initialement 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 les Rollups, qui reste la stratégie d'extension actuelle d'Ethereum. La feuille de route centrée sur les Rollups propose une division du travail 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'expansion de l'écosystème.
Cette année, la feuille de route centrée sur Rollup a réalisé 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 phase. 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 cette voie présente également des défis uniques. Ainsi, 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 à travers L2 peut atteindre plus de 100 000 TPS;
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, (, de confiance, ouvertes, anti-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 l'évolutivité
Avancées supplémentaires sur l'échantillonnage de la disponibilité des données
Compression des données
Plasma généralisé
Systèmes de preuve L2 matures
Amélioration de l'interopérabilité entre L2
Étendre l'exécution sur L1
Paradoxe du triangle de la scalabilité
Le paradoxe de la triangle de scalabilité est une idée proposée en 2017, qui postule qu'il existe des contradictions entre trois caractéristiques de la blockchain : la décentralisation (, plus précisément : le coût d'exploitation des nœuds est faible ), la scalabilité ( c'est-à-dire 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 seule transaction ).
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 n'ont pas non plus été accompagnées de preuves mathématiques. Il fournit en effet un argument mathématique heuristique : si un nœud amical décentralisé (, par exemple 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 qu'un petit nombre de nœuds pour réaliser une transaction malveillante, ou (ii) votre nœud deviendra puissant, tandis que votre chaîne ne sera pas décentralisée. L'objectif de cet article n'est en aucun cas 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 sans modifier fondamentalement l'architecture, souvent en optimisant les nœuds grâce à des techniques d'ingénierie logicielle. 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 ne peut pas à elle seule 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 exécutées correctement, tout 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 possède un modèle de confiance subtil de few-of-N, mais il conserve les caractéristiques fondamentales que possède une chaîne non extensible, à savoir que même une attaque à 51 % ne peut pas forcer un bloc défectueux à être accepté 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 de surveillance aux utilisateurs de manière compatible avec les incitations. Entre 2017 et 2019, lorsque nous ne disposions que de la preuve de fraude comme moyen d'élargir 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 zéro connaissance succinctes non interactives), l'architecture Plasma est devenue plus viable pour une plus grande variété de cas d'utilisation que jamais.
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
Quels problèmes 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, 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, 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 du calldata d'Ethereum ( : chaque slot 30 millions de Gas / par octet 16 gas = chaque slot 1 875 000 octets ), cela donnerait 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, et si cela est combiné avec des améliorations de compression des données Rollup, cela 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 le champ premier de 253 bits (. Nous diffusons les parts du polynôme, chacune contenant 16 valeurs d'évaluation des 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 valeurs d'évaluation, n'importe quel ensemble de 4096 ) peut être récupéré à partir des paramètres proposés actuellement : n'importe quel 64 parmi les 128 échantillons possibles (.
Le fonctionnement de PeerDAS est de 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 en demandant aux pairs dans le réseau p2p mondial ) qui écoutera différents sous-réseaux ( pour demander les blobs dont il a besoin 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 permettre aux nœuds participant à la preuve d'enjeu d'utiliser SubnetDAS, tandis que les autres nœuds ), c'est-à-dire les clients (, utilisent PeerDAS.
Théoriquement, nous pouvons étendre une "échantillonnage 1D" à une échelle assez grande : si nous augmentons le nombre maximum de blobs à 256) avec un objectif de 128(, alors nous pouvons atteindre l'objectif de 16 Mo, et avec un é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 créneau. 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.
![Vitalik nouvel article : Ethereum et son avenir possible, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
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 de l'engagement KZG, nous élargissons un ensemble de blobs dans un bloc à l'aide d'un ensemble de nouveaux blobs virtuels, qui codent de manière redondante les mêmes informations.
Ainsi, finalement, nous souhaitons aller plus loin et effectuer un échantillonnage 2D, qui non seulement échantillonne aléatoirement à l'intérieur des blobs, mais aussi 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 avec les mêmes informations.
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 réellement des blocs n'ont besoin que de posséder l'engagement KZG des blobs, et ils peuvent se fier à 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 sont les compromis ?
Ensuite, il s'agit de compléter la mise en œuvre et le lancement de PeerDAS. Par la suite, nous augmenterons progressivement le nombre de blobs sur PeerDAS, tout en observant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité, c'est un processus graduel. En même temps, nous espérons avoir plus de travaux académiques pour réguler 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 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 de KZG à une alternative quantiquement sécurisée et sans configuration de confiance. Pour l'instant, nous ne savons pas encore quelles sont les solutions candidates qui sont favorables à la construction de blocs distribués. Même en utilisant des techniques de "force brute" coûteuses, 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 qu'en théorie, la taille d'un STARK soit O(log)n### * log(log(n)( le hachage ( 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 :
Mettre en œuvre un DAS 2D idéal;
Maintenir l'utilisation de 1D DAS, sacrifier l'efficacité de la bande passante d'échantillonnage, pour la simplicité et la robustesse, accepter une limite de données inférieure.
Abandonner DA, accepter complètement Plasma comme notre principale architecture Layer2 d'intérêt.
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é, c'est pourquoi 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 les DAS 2D diminuera ou du moins sera retardée, et si Plasma est largement utilisé, la demande diminuera encore davantage. Les DAS posent également des défis aux protocoles et mécanismes de construction de blocs distribués : bien que les DAS soient théoriquement favorables à 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 sélection de forks qui l'entourent.
Compression des données
( Quels problèmes résolvons-nous ?
Chaque transaction dans un Rollup occupe une grande quantité 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 de 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, afin que chaque transaction dans un Rollup occupe 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 :
![Vitalik nouvel article : l'avenir potentiel d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp###
Dans la compression des zéros, chaque longue séquence de zéros est remplacée par deux octets qui indiquent 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 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, et cette signature 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. Mais dans un environnement L2 où les données sont rares, l'utilisation de signatures BLS a du sens. La caractéristique d'agrégation de l'ERC-4337 offre une voie pour réaliser cette fonctionnalité.
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.
11 J'aime
Récompense
11
6
Partager
Commentaire
0/400
DeFiGrayling
· Il y a 9h
L2 parier sur un grand bull run
Voir l'originalRépondre0
QuorumVoter
· Il y a 9h
Regardez, c'est toujours le même vieux chemin.
Voir l'originalRépondre0
TestnetNomad
· Il y a 9h
Vitalik Buterin est encore en train de faire des siennes.
Voir l'originalRépondre0
WenAirdrop
· Il y a 9h
Encore en train de faire des promesses en l'air, Vitalik Buterin
Voir l'originalRépondre0
WhaleMistaker
· Il y a 10h
La piste L2 est devenue folle.
Voir l'originalRépondre0
PumpDoctrine
· Il y a 10h
le gaz, qu'il soit changé ou non, c'est la vieille V qui décide.
Vitalik envisage l'avenir d'Ethereum : comment The Surge permet d'atteindre une capacité d'extension de 100 000 TPS
Nouveau texte de Vitalik : l'avenir possible d'Ethereum, The Surge
La feuille de route d'Ethereum comprenait initialement 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 les Rollups, qui reste la stratégie d'extension actuelle d'Ethereum. La feuille de route centrée sur les Rollups propose une division du travail 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'expansion de l'écosystème.
Cette année, la feuille de route centrée sur Rollup a réalisé 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 phase. 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 cette voie présente également des défis uniques. Ainsi, 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 à travers L2 peut atteindre plus de 100 000 TPS;
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, (, de confiance, ouvertes, anti-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é
Le paradoxe de la triangle de scalabilité est une idée proposée en 2017, qui postule qu'il existe des contradictions entre trois caractéristiques de la blockchain : la décentralisation (, plus précisément : le coût d'exploitation des nœuds est faible ), la scalabilité ( c'est-à-dire 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 seule transaction ).
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 n'ont pas non plus été accompagnées de preuves mathématiques. Il fournit en effet un argument mathématique heuristique : si un nœud amical décentralisé (, par exemple 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 qu'un petit nombre de nœuds pour réaliser une transaction malveillante, ou (ii) votre nœud deviendra puissant, tandis que votre chaîne ne sera pas décentralisée. L'objectif de cet article n'est en aucun cas 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 sans modifier fondamentalement l'architecture, souvent en optimisant les nœuds grâce à des techniques d'ingénierie logicielle. 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 ne peut pas à elle seule 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 exécutées correctement, tout 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 possède un modèle de confiance subtil de few-of-N, mais il conserve les caractéristiques fondamentales que possède une chaîne non extensible, à savoir que même une attaque à 51 % ne peut pas forcer un bloc défectueux à être accepté 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 de surveillance aux utilisateurs de manière compatible avec les incitations. Entre 2017 et 2019, lorsque nous ne disposions que de la preuve de fraude comme moyen d'élargir 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 zéro connaissance succinctes non interactives), l'architecture Plasma est devenue plus viable pour une plus grande variété de cas d'utilisation que jamais.
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
Quels problèmes 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, 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, 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 du calldata d'Ethereum ( : chaque slot 30 millions de Gas / par octet 16 gas = chaque slot 1 875 000 octets ), cela donnerait 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, et si cela est combiné avec des améliorations de compression des données Rollup, cela 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 le champ premier de 253 bits (. Nous diffusons les parts du polynôme, chacune contenant 16 valeurs d'évaluation des 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 valeurs d'évaluation, n'importe quel ensemble de 4096 ) peut être récupéré à partir des paramètres proposés actuellement : n'importe quel 64 parmi les 128 échantillons possibles (.
Le fonctionnement de PeerDAS est de 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 en demandant aux pairs dans le réseau p2p mondial ) qui écoutera différents sous-réseaux ( pour demander les blobs dont il a besoin 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 permettre aux nœuds participant à la preuve d'enjeu d'utiliser SubnetDAS, tandis que les autres nœuds ), c'est-à-dire les clients (, utilisent PeerDAS.
Théoriquement, nous pouvons étendre une "échantillonnage 1D" à une échelle assez grande : si nous augmentons le nombre maximum de blobs à 256) avec un objectif de 128(, alors nous pouvons atteindre l'objectif de 16 Mo, et avec un é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 créneau. 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.
![Vitalik nouvel article : Ethereum et son avenir possible, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
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 de l'engagement KZG, nous élargissons un ensemble de blobs dans un bloc à l'aide d'un ensemble de nouveaux blobs virtuels, qui codent de manière redondante les mêmes informations.
Ainsi, finalement, nous souhaitons aller plus loin et effectuer un échantillonnage 2D, qui non seulement échantillonne aléatoirement à l'intérieur des blobs, mais aussi 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 avec les mêmes informations.
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 réellement des blocs n'ont besoin que de posséder l'engagement KZG des blobs, et ils peuvent se fier à 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 sont les compromis ?
Ensuite, il s'agit de compléter la mise en œuvre et le lancement de PeerDAS. Par la suite, nous augmenterons progressivement le nombre de blobs sur PeerDAS, tout en observant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité, c'est un processus graduel. En même temps, nous espérons avoir plus de travaux académiques pour réguler 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 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 de KZG à une alternative quantiquement sécurisée et sans configuration de confiance. Pour l'instant, nous ne savons pas encore quelles sont les solutions candidates qui sont favorables à la construction de blocs distribués. Même en utilisant des techniques de "force brute" coûteuses, 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 qu'en théorie, la taille d'un STARK soit O(log)n### * log(log(n)( le hachage ( 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é, c'est pourquoi 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 les DAS 2D diminuera ou du moins sera retardée, et si Plasma est largement utilisé, la demande diminuera encore davantage. Les DAS posent également des défis aux protocoles et mécanismes de construction de blocs distribués : bien que les DAS soient théoriquement favorables à 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 sélection de forks qui l'entourent.
Compression des données
( Quels problèmes résolvons-nous ?
Chaque transaction dans un Rollup occupe une grande quantité 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 de 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, afin que chaque transaction dans un Rollup occupe 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 :
![Vitalik nouvel article : l'avenir potentiel d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp###
Dans la compression des zéros, chaque longue séquence de zéros est remplacée par deux octets qui indiquent 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 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, et cette signature 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. Mais dans un environnement L2 où les données sont rares, l'utilisation de signatures BLS a du sens. La caractéristique d'agrégation de l'ERC-4337 offre une voie pour réaliser cette fonctionnalité.
Utiliser