Au départ, la feuille de route d'Ethereum prévoyait deux stratégies d'extensibilité : le sharding et les protocoles Layer 2. Ces deux stratégies ont finalement été combinées pour former une feuille de route centrée sur les Rollups, qui demeure à ce jour la stratégie d'extension d'Ethereum.
La feuille de route centrée sur Rollup propose une division simple des tâches : Ethereum L1 se concentre sur le fait d'être une couche de base puissante et décentralisée, tandis que L2 assume la tâche d'aider à l'expansion de l'écosystème. Ce modèle est omniprésent dans la société : l'existence du système judiciaire (L1) est destinée à protéger les contrats et les droits de propriété, tandis que les entrepreneurs (L2) construisent sur cette base, faisant avancer l'humanité.
Cette année, la feuille de route centrée sur Rollup 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 EVM ont atteint la première phase. Chaque L2 existe en tant que "fragment" avec ses propres règles et logiques, et la diversité et la pluralité des méthodes de mise en œuvre des fragments sont désormais une réalité. Cependant, emprunter 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 Rollup, de résoudre ces problèmes tout en maintenant la robustesse et la décentralisation de l'Ethereum L1.
The Surge : Objectif clé
L'Ethereum pourra atteindre plus de 100 000 TPS grâce à L2 dans le futur;
Maintenir la décentralisation et la robustesse de L1;
Au moins certains L2 héritent complètement des propriétés fondamentales d'Ethereum, telles que 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.
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
![Vitalik nouveau document : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
Paradoxe du triangle de la scalabilité
Le paradoxe du triangle de la scalabilité postule qu'il existe une contradiction entre trois caractéristiques de la blockchain : la décentralisation ), le faible coût d'exploitation des nœuds (, 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 transaction unique (.
Il convient de noter que le paradoxe du triangle n'est pas un théorème, et les messages présentant le paradoxe du triangle ne sont pas accompagnés de preuves mathématiques. Il fournit un argument mathématique heuristique : si un nœud amical décentralisé peut valider 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 qu'à compromettre quelques nœuds pour réaliser 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 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 de nombreuses années, certaines chaînes haute performance prétendent avoir résolu le trilemme de la blockchain sans modifier fondamentalement 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 beaucoup plus difficile que sur Ethereum. Cet article explorera pourquoi c'est le cas et pourquoi l'ingénierie logicielle des clients L1 ne peut pas à elle seule étendre Ethereum.
Cependant, la combinaison de l'échantillonnage de la disponibilité des données avec les 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 présente un modèle de confiance subtil few-of-N, mais il conserve les caractéristiques fondamentales d'une chaîne non évolutive, c'est-à-dire qu'une attaque à 51 % ne peut pas forcer des blocs mauvais à être acceptés par le réseau.
Une autre méthode pour résoudre le trilemme est l'architecture Plasma, qui utilise une technologie ingénieuse 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 avions seulement 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, l'architecture Plasma est devenue plus viable pour un éventail d'applications plus large que jamais.
![Vitalik nouvel article : l'avenir possible d'Ethereum, 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
) Quels problèmes résolvons-nous ?
Le 13 mars 2024, lors du lancement 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 d'environ 375 kB par slot. Supposons que les données de transaction soient publiées directement sur la chaîne, un transfert ERC20 faisant environ 180 octets, donc le maximum de TPS pour le Rollup sur Ethereum est : 375000 / 12 / 180 = 173.6 TPS.
Si nous ajoutons la valeur maximale théorique du calldata d'Ethereum ### : 30 millions de Gas par slot / 16 gas par octet = 1 875 000 octets par slot (, 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, combiné aux améliorations de compression des données Rollup, pourrait 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 un corps de nombres premiers de 253 bits. Nous diffusons les parts du polynôme, chaque part contenant 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 4096 de ### selon les paramètres proposés actuellement : n'importe quel 64 de 128 échantillons possibles de ( peuvent 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 à des pairs dans le réseau p2p mondial ) qui écoutera différents sous-réseaux ( pour demander les blobs nécessaires sur d'autres sous-réseaux. Une version plus conservatrice, SubnetDAS, utilise uniquement le mécanisme des sous-réseaux, sans interroger la couche de pairs supplémentaire. 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 l'échelle d'un "échantillonnage 1D" à une taille assez grande : si nous augmentons le nombre maximal de blobs à 256) avec un objectif de 128(, alors nous pourrions atteindre un objectif de 16 Mo, et avec l'échantillonnage de disponibilité des données, chaque nœud aurait 16 échantillons * 128 blobs * 512 octets par échantillon et par blob = 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 souhaitons finalement aller plus loin en effectuant un échantillonnage 2D, une méthode qui effectue non seulement un échantillonnage aléatoire à l'intérieur du blob, mais aussi entre les blobs. En utilisant la propriété linéaire des engagements KZG, nous pouvons étendre l'ensemble de blobs dans un bloc par un ensemble de nouveaux blobs virtuels, ces blobs virtuels codant de manière redondante les mêmes informations.
Il est crucial que l'expansion des engagements de calcul ne nécessite pas de blob, donc cette solution est fondamentalement amicale pour la construction de blocs distribués. Les nœuds qui construisent réellement les blocs n'ont besoin que d'un engagement KZG de blob, et ils peuvent se fier à l'échantillonnage de la disponibilité des données pour vérifier la disponibilité des blocs de données. L'échantillonnage de la disponibilité des données unidimensionnelles est également fondamentalement amical pour la construction de blocs distribués.
![Vitalik nouvel article : L'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
) Que doit-on encore faire ? Quelles sont les compromis ?
La prochaine étape est de finaliser la mise en œuvre 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 graduel. 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 leurs interactions avec des questions de sécurité telles que les règles de choix de fork.
À des étapes futures plus lointaines, nous devrons faire plus de travail pour déterminer la version idéale du 2D DAS et prouver ses propriétés de sécurité. Nous espérons également finalement pouvoir passer du KZG à une alternative qui soit sécurisée contre les menaces quantiques et ne nécessite pas d'installation 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 "brute force" coûteuses, c'est-à-dire en utilisant le STARK récursif pour générer des preuves de validité pour reconstruire 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(), le hachage ) utilisant STIR(, en réalité, le 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, sacrifiant l'efficacité de la bande passante d'échantillonnage, pour la simplicité et la robustesse en acceptant une limite de données inférieure.
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 sur la couche L1, cette option existe. En effet, si la couche L1 doit traiter un grand nombre de TPS, les blocs L1 deviendront très volumineux, et le client souhaitera avoir un moyen efficace de vérifier leur validité. Par conséquent, nous devrons utiliser sur la couche L1 les mêmes technologies que celles utilisées avec 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. 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 de s'associer avec la proposition de liste d'inclusion de paquets et les mécanismes de sélection de forks qui l'entourent.
![Vitalik nouvel article : avenir possible d'Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
Compression des données
) Quel problème résolvons-nous ?
Chaque transaction dans un Rollup consomme une grande quantité d'espace de données sur la chaîne : un transfert ERC20 nécessite environ 180 octets. Même avec un échantillonnage de disponibilité des données idéal, cela limite l'évolutivité des protocoles de couche. Chaque slot de 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 résoudre le problème 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 et comment ça fonctionne?
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 pouvant prouver la validité de toutes les signatures originales. Dans la couche L1, en raison du coût de calcul élevé de la vérification même avec l'agrégation, l'utilisation de la signature BLS n'est donc pas envisagée. Mais dans un environnement L2 où les données sont rares, l'utilisation de la signature BLS a du sens. La fonctionnalité d'agrégation de l'ERC-4337 offre un moyen d'implémenter cette fonctionnalité.
Remplacer les adresses par des pointeurs : si une adresse a déjà été utilisée auparavant, nous pouvons remplacer l'adresse de 20 octets par un pointeur de 4 octets pointant vers un certain emplacement dans l'historique.
Sérialisation personnalisée des valeurs de transaction------La plupart des valeurs de transaction ont peu de chiffres, par exemple, 0,25 Éther est représenté par 250
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
4
Partager
Commentaire
0/400
BrokeBeans
· 07-22 21:16
Tu es toujours en train de faire de l'augmentation de données ? C'est déjà trop joué.
Voir l'originalRépondre0
BearMarketSurvivor
· 07-22 21:15
La ligne de ravitaillement à l'arrière est très stable, la puissance d'Ethereum continue de se renforcer.
La route de l'extension d'Ethereum : Analyse de la stratégie d'extension de The Surge et des objectifs futurs
The Surge : l'avenir de l'évolutivité d'Ethereum
Au départ, la feuille de route d'Ethereum prévoyait deux stratégies d'extensibilité : le sharding et les protocoles Layer 2. Ces deux stratégies ont finalement été combinées pour former une feuille de route centrée sur les Rollups, qui demeure à ce jour la stratégie d'extension d'Ethereum.
La feuille de route centrée sur Rollup propose une division simple des tâches : Ethereum L1 se concentre sur le fait d'être une couche de base puissante et décentralisée, tandis que L2 assume la tâche d'aider à l'expansion de l'écosystème. Ce modèle est omniprésent dans la société : l'existence du système judiciaire (L1) est destinée à protéger les contrats et les droits de propriété, tandis que les entrepreneurs (L2) construisent sur cette base, faisant avancer l'humanité.
Cette année, la feuille de route centrée sur Rollup 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 EVM ont atteint la première phase. Chaque L2 existe en tant que "fragment" avec ses propres règles et logiques, et la diversité et la pluralité des méthodes de mise en œuvre des fragments sont désormais une réalité. Cependant, emprunter 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 Rollup, de résoudre ces problèmes tout en maintenant la robustesse et la décentralisation de l'Ethereum L1.
The Surge : Objectif clé
Contenu de ce chapitre
![Vitalik nouveau document : l'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-0a07a34094cbf643fdead78b4dd682c6.webp(
Paradoxe du triangle de la scalabilité
Le paradoxe du triangle de la scalabilité postule qu'il existe une contradiction entre trois caractéristiques de la blockchain : la décentralisation ), le faible coût d'exploitation des nœuds (, 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 transaction unique (.
Il convient de noter que le paradoxe du triangle n'est pas un théorème, et les messages présentant le paradoxe du triangle ne sont pas accompagnés de preuves mathématiques. Il fournit un argument mathématique heuristique : si un nœud amical décentralisé peut valider 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 qu'à compromettre quelques nœuds pour réaliser 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 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 de nombreuses années, certaines chaînes haute performance prétendent avoir résolu le trilemme de la blockchain sans modifier fondamentalement 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 beaucoup plus difficile que sur Ethereum. Cet article explorera pourquoi c'est le cas et pourquoi l'ingénierie logicielle des clients L1 ne peut pas à elle seule étendre Ethereum.
Cependant, la combinaison de l'échantillonnage de la disponibilité des données avec les 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 présente un modèle de confiance subtil few-of-N, mais il conserve les caractéristiques fondamentales d'une chaîne non évolutive, c'est-à-dire qu'une attaque à 51 % ne peut pas forcer des blocs mauvais à être acceptés par le réseau.
Une autre méthode pour résoudre le trilemme est l'architecture Plasma, qui utilise une technologie ingénieuse 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 avions seulement 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, l'architecture Plasma est devenue plus viable pour un éventail d'applications plus large que jamais.
![Vitalik nouvel article : l'avenir possible d'Ethereum, 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
) Quels problèmes résolvons-nous ?
Le 13 mars 2024, lors du lancement 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 d'environ 375 kB par slot. Supposons que les données de transaction soient publiées directement sur la chaîne, un transfert ERC20 faisant environ 180 octets, donc le maximum de TPS pour le Rollup sur Ethereum est : 375000 / 12 / 180 = 173.6 TPS.
Si nous ajoutons la valeur maximale théorique du calldata d'Ethereum ### : 30 millions de Gas par slot / 16 gas par octet = 1 875 000 octets par slot (, 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, combiné aux améliorations de compression des données Rollup, pourrait 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 un corps de nombres premiers de 253 bits. Nous diffusons les parts du polynôme, chaque part contenant 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 4096 de ### selon les paramètres proposés actuellement : n'importe quel 64 de 128 échantillons possibles de ( peuvent 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 à des pairs dans le réseau p2p mondial ) qui écoutera différents sous-réseaux ( pour demander les blobs nécessaires sur d'autres sous-réseaux. Une version plus conservatrice, SubnetDAS, utilise uniquement le mécanisme des sous-réseaux, sans interroger la couche de pairs supplémentaire. 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 l'échelle d'un "échantillonnage 1D" à une taille assez grande : si nous augmentons le nombre maximal de blobs à 256) avec un objectif de 128(, alors nous pourrions atteindre un objectif de 16 Mo, et avec l'échantillonnage de disponibilité des données, chaque nœud aurait 16 échantillons * 128 blobs * 512 octets par échantillon et par blob = 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 souhaitons finalement aller plus loin en effectuant un échantillonnage 2D, une méthode qui effectue non seulement un échantillonnage aléatoire à l'intérieur du blob, mais aussi entre les blobs. En utilisant la propriété linéaire des engagements KZG, nous pouvons étendre l'ensemble de blobs dans un bloc par un ensemble de nouveaux blobs virtuels, ces blobs virtuels codant de manière redondante les mêmes informations.
Il est crucial que l'expansion des engagements de calcul ne nécessite pas de blob, donc cette solution est fondamentalement amicale pour la construction de blocs distribués. Les nœuds qui construisent réellement les blocs n'ont besoin que d'un engagement KZG de blob, et ils peuvent se fier à l'échantillonnage de la disponibilité des données pour vérifier la disponibilité des blocs de données. L'échantillonnage de la disponibilité des données unidimensionnelles est également fondamentalement amical pour la construction de blocs distribués.
![Vitalik nouvel article : L'avenir possible d'Ethereum, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
) Que doit-on encore faire ? Quelles sont les compromis ?
La prochaine étape est de finaliser la mise en œuvre 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 graduel. 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 leurs interactions avec des questions de sécurité telles que les règles de choix de fork.
À des étapes futures plus lointaines, nous devrons faire plus de travail pour déterminer la version idéale du 2D DAS et prouver ses propriétés de sécurité. Nous espérons également finalement pouvoir passer du KZG à une alternative qui soit sécurisée contre les menaces quantiques et ne nécessite pas d'installation 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 "brute force" coûteuses, c'est-à-dire en utilisant le STARK récursif pour générer des preuves de validité pour reconstruire 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(), le hachage ) utilisant STIR(, en réalité, le 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 sur la couche L1, cette option existe. En effet, si la couche L1 doit traiter un grand nombre de TPS, les blocs L1 deviendront très volumineux, et le client souhaitera avoir un moyen efficace de vérifier leur validité. Par conséquent, nous devrons utiliser sur la couche L1 les mêmes technologies que celles utilisées avec 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. 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 de s'associer avec la proposition de liste d'inclusion de paquets et les mécanismes de sélection de forks qui l'entourent.
![Vitalik nouvel article : avenir possible d'Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.webp(
Compression des données
) Quel problème résolvons-nous ?
Chaque transaction dans un Rollup consomme une grande quantité d'espace de données sur la chaîne : un transfert ERC20 nécessite environ 180 octets. Même avec un échantillonnage de disponibilité des données idéal, cela limite l'évolutivité des protocoles de couche. Chaque slot de 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 résoudre le problème 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 et comment ça fonctionne?
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 pouvant prouver la validité de toutes les signatures originales. Dans la couche L1, en raison du coût de calcul élevé de la vérification même avec l'agrégation, l'utilisation de la signature BLS n'est donc pas envisagée. Mais dans un environnement L2 où les données sont rares, l'utilisation de la signature BLS a du sens. La fonctionnalité d'agrégation de l'ERC-4337 offre un moyen d'implémenter cette fonctionnalité.
Remplacer les adresses par des pointeurs : si une adresse a déjà été utilisée auparavant, nous pouvons remplacer l'adresse de 20 octets par un pointeur de 4 octets pointant vers un certain emplacement dans l'historique.
Sérialisation personnalisée des valeurs de transaction------La plupart des valeurs de transaction ont peu de chiffres, par exemple, 0,25 Éther est représenté par 250