ERC-3668 on Linea: built-in, trust-minimized L2 to L1 data retrieval

... ... ... ... ...

... ... ... ... ...

... ... ... there. I know it's the lunch break, so thanks really for being there.

So my name is Arthur. I'm a product manager at Linea. And so like today I will be talking about ERC3668. So yeah, let's get started. Basically the agenda is quite straightforward.

I will explain what it is, why do we need it, les cas d'utilisation derrière, et je vais passer du temps à parler de l'intégration cool que nous avons faite à Linear pour bénéficier de ce standard. Donc, peut-être pour mettre le contexte, allons juste parler de comment nous pouvons accéder aux données externes. Je pense que la plupart de vous le savent, mais nativement, une chaîne ne peut pas accéder aux données du monde externe, external data i think most of you knows but natively right chain cannot access data from the external world without its over change of the web but like over the time we will some over protocols that solve those problems so the main one are bridges right if you must known to if you want to bridge assets, so coins and NFTs, but there are also message bridge that let you send a transaction on chain A and it execute a transaction on chain B. There are also oracles that are well known for like price feed mostly, but most recently they have creating more generalized implementation such as like chain link function and over mais plus récemment ils ont créé des implementations plus généralisées comme les fonctions de chainlink et autres et récemment nous avons aussi des coprocesseurs qui sont en mesure d'envoyer ce type de cas de fonction donc la question que vous vous demanderez est pourquoi nous avons besoin d'une autre solution. Et, en fait, ERC-3668, aussi connu comme CCIP-READ, était un standard proposé par le team ENS, particulièrement NIC, parce qu'ils avaient des cas d'utilisation uniques où ils voulaient accéder à l'information pour L2, surtout pour gérer les noms de domaines avec des coûts de gaz plus chers, mais il y a des contraintes et le design reflète cela.

Le premier bénéfice est que il ne nécessite pas de transaction pour envoyer en chaine, comparé à toutes les solutions que nous avons mentionnées. C'est plus efficace, d'une certaine manière, si vous n'avez pas besoin de stocker les données en chaîne, parce que vous n'avez pas à payer les coûts de gaz. Vous évitez aussi l'indépendance externe sur les protocoles externes, parce que c'est un ERC, et c'est sur le protocole mais qui n'a pas de dépendance et une assumption de confiance externe. Je vais vous expliquer comment ça fonctionne. Il y a 3 parties à ça.

Il commence avec le client et ici nous ne parlons pas d'un client d'exécution ou d'un client de consensus mais plutôt des UIs ou des back-ends qui appellent la blockchain et le client appellera un contrat smart, un appel standard, pour obtenir des informations, quelque chose qui se passe très généralement et la partie principale du design de l'ERC3668 est que cela permet au contrat de révertir avec une erreur qui dit au client qu'il faut lui donner un peu plus de données pour qu le client va faire le travail de fédérer les données sur un portail, donc un code standard HTTP, et bien sûr, le portail va envoyer le résultat, et puis le client va donner la information à l'entraînement, grâce à une fonction de réunification. Et à la fin du jour, vous avez une réponse. the information to the contract through a callback function. And at the end of the day, you have an answer. So here I talk about call, but actually the callback function can be also sent in a transaction.

So that means that at the end of the day, you have some logic that can be executed on-chain in a block. The nice thing about this design is that if you look at the off-chain Le bon point de ce design est que si vous regardez les erreurs de données off chain, il y a toutes les informations qui sont là pour expliquer au client ce qu'il doit faire. Donc, en avance, le client n'a pas besoin d'avoir aucune information sur les portes de la portée, information about what what are the gateway to call what is the information that I need to send to the gateway which is the cold data or what are the call back function and so on so this mean that the client can have a standard implementation and you don't need to integrate each time like a specific use case or if you want to integrate like a chain like I don't know optimism and a cas de utilisation spécifique, si vous voulez intégrer une chaîne comme Optimism et une chaîne comme Linear, vous n'avez pas besoin de le faire deux fois. Si vous vous suivez attentivement, vous vous demanderez peut-être que il semble que vous devez croire au Gateway, et grâce à la introduction, nous avons dit que c'était une façon deisé et de minimiser la confiance pour ficher des données. Et en fait, vous n'avez pas nécessairement à confiance dans le portail si le portail offre aussi des preuves de l'information qui a été donnée.

Et la chose amusante à ce sujet est que vous savez que les L2, comme dans le design de Rollup, poste son état sur le layer 1. Vous pouvez donc juste acheter une preuve de stockage sur L2 et la vérifier sur le layer 1 afin de être sûr que les données sont correctes. C'est ce qui est montré ici. Lorsque le Gateway fait le requêt HTTP, le Gateway appellera un L2RPC, lui demander la information, un IF-CALL, et ensuite faire un IF-GET-PROOF pour obtenir le PROOF de storage. Lorsque le contrat reçoit l'information, il appellera le contracte Rollup qui peut vérifier la preuve à un niveau élevé.

Donc je pense que le design est assez cool, mais qu'est-ce que nous pouvons faire avec ça ? Comme mentionné dans l'introduction, ENS était celui qui l'a proposé et en fait, ils avaient un cas de util cas très spécifique à l'esprit qui était de pouvoir gérer les domaines sur L2 pour des coûts plus élevés et c'est le cas principal que nous voyons aujourd'hui un exemple est le nom de l'Inea que nous avons introduit sur l'Inea où vous pouvez avoir des noms comme brian.linea.if ou athor.linear.

if. C'est quelque chose que nous avons construit et qui peut être réutilisé par l'écosystème pour construire une intégration avec ENS et ça fonctionne partout où ENS est résolu. résolue comme un exemple comme nous avons une collection de nfts sur l'inna qui sont appelés ifrogs qui voulaient donner un domaine ens à tous les utilisateurs, donc par exemple, si vous avez un type 743.ifrogs.if, c'est résolu à l'administrateur de cette nft et si la nité est transférée, le nom est transféré avec elle aussi.

C'est cool. C'est juste un premier usage et ça ne se déroule pas là. Il peut être utilisé pour tous les cas de utilisation où vous voulez compter ou stocker des données sur le second layer ou même en chaine et les acc des données sur le second layer ou même sur la chaîne et les accéder sur le premier layer certains exemples incluent le DAO Governance avec des solutions comme Snapshot X qui offrent une vote sur la chaîne vous pouvez voter sur Linear ou sur L2 qui sont plus chers que sur Gaz. Et puis, vous pouvez juste prendre le résultat et appeler ce résultat pour exécuter une transaction sur le layer 1. Un autre cas intéressant, par exemple, est d'accéder à des contrats smarts.

Par exemple, si vous faites un airdrop ou des mintes NFT, vous pouvez demander aux gens de avoir des crédits spécifiques qui sont mintés sur le second layer, par exemple en attestation. Vous pouvez donc vous poser la question de comment j'ai besoin d'impliquer ça. Ça semble vraiment compliqué, vous parlez de preuves et ainsi de suite. La chose sympa, c'est que nous avons déjà impliqué tous les contrats smart. vous parlez de la preuve et ainsi de suite la chose amusante est que nous avons déjà impliqué tous les contrats smart donc toute cette logique compliquée non pas si compliquée mais toute cette logique est déjà prise en compte nous avons un port qui se déroule nous avons tous les contrats smart qui vérifient la preuve ce qui est particulièrement difficile pour le ZK Rollup parce que les 2 layers ZK ont souvent une manière différente de stocker des données parce que la fonction de hash standard peut être un peu compliquée pour ZK donc par exemple sur Linear nous avons SparkVercalTree au lieu de MercalTree mais en fait tout cela veut dire que nous avons des contrats qui sont open source et qui peuvent être appelés pour vérifier les données pour aussi ficher les données directement donc en fait sur le niveau des contrats smart, c'est beaucoup plus simple et en plus de cela, il y a eu des équipes comme l'équipe Unruggable qui ont construit des couches d'abstraction supplémentaires qui l'ont simplifiée encore plus et qui ont abstraité la chaîne pour que ça puisse fonctionner sans doute sur différentes chaînes.

Donc, pour résumer les bénéfices, ERC3668 est efficace car vous n'avez pas à envoyer une transaction sur L1 quand vous n'en avez pas besoin. C'est sécurisé, surtout quand vous travaillez sur un layer 2 avec des prouves de zéro connaissance, comme Linear. Vous n'introduisez pas d'indépendance supplémentaireautre protocole et comme le développement de l'arrière est minimal parce que tous les contrats le gateway tout est déjà pour vous pour construire et donc si vous voulez commencer ce sont des liens à nos documents doc open source triple mais le plus important c'est que nous faisons un workshop juste après la But most importantly, we are doing a workshop just after the lunch break where we will deep dive into really code example and you will be able to have a live version running on your laptop at the end of the session. So yeah, that's it. Thanks a lot.

Just a reminder, guys, if you guys have any questions, you can ask them through Meerkat, scan the QR code. Looks like we already have some more coming in. The first question, is it possible to read L1 data from L2? So yeah, in theory, it's totally possible. Like ERC-3668 allows de ficher tous les données.

L'unique chose, c'est que vous devez avoir le stade de la blockchain que vous voulez enquêter ancré sur la chaîne de laquelle vous voulez... Désolé, je vais y aller encore. Mais vous devez... Sur la blockchain qui enquête l the information, you need to have the state of the blockchain that is being queried and so, like, it's not most roll-up doesn't have that at the moment, maybe at some point we will see, like, Oracle that are streaming this kind of data on-chain but it would be something really cool to build. The last question we have, doesn't it make the process more centralized?

So, indeed, the point of centralization here is the gateway, but if we come back to... Actually, the smart contract can pass multiple URLs, so you have a kind of redundancy here ... so there is no additional stress assumption regarding the accuracy of the data. We have another question. Keep them coming, guys.

We still have time. Does it open up to a temporal attack if the L2 storage proof is not posted on L1 yet? Yeah, that's a très bonne question. Vous êtes conscient que les L2 ne finissent pas chaque seconde ou minute sur les L1. Et donc, en fait, vous n'avez pas le state de L2 avant de le finir.

Donc, sur le ZK Rollup, ça peut être de quelques minutes à deux heures, selon les outils de l'électrode. Pour le roll-up optimiste, c'est comme les 7 jours. Donc, cela signifie que vous devez attendre cette période pour fédérer les données. Donc, il y a cette latence. Mais comme l'espace évolue et nous allons à une finalité plus rapide, j'espère que cela va se faire mieux.

Je ne pense pas qu'il y ait un attaque c'est juste que les clients et les contrats smart doivent être conscients de cette limitation et travailler avec elle en ce moment Quelles librairies implémentent déjà ce comportement ? Ifr.js pour sûr Wagme aussi Un Unrogable crée une abstraction de niveau supérieur pour travailler sur la chaîne, donc vous n'avez pas à vous inquiéter du spécifique de chaque portail et ainsi de suite, comme un développeur qui veut se baser sur son propre portail. Ce sont les librairies que je connais. wants to rely on your own gateway.

Those are the libraries I know. Is there any work latency when reading data? ROMAIN GUYETT- So yeah, it's the finalization latency. So as I mentioned, from a few minutes to seven days if you're on an optimistic rollup. But from the network latency, comme, de la latence de la nettoie, vraiment, comme, c'est vraiment rapide, comme, souvent moins d'une seconde, ou même moins, donc, vous pouvez tester et, comme, type, par exemple, comme, arthur.

lina.if sur votre métamask ou sur la site d'ENS, et vous verrez, comme, que l'antwort est presque