Dans la feuille de route d'Ethereum, il y avait initialement deux stratégies d'extension : le sharding et les protocoles Layer 2. Ces deux voies se sont finalement fusionnées pour former une feuille de route centrée sur le Rollup, qui reste à ce jour la stratégie d'extension d'Ethereum. La feuille de route centrée sur le 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 assume la tâche d'aider l'écosystème à se développer.
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é, plusieurs Rollups de la machine virtuelle Ethereum (EVM) ont atteint la première phase. Chaque L2 existe comme un "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 ce chemin fait également face à certains défis uniques. 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 préservant la robustesse et la décentralisation propres à l'Ethereum L1.
The Surge: Objectif clé
L'avenir d'Ethereum peut atteindre plus de 100 000 TPS grâce à L2;
Maintenir la décentralisation et la robustesse de L1;
Au moins certains L2 héritent entièrement des propriétés fondamentales d'Ethereum, comme la confiance, l'ouverture et la 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(
Paradoxe de la triangle de scalabilité
Le paradoxe du triangle de la scalabilité affirme qu'il existe une contradiction entre trois caractéristiques de la blockchain : la décentralisation ), plus précisément : le faible coût des nœuds opérationnels (, la scalabilité ) qui permet de traiter un grand nombre de transactions ( et la sécurité ), où un attaquant doit compromettre une grande partie des nœuds du réseau pour faire échouer une seule transaction (.
Il est à noter que le paradoxe triangulaire n'est pas un théorème, et les publications introduisant ce paradoxe ne sont pas accompagnées de preuves mathématiques. Il fournit en effet 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 effectuer une transaction malveillante, ou )ii( vos nœuds deviendront puissants, tandis que votre chaîne ne sera pas décentralisée. L'objectif de cet article n'est pas de prouver qu'il est impossible de briser le paradoxe triangulaire ; au contraire, il vise à montrer qu'il est difficile de briser le paradoxe ternaire, et cela nécessite d'une certaine manière de sortir du cadre de pensée implicite dans cet argument.
Depuis de nombreuses années, certaines chaînes haute performance prétendent résoudre le trilemme de manière fondamentale sans changer leur architecture, généralement en optimisant les nœuds grâce à des techniques d'ingénierie logicielle. Cela est toujours trompeur, car faire fonctionner des nœuds sur ces chaînes est bien plus difficile que de faire fonctionner des nœuds sur Ethereum. Cet article explorera pourquoi cela est le cas et pourquoi l'optimisation seule des logiciels clients L1 ne peut pas à elle seule étendre Ethereum.
Cependant, la combinaison de l'échantillonnage de la disponibilité des données et des SNARKs résout effectivement le paradoxe triangulaire : elle permet aux clients de vérifier qu'une certaine quantité de données est disponible et qu'un certain nombre d'étapes de calcul sont correctement exécutées, 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 la 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 évolutive, à savoir qu'une attaque à 51 % ne peut pas forcer un bloc malveillant à être accepté par le réseau.
Une autre méthode pour résoudre le dilemme des trois est l'architecture Plasma, qui utilise des techniques ingénieuses 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'élargir la capacité de calcul, Plasma était très limité en matière d'exécution sécurisée. Cependant, avec la popularité des SNARKs) et des preuves de connaissance zéro succinctes non interactives(, l'architecture Plasma devient de plus en plus viable pour des scénarios d'utilisation plus larges qu'auparavant.
![Vitalik nouveau article : l'avenir potentiel d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
) Quels problèmes 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, soit une bande passante de données d'environ 375 kB par slot. En supposant que les données des transactions soient publiées directement sur la chaîne, un transfert ERC20 représente environ 180 octets, donc le TPS maximum des Rollups 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 devient 607 TPS. En utilisant PeerDAS, le nombre de blobs pourrait augmenter à 8-16, ce qui fournirait 463-926 TPS pour le calldata.
C'est une amélioration majeure de l'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, associé aux améliorations de compression des données Rollup, pourrait apporter environ ~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 évaluations à partir de 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 évaluations, n'importe quel ensemble de 4096 (, selon les paramètres actuellement proposés : n'importe quel ensemble de 64 parmi 128 échantillons possibles ) peut restaurer le blob.
Le principe de fonctionnement de PeerDAS est de permettre à chaque client d'écouter un petit nombre de sous-réseaux, où le ième sous-réseau diffuse le ième échantillon de tout blob, et de demander à des pairs dans le réseau p2p mondial ( qui écoutera 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 requêtes supplémentaires au niveau des pairs. 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.
En théorie, nous pouvons étendre une "échantillonnage 1D" à une échelle assez grande : si nous augmentons le nombre maximum de blobs à 256( avec un objectif de 128), nous pourrions atteindre l'objectif de 16 Mo, et avec l'échantillonnage de disponibilité des données, chaque nœud aurait 16 échantillons * 128 blobs * 512 octets par blob 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 avec une 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 non seulement effectue un échantillonnage aléatoire à l'intérieur du blob, 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 avec un ensemble de nouveaux blobs virtuels, ces blobs virtuels codent de manière redondante les mêmes informations.
Ainsi, finalement, nous voulons aller plus loin et effectuer un échantillonnage 2D, qui se fait non seulement à l'intérieur des blobs, mais aussi entre les blobs de manière aléatoire. Les propriétés linéaires de l'engagement KZG sont utilisées pour étendre un ensemble de blobs dans un bloc, qui contient une nouvelle liste de blobs virtuels avec un codage redondant des mêmes informations.
Il est crucial de noter que l'expansion des engagements de calcul ne nécessite pas de blob, rendant cette solution fondamentalement amicale pour la construction de blocs distribués. Les nœuds qui construisent réellement les blocs n'ont besoin que de posséder l'engagement 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 ? Quelles sont les concessions ?
Ensuite, il s'agit de finaliser la mise en œuvre et le lancement de PeerDAS. Par la suite, le nombre de blobs sur PeerDAS augmentera progressivement, tout en observant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité, ce qui est un processus progressif. En même temps, nous espérons qu'il y aura davantage de travaux académiques pour réglementer PeerDAS et d'autres versions de DAS ainsi que leurs interactions avec des questions de sécurité telles que les règles de sélection de forks.
À des étapes futures plus lointaines, nous devrons faire davantage 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 quantiquement sécurisée et ne nécessite pas de configuration de confiance. Actuellement, nous ne savons pas encore quelles sont les solutions candidates favorables à la construction de blocs distribués. Même en utilisant la technique coûteuse de "force brute", c'est-à-dire en utilisant des STARK récursifs pour générer des preuves de validité pour reconstruire les lignes et les colonnes, cela ne suffit pas à répondre aux besoins, car bien que techniquement, la taille d'un STARK soit O)log(n) * log###log(n() la valeur de hachage( 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 du DAS 1D, sacrifier l'efficacité de la bande passante d'échantillonnage, accepter une limite de données inférieure pour la simplicité et la robustesse.
Abandonner DA et accepter pleinement Plasma comme notre principal cadre Layer 2 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 gérer un grand nombre de TPS, les blocs L1 deviendront très volumineux, et les clients souhaiteront avoir un moyen efficace de vérifier leur validité, c'est pourquoi nous devrons utiliser au niveau L1 les mêmes technologies que Rollup) comme ZK-EVM et DAS).
( Comment interagir avec les autres parties de la feuille de route ?
Si la compression des données est réalisée, la demande pour le DAS 2D sera réduite, ou du moins retardée ; si le Plasma est largement utilisé, la demande diminuera encore davantage. Le DAS pose également des défis pour les protocoles et mécanismes de construction de blocs distribués : bien que le DAS soit théoriquement amical envers la reconstruction distribuée, cela nécessite en pratique une combinaison avec la proposition de liste d'inclusion de paquets et les mécanismes de sélection de forks qui l'entourent.
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
Compression des données
) Quel problème résolvons-nous ?
Chaque transaction dans un Rollup occupera une grande quantité d'espace de données sur la chaîne : le 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 de numérateur, mais aussi ceux de dénominateur, permettant ainsi à chaque transaction dans un Rollup d'occuper moins de bytes sur la chaîne?
Qu'est-ce que c'est et comment ça fonctionne?
À mon avis, la meilleure explication est cette image d'il y a deux ans :
Compression à zéros, remplaçant chaque longue séquence de zéros par deux octets, indiquant combien de zéros sont présents. 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 pouvant prouver la validité de toutes les signatures originales. Au niveau L1, en raison des coûts de calcul élevés de vérification même avec l'agrégation, l'utilisation de signatures BLS n'est pas envisagée. Cependant, dans un environnement L2 où les données sont rares, l'utilisation de signatures BLS a du sens. La fonctionnalité d'agrégation d'ERC-4337 fournit un moyen d'implémenter cette fonctionnalité.
Remplacer l'adresse par des pointeurs : Si une adresse a déjà été utilisée, nous pouvons remplacer l'adresse de 20 octets par un pointeur de 4 octets pointant vers un emplacement dans l'historique.
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.
19 J'aime
Récompense
19
9
Partager
Commentaire
0/400
HashBard
· 07-19 15:02
ser... les rollups sont comme de la poésie en mouvement fr fr. haussier sur cette élán narrative ngl
Voir l'originalRépondre0
FUDwatcher
· 07-19 07:32
Enfin, on peut avoir du gas pas cher !
Voir l'originalRépondre0
MemeCurator
· 07-17 19:11
Cette vague de l2 va de nouveau To the moon.
Voir l'originalRépondre0
ImpermanentPhobia
· 07-17 03:56
v确实猛 L2To the moon了属于是
Voir l'originalRépondre0
DAOdreamer
· 07-17 03:56
Rollup est là, et tu n'es toujours pas à la hauteur ?
Voir l'originalRépondre0
GateUser-5854de8b
· 07-17 03:54
Ce v frère a encore sorti quelque chose de nouveau.
Ethereum La montée : une nouvelle stratégie d'extension centrée sur les Rollups
L'avenir possible d'Ethereum : The Surge
Dans la feuille de route d'Ethereum, il y avait initialement deux stratégies d'extension : le sharding et les protocoles Layer 2. Ces deux voies se sont finalement fusionnées pour former une feuille de route centrée sur le Rollup, qui reste à ce jour la stratégie d'extension d'Ethereum. La feuille de route centrée sur le 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 assume la tâche d'aider l'écosystème à se développer.
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é, plusieurs Rollups de la machine virtuelle Ethereum (EVM) ont atteint la première phase. Chaque L2 existe comme un "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 ce chemin fait également face à certains défis uniques. 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 préservant la robustesse et la décentralisation propres à l'Ethereum L1.
The Surge: Objectif clé
L'avenir d'Ethereum peut atteindre plus de 100 000 TPS grâce à L2;
Maintenir la décentralisation et la robustesse de L1;
Au moins certains L2 héritent entièrement des propriétés fondamentales d'Ethereum, comme la confiance, l'ouverture et la 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(
Paradoxe de la triangle de scalabilité
Le paradoxe du triangle de la scalabilité affirme qu'il existe une contradiction entre trois caractéristiques de la blockchain : la décentralisation ), plus précisément : le faible coût des nœuds opérationnels (, la scalabilité ) qui permet de traiter un grand nombre de transactions ( et la sécurité ), où un attaquant doit compromettre une grande partie des nœuds du réseau pour faire échouer une seule transaction (.
Il est à noter que le paradoxe triangulaire n'est pas un théorème, et les publications introduisant ce paradoxe ne sont pas accompagnées de preuves mathématiques. Il fournit en effet 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 effectuer une transaction malveillante, ou )ii( vos nœuds deviendront puissants, tandis que votre chaîne ne sera pas décentralisée. L'objectif de cet article n'est pas de prouver qu'il est impossible de briser le paradoxe triangulaire ; au contraire, il vise à montrer qu'il est difficile de briser le paradoxe ternaire, et cela nécessite d'une certaine manière de sortir du cadre de pensée implicite dans cet argument.
Depuis de nombreuses années, certaines chaînes haute performance prétendent résoudre le trilemme de manière fondamentale sans changer leur architecture, généralement en optimisant les nœuds grâce à des techniques d'ingénierie logicielle. Cela est toujours trompeur, car faire fonctionner des nœuds sur ces chaînes est bien plus difficile que de faire fonctionner des nœuds sur Ethereum. Cet article explorera pourquoi cela est le cas et pourquoi l'optimisation seule des logiciels clients L1 ne peut pas à elle seule étendre Ethereum.
Cependant, la combinaison de l'échantillonnage de la disponibilité des données et des SNARKs résout effectivement le paradoxe triangulaire : elle permet aux clients de vérifier qu'une certaine quantité de données est disponible et qu'un certain nombre d'étapes de calcul sont correctement exécutées, 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 la 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 évolutive, à savoir qu'une attaque à 51 % ne peut pas forcer un bloc malveillant à être accepté par le réseau.
Une autre méthode pour résoudre le dilemme des trois est l'architecture Plasma, qui utilise des techniques ingénieuses 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'élargir la capacité de calcul, Plasma était très limité en matière d'exécution sécurisée. Cependant, avec la popularité des SNARKs) et des preuves de connaissance zéro succinctes non interactives(, l'architecture Plasma devient de plus en plus viable pour des scénarios d'utilisation plus larges qu'auparavant.
![Vitalik nouveau article : l'avenir potentiel d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
) Quels problèmes 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, soit une bande passante de données d'environ 375 kB par slot. En supposant que les données des transactions soient publiées directement sur la chaîne, un transfert ERC20 représente environ 180 octets, donc le TPS maximum des Rollups 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 devient 607 TPS. En utilisant PeerDAS, le nombre de blobs pourrait augmenter à 8-16, ce qui fournirait 463-926 TPS pour le calldata.
C'est une amélioration majeure de l'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, associé aux améliorations de compression des données Rollup, pourrait apporter environ ~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 évaluations à partir de 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 évaluations, n'importe quel ensemble de 4096 (, selon les paramètres actuellement proposés : n'importe quel ensemble de 64 parmi 128 échantillons possibles ) peut restaurer le blob.
Le principe de fonctionnement de PeerDAS est de permettre à chaque client d'écouter un petit nombre de sous-réseaux, où le ième sous-réseau diffuse le ième échantillon de tout blob, et de demander à des pairs dans le réseau p2p mondial ( qui écoutera 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 requêtes supplémentaires au niveau des pairs. 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.
En théorie, nous pouvons étendre une "échantillonnage 1D" à une échelle assez grande : si nous augmentons le nombre maximum de blobs à 256( avec un objectif de 128), nous pourrions atteindre l'objectif de 16 Mo, et avec l'échantillonnage de disponibilité des données, chaque nœud aurait 16 échantillons * 128 blobs * 512 octets par blob 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 avec une 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 non seulement effectue un échantillonnage aléatoire à l'intérieur du blob, 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 avec un ensemble de nouveaux blobs virtuels, ces blobs virtuels codent de manière redondante les mêmes informations.
Ainsi, finalement, nous voulons aller plus loin et effectuer un échantillonnage 2D, qui se fait non seulement à l'intérieur des blobs, mais aussi entre les blobs de manière aléatoire. Les propriétés linéaires de l'engagement KZG sont utilisées pour étendre un ensemble de blobs dans un bloc, qui contient une nouvelle liste de blobs virtuels avec un codage redondant des mêmes informations.
Il est crucial de noter que l'expansion des engagements de calcul ne nécessite pas de blob, rendant cette solution fondamentalement amicale pour la construction de blocs distribués. Les nœuds qui construisent réellement les blocs n'ont besoin que de posséder l'engagement 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 ? Quelles sont les concessions ?
Ensuite, il s'agit de finaliser la mise en œuvre et le lancement de PeerDAS. Par la suite, le nombre de blobs sur PeerDAS augmentera progressivement, tout en observant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité, ce qui est un processus progressif. En même temps, nous espérons qu'il y aura davantage de travaux académiques pour réglementer PeerDAS et d'autres versions de DAS ainsi que leurs interactions avec des questions de sécurité telles que les règles de sélection de forks.
À des étapes futures plus lointaines, nous devrons faire davantage 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 quantiquement sécurisée et ne nécessite pas de configuration de confiance. Actuellement, nous ne savons pas encore quelles sont les solutions candidates favorables à la construction de blocs distribués. Même en utilisant la technique coûteuse de "force brute", c'est-à-dire en utilisant des STARK récursifs pour générer des preuves de validité pour reconstruire les lignes et les colonnes, cela ne suffit pas à répondre aux besoins, car bien que techniquement, la taille d'un STARK soit O)log(n) * log###log(n() la valeur de hachage( 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 gérer un grand nombre de TPS, les blocs L1 deviendront très volumineux, et les clients souhaiteront avoir un moyen efficace de vérifier leur validité, c'est pourquoi nous devrons utiliser au niveau L1 les mêmes technologies que Rollup) comme ZK-EVM et DAS).
( Comment interagir avec les autres parties de la feuille de route ?
Si la compression des données est réalisée, la demande pour le DAS 2D sera réduite, ou du moins retardée ; si le Plasma est largement utilisé, la demande diminuera encore davantage. Le DAS pose également des défis pour les protocoles et mécanismes de construction de blocs distribués : bien que le DAS soit théoriquement amical envers la reconstruction distribuée, cela nécessite en pratique une combinaison avec la proposition de liste d'inclusion de paquets et les mécanismes de sélection de forks qui l'entourent.
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
Compression des données
) Quel problème résolvons-nous ?
Chaque transaction dans un Rollup occupera une grande quantité d'espace de données sur la chaîne : le 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 de numérateur, mais aussi ceux de dénominateur, permettant ainsi à chaque transaction dans un Rollup d'occuper moins de bytes sur la chaîne?
Qu'est-ce que c'est et comment ça fonctionne?
À mon avis, la meilleure explication est cette image d'il y a deux ans :
Compression à zéros, remplaçant chaque longue séquence de zéros par deux octets, indiquant combien de zéros sont présents. 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 pouvant prouver la validité de toutes les signatures originales. Au niveau L1, en raison des coûts de calcul élevés de vérification même avec l'agrégation, l'utilisation de signatures BLS n'est pas envisagée. Cependant, dans un environnement L2 où les données sont rares, l'utilisation de signatures BLS a du sens. La fonctionnalité d'agrégation d'ERC-4337 fournit un moyen d'implémenter cette fonctionnalité.
Remplacer l'adresse par des pointeurs : Si une adresse a déjà été utilisée, nous pouvons remplacer l'adresse de 20 octets par un pointeur de 4 octets pointant vers un emplacement dans l'historique.
Séquence personnalisée de valeur de transaction