Le paradoxe de la triangle de l'évolutivité soutient qu'il existe une contradiction entre les trois caractéristiques de la décentralisation, de l'évolutivité et de la sécurité dans la blockchain. Ce n'est pas un théorème strict, mais plutôt un argument mathématique heuristique : si un nœud amical à la décentralisation peut vérifier N transactions par seconde, et que vous avez une chaîne capable de traiter k*N transactions par seconde, alors soit chaque transaction ne peut être vue que par 1/k nœuds, ce qui signifie qu'un attaquant n'aurait besoin de compromettre qu'un petit nombre de nœuds pour réussir une transaction malveillante ; soit vos nœuds deviendront puissants, et votre chaîne ne sera pas décentralisée.
Depuis des années, certaines chaînes haute performance affirment qu'elles ont résolu 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 chaînes est beaucoup plus difficile que de faire fonctionner des nœuds sur Ethereum.
Cependant, la combinaison de l'échantillonnage de la disponibilité des données et des SNARKs résout effectivement le paradoxe du triangle : 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 téléchargeant uniquement une petite quantité de données et en effectuant un très faible calcul. 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 un mauvais bloc à être accepté 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 la disponibilité des données de surveillance aux utilisateurs d'une manière compatible avec les incitations. Avec la popularité des SNARKs, l'architecture Plasma devient plus viable pour une gamme d'utilisations plus large que jamais.
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
Quel problème essayons-nous de résoudre ?
Le 13 mars 2024, lorsque la mise à niveau Dencun sera en ligne, la blockchain Ethereum aura 3 blobs d'environ 125 kB par slot toutes les 12 secondes, soit une bande passante de données disponible d'environ 375 kB par slot. Supposons que les données de transaction soient publiées directement sur la chaîne, alors un transfert ERC20 fait environ 180 octets, donc le TPS maximum de Rollup sur Ethereum est : 375000 / 12 / 180 = 173.6 TPS.
Si nous ajoutons le calldata d'Ethereum, 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, donnera environ ~58000 TPS.
Qu'est-ce que c'est ? Comment ça fonctionne ?
PeerDAS est une implémentation relativement simple de l'"échantillonnage 1D". Dans Ethereum, chaque blob est un polynôme de degré 4096 dans un champ premier de 253 bits. Nous diffusons les parts du polynôme, chaque part contenant 16 valeurs évaluées sur 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 valeurs évaluées, n'importe quelle combinaison de 4096 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 le blob dont il a besoin sur d'autres sous-réseaux. Une version plus conservatrice, SubnetDAS, utilise uniquement le mécanisme de sous-réseau, sans requêtes supplémentaires 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 utiliseront PeerDAS.
En théorie, nous pouvons étendre l'échantillonnage "1D" à une échelle assez grande : si nous augmentons le nombre maximum de blobs à 256, nous pouvons atteindre l'objectif de 16 Mo, et dans l'échantillonnage de la 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 augmentera le coût de reconstruction.
Ainsi, nous souhaitons finalement aller plus loin et effectuer un échantillonnage 2D, une méthode qui consiste non seulement à effectuer un échantillonnage aléatoire à l'intérieur des blobs, 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, 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 approche est 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 compter sur l'échantillonnage de la disponibilité des données pour valider 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.
Que faut-il encore faire ? Quelles sont les concessions à faire ?
La prochaine étape consiste à finaliser l'implémentation et le lancement de PeerDAS. Ensuite, nous augmenterons 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 progressif. Dans le 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 choix de forks.
À un stade futur plus éloigné, nous devrons faire plus de travail pour déterminer la version idéale du 2D DAS et prouver ses attributs de sécurité. Nous espérons également pouvoir finalement passer du KZG à une alternative quantiquement sûre et sans configuration de confiance. Pour l'instant, nous ne savons pas encore quelles solutions candidates sont favorables à la construction de blocs distribués. Même en utilisant la technologie coûteuse de "brute force", c'est-à-dire en utilisant des STARKs 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 qu'en théorie, la taille d'un STARK soit O(log(n) * log(log(n)) valeur de hachage, en pratique, un STARK est presque aussi grand que le blob entier.
Le chemin de réalité à long terme que je considère est :
Mettre en œuvre un DAS 2D idéal;
Persister à utiliser 1D DAS, sacrifiant l'efficacité de la bande passante d'échantillonnage, afin d'accepter une limite de données inférieure pour la simplicité et la robustesse.
Abandonner DA et accepter complètement Plasma comme notre principale architecture Layer2 d'intérêt.
Veuillez noter que même si nous choisissons d'étendre directement l'exécution au niveau L1, cette option existe. Cela est dû au fait que si le niveau L1 doit traiter un grand nombre de TPS, les blocs L1 deviendront très volumineux, et les clients souhaiteront avoir une méthode efficace pour vérifier leur validité, nous devrons donc utiliser la même technologie qu'avec Rollup au niveau L1.
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 à la proposition de liste d'inclusion de paquets et aux mécanismes de sélection de forks qui l'entourent.
Compression des données
Quel problème essayons-nous de résoudre ?
Chaque transaction dans un Rollup occupe 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 de couche. Chaque slot 16 Mo, nous obtenons :
16000000 / 12 / 180 = 7407 TPS
Que se passerait-il si nous pouvions non seulement résoudre le problème des numérateurs, mais aussi celui des dénominateurs, permettant à chaque transaction dans 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 :
Compression à zéro octet, remplaçant chaque longue séquence de zéros par deux octets, indiquant combien de zéros il y a. De plus, nous avons tiré parti de certaines propriétés spécifiques des 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, qui peut prouver la validité de toutes les signatures originales. Au niveau L1, même avec l'agrégation, le coût de calcul de la vérification est élevé, donc l'utilisation de signatures BLS n'est pas envisagée. Mais dans un environnement L2 où les données sont rares, l'utilisation de signatures BLS a du sens. La caractéristique d'agrégation de l'ERC-4337 fournit une voie pour réaliser cette fonctionnalité.
Remplacer les adresses par des pointeurs : si nous avons utilisé une adresse auparavant, 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 ETH est représenté par 250 000 000 000 000 000 wei. Les frais de base maximum et les frais prioritaires sont également 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 est de mettre en œuvre concrètement le plan ci-dessus. Les principaux compromis incluent :
Passer aux signatures BLS nécessite un effort considérable et diminuera la compatibilité avec les puces matérielles de confiance qui peuvent renforcer la sécurité. Il est possible d'utiliser un emballage 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 au lieu des transactions réduira l'auditabilité et empêchera de nombreux logiciels (, tels que les explorateurs de blocs ), de fonctionner.
Comment interagir avec d'autres parties de la feuille de route ?
L'adoption d'ERC-4337 et l'intégration de certaines de ses fonctionnalités dans le L2 EVM peuvent considérablement accélérer le déploiement des technologies d'agrégation. Mettre certaines fonctionnalités d'ERC-4337 sur L1 peut accélérer son déploiement sur L2.
Plasma généralisé
Quels problèmes sommes-nous en train de résoudre ?
Même avec un blob de 16 Mo et la compression des données, 58 000 TPS ne seront peut-être pas suffisants pour répondre entièrement aux besoins des paiements consommateurs, des réseaux sociaux décentralisés ou d'autres domaines à forte bande passante, surtout quand nous commençons à prendre en compte les facteurs de confidentialité, ce qui pourrait réduire la scalabilité de 3 à 8 fois. Pour les scénarios d'application à fort volume de transactions et à faible valeur, une option actuelle est d'utiliser Validium, qui conserve les données hors chaîne et adopte un modèle de sécurité intéressant : les opérateurs ne peuvent pas voler les fonds des utilisateurs, mais ils peuvent geler temporairement ou définitivement les fonds de tous les utilisateurs. Mais nous pouvons faire mieux.
Qu'est-ce que c'est, comment ça fonctionne ?
Plasma est une solution d'extensibilité qui implique un opérateur publiant des blocs hors chaîne et plaçant la racine Merkle de ces blocs sur la chaîne. Pour chaque bloc, l'opérateur envoie à chaque utilisateur une branche Merkle pour prouver les changements d'actifs de cet utilisateur, ou l'absence de changements. Les utilisateurs peuvent retirer leurs actifs en fournissant la branche Merkle. Il est important de noter que cette branche n'a pas besoin d'être à jour. Ainsi, même en cas de problème de disponibilité des données, les utilisateurs peuvent récupérer leurs actifs en extrayant leur état le plus récent disponible. Si un utilisateur soumet une branche invalide, la légitimité de la possession des actifs peut être déterminée par le mécanisme de défi sur la chaîne.
Les premières versions de Plasma ne pouvaient traiter que des cas de paiement, et ne pouvaient pas être efficacement étendues. Cependant, si nous exigeons que chaque racine soit vérifiée par SNARK, alors Plasma deviendrait beaucoup plus puissant. Chaque jeu de défi pourrait être grandement simplifié,
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
6 J'aime
Récompense
6
6
Reposter
Partager
Commentaire
0/400
AltcoinMarathoner
· 08-13 13:35
dans la crypto depuis 2016... l'évolutivité n'est pas un sprint, c'est un ultra marathon. eth reste leading le peloton fr
Voir l'originalRépondre0
BoredApeResistance
· 08-13 07:25
Quand le Layer 2 pourra-t-il être mis en œuvre, sigh.
Voir l'originalRépondre0
NeverVoteOnDAO
· 08-10 19:10
Encore dit ces paroles creuses, le nœud ne peut pas fonctionner.
Voir l'originalRépondre0
FancyResearchLab
· 08-10 18:58
Valeur académique pump, je vais me connecter pour faire une petite expérience.
Voir l'originalRépondre0
BlockchainThinkTank
· 08-10 18:51
Peu importe à quel point les discours sont séduisants, les données ne mentent jamais. Je conseille aux pigeons de rester attentifs aux évolutions.
Voir l'originalRépondre0
FudVaccinator
· 08-10 18:44
Le paradoxe des trios ne peut toujours pas être évité, il faut y faire face.
Ethereum The Surge : dépasser les limites de la scalabilité
L'avenir d'Ethereum : The Surge
Paradoxe de la triangle de la scalabilité
Le paradoxe de la triangle de l'évolutivité soutient qu'il existe une contradiction entre les trois caractéristiques de la décentralisation, de l'évolutivité et de la sécurité dans la blockchain. Ce n'est pas un théorème strict, mais plutôt un argument mathématique heuristique : si un nœud amical à la décentralisation peut vérifier N transactions par seconde, et que vous avez une chaîne capable de traiter k*N transactions par seconde, alors soit chaque transaction ne peut être vue que par 1/k nœuds, ce qui signifie qu'un attaquant n'aurait besoin de compromettre qu'un petit nombre de nœuds pour réussir une transaction malveillante ; soit vos nœuds deviendront puissants, et votre chaîne ne sera pas décentralisée.
Depuis des années, certaines chaînes haute performance affirment qu'elles ont résolu 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 chaînes est beaucoup plus difficile que de faire fonctionner des nœuds sur Ethereum.
Cependant, la combinaison de l'échantillonnage de la disponibilité des données et des SNARKs résout effectivement le paradoxe du triangle : 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 téléchargeant uniquement une petite quantité de données et en effectuant un très faible calcul. 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 un mauvais bloc à être accepté 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 la disponibilité des données de surveillance aux utilisateurs d'une manière compatible avec les incitations. Avec la popularité des SNARKs, l'architecture Plasma devient plus viable pour une gamme d'utilisations plus large que jamais.
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
Quel problème essayons-nous de résoudre ?
Le 13 mars 2024, lorsque la mise à niveau Dencun sera en ligne, la blockchain Ethereum aura 3 blobs d'environ 125 kB par slot toutes les 12 secondes, soit une bande passante de données disponible d'environ 375 kB par slot. Supposons que les données de transaction soient publiées directement sur la chaîne, alors un transfert ERC20 fait environ 180 octets, donc le TPS maximum de Rollup sur Ethereum est : 375000 / 12 / 180 = 173.6 TPS.
Si nous ajoutons le calldata d'Ethereum, 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, donnera environ ~58000 TPS.
Qu'est-ce que c'est ? Comment ça fonctionne ?
PeerDAS est une implémentation relativement simple de l'"échantillonnage 1D". Dans Ethereum, chaque blob est un polynôme de degré 4096 dans un champ premier de 253 bits. Nous diffusons les parts du polynôme, chaque part contenant 16 valeurs évaluées sur 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 valeurs évaluées, n'importe quelle combinaison de 4096 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 le blob dont il a besoin sur d'autres sous-réseaux. Une version plus conservatrice, SubnetDAS, utilise uniquement le mécanisme de sous-réseau, sans requêtes supplémentaires 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 utiliseront PeerDAS.
En théorie, nous pouvons étendre l'échantillonnage "1D" à une échelle assez grande : si nous augmentons le nombre maximum de blobs à 256, nous pouvons atteindre l'objectif de 16 Mo, et dans l'échantillonnage de la 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 augmentera le coût de reconstruction.
Ainsi, nous souhaitons finalement aller plus loin et effectuer un échantillonnage 2D, une méthode qui consiste non seulement à effectuer un échantillonnage aléatoire à l'intérieur des blobs, 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, 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 approche est 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 compter sur l'échantillonnage de la disponibilité des données pour valider 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.
Que faut-il encore faire ? Quelles sont les concessions à faire ?
La prochaine étape consiste à finaliser l'implémentation et le lancement de PeerDAS. Ensuite, nous augmenterons 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 progressif. Dans le 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 choix de forks.
À un stade futur plus éloigné, nous devrons faire plus de travail pour déterminer la version idéale du 2D DAS et prouver ses attributs de sécurité. Nous espérons également pouvoir finalement passer du KZG à une alternative quantiquement sûre et sans configuration de confiance. Pour l'instant, nous ne savons pas encore quelles solutions candidates sont favorables à la construction de blocs distribués. Même en utilisant la technologie coûteuse de "brute force", c'est-à-dire en utilisant des STARKs 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 qu'en théorie, la taille d'un STARK soit O(log(n) * log(log(n)) valeur de hachage, en pratique, un STARK est presque aussi grand que le blob entier.
Le chemin de réalité à long terme que je considère est :
Veuillez noter que même si nous choisissons d'étendre directement l'exécution au niveau L1, cette option existe. Cela est dû au fait que si le niveau L1 doit traiter un grand nombre de TPS, les blocs L1 deviendront très volumineux, et les clients souhaiteront avoir une méthode efficace pour vérifier leur validité, nous devrons donc utiliser la même technologie qu'avec Rollup au niveau L1.
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 à la proposition de liste d'inclusion de paquets et aux mécanismes de sélection de forks qui l'entourent.
Compression des données
Quel problème essayons-nous de résoudre ?
Chaque transaction dans un Rollup occupe 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 de couche. Chaque slot 16 Mo, nous obtenons :
16000000 / 12 / 180 = 7407 TPS
Que se passerait-il si nous pouvions non seulement résoudre le problème des numérateurs, mais aussi celui des dénominateurs, permettant à chaque transaction dans 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 :
Compression à zéro octet, remplaçant chaque longue séquence de zéros par deux octets, indiquant combien de zéros il y a. De plus, nous avons tiré parti de certaines propriétés spécifiques des 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, qui peut prouver la validité de toutes les signatures originales. Au niveau L1, même avec l'agrégation, le coût de calcul de la vérification est élevé, donc l'utilisation de signatures BLS n'est pas envisagée. Mais dans un environnement L2 où les données sont rares, l'utilisation de signatures BLS a du sens. La caractéristique d'agrégation de l'ERC-4337 fournit une voie pour réaliser cette fonctionnalité.
Remplacer les adresses par des pointeurs : si nous avons utilisé une adresse auparavant, 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 ETH est représenté par 250 000 000 000 000 000 wei. Les frais de base maximum et les frais prioritaires sont également 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 est de mettre en œuvre concrètement le plan ci-dessus. Les principaux compromis incluent :
Passer aux signatures BLS nécessite un effort considérable et diminuera la compatibilité avec les puces matérielles de confiance qui peuvent renforcer la sécurité. Il est possible d'utiliser un emballage 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 au lieu des transactions réduira l'auditabilité et empêchera de nombreux logiciels (, tels que les explorateurs de blocs ), de fonctionner.
Comment interagir avec d'autres parties de la feuille de route ?
L'adoption d'ERC-4337 et l'intégration de certaines de ses fonctionnalités dans le L2 EVM peuvent considérablement accélérer le déploiement des technologies d'agrégation. Mettre certaines fonctionnalités d'ERC-4337 sur L1 peut accélérer son déploiement sur L2.
Plasma généralisé
Quels problèmes sommes-nous en train de résoudre ?
Même avec un blob de 16 Mo et la compression des données, 58 000 TPS ne seront peut-être pas suffisants pour répondre entièrement aux besoins des paiements consommateurs, des réseaux sociaux décentralisés ou d'autres domaines à forte bande passante, surtout quand nous commençons à prendre en compte les facteurs de confidentialité, ce qui pourrait réduire la scalabilité de 3 à 8 fois. Pour les scénarios d'application à fort volume de transactions et à faible valeur, une option actuelle est d'utiliser Validium, qui conserve les données hors chaîne et adopte un modèle de sécurité intéressant : les opérateurs ne peuvent pas voler les fonds des utilisateurs, mais ils peuvent geler temporairement ou définitivement les fonds de tous les utilisateurs. Mais nous pouvons faire mieux.
Qu'est-ce que c'est, comment ça fonctionne ?
Plasma est une solution d'extensibilité qui implique un opérateur publiant des blocs hors chaîne et plaçant la racine Merkle de ces blocs sur la chaîne. Pour chaque bloc, l'opérateur envoie à chaque utilisateur une branche Merkle pour prouver les changements d'actifs de cet utilisateur, ou l'absence de changements. Les utilisateurs peuvent retirer leurs actifs en fournissant la branche Merkle. Il est important de noter que cette branche n'a pas besoin d'être à jour. Ainsi, même en cas de problème de disponibilité des données, les utilisateurs peuvent récupérer leurs actifs en extrayant leur état le plus récent disponible. Si un utilisateur soumet une branche invalide, la légitimité de la possession des actifs peut être déterminée par le mécanisme de défi sur la chaîne.
Les premières versions de Plasma ne pouvaient traiter que des cas de paiement, et ne pouvaient pas être efficacement étendues. Cependant, si nous exigeons que chaque racine soit vérifiée par SNARK, alors Plasma deviendrait beaucoup plus puissant. Chaque jeu de défi pourrait être grandement simplifié,