Titre original : « Différents types de couches 2 »
Texte : Vitalik Buterin
Compilation : BlockBeats
L’écosystème s’est rapidement développé au cours de l’année écoulée. L’écosystème de cumul ZK-EVM, traditionnellement représenté par StarkNet, Arbitrum, Optimism et Scroll, progresse rapidement, améliorant sa sécurité, et la page L2beat fournit un bon résumé de l’état de chaque projet.
De plus, nous voyons des équipes construire des sidechains et des rollups (par exemple, Polygon), certains projets L1 essayant d’aller vers la validation (par exemple, Celo), et des tentatives complètement nouvelles (par exemple, Linea, Zeth...). ）。
L’une des conséquences inévitables de cette situation est que les projets L2 ont tendance à être plus hétérogènes (c’est-à-dire « isomérisés »). En crypto, « hétérogénéité » fait référence à la coexistence ou au mélange de différents types de choses ou de différentes natures. Ce terme est souvent utilisé pour décrire différentes blockchains, protocoles, technologies ou actifs qui ont des caractéristiques, des règles ou des attributs différents. Je m’attends à ce que cette tendance se poursuive pour les raisons suivantes :
Actuellement, un certain nombre de projets L1 indépendants cherchent à s’engager plus étroitement avec l’écosystème Ethereum et à se transformer potentiellement en projets L2. Ces projets voudront peut-être adopter une approche progressive de la transition. Effectuer une transition globale immédiate réduira la facilité d’utilisation, car la technologie n’est pas prête à tout mettre dans un scénario de cumul. Et dans la transition globale ultérieure, il sera peut-être trop tard pour sacrifier l’élan et le sens pratique.
Certains projets centralisés veulent offrir plus de sécurité à leurs utilisateurs et explorent des avenues basées sur la blockchain. Dans de nombreux cas, ces projets se sont peut-être penchés sur les « blockchains de consortium autorisées » dans le passé. En fait, ils n’ont peut-être besoin que d’atteindre le niveau de « semi-centralisation ». De plus, ils ont généralement un débit très élevé, ce qui les rend inadaptés aux schémas de cumul, 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’un certain niveau de sécurité.
Dans le cas des médias sociaux, il y a en fait différentes parties de l’application qui sont abordées de différentes manières : les activités rares et de grande valeur comme l’enregistrement du nom d’utilisateur et la récupération de compte doivent être effectuées dans un système de cumul, mais les activités fréquentes et de faible valeur comme les publications et les sondages nécessitent moins de sécurité, ce qui est un prix acceptable à payer si la blockchain échoue et fait disparaître vos publications ; Mais si une défaillance de la blockchain vous fait perdre votre compte, c’est un problème plus important.
Un thème important est que si les applications et les utilisateurs actuellement situés sur Ethereum L1 sont prêts à payer des frais de cumul plus petits mais toujours visibles à court terme, les utilisateurs du monde non blockchain sont moins disposés à le faire : si vous avez déjà payé 1 $, alors payer 0,10 $ est plus acceptable, et si vous avez déjà payé 0 $, il est difficile d’accepter.
Cela s’applique aux applications qui sont encore centralisées aujourd’hui, ainsi qu’aux petits projets L1 qui ont souvent des frais extrêmement bas lorsque leur base d’utilisateurs est petite.
Une question naturelle est la suivante : lequel de ces compromis complexes entre les schémas de cumul, les validiums et d’autres systèmes est raisonnable pour une application particulière ?
Cumuls vs Validiums vs Déconnectés s
La première dimension de la sécurité et de l’évolutivité que nous allons explorer peut être décrite comme suit : si vous possédez un actif émis sur L1, puis que vous le déposez en L2 et que vous le transférez, dans quelle mesure avez-vous l’assurance que vous pouvez récupérer l’actif en L1 ?
Il y a aussi une question connexe : quel choix technologique mène à ce niveau d’assurance, et quels sont les compromis de ce choix technologique ?
Nous pouvons illustrer le problème avec un schéma simple :
! [Vitalik : Il est temps d’arrêter les chamailleries, j’ai quelque chose à dire sur la définition de la couche 2] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-c56f261579-dd1a6f-69ad2a.webp)
Il convient de mentionner qu’il s’agit d’un scénario simplifié dans lequel de nombreuses options intermédiaires existent. Par exemple:
Entre le cumul et la validation : Dans la validation, n’importe qui peut effectuer un paiement 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 le plasma et le validium : un système plasma offre des garanties de sécurité de type rollup avec une disponibilité des données hors chaîne, mais il ne prend en charge qu’un nombre limité d’applications. Un système peut fournir un EVM complet avec des garanties de niveau plasma pour ceux qui n’utilisent pas ces applications plus complexes, ainsi que des garanties de niveau validium pour ceux qui utilisent ces applications.
Ces options intermédiaires peuvent être considérées comme un spectre entre le cumul et le validium. Mais qu’est-ce qui motive l’application à choisir un point spécifique sur ce spectre, plutôt qu’un point plus à gauche ou à droite ? Ici, il y a deux facteurs principaux :
**1. Le coût de la disponibilité des données natives d’Ethereum, qui diminuera au fil du temps à mesure que la technologie évoluera. Le prochain hard fork d’Ethereum, Dencun, introduit EIP-4844 (également connu sous le nom de « proto-danksharding »), qui fournit environ 32 Ko/s de disponibilité des données on-chain.
Cette disponibilité des données devrait augmenter progressivement au cours des prochaines années avec le déploiement complet du danksharding, avec l’objectif ultime d’une disponibilité des données 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.
**2. Les besoins propres à l’application : quelle est la gravité de la perte de l’utilisateur en termes de coûts élevés par rapport au problème de l’application ? ** Les applications financières perdront plus en raison de l’échec de l’application ; Les jeux et les médias sociaux impliquent beaucoup d’activité des utilisateurs et des activités de faible valeur, de sorte que différents compromis en matière de sécurité ont du sens pour eux.
Ce compromis ressemble à peu près à ceci :
! [Vitalik : Il est temps d’arrêter les chamailleries, j’ai quelque chose à dire sur la définition de la couche 2] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-52e34e810f-dd1a6f-69ad2a.webp)
Un autre type qui mérite d’être mentionné est celui des pré-confirmations. Une préconfirmation est un message signé par un groupe de participants à un cumul ou à une validation qui indique « nous prouvons que ces transactions sont incluses dans cet ordre et que la racine post-état est celle-ci ». Ces participants peuvent signer une pré-confirmation qui ne correspond pas à la réalité, mais si c’est le cas, leurs dépôts seront détruits.
Ceci est utile pour les applications de faible valeur, telles que les paiements des 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 » soutenue par l’intégrité de la sécurité du système.
La préconfirmation peut être considérée comme un autre exemple de système hybride, similaire à l’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 faible latence. Les applications qui nécessitent une latence plus faible bénéficieront d’une sécurité plus faible, mais peuvent coexister dans le même écosystème que celles qui sont prêtes à tolérer une latence plus élevée pour une sécurité maximale.
Lecture sans confiance de l’Ethereum
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. Plus précisément, cela inclut la capacité du système à revenir en arrière lorsque Ethereum se produit. Pour comprendre pourquoi cela est utile, considérez le scénario suivant :
! [Vitalik : Il est temps d’arrêter les chamailleries, j’ai quelque chose à dire sur la définition de la couche 2] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-9efa41e033-dd1a6f-69ad2a.webp)
Supposons qu’un retour en arrière se produise sur la blockchain Ethereum, comme le montre le schéma. Il peut s’agir d’une panne temporaire à une époque où la blockchain n’a pas encore été finalisée ; Ou cela peut être dû au fait qu’un trop grand nombre de validateurs sont hors ligne, ce qui entraîne des périodes de fuite inactives que la blockchain ne peut pas finaliser avant une période plus longue.
Le pire scénario qui peut en résulter est le suivant : supposons que le premier bloc de la chaîne supérieure lise des 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, Ethereum a reculé, mais pas la chaîne supérieure. Par conséquent, les futurs blocs de la chaîne supérieure suivent correctement les nouveaux blocs corrects de la blockchain Ethereum, mais la mauvaise transaction (c’est-à-dire un dépôt de 100 ETH) existe toujours dans la chaîne supérieure. Cette vulnérabilité pourrait conduire à l’émission supplémentaire de pièces, transformant l’ETH ponté sur la chaîne supérieure en réserves partielles.
Il existe deux façons de résoudre ce problème :
La chaîne supérieure ne peut lire que les blocs qui ont été finalisés par Ethereum, de sorte qu’elle n’a jamais besoin d’être annulée ;
Si un rollback se produit sur Ethereum, un rollback peut également se produire sur la chaîne supérieure. Les deux peuvent prévenir ce problème. Le premier est plus facile à mettre en œuvre, mais si Ethereum entre dans une période de fuite inactive, cela peut entraîner une perte de fonctionnalité pendant une période prolongée. Ce dernier est plus difficile à mettre en œuvre, mais garantit qu’il dispose toujours des meilleures fonctionnalités.
Notez qu’il existe bien un cas particulier pour la première méthode. S’il y a une attaque de 51 % sur Ethereum, entraînant l’apparition simultanée de deux nouveaux blocs incompatibles, qui semblent tous deux avoir été finalisés, la chaîne supérieure peut choisir le mauvais bloc (c’est-à-dire le bloc que le consensus social Ethereum ne prend finalement pas en charge) et doit revenir en arrière pour passer au bon bloc. On peut dire qu’il n’est pas nécessaire d’écrire du code au préalable pour gérer cette situation ; Cela peut être géré en faisant une fourche dure de la chaîne supérieure.
Il y a deux raisons importantes à la capacité de la blockchain à lire Ethereum sans confiance :
Tout d’abord, cette capacité peut réduire les problèmes de sécurité liés au pontage des jetons émis sur Ethereum (ou d’autres solutions de couche 2) à cette chaîne ;
Deuxièmement, cette fonctionnalité permet aux portefeuilles d’abstraction de compte qui utilisent une structure de stockage de clés partagées de conserver en toute sécurité les actifs sur la chaîne.
Malgré la controverse, l’importance de la première approche est largement reconnue. Encore une fois, la deuxième méthode est importante car elle signifie que vous pouvez avoir un portefeuille qui peut facilement changer de clé et détenir des actifs sur de nombreuses chaînes différentes.
Est-ce que le fait d’avoir un pont fait un validium ?
Supposons que la chaîne supérieure ait été initialement lancée en tant que chaîne indépendante, puis que quelqu’un ait déployé un contrat relais sur Ethereum. Un contrat de pont est simplement un contrat qui accepte les en-têtes de bloc de la chaîne supérieure, en vérifiant que tous les en-têtes de bloc qui lui sont soumis sont accompagnés d’un certificat valide qui prouve que l’en-tête de bloc a été accepté par le consensus de la chaîne supérieure, et ajoute l’en-tête de bloc à la liste.
L’application peut créer des fonctionnalités en plus de cela, telles que le dépôt et le retrait de jetons. Une fois qu’un tel pont est établi, offre-t-il l’une ou l’autre des garanties de sécurité des actifs que nous avons mentionnées plus tôt ?
! [Vitalik : Il est temps d’arrêter les chamailleries, j’ai quelque chose à dire sur la définition de la couche 2] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-d22cfade39-dd1a6f-69ad2a.webp)
Jusqu’à présent, pas encore ! Il y a deux raisons à cela :
Nous vérifions la signature du bloc, mais nous ne vérifions pas que la transition d’état est correcte. Ainsi, si vous déposez des actifs émis sur Ethereum dans la chaîne supérieure, et que le validateur de la chaîne supérieure devient malhonnête, il peut signer une transition d’état invalide, volant ainsi ces actifs ;
La chaîne supérieure est toujours illisible Ethereum. Par conséquent, vous ne pouvez pas déposer d’actifs natifs d’Ethereum dans la chaîne supérieure, sauf si vous vous appuyez sur d’autres ponts tiers (potentiellement non sécurisés).
Maintenant, construisons le pont comme un pont de validation : il vérifie non seulement le consensus, mais vérifie également que l’état de tout nouveau bloc calculé à l’aide des preuves ZK-SNARK est correct.
Une fois cette étape terminée, les validateurs de la chaîne supérieure ne pourront plus voler vos fonds. Ils peuvent publier un bloc contenant des données inutilisables, empêchant tout le monde de retirer des fonds, mais ils ne peuvent pas voler les fonds (sauf s’ils essaient de révéler les données qui permettent aux utilisateurs de retirer leurs fonds en exigeant une rançon). Celui-ci a le 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 les données d’Ethereum. Pour y parvenir, nous devons faire l’une des deux choses suivantes :
Placez un contrat relais dans la chaîne supérieure qui valide le bloc Ethereum finalisé ;
Incluez un hachage du bloc Ethereum le plus récent dans chaque bloc de la chaîne supérieure et utilisez des règles de sélection de fork pour appliquer le lien de hachage. C’est-à-dire que le bloc de la chaîne supérieure lui-même qui sera lié à un bloc Ethereum sur une chaîne non principale est une chaîne non principale. Si le bloc Ethereum connecté à la blockchain de la chaîne supérieure se trouve initialement sur la chaîne principale mais devient plus tard non-mainchain, le bloc de la chaîne supérieure doit également devenir non-mainchain.
! [Vitalik : Il est temps d’arrêter les chamailleries, j’ai quelque chose à dire sur la définition de la couche 2] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-0ce4cb4db0-dd1a6f-69ad2a.webp)
Ces liens violets peuvent être des liens de hachage ou des contrats de pont qui vérifient le consensus Ethereum
Est-ce suffisant ? En fait, ce n’est pas suffisant, car il y a quelques petits cas limites :
Que se passe-t-il si Ethereum subit une attaque à 51 % ?
Comment gérer la mise à niveau du hard fork d’Ethereum ?
Comment gérer une mise à niveau hard fork de votre chaîne ?
Une attaque à 51 % sur Ethereum aurait des conséquences similaires à une attaque à 51 % sur la chaîne supérieure, mais l’inverse serait vrai. Un hard fork d’Ethereum pourrait invalider le pont Ethereum au sein de la chaîne supérieure. Un engagement social, c’est-à-dire que si Ethereum restaure un bloc finalisé, il sera restauré, et si Ethereum fait un hard fork, il sera hard fork, est le moyen le plus propre de résoudre ce problème.
Une telle promesse n’a peut-être jamais besoin d’être réellement appliquée : si l’organe de gouvernance de la chaîne supérieure trouve des preuves d’une attaque ou d’un hard fork possible, il peut activer l’organe de gouvernance et ne faire un hard fork de la chaîne supérieure qu’en cas d’échec de l’organe de gouvernance.
À la troisième question, la seule réponse viable est d’avoir une forme de gouvernance sur Ethereum qui rendrait le contrat de pont sur Ethereum conscient de la mise à niveau hard fork de la chaîne supérieure.
Résumé : Un pont de vérification bidirectionnel est presque suffisant pour faire d’une blockchain un validium. Le principal élément restant est un engagement social selon lequel si quelque chose d’inhabituel arrive à Ethereum et que le contrat de pont ne fonctionne pas correctement, une autre blockchain fera un hard fork en réponse.
En conclusion
« Se connecter à Ethereum » a deux dimensions clés :
Sécurité des retraits vers Ethereum ;
Lisez la sécurité d’Ethereum.
Ces deux éléments sont très importants et ont des considérations différentes. Dans les deux cas, il y a un continuum :
! [Vitalik : Il est temps d’arrêter les chamailleries, j’ai quelque chose à dire sur la définition de la couche 2] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-fdbcc249f6-dd1a6f-69ad2a.webp)
Notez que chaque dimension est mesurée de deux manières différentes (il y en a en fait quatre) : la sécurité extraite peut être mesurée par (i) le niveau de sécurité, et (ii) le nombre d’utilisateurs ou d’utilisateurs bénéficiant du plus haut niveau de sécurité ;
La sécurité de lecture peut être mesurée par (i) la vitesse à laquelle le lien peut lire les blocs d’Ethereum, et en particulier la façon dont le bloc finalisé diffère de n’importe quel bloc, et (ii) le degré d’engagement du lien lorsqu’il s’agit de cas limites tels que les attaques à 51 % et les hard forks.
Il y a de la valeur pour le projet dans de nombreux domaines de cet espace de conception. Pour certaines applications, un haut niveau de sécurité et une connectivité étroite sont essentiels. Pour d’autres applications, des conditions plus souples sont acceptables pour une plus grande évolutivité. Dans de nombreux cas, à partir de conditions plus souples aujourd’hui, une transition progressive vers un couplage plus serré au cours de la prochaine décennie peut être optimale à 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.
Vitalik : Il est temps d’arrêter les chamailleries, j’ai quelque chose à dire sur la définition de la couche 2
Titre original : « Différents types de couches 2 »
Texte : Vitalik Buterin
Compilation : BlockBeats
L’écosystème s’est rapidement développé au cours de l’année écoulée. L’écosystème de cumul ZK-EVM, traditionnellement représenté par StarkNet, Arbitrum, Optimism et Scroll, progresse rapidement, améliorant sa sécurité, et la page L2beat fournit un bon résumé de l’état de chaque projet.
De plus, nous voyons des équipes construire des sidechains et des rollups (par exemple, Polygon), certains projets L1 essayant d’aller vers la validation (par exemple, Celo), et des tentatives complètement nouvelles (par exemple, Linea, Zeth...). ）。
L’une des conséquences inévitables de cette situation est que les projets L2 ont tendance à être plus hétérogènes (c’est-à-dire « isomérisés »). En crypto, « hétérogénéité » fait référence à la coexistence ou au mélange de différents types de choses ou de différentes natures. Ce terme est souvent utilisé pour décrire différentes blockchains, protocoles, technologies ou actifs qui ont des caractéristiques, des règles ou des attributs différents. Je m’attends à ce que cette tendance se poursuive pour les raisons suivantes :
Actuellement, un certain nombre de projets L1 indépendants cherchent à s’engager plus étroitement avec l’écosystème Ethereum et à se transformer potentiellement en projets L2. Ces projets voudront peut-être adopter une approche progressive de la transition. Effectuer une transition globale immédiate réduira la facilité d’utilisation, car la technologie n’est pas prête à tout mettre dans un scénario de cumul. Et dans la transition globale ultérieure, il sera peut-être trop tard pour sacrifier l’élan et le sens pratique.
Certains projets centralisés veulent offrir plus de sécurité à leurs utilisateurs et explorent des avenues basées sur la blockchain. Dans de nombreux cas, ces projets se sont peut-être penchés sur les « blockchains de consortium autorisées » dans le passé. En fait, ils n’ont peut-être besoin que d’atteindre le niveau de « semi-centralisation ». De plus, ils ont généralement un débit très élevé, ce qui les rend inadaptés aux schémas de cumul, 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’un certain niveau de sécurité.
Dans le cas des médias sociaux, il y a en fait différentes parties de l’application qui sont abordées de différentes manières : les activités rares et de grande valeur comme l’enregistrement du nom d’utilisateur et la récupération de compte doivent être effectuées dans un système de cumul, mais les activités fréquentes et de faible valeur comme les publications et les sondages nécessitent moins de sécurité, ce qui est un prix acceptable à payer si la blockchain échoue et fait disparaître vos publications ; Mais si une défaillance de la blockchain vous fait perdre votre compte, c’est un problème plus important.
Un thème important est que si les applications et les utilisateurs actuellement situés sur Ethereum L1 sont prêts à payer des frais de cumul plus petits mais toujours visibles à court terme, les utilisateurs du monde non blockchain sont moins disposés à le faire : si vous avez déjà payé 1 $, alors payer 0,10 $ est plus acceptable, et si vous avez déjà payé 0 $, il est difficile d’accepter.
Cela s’applique aux applications qui sont encore centralisées aujourd’hui, ainsi qu’aux petits projets L1 qui ont souvent des frais extrêmement bas lorsque leur base d’utilisateurs est petite.
Une question naturelle est la suivante : lequel de ces compromis complexes entre les schémas de cumul, les validiums et d’autres systèmes est raisonnable pour une application particulière ?
Cumuls vs Validiums vs Déconnectés s
La première dimension de la sécurité et de l’évolutivité que nous allons explorer peut être décrite comme suit : si vous possédez un actif émis sur L1, puis que vous le déposez en L2 et que vous le transférez, dans quelle mesure avez-vous l’assurance que vous pouvez récupérer l’actif en L1 ?
Il y a aussi une question connexe : quel choix technologique mène à ce niveau d’assurance, et quels sont les compromis de ce choix technologique ?
Nous pouvons illustrer le problème avec un schéma simple :
! [Vitalik : Il est temps d’arrêter les chamailleries, j’ai quelque chose à dire sur la définition de la couche 2] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-c56f261579-dd1a6f-69ad2a.webp)
Il convient de mentionner qu’il s’agit d’un scénario simplifié dans lequel de nombreuses options intermédiaires existent. Par exemple:
Entre le cumul et la validation : Dans la validation, n’importe qui peut effectuer un paiement 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 le plasma et le validium : un système plasma offre des garanties de sécurité de type rollup avec une disponibilité des données hors chaîne, mais il ne prend en charge qu’un nombre limité d’applications. Un système peut fournir un EVM complet avec des garanties de niveau plasma pour ceux qui n’utilisent pas ces applications plus complexes, ainsi que des garanties de niveau validium pour ceux qui utilisent ces applications.
Ces options intermédiaires peuvent être considérées comme un spectre entre le cumul et le validium. Mais qu’est-ce qui motive l’application à choisir un point spécifique sur ce spectre, plutôt qu’un point plus à gauche ou à droite ? Ici, il y a deux facteurs principaux :
**1. Le coût de la disponibilité des données natives d’Ethereum, qui diminuera au fil du temps à mesure que la technologie évoluera. Le prochain hard fork d’Ethereum, Dencun, introduit EIP-4844 (également connu sous le nom de « proto-danksharding »), qui fournit environ 32 Ko/s de disponibilité des données on-chain.
Cette disponibilité des données devrait augmenter progressivement au cours des prochaines années avec le déploiement complet du danksharding, avec l’objectif ultime d’une disponibilité des données 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.
**2. Les besoins propres à l’application : quelle est la gravité de la perte de l’utilisateur en termes de coûts élevés par rapport au problème de l’application ? ** Les applications financières perdront plus en raison de l’échec de l’application ; Les jeux et les médias sociaux impliquent beaucoup d’activité des utilisateurs et des activités de faible valeur, de sorte que différents compromis en matière de sécurité ont du sens pour eux.
Ce compromis ressemble à peu près à ceci :
! [Vitalik : Il est temps d’arrêter les chamailleries, j’ai quelque chose à dire sur la définition de la couche 2] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-52e34e810f-dd1a6f-69ad2a.webp)
Un autre type qui mérite d’être mentionné est celui des pré-confirmations. Une préconfirmation est un message signé par un groupe de participants à un cumul ou à une validation qui indique « nous prouvons que ces transactions sont incluses dans cet ordre et que la racine post-état est celle-ci ». Ces participants peuvent signer une pré-confirmation qui ne correspond pas à la réalité, mais si c’est le cas, leurs dépôts seront détruits.
Ceci est utile pour les applications de faible valeur, telles que les paiements des 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 » soutenue par l’intégrité de la sécurité du système.
La préconfirmation peut être considérée comme un autre exemple de système hybride, similaire à l’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 faible latence. Les applications qui nécessitent une latence plus faible bénéficieront d’une sécurité plus faible, mais peuvent coexister dans le même écosystème que celles qui sont prêtes à tolérer une latence plus élevée pour une sécurité maximale.
Lecture sans confiance de l’Ethereum
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. Plus précisément, cela inclut la capacité du système à revenir en arrière lorsque Ethereum se produit. Pour comprendre pourquoi cela est utile, considérez le scénario suivant :
! [Vitalik : Il est temps d’arrêter les chamailleries, j’ai quelque chose à dire sur la définition de la couche 2] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-9efa41e033-dd1a6f-69ad2a.webp)
Supposons qu’un retour en arrière se produise sur la blockchain Ethereum, comme le montre le schéma. Il peut s’agir d’une panne temporaire à une époque où la blockchain n’a pas encore été finalisée ; Ou cela peut être dû au fait qu’un trop grand nombre de validateurs sont hors ligne, ce qui entraîne des périodes de fuite inactives que la blockchain ne peut pas finaliser avant une période plus longue.
Le pire scénario qui peut en résulter est le suivant : supposons que le premier bloc de la chaîne supérieure lise des 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, Ethereum a reculé, mais pas la chaîne supérieure. Par conséquent, les futurs blocs de la chaîne supérieure suivent correctement les nouveaux blocs corrects de la blockchain Ethereum, mais la mauvaise transaction (c’est-à-dire un dépôt de 100 ETH) existe toujours dans la chaîne supérieure. Cette vulnérabilité pourrait conduire à l’émission supplémentaire de pièces, transformant l’ETH ponté sur la chaîne supérieure en réserves partielles.
Il existe deux façons de résoudre ce problème :
La chaîne supérieure ne peut lire que les blocs qui ont été finalisés par Ethereum, de sorte qu’elle n’a jamais besoin d’être annulée ;
Si un rollback se produit sur Ethereum, un rollback peut également se produire sur la chaîne supérieure. Les deux peuvent prévenir ce problème. Le premier est plus facile à mettre en œuvre, mais si Ethereum entre dans une période de fuite inactive, cela peut entraîner une perte de fonctionnalité pendant une période prolongée. Ce dernier est plus difficile à mettre en œuvre, mais garantit qu’il dispose toujours des meilleures fonctionnalités.
Notez qu’il existe bien un cas particulier pour la première méthode. S’il y a une attaque de 51 % sur Ethereum, entraînant l’apparition simultanée de deux nouveaux blocs incompatibles, qui semblent tous deux avoir été finalisés, la chaîne supérieure peut choisir le mauvais bloc (c’est-à-dire le bloc que le consensus social Ethereum ne prend finalement pas en charge) et doit revenir en arrière pour passer au bon bloc. On peut dire qu’il n’est pas nécessaire d’écrire du code au préalable pour gérer cette situation ; Cela peut être géré en faisant une fourche dure de la chaîne supérieure.
Il y a deux raisons importantes à la capacité de la blockchain à lire Ethereum sans confiance :
Tout d’abord, cette capacité peut réduire les problèmes de sécurité liés au pontage des jetons émis sur Ethereum (ou d’autres solutions de couche 2) à cette chaîne ;
Deuxièmement, cette fonctionnalité permet aux portefeuilles d’abstraction de compte qui utilisent une structure de stockage de clés partagées de conserver en toute sécurité les actifs sur la chaîne.
Malgré la controverse, l’importance de la première approche est largement reconnue. Encore une fois, la deuxième méthode est importante car elle signifie que vous pouvez avoir un portefeuille qui peut facilement changer de clé et détenir des actifs sur de nombreuses chaînes différentes.
Est-ce que le fait d’avoir un pont fait un validium ?
Supposons que la chaîne supérieure ait été initialement lancée en tant que chaîne indépendante, puis que quelqu’un ait déployé un contrat relais sur Ethereum. Un contrat de pont est simplement un contrat qui accepte les en-têtes de bloc de la chaîne supérieure, en vérifiant que tous les en-têtes de bloc qui lui sont soumis sont accompagnés d’un certificat valide qui prouve que l’en-tête de bloc a été accepté par le consensus de la chaîne supérieure, et ajoute l’en-tête de bloc à la liste.
L’application peut créer des fonctionnalités en plus de cela, telles que le dépôt et le retrait de jetons. Une fois qu’un tel pont est établi, offre-t-il l’une ou l’autre des garanties de sécurité des actifs que nous avons mentionnées plus tôt ?
! [Vitalik : Il est temps d’arrêter les chamailleries, j’ai quelque chose à dire sur la définition de la couche 2] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-d22cfade39-dd1a6f-69ad2a.webp)
Jusqu’à présent, pas encore ! Il y a deux raisons à cela :
Nous vérifions la signature du bloc, mais nous ne vérifions pas que la transition d’état est correcte. Ainsi, si vous déposez des actifs émis sur Ethereum dans la chaîne supérieure, et que le validateur de la chaîne supérieure devient malhonnête, il peut signer une transition d’état invalide, volant ainsi ces actifs ;
La chaîne supérieure est toujours illisible Ethereum. Par conséquent, vous ne pouvez pas déposer d’actifs natifs d’Ethereum dans la chaîne supérieure, sauf si vous vous appuyez sur d’autres ponts tiers (potentiellement non sécurisés).
Maintenant, construisons le pont comme un pont de validation : il vérifie non seulement le consensus, mais vérifie également que l’état de tout nouveau bloc calculé à l’aide des preuves ZK-SNARK est correct.
Une fois cette étape terminée, les validateurs de la chaîne supérieure ne pourront plus voler vos fonds. Ils peuvent publier un bloc contenant des données inutilisables, empêchant tout le monde de retirer des fonds, mais ils ne peuvent pas voler les fonds (sauf s’ils essaient de révéler les données qui permettent aux utilisateurs de retirer leurs fonds en exigeant une rançon). Celui-ci a le 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 les données d’Ethereum. Pour y parvenir, nous devons faire l’une des deux choses suivantes :
Placez un contrat relais dans la chaîne supérieure qui valide le bloc Ethereum finalisé ;
Incluez un hachage du bloc Ethereum le plus récent dans chaque bloc de la chaîne supérieure et utilisez des règles de sélection de fork pour appliquer le lien de hachage. C’est-à-dire que le bloc de la chaîne supérieure lui-même qui sera lié à un bloc Ethereum sur une chaîne non principale est une chaîne non principale. Si le bloc Ethereum connecté à la blockchain de la chaîne supérieure se trouve initialement sur la chaîne principale mais devient plus tard non-mainchain, le bloc de la chaîne supérieure doit également devenir non-mainchain.
! [Vitalik : Il est temps d’arrêter les chamailleries, j’ai quelque chose à dire sur la définition de la couche 2] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-0ce4cb4db0-dd1a6f-69ad2a.webp)
Ces liens violets peuvent être des liens de hachage ou des contrats de pont qui vérifient le consensus Ethereum
Est-ce suffisant ? En fait, ce n’est pas suffisant, car il y a quelques petits cas limites :
Que se passe-t-il si Ethereum subit une attaque à 51 % ?
Comment gérer la mise à niveau du hard fork d’Ethereum ?
Comment gérer une mise à niveau hard fork de votre chaîne ?
Une attaque à 51 % sur Ethereum aurait des conséquences similaires à une attaque à 51 % sur la chaîne supérieure, mais l’inverse serait vrai. Un hard fork d’Ethereum pourrait invalider le pont Ethereum au sein de la chaîne supérieure. Un engagement social, c’est-à-dire que si Ethereum restaure un bloc finalisé, il sera restauré, et si Ethereum fait un hard fork, il sera hard fork, est le moyen le plus propre de résoudre ce problème.
Une telle promesse n’a peut-être jamais besoin d’être réellement appliquée : si l’organe de gouvernance de la chaîne supérieure trouve des preuves d’une attaque ou d’un hard fork possible, il peut activer l’organe de gouvernance et ne faire un hard fork de la chaîne supérieure qu’en cas d’échec de l’organe de gouvernance.
À la troisième question, la seule réponse viable est d’avoir une forme de gouvernance sur Ethereum qui rendrait le contrat de pont sur Ethereum conscient de la mise à niveau hard fork de la chaîne supérieure.
Résumé : Un pont de vérification bidirectionnel est presque suffisant pour faire d’une blockchain un validium. Le principal élément restant est un engagement social selon lequel si quelque chose d’inhabituel arrive à Ethereum et que le contrat de pont ne fonctionne pas correctement, une autre blockchain fera un hard fork en réponse.
En conclusion
« Se connecter à Ethereum » a deux dimensions clés :
Sécurité des retraits vers Ethereum ;
Lisez la sécurité d’Ethereum.
Ces deux éléments sont très importants et ont des considérations différentes. Dans les deux cas, il y a un continuum :
! [Vitalik : Il est temps d’arrêter les chamailleries, j’ai quelque chose à dire sur la définition de la couche 2] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-fdbcc249f6-dd1a6f-69ad2a.webp)
Notez que chaque dimension est mesurée de deux manières différentes (il y en a en fait quatre) : la sécurité extraite peut être mesurée par (i) le niveau de sécurité, et (ii) le nombre d’utilisateurs ou d’utilisateurs bénéficiant du plus haut niveau de sécurité ;
La sécurité de lecture peut être mesurée par (i) la vitesse à laquelle le lien peut lire les blocs d’Ethereum, et en particulier la façon dont le bloc finalisé diffère de n’importe quel bloc, et (ii) le degré d’engagement du lien lorsqu’il s’agit de cas limites tels que les attaques à 51 % et les hard forks.
Il y a de la valeur pour le projet dans de nombreux domaines de cet espace de conception. Pour certaines applications, un haut niveau de sécurité et une connectivité étroite sont essentiels. Pour d’autres applications, des conditions plus souples sont acceptables pour une plus grande évolutivité. Dans de nombreux cas, à partir de conditions plus souples aujourd’hui, une transition progressive vers un couplage plus serré au cours de la prochaine décennie peut être optimale à mesure que la technologie s’améliore.