! [Le pape Vitalinck Ier redéfinit la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-17bf55f5b7-dd1a6f-69ad2a.webp)
Un grand merci à Karl Floersch pour ses commentaires et sa critique
L’écosystème Ethereum Layer 2 s’est rapidement développé au cours de l’année écoulée. L’écosystème ZK-EVM Rollup, représenté par StarkNet, Arbitrum, Optimism et Scroll, a fait de grands progrès dans l’amélioration de la sécurité, et la page L2beat fournit un bon résumé de l’état de chaque projet. De plus, nous avons vu des équipes construire des sidechains commencer à construire des Rollups (Polygon), des projets de couche 1 essayer de migrer vers Validation (Celo) et faire de nouveaux efforts (Linea, Zeth, etc.).
En conséquence, les projets de couche 2 deviennent plus hétérogènes. Je m’attends à ce que cette tendance se poursuive pour les raisons suivantes :
Certains projets de couche 1 actuellement autonomes cherchent à se rapprocher de l’écosystème Ethereum et à devenir potentiellement de couche 2. **Ces projets peuvent nécessiter une transition graduelle. Changer maintenant entraînera une diminution de la facilité d’utilisation, car la technologie n’est pas prête à tout mettre sur le cumul ; Mais changer trop tard peut coûter de l’élan et il est trop tard pour avoir un sens.
Certains projets centralisés veulent offrir aux utilisateurs plus de garanties de sécurité et explorent des voies basées sur la blockchain. Dans de nombreux cas, ces projets peuvent déjà explorer des « chaînes de consortium autorisées ». En fait, ils n’ont peut-être besoin que d’un niveau de décentralisation « intermédiaire ». De plus, ils ont souvent un débit très élevé, ce qui les rend même pas adaptés aux rollups, du moins à court terme.
Les applications non financières, telles que les jeux ou les médias sociaux, veulent être décentralisées, mais n’ont besoin que d’une « couche intermédiaire » de sécurité. Les médias sociaux, par exemple, impliquent en fait que différentes parties de l’application sont traitées différemment : les activités à faible fréquence et à forte valeur ajoutée telles que l’enregistrement du nom d’utilisateur et la récupération de compte doivent être effectuées sur Rollup ; Les activités à haute fréquence et à faible valeur ajoutée, telles que la publication et l’interrogation, nécessitent moins de sécurité. Si votre message disparaît en raison d’une défaillance de la chaîne, c’est un prix acceptable ; Mais si la défaillance de la chaîne vous fait perdre votre compte, c’est un gros problème.
Un problème important est que le paiement de frais de cumul plus faibles, mais toujours visibles, est acceptable pour les applications et les utilisateurs d’Ethereum Layer 1 pour le moment, mais pas pour les utilisateurs en dehors du monde de la blockchain : si vous avez déjà payé 1 $, payer 0,10 $ est plus acceptable ; Mais si vous avez déjà payé 0 $, payer 0,10 $ est inacceptable. Cela s’applique à la fois aux applications centralisées actuelles et aux petits projets de couche 1, qui ont souvent des frais très bas avec une petite base d’utilisateurs.
La question qui se pose est la suivante : lequel de ces compromis complexes entre les cumuls, les validiums et d’autres systèmes est raisonnable pour une application particulière ?
Cumuls、Validiums、Déconnecté
La première dimension de la sécurité et de l’échelle que nous allons explorer peut être décrite comme suit : si vous possédez un actif qui a été émis sur la couche 1, puis déposé dans la couche 2, puis transféré sur votre compte, pouvez-vous être sûr que vous pouvez récupérer cet actif sur la couche 1 ? **
Dans le même temps, il y a une question similaire : quels sont les choix technologiques qui mènent à cette assurance, et quels sont les compromis derrière ces choix technologiques ? **
Nous pouvons simplement décrire le problème à l’aide d’un tableau :
! [Le pape Vitalinck Ier redéfinit la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-144dab5eab-dd1a6f-69ad2a.webp)
Il convient de mentionner qu’il s’agit d’une architecture simplifiée et qu’il existe de nombreux éléments intermédiaires parmi lesquels choisir. Par exemple:
Entre le cumul et le validium : un type de validium qui permet à quiconque d’effectuer des paiements on-chain pour couvrir les frais de transaction, auquel cas l’opérateur sera obligé de fournir certaines données à la chaîne ou de perdre le dépôt.
Entre Plasma et Validium : Le système Plasma offre des garanties de sécurité de type rollup et une disponibilité des données (DA) hors chaîne, mais ne prend en charge qu’un nombre limité d’applications. Un système peut fournir une EVM complète et fournir des garanties de niveau plasma aux utilisateurs qui n’utilisent pas ces applications plus complexes, et des garanties de niveau validium aux utilisateurs qui utilisent ces applications.
Ces options intermédiaires peuvent être considérées comme un spectre de technologies entre les rollups et les validiums. Mais qu’est-ce qui motive l’application à choisir un point particulier sur le pedigree, plutôt que l’extrême gauche ou l’extrême droite ? Il y a deux facteurs principaux ici :
Le coût de la disponibilité des données sur Ethereum lui-même diminuera progressivement à mesure que la technologie s’améliorera. Le prochain hard fork d’Ethereum, Dencun, a introduit l’EIP-4844 (également connu sous le nom de « proto-danksharding »), qui fournit un DA on-chain d’environ 32 kB/sec. Au cours des prochaines années, ce nombre devrait augmenter progressivement avec le déploiement complet du danksharding, pour finalement atteindre un objectif DA d’environ 1,3 Mo/s. Dans le même temps, les améliorations apportées à la compression des données nous permettront d’en faire plus avec la même quantité de données.
Les besoins de l’application elle-même : Combien l’utilisateur perd-il en raison de frais élevés par rapport aux problèmes avec l’application ? ** Les applications financières perdent davantage en raison de défaillances d’applications ; Les jeux et les médias sociaux impliquent une grande quantité d’activité par utilisateur et la valeur de l’activité est relativement faible, de sorte que le compromis entre la sécurité est différent pour eux.
Ce compromis ressemble à ceci :
! [Le pape Vitalinck Ier redéfinit la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d6d63d0742-dd1a6f-69ad2a.webp)
Une autre garantie partielle qui mérite d’être mentionnée est la pré-confirmation. Une préconfirmation est un message signé par certains participants à un cumul ou à une validation qui indique « nous avons prouvé que ces transactions sont incluses dans cet ordre, et que la racine post-état est celle-ci ». Ces participants peuvent signer ultérieurement une pré-confirmation qui ne correspond pas à la situation réelle ; Mais s’ils le font, ils brûlent un dépôt. Ceci est utile pour les applications de faible valeur telles que les paiements aux consommateurs, tandis que les applications de grande valeur telles que les transferts financiers de plusieurs millions de dollars peuvent attendre une confirmation « régulière » de la part du support de sécurité complet du système.
La pré-validation peut être considérée comme un autre exemple de système hybride, similaire au « système hybride Plasma/Validium » mentionné ci-dessus, mais cette fois-ci entre un Rollup (ou Validium) avec une sécurité totale mais une latence élevée et un système avec un niveau de sécurité inférieur mais une latence plus faible. Les applications qui nécessitent une latence plus faible bénéficient d’une sécurité plus faible, mais peuvent coexister dans le même écosystème que les applications qui nécessitent une latence plus élevée en échange d’une sécurité maximale.
Lire Ethereum sans autorisation
Une autre forme de connexion moins considérée, mais tout de même très importante, concerne la capacité du système à lire la blockchain Ethereum. En particulier, cela inclut la possibilité de revenir en arrière lorsque Ethereum a besoin de revenir en arrière. Pour comprendre pourquoi cela est utile, considérez le scénario suivant :
! [Le pape Vitalinck Ier redéfinit la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-ccbb1fb3ee-dd1a6f-69ad2a.webp)
Supposons, comme le montre le diagramme, qu’un retour en arrière se produise sur la chaîne Ethereum. Il peut s’agir d’une défaillance temporaire à une époque où la chaîne n’a pas été finalisée, ou il peut s’agir d’un réseau inactif et d’un trop grand nombre de validateurs hors ligne et d’une chaîne qui n’a pas été finalisée pendant une période prolongée.
Le pire scénario auquel cela peut conduire est le suivant. Supposons que le premier bloc de la chaîne supérieure lise certaines données du bloc le plus à gauche de la chaîne Ethereum. Par exemple, quelqu’un dépose 100 ETH sur Ethereum dans la chaîne supérieure. Ensuite, un retour en arrière se produit avec Ethereum. Cependant, il n’y a pas de retour en arrière de la chaîne supérieure. En conséquence, le futur bloc de la chaîne supérieure suivait correctement le nouveau bloc de la nouvelle chaîne Ethereum correcte, mais maintenant le résultat de la mauvaise ancienne chaîne (c’est-à-dire un dépôt de 100 ETH) existe toujours dans la chaîne supérieure. Cette vulnérabilité pourrait permettre la création d’une monnaie qui convertit l’ETH ponté sur la chaîne supérieure en une réserve partielle.
Il existe deux façons de résoudre ce problème :
La chaîne supérieure ne peut lire que les blocs Ethereum qui ont été finalisés, il n’y a donc pas besoin d’une opération de restauration. **
Si un rollback se produit sur Ethereum, la chaîne supérieure peut également revenir en arrière. **
Les deux peuvent empêcher que cela ne se produise. Le premier est plus facile à mettre en œuvre, mais il peut entraîner une perte prolongée de fonctionnalité si Ethereum entre dans une période d’inactivité. Ce dernier est plus difficile à mettre en œuvre, mais assure toujours une fonctionnalité optimale.
Il est important de noter qu’il existe un cas particulier dans la première méthode (1). Si une attaque à 51 % crée deux blocs incompatibles sur Ethereum, et que les deux blocs semblent finalisés en même temps, la chaîne supérieure peut choisir le mauvais bloc (c’est-à-dire le bloc que le consensus de la communauté Ethereum ne prend finalement pas en charge) et doit être annulée pour passer au bon bloc. On peut dire qu’il n’est pas nécessaire d’écrire du code à l’avance pour gérer cette situation ; Il peut gérer cela en faisant une fourche dure de la chaîne supérieure.
La possibilité pour les chaînes de lire des données sur Ethereum sans autorisation est précieuse pour les raisons suivantes :
Réduire les problèmes de sécurité liés au chaînage croisé des jetons émis sur Ethereum (ou une autre couche 2) vers cette chaîne.
Permet aux portefeuilles d’abstraction de compte utilisant une structure de stockage de clés partagées de conserver en toute sécurité les actifs sur la chaîne.
La première raison est importante, bien que cette importance soit peut-être déjà largement reconnue ; Et la deuxième raison est tout aussi importante, car elle signifie que vous pouvez avoir un portefeuille, changer facilement de clés et détenir des actifs sur de nombreuses chaînes différentes.
Est-ce que le fait d’avoir un pont fait de la chaîne un validium ?
Supposons que la chaîne supérieure commence comme une seule chaîne, puis que quelqu’un mette un contrat inter-chaînes sur Ethereum. Un contrat inter-chaînes est simplement un contrat qui accepte l’en-tête de bloc de la chaîne supérieure, en vérifiant que tout en-tête qui lui est soumis est accompagné d’un certificat valide indiquant qu’il est accepté par le consensus de la chaîne supérieure et ajoute cet en-tête à la liste. Des applications peuvent être construites en plus de cela pour activer des fonctionnalités telles que le dépôt et le retrait de jetons. Une fois qu’un tel pont est en place, offre-t-il l’une ou l’autre des garanties de sécurité des actifs que nous avons mentionnées plus tôt ?
! [Le pape Vitalinck Ier redéfinit la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-77802047aa-dd1a6f-69ad2a.webp)
Jusqu’à présent, pas encore ! Il y a deux raisons à cela :
Nous vérifions que le blocage est signé, mais nous ne vérifions pas que la transition d’état n’est pas correcte. Ainsi, si vous émettez des actifs sur Ethereum qui sont déposés dans la chaîne supérieure, et que les validateurs de la chaîne supérieure sont des voyous, ils peuvent signer une transition d’état invalide et voler ces actifs.
Il n’y a toujours aucun moyen pour la chaîne supérieure de lire les données Ethereum. Par conséquent, vous ne pouvez même pas déposer d’actifs natifs d’Ethereum dans la chaîne supérieure sans vous appuyer sur d’autres ponts tiers (potentiellement non sécurisés).
Maintenant, faisons du pont un pont de validation : il ne vérifie pas seulement le consensus, mais aussi un ZK-SNARK qui prouve que l’état de tout nouveau bloc est calculé correctement.
Une fois cela fait, les validateurs de la chaîne supérieure ne peuvent plus voler vos fonds. Ils peuvent publier un bloc contenant des données inutilisables, empêchant tout le monde de sortir, mais ils ne peuvent pas le voler (à moins d’essayer d’extorquer une rançon aux utilisateurs en échange de la fuite de données qui leur permettent de sortir). Il s’agit du même modèle de sécurité que les validiums.
Cependant, nous n’avons toujours pas résolu le deuxième problème : la chaîne supérieure ne peut pas lire Ethereum.
Pour ce faire, nous devons faire l’une des deux choses suivantes :
Placez le contrat inter-chaînes qui valide le bloc Ethereum final dans la chaîne supérieure.
Faire en sorte que chaque bloc de la topchain contienne le hachage du bloc Ethereum le plus récent, et avoir une règle de choix de fork qui applique le lien de hachage. C’est-à-dire que le bloc de la chaîne supérieure lié à un bloc Ethereum qui n’est pas dans la chaîne canonique est lui-même non canonique, et si la blockchain de la chaîne supérieure est connectée à un bloc Ethereum qui était initialement canonique, mais qui devient plus tard non canonique, alors le bloc de la chaîne supérieure doit également devenir non canonique.
! [Le pape Vitalinck Ier redéfinit la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-7340ab7dba-dd1a6f-69ad2a.webp)
Le lien violet dans le diagramme peut être soit un lien de hachage, soit un contrat de pont qui vérifie le consensus Ethereum.
Est-ce suffisant ? Il s’est avéré que ce n’était pas suffisant, car il y avait quelques petits cas particuliers :
Que se passe-t-il si Ethereum est attaqué par 51 % ? **
Comment gérer une mise à niveau du hard fork d’Ethereum ? **
Comment faire face à une mise à niveau hard fork de la chaîne supérieure ?**
L’attaque à 51 % d’Ethereum aurait des conséquences similaires à l’attaque à 51 % de la chaîne supérieure, mais dans la direction opposée. Un hard fork d’Ethereum peut rendre le pont Ethereum au sein de la chaîne supérieure non valide. La solution la plus propre à ce problème est de promettre que si Ethereum annule un bloc finalisé, la chaîne supérieure reviendra également en arrière, et si Ethereum fait un hard fork, la chaîne supérieure fera également un hard fork. Une telle promesse n’aura peut-être jamais besoin d’être réellement appliquée : vous pouvez activer un mécanisme de gouvernance sur la chaîne supérieure et si elle voit des preuves d’une attaque ou d’un hard fork possible, et ne faire un hard fork sur la chaîne supérieure que si le mécanisme de gouvernance échoue.
La seule réponse viable à la question (3) est que le fait d’avoir une forme de mécanisme de gouvernance sur Ethereum rendrait le contrat relais sur Ethereum conscient de la mise à niveau du hard fork de la chaîne supérieure.
Résumé : Un pont de validation bidirectionnel est presque suffisant pour faire de la chaîne un validium. Le principal problème restant est que l’autre chaîne s’engagera socialement à un hard fork lorsque quelque chose arrivera à Ethereum qui empêchera le pont de fonctionner.
En conclusion
Il y a deux dimensions clés à la « connexion à Ethereum » :
Sécurité des retraits vers EthereumSécurité de la lecture des données Ethereum
Les deux dimensions sont importantes et ont des considérations différentes. Dans les deux cas, il existe un pedigree :
! [Le pape Vitalinck Ier redéfinit la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-be23ca98bb-dd1a6f-69ad2a.webp)
Notez que chaque dimension est mesurée de deux manières différentes (il y a donc en fait quatre dimensions ?). ) : La sécurité de l’extrait peut être mesurée par (i) le niveau de sécurité et (ii) le pourcentage d’utilisateurs ou de cas d’utilisation qui bénéficient du plus haut niveau de sécurité, tandis que la sécurité de lecture peut être mesurée par (i) la capacité du lien à lire rapidement les blocs d’Ethereum, en particulier la différence entre un bloc qui a été finalisé et n’importe quel bloc, et (ii) la force de l’engagement social du lien lorsqu’il s’agit de cas extrêmes tels que les attaques à 51 % et les hard forks.
Il existe de nombreux projets qui ont de la valeur dans cet espace de conception. Pour certaines applications, une sécurité élevée et une connectivité étroite sont importantes. Pour d’autres applications, une connectivité plus lâche est acceptable pour une plus grande évolutivité. Dans de nombreux cas, il peut être préférable de commencer par certaines des méthodes les plus indulgentes aujourd’hui et de passer progressivement à des connexions plus étroites au cours de la prochaine décennie à mesure que la technologie s’améliore.
Voir l'original
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.
Le pape Vitalinck Ier redéfinit la L2
Auteur original | Vitalik.eth
Compiler | Odaily 0xAyA
! [Le pape Vitalinck Ier redéfinit la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-17bf55f5b7-dd1a6f-69ad2a.webp)
Un grand merci à Karl Floersch pour ses commentaires et sa critique
L’écosystème Ethereum Layer 2 s’est rapidement développé au cours de l’année écoulée. L’écosystème ZK-EVM Rollup, représenté par StarkNet, Arbitrum, Optimism et Scroll, a fait de grands progrès dans l’amélioration de la sécurité, et la page L2beat fournit un bon résumé de l’état de chaque projet. De plus, nous avons vu des équipes construire des sidechains commencer à construire des Rollups (Polygon), des projets de couche 1 essayer de migrer vers Validation (Celo) et faire de nouveaux efforts (Linea, Zeth, etc.).
En conséquence, les projets de couche 2 deviennent plus hétérogènes. Je m’attends à ce que cette tendance se poursuive pour les raisons suivantes :
Certains projets de couche 1 actuellement autonomes cherchent à se rapprocher de l’écosystème Ethereum et à devenir potentiellement de couche 2. **Ces projets peuvent nécessiter une transition graduelle. Changer maintenant entraînera une diminution de la facilité d’utilisation, car la technologie n’est pas prête à tout mettre sur le cumul ; Mais changer trop tard peut coûter de l’élan et il est trop tard pour avoir un sens. Certains projets centralisés veulent offrir aux utilisateurs plus de garanties de sécurité et explorent des voies basées sur la blockchain. Dans de nombreux cas, ces projets peuvent déjà explorer des « chaînes de consortium autorisées ». En fait, ils n’ont peut-être besoin que d’un niveau de décentralisation « intermédiaire ». De plus, ils ont souvent un débit très élevé, ce qui les rend même pas adaptés aux rollups, du moins à court terme. Les applications non financières, telles que les jeux ou les médias sociaux, veulent être décentralisées, mais n’ont besoin que d’une « couche intermédiaire » de sécurité. Les médias sociaux, par exemple, impliquent en fait que différentes parties de l’application sont traitées différemment : les activités à faible fréquence et à forte valeur ajoutée telles que l’enregistrement du nom d’utilisateur et la récupération de compte doivent être effectuées sur Rollup ; Les activités à haute fréquence et à faible valeur ajoutée, telles que la publication et l’interrogation, nécessitent moins de sécurité. Si votre message disparaît en raison d’une défaillance de la chaîne, c’est un prix acceptable ; Mais si la défaillance de la chaîne vous fait perdre votre compte, c’est un gros problème.
Un problème important est que le paiement de frais de cumul plus faibles, mais toujours visibles, est acceptable pour les applications et les utilisateurs d’Ethereum Layer 1 pour le moment, mais pas pour les utilisateurs en dehors du monde de la blockchain : si vous avez déjà payé 1 $, payer 0,10 $ est plus acceptable ; Mais si vous avez déjà payé 0 $, payer 0,10 $ est inacceptable. Cela s’applique à la fois aux applications centralisées actuelles et aux petits projets de couche 1, qui ont souvent des frais très bas avec une petite base d’utilisateurs.
La question qui se pose est la suivante : lequel de ces compromis complexes entre les cumuls, les validiums et d’autres systèmes est raisonnable pour une application particulière ?
Cumuls、Validiums、Déconnecté
La première dimension de la sécurité et de l’échelle que nous allons explorer peut être décrite comme suit : si vous possédez un actif qui a été émis sur la couche 1, puis déposé dans la couche 2, puis transféré sur votre compte, pouvez-vous être sûr que vous pouvez récupérer cet actif sur la couche 1 ? **
Dans le même temps, il y a une question similaire : quels sont les choix technologiques qui mènent à cette assurance, et quels sont les compromis derrière ces choix technologiques ? **
Nous pouvons simplement décrire le problème à l’aide d’un tableau :
! [Le pape Vitalinck Ier redéfinit la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-144dab5eab-dd1a6f-69ad2a.webp)
Il convient de mentionner qu’il s’agit d’une architecture simplifiée et qu’il existe de nombreux éléments intermédiaires parmi lesquels choisir. Par exemple:
Ces options intermédiaires peuvent être considérées comme un spectre de technologies entre les rollups et les validiums. Mais qu’est-ce qui motive l’application à choisir un point particulier sur le pedigree, plutôt que l’extrême gauche ou l’extrême droite ? Il y a deux facteurs principaux ici :
Le coût de la disponibilité des données sur Ethereum lui-même diminuera progressivement à mesure que la technologie s’améliorera. Le prochain hard fork d’Ethereum, Dencun, a introduit l’EIP-4844 (également connu sous le nom de « proto-danksharding »), qui fournit un DA on-chain d’environ 32 kB/sec. Au cours des prochaines années, ce nombre devrait augmenter progressivement avec le déploiement complet du danksharding, pour finalement atteindre un objectif DA d’environ 1,3 Mo/s. Dans le même temps, les améliorations apportées à la compression des données nous permettront d’en faire plus avec la même quantité de données. Les besoins de l’application elle-même : Combien l’utilisateur perd-il en raison de frais élevés par rapport aux problèmes avec l’application ? ** Les applications financières perdent davantage en raison de défaillances d’applications ; Les jeux et les médias sociaux impliquent une grande quantité d’activité par utilisateur et la valeur de l’activité est relativement faible, de sorte que le compromis entre la sécurité est différent pour eux.
Ce compromis ressemble à ceci :
! [Le pape Vitalinck Ier redéfinit la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d6d63d0742-dd1a6f-69ad2a.webp)
Une autre garantie partielle qui mérite d’être mentionnée est la pré-confirmation. Une préconfirmation est un message signé par certains participants à un cumul ou à une validation qui indique « nous avons prouvé que ces transactions sont incluses dans cet ordre, et que la racine post-état est celle-ci ». Ces participants peuvent signer ultérieurement une pré-confirmation qui ne correspond pas à la situation réelle ; Mais s’ils le font, ils brûlent un dépôt. Ceci est utile pour les applications de faible valeur telles que les paiements aux consommateurs, tandis que les applications de grande valeur telles que les transferts financiers de plusieurs millions de dollars peuvent attendre une confirmation « régulière » de la part du support de sécurité complet du système.
La pré-validation peut être considérée comme un autre exemple de système hybride, similaire au « système hybride Plasma/Validium » mentionné ci-dessus, mais cette fois-ci entre un Rollup (ou Validium) avec une sécurité totale mais une latence élevée et un système avec un niveau de sécurité inférieur mais une latence plus faible. Les applications qui nécessitent une latence plus faible bénéficient d’une sécurité plus faible, mais peuvent coexister dans le même écosystème que les applications qui nécessitent une latence plus élevée en échange d’une sécurité maximale.
Lire Ethereum sans autorisation
Une autre forme de connexion moins considérée, mais tout de même très importante, concerne la capacité du système à lire la blockchain Ethereum. En particulier, cela inclut la possibilité de revenir en arrière lorsque Ethereum a besoin de revenir en arrière. Pour comprendre pourquoi cela est utile, considérez le scénario suivant :
! [Le pape Vitalinck Ier redéfinit la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-ccbb1fb3ee-dd1a6f-69ad2a.webp)
Supposons, comme le montre le diagramme, qu’un retour en arrière se produise sur la chaîne Ethereum. Il peut s’agir d’une défaillance temporaire à une époque où la chaîne n’a pas été finalisée, ou il peut s’agir d’un réseau inactif et d’un trop grand nombre de validateurs hors ligne et d’une chaîne qui n’a pas été finalisée pendant une période prolongée.
Le pire scénario auquel cela peut conduire est le suivant. Supposons que le premier bloc de la chaîne supérieure lise certaines données du bloc le plus à gauche de la chaîne Ethereum. Par exemple, quelqu’un dépose 100 ETH sur Ethereum dans la chaîne supérieure. Ensuite, un retour en arrière se produit avec Ethereum. Cependant, il n’y a pas de retour en arrière de la chaîne supérieure. En conséquence, le futur bloc de la chaîne supérieure suivait correctement le nouveau bloc de la nouvelle chaîne Ethereum correcte, mais maintenant le résultat de la mauvaise ancienne chaîne (c’est-à-dire un dépôt de 100 ETH) existe toujours dans la chaîne supérieure. Cette vulnérabilité pourrait permettre la création d’une monnaie qui convertit l’ETH ponté sur la chaîne supérieure en une réserve partielle.
Il existe deux façons de résoudre ce problème :
La chaîne supérieure ne peut lire que les blocs Ethereum qui ont été finalisés, il n’y a donc pas besoin d’une opération de restauration. ** Si un rollback se produit sur Ethereum, la chaîne supérieure peut également revenir en arrière. **
Les deux peuvent empêcher que cela ne se produise. Le premier est plus facile à mettre en œuvre, mais il peut entraîner une perte prolongée de fonctionnalité si Ethereum entre dans une période d’inactivité. Ce dernier est plus difficile à mettre en œuvre, mais assure toujours une fonctionnalité optimale.
Il est important de noter qu’il existe un cas particulier dans la première méthode (1). Si une attaque à 51 % crée deux blocs incompatibles sur Ethereum, et que les deux blocs semblent finalisés en même temps, la chaîne supérieure peut choisir le mauvais bloc (c’est-à-dire le bloc que le consensus de la communauté Ethereum ne prend finalement pas en charge) et doit être annulée pour passer au bon bloc. On peut dire qu’il n’est pas nécessaire d’écrire du code à l’avance pour gérer cette situation ; Il peut gérer cela en faisant une fourche dure de la chaîne supérieure.
La possibilité pour les chaînes de lire des données sur Ethereum sans autorisation est précieuse pour les raisons suivantes :
La première raison est importante, bien que cette importance soit peut-être déjà largement reconnue ; Et la deuxième raison est tout aussi importante, car elle signifie que vous pouvez avoir un portefeuille, changer facilement de clés et détenir des actifs sur de nombreuses chaînes différentes.
Est-ce que le fait d’avoir un pont fait de la chaîne un validium ?
Supposons que la chaîne supérieure commence comme une seule chaîne, puis que quelqu’un mette un contrat inter-chaînes sur Ethereum. Un contrat inter-chaînes est simplement un contrat qui accepte l’en-tête de bloc de la chaîne supérieure, en vérifiant que tout en-tête qui lui est soumis est accompagné d’un certificat valide indiquant qu’il est accepté par le consensus de la chaîne supérieure et ajoute cet en-tête à la liste. Des applications peuvent être construites en plus de cela pour activer des fonctionnalités telles que le dépôt et le retrait de jetons. Une fois qu’un tel pont est en place, offre-t-il l’une ou l’autre des garanties de sécurité des actifs que nous avons mentionnées plus tôt ?
! [Le pape Vitalinck Ier redéfinit la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-77802047aa-dd1a6f-69ad2a.webp)
Jusqu’à présent, pas encore ! Il y a deux raisons à cela :
Nous vérifions que le blocage est signé, mais nous ne vérifions pas que la transition d’état n’est pas correcte. Ainsi, si vous émettez des actifs sur Ethereum qui sont déposés dans la chaîne supérieure, et que les validateurs de la chaîne supérieure sont des voyous, ils peuvent signer une transition d’état invalide et voler ces actifs.
Maintenant, faisons du pont un pont de validation : il ne vérifie pas seulement le consensus, mais aussi un ZK-SNARK qui prouve que l’état de tout nouveau bloc est calculé correctement.
Une fois cela fait, les validateurs de la chaîne supérieure ne peuvent plus voler vos fonds. Ils peuvent publier un bloc contenant des données inutilisables, empêchant tout le monde de sortir, mais ils ne peuvent pas le voler (à moins d’essayer d’extorquer une rançon aux utilisateurs en échange de la fuite de données qui leur permettent de sortir). Il s’agit du même modèle de sécurité que les validiums.
Cependant, nous n’avons toujours pas résolu le deuxième problème : la chaîne supérieure ne peut pas lire Ethereum.
Pour ce faire, nous devons faire l’une des deux choses suivantes :
! [Le pape Vitalinck Ier redéfinit la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-7340ab7dba-dd1a6f-69ad2a.webp)
Le lien violet dans le diagramme peut être soit un lien de hachage, soit un contrat de pont qui vérifie le consensus Ethereum.
Est-ce suffisant ? Il s’est avéré que ce n’était pas suffisant, car il y avait quelques petits cas particuliers :
Que se passe-t-il si Ethereum est attaqué par 51 % ? ** Comment gérer une mise à niveau du hard fork d’Ethereum ? ** Comment faire face à une mise à niveau hard fork de la chaîne supérieure ?**
L’attaque à 51 % d’Ethereum aurait des conséquences similaires à l’attaque à 51 % de la chaîne supérieure, mais dans la direction opposée. Un hard fork d’Ethereum peut rendre le pont Ethereum au sein de la chaîne supérieure non valide. La solution la plus propre à ce problème est de promettre que si Ethereum annule un bloc finalisé, la chaîne supérieure reviendra également en arrière, et si Ethereum fait un hard fork, la chaîne supérieure fera également un hard fork. Une telle promesse n’aura peut-être jamais besoin d’être réellement appliquée : vous pouvez activer un mécanisme de gouvernance sur la chaîne supérieure et si elle voit des preuves d’une attaque ou d’un hard fork possible, et ne faire un hard fork sur la chaîne supérieure que si le mécanisme de gouvernance échoue.
La seule réponse viable à la question (3) est que le fait d’avoir une forme de mécanisme de gouvernance sur Ethereum rendrait le contrat relais sur Ethereum conscient de la mise à niveau du hard fork de la chaîne supérieure.
Résumé : Un pont de validation bidirectionnel est presque suffisant pour faire de la chaîne un validium. Le principal problème restant est que l’autre chaîne s’engagera socialement à un hard fork lorsque quelque chose arrivera à Ethereum qui empêchera le pont de fonctionner.
En conclusion
Il y a deux dimensions clés à la « connexion à Ethereum » :
Sécurité des retraits vers Ethereum Sécurité de la lecture des données Ethereum
Les deux dimensions sont importantes et ont des considérations différentes. Dans les deux cas, il existe un pedigree :
! [Le pape Vitalinck Ier redéfinit la L2] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-be23ca98bb-dd1a6f-69ad2a.webp)
Notez que chaque dimension est mesurée de deux manières différentes (il y a donc en fait quatre dimensions ?). ) : La sécurité de l’extrait peut être mesurée par (i) le niveau de sécurité et (ii) le pourcentage d’utilisateurs ou de cas d’utilisation qui bénéficient du plus haut niveau de sécurité, tandis que la sécurité de lecture peut être mesurée par (i) la capacité du lien à lire rapidement les blocs d’Ethereum, en particulier la différence entre un bloc qui a été finalisé et n’importe quel bloc, et (ii) la force de l’engagement social du lien lorsqu’il s’agit de cas extrêmes tels que les attaques à 51 % et les hard forks.
Il existe de nombreux projets qui ont de la valeur dans cet espace de conception. Pour certaines applications, une sécurité élevée et une connectivité étroite sont importantes. Pour d’autres applications, une connectivité plus lâche est acceptable pour une plus grande évolutivité. Dans de nombreux cas, il peut être préférable de commencer par certaines des méthodes les plus indulgentes aujourd’hui et de passer progressivement à des connexions plus étroites au cours de la prochaine décennie à mesure que la technologie s’améliore.