La feuille de route d'Ethereum comprenait initialement deux stratégies d'évolutivité : le sharding et les protocoles Layer 2. Ces deux voies se sont finalement fusionnées pour former une feuille de route centrée sur les Rollups, qui reste aujourd'hui la stratégie d'expansion d'Ethereum. La feuille de route centrée sur les Rollups propose une division claire des tâches : Ethereum L1 se concentre sur le fait de devenir une couche de base puissante et décentralisée, tandis que L2 prend en charge la tâche d'aider l'écosystème à se développer.
Cette année, la feuille de route centrée sur les Rollups a réalisé 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 de la machine virtuelle Ethereum ont atteint la première phase. Chaque L2 existe en tant que "fragment" avec ses propres règles et logiques internes. La diversité et la pluralité des modes de réalisation des fragments sont désormais une réalité. Cependant, ce chemin fait également face à certains défis uniques. Ainsi, 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 propres à l'Ethereum L1.
The Surge: Objectifs clés
L'avenir d'Ethereum via L2 peut atteindre plus de 100 000 TPS;
Maintenir la décentralisation et la robustesse de L1;
Au moins quelques L2 ont complètement hérité des propriétés fondamentales d'Ethereum de confiance, d'ouverture et de résistance à la censure (;
Ethereum devrait se sentir comme un écosystème unifié, et non comme 34 blockchains différentes.
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-6e846316491095cf7d610acb3b583d06.webp(
Contenu du chapitre
Paradoxe des triangles de 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 les L2
Étendre l'exécution sur L1
Paradoxe de la triangle de scalabilité
Le paradoxe du triangle de la scalabilité soutient qu'il existe une contradiction entre trois caractéristiques de la blockchain : la décentralisation ), plus précisément : un faible coût d'exploitation des nœuds (, la scalabilité ), un grand nombre 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 transaction unique (.
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 ne sont pas accompagnées de preuves mathématiques. Cela 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 pas de prouver qu'il est impossible de briser le paradoxe du triangle ; au contraire, il vise à montrer que briser le paradoxe ternar est difficile et nécessite, dans une certaine mesure, de sortir du cadre de pensée implicite de cet argument.
![Vitalik nouveau texte : L'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
Depuis de nombreuses années, certaines chaînes haute performance prétendent avoir résolu le trilemme de la scalabilité sans changer fondamentalement l'architecture, généralement en optimisant les nœuds grâce à des techniques d'ingénierie logicielle. Cela est 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 des clients L1 seuls ne peut pas faire évoluer Ethereum.
Cependant, la combinaison de l'échantillonnage de 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 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 disponibilité des données présente un modèle de confiance subtil de few-of-N, mais il conserve les caractéristiques fondamentales d'une chaîne non extensible, à savoir qu'une attaque à 51 % ne peut pas forcer les blocs malveillants à ê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 compatible avec les incitations. Entre 2017 et 2019, lorsque nous n'avions que 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 SNARKs), des preuves non interactives succinctes de connaissance zéro(, l'architecture Plasma est devenue plus viable pour un éventail d'applications plus large qu'auparavant.
![Vitalik nouveau texte : Ethereum, un avenir possible, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
) Quel problème sommes-nous en train 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 toutes les 12 secondes, ou 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 maximum pour le Rollup 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(, alors cela devient 607 TPS. Avec PeerDAS, le nombre de blobs pourrait passer à 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.
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
) Qu'est-ce que c'est ? Comment ça fonctionne ?
PeerDAS est une implémentation relativement simple de la "1D sampling". Dans Ethereum, chaque blob est un polynôme de degré 4096 sur un domaine de nombres premiers de 253 bits ###. Nous diffusons les parts du polynôme, où chaque part contient 16 valeurs d'évaluation à partir de 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 restauré selon les paramètres proposés : n'importe quel 64 parmi 128 échantillons possibles ).
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 à qui dans le réseau p2p mondial ( écoutera les différents sous-réseaux ) pour obtenir 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 demander de manière supplémentaire à la couche de pair. 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 un 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 slot. Cela reste juste 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.
Ainsi, nous voulons finalement aller plus loin, effectuer un échantillonnage 2D (2D sampling). Cette méthode permet non seulement d'effectuer un échantillonnage aléatoire à l'intérieur du blob, mais également d'effectuer un échantillonnage aléatoire entre les blobs. En utilisant les propriétés linéaires des engagements KZG, nous élargissons l'ensemble des blobs dans un bloc par un ensemble de nouveaux blobs virtuels, ces blobs virtuels codant redondamment les mêmes informations.
Ainsi, finalement, nous souhaitons aller plus loin en effectuant un échantillonnage 2D, qui se fait non seulement à l'intérieur des blobs, mais également entre les blobs. La propriété linéaire de l'engagement 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 avec les mêmes informations.
Il est crucial de noter que l'extension de l'engagement de calcul ne nécessite pas de blob, donc ce schéma est fondamentalement amical 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 de blob, 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 ? Quelles sont les considérations ?
La prochaine étape est de finaliser l'implémentation et le lancement de PeerDAS. Ensuite, nous allons augmenter progressivement le nombre de blobs sur PeerDAS tout en surveillant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité, ce qui est un processus progressif. 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 les questions de sécurité liées aux règles de sélection de fork.
À des étapes futures plus lointaines, 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 de KZG à une alternative qui soit quantiquement sécurisée et ne nécessite pas de configuration de confiance. Actuellement, nous ne savons pas encore quelles sont les solutions candidates amicales pour la construction de blocs distribués. Même en utilisant une technologie de "force brute" coûteuse, même en utilisant STARK récursif pour générer des preuves de validité pour reconstruire les lignes et les colonnes, cela ne suffit pas à répondre aux besoins, car bien que techniquement, un STARK ait une taille de O)log(n) * log###log(n() 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;
S'engager à 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 plus basse.
Abandonner DA et 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 volumineux, et les clients souhaiteront avoir une méthode efficace pour vérifier leur validité, c'est pourquoi nous devrons utiliser au niveau L1 des technologies similaires à celles du 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 sera encore réduite. 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 d'être combiné avec les propositions de liste d'inclusion des paquets et les mécanismes de choix de fork qui les entourent.
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-e0ddd016e2afb3218833324254451c1d.webp(
Compression des données
) Quels problèmes 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 du numérateur, mais aussi ceux du dénominateur, 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 :
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.webp(
Compression à zéro octet en cours, remplaçant chaque séquence longue de zéro octet par deux octets, indiquant combien de zéro octets il y a. De plus, nous avons utilisé les 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.
11 J'aime
Récompense
11
4
Partager
Commentaire
0/400
Ser_Liquidated
· Il y a 14h
Ouvrir quoi comme piège, de toute façon, je suis déjà à l'intérieur.
Voir l'originalRépondre0
ThatsNotARugPull
· Il y a 21h
C'est rare que cet article ne fasse pas de promesses en l'air~
Voir l'originalRépondre0
SellTheBounce
· Il y a 21h
Encore un plan de prise de pigeons. L'histoire nous a déjà appris qu'il faut vendre.
Voir l'originalRépondre0
SchroedingerAirdrop
· Il y a 21h
Encore en train de rollup ? Ça disparait en vendant.
Ethereum The Surge : le chemin et les défis d'une montée en charge à 100 000 TPS
L'avenir potentiel d'Ethereum : The Surge
La feuille de route d'Ethereum comprenait initialement deux stratégies d'évolutivité : le sharding et les protocoles Layer 2. Ces deux voies se sont finalement fusionnées pour former une feuille de route centrée sur les Rollups, qui reste aujourd'hui la stratégie d'expansion d'Ethereum. La feuille de route centrée sur les Rollups propose une division claire des tâches : Ethereum L1 se concentre sur le fait de devenir une couche de base puissante et décentralisée, tandis que L2 prend en charge la tâche d'aider l'écosystème à se développer.
Cette année, la feuille de route centrée sur les Rollups a réalisé 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 de la machine virtuelle Ethereum ont atteint la première phase. Chaque L2 existe en tant que "fragment" avec ses propres règles et logiques internes. La diversité et la pluralité des modes de réalisation des fragments sont désormais une réalité. Cependant, ce chemin fait également face à certains défis uniques. Ainsi, 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 propres à l'Ethereum L1.
The Surge: Objectifs clés
L'avenir d'Ethereum via L2 peut atteindre plus de 100 000 TPS;
Maintenir la décentralisation et la robustesse de L1;
Au moins quelques L2 ont complètement hérité des propriétés fondamentales d'Ethereum de confiance, d'ouverture et de résistance à la censure (;
Ethereum devrait se sentir comme un écosystème unifié, et non comme 34 blockchains différentes.
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-6e846316491095cf7d610acb3b583d06.webp(
Contenu du chapitre
Paradoxe de la triangle de scalabilité
Le paradoxe du triangle de la scalabilité soutient qu'il existe une contradiction entre trois caractéristiques de la blockchain : la décentralisation ), plus précisément : un faible coût d'exploitation des nœuds (, la scalabilité ), un grand nombre 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 transaction unique (.
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 ne sont pas accompagnées de preuves mathématiques. Cela 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 pas de prouver qu'il est impossible de briser le paradoxe du triangle ; au contraire, il vise à montrer que briser le paradoxe ternar est difficile et nécessite, dans une certaine mesure, de sortir du cadre de pensée implicite de cet argument.
![Vitalik nouveau texte : L'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
Depuis de nombreuses années, certaines chaînes haute performance prétendent avoir résolu le trilemme de la scalabilité sans changer fondamentalement l'architecture, généralement en optimisant les nœuds grâce à des techniques d'ingénierie logicielle. Cela est 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 des clients L1 seuls ne peut pas faire évoluer Ethereum.
Cependant, la combinaison de l'échantillonnage de 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 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 disponibilité des données présente un modèle de confiance subtil de few-of-N, mais il conserve les caractéristiques fondamentales d'une chaîne non extensible, à savoir qu'une attaque à 51 % ne peut pas forcer les blocs malveillants à ê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 compatible avec les incitations. Entre 2017 et 2019, lorsque nous n'avions que 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 SNARKs), des preuves non interactives succinctes de connaissance zéro(, l'architecture Plasma est devenue plus viable pour un éventail d'applications plus large qu'auparavant.
![Vitalik nouveau texte : Ethereum, un avenir possible, The Surge])https://img-cdn.gateio.im/webp-social/moments-40311fde406a2b6c83ba590c35e23a7c.webp(
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
) Quel problème sommes-nous en train 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 toutes les 12 secondes, ou 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 maximum pour le Rollup 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(, alors cela devient 607 TPS. Avec PeerDAS, le nombre de blobs pourrait passer à 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.
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
) Qu'est-ce que c'est ? Comment ça fonctionne ?
PeerDAS est une implémentation relativement simple de la "1D sampling". Dans Ethereum, chaque blob est un polynôme de degré 4096 sur un domaine de nombres premiers de 253 bits ###. Nous diffusons les parts du polynôme, où chaque part contient 16 valeurs d'évaluation à partir de 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 restauré selon les paramètres proposés : n'importe quel 64 parmi 128 échantillons possibles ).
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 à qui dans le réseau p2p mondial ( écoutera les différents sous-réseaux ) pour obtenir 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 demander de manière supplémentaire à la couche de pair. 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 un 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 slot. Cela reste juste 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.
Ainsi, nous voulons finalement aller plus loin, effectuer un échantillonnage 2D (2D sampling). Cette méthode permet non seulement d'effectuer un échantillonnage aléatoire à l'intérieur du blob, mais également d'effectuer un échantillonnage aléatoire entre les blobs. En utilisant les propriétés linéaires des engagements KZG, nous élargissons l'ensemble des blobs dans un bloc par un ensemble de nouveaux blobs virtuels, ces blobs virtuels codant redondamment les mêmes informations.
Ainsi, finalement, nous souhaitons aller plus loin en effectuant un échantillonnage 2D, qui se fait non seulement à l'intérieur des blobs, mais également entre les blobs. La propriété linéaire de l'engagement 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 avec les mêmes informations.
Il est crucial de noter que l'extension de l'engagement de calcul ne nécessite pas de blob, donc ce schéma est fondamentalement amical 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 de blob, 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 ? Quelles sont les considérations ?
La prochaine étape est de finaliser l'implémentation et le lancement de PeerDAS. Ensuite, nous allons augmenter progressivement le nombre de blobs sur PeerDAS tout en surveillant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité, ce qui est un processus progressif. 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 les questions de sécurité liées aux règles de sélection de fork.
À des étapes futures plus lointaines, 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 de KZG à une alternative qui soit quantiquement sécurisée et ne nécessite pas de configuration de confiance. Actuellement, nous ne savons pas encore quelles sont les solutions candidates amicales pour la construction de blocs distribués. Même en utilisant une technologie de "force brute" coûteuse, même en utilisant STARK récursif pour générer des preuves de validité pour reconstruire les lignes et les colonnes, cela ne suffit pas à répondre aux besoins, car bien que techniquement, un STARK ait une taille de O)log(n) * log###log(n() 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 volumineux, et les clients souhaiteront avoir une méthode efficace pour vérifier leur validité, c'est pourquoi nous devrons utiliser au niveau L1 des technologies similaires à celles du 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 sera encore réduite. 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 d'être combiné avec les propositions de liste d'inclusion des paquets et les mécanismes de choix de fork qui les entourent.
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-e0ddd016e2afb3218833324254451c1d.webp(
Compression des données
) Quels problèmes 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 du numérateur, mais aussi ceux du dénominateur, 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 :
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.webp(
Compression à zéro octet en cours, remplaçant chaque séquence longue de zéro octet par deux octets, indiquant combien de zéro octets il y a. De plus, nous avons utilisé les transactions.