L'avenir d'Ethereum grâce à L2 peut atteindre plus de 100 000 TPS ;
Maintenir la décentralisation et la robustesse de L1 ;
Au moins quelques L2 héritent complètement des propriétés fondamentales d'Ethereum (sans confiance, ouvert, résistant à la censure) ;
Ethereum devrait ressembler à un écosystème unifié, et non à 34 chaînes de blocs 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 les L2
Élargir l'exécution sur L1
Paradoxe du triangle de la scalabilité
Le paradoxe de la triangle de la scalabilité est une idée proposée en 2017, qui soutient qu'il existe une contradiction entre trois caractéristiques de la blockchain : la décentralisation (plus précisément : le faible coût de fonctionnement des nœuds), la scalabilité (un grand nombre de transactions traitées) et la sécurité (les attaquants doivent compromettre une grande partie des nœuds du réseau pour faire échouer une transaction unique).
Il est important de noter que la paradoxe triangulaire n'est pas un théorème, et que les publications présentant cette paradoxe ne sont pas accompagnées de preuves mathématiques. Cela donne effectivement un argument mathématique heuristique : si un nœud amical décentralisé (comme un ordinateur portable de consommation) peut vérifier N transactions par seconde, et que vous avez une chaîne capable de traiter k*N transactions par seconde, alors (i) chaque transaction ne peut être vue que par 1/k nœuds, ce qui signifie qu'un attaquant n'a besoin de compromettre qu'un petit nombre de nœuds pour réussir 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 la paradoxe triangulaire ; au contraire, il vise à montrer qu'il est difficile de briser le paradoxe ternaire, et qu'il faut dans une certaine mesure sortir du cadre de pensée implicite dans cet argument.
Depuis des années, certaines blockchains haute performance affirment qu'elles résolvent le trilemme sans changer fondamentalement l'architecture, généralement en utilisant des techniques d'ingénierie logicielle pour optimiser les nœuds. Cela est toujours trompeur, car faire fonctionner des nœuds sur ces blockchains est beaucoup plus difficile que sur Ethereum. Cet article explorera pourquoi c'est le cas et pourquoi l'ingénierie logicielle des clients L1 à elle seule ne peut pas faire évoluer 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 présente 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 l'acceptation de blocs malveillants par le réseau.
Une autre méthode pour résoudre le dilemme des trois difficultés est l'architecture Plasma, qui utilise une technologie astucieuse pour transférer la responsabilité de surveiller la disponibilité des données 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 prolifération des SNARKs (preuves succinctes non interactives à connaissance nulle), l'architecture Plasma est devenue plus viable pour un éventail d'applications plus large que jamais.
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
Quels problèmes essayons-nous de résoudre ?
Le 13 mars 2024, lors de la mise à niveau Dencun, la blockchain Ethereum disposera de 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. Si l'on suppose que les données de transaction sont publiées directement sur la chaîne, un transfert ERC20 fait environ 180 octets, donc le maximum de TPS pour les Rollups sur Ethereum est : 375000 / 12 / 180 = 173.6 TPS.
Si nous ajoutons le calldata d'Ethereum (valeur maximale théorique : 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 pour Ethereum L1, mais ce n'est pas suffisant. Nous voulons plus de scalabilité. 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 mise en œuvre relativement simple de l'« échantillonnage 1D ». Dans Ethereum, chaque blob est un polynôme de degré 4096 dans un corps de nombres premiers 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 quelle combinaison de 4096 (selon les paramètres proposés actuellement : 64 parmi 128 échantillons possibles) peut 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 aux pairs dans le réseau p2p mondial (qui écoutera différents sous-réseaux) les blobs nécessaires provenant 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 utiliser SubnetDAS aux nœuds participant à la preuve de participation, tandis que les autres nœuds (c'est-à-dire les clients) utilisent PeerDAS.
Théoriquement, nous pouvons évoluer à une échelle assez grande pour le « 1D sampling » : si nous augmentons le nombre maximal de blobs à 256 (l'objectif étant 128), nous pouvons atteindre l'objectif de 16 Mo, alors que dans l'échantillonnage de disponibilité des données, chaque nœud a 16 échantillons * 128 blobs * 512 octets par blob et par échantillon = 1 Mo de bande passante de données par slot. Cela est juste à la limite de notre 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 rendra le coût de reconstruction plus élevé.
Ainsi, nous voulons finalement aller plus loin en effectuant un échantillonnage 2D, une méthode qui effectue des échantillonnages aléatoires non seulement à l'intérieur d'un blob, mais également entre les blobs. En utilisant les propriétés linéaires des engagements KZG, nous étendons un ensemble de blobs dans un bloc par un ensemble de nouveaux blobs virtuels, qui codent de manière redondante les mêmes informations.
Ainsi, finalement, nous souhaitons aller plus loin en effectuant un échantillonnage 2D, qui effectue un échantillonnage aléatoire non seulement à l'intérieur des blobs, mais également entre les blobs. La propriété linéaire de l'engagement KZG est utilisée pour étendre un ensemble de blobs dans un bloc, qui contient une nouvelle liste de blobs virtuels codés en redondance pour les mêmes informations.
Il est crucial de noter que l'extension des engagements de calcul ne nécessite pas de blob, ce qui rend cette solution fondamentalement amicale pour la construction de blocs distribués. Les nœuds qui construisent réellement les blocs n'ont besoin que des engagements KZG des blobs, et ils peuvent compter 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 unidimensionnelles (1D DAS) est également fondamentalement amical pour la construction de blocs distribués.
Que faut-il encore faire ? Quelles sont les considérations ?
La prochaine étape est la mise en œuvre et le lancement de PeerDAS. Ensuite, nous continuerons à augmenter 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. Parallèlement, nous espérons avoir plus de travaux académiques pour réglementer PeerDAS et d'autres versions de DAS ainsi que leur interaction avec des questions de sécurité telles que les règles de sélection de fork.
À un stade futur plus éloigné, nous devrons faire plus de travail pour déterminer la version idéale de 2D DAS et prouver ses propriétés de sécurité. Nous espérons également pouvoir finalement passer de KZG à une alternative quantique sécurisée et sans configuration de confiance. Actuellement, nous ne savons pas encore quelles sont les solutions candidates amicales pour la construction de blocs distribués. Même l'utilisation de techniques « de force brute » coûteuses, comme l'utilisation de STARK récursifs pour générer des preuves de validité pour reconstruire les lignes et les colonnes, ne suffit pas à répondre aux besoins, car bien qu'en théorie, un STARK a une taille de O(log(n) * log(log(n)) hachage (utilisant STIR), en réalité, le STARK est presque aussi grand que l'ensemble du blob.
Je pense que le chemin de réalité à long terme est :
Mettre en œuvre un DAS 2D idéal ;
Continuer à utiliser 1D DAS, sacrifiant l'efficacité de la bande passante d'échantillonnage, afin d'accepter une limite de données plus basse pour la simplicité et la robustesse.
Abandonner DA et accepter complètement Plasma comme notre principale architecture Layer2.
Veuillez noter que même si nous décidons d'étendre directement l'exécution 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 une méthode efficace pour vérifier leur validité. Par conséquent, nous devrons utiliser les mêmes technologies au niveau L1 que celles utilisées pour les Rollups (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, et 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 convivial pour la reconstruction distribuée, cela nécessite en pratique d'être combiné avec la proposition de liste d'inclusion de paquets et les mécanismes de sélection de forks qui l'entourent.
Compression de données
Quels problèmes résolvons-nous ?
Chaque transaction dans un Rollup occupe 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 Layer. Chaque slot étant 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 molécules, mais aussi celui des dénominateurs, permettant à 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 :
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 utilisé des propriétés spécifiques des transactions :
Agrégation de signatures : Nous avons changé de signatures ECDSA à des signatures BLS, dont la caractéristique est que plusieurs signatures peuvent être combinées en une seule signature, qui peut prouver la validité de toutes les signatures originales. Au niveau L1, il n'est pas envisagé d'utiliser des signatures BLS car le coût de calcul de la vérification reste élevé même avec l'agrégation. Mais dans un environnement L2 où les données sont rares, l'utilisation de signatures BLS a du sens. La fonctionnalité d'agrégation de l'ERC-4337 offre un moyen de réaliser cela.
Remplacer les adresses par des pointeurs : si nous avons déjà utilisé une adresse, nous pouvons remplacer l'adresse de 20 octets par un pointeur de 4 octets pointant vers un 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 000 000 000 000 000 wei. Main de base maximale
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.
9 J'aime
Récompense
9
4
Reposter
Partager
Commentaire
0/400
MetaEggplant
· Il y a 19h
L2 cette vitesse To the moon? bull wow
Voir l'originalRépondre0
rugpull_ptsd
· 08-06 07:39
Ce tps est un peu exagéré, non ? C'est loin derrière sol.
Voir l'originalRépondre0
ZeroRushCaptain
· 08-06 07:27
prendre les gens pour des idiots, c'est être un roi; Inversé, faire faillite, c'est être un champion.
Voir l'originalRépondre0
VCsSuckMyLiquidity
· 08-06 07:25
C'est un peu brutal, 100 000 tps, ça va enfin atteindre un grand score.
Ethereum La mise à niveau The Surge : atteindre 100 000 TPS grâce à L2 tout en maintenant la Décentralisation
L'avenir possible d'Ethereum : The Surge
The Surge : Objectifs clés
L'avenir d'Ethereum grâce à L2 peut atteindre plus de 100 000 TPS ;
Maintenir la décentralisation et la robustesse de L1 ;
Au moins quelques L2 héritent complètement des propriétés fondamentales d'Ethereum (sans confiance, ouvert, résistant à la censure) ;
Ethereum devrait ressembler à un écosystème unifié, et non à 34 chaînes de blocs différentes.
Contenu de ce chapitre
Paradoxe du triangle de la scalabilité
Le paradoxe de la triangle de la scalabilité est une idée proposée en 2017, qui soutient qu'il existe une contradiction entre trois caractéristiques de la blockchain : la décentralisation (plus précisément : le faible coût de fonctionnement des nœuds), la scalabilité (un grand nombre de transactions traitées) et la sécurité (les attaquants doivent compromettre une grande partie des nœuds du réseau pour faire échouer une transaction unique).
Il est important de noter que la paradoxe triangulaire n'est pas un théorème, et que les publications présentant cette paradoxe ne sont pas accompagnées de preuves mathématiques. Cela donne effectivement un argument mathématique heuristique : si un nœud amical décentralisé (comme un ordinateur portable de consommation) peut vérifier N transactions par seconde, et que vous avez une chaîne capable de traiter k*N transactions par seconde, alors (i) chaque transaction ne peut être vue que par 1/k nœuds, ce qui signifie qu'un attaquant n'a besoin de compromettre qu'un petit nombre de nœuds pour réussir 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 la paradoxe triangulaire ; au contraire, il vise à montrer qu'il est difficile de briser le paradoxe ternaire, et qu'il faut dans une certaine mesure sortir du cadre de pensée implicite dans cet argument.
Depuis des années, certaines blockchains haute performance affirment qu'elles résolvent le trilemme sans changer fondamentalement l'architecture, généralement en utilisant des techniques d'ingénierie logicielle pour optimiser les nœuds. Cela est toujours trompeur, car faire fonctionner des nœuds sur ces blockchains est beaucoup plus difficile que sur Ethereum. Cet article explorera pourquoi c'est le cas et pourquoi l'ingénierie logicielle des clients L1 à elle seule ne peut pas faire évoluer 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 présente 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 l'acceptation de blocs malveillants par le réseau.
Une autre méthode pour résoudre le dilemme des trois difficultés est l'architecture Plasma, qui utilise une technologie astucieuse pour transférer la responsabilité de surveiller la disponibilité des données 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 prolifération des SNARKs (preuves succinctes non interactives à connaissance nulle), l'architecture Plasma est devenue plus viable pour un éventail d'applications plus large que jamais.
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
Quels problèmes essayons-nous de résoudre ?
Le 13 mars 2024, lors de la mise à niveau Dencun, la blockchain Ethereum disposera de 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. Si l'on suppose que les données de transaction sont publiées directement sur la chaîne, un transfert ERC20 fait environ 180 octets, donc le maximum de TPS pour les Rollups sur Ethereum est : 375000 / 12 / 180 = 173.6 TPS.
Si nous ajoutons le calldata d'Ethereum (valeur maximale théorique : 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 pour Ethereum L1, mais ce n'est pas suffisant. Nous voulons plus de scalabilité. 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 mise en œuvre relativement simple de l'« échantillonnage 1D ». Dans Ethereum, chaque blob est un polynôme de degré 4096 dans un corps de nombres premiers 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 quelle combinaison de 4096 (selon les paramètres proposés actuellement : 64 parmi 128 échantillons possibles) peut 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 aux pairs dans le réseau p2p mondial (qui écoutera différents sous-réseaux) les blobs nécessaires provenant 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 utiliser SubnetDAS aux nœuds participant à la preuve de participation, tandis que les autres nœuds (c'est-à-dire les clients) utilisent PeerDAS.
Théoriquement, nous pouvons évoluer à une échelle assez grande pour le « 1D sampling » : si nous augmentons le nombre maximal de blobs à 256 (l'objectif étant 128), nous pouvons atteindre l'objectif de 16 Mo, alors que dans l'échantillonnage de disponibilité des données, chaque nœud a 16 échantillons * 128 blobs * 512 octets par blob et par échantillon = 1 Mo de bande passante de données par slot. Cela est juste à la limite de notre 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 rendra le coût de reconstruction plus élevé.
Ainsi, nous voulons finalement aller plus loin en effectuant un échantillonnage 2D, une méthode qui effectue des échantillonnages aléatoires non seulement à l'intérieur d'un blob, mais également entre les blobs. En utilisant les propriétés linéaires des engagements KZG, nous étendons un ensemble de blobs dans un bloc par un ensemble de nouveaux blobs virtuels, qui codent de manière redondante les mêmes informations.
Ainsi, finalement, nous souhaitons aller plus loin en effectuant un échantillonnage 2D, qui effectue un échantillonnage aléatoire non seulement à l'intérieur des blobs, mais également entre les blobs. La propriété linéaire de l'engagement KZG est utilisée pour étendre un ensemble de blobs dans un bloc, qui contient une nouvelle liste de blobs virtuels codés en redondance pour les mêmes informations.
Il est crucial de noter que l'extension des engagements de calcul ne nécessite pas de blob, ce qui rend cette solution fondamentalement amicale pour la construction de blocs distribués. Les nœuds qui construisent réellement les blocs n'ont besoin que des engagements KZG des blobs, et ils peuvent compter 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 unidimensionnelles (1D DAS) est également fondamentalement amical pour la construction de blocs distribués.
Que faut-il encore faire ? Quelles sont les considérations ?
La prochaine étape est la mise en œuvre et le lancement de PeerDAS. Ensuite, nous continuerons à augmenter 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. Parallèlement, nous espérons avoir plus de travaux académiques pour réglementer PeerDAS et d'autres versions de DAS ainsi que leur interaction avec des questions de sécurité telles que les règles de sélection de fork.
À un stade futur plus éloigné, nous devrons faire plus de travail pour déterminer la version idéale de 2D DAS et prouver ses propriétés de sécurité. Nous espérons également pouvoir finalement passer de KZG à une alternative quantique sécurisée et sans configuration de confiance. Actuellement, nous ne savons pas encore quelles sont les solutions candidates amicales pour la construction de blocs distribués. Même l'utilisation de techniques « de force brute » coûteuses, comme l'utilisation de STARK récursifs pour générer des preuves de validité pour reconstruire les lignes et les colonnes, ne suffit pas à répondre aux besoins, car bien qu'en théorie, un STARK a une taille de O(log(n) * log(log(n)) hachage (utilisant STIR), en réalité, le STARK est presque aussi grand que l'ensemble du blob.
Je pense que le chemin de réalité à long terme est :
Veuillez noter que même si nous décidons d'étendre directement l'exécution 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 une méthode efficace pour vérifier leur validité. Par conséquent, nous devrons utiliser les mêmes technologies au niveau L1 que celles utilisées pour les Rollups (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, et 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 convivial pour la reconstruction distribuée, cela nécessite en pratique d'être combiné avec la proposition de liste d'inclusion de paquets et les mécanismes de sélection de forks qui l'entourent.
Compression de données
Quels problèmes résolvons-nous ?
Chaque transaction dans un Rollup occupe 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 Layer. Chaque slot étant 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 molécules, mais aussi celui des dénominateurs, permettant à 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 :
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 utilisé des propriétés spécifiques des transactions :
Agrégation de signatures : Nous avons changé de signatures ECDSA à des signatures BLS, dont la caractéristique est que plusieurs signatures peuvent être combinées en une seule signature, qui peut prouver la validité de toutes les signatures originales. Au niveau L1, il n'est pas envisagé d'utiliser des signatures BLS car le coût de calcul de la vérification reste élevé même avec l'agrégation. Mais dans un environnement L2 où les données sont rares, l'utilisation de signatures BLS a du sens. La fonctionnalité d'agrégation de l'ERC-4337 offre un moyen de réaliser cela.
Remplacer les adresses par des pointeurs : si nous avons déjà utilisé une adresse, nous pouvons remplacer l'adresse de 20 octets par un pointeur de 4 octets pointant vers un 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 000 000 000 000 000 wei. Main de base maximale