Analyse de la mise à niveau technologique d'Ethereum The Surge
Depuis octobre de cette année, le cofondateur d'Ethereum a publié une série d'articles sur les possibilités futures du protocole Ethereum, couvrant six parties de la feuille de route de développement d'Ethereum. Cet article interprétera la deuxième partie de cette série, The Surge, en se concentrant sur l'évolutivité d'Ethereum et son développement à long terme. À partir de la feuille de route technique de cette phase, nous pouvons mieux comprendre comment Ethereum va se transformer en un protocole capable de gérer une demande énorme (TPS atteignant 100,000+), tout en maintenant la décentralisation et la sécurité.
Vision centrale d'Ethereum
En essence, Ethereum vise à devenir la couche de base de l'internet décentralisé. L'Éther soutient des applications décentralisées complexes grâce à des contrats intelligents exécutés automatiquement, cette flexibilité en fait la blockchain de choix pour les développeurs construisant des applications décentralisées, y compris DeFi, NFT, etc.
Cependant, Ethereum présente des limitations en matière d'évolutivité. Ethereum L1 ne peut traiter qu'environ 15 à 30 transactions par seconde, ce qui laisse un écart considérable par rapport aux réseaux de paiement traditionnels. Cela entraîne des frais de gas élevés pendant les périodes de congestion du réseau et limite la capacité d'Ethereum à devenir une infrastructure à l'échelle mondiale. C'est précisément le problème que The Surge vise à résoudre.
Les principaux objectifs de The Surge sont les suivants :
Ethereum L1+L2 atteint 100 000+ TPS ;
Maintenir la décentralisation et la robustesse de L1 ;
Au moins certains L2 héritent complètement des propriétés fondamentales d'Ethereum (sans confiance, ouvert, résistant à la censure) ;
Maximiser l'interopérabilité entre les L2 : Ethereum devrait agir comme un écosystème, et non comme des dizaines de blockchains différentes.
Un avenir centré sur les rollups
La Surge fait référence au plan d'Ethereum d'augmenter considérablement sa scalabilité, principalement par le biais de solutions L2. Le rollup est un élément clé de cette stratégie. La feuille de route centrée sur le rollup propose une division du travail simple : 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.
Le Rollup regroupe les transactions hors chaîne, puis les soumet au réseau principal Ethereum, tout en maintenant la sécurité et la décentralisation, tout en augmentant considérablement le débit. Le rollup peut améliorer l'évolutivité d'Ethereum à plus de 100 000 TPS. Ce sera une extension transformative, car elle permet à Ethereum de traiter des applications à l'échelle mondiale sans compromettre l'esprit de décentralisation.
La feuille de route centrée sur les rollups est considérée comme une solution d'extension à long terme. Ethereum 2.0 a réduit la consommation d'énergie en passant de PoW à PoS grâce à The Merge, tandis que les rollups, en tant que solution d'extension à long terme, sont considérés comme le prochain jalon important.
Cette année, la feuille de route centrée sur les rollups a obtenu des résultats importants : avec le lancement des blobs EIP-4844, la bande passante des données de l'Ethereum L1 a considérablement augmenté, et plusieurs rollups de la machine virtuelle Ethereum (EVM) sont entrés dans la première phase. Chaque L2 existe en tant que shard avec ses propres règles et logiques internes, et la diversité et la pluralité des méthodes de mise en œuvre des shards sont désormais une réalité.
Échantillonnage de la disponibilité des données (DAS) développement supplémentaire
Un autre aspect clé de The Surge est l'échantillonnage de disponibilité des données (DAS), qui est une technologie conçue pour résoudre les problèmes de disponibilité des données. Dans des réseaux décentralisés comme Ethereum, il est essentiel que tous les nœuds puissent vérifier les données sans avoir besoin de stocker ou de télécharger tout le contenu.
DAS permet aux nœuds de vérifier les données sans accéder à l'ensemble des données, améliorant ainsi la scalabilité et l'efficacité.
Il existe deux formes de DAS : PeerDAS et 2D DAS. PeerDAS devrait renforcer l'hypothèse de confiance dans le rollup, le rendant ainsi plus sécurisé. Le 2D DAS effectue un échantillonnage aléatoire non seulement à l'intérieur du blob mais aussi entre les blobs. En utilisant les propriétés linéaires des engagements KZG, un ensemble de nouveaux blobs virtuels est utilisé pour étendre l'ensemble de blobs d'un bloc, ces blobs virtuels encodant les mêmes informations redondantes.
Grâce à DAS, Ethereum peut traiter un plus grand volume de données, permettant ainsi des rollups plus rapides et moins coûteux, sans compromettre la décentralisation.
À un stade futur plus avancé, il sera nécessaire de faire davantage de travail pour déterminer la version idéale de DAS 2D et prouver ses attributs de sécurité.
Le chemin de réalité à long terme est :
Mettre en œuvre un DAS 2D idéal ;
S'en tenir à 1D DAS, sacrifier l'efficacité de la bande passante d'échantillonnage, accepter une limite de données inférieure pour la simplicité et la robustesse ;
Abandonner DA et accepter complètement Plasma comme principale architecture Layer2.
Il est important de noter que même si l'on décide d'étendre l'exécution directement 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 exactitude, ils devront donc utiliser au niveau L1 les mêmes techniques que celles utilisées pour les rollups (comme ZK-EVM et DAS).
Plasma et autres solutions
En plus de Rollup, l'une des premières solutions d'extension hors chaîne proposées, Plasma est également une autre solution L2.
La création de sous-chaînes Plasma, qui traitent les transactions indépendamment de la chaîne principale Ethereum, soumet régulièrement des résumés à la chaîne principale. Pour chaque bloc, l'opérateur envoie à chaque utilisateur une branche Merkle pour prouver l'état de changement des actifs de cet utilisateur. 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 à l'état le plus récent.
Ainsi, même en cas de problèmes de disponibilité des données, 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 (par exemple, en extrayant des actifs qui ont déjà été envoyés à d'autres, ou si l'opérateur a lui-même créé un actif de toutes pièces), la légitimité de la propriété des actifs peut être déterminée par le mécanisme de défi sur la chaîne.
Bien que le développement de Plasma soit en retard par rapport aux rollups dans une certaine mesure, il est toujours considéré comme faisant partie de la boîte à outils d'évolutivité plus large d'Ethereum.
De plus, il y a des discussions sur l'amélioration des techniques de compression de données et de preuve cryptographique, afin d'augmenter l'efficacité des rollups et d'autres solutions L2. L'idée est de compresser autant de données que possible tout en s'assurant que toutes les informations nécessaires restent disponibles pour la validation par les nœuds Ethereum. Ces améliorations techniques joueront probablement un rôle clé dans le processus d'atteinte d'un débit plus élevé pour Ethereum.
Les premières versions de Plasma ne pouvaient traiter que des cas de paiement, ce qui rendait leur diffusion plus difficile. Cependant, si chaque racine doit être vérifiée par SNARK, alors Plasma deviendrait beaucoup plus puissant. Son processus peut être considérablement simplifié, car la plupart des chemins possibles de tricherie des opérateurs sont exclus. En même temps, de nouveaux chemins s'ouvrent, c'est-à-dire que les utilisateurs peuvent retirer immédiatement des fonds sans avoir à attendre une période de contestation d'une semaine, tant que l'opérateur ne triche pas.
Une des méthodes (et non la seule) pour créer une chaîne plasma EVM est : utiliser ZK-SNARK pour construire un arbre UTXO parallèle, reflétant les changements de solde effectués par l'EVM, définissant un mappage unique de "la même pièce" à différentes périodes de l'histoire. La structure Plasma peut ensuite être construite sur cette base.
Les performances de Plasma sont assez bonnes, c'est aussi la raison clé pour laquelle tout le monde doit concevoir des structures techniques pour surmonter ses insuffisances en matière de sécurité.
Amélioration de l'interopérabilité inter-L2
Un des principaux défis auxquels fait face l'écosystème L2 d'aujourd'hui est la faible interopérabilité entre les L2. Il est urgent d'améliorer la manière dont l'utilisation de l'écosystème L2 ressemble à celle d'un écosystème Ethereum unifié.
Il existe de nombreuses catégories d'améliorations de l'interopérabilité entre les L2. En théorie, Ethereum centré sur les Rollups est similaire à un L1 avec des shards d'exécution. L'écosystème actuel des L2 d'Ethereum rencontre encore les problèmes suivants dans la pratique :
Adresse de la chaîne spécifique : l'adresse doit contenir des informations sur la chaîne (L1, Optimism, Arbitrum......). Une fois cela réalisé, il est possible de mettre en œuvre le processus d'envoi inter-L2 simplement en plaçant l'adresse dans le champ d'envoi, à ce moment-là, le portefeuille peut gérer en arrière-plan comment envoyer (y compris l'utilisation de protocoles inter-chaînes).
Demande de paiement sur une chaîne spécifique : il devrait être facile et standardisé de créer un message sous la forme "envoyez-moi X jetons de type Y sur la chaîne Z". Cela a principalement deux cas d'utilisation : le paiement entre personnes ou le paiement entre une personne et un service marchand ; demande de fonds par dApp.
Échange inter-chaînes et paiement de Gas : il devrait y avoir un protocole ouvert et standardisé pour exprimer les opérations inter-chaînes. ERC-7683 et RIP-7755 tentent dans ce domaine, bien que l'application de ces deux soit plus large que ces cas d'utilisation spécifiques.
Client léger : les utilisateurs devraient être capables de vérifier réellement la chaîne avec laquelle ils interagissent, et pas seulement faire confiance aux fournisseurs RPC. ERC-3668 (CCIP-read) est une stratégie pour atteindre cet objectif.
Concept de pont de tokens partagés : Supposons que dans un monde où tous les L2 sont des rollups à preuve de validité, et où chaque slot est soumis à Ethereum, pour transférer un actif d'un L2 à un autre dans son état natif, il est toujours nécessaire de retirer et de déposer, ce qui nécessite de payer de lourds frais de Gas L1.
Une manière de résoudre ce problème est de créer un Rollup minimal partagé, dont la seule fonction est de maintenir quel L2 possède quel type de jeton et combien de solde chacun possède, et de permettre à ces soldes d'être mis à jour par lot via une série d'opérations d'envoi inter-L2 initiées par n'importe quel L2. Cela permettra des transferts inter-L2 sans avoir à payer des frais de gaz L1 à chaque transfert, ni à utiliser des technologies basées sur des fournisseurs de liquidité comme l'ERC-7683.
Synchronicité composite : permet d'effectuer des appels synchrones entre un L2 spécifique et un L1 ou entre plusieurs L2. Cela contribue à améliorer l'efficacité financière des protocoles DeFi. Le premier peut être réalisé sans aucune coordination entre L2 ; le second nécessite un tri partagé. Les technologies basées sur le rollup s'appliquent automatiquement à toutes ces technologies.
De nombreux exemples ci-dessus font face au dilemme de savoir quand standardiser et quels niveaux de standardisation adopter. Si la standardisation est trop précoce, elle risque de rendre une solution médiocre profondément ancrée. Si la standardisation est trop tardive, cela peut entraîner une fragmentation inutile.
Un consensus actuel est le suivant : dans certains cas, il existe une solution à court terme qui est moins complexe mais plus facile à mettre en œuvre, ainsi qu'une solution à long terme qui est "finalement correcte" mais qui nécessite des années pour être réalisée. Ces tâches ne sont pas seulement des questions techniques, elles sont aussi (et peuvent-être principalement) des questions sociales, nécessitant une collaboration entre L2, portefeuilles et L1.
Continuer à étendre Ethereum L1
Il est très précieux d'étendre Ethereum L1 lui-même et de s'assurer qu'il peut continuer à accueillir un nombre croissant de cas d'utilisation.
Les stratégies d'extension L1 sont au nombre de trois, et peuvent être mises en œuvre individuellement ou en parallèle :
Améliorer la technologie (par exemple, le code du client, le client sans état, l'expiration historique) pour faciliter la vérification de L1, puis augmenter la limite de Gas ;
Réduire le coût des opérations spécifiques tout en augmentant la capacité moyenne sans accroître le risque du pire scénario ;
Rollups natifs (c'est-à-dire, créer N copies parallèles de l'EVM).
Ces différentes technologies ont chacune leurs compromis. Par exemple, les rollups natifs présentent la même faiblesse en termes de combinabilité que les rollups ordinaires : il n'est pas possible d'envoyer une seule transaction pour exécuter des opérations de manière synchronisée à travers plusieurs rollups. Augmenter la limite de Gas peut affaiblir d'autres avantages réalisables grâce à la simplification de la vérification L1, comme l'augmentation du pourcentage d'utilisateurs exécutant des nœuds de validation et l'augmentation du nombre de validateurs solo. Selon la manière dont cela est implémenté, rendre certaines opérations moins chères dans l'EVM peut accroître la complexité globale de l'EVM.
Décentralisation et sécurité
L'équilibre entre l'évolutivité et la décentralisation est l'un des thèmes souvent évoqués. De nombreux projets de blockchain choisissent de sacrifier la décentralisation au profit d'un débit plus élevé. Par exemple, une blockchain chaque
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.
12 J'aime
Récompense
12
7
Partager
Commentaire
0/400
DiamondHands
· 07-25 01:37
Encore à parler de tps, sigh
Voir l'originalRépondre0
0xSoulless
· 07-23 21:11
tps continue à hausser, ce sont des pigeons qui cuisinent.
Voir l'originalRépondre0
WenAirdrop
· 07-22 23:20
tps si élevé, je n'ai jamais vu ça
Voir l'originalRépondre0
FloorSweeper
· 07-22 08:45
mains faibles croient toujours en eth lmao
Voir l'originalRépondre0
CryptoFortuneTeller
· 07-22 08:45
Ça y est, l'eth peut encore atteindre 100k tps.
Voir l'originalRépondre0
MrRightClick
· 07-22 08:31
À peine 10 000 tps ? Ce n'est vraiment pas suffisant.
Voir l'originalRépondre0
AirdropHunterWang
· 07-22 08:30
C'est tout ce qu'il faut faire, j'attends que les frais de gas baissent un peu.
Mise à niveau d'Ethereum The Surge : le chemin d'extension vers l'objectif de plus de 100 000 TPS
Analyse de la mise à niveau technologique d'Ethereum The Surge
Depuis octobre de cette année, le cofondateur d'Ethereum a publié une série d'articles sur les possibilités futures du protocole Ethereum, couvrant six parties de la feuille de route de développement d'Ethereum. Cet article interprétera la deuxième partie de cette série, The Surge, en se concentrant sur l'évolutivité d'Ethereum et son développement à long terme. À partir de la feuille de route technique de cette phase, nous pouvons mieux comprendre comment Ethereum va se transformer en un protocole capable de gérer une demande énorme (TPS atteignant 100,000+), tout en maintenant la décentralisation et la sécurité.
Vision centrale d'Ethereum
En essence, Ethereum vise à devenir la couche de base de l'internet décentralisé. L'Éther soutient des applications décentralisées complexes grâce à des contrats intelligents exécutés automatiquement, cette flexibilité en fait la blockchain de choix pour les développeurs construisant des applications décentralisées, y compris DeFi, NFT, etc.
Cependant, Ethereum présente des limitations en matière d'évolutivité. Ethereum L1 ne peut traiter qu'environ 15 à 30 transactions par seconde, ce qui laisse un écart considérable par rapport aux réseaux de paiement traditionnels. Cela entraîne des frais de gas élevés pendant les périodes de congestion du réseau et limite la capacité d'Ethereum à devenir une infrastructure à l'échelle mondiale. C'est précisément le problème que The Surge vise à résoudre.
Les principaux objectifs de The Surge sont les suivants :
Un avenir centré sur les rollups
La Surge fait référence au plan d'Ethereum d'augmenter considérablement sa scalabilité, principalement par le biais de solutions L2. Le rollup est un élément clé de cette stratégie. La feuille de route centrée sur le rollup propose une division du travail simple : 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.
Le Rollup regroupe les transactions hors chaîne, puis les soumet au réseau principal Ethereum, tout en maintenant la sécurité et la décentralisation, tout en augmentant considérablement le débit. Le rollup peut améliorer l'évolutivité d'Ethereum à plus de 100 000 TPS. Ce sera une extension transformative, car elle permet à Ethereum de traiter des applications à l'échelle mondiale sans compromettre l'esprit de décentralisation.
La feuille de route centrée sur les rollups est considérée comme une solution d'extension à long terme. Ethereum 2.0 a réduit la consommation d'énergie en passant de PoW à PoS grâce à The Merge, tandis que les rollups, en tant que solution d'extension à long terme, sont considérés comme le prochain jalon important.
Cette année, la feuille de route centrée sur les rollups a obtenu des résultats importants : avec le lancement des blobs EIP-4844, la bande passante des données de l'Ethereum L1 a considérablement augmenté, et plusieurs rollups de la machine virtuelle Ethereum (EVM) sont entrés dans la première phase. Chaque L2 existe en tant que shard avec ses propres règles et logiques internes, et la diversité et la pluralité des méthodes de mise en œuvre des shards sont désormais une réalité.
Échantillonnage de la disponibilité des données (DAS) développement supplémentaire
Un autre aspect clé de The Surge est l'échantillonnage de disponibilité des données (DAS), qui est une technologie conçue pour résoudre les problèmes de disponibilité des données. Dans des réseaux décentralisés comme Ethereum, il est essentiel que tous les nœuds puissent vérifier les données sans avoir besoin de stocker ou de télécharger tout le contenu.
DAS permet aux nœuds de vérifier les données sans accéder à l'ensemble des données, améliorant ainsi la scalabilité et l'efficacité.
Il existe deux formes de DAS : PeerDAS et 2D DAS. PeerDAS devrait renforcer l'hypothèse de confiance dans le rollup, le rendant ainsi plus sécurisé. Le 2D DAS effectue un échantillonnage aléatoire non seulement à l'intérieur du blob mais aussi entre les blobs. En utilisant les propriétés linéaires des engagements KZG, un ensemble de nouveaux blobs virtuels est utilisé pour étendre l'ensemble de blobs d'un bloc, ces blobs virtuels encodant les mêmes informations redondantes.
Grâce à DAS, Ethereum peut traiter un plus grand volume de données, permettant ainsi des rollups plus rapides et moins coûteux, sans compromettre la décentralisation.
À un stade futur plus avancé, il sera nécessaire de faire davantage de travail pour déterminer la version idéale de DAS 2D et prouver ses attributs de sécurité.
Le chemin de réalité à long terme est :
Il est important de noter que même si l'on décide d'étendre l'exécution directement 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 exactitude, ils devront donc utiliser au niveau L1 les mêmes techniques que celles utilisées pour les rollups (comme ZK-EVM et DAS).
Plasma et autres solutions
En plus de Rollup, l'une des premières solutions d'extension hors chaîne proposées, Plasma est également une autre solution L2.
La création de sous-chaînes Plasma, qui traitent les transactions indépendamment de la chaîne principale Ethereum, soumet régulièrement des résumés à la chaîne principale. Pour chaque bloc, l'opérateur envoie à chaque utilisateur une branche Merkle pour prouver l'état de changement des actifs de cet utilisateur. 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 à l'état le plus récent.
Ainsi, même en cas de problèmes de disponibilité des données, 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 (par exemple, en extrayant des actifs qui ont déjà été envoyés à d'autres, ou si l'opérateur a lui-même créé un actif de toutes pièces), la légitimité de la propriété des actifs peut être déterminée par le mécanisme de défi sur la chaîne.
Bien que le développement de Plasma soit en retard par rapport aux rollups dans une certaine mesure, il est toujours considéré comme faisant partie de la boîte à outils d'évolutivité plus large d'Ethereum.
De plus, il y a des discussions sur l'amélioration des techniques de compression de données et de preuve cryptographique, afin d'augmenter l'efficacité des rollups et d'autres solutions L2. L'idée est de compresser autant de données que possible tout en s'assurant que toutes les informations nécessaires restent disponibles pour la validation par les nœuds Ethereum. Ces améliorations techniques joueront probablement un rôle clé dans le processus d'atteinte d'un débit plus élevé pour Ethereum.
Les premières versions de Plasma ne pouvaient traiter que des cas de paiement, ce qui rendait leur diffusion plus difficile. Cependant, si chaque racine doit être vérifiée par SNARK, alors Plasma deviendrait beaucoup plus puissant. Son processus peut être considérablement simplifié, car la plupart des chemins possibles de tricherie des opérateurs sont exclus. En même temps, de nouveaux chemins s'ouvrent, c'est-à-dire que les utilisateurs peuvent retirer immédiatement des fonds sans avoir à attendre une période de contestation d'une semaine, tant que l'opérateur ne triche pas.
Une des méthodes (et non la seule) pour créer une chaîne plasma EVM est : utiliser ZK-SNARK pour construire un arbre UTXO parallèle, reflétant les changements de solde effectués par l'EVM, définissant un mappage unique de "la même pièce" à différentes périodes de l'histoire. La structure Plasma peut ensuite être construite sur cette base.
Les performances de Plasma sont assez bonnes, c'est aussi la raison clé pour laquelle tout le monde doit concevoir des structures techniques pour surmonter ses insuffisances en matière de sécurité.
Amélioration de l'interopérabilité inter-L2
Un des principaux défis auxquels fait face l'écosystème L2 d'aujourd'hui est la faible interopérabilité entre les L2. Il est urgent d'améliorer la manière dont l'utilisation de l'écosystème L2 ressemble à celle d'un écosystème Ethereum unifié.
Il existe de nombreuses catégories d'améliorations de l'interopérabilité entre les L2. En théorie, Ethereum centré sur les Rollups est similaire à un L1 avec des shards d'exécution. L'écosystème actuel des L2 d'Ethereum rencontre encore les problèmes suivants dans la pratique :
Adresse de la chaîne spécifique : l'adresse doit contenir des informations sur la chaîne (L1, Optimism, Arbitrum......). Une fois cela réalisé, il est possible de mettre en œuvre le processus d'envoi inter-L2 simplement en plaçant l'adresse dans le champ d'envoi, à ce moment-là, le portefeuille peut gérer en arrière-plan comment envoyer (y compris l'utilisation de protocoles inter-chaînes).
Demande de paiement sur une chaîne spécifique : il devrait être facile et standardisé de créer un message sous la forme "envoyez-moi X jetons de type Y sur la chaîne Z". Cela a principalement deux cas d'utilisation : le paiement entre personnes ou le paiement entre une personne et un service marchand ; demande de fonds par dApp.
Échange inter-chaînes et paiement de Gas : il devrait y avoir un protocole ouvert et standardisé pour exprimer les opérations inter-chaînes. ERC-7683 et RIP-7755 tentent dans ce domaine, bien que l'application de ces deux soit plus large que ces cas d'utilisation spécifiques.
Client léger : les utilisateurs devraient être capables de vérifier réellement la chaîne avec laquelle ils interagissent, et pas seulement faire confiance aux fournisseurs RPC. ERC-3668 (CCIP-read) est une stratégie pour atteindre cet objectif.
Concept de pont de tokens partagés : Supposons que dans un monde où tous les L2 sont des rollups à preuve de validité, et où chaque slot est soumis à Ethereum, pour transférer un actif d'un L2 à un autre dans son état natif, il est toujours nécessaire de retirer et de déposer, ce qui nécessite de payer de lourds frais de Gas L1.
Une manière de résoudre ce problème est de créer un Rollup minimal partagé, dont la seule fonction est de maintenir quel L2 possède quel type de jeton et combien de solde chacun possède, et de permettre à ces soldes d'être mis à jour par lot via une série d'opérations d'envoi inter-L2 initiées par n'importe quel L2. Cela permettra des transferts inter-L2 sans avoir à payer des frais de gaz L1 à chaque transfert, ni à utiliser des technologies basées sur des fournisseurs de liquidité comme l'ERC-7683.
De nombreux exemples ci-dessus font face au dilemme de savoir quand standardiser et quels niveaux de standardisation adopter. Si la standardisation est trop précoce, elle risque de rendre une solution médiocre profondément ancrée. Si la standardisation est trop tardive, cela peut entraîner une fragmentation inutile.
Un consensus actuel est le suivant : dans certains cas, il existe une solution à court terme qui est moins complexe mais plus facile à mettre en œuvre, ainsi qu'une solution à long terme qui est "finalement correcte" mais qui nécessite des années pour être réalisée. Ces tâches ne sont pas seulement des questions techniques, elles sont aussi (et peuvent-être principalement) des questions sociales, nécessitant une collaboration entre L2, portefeuilles et L1.
Continuer à étendre Ethereum L1
Il est très précieux d'étendre Ethereum L1 lui-même et de s'assurer qu'il peut continuer à accueillir un nombre croissant de cas d'utilisation.
Les stratégies d'extension L1 sont au nombre de trois, et peuvent être mises en œuvre individuellement ou en parallèle :
Ces différentes technologies ont chacune leurs compromis. Par exemple, les rollups natifs présentent la même faiblesse en termes de combinabilité que les rollups ordinaires : il n'est pas possible d'envoyer une seule transaction pour exécuter des opérations de manière synchronisée à travers plusieurs rollups. Augmenter la limite de Gas peut affaiblir d'autres avantages réalisables grâce à la simplification de la vérification L1, comme l'augmentation du pourcentage d'utilisateurs exécutant des nœuds de validation et l'augmentation du nombre de validateurs solo. Selon la manière dont cela est implémenté, rendre certaines opérations moins chères dans l'EVM peut accroître la complexité globale de l'EVM.
Décentralisation et sécurité
L'équilibre entre l'évolutivité et la décentralisation est l'un des thèmes souvent évoqués. De nombreux projets de blockchain choisissent de sacrifier la décentralisation au profit d'un débit plus élevé. Par exemple, une blockchain chaque