Le 8 avril 2025, le fondateur d'Ethereum, Vitalik, donnera un discours principal lors du sommet des chercheurs Web3 2025. Jinse Finance a résumé le contenu du discours comme suit.
Actuellement, le retrait d'Optimism ou d'Arbitrum nécessite un délai de sortie d'une semaine, ce qui pose de nombreux problèmes.
Pourquoi devrions-nous nous en soucier ? Pourquoi devrions-nous nous soucier d'une connexion plus rapide entre L2 et L1 ? Je pense qu'il y a deux raisons pour moi. L'une est l'expérience utilisateur, nous voulons que les utilisateurs aient une meilleure expérience, attendre une semaine est une mauvaise expérience. L'autre raison est que nous avons besoin d'un écosystème plus intégré. Nous devons faire certaines choses pour vraiment améliorer Optimism, Arbitrum, Polygon.
Ces éléments dans le monde d'Ethereum ne sont pas indépendants.
Actuellement, l'interopérabilité entre L1 et L2 est très rapide, mais elle nécessite beaucoup de Gas. Nous avons commencé à nous soucier de ce problème depuis l'été dernier. Les deux choses qui nous intéressent incluent : les adresses spécifiques de la blockchain et les projets d'intention. J'espère que transférer Optimism vers Arbitrum ne prendra pas une semaine, et même j'espère pouvoir mettre Optimism dans un contrat intelligent.
Dans un contrat intelligent, si quelqu'un fournit d'abord une preuve prouvant qu'il a envoyé de la monnaie à n'importe quelle adresse de destination via le contrat, il passera automatiquement à cette étape. Par conséquent, nous espérons trouver un moyen approprié de réduire autant que possible le délai d'attente d'une semaine.
Pourquoi avons-nous maintenant une fenêtre de retrait d'une semaine ? Parce que le Rollup d'Optimism doit attendre une semaine pour voir si quelqu'un conteste son hash, et si personne ne conteste, vous pouvez accepter le hash. L'avantage d'Optimism réside dans la prudence de la technologie sur laquelle il repose, mais cela a un coût : attendre une semaine.
Si nous ne voulons pas attendre une semaine, nous devons établir un système capable de regrouper des blocs en utilisant entièrement un système de preuve non Optimism, comme la combinaison ZK+TEE+OP — c'est la solution de conception que nous proposons.
Dans des conditions normales, une fois qu'une transaction L2 a eu lieu, l'état sera finalisé sur L1 dans l'heure, réduisant 1 heure à 12 secondes, ce qui est essentiellement un problème d'efficacité. C'est donc le premier objectif. Le deuxième objectif est que nous souhaitons que L2 soit sans confiance. Nous voulons prouver que le système peut déterminer l'état correct et enregistrer les états incorrects, même si les composants nécessitant une confiance sont compromis. Ainsi, aujourd'hui, les Rollups sont soit en phase zéro, soit en phase un, ce qui signifie qu'ils placent un certain degré de confiance ou toute la confiance sur un certain comité de sécurité. Vous devez croire que le fabricant peut les concevoir correctement. Vous devez croire que le fabricant ne conservera pas de copies sur la clé de site elle-même.
De plus, vous devez croire que le mécanisme matériel n'est pas quelque chose que n'importe qui possédant du matériel peut détruire, vous devez croire qu'ils ne peuvent pas trouver un moyen, comme un laser ou un scan infrarouge du matériel, d'extraire des informations sans endommager la visualisation.
Maintenant, nous ne voulons pas mettre toute notre confiance dans ZK.
Vous allez répartir la confiance entre trois mécanismes différents qui fonctionnent selon des types de logique très différents. Si nous avons ce type de conception, alors vous pouvez réduire le délai de finalisation de 1 semaine à 1 heure. Au fait, une autre façon est ma vision précédente des systèmes de groupe, que je les divise essentiellement en deux catégories. L'une est la confiance institutionnelle, l'autre est la confiance cryptographique.
Une autre dimension est la rapidité et la lenteur. Les choses rapides peuvent être approuvées immédiatement, tandis que les choses lentes nécessitent une période d'attente. Ce qui est intéressant, c'est que, tout comme ces quatre éléments ici, ils représentent essentiellement quatre composants de systèmes de preuve que les gens utilisent ou réfléchissent dans le contexte de L2, n'est-ce pas ? Si nous pouvons vraiment les mettre dans une boîte, ils s'adaptent parfaitement à 2×2.
Dans un premier temps, nous avons raccourci la fenêtre de la Marche du Diable de 1 semaine à 1 heure. Qu’est-ce que cela vous apporte ? En gros, cela signifie que si vous utilisez un pont natif pour transférer directement des actifs, votre temps d’attente sera réduit de 1 semaine à 1 heure. Si vous utilisez un pontage basé sur l’intention, le pontage basé sur l’intention est instantané, mais au lieu d’avoir à attendre 1 heure, les fournisseurs de liquidité doivent attendre 1 heure. Le coût de l’apport de liquidités a été multiplié par 168. Par conséquent, les frais que vous devez payer seront jusqu’à 168 fois plus élevés.
L2s peuvent utiliser lowlookahead pour lire L1 de manière asynchrone. C'est une fonctionnalité que L2 possède déjà, car ils doivent être en mesure de traiter les dépôts. Nous adoptons le même état que pour la lecture des dépôts et l'exposons à l'opcode L1SLOAD. Il est très précieux de prendre en charge la lecture des données des oracles L1, des portefeuilles de clés et de nombreuses autres applications, car l'un des défis auxquels L2 est souvent confronté est qu'ils doivent payer des sommes considérables.
Ainsi, j'ai obtenu diverses applications personnalisées et intégrations spécifiques. Cela peut effectivement réduire les coûts, car dans de nombreux cas, les alternatives pourront lire directement une copie d'application déjà existante sur une application, ce qui est applicable au traitement des données. Cela s'applique à certaines choses, mais ne convient pas à celles qui nécessitent d'écrire à quiconque.
Un portefeuille de stockage de clés est une autre idée intéressante, n'est-ce pas ? L'idée d'un portefeuille de stockage de clés est essentiellement que, dans la sécurité réseau normale, si vous souhaitez changer une clé, vous ne voulez pas que la clé ait une durée de vie infinie. Neo fait partie des objectifs d'abstraction de compte, et aujourd'hui je vais discuter de cet objectif.
Mais j'ai déjà mentionné plusieurs fois que c'est essentiellement la création de comptes avec une logique arbitraire, ce qui vous permet de faire des choses comme changer l'algorithme de cryptage, changer les clés, les rendre très résistantes et les faire utiliser des snarks ajoutés comme une méthode de récupération. Maintenant, l'un des défis est que si vous pouvez changer la clé, vous avez donc cent résultats après les changements. Par conséquent, vous devez modifier l'enregistrement de la clé actuelle à 100 endroits.
Comment résolvez-vous ce problème ? Nous résolvons ce problème en plaçant l'enregistrement de la clé actuelle sur un contrat central. Ensuite, vous avez une copie du portefeuille qui apparaît sur chaque L2, vous n'avez qu'à lire le L1. Cela rend beaucoup de pratiques de sécurité de titrisation très raisonnables et très similaires beaucoup plus viables et pratiques dans le monde des L2.
Un autre avantage est que cela rend les flux de travail contenant à la fois L2 et L1 plus faciles et naturels pour les développeurs. Nous ne parlons pas seulement de théorie, et d'une multitude de chaînes complètement indépendantes, nous parlons en réalité de la théorie L1 qui continue d'être au cœur des expériences utilisateur des applications et des personnes.
La troisième étape est la preuve d'agrégation. J'ai mentionné auparavant que si nous adoptons cette méthode basée sur deux ou trois approches, ou à l'avenir, si nous effectuons une très bonne validation formelle, et que nous nous reposons uniquement sur ZK, nous pouvons réduire le temps de soumission d'une semaine à une heure. Pourquoi une heure ? Pourquoi pas 12 secondes ? Il y a deux raisons, et nous pouvons aborder ces deux raisons. La première raison est le coût de soumission. Par conséquent, soumettre une preuve à L1 nécessite des frais supplémentaires, environ 500 000 gas, et le coût de l'AA est très élevé.
Maintenant, si vous imaginez soumettre une preuve pour chaque période, cela fait 2,5 millions de périodes par an. Nous devons dépenser 27,5 millions de dollars par an juste pour maintenir une valeur relative, c'est fou. Qui ici serait prêt à payer 27 millions de dollars par an. Mais si vous soumettez une fois par minute, au lieu d'une fois toutes les 12 secondes, alors le coût annuel de 27 millions de dollars devient 5,5 millions de dollars. Ensuite, si vous soumettez une fois par heure, cela descend en dessous de 100 000 dollars par an. C'est en fait gérable. Cette solution naturelle est l'agrégation de preuves.
Si nous avons un grand nombre d’outils différents, alors ces outils n’ont pas besoin d’être soumis à différents groupes individuellement, les preuves en chaîne peuvent être regroupées, les groupes peuvent soumettre leurs preuves à l’agrégat, puis l’agrégat peut soumettre un SNARK séparé pour prouver l’existence d’autres SNARK. Le coût de la vérification du SNARK n’est qu’un coût unique de 500 000 gaz. Ce qui se passe ici, c’est essentiellement ce qu’il y a sur ce diagramme ? Droite? En gros, vous avez un tas de preuves, et ces preuves spécifient également quel contrat. Nous sommes dans un bloc. Ensuite, vous avez une preuve agrégée. Les preuves agrégées sont vérifiées. L’attestation d’agrégat contient toutes les informations d’un seul agrégat en tant qu’entrée commune, puis l’attestation ne se produit qu’une seule fois. Ce contrat n’effectuera alors qu’un seul appel par cumul, et la seule chose que l’appel fait est pour chaque cumul. Il est juste chargé séparément. Le coût par visite est passé de 500 000 à moins de 10 000 gaz.
Il reste maintenant une quatrième étape, à savoir réduire le délai de preuve. Le calcul de la preuve nécessite plus de temps et de puissance de calcul que le calcul lui-même. Par défaut, ce calcul ne doit pas être paralysé. Vous devez l'étendre et vous devez effectuer ce calcul très intensif.
Ainsi, le résultat est que, dans un état d'équilibre, générer un bloc qui prend 5 secondes nécessite toujours 500 secondes pour être prouvé, n'est-ce pas ? C'est un problème. Donc la question est, comment pouvons-nous résoudre ce problème ? Il y a deux idées. L'une est que nous pouvons utiliser du matériel dédié pour l'améliorer. Certaines entreprises font déjà cela. Si vous obtenez un facteur d'accélération matériel de 100 fois, alors vous pouvez prouver en temps réel. L'autre idée est la preuve de super paralysie. Donc, d'un point de vue mathématique, c'est en fait très simple. En gros, vous allez décomposer le calcul en plusieurs étapes. Ensuite, vous générez parallèlement la preuve de chaque étape sur différents dispositifs.
Si cela ne suffit pas, la vitesse d'amélioration du matériel spécialisé sera encore plus rapide. De plus, le coût des améliorations sera également plus bas. Nous avons donc de nombreuses options.
Si vous utilisez Intensive Optimism et Arbitrum, les deux ayant des créneaux beaucoup plus rapides, vous pouvez également terminer en 2 secondes. Donc, ce sera très peu coûteux. Ainsi, si vous utilisez Intensive, vous pourrez transférer rapidement pratiquement une quantité illimitée d'Ethereum à faible coût. Cela signifie également que nous pouvons établir des liens plus étroits entre L1 et L2. Nous avons un monde plus intégré, ce qui rend tout plus facile et rapide pour tout le monde. Merci.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Vatilik : Pourquoi accélérer la vitesse de confirmation L2 ? Comment accélérer ?
Organisation : Wu Zhu, Jin Se Cai Jin
Le 8 avril 2025, le fondateur d'Ethereum, Vitalik, donnera un discours principal lors du sommet des chercheurs Web3 2025. Jinse Finance a résumé le contenu du discours comme suit.
Actuellement, le retrait d'Optimism ou d'Arbitrum nécessite un délai de sortie d'une semaine, ce qui pose de nombreux problèmes.
Pourquoi devrions-nous nous en soucier ? Pourquoi devrions-nous nous soucier d'une connexion plus rapide entre L2 et L1 ? Je pense qu'il y a deux raisons pour moi. L'une est l'expérience utilisateur, nous voulons que les utilisateurs aient une meilleure expérience, attendre une semaine est une mauvaise expérience. L'autre raison est que nous avons besoin d'un écosystème plus intégré. Nous devons faire certaines choses pour vraiment améliorer Optimism, Arbitrum, Polygon.
Ces éléments dans le monde d'Ethereum ne sont pas indépendants.
Actuellement, l'interopérabilité entre L1 et L2 est très rapide, mais elle nécessite beaucoup de Gas. Nous avons commencé à nous soucier de ce problème depuis l'été dernier. Les deux choses qui nous intéressent incluent : les adresses spécifiques de la blockchain et les projets d'intention. J'espère que transférer Optimism vers Arbitrum ne prendra pas une semaine, et même j'espère pouvoir mettre Optimism dans un contrat intelligent.
Dans un contrat intelligent, si quelqu'un fournit d'abord une preuve prouvant qu'il a envoyé de la monnaie à n'importe quelle adresse de destination via le contrat, il passera automatiquement à cette étape. Par conséquent, nous espérons trouver un moyen approprié de réduire autant que possible le délai d'attente d'une semaine.
Pourquoi avons-nous maintenant une fenêtre de retrait d'une semaine ? Parce que le Rollup d'Optimism doit attendre une semaine pour voir si quelqu'un conteste son hash, et si personne ne conteste, vous pouvez accepter le hash. L'avantage d'Optimism réside dans la prudence de la technologie sur laquelle il repose, mais cela a un coût : attendre une semaine.
Si nous ne voulons pas attendre une semaine, nous devons établir un système capable de regrouper des blocs en utilisant entièrement un système de preuve non Optimism, comme la combinaison ZK+TEE+OP — c'est la solution de conception que nous proposons.
Dans des conditions normales, une fois qu'une transaction L2 a eu lieu, l'état sera finalisé sur L1 dans l'heure, réduisant 1 heure à 12 secondes, ce qui est essentiellement un problème d'efficacité. C'est donc le premier objectif. Le deuxième objectif est que nous souhaitons que L2 soit sans confiance. Nous voulons prouver que le système peut déterminer l'état correct et enregistrer les états incorrects, même si les composants nécessitant une confiance sont compromis. Ainsi, aujourd'hui, les Rollups sont soit en phase zéro, soit en phase un, ce qui signifie qu'ils placent un certain degré de confiance ou toute la confiance sur un certain comité de sécurité. Vous devez croire que le fabricant peut les concevoir correctement. Vous devez croire que le fabricant ne conservera pas de copies sur la clé de site elle-même.
De plus, vous devez croire que le mécanisme matériel n'est pas quelque chose que n'importe qui possédant du matériel peut détruire, vous devez croire qu'ils ne peuvent pas trouver un moyen, comme un laser ou un scan infrarouge du matériel, d'extraire des informations sans endommager la visualisation.
Maintenant, nous ne voulons pas mettre toute notre confiance dans ZK.
Vous allez répartir la confiance entre trois mécanismes différents qui fonctionnent selon des types de logique très différents. Si nous avons ce type de conception, alors vous pouvez réduire le délai de finalisation de 1 semaine à 1 heure. Au fait, une autre façon est ma vision précédente des systèmes de groupe, que je les divise essentiellement en deux catégories. L'une est la confiance institutionnelle, l'autre est la confiance cryptographique.
Une autre dimension est la rapidité et la lenteur. Les choses rapides peuvent être approuvées immédiatement, tandis que les choses lentes nécessitent une période d'attente. Ce qui est intéressant, c'est que, tout comme ces quatre éléments ici, ils représentent essentiellement quatre composants de systèmes de preuve que les gens utilisent ou réfléchissent dans le contexte de L2, n'est-ce pas ? Si nous pouvons vraiment les mettre dans une boîte, ils s'adaptent parfaitement à 2×2.
Dans un premier temps, nous avons raccourci la fenêtre de la Marche du Diable de 1 semaine à 1 heure. Qu’est-ce que cela vous apporte ? En gros, cela signifie que si vous utilisez un pont natif pour transférer directement des actifs, votre temps d’attente sera réduit de 1 semaine à 1 heure. Si vous utilisez un pontage basé sur l’intention, le pontage basé sur l’intention est instantané, mais au lieu d’avoir à attendre 1 heure, les fournisseurs de liquidité doivent attendre 1 heure. Le coût de l’apport de liquidités a été multiplié par 168. Par conséquent, les frais que vous devez payer seront jusqu’à 168 fois plus élevés.
L2s peuvent utiliser lowlookahead pour lire L1 de manière asynchrone. C'est une fonctionnalité que L2 possède déjà, car ils doivent être en mesure de traiter les dépôts. Nous adoptons le même état que pour la lecture des dépôts et l'exposons à l'opcode L1SLOAD. Il est très précieux de prendre en charge la lecture des données des oracles L1, des portefeuilles de clés et de nombreuses autres applications, car l'un des défis auxquels L2 est souvent confronté est qu'ils doivent payer des sommes considérables.
Ainsi, j'ai obtenu diverses applications personnalisées et intégrations spécifiques. Cela peut effectivement réduire les coûts, car dans de nombreux cas, les alternatives pourront lire directement une copie d'application déjà existante sur une application, ce qui est applicable au traitement des données. Cela s'applique à certaines choses, mais ne convient pas à celles qui nécessitent d'écrire à quiconque.
Un portefeuille de stockage de clés est une autre idée intéressante, n'est-ce pas ? L'idée d'un portefeuille de stockage de clés est essentiellement que, dans la sécurité réseau normale, si vous souhaitez changer une clé, vous ne voulez pas que la clé ait une durée de vie infinie. Neo fait partie des objectifs d'abstraction de compte, et aujourd'hui je vais discuter de cet objectif.
Mais j'ai déjà mentionné plusieurs fois que c'est essentiellement la création de comptes avec une logique arbitraire, ce qui vous permet de faire des choses comme changer l'algorithme de cryptage, changer les clés, les rendre très résistantes et les faire utiliser des snarks ajoutés comme une méthode de récupération. Maintenant, l'un des défis est que si vous pouvez changer la clé, vous avez donc cent résultats après les changements. Par conséquent, vous devez modifier l'enregistrement de la clé actuelle à 100 endroits.
Comment résolvez-vous ce problème ? Nous résolvons ce problème en plaçant l'enregistrement de la clé actuelle sur un contrat central. Ensuite, vous avez une copie du portefeuille qui apparaît sur chaque L2, vous n'avez qu'à lire le L1. Cela rend beaucoup de pratiques de sécurité de titrisation très raisonnables et très similaires beaucoup plus viables et pratiques dans le monde des L2.
Un autre avantage est que cela rend les flux de travail contenant à la fois L2 et L1 plus faciles et naturels pour les développeurs. Nous ne parlons pas seulement de théorie, et d'une multitude de chaînes complètement indépendantes, nous parlons en réalité de la théorie L1 qui continue d'être au cœur des expériences utilisateur des applications et des personnes.
La troisième étape est la preuve d'agrégation. J'ai mentionné auparavant que si nous adoptons cette méthode basée sur deux ou trois approches, ou à l'avenir, si nous effectuons une très bonne validation formelle, et que nous nous reposons uniquement sur ZK, nous pouvons réduire le temps de soumission d'une semaine à une heure. Pourquoi une heure ? Pourquoi pas 12 secondes ? Il y a deux raisons, et nous pouvons aborder ces deux raisons. La première raison est le coût de soumission. Par conséquent, soumettre une preuve à L1 nécessite des frais supplémentaires, environ 500 000 gas, et le coût de l'AA est très élevé.
Maintenant, si vous imaginez soumettre une preuve pour chaque période, cela fait 2,5 millions de périodes par an. Nous devons dépenser 27,5 millions de dollars par an juste pour maintenir une valeur relative, c'est fou. Qui ici serait prêt à payer 27 millions de dollars par an. Mais si vous soumettez une fois par minute, au lieu d'une fois toutes les 12 secondes, alors le coût annuel de 27 millions de dollars devient 5,5 millions de dollars. Ensuite, si vous soumettez une fois par heure, cela descend en dessous de 100 000 dollars par an. C'est en fait gérable. Cette solution naturelle est l'agrégation de preuves.
Si nous avons un grand nombre d’outils différents, alors ces outils n’ont pas besoin d’être soumis à différents groupes individuellement, les preuves en chaîne peuvent être regroupées, les groupes peuvent soumettre leurs preuves à l’agrégat, puis l’agrégat peut soumettre un SNARK séparé pour prouver l’existence d’autres SNARK. Le coût de la vérification du SNARK n’est qu’un coût unique de 500 000 gaz. Ce qui se passe ici, c’est essentiellement ce qu’il y a sur ce diagramme ? Droite? En gros, vous avez un tas de preuves, et ces preuves spécifient également quel contrat. Nous sommes dans un bloc. Ensuite, vous avez une preuve agrégée. Les preuves agrégées sont vérifiées. L’attestation d’agrégat contient toutes les informations d’un seul agrégat en tant qu’entrée commune, puis l’attestation ne se produit qu’une seule fois. Ce contrat n’effectuera alors qu’un seul appel par cumul, et la seule chose que l’appel fait est pour chaque cumul. Il est juste chargé séparément. Le coût par visite est passé de 500 000 à moins de 10 000 gaz.
Il reste maintenant une quatrième étape, à savoir réduire le délai de preuve. Le calcul de la preuve nécessite plus de temps et de puissance de calcul que le calcul lui-même. Par défaut, ce calcul ne doit pas être paralysé. Vous devez l'étendre et vous devez effectuer ce calcul très intensif.
Ainsi, le résultat est que, dans un état d'équilibre, générer un bloc qui prend 5 secondes nécessite toujours 500 secondes pour être prouvé, n'est-ce pas ? C'est un problème. Donc la question est, comment pouvons-nous résoudre ce problème ? Il y a deux idées. L'une est que nous pouvons utiliser du matériel dédié pour l'améliorer. Certaines entreprises font déjà cela. Si vous obtenez un facteur d'accélération matériel de 100 fois, alors vous pouvez prouver en temps réel. L'autre idée est la preuve de super paralysie. Donc, d'un point de vue mathématique, c'est en fait très simple. En gros, vous allez décomposer le calcul en plusieurs étapes. Ensuite, vous générez parallèlement la preuve de chaque étape sur différents dispositifs.
Si cela ne suffit pas, la vitesse d'amélioration du matériel spécialisé sera encore plus rapide. De plus, le coût des améliorations sera également plus bas. Nous avons donc de nombreuses options.
Si vous utilisez Intensive Optimism et Arbitrum, les deux ayant des créneaux beaucoup plus rapides, vous pouvez également terminer en 2 secondes. Donc, ce sera très peu coûteux. Ainsi, si vous utilisez Intensive, vous pourrez transférer rapidement pratiquement une quantité illimitée d'Ethereum à faible coût. Cela signifie également que nous pouvons établir des liens plus étroits entre L1 et L2. Nous avons un monde plus intégré, ce qui rend tout plus facile et rapide pour tout le monde. Merci.