Les stratégies d'extension d'Ethereum avaient initialement deux types : le sharding et les protocoles Layer 2. Le sharding permet à chaque nœud de ne vérifier et stocker qu'une partie des transactions, tandis que le Layer 2 construit un réseau au-dessus d'Ethereum. Ces deux stratégies se sont finalement fusionnées pour former 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 répartition simple 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 à s'étendre. Ce modèle est largement présent dans la société, comme le système judiciaire (L1) qui protège les contrats et la propriété, tandis que les entrepreneurs (L2) construisent sur cette base.
Cette année, la feuille de route centrée sur Rollup a réalisé des résultats importants : les blobs EIP-4844 ont considérablement augmenté la bande passante des données de l'Ethereum L1, 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, et la diversité et la pluralité des méthodes de mise en œuvre des fragments sont devenues une réalité. Mais cette voie fait également face à des 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 de l'Ethereum L1.
La Surge : Objectif clé
L'avenir d'Ethereum pourrait atteindre plus de 100 000 TPS grâce aux L2.
Maintenir la décentralisation et la robustesse de L1;
Au moins certains L2 héritent complètement des attributs fondamentaux d'Ethereum ( tels 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.
Résumé du contenu
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éliorations de l'interopérabilité inter-L2
Étendre l'exécution sur L1
Paradoxe de la triangle de la scalabilité
Le paradoxe du triangle de la scalabilité soutient qu'il existe des contradictions entre trois caractéristiques de la blockchain : la décentralisation (, le coût faible des nœuds de fonctionnement ), la scalabilité ( pour traiter un grand nombre de transactions ) et la sécurité (, où un attaquant doit détruire un grand nombre de nœuds pour faire échouer une transaction unique ).
Le paradoxe du triangle n'est pas un théorème, et les publications qui l'introduisent ne fournissent pas de preuve mathématique. Il donne un argument heuristique : si des nœuds amicaux décentralisés peuvent vérifier N transactions par seconde, vous avez une chaîne qui peut traiter k*N transactions par seconde, alors : (i) chaque transaction ne peut être vue que par 1/k nœuds, un attaquant n'a qu'à détruire quelques nœuds pour passer des transactions malveillantes, ou (ii) vos nœuds deviendront puissants, la chaîne ne sera pas décentralisée. L'article ne cherche pas à prouver qu'il est impossible de briser le paradoxe du triangle, mais indique que cela est difficile et nécessite de sortir du cadre de pensée implicite de cet argument.
Depuis des années, certaines chaînes hautes performances prétendent résoudre le trilemme de manière fondamentale sans changer leur architecture, généralement en optimisant les nœuds par des techniques d'ingénierie logicielle. Cela est toujours trompeur, car faire fonctionner des nœuds sur ces chaînes est plus difficile que sur Ethereum. Cet article explorera pourquoi cela est le cas et pourquoi l'ingénierie logicielle des clients L1 ne peut pas en soi faire évoluer Ethereum.
Cependant, l'échantillonnage de disponibilité des données combiné aux SNARKs résout effectivement le paradoxe du triangle : il permet aux clients de ne télécharger qu'une petite quantité de données et d'effectuer très peu de calculs pour vérifier qu'un certain nombre de données sont disponibles, et que certaines étapes de calcul ont été correctement exécutées. Les SNARKs ne nécessitent pas de confiance. L'échantillonnage de disponibilité des données a un modèle de confiance subtil de few-of-N, mais conserve les caractéristiques fondamentales d'une chaîne non extensible, même une attaque à 51 % ne peut pas forcer les blocs mauvais à être acceptés par le réseau.
Une autre méthode pour résoudre le trilemme est l'architecture Plasma, qui déplace habilement la responsabilité de la surveillance de la disponibilité des données vers les utilisateurs. De 2017 à 2019, lorsque nous n'avions que des preuves de fraude pour é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 réalisable pour des cas d'utilisation plus larges.
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, soit une bande passante de données disponible par slot d'environ 375 kB. Supposons que les données de transaction soient publiées directement sur la chaîne, un transfert ERC20 faisant environ 180 octets, alors le TPS maximal pour Rollup sur Ethereum sera : 375000 / 12 / 180 = 173.6 TPS.
Ajoutez à l'Éther calldata( la valeur maximale théorique : par slot 30 millions de Gas / par octet 16 gas = par slot 1 875 000 octets), ce qui devient 607 TPS. En utilisant PeerDAS, le nombre de blobs peut augmenter à 8-16, ce qui fournira 463-926 TPS pour le calldata.
C'est une amélioration majeure pour Ethereum L1, mais ce n'est pas suffisant. Nous voulons plus de scalabilité. L'objectif à moyen terme est de 16 Mo par slot, combiné à des améliorations de compression des données Rollup, ce qui apportera ~58000 TPS.
Qu'est-ce que c'est ? Comment ça fonctionne ?
PeerDAS est une implémentation relativement simple de "1D sampling". Dans Ethereum, chaque blob est un polynôme de degré 4096 sur un champ premier de 253 bits. Nous diffusons les parts du polynôme, chaque part contenant 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 récupéré selon les paramètres de proposition actuels : n'importe quel 64 parmi les 128 échantillons possibles ) peut récupérer le blob.
Le fonctionnement de PeerDAS consiste à faire en sorte que chaque client écoute un petit nombre de sous-réseaux, le ième sous-réseau diffuse le ième échantillon de tout blob, et en interrogeant les pairs dans le réseau p2p mondial concernant qui écoutera les différents sous-réseaux ( pour demander les blobs nécessaires sur d'autres sous-réseaux. La version plus conservatrice SubnetDAS utilise uniquement le mécanisme de sous-réseau, sans interroger la couche de pairs supplémentaire. La proposition actuelle permet 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 du "1D sampling" très largement : si nous augmentons le nombre maximum de blobs à 256) avec un objectif de 128(, nous pouvons atteindre un objectif de 16 Mo, et dans l'échantillonnage de la disponibilité des données, chaque nœud a 16 échantillons * 128 blobs * chaque blob ayant chaque échantillon de 512 octets = 1 Mo de bande passante de données par slot. Cela est juste à la limite de ce qui est tolérable : faisable, mais cela signifie qu'un client à bande passante limitée ne peut pas échantillonner. Nous pouvons optimiser en réduisant le nombre de blobs et en augmentant la taille des blobs, mais cela rendra le coût de reconstruction plus élevé.
Ainsi, nous voulons finalement aller plus loin en effectuant un échantillonnage 2D, qui échantillonne non seulement à l'intérieur des blobs, mais également entre les blobs de manière aléatoire. En utilisant les propriétés linéaires des engagements KZG, nous élargissons un ensemble de blobs dans un bloc par un nouvel ensemble de blobs virtuels, ces blobs virtuels codent de manière redondante les mêmes informations.
Il est important de noter que l'extension de l'engagement de calcul n'a pas besoin 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 blob, et ils peuvent compter sur 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 nouveau texte : Ethereum et son avenir possible, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
) Que faut-il encore faire ? Quels compromis y a-t-il ?
La prochaine étape est la mise en œuvre et le lancement de PeerDAS. Ensuite, 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é, c'est un processus progressif. En même temps, nous espérons avoir davantage de travaux académiques pour normaliser 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.
À un stade futur plus éloigné, nous aurons besoin de plus de travail pour déterminer la version idéale du DAS 2D et prouver ses attributs de sécurité. Nous espérons également pouvoir passer finalement de KZG à une alternative sécurisée contre les menaces quantiques et sans configuration de confiance. Il n'est actuellement pas clair quelles solutions candidates sont amicales pour la construction de blocs distribués. Même en utilisant une technique "brute force" 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 à satisfaire la demande, car bien que techniquement, la taille de STARK soit O###log(n( * log)log(n() hash ) utilisant STIR(, en réalité STARK est presque aussi grand que tout le 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, sacrifiant l'efficacité de la bande passante d'échantillonnage, pour accepter une limite de données inférieure pour la simplicité et la robustesse.
Abandonner DA et accepter entièrement Plasma comme notre principale architecture Layer2.
Veuillez noter que même si nous décidons d'étendre l'exécution directement au niveau L1, cette option existe. En effet, si le niveau L1 doit traiter un grand nombre de TPS, les blocs L1 deviendront très volumineux, et les clients souhaiteront avoir des méthodes efficaces pour vérifier leur validité. Par conséquent, nous devrons utiliser au niveau L1 les mêmes technologies que celles utilisées par 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 diminuera, ou du moins sera retardée. Si le 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 favorable à la reconstruction distribuée, cela nécessite en pratique d'être combiné avec la proposition de liste d'inclusion de paquets et son mécanisme de choix de forks environnant.
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.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 de Layer. Chaque slot de 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 résoudre les problèmes de 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-e0ddd016e2afb3218833324254451c1d.webp(
Dans la compression à zéro octet, chaque séquence longue de zéros est remplacée par deux octets, indiquant combien de zéros il y a. De plus, nous avons utilisé des attributs spécifiques aux transactions :
Agrégation de signatures : Nous passons des signatures ECDSA aux signatures BLS, la caractéristique des signatures BLS est que plusieurs signatures peuvent être combinées en une seule signature, cette signature peut prouver la validité de toutes les signatures originales. Au niveau L1, en raison du coût élevé de calcul de vérification même après agrégation, l'utilisation de signatures BLS n'est donc pas envisagée. Mais dans un environnement L2 où les données sont rares, l'utilisation de signatures BLS a du sens. La fonctionnalité d'agrégation ERC-4337 offre un moyen de réaliser cela.
Remplacer les adresses par des pointeurs : Si une adresse a été utilisée auparavant, nous pouvons remplacer l'adresse de 20 octets par un pointeur de 4 octets pointant vers une position 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 000 000 000 000 000 wei. Les frais de base maximum et les frais prioritaires sont similaires. Par conséquent, nous pouvons utiliser un format décimal flottant personnalisé pour représenter la plupart des valeurs monétaires.
) Que faut-il encore faire, quels sont les compromis?
Ce que nous devons faire ensuite, c'est mettre en œuvre concrètement le plan ci-dessus. Les principaux compromis incluent :
Passer à la signature BLS nécessite un grand effort et peut réduire la compatibilité avec des puces matérielles de confiance qui peuvent renforcer la sécurité. Il est possible d'utiliser des emballages ZK-SNARK d'autres schémas de signature comme alternative.
Compression dynamique ### Par exemple, remplacer les adresses ( par des pointeurs rendra le code client plus complexe.
Publier les différences d'état sur la chaîne plutôt que dans les transactions réduira l'auditabilité, rendant de nombreux logiciels ) tels que les explorateurs de blocs ( incapables de fonctionner.
) Comment interagir avec les autres parties de la feuille de route?
Adopter ERC-4337 et finalement intégrer une partie de son contenu.
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.
24 J'aime
Récompense
24
6
Partager
Commentaire
0/400
LongTermDreamer
· 07-22 01:04
Dans trois ans, tout le monde devra regarder le visage de notre L2, stocker un peu ne sera pas une perte.
Voir l'originalRépondre0
alpha_leaker
· 07-19 10:23
Dans un bull run, il faut utiliser L2 pour gagner de l'argent.
Voir l'originalRépondre0
GasDevourer
· 07-19 01:26
Je ne comprends pas L2, j'ai perdu mon slip !
Voir l'originalRépondre0
TrustlessMaximalist
· 07-19 01:21
Rollup est vraiment bon, entrer dans une position est la bonne décision.
Voir l'originalRépondre0
consensus_whisperer
· 07-19 01:11
Quand pourrons-nous atteindre 10 000 tps ? Soyez précis.
Voir l'originalRépondre0
GateUser-3824aa38
· 07-19 01:10
Finalement, c'est toujours Bitcoin qui est le plus utile.
Ethereum : Analyse de la montée en charge et perspectives de développement des L2
Ethereum possible futur : The Surge
Les stratégies d'extension d'Ethereum avaient initialement deux types : le sharding et les protocoles Layer 2. Le sharding permet à chaque nœud de ne vérifier et stocker qu'une partie des transactions, tandis que le Layer 2 construit un réseau au-dessus d'Ethereum. Ces deux stratégies se sont finalement fusionnées pour former 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 répartition simple 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 à s'étendre. Ce modèle est largement présent dans la société, comme le système judiciaire (L1) qui protège les contrats et la propriété, tandis que les entrepreneurs (L2) construisent sur cette base.
Cette année, la feuille de route centrée sur Rollup a réalisé des résultats importants : les blobs EIP-4844 ont considérablement augmenté la bande passante des données de l'Ethereum L1, 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, et la diversité et la pluralité des méthodes de mise en œuvre des fragments sont devenues une réalité. Mais cette voie fait également face à des 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 de l'Ethereum L1.
La Surge : Objectif clé
Résumé du contenu
Paradoxe de la triangle de la scalabilité
Le paradoxe du triangle de la scalabilité soutient qu'il existe des contradictions entre trois caractéristiques de la blockchain : la décentralisation (, le coût faible des nœuds de fonctionnement ), la scalabilité ( pour traiter un grand nombre de transactions ) et la sécurité (, où un attaquant doit détruire un grand nombre de nœuds pour faire échouer une transaction unique ).
Le paradoxe du triangle n'est pas un théorème, et les publications qui l'introduisent ne fournissent pas de preuve mathématique. Il donne un argument heuristique : si des nœuds amicaux décentralisés peuvent vérifier N transactions par seconde, vous avez une chaîne qui peut traiter k*N transactions par seconde, alors : (i) chaque transaction ne peut être vue que par 1/k nœuds, un attaquant n'a qu'à détruire quelques nœuds pour passer des transactions malveillantes, ou (ii) vos nœuds deviendront puissants, la chaîne ne sera pas décentralisée. L'article ne cherche pas à prouver qu'il est impossible de briser le paradoxe du triangle, mais indique que cela est difficile et nécessite de sortir du cadre de pensée implicite de cet argument.
Depuis des années, certaines chaînes hautes performances prétendent résoudre le trilemme de manière fondamentale sans changer leur architecture, généralement en optimisant les nœuds par des techniques d'ingénierie logicielle. Cela est toujours trompeur, car faire fonctionner des nœuds sur ces chaînes est plus difficile que sur Ethereum. Cet article explorera pourquoi cela est le cas et pourquoi l'ingénierie logicielle des clients L1 ne peut pas en soi faire évoluer Ethereum.
Cependant, l'échantillonnage de disponibilité des données combiné aux SNARKs résout effectivement le paradoxe du triangle : il permet aux clients de ne télécharger qu'une petite quantité de données et d'effectuer très peu de calculs pour vérifier qu'un certain nombre de données sont disponibles, et que certaines étapes de calcul ont été correctement exécutées. Les SNARKs ne nécessitent pas de confiance. L'échantillonnage de disponibilité des données a un modèle de confiance subtil de few-of-N, mais conserve les caractéristiques fondamentales d'une chaîne non extensible, même une attaque à 51 % ne peut pas forcer les blocs mauvais à être acceptés par le réseau.
Une autre méthode pour résoudre le trilemme est l'architecture Plasma, qui déplace habilement la responsabilité de la surveillance de la disponibilité des données vers les utilisateurs. De 2017 à 2019, lorsque nous n'avions que des preuves de fraude pour é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 réalisable pour des cas d'utilisation plus larges.
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, soit une bande passante de données disponible par slot d'environ 375 kB. Supposons que les données de transaction soient publiées directement sur la chaîne, un transfert ERC20 faisant environ 180 octets, alors le TPS maximal pour Rollup sur Ethereum sera : 375000 / 12 / 180 = 173.6 TPS.
Ajoutez à l'Éther calldata( la valeur maximale théorique : par slot 30 millions de Gas / par octet 16 gas = par slot 1 875 000 octets), ce qui devient 607 TPS. En utilisant PeerDAS, le nombre de blobs peut augmenter à 8-16, ce qui fournira 463-926 TPS pour le calldata.
C'est une amélioration majeure pour Ethereum L1, mais ce n'est pas suffisant. Nous voulons plus de scalabilité. L'objectif à moyen terme est de 16 Mo par slot, combiné à des améliorations de compression des données Rollup, ce qui apportera ~58000 TPS.
Qu'est-ce que c'est ? Comment ça fonctionne ?
PeerDAS est une implémentation relativement simple de "1D sampling". Dans Ethereum, chaque blob est un polynôme de degré 4096 sur un champ premier de 253 bits. Nous diffusons les parts du polynôme, chaque part contenant 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 récupéré selon les paramètres de proposition actuels : n'importe quel 64 parmi les 128 échantillons possibles ) peut récupérer le blob.
Le fonctionnement de PeerDAS consiste à faire en sorte que chaque client écoute un petit nombre de sous-réseaux, le ième sous-réseau diffuse le ième échantillon de tout blob, et en interrogeant les pairs dans le réseau p2p mondial concernant qui écoutera les différents sous-réseaux ( pour demander les blobs nécessaires sur d'autres sous-réseaux. La version plus conservatrice SubnetDAS utilise uniquement le mécanisme de sous-réseau, sans interroger la couche de pairs supplémentaire. La proposition actuelle permet 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 du "1D sampling" très largement : si nous augmentons le nombre maximum de blobs à 256) avec un objectif de 128(, nous pouvons atteindre un objectif de 16 Mo, et dans l'échantillonnage de la disponibilité des données, chaque nœud a 16 échantillons * 128 blobs * chaque blob ayant chaque échantillon de 512 octets = 1 Mo de bande passante de données par slot. Cela est juste à la limite de ce qui est tolérable : faisable, mais cela signifie qu'un client à bande passante limitée ne peut pas échantillonner. Nous pouvons optimiser en réduisant le nombre de blobs et en augmentant la taille des blobs, mais cela rendra le coût de reconstruction plus élevé.
Ainsi, nous voulons finalement aller plus loin en effectuant un échantillonnage 2D, qui échantillonne non seulement à l'intérieur des blobs, mais également entre les blobs de manière aléatoire. En utilisant les propriétés linéaires des engagements KZG, nous élargissons un ensemble de blobs dans un bloc par un nouvel ensemble de blobs virtuels, ces blobs virtuels codent de manière redondante les mêmes informations.
Il est important de noter que l'extension de l'engagement de calcul n'a pas besoin 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 blob, et ils peuvent compter sur 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 nouveau texte : Ethereum et son avenir possible, The Surge])https://img-cdn.gateio.im/webp-social/moments-5d1a322bd6b6dfef0dbb78017226633d.webp(
) Que faut-il encore faire ? Quels compromis y a-t-il ?
La prochaine étape est la mise en œuvre et le lancement de PeerDAS. Ensuite, 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é, c'est un processus progressif. En même temps, nous espérons avoir davantage de travaux académiques pour normaliser 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.
À un stade futur plus éloigné, nous aurons besoin de plus de travail pour déterminer la version idéale du DAS 2D et prouver ses attributs de sécurité. Nous espérons également pouvoir passer finalement de KZG à une alternative sécurisée contre les menaces quantiques et sans configuration de confiance. Il n'est actuellement pas clair quelles solutions candidates sont amicales pour la construction de blocs distribués. Même en utilisant une technique "brute force" 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 à satisfaire la demande, car bien que techniquement, la taille de STARK soit O###log(n( * log)log(n() hash ) utilisant STIR(, en réalité STARK est presque aussi grand que tout le 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. En effet, si le niveau L1 doit traiter un grand nombre de TPS, les blocs L1 deviendront très volumineux, et les clients souhaiteront avoir des méthodes efficaces pour vérifier leur validité. Par conséquent, nous devrons utiliser au niveau L1 les mêmes technologies que celles utilisées par 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 diminuera, ou du moins sera retardée. Si le 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 favorable à la reconstruction distribuée, cela nécessite en pratique d'être combiné avec la proposition de liste d'inclusion de paquets et son mécanisme de choix de forks environnant.
![Vitalik nouvel article : l'avenir possible d'Ethereum, The Surge]###https://img-cdn.gateio.im/webp-social/moments-71424e26868ad99f2adda7a27447820a.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 de Layer. Chaque slot de 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 résoudre les problèmes de 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-e0ddd016e2afb3218833324254451c1d.webp(
Dans la compression à zéro octet, chaque séquence longue de zéros est remplacée par deux octets, indiquant combien de zéros il y a. De plus, nous avons utilisé des attributs spécifiques aux transactions :
Agrégation de signatures : Nous passons des signatures ECDSA aux signatures BLS, la caractéristique des signatures BLS est que plusieurs signatures peuvent être combinées en une seule signature, cette signature peut prouver la validité de toutes les signatures originales. Au niveau L1, en raison du coût élevé de calcul de vérification même après agrégation, l'utilisation de signatures BLS n'est donc pas envisagée. Mais dans un environnement L2 où les données sont rares, l'utilisation de signatures BLS a du sens. La fonctionnalité d'agrégation ERC-4337 offre un moyen de réaliser cela.
Remplacer les adresses par des pointeurs : Si une adresse a été utilisée auparavant, nous pouvons remplacer l'adresse de 20 octets par un pointeur de 4 octets pointant vers une position 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 000 000 000 000 000 wei. Les frais de base maximum et les frais prioritaires sont similaires. Par conséquent, nous pouvons utiliser un format décimal flottant personnalisé pour représenter la plupart des valeurs monétaires.
) Que faut-il encore faire, quels sont les compromis?
Ce que nous devons faire ensuite, c'est mettre en œuvre concrètement le plan ci-dessus. Les principaux compromis incluent :
Passer à la signature BLS nécessite un grand effort et peut réduire la compatibilité avec des puces matérielles de confiance qui peuvent renforcer la sécurité. Il est possible d'utiliser des emballages ZK-SNARK d'autres schémas de signature comme alternative.
Compression dynamique ### Par exemple, remplacer les adresses ( par des pointeurs rendra le code client plus complexe.
Publier les différences d'état sur la chaîne plutôt que dans les transactions réduira l'auditabilité, rendant de nombreux logiciels ) tels que les explorateurs de blocs ( incapables de fonctionner.
) Comment interagir avec les autres parties de la feuille de route?
Adopter ERC-4337 et finalement intégrer une partie de son contenu.