La feuille de route d'Ethereum comprenait initialement deux stratégies d'extension : le sharding et les protocoles Layer2. Le sharding permet à chaque nœud de ne vérifier et de stocker qu'une partie des transactions, tandis que Layer2 construit des réseaux au-dessus d'Ethereum, tirant parti de sa sécurité tout en conservant la plupart des données et des calculs en dehors de la chaîne principale. Ces deux méthodes ont finalement fusionné en une feuille de route centrée sur les Rollups, qui reste à ce jour la stratégie d'extension d'Ethereum.
La feuille de route centrée sur Rollup 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 prend en charge la tâche d'aider l'écosystème à se développer. Ce modèle est très courant dans la société : le système judiciaire (L1) existe pour protéger les contrats et la propriété, tandis que les entrepreneurs (L2) construisent sur cette base, faisant avancer le développement humain.
Cette année, la feuille de route centrée sur Rollup a fait des progrès significatifs : le lancement des blobs EIP-4844 a considérablement augmenté la bande passante des données d'Ethereum L1, 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, la diversité des méthodes de mise en œuvre des fragments est désormais une réalité. Mais ce chemin fait également face à certains défis uniques. Notre tâche actuelle est de finaliser la feuille de route centrée sur Rollup, de résoudre ces problèmes tout en maintenant la robustesse et la décentralisation d'Ethereum L1.
The Surge : Objectifs clés
L'avenir d'Ethereum peut atteindre plus de 100 000 TPS grâce aux L2;
Maintenir la décentralisation et la robustesse de L1;
Au moins une partie des L2 hérite complètement des propriétés fondamentales d'Ethereum : ( sans confiance, ouvertes, résistantes à la censure );
Ethereum devrait se sentir comme un écosystème unifié, et non comme 34 blockchains différentes.
Paradoxe de la triangle de la scalabilité
Le paradoxe du triangle de la scalabilité soutient qu'il existe une contradiction entre les trois caractéristiques de la blockchain : décentralisation (, coût faible des nœuds fonctionnant ), scalabilité ( pour traiter un grand nombre de transactions ) et sécurité (, où un attaquant doit compromettre une grande partie des nœuds du réseau pour faire échouer une transaction unique ).
Le paradoxe triangulaire n'est pas un théorème, et les posts qui l'introduisent ne sont pas accompagnés de preuves mathématiques. Il présente un argument mathématique heuristique : si un nœud décentralisé amical 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 des nœuds, ce qui signifie qu'un attaquant n'a besoin de compromettre qu'un petit nombre de nœuds pour faire passer une transaction malveillante, ou (ii) votre nœud deviendra puissant, tandis que votre chaîne ne sera pas décentralisée. Cet article vise à montrer qu'il est difficile de briser le paradoxe ternaire, nécessitant dans une certaine mesure de sortir du cadre de pensée implicite de cet argument.
Depuis de nombreuses années, certaines chaînes haute performance prétendent résoudre le trilemme sans changer fondamentalement l'architecture, généralement en optimisant 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.
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, 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 a un modèle de confiance subtil few-of-N, mais il conserve les caractéristiques fondamentales des chaînes non extensibles, à savoir qu'une attaque à 51 % ne peut pas forcer des blocs défectueux à être acceptés par le réseau.
Une autre méthode pour résoudre le trilemme est l'architecture Plasma, qui utilise 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 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 généralisation des SNARKs, l'architecture Plasma devient plus viable pour des scénarios d'utilisation plus larges que jamais.
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
Quel problème essayons-nous de résoudre ?
Le 13 mars 2024, lorsque la mise à niveau Dencun sera en ligne, la blockchain Ethereum aura 3 blobs d'environ 125 kB par slot 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 est d'environ 180 octets, donc le TPS maximum pour les Rollups sur Ethereum est : 375000 / 12 / 180 = 173.6 TPS
Si nous ajoutons la valeur maximale théorique de calldata d'Ethereum ( : par slot 30 millions de Gas / par octet 16 gas = par slot 1 875 000 octets ), cela devient 607 TPS. Avec PeerDAS, le nombre de blobs pourrait passer à 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 d'évolutivité. 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 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, où chaque part contient 16 valeurs d'évaluation sur 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 valeurs d'évaluation, n'importe quel 4096 ) peut être restauré en fonction des paramètres proposés actuellement : 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 à des pairs dans le réseau p2p mondial ) qui écouteront différents sous-réseaux ( de lui fournir 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 à la couche de pair. 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 l'échelle d'un "échantillonnage 1D" assez largement : si nous augmentons le nombre maximum de blobs à 256) avec un objectif de 128(, alors nous pouvons atteindre un objectif de 16 Mo, et dans l'échantillonnage de disponibilité des données, chaque nœud a 16 échantillons * 128 blobs * 512 octets par échantillon et par blob = 1 Mo de bande passante de données par créneau. Cela est juste à la limite de notre tolérance : c'est réalisable, 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 et effectuer un 2D sampling), cette méthode effectue des échantillonnages aléatoires non seulement à l'intérieur du blob, mais aussi entre les blobs. En utilisant les propriétés linéaires de l'engagement KZG, un ensemble de nouveaux blobs virtuels est utilisé pour étendre l'ensemble de blobs dans un bloc, ces blobs virtuels codent redondamment les mêmes informations.
Ainsi, finalement, nous souhaitons aller plus loin en effectuant un échantillonnage 2D, qui ne se fait pas seulement à l'intérieur du blob, mais aussi 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 en redondance avec les mêmes informations.
Il est essentiel que l'expansion des engagements 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 effectivement les blocs n'ont besoin que de l'engagement KZG du blob, et ils peuvent s'appuyer sur l'échantillonnage de disponibilité des données (DAS) pour vérifier la disponibilité des blocs de données. L'échantillonnage de disponibilité des données unidimensionnel (1D DAS) est également fondamentalement amical pour la construction de blocs distribués.
( Que faut-il encore faire ? Quels sont les compromis ?
La prochaine étape consiste à finaliser l'implémentation et le lancement de PeerDAS. Ensuite, le nombre de blobs sur PeerDAS sera progressivement augmenté, 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 davantage de travaux académiques pour réglementer PeerDAS et d'autres versions de DAS ainsi que leurs interactions avec des questions telles que la sécurité des règles de sélection de fork.
À des étapes futures encore plus éloignées, nous devrons faire davantage de travail pour déterminer la version idéale de 2D DAS et prouver ses attributs de sécurité. Nous espérons également finalement pouvoir passer de KZG à une alternative qui soit à la fois sécurisée contre les quantiques et sans configuration de confiance. Pour l’instant, il n’est pas encore clair quels candidats sont amicaux pour la construction de blocs distribués. Même avec l’utilisation de techniques coûteuses de "brute force", c’est-à-dire en utilisant STARK récursifs pour générer des preuves de validité pour reconstruire les lignes et les colonnes, cela ne répond pas aux besoins, car bien que techniquement, la taille d’un STARK soit O)log(n) * log###log(n() hash ( utilisant STIR(, en réalité, 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;
Insister sur l'utilisation de 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 pleinement 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 exactitude. 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 ami des reconstructions distribuées, cela nécessite en pratique une combinaison avec les propositions de listes d'inclusion de paquets et les mécanismes de sélection de forks qui les entourent.
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.webp(
Compression de 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 de Layer. Chaque slot fait 16 Mo, nous obtenons :
16000000 / 12 / 180 = 7407 TPS
Que se passerait-il si nous pouvions non seulement résoudre le problème des numérateurs, mais aussi celui des dénominateurs, permettant à chaque transaction dans les Rollups 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 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, cette signature peut prouver toutes les originales.
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.
6 J'aime
Récompense
6
4
Partager
Commentaire
0/400
FloorSweeper
· Il y a 20h
Ne demande pas pourquoi, L2 c'est génial.
Voir l'originalRépondre0
RamenDeFiSurvivor
· Il y a 20h
Vala L2 est vraiment bon
Voir l'originalRépondre0
ShadowStaker
· Il y a 20h
hum, l'efficacité de mev sur les l2 doit encore être améliorée, à vrai dire... la topologie du réseau n'est pas encore tout à fait au point.
Voir l'originalRépondre0
BearMarketBuyer
· Il y a 20h
On est en train de jouer avec la couche 2 ou pas ? On va juste jeter un œil.
Ethereum scalabilité nouvelle phase : Analyse approfondie de la feuille de route The Surge
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 Layer2. Le sharding permet à chaque nœud de ne vérifier et de stocker qu'une partie des transactions, tandis que Layer2 construit des réseaux au-dessus d'Ethereum, tirant parti de sa sécurité tout en conservant la plupart des données et des calculs en dehors de la chaîne principale. Ces deux méthodes ont finalement fusionné en une feuille de route centrée sur les Rollups, qui reste à ce jour la stratégie d'extension d'Ethereum.
La feuille de route centrée sur Rollup 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 prend en charge la tâche d'aider l'écosystème à se développer. Ce modèle est très courant dans la société : le système judiciaire (L1) existe pour protéger les contrats et la propriété, tandis que les entrepreneurs (L2) construisent sur cette base, faisant avancer le développement humain.
Cette année, la feuille de route centrée sur Rollup a fait des progrès significatifs : le lancement des blobs EIP-4844 a considérablement augmenté la bande passante des données d'Ethereum L1, 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, la diversité des méthodes de mise en œuvre des fragments est désormais une réalité. Mais ce chemin fait également face à certains défis uniques. Notre tâche actuelle est de finaliser la feuille de route centrée sur Rollup, de résoudre ces problèmes tout en maintenant la robustesse et la décentralisation d'Ethereum L1.
The Surge : Objectifs clés
Paradoxe de la triangle de la scalabilité
Le paradoxe du triangle de la scalabilité soutient qu'il existe une contradiction entre les trois caractéristiques de la blockchain : décentralisation (, coût faible des nœuds fonctionnant ), scalabilité ( pour traiter un grand nombre de transactions ) et sécurité (, où un attaquant doit compromettre une grande partie des nœuds du réseau pour faire échouer une transaction unique ).
Le paradoxe triangulaire n'est pas un théorème, et les posts qui l'introduisent ne sont pas accompagnés de preuves mathématiques. Il présente un argument mathématique heuristique : si un nœud décentralisé amical 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 des nœuds, ce qui signifie qu'un attaquant n'a besoin de compromettre qu'un petit nombre de nœuds pour faire passer une transaction malveillante, ou (ii) votre nœud deviendra puissant, tandis que votre chaîne ne sera pas décentralisée. Cet article vise à montrer qu'il est difficile de briser le paradoxe ternaire, nécessitant dans une certaine mesure de sortir du cadre de pensée implicite de cet argument.
Depuis de nombreuses années, certaines chaînes haute performance prétendent résoudre le trilemme sans changer fondamentalement l'architecture, généralement en optimisant 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.
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, 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 a un modèle de confiance subtil few-of-N, mais il conserve les caractéristiques fondamentales des chaînes non extensibles, à savoir qu'une attaque à 51 % ne peut pas forcer des blocs défectueux à être acceptés par le réseau.
Une autre méthode pour résoudre le trilemme est l'architecture Plasma, qui utilise 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 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 généralisation des SNARKs, l'architecture Plasma devient plus viable pour des scénarios d'utilisation plus larges que jamais.
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
Quel problème essayons-nous de résoudre ?
Le 13 mars 2024, lorsque la mise à niveau Dencun sera en ligne, la blockchain Ethereum aura 3 blobs d'environ 125 kB par slot 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 est d'environ 180 octets, donc le TPS maximum pour les Rollups sur Ethereum est : 375000 / 12 / 180 = 173.6 TPS
Si nous ajoutons la valeur maximale théorique de calldata d'Ethereum ( : par slot 30 millions de Gas / par octet 16 gas = par slot 1 875 000 octets ), cela devient 607 TPS. Avec PeerDAS, le nombre de blobs pourrait passer à 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 d'évolutivité. 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 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, où chaque part contient 16 valeurs d'évaluation sur 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 valeurs d'évaluation, n'importe quel 4096 ) peut être restauré en fonction des paramètres proposés actuellement : 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 à des pairs dans le réseau p2p mondial ) qui écouteront différents sous-réseaux ( de lui fournir 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 à la couche de pair. 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 l'échelle d'un "échantillonnage 1D" assez largement : si nous augmentons le nombre maximum de blobs à 256) avec un objectif de 128(, alors nous pouvons atteindre un objectif de 16 Mo, et dans l'échantillonnage de disponibilité des données, chaque nœud a 16 échantillons * 128 blobs * 512 octets par échantillon et par blob = 1 Mo de bande passante de données par créneau. Cela est juste à la limite de notre tolérance : c'est réalisable, 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 et effectuer un 2D sampling), cette méthode effectue des échantillonnages aléatoires non seulement à l'intérieur du blob, mais aussi entre les blobs. En utilisant les propriétés linéaires de l'engagement KZG, un ensemble de nouveaux blobs virtuels est utilisé pour étendre l'ensemble de blobs dans un bloc, ces blobs virtuels codent redondamment les mêmes informations.
Ainsi, finalement, nous souhaitons aller plus loin en effectuant un échantillonnage 2D, qui ne se fait pas seulement à l'intérieur du blob, mais aussi 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 en redondance avec les mêmes informations.
Il est essentiel que l'expansion des engagements 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 effectivement les blocs n'ont besoin que de l'engagement KZG du blob, et ils peuvent s'appuyer sur l'échantillonnage de disponibilité des données (DAS) pour vérifier la disponibilité des blocs de données. L'échantillonnage de disponibilité des données unidimensionnel (1D DAS) est également fondamentalement amical pour la construction de blocs distribués.
( Que faut-il encore faire ? Quels sont les compromis ?
La prochaine étape consiste à finaliser l'implémentation et le lancement de PeerDAS. Ensuite, le nombre de blobs sur PeerDAS sera progressivement augmenté, 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 davantage de travaux académiques pour réglementer PeerDAS et d'autres versions de DAS ainsi que leurs interactions avec des questions telles que la sécurité des règles de sélection de fork.
À des étapes futures encore plus éloignées, nous devrons faire davantage de travail pour déterminer la version idéale de 2D DAS et prouver ses attributs de sécurité. Nous espérons également finalement pouvoir passer de KZG à une alternative qui soit à la fois sécurisée contre les quantiques et sans configuration de confiance. Pour l’instant, il n’est pas encore clair quels candidats sont amicaux pour la construction de blocs distribués. Même avec l’utilisation de techniques coûteuses de "brute force", c’est-à-dire en utilisant STARK récursifs pour générer des preuves de validité pour reconstruire les lignes et les colonnes, cela ne répond pas aux besoins, car bien que techniquement, la taille d’un STARK soit O)log(n) * log###log(n() hash ( utilisant STIR(, en réalité, 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 exactitude. 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 ami des reconstructions distribuées, cela nécessite en pratique une combinaison avec les propositions de listes d'inclusion de paquets et les mécanismes de sélection de forks qui les entourent.
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-c585e5f955b6646c513eaecf452b0597.webp(
Compression de 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 de Layer. Chaque slot fait 16 Mo, nous obtenons :
16000000 / 12 / 180 = 7407 TPS
Que se passerait-il si nous pouvions non seulement résoudre le problème des numérateurs, mais aussi celui des dénominateurs, permettant à chaque transaction dans les Rollups 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 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, cette signature peut prouver toutes les originales.