Indexing Ethereum: When and How to Build an Indexer
Devcon 7 SEA·Wed, Nov 13, 2024, 08:06 AM · 26:07
Speaker
Open source Ethereum Indexers are great for quickly getting your project off the ground. However, there are limits to these tools and in some cases building your own Indexer is the right thing to do. This talk will explore why you might want to build your own and outline a technical approach for building simple, reliable Indexers.
Transcript
... ... ... ... ...
... ... ... ... ...
... ... ... there i know it's the lunch break so thanks really for for being there so my name is arthur i'm a product manager at linea and so like today i will be talking about erc 30 3668 so yeah let's get started basically the agenda is quite straightforward i will explain what it is why do we need it right and how does it work the use cases behind it and i will spend some time pourquoi nous en avons besoin, et comment ça fonctionne, les cas d'utilisation derrière, et je vais passer un peu de temps à parler de l'intégration cool que nous avons fait à 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 other protocols that solve those problems so the main one are bridges right if you must known to if you want to bridge assets, so NFTs, but there are also message bridges that let you send a transaction on chain A and it executes a transaction on chain B. There are also oracles that are well known for price feed mostly, but most recently they have created more generalized implementation such as chain link functions and other. And lately 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 ils ont des contraintes et le le design reflète cela. Donc le premier bénéfice est que ça ne requiert pas aucune transaction à envoyer en chaine comparé à toutes les autres solutions que nous avons mentionnées.
Donc, 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. Alors, laissez-moi vous expliquer comment ça fonctionne. Il y a trois parties à ça. Ça 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 call 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' client va faire le travail de fédérer les données sur un port Http, et le port va envoyer les résultats, et le client va donner la information à l'entreprise, en fonction d'une fonction de réunification.
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 means 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 si 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. 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, postent leur état sur le sur le layer 1 et donc vous pouvez juste acheter une preuve de stockage sur le L2 et ensuite vérifier le sur le layer 1 pour être sûr que le data est correct. 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.linear.
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 l'ENS. Et si ça fonctionne, partout où l'ENS est résolu.
En exemple, nous avons une collection de NFT surs 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 de 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 ensuite vous pouvez 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 de faire accès à 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 poser votre question, comment je dois l'impliquer ? Ça semble vraiment compliqué, vous parlez de preuves et ainsi de suite. La chose sympa, cante 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 charge nous avons un port qui se déroule, nous avons tous les contrats smart, ceux qui vérifient la preuve ce qui pour ZK ce qui est particulièrement difficile pour le ZK Rollup parce que les 2 couches de 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 le team Unruggable qui ont construit des couches d'abstraction supplémentaires qui ont simplifié le processus et qui ont abstraité la chaîne pour que ça puisse fonctionner sans doute sur différentes chaînes.
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'adresse est minimal parce que tous les contrats le gateway tout est déjà prêt pour vous de 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 pause de longue durée où 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 very good question. C'est une 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, Unroguable 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 la même
Automatic transcript — names and jargon may be misspelled.