Nouvel article de Vitalik : l'avenir possible d'Ethereum, The Surge
Le plan d'Ethereum comprenait initialement deux stratégies d'extensibilité : le sharding et les protocoles Layer 2. Ces deux stratégies 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 Rollup propose une répartition simple : 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 omniprésent dans la société : l'existence du système judiciaire (L1) n'est pas pour poursuivre une ultra-rapidité et une efficacité, mais pour protéger les contrats et la propriété, tandis que les entrepreneurs (L2) doivent construire sur cette couche de base solide pour mener l'humanité vers Mars.
Cette année, la feuille de route centrée sur les Rollups a obtenu des résultats importants : avec le lancement des blobs EIP-4844, la bande passante des données de l'Ethereum L1 a considérablement augmenté, et plusieurs Rollups Ethereum Virtual Machine (EVM) ont atteint la première étape. 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 comme nous l'avons vu, suivre cette voie présente également certains défis uniques. Par conséquent, notre tâche actuelle est de finaliser la feuille de route centrée sur les Rollups et de résoudre ces problèmes tout en maintenant la robustesse et la décentralisation qui caractérisent l'Ethereum L1.
The Surge: Objectif clé
L'avenir d'Ethereum grâce à 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 la confiance, de l'ouverture, de l'anti-censure );
Ethereum devrait se sentir comme un écosystème unifié, et non comme 34 blockchains différentes.
Le contenu de ce chapitre
Paradoxe du triangle de la scalabilité
Progrès 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 L2
Étendre l'exécution sur L1
paradoxe du triangle de la scalabilité
Le paradoxe de la triangle de la scalabilité est une idée proposée en 2017, qui soutient qu'il existe des contradictions entre trois caractéristiques de la blockchain : la décentralisation (, plus précisément : le faible coût d'exécution des nœuds ), la scalabilité (, le nombre de transactions traitées ) et la sécurité (, où un attaquant doit compromettre une grande partie des nœuds dans le réseau pour échouer une seule transaction ).
Il est important de noter que le paradoxe du triangle n'est pas un théorème, et les publications introduisant le paradoxe du triangle ne sont pas accompagnées de preuves mathématiques. Il présente effectivement un argument mathématique heuristique : si un nœud décentralisé amical (, 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 détruire qu'un petit nombre de nœuds pour réussir une transaction malveillante, ou (ii) votre nœud deviendra puissant alors 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 résoudre le trilemme de manière fondamentale sans changer l'architecture, généralement 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 ne peut pas à elle seule faire évoluer 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'un certain nombre de données sont disponibles et qu'un certain nombre d'étapes de calcul sont correctement exécutées, tout en téléchargeant seulement une petite quantité de données et en effectuant un nombre minimal de calculs. Les SNARKs sont sans confiance. L'échantillonnage de disponibilité des données a un modèle de confiance subtil few-of-N, mais il conserve les caractéristiques fondamentales d'une chaîne non extensible, c'est-à-dire qu'une attaque de 51 % ne peut pas forcer les 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 des techniques astucieuses 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é dans l'exécution sécurisée. Cependant, avec la popularité des SNARKs( et des preuves succinctes non interactives à connaissance nulle), l'architecture Plasma est devenue beaucoup plus viable pour des cas d'utilisation plus larges qu'auparavant.
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
Quels problèmes résolvons-nous ?
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 disponible d'environ 375 kB par slot. Si l'on suppose que 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 les Rollups sur Ethereum est : 375000 / 12 / 180 = 173,6 TPS.
Si nous ajoutons la valeur maximale théorique de calldata d'Ethereum( : chaque slot 30 millions de Gas / par octet 16 gas = chaque slot 1 875 000 octets), cela devient 607 TPS. En utilisant PeerDAS, le nombre de blobs pourrait augmenter à 8-16, ce qui fournirait 463-926 TPS pour calldata.
C'est une amélioration majeure pour 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é aux améliorations de compression des données Rollup, apportera ~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 sur le champ premier de 253 bits (. Nous diffusons les parts du polynôme, chacune contenant 16 valeurs d'évaluation provenant de 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 valeurs d'évaluation, 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 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 ) qui écoutera différents sous-réseaux ( pour obtenir les blobs supplémentaires dont il a besoin. Une version plus conservatrice, SubnetDAS, utilise uniquement le mécanisme de sous-réseau, sans demander des informations supplémentaires au niveau des pairs. La proposition actuelle est de permettre aux nœuds participant à la preuve de participation d'utiliser SubnetDAS, tandis que les autres nœuds ), c'est-à-dire les clients (, utilisent PeerDAS.
En théorie, nous pouvons étendre l'échelle d'un "échantillonnage 1D" assez largement : si nous augmentons le nombre maximum de blobs à 256) avec un objectif de 128(, nous pourrions atteindre l'objectif de 16 Mo, et dans l'échantillonnage de disponibilité des données, chaque nœud aurait 16 échantillons * 128 blobs * 512 octets par échantillon pour chaque blob = 1 Mo de bande passante de données par slot. Cela reste à 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 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.
Par conséquent, nous voulons finalement aller plus loin, effectuer un échantillonnage 2D )2D sampling(, cette méthode effectue non seulement un échantillonnage aléatoire à l'intérieur des blobs, mais aussi un échantillonnage aléatoire 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, ces blobs virtuels codent redondamment les mêmes informations.
Ainsi, nous souhaitons aller plus loin en effectuant un échantillonnage 2D, qui ne se limite pas à un échantillonnage aléatoire à l'intérieur des blobs, mais qui se fait é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, contenant une nouvelle liste de blobs virtuels codés en redondance 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 ce schéma fondamentalement amical pour la construction de blocs distribués. Les nœuds qui construisent réellement des blocs n'ont besoin que de l'engagement KZG du 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 unidimensionnel de disponibilité des données )1D DAS( est également fondamentalement amical pour la construction de blocs distribués.
![Vitalik nouvel article : Ethereum et son avenir potentiel, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
)# Que faut-il encore faire ? Quelles sont les considérations ?
La prochaine étape est de compléter la mise en œuvre et le lancement de PeerDAS. Ensuite, augmenter continuellement le nombre de blobs sur PeerDAS tout en observant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité est un processus progressif. Parallèlement, nous espérons qu'il y aura plus de travaux académiques pour réglementer PeerDAS et d'autres versions de DAS ainsi que leur interaction avec des problèmes de sécurité comme les règles de sélection de fork.
À des étapes plus éloignées dans le futur, nous devrons faire plus de travail pour déterminer la version idéale de 2D DAS et prouver ses propriétés de sécurité. Nous espérons également pouvoir finalement passer d'un KZG à une alternative qui soit à la fois sécurisée quantiquement et sans configuration de confiance. Actuellement, nous ne savons pas encore quelles options candidates sont favorables à la construction de blocs distribués. Même en utilisant des techniques coûteuses de "force brute", même en utilisant des STARKs récursifs pour générer des preuves de validité pour la reconstruction des lignes et des 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)( hachage ( utilisant STIR), en pratique, un STARK est presque aussi grand que l'ensemble du blob.
Je pense que le chemin de réalité à long terme est :
Mettre en œuvre un DAS 2D idéal;
Persister à utiliser 1D DAS, sacrifier l'efficacité de la bande passante d'échantillonnage, accepter une limite de données plus basse pour la simplicité et la robustesse.
Abandonner DA et accepter entièrement Plasma comme notre architecture Layer2 principale de préoccupation.
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 volumineux, 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 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. 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 les propositions de liste d'inclusion de paquets et les mécanismes de sélection de forks qui les entourent.
compression de données
(# Quel problème résolvons-nous ?
Chaque transaction dans un Rollup occupera une grande quantité d'espace de données on-chain : un transfert ERC20 nécessite environ 180 octets. Même avec un échantillonnage de disponibilité des données idéal, cela limite la scalabilité des protocoles de couche. 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 :
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp###
La compression en zéro octet remplace chaque longue séquence de zéros par deux octets, indiquant combien de zéros il y a. De plus, nous avons utilisé 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.
22 J'aime
Récompense
22
8
Reposter
Partager
Commentaire
0/400
BearHugger
· 08-19 09:26
Le principe, c'est de faire de l'argent en s'impliquant.
Voir l'originalRépondre0
MEVSupportGroup
· 08-17 12:40
L2 centralisé, ça me fait rire. N'est-ce pas juste une base de données auto-construite ?
Voir l'originalRépondre0
GasWaster
· 08-17 00:14
je paie toujours 500 gwei pour le bridge... when moon ser ?
Voir l'originalRépondre0
ForkPrince
· 08-16 19:07
Au fond, la voie de l'upgrade vise toujours à prendre les gens pour des idiots dans l'univers de la cryptomonnaie.
Voir l'originalRépondre0
OnchainDetective
· 08-16 19:06
Y a-t-il quelqu'un qui a remarqué que le modèle de transaction de l'adresse du portefeuille dans cet article de Vitalik Buterin est très suspect ? J'attends qu'un pair l'analyse.
Vitalik analyse Ethereum The Surge : objectif de 100 000 TPS et voie d'expansion L2
Nouvel article de Vitalik : l'avenir possible d'Ethereum, The Surge
Le plan d'Ethereum comprenait initialement deux stratégies d'extensibilité : le sharding et les protocoles Layer 2. Ces deux stratégies 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 Rollup propose une répartition simple : 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 omniprésent dans la société : l'existence du système judiciaire (L1) n'est pas pour poursuivre une ultra-rapidité et une efficacité, mais pour protéger les contrats et la propriété, tandis que les entrepreneurs (L2) doivent construire sur cette couche de base solide pour mener l'humanité vers Mars.
Cette année, la feuille de route centrée sur les Rollups a obtenu des résultats importants : avec le lancement des blobs EIP-4844, la bande passante des données de l'Ethereum L1 a considérablement augmenté, et plusieurs Rollups Ethereum Virtual Machine (EVM) ont atteint la première étape. 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 comme nous l'avons vu, suivre cette voie présente également certains défis uniques. Par conséquent, notre tâche actuelle est de finaliser la feuille de route centrée sur les Rollups et de résoudre ces problèmes tout en maintenant la robustesse et la décentralisation qui caractérisent l'Ethereum L1.
The Surge: Objectif clé
L'avenir d'Ethereum grâce à 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 la confiance, de l'ouverture, de l'anti-censure );
Ethereum devrait se sentir comme un écosystème unifié, et non comme 34 blockchains différentes.
Le contenu de ce chapitre
paradoxe du triangle de la scalabilité
Le paradoxe de la triangle de la scalabilité est une idée proposée en 2017, qui soutient qu'il existe des contradictions entre trois caractéristiques de la blockchain : la décentralisation (, plus précisément : le faible coût d'exécution des nœuds ), la scalabilité (, le nombre de transactions traitées ) et la sécurité (, où un attaquant doit compromettre une grande partie des nœuds dans le réseau pour échouer une seule transaction ).
Il est important de noter que le paradoxe du triangle n'est pas un théorème, et les publications introduisant le paradoxe du triangle ne sont pas accompagnées de preuves mathématiques. Il présente effectivement un argument mathématique heuristique : si un nœud décentralisé amical (, 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 détruire qu'un petit nombre de nœuds pour réussir une transaction malveillante, ou (ii) votre nœud deviendra puissant alors 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 résoudre le trilemme de manière fondamentale sans changer l'architecture, généralement 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 ne peut pas à elle seule faire évoluer 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'un certain nombre de données sont disponibles et qu'un certain nombre d'étapes de calcul sont correctement exécutées, tout en téléchargeant seulement une petite quantité de données et en effectuant un nombre minimal de calculs. Les SNARKs sont sans confiance. L'échantillonnage de disponibilité des données a un modèle de confiance subtil few-of-N, mais il conserve les caractéristiques fondamentales d'une chaîne non extensible, c'est-à-dire qu'une attaque de 51 % ne peut pas forcer les 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 des techniques astucieuses 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é dans l'exécution sécurisée. Cependant, avec la popularité des SNARKs( et des preuves succinctes non interactives à connaissance nulle), l'architecture Plasma est devenue beaucoup plus viable pour des cas d'utilisation plus larges qu'auparavant.
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
Quels problèmes résolvons-nous ?
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 disponible d'environ 375 kB par slot. Si l'on suppose que 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 les Rollups sur Ethereum est : 375000 / 12 / 180 = 173,6 TPS.
Si nous ajoutons la valeur maximale théorique de calldata d'Ethereum( : chaque slot 30 millions de Gas / par octet 16 gas = chaque slot 1 875 000 octets), cela devient 607 TPS. En utilisant PeerDAS, le nombre de blobs pourrait augmenter à 8-16, ce qui fournirait 463-926 TPS pour calldata.
C'est une amélioration majeure pour 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é aux améliorations de compression des données Rollup, apportera ~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 sur le champ premier de 253 bits (. Nous diffusons les parts du polynôme, chacune contenant 16 valeurs d'évaluation provenant de 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 valeurs d'évaluation, 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 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 ) qui écoutera différents sous-réseaux ( pour obtenir les blobs supplémentaires dont il a besoin. Une version plus conservatrice, SubnetDAS, utilise uniquement le mécanisme de sous-réseau, sans demander des informations supplémentaires au niveau des pairs. La proposition actuelle est de permettre aux nœuds participant à la preuve de participation d'utiliser SubnetDAS, tandis que les autres nœuds ), c'est-à-dire les clients (, utilisent PeerDAS.
En théorie, nous pouvons étendre l'échelle d'un "échantillonnage 1D" assez largement : si nous augmentons le nombre maximum de blobs à 256) avec un objectif de 128(, nous pourrions atteindre l'objectif de 16 Mo, et dans l'échantillonnage de disponibilité des données, chaque nœud aurait 16 échantillons * 128 blobs * 512 octets par échantillon pour chaque blob = 1 Mo de bande passante de données par slot. Cela reste à 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 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.
Par conséquent, nous voulons finalement aller plus loin, effectuer un échantillonnage 2D )2D sampling(, cette méthode effectue non seulement un échantillonnage aléatoire à l'intérieur des blobs, mais aussi un échantillonnage aléatoire 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, ces blobs virtuels codent redondamment les mêmes informations.
Ainsi, nous souhaitons aller plus loin en effectuant un échantillonnage 2D, qui ne se limite pas à un échantillonnage aléatoire à l'intérieur des blobs, mais qui se fait é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, contenant une nouvelle liste de blobs virtuels codés en redondance 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 ce schéma fondamentalement amical pour la construction de blocs distribués. Les nœuds qui construisent réellement des blocs n'ont besoin que de l'engagement KZG du 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 unidimensionnel de disponibilité des données )1D DAS( est également fondamentalement amical pour la construction de blocs distribués.
![Vitalik nouvel article : Ethereum et son avenir potentiel, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
)# Que faut-il encore faire ? Quelles sont les considérations ?
La prochaine étape est de compléter la mise en œuvre et le lancement de PeerDAS. Ensuite, augmenter continuellement le nombre de blobs sur PeerDAS tout en observant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité est un processus progressif. Parallèlement, nous espérons qu'il y aura plus de travaux académiques pour réglementer PeerDAS et d'autres versions de DAS ainsi que leur interaction avec des problèmes de sécurité comme les règles de sélection de fork.
À des étapes plus éloignées dans le futur, nous devrons faire plus de travail pour déterminer la version idéale de 2D DAS et prouver ses propriétés de sécurité. Nous espérons également pouvoir finalement passer d'un KZG à une alternative qui soit à la fois sécurisée quantiquement et sans configuration de confiance. Actuellement, nous ne savons pas encore quelles options candidates sont favorables à la construction de blocs distribués. Même en utilisant des techniques coûteuses de "force brute", même en utilisant des STARKs récursifs pour générer des preuves de validité pour la reconstruction des lignes et des 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)( hachage ( utilisant STIR), en pratique, un STARK est presque aussi grand que l'ensemble du blob.
Je pense que le chemin de réalité à 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 volumineux, 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 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. 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 les propositions de liste d'inclusion de paquets et les mécanismes de sélection de forks qui les entourent.
compression de données
(# Quel problème résolvons-nous ?
Chaque transaction dans un Rollup occupera une grande quantité d'espace de données on-chain : un transfert ERC20 nécessite environ 180 octets. Même avec un échantillonnage de disponibilité des données idéal, cela limite la scalabilité des protocoles de couche. 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 :
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp###
La compression en zéro octet remplace chaque longue séquence de zéros 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