La stratégie d'extension d'Ethereum avait initialement deux voies : le sharding et Layer2. Le sharding permet à chaque nœud de ne valider et de stocker qu'une petite partie des transactions, tandis que Layer2 déplace la plupart des données et des calculs en dehors de la chaîne principale. Ces deux voies 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 le Rollup propose une division 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 assume la tâche d'aider l'écosystème à s'étendre. Ce modèle est courant dans la société : le système judiciaire (L1) existe pour protéger les contrats et les droits de propriété, tandis que les entrepreneurs (L2) construisent dessus, propulsant le développement humain.
Cette année, la feuille de route axée sur les Rollups a obtenu des résultats importants : le lancement des blobs EIP-4844 a considérablement augmenté la bande passante des données d'Ethereum L1, et plusieurs Rollups EVM ont atteint la première phase. Chaque L2 existe en tant que "fragment" avec des règles et logiques internes. La diversité des méthodes de mise en œuvre des fragments est désormais une réalité. Mais ce chemin fait également face à des défis uniques. Notre tâche actuelle est de compléter cette feuille de route et de résoudre ces problèmes tout en maintenant la robustesse et la décentralisation d'Ethereum L1.
The Surge: Objectifs clés
L'avenir d'Ethereum peut atteindre plus de 100 000 TPS grâce à L2.
Maintenir la décentralisation et la robustesse de L1
Au moins certaines L2 héritent complètement des propriétés fondamentales d'Ethereum : ( la confiance, l'ouverture, 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
Paradoxe du triangle de la scalabilité
Le paradoxe du triangle de la scalabilité soutient qu'il existe une contradiction entre les trois caractéristiques de la décentralisation, de la scalabilité et de la sécurité des blockchains. Ce n'est pas un théorème, mais cela propose un argument 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 des nœuds, soit vos nœuds deviendront puissants et la chaîne ne sera pas décentralisée.
Certaines chaînes haute performance prétendent résoudre le paradoxe trilemme, généralement en optimisant le logiciel des nœuds. Mais cela est souvent trompeur, car faire fonctionner des nœuds sur ces chaînes est plus difficile que sur Ethereum. L'ingénierie logicielle des clients L1 à elle seule ne peut pas faire évoluer Ethereum.
Cependant, la combinaison de l'échantillonnage de disponibilité des données et des SNARKs résout effectivement le paradoxe du triangle : elle permet aux clients de vérifier la disponibilité d'une grande quantité de données et l'exécution correcte des étapes de calcul 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 disponibilité des données a un modèle de confiance subtil few-of-N, mais conserve les caractéristiques fondamentales des chaînes non extensibles.
L'architecture Plasma est une autre solution qui confie aux utilisateurs la responsabilité de surveiller la disponibilité des données. Avec la popularité des SNARKs, Plasma devient viable pour un plus large éventail de scénarios.
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
Nous résolvons quel problème ?
Après la mise à niveau Dencun le 13 mars 2024, Ethereum aura 3 blobs d'environ 125 Ko par slot toutes les 12 secondes, avec une bande passante de données disponible d'environ 375 Ko/slot. Supposons que les données de transaction soient directement publiées sur la chaîne, un transfert ERC20 fait environ 180 octets, alors le maximum de TPS pour les Rollups sur Ethereum sera de 173,6.
Avec les données de calldatas, on peut atteindre 607 TPS. En utilisant PeerDAS, le nombre de blobs peut augmenter à 8-16, fournissant 463-926 TPS pour les calldatas.
C'est une amélioration majeure pour L1, mais ce n'est pas suffisant. Notre objectif à moyen terme est de 16 Mo par slot, combiné à la compression des données Rollup, ce qui permettra d'atteindre ~58000 TPS.
Qu'est-ce que c'est ? Comment ça fonctionne ?
PeerDAS est une implémentation simple de "1D sampling". Dans Ethereum, chaque blob est un polynôme de degré 4096 sur un corps premier de 253 bits. Nous diffusons les parts du polynôme, chaque part contenant 16 évaluations de 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 évaluations, n'importe quel ensemble de 4096 peut restaurer le blob.
PeerDAS permet à chaque client d'écouter un petit nombre de sous-réseaux, le ième sous-réseau diffuse le ième échantillon de tout blob et demande des blobs sur d'autres sous-réseaux en interrogeant les pairs dans le réseau p2p mondial. SubnetDAS utilise uniquement la mécanique des sous-réseaux, sans interroger de couche de pair supplémentaire. La proposition actuelle permet aux nœuds participant à la preuve de participation d'utiliser SubnetDAS, tandis que les autres nœuds utilisent PeerDAS.
Théoriquement, nous pouvons étendre l'échelle du "1D sampling" très largement : si nous augmentons le nombre maximal de blobs à 256, nous pouvons atteindre l'objectif de 16 Mo, chaque nœud nécessitant 1 Mo de bande passante de données par slot. Cela est à peine réalisable, mais les clients avec une bande passante limitée ne peuvent pas échantillonner. Nous pouvons optimiser en réduisant le nombre de blobs et en augmentant la taille des blobs, mais cela augmentera le coût de reconstruction.
Ainsi, nous voulons finalement effectuer un échantillonnage 2D, non seulement à l'intérieur des blobs, mais également entre les blobs. En utilisant les propriétés linéaires des engagements KZG, nous étendons l'ensemble de blobs dans un bloc par de nouveaux blobs virtuels, ces blobs virtuels encodent redondamment la même information.
L'échantillonnage 2D est favorable à la construction de blocs distribués. Les nœuds qui construisent effectivement des blocs n'ont besoin que d'un engagement KZG blob et peuvent compter sur le DAS pour vérifier la disponibilité. Le DAS 1D est également fondamentalement favorable à la construction de blocs distribués.
Quels sont les liens avec les recherches existantes?
Introduction au message original sur la disponibilité des données (2018)
Document de suivi
Article explicatif sur DAS
Disponibilité 2D avec engagement KZG
PeerDAS et articles sur ethresear.ch
EIP-7594
SubnetDAS sur ethresear.ch
Les subtilités de la récupérabilité dans l'échantillonnage 2D
que faut-il encore faire ? Quels sont les compromis ?
La prochaine étape est de finaliser l'implémentation et le lancement de PeerDAS. Ensuite, augmenter continuellement le nombre de blobs sur PeerDAS tout en observant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité. Nous espérons qu'il y aura davantage de travaux académiques pour réguler PeerDAS et ses interactions avec des problèmes tels que la sécurité des règles de choix de fork.
L'avenir nécessite également de déterminer la version idéale du 2D DAS et de prouver ses attributs de sécurité. Nous espérons finalement pouvoir passer du KZG à des solutions alternatives qui soient sécurisées quantiquement et ne nécessitent pas de configuration de confiance. Actuellement, il n'est pas clair quelles sont les solutions candidates qui sont compatibles avec la construction de blocs distribués.
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 accepter une limite de données inférieure pour la simplicité et la robustesse.
Abandonner DA et accepter complètement Plasma comme principale architecture Layer 2.
Même si nous décidons d'étendre l'exécution directement au niveau L1, cette option existe. Car si L1 doit traiter un grand nombre de TPS, les blocs L1 deviendront très volumineux, et les clients auront besoin de méthodes de vérification efficaces, donc nous devrons utiliser la même technologie au niveau L1 que celle utilisée pour les Rollups.
Comment interagir avec les autres parties de la feuille de route ?
Si la compression des données est réalisée, la demande pour les DAS 2D diminuera ou sera retardée, et si Plasma est largement utilisé, la demande diminuera encore davantage. Les DAS posent également des défis aux protocoles et mécanismes de construction de blocs distribués : bien que les DAS soient théoriquement amicaux pour la reconstruction distribuée, en pratique, ils doivent être combinés avec la proposition de liste d'inclusion de paquets et les mécanismes de choix de bifurcation qui l'entourent.
Compression des données
Quel problème résolvons-nous ?
Chaque transaction dans un Rollup occupe une grande quantité d'espace de données on-chain : 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 Layer. Chaque slot fait 16 Mo, nous obtenons :
16000000 / 12 / 180 = 7407 TPS
Que se passerait-il si nous pouvions faire en sorte que les transactions dans le Rollup occupent moins de bytes sur la chaîne?
Qu'est-ce que c'est, comment ça fonctionne ?
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 tiré parti des propriétés spécifiques des transactions :
Agrégation de signatures : Passage des signatures ECDSA aux signatures BLS, plusieurs signatures peuvent être combinées en une seule signature, prouvant la validité de toutes les signatures originales. Dans L1, l'utilisation de BLS n'est pas envisagée en raison du coût élevé des calculs de vérification, mais dans L2, un environnement où les données sont rares, l'utilisation de BLS a du sens. La fonctionnalité d'agrégation d'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 ETH est représenté par 250 000 000 000 000 000 wei. Les frais de base maximum et les frais prioritaires sont également similaires. Ainsi, nous pouvons utiliser un format décimal flottant personnalisé pour représenter la plupart des valeurs monétaires.
Quels sont les liens avec les recherches existantes?
Explorer sequence.xyz
Optimisation des contrats L2 Calldata
Différences d'état de publication des Rollups basées sur la preuve d'efficacité plutôt que sur les transactions
Portefeuille BLS - Agrégation BLS via ERC-4337
Que faut-il encore faire, quels sont les compromis ?
La suite concerne principalement la mise en œuvre pratique du plan ci-dessus. Les principaux compromis incluent :
Passer à la signature BLS nécessite beaucoup d'efforts et réduira la compatibilité avec les puces matérielles de confiance. Des emballages ZK-SNARK utilisant d'autres schémas de signature peuvent être utilisés en remplacement.
La compression dynamique de (, si l'on remplace 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 la capacité d'audit, rendant de nombreux logiciels ( comme les explorateurs de blocs ) incapables de fonctionner.
Comment interagir avec les autres parties de la feuille de route ?
En adoptant l'ERC-4337 et en intégrant finalement une partie de celui-ci dans l'EVM L2, cela peut considérablement accélérer le déploiement de la technologie d'agrégation. Placer une partie de l'ERC-4337 sur L1 peut accélérer son déploiement sur L2.
Plasma généralisé
Nous résolvons quel problème ?
Même avec un blob de 16 Mo et la compression des données, 58 000 TPS ne peuvent pas nécessairement satisfaire complètement les besoins des consommateurs dans des domaines à haute bande passante tels que les paiements et les réseaux sociaux décentralisés, surtout si l'on considère que des facteurs de confidentialité peuvent réduire la scalabilité de 3 à 8 fois. Actuellement, le choix pour des scénarios à fort volume de transactions et à faible valeur est Validium, qui conserve les données hors chaîne, utilisant un modèle de sécurité : les opérateurs ne peuvent pas voler les fonds des utilisateurs, mais peuvent temporairement ou définitivement geler tous les fonds des utilisateurs. Cependant, nous pouvons faire mieux.
Qu'est-ce que c'est, comment ça fonctionne ?
Plasma est une solution d'évolutivité, les opérateurs publient des blocs hors chaîne et ne mettent en ligne que la racine Merkle de ces blocs. Pour chaque bloc, l'opérateur envoie à chaque utilisateur une preuve de branche Merkle montrant les changements ou la stabilité des actifs de cet utilisateur. Les utilisateurs peuvent extraire des actifs en fournissant la branche Merkle. Il est important que cette branche n'ait pas besoin d'être à jour pour être valide. Ainsi, même si la disponibilité des données pose problème, les utilisateurs peuvent toujours récupérer leurs actifs en extrayant l'état le plus récent disponible. Si un utilisateur soumet une branche invalide, la propriété des actifs peut être déterminée par le mécanisme de défi en chaîne.
Les premières versions de Plasma ne pouvaient traiter que des cas d'utilisation de paiement, ce qui rendait leur diffusion inefficace. Mais
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.
Ethereum The Surge : Objectif et défis d'une capacité de 100 000 TPS grâce à L2
L'avenir possible d'Ethereum : The Surge
La stratégie d'extension d'Ethereum avait initialement deux voies : le sharding et Layer2. Le sharding permet à chaque nœud de ne valider et de stocker qu'une petite partie des transactions, tandis que Layer2 déplace la plupart des données et des calculs en dehors de la chaîne principale. Ces deux voies 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 le Rollup propose une division 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 assume la tâche d'aider l'écosystème à s'étendre. Ce modèle est courant dans la société : le système judiciaire (L1) existe pour protéger les contrats et les droits de propriété, tandis que les entrepreneurs (L2) construisent dessus, propulsant le développement humain.
Cette année, la feuille de route axée sur les Rollups a obtenu des résultats importants : le lancement des blobs EIP-4844 a considérablement augmenté la bande passante des données d'Ethereum L1, et plusieurs Rollups EVM ont atteint la première phase. Chaque L2 existe en tant que "fragment" avec des règles et logiques internes. La diversité des méthodes de mise en œuvre des fragments est désormais une réalité. Mais ce chemin fait également face à des défis uniques. Notre tâche actuelle est de compléter cette feuille de route et de résoudre ces problèmes tout en maintenant la robustesse et la décentralisation d'Ethereum L1.
The Surge: Objectifs clés
Contenu de ce chapitre
Paradoxe du triangle de la scalabilité
Le paradoxe du triangle de la scalabilité soutient qu'il existe une contradiction entre les trois caractéristiques de la décentralisation, de la scalabilité et de la sécurité des blockchains. Ce n'est pas un théorème, mais cela propose un argument 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 des nœuds, soit vos nœuds deviendront puissants et la chaîne ne sera pas décentralisée.
Certaines chaînes haute performance prétendent résoudre le paradoxe trilemme, généralement en optimisant le logiciel des nœuds. Mais cela est souvent trompeur, car faire fonctionner des nœuds sur ces chaînes est plus difficile que sur Ethereum. L'ingénierie logicielle des clients L1 à elle seule ne peut pas faire évoluer Ethereum.
Cependant, la combinaison de l'échantillonnage de disponibilité des données et des SNARKs résout effectivement le paradoxe du triangle : elle permet aux clients de vérifier la disponibilité d'une grande quantité de données et l'exécution correcte des étapes de calcul 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 disponibilité des données a un modèle de confiance subtil few-of-N, mais conserve les caractéristiques fondamentales des chaînes non extensibles.
L'architecture Plasma est une autre solution qui confie aux utilisateurs la responsabilité de surveiller la disponibilité des données. Avec la popularité des SNARKs, Plasma devient viable pour un plus large éventail de scénarios.
Progrès supplémentaires sur l'échantillonnage de la disponibilité des données
Nous résolvons quel problème ?
Après la mise à niveau Dencun le 13 mars 2024, Ethereum aura 3 blobs d'environ 125 Ko par slot toutes les 12 secondes, avec une bande passante de données disponible d'environ 375 Ko/slot. Supposons que les données de transaction soient directement publiées sur la chaîne, un transfert ERC20 fait environ 180 octets, alors le maximum de TPS pour les Rollups sur Ethereum sera de 173,6.
Avec les données de calldatas, on peut atteindre 607 TPS. En utilisant PeerDAS, le nombre de blobs peut augmenter à 8-16, fournissant 463-926 TPS pour les calldatas.
C'est une amélioration majeure pour L1, mais ce n'est pas suffisant. Notre objectif à moyen terme est de 16 Mo par slot, combiné à la compression des données Rollup, ce qui permettra d'atteindre ~58000 TPS.
Qu'est-ce que c'est ? Comment ça fonctionne ?
PeerDAS est une implémentation simple de "1D sampling". Dans Ethereum, chaque blob est un polynôme de degré 4096 sur un corps premier de 253 bits. Nous diffusons les parts du polynôme, chaque part contenant 16 évaluations de 16 coordonnées adjacentes parmi un total de 8192 coordonnées. Parmi ces 8192 évaluations, n'importe quel ensemble de 4096 peut restaurer le blob.
PeerDAS permet à chaque client d'écouter un petit nombre de sous-réseaux, le ième sous-réseau diffuse le ième échantillon de tout blob et demande des blobs sur d'autres sous-réseaux en interrogeant les pairs dans le réseau p2p mondial. SubnetDAS utilise uniquement la mécanique des sous-réseaux, sans interroger de couche de pair supplémentaire. La proposition actuelle permet aux nœuds participant à la preuve de participation d'utiliser SubnetDAS, tandis que les autres nœuds utilisent PeerDAS.
Théoriquement, nous pouvons étendre l'échelle du "1D sampling" très largement : si nous augmentons le nombre maximal de blobs à 256, nous pouvons atteindre l'objectif de 16 Mo, chaque nœud nécessitant 1 Mo de bande passante de données par slot. Cela est à peine réalisable, mais les clients avec une bande passante limitée ne peuvent pas échantillonner. Nous pouvons optimiser en réduisant le nombre de blobs et en augmentant la taille des blobs, mais cela augmentera le coût de reconstruction.
Ainsi, nous voulons finalement effectuer un échantillonnage 2D, non seulement à l'intérieur des blobs, mais également entre les blobs. En utilisant les propriétés linéaires des engagements KZG, nous étendons l'ensemble de blobs dans un bloc par de nouveaux blobs virtuels, ces blobs virtuels encodent redondamment la même information.
L'échantillonnage 2D est favorable à la construction de blocs distribués. Les nœuds qui construisent effectivement des blocs n'ont besoin que d'un engagement KZG blob et peuvent compter sur le DAS pour vérifier la disponibilité. Le DAS 1D est également fondamentalement favorable à la construction de blocs distribués.
Quels sont les liens avec les recherches existantes?
que faut-il encore faire ? Quels sont les compromis ?
La prochaine étape est de finaliser l'implémentation et le lancement de PeerDAS. Ensuite, augmenter continuellement le nombre de blobs sur PeerDAS tout en observant attentivement le réseau et en améliorant le logiciel pour garantir la sécurité. Nous espérons qu'il y aura davantage de travaux académiques pour réguler PeerDAS et ses interactions avec des problèmes tels que la sécurité des règles de choix de fork.
L'avenir nécessite également de déterminer la version idéale du 2D DAS et de prouver ses attributs de sécurité. Nous espérons finalement pouvoir passer du KZG à des solutions alternatives qui soient sécurisées quantiquement et ne nécessitent pas de configuration de confiance. Actuellement, il n'est pas clair quelles sont les solutions candidates qui sont compatibles avec la construction de blocs distribués.
Je pense que le chemin de réalité à long terme est :
Même si nous décidons d'étendre l'exécution directement au niveau L1, cette option existe. Car si L1 doit traiter un grand nombre de TPS, les blocs L1 deviendront très volumineux, et les clients auront besoin de méthodes de vérification efficaces, donc nous devrons utiliser la même technologie au niveau L1 que celle utilisée pour les Rollups.
Comment interagir avec les autres parties de la feuille de route ?
Si la compression des données est réalisée, la demande pour les DAS 2D diminuera ou sera retardée, et si Plasma est largement utilisé, la demande diminuera encore davantage. Les DAS posent également des défis aux protocoles et mécanismes de construction de blocs distribués : bien que les DAS soient théoriquement amicaux pour la reconstruction distribuée, en pratique, ils doivent être combinés avec la proposition de liste d'inclusion de paquets et les mécanismes de choix de bifurcation qui l'entourent.
Compression des données
Quel problème résolvons-nous ?
Chaque transaction dans un Rollup occupe une grande quantité d'espace de données on-chain : 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 Layer. Chaque slot fait 16 Mo, nous obtenons :
16000000 / 12 / 180 = 7407 TPS
Que se passerait-il si nous pouvions faire en sorte que les transactions dans le Rollup occupent moins de bytes sur la chaîne?
Qu'est-ce que c'est, comment ça fonctionne ?
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 tiré parti des propriétés spécifiques des transactions :
Agrégation de signatures : Passage des signatures ECDSA aux signatures BLS, plusieurs signatures peuvent être combinées en une seule signature, prouvant la validité de toutes les signatures originales. Dans L1, l'utilisation de BLS n'est pas envisagée en raison du coût élevé des calculs de vérification, mais dans L2, un environnement où les données sont rares, l'utilisation de BLS a du sens. La fonctionnalité d'agrégation d'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 ETH est représenté par 250 000 000 000 000 000 wei. Les frais de base maximum et les frais prioritaires sont également similaires. Ainsi, nous pouvons utiliser un format décimal flottant personnalisé pour représenter la plupart des valeurs monétaires.
Quels sont les liens avec les recherches existantes?
Que faut-il encore faire, quels sont les compromis ?
La suite concerne principalement la mise en œuvre pratique du plan ci-dessus. Les principaux compromis incluent :
Passer à la signature BLS nécessite beaucoup d'efforts et réduira la compatibilité avec les puces matérielles de confiance. Des emballages ZK-SNARK utilisant d'autres schémas de signature peuvent être utilisés en remplacement.
La compression dynamique de (, si l'on remplace 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 la capacité d'audit, rendant de nombreux logiciels ( comme les explorateurs de blocs ) incapables de fonctionner.
Comment interagir avec les autres parties de la feuille de route ?
En adoptant l'ERC-4337 et en intégrant finalement une partie de celui-ci dans l'EVM L2, cela peut considérablement accélérer le déploiement de la technologie d'agrégation. Placer une partie de l'ERC-4337 sur L1 peut accélérer son déploiement sur L2.
Plasma généralisé
Nous résolvons quel problème ?
Même avec un blob de 16 Mo et la compression des données, 58 000 TPS ne peuvent pas nécessairement satisfaire complètement les besoins des consommateurs dans des domaines à haute bande passante tels que les paiements et les réseaux sociaux décentralisés, surtout si l'on considère que des facteurs de confidentialité peuvent réduire la scalabilité de 3 à 8 fois. Actuellement, le choix pour des scénarios à fort volume de transactions et à faible valeur est Validium, qui conserve les données hors chaîne, utilisant un modèle de sécurité : les opérateurs ne peuvent pas voler les fonds des utilisateurs, mais peuvent temporairement ou définitivement geler tous les fonds des utilisateurs. Cependant, nous pouvons faire mieux.
Qu'est-ce que c'est, comment ça fonctionne ?
Plasma est une solution d'évolutivité, les opérateurs publient des blocs hors chaîne et ne mettent en ligne que la racine Merkle de ces blocs. Pour chaque bloc, l'opérateur envoie à chaque utilisateur une preuve de branche Merkle montrant les changements ou la stabilité des actifs de cet utilisateur. Les utilisateurs peuvent extraire des actifs en fournissant la branche Merkle. Il est important que cette branche n'ait pas besoin d'être à jour pour être valide. Ainsi, même si la disponibilité des données pose problème, les utilisateurs peuvent toujours récupérer leurs actifs en extrayant l'état le plus récent disponible. Si un utilisateur soumet une branche invalide, la propriété des actifs peut être déterminée par le mécanisme de défi en chaîne.
Les premières versions de Plasma ne pouvaient traiter que des cas d'utilisation de paiement, ce qui rendait leur diffusion inefficace. Mais