Zero To Dapp
Devcon 7 SEA·Wed, Nov 13, 2024, 04:22 AM · 1:16:47
Learning Web3 programming. There are so many different tools and protocols to learn. Zero to Dapp is a workshop series that builds upon collaboration between different projects to guide the students from zero to their first Dapp. In this workshop, we review our learning from previous editions to encourage others give their own Zero to Dapp. Then we'll give a shortened version - usually, this workshop takes between a half day up to two full days. But we are fast learners at DevCon, aren’t we? ;)
Transcript
Hi everyone, I welcome you to our session today. I know it's early but I hope you're still ready. I'm really excited to present the workshop Zero to Dapp together with Simon and Rob. The topic is about how, like a new format called Zero to Dep, how to onboard the next wave of builders across the world. Short intro, short overview, I will talk about what exactly is Zero2Dep, how did it started, what can you expect out of this session, what is EthaCRA, and then we have a lot of hands-on experience with the Graph, Remix, and CELO.
Zero to Depth. The name, the first edition started in San Francisco, 2022. It was like a way for everyone who is familiar with Hackathon. It was a way for hackers to have a pre-Hackathon experience, a longer guided format, more hands-on dedicated workshops. Because during a hackathon, you usually have like 30 minutes technical workshop where sponsors are guiding you through how to build on their product.
But usually, even though as a, how should I say, as a new B.O. experience hacker, this workshop is a little bit short. It doesn't really give you enough insights, which is why some organizations start off, hey, let's have a pre-hackathon workshop where we have longer format. And each partner session builds up onto the last one.
That's why I start zero to DAP. You start, and the session, the goal should be that at the end of the session, as a participant, you have built a DAP from the scratch. The format was like 30 minutes, you have a theory, After this edition in 2022, I think it took place in 2023 in Paris, before the ECC Hackathon. And I'm a hackathon aficionado and I picked up this concept and I was like, hey, when I founded EthaCraw in 2023, I thought as a way to onboard especially new hackers, why not having this format as well as in Ghana? And this is where the EtherCRA zero-to-dap edition found its way.
I think one of the added value of this format is also that different protocols are able to collaborate between each other. For example, we had the graph last year and also Remix, and this year we had Circles participating. I mean, the format is the same, but which protocol are participating can differ and vary from city to city. Another way that also adds value is as a hacker, especially if you're not really familiar with the concept of hackathon, we have many hackers that just sign up for the zero to depth, and they feel confident, and then after they sign up to the hackathon, because the hackathon itself can sound intimidating if you're not really familiar with the concept, but if you just come for a one day or two day workshop, gives you a little bit of insight of what to expect. You can also ask Q&A questions with the protocol.
It's a smaller setting. You can also have a little bit of brainstorming, team formation, and based on that, we had many people who also attended the hackathon itself. The format, you can have it in one day or in two days. I mean, in Accra last year we had it one day. This year we decided to have it on two days.
We had a beginner track as well as advanced track. So the format and how the length, et cetera, is pretty flexible, but it should be that the overarching goal should be that at the end everybody, all the participants have finished um building adapt within one or two days are there any questions so far okay now i'm happy to talk about a little bit about ethercraft um i find as as you might have heard i'm a hackathon aficionado. I love attending hackathons. I've attended, I don't know, maybe 15 EthCorp hackathons the past two years. I realized that usually when I go to places, there aren't many women and also not many African people.
And I was thinking, okay, if people are not able to come to places like here in Bangkok or Brussels or San Francisco, etc., why not bring Ethereum to Ghana? This was the idea why it started. And last year, I found a bunch of people. We were like, hey, let's create this hub.
It has never happened in West Africa. And yes, we were taught, like, combine international people with local people and creating a hub for anyone who wants to enter the Ethereum universe and then create amazing project. The reason why we are doing this is I think we also want to bring a little bit a different conversation to the developer ecosystem globally, bring new perspectives, and providing appealing opportunity for companies who are looking to hire people remotely. Because Hackathon is like, I would say, a mini R&D. If you always host Hackathon in the same region, I think usually you always have the same solutions or projects.
But if you host Hackathon in different regions, then you also get new insights on different how people are using your project because people always build what is related to their local needs and solve local problems. And I've been I've hacked in Bogota, I've hacked in New York, I've hacked in Bengaluru, I've hacked where else? Many different places and always Ethereum hackathon, I always thought I will not see something new, but each time when I go to different places, I'm exposed to different way of people are coming up with solutions. I think it's very interesting. As a company, if you're interested to expand, have a more holistic, broader perspective on how people are using your tool, I think you cannot miss hosting hackathons in various regions and being exposed to different needs, different perspectives and fresh new ideas, which is why I think it's a win for those who want to attend hackathons, but also for companies who want to expand a new region.
And as we all know, I think African continent, especially West Africa, is 75% of the population is below 35 years. It's a huge youth population. And I think the future of, I don't know, maybe the tech hub or tech savings is going to be then. It's just right to have an entry point or way to harness this huge potential market. Okay.
And yes, I mean, I said we identified this opportunity in 2023. None of us had really like come from an event organization background. I think we are just very curious people. But believe me, if we knew what it would expect us, I don't know if we would have done this, but we are very happy. I think we have grown as well.
And last year was a huge success, which is why we did again the second edition and popular demand, we will do a third edition as well next year. So if you're interested to attend a hackathon outside of the popular path, you're highly welcome to attend Accra in West Africa. We do annual hackathon, but we also collaborate with existing communities, for example, Python Ghana, React Ghana. These are existing Web2 matured communities, and when you collaborate with them, I think we can leverage on their synergies. Also Swiss Embassy in Ghana also got notice of us, and they also supported us.
As a way to prepare people or like bring awareness to what the hackathon is, we did a campus tour. We went to different universities in Ghana but we did like I would not say road show but like we did a technical and non-technical workshop there. The main target audience were the university students. Last year we did like two universities, this year four, and it has spread the word that universities are reaching us to ask that we should come to their campus and do like Ether Crown campus tour. Also and next year we are planning to do like when they have like a spring break we do a week-long technical workshop.
So the demand and the need and the interest is very high. We were able to participate with quite leading Ethereum projects, like The Graph, Sponsored, Optimism, Celo, Near, Ethereum Foundation, Biddlegiddle, Herdao. They all like the idea, initiative, so the demand and interest is high. We also have started doing more like meetups. I mean, usually people start doing meetups and based on that, they do a hackathon.
We did the other way around. We started bold. We're just doing a hackathon first. And then now we're doing more and more meetups to also have better community engagement. These are a little bit facts and figures.
Like last year, for first time edition, we had quite impressive amount of people, roughly like 100 hackers, 18 projects, 5 sponsors, thank you US dollar. We're able to scale it in a good way. I think for our mission, our goal is to have it slowly but steady. For us, it's more important about quality than quantity and we're happy about the turnout of this year so the numbers speaks volume we are going to do a third edition definitely and we want to build on these successes and then who knows the future might be that some amazing unicorn projects the idea started at the hackathon in etherthaca, maybe 2025 or beyond. Are there any questions so far?
If not, then I think I can pass it on to my next speaker, Rob. And he will talk about more the hands-on practical experience. Hello, Bangkok. Oh, I need the clicker. I need that to electrocute myself if I spell the T.
The next slide is not that. The next slide is wow, I thought there was another next slide. There. So I work at Remix. It's an online IDE.
And if you want to do a zero to dap workshop and want to join our community of zero to dap workshop organizers, take that telegram group and we can support you, give you some ideas about how we organize the projects we've done before, and maybe even send you some Sipoli ETH for all your hackers or hook you up with other projects or anyway. so there's that. And the next one is on to Remix. So just so I get a sense of who's here, everyone knows what a smart contract is? Or no?
Oh, good. Okay. And of the people that know what a smart contract is, has anyone ever deployed one? Okay. Okay.
And has anyone used Remix before? Well, it's going to be a review for the use. But anyway, here we go. So we're going to basically, like, first when you start up Remix, well, first you've got to know the URL to start up Remix. Otherwise you're sunk.
And then just so you know a little bit of the layout of Remix, like there's this part over here, there's icon panels, and that's where you switch out the plug-ins, which are over here. Here's a console. Here's a terminal. And there's the home tab. And when you start writing code, the code's going to appear in the home tab, in a tab in the home tab, something like that.
So you've got to get some templates. It's an easy way to start if you just want to start looking at what some code looks like. And maybe that's better. And so to get the code, you, oh, look, I can look over here. You go to the hamburger menu.
And actually, that's another question I had. Because I do DevRel and I'm writing all these docs. Does everyone know what a hamburger menu is? Okay, okay. So you click the hamburger menu, and then...
Anyway, that's what the File Explorer looks like. And then you click the hamburger menu, and if you do that, then you get this pull-down menu, and then you can select Create Using Template. So it's creating a workspace. So in Remix, files are in workspaces. And then you can select the template you want.
That's an ERC-21. So typically in a zero-to-dap workshop, there's someone like me that gets up and rambles away, and then you kind of catch what you catch, and then you go and you do some of your own work on it. Like you'd use a tool, I'd give you a recipe to follow, and then you could play with it on your own and then the next speaker comes up and builds on it. And so in Simon's one when he talks about the graph, using a ERC20 project so we would get one in Remix and then deploy it. But now I'm just going to give you a quick run through of Remix and then deploy it.
But now I'm just going to give you a quick run-through of Remix, and then I'll show you on the tool, and I'll fumble around on the tool, and we'll see if it works. So then you can also clone GitHub repos into Remix. You can...what else you can do? Yeah, so it's simple to get a GitHub repo.
You can also grab verified contracts on Etherscan and bring them into Remix. You can go to the Open Zeppelin wizard and open in Remix button. And you can also go to, you can write your own code. Just like click that icon there in the top of the file explorer underneath the workspace pull downdown menu. And in Remix, it's important to know, like, it's an online IDE, so there's no setup.
But also it means that the files are stored in browser storage, so you have to know that. And it can, you know, if browser storage gets corrupted, then you lose your work. So either you've got to push it to a repo if you want to save it, you could download it to your computer, or... yeah. Or you can work with RemixD, which is a little script that runs locally that allows you to share a folder on your hard drive with the browser.
And also, we have Remix Desktop in beta right now, so you can work with Remix offline. And just so also, like, in Remix, there's a lot of plugins for lots of additional functionality, and you go to the Plugin Manager at the bottom there. And so you kind of click that, and you choose the one you want to activate, and then it will activate it, and the icon will appear on the left column there. So you get the file you want and you want to compile it. Oh look, another member of the Remix team coming in the door.
So you compile the active file from the active tab in the main panel and you click the compile button and what's that oh yeah there are multiple ways to compile you can you know click the play button you can click compile you can go to the what you call it solidity compiler andiler, and click it there. Or you can do just Control-S to compile. And then after it's compiled, then you can grab the ABI, which is important for making your dApps. And then you deploy. And run and deploy panel is a little dense, but it's important to get to know it.
You choose the environment. That means what chain you're going to deploy to, a local chain or a chain using a browser wallet to connect to a public chain. And then you can add value to your transactions, which is over here. And then you can select which account you want to use. And in the Remix VM, which is the local chain inside the browser in Remix, over here.
And then you can select which account you want to use. And in the Remix VM, which is the local chain inside the browser in Remix, it gives you 10 accounts with 100 Ether each. And you can also deploy to different environments. You can deploy to local chains. You can deploy using MetaMask, which is using or whatever browser wallet you want, using Injective Provider.
And then there's other ones we check, the bottom one which says customize this list. And then you can go to another tab and so anyway. Then you click deploy after you've got the file compiled. And then it appears below in this deployed contract section. And you get this little green thing with a button there.
And if you want to debug it, you can launch a debugger section by clicking on the debug deployed contract in the deploy and run, you get this kind of pop down menu or this accordion and then orange buttons are for where you're saving to the blockchain. Blue buttons are just read functions and red ones are payable functions. And then you can open each one of those up further, and if there are multiple inputs, you can dial that thing down, and then you can put the inputs in individually, and it tells you what the input type should be. And then you can copy the address there, and now you can even pin the address. So that next time you come back to Remix, you can get that easily.
Then the other part is contract verification is very important. And so people can read your source code. And to do that, you've got to open up the contract verification plugin down in the plugin manager. And then it comes up, and then you can verify on multiple verification services. And then this verification plugin has multiple tabs, and so you can verify on one.
If you're using one of the services like Etherscan, you've got to put in your API key. So then you go over to the Settings tab and put that in and then come back to the Verify tab and verify the contract on the chain that you deployed it to. And then there's also learning things in Remix because when you're learning, you've got questions. So you can ask Remix AI. So there's a bunch of ways Remix AI works.
There's code explanations, like explain a contract or block a code. You can get coding assistance, like when you're coding, you can say like, write a function that counts to 50 or whatever you want. And then you can get coding completion while you type. So in the robot icon up there, it'll explain that contract. I'm kind of whipping through it so I can just show you quickly in Remix when I get to that.
that contract. I'm kind of whipping through it so I can just show you quickly in remix when I get to that. So anyway, that will explain the contract. And right now it will appear in a new AI assistant panel. Right now this is like the previous version, so it's appearing in the terminal.
And then you can get AI to help you with compiler errors. So you just click that AI button, and then it'll give you the answer in the AI Assistant panel. Right now, it's in the terminal. So you can get explanations initiated from that robot icon, but also when you click on some code. And what you got here?
Oh, yeah, so you can explain this code. You can explain this function. And then you can also get coding assistance on request. But to do that, you need to turn on the switch. There's a lot of little things hidden around Remix.
So you turn on the switch, and then you can, inside a contract, with the three slashes, you can say, like, write whatever you want. What's that one say? Yeah, and then... And when you're... Each time you ask it to do this, it will give you a different answer.
So if you don't like the answer it gave you, then ask again. And then there's code completion, and sometimes that could get annoying. If you don't like it, then you can turn that off by switching that top thing, the top switcher. And then there are Learn It tutorials, which are tutorials inside of Remix. I just wanted to put this little note here.
See this little icon up there? If you click that, then the plug-in will bounce over to the right side of the panel. So then that means that you can be getting the instructions on one side and doing the work on the other, and it should be super fun. Then we have this remix guide, which you can either get to from the plugin manager or from the home tab, and they get a bunch of videos and they're a bunch of low-level solidity videos which are kind of complicated there's some just intro to remix videos there's some intro to solidity videos knock yourselves out and then you could ask somebody and a good way to ask somebody who especially is not next to you, is to send them a gist. So you can just do that pretty easily just from the File Explorer, and right-click, you get this pop-up menu, and you get a gist.
And your gist is ready. Okay, so now I'm going to show you how to deploy a contract in Remix. I think I can do it like this. Oh, did I? Yeah.
Look at that. Okay. So here we got Remix. And you can see it's in, there are different themes in Remix. You can go to the settings tab and switch that if you want.
And this one's set up with the ERC20 contract. But here, I'll make a new one using a template. And then we're going over here and then we're going to set an ERC20 burnable, mintable, we're going to create it, and it's going to load. And then, here, look. So then it loaded all the dependencies.
So just to note, to do the dependencies with the import statements, if it's importing something that's on npm package, you just do it like that. Remix will grab it from unpackage. And then you got that. Here, I'm going to compile this using this little button. Here, look, it compiled.
But going into the Solidity compiler, you go here if you want to switch your Solidity version. And if you're loading some old contracts, you probably need to change your Solidity version. And so that's loaded. Yeah. And here's the ABI if you want to grab that.
Here. And then we're going to deploy to the local VM. Here I'm going to grab my contract because I'm going to mint it to myself. Put it in here. Here, but I'll dial this down.
Ka-chunk. Transact. So you can see that. And then so add address is when you want to access an already deployed contract. So, if you just have the right chain connected, then you can...
And you have the ABI, then you can pull in a contract or the source code. You can pull in a contract from... That's already deployed. And so, yeah. So, look, it's interesting here.
There's like a bazillion functions here. Okay, so now we're going to deploy to a public net. And we're going to do that with... What's going on here? Oh, got to customize this list.
So we enabled injected provider. And then we're going to... And we're connected to Sepolia. But if we wanted to connect to some other chain, we click here, and we go to Chainlist. And Chainlist, you just put in the chain.
If you want to deploy, like, to scroll Sepolia, you put scroll in here. Scroll. Well, you get the idea. Anyway, you can get there, and if you click the one that you select, it'll configure the browser wallet, and then you don't have to put any RPC stuff. It just does it automatically.
And what else? Yeah, okay, so we're connected there. We're going to deploy here. Now it's going to want approval. And I'm going to give it approval.
And you have to wait, because it's pending. And maybe when the Internet is slow, it takes a little while. Oh, did it happen? I think it did. Yeah.
So now we can see the functions from this deployment. Just also note that here's the EVM version, and you can select the EVM version back here in the advanced settings. But anyway, so we've deployed it here. And just quickly, just so you have this little secret thing here, is you can quickly make a dap here. You click that.
And you can quickly just deploy this to this dap on surge. You can make a free account. You can put in your name of the dap, some instructions. There's like a million functions. And maybe you don't want to show them to somebody.
You just want to show a couple of functions. So you just select the ones you want. You can get rid of that. You can move this one over here. Then you put in username and password.
And then when you hit deploy, you'll have a URL outside of Remix that you could just pass to someone, and then they can check out your functions. And if it's a verified contract, then you can open up the code. Someone can open up the code back in Remix. You got a question? It's better.
Yeah, I know there's a way to verify a contract on Remix. Do you want to go over that? Sure. So I just deployed this here onto Sepolia. And then I'm going to go to the plugin manager and go down to contract.
I'm going to search contract verification. And so you can... We're going to select Sepolia. And it's this contract. And this is asking if it's a proxy contract, but this one isn't.
And EtherScan is not enabled here because you need to put in the... What? Ah, don't worry about it. I mean, if you wanted to do it, you could just go to the Settings tab over here, but it's not going to... It's not that important.
I mean, you could do it or not, or... Anyway, so... We're verifying it. Oh, valid contract address. Oh, I see.
Okay, maybe this wasn't the... I'm going to put it here. That was not a valid contract address. Wow, that's tricky. Okay.
Copy the address. Oh, I see what happened. Okay. So anyway, go back to contract verification. Let me take this.
Grab it all, delete it and paste it. Now we'll try. Will it work? Oh, valid contract address. Didn't like it.
Okay. Is this the API key again? Nope. Okay. We've got the verification in the verification receipt section.
It's not going to be on Etherscan because we didn't put the API key in, it'll be on Etherscan. So we have four different verification services. And also, Sourceify is interesting because if you just deploy the, if you publish the source code on IPFS and you deploy, it'll find the source code on IPFS and you deploy, it'll find the source code on IPFS and it goes through all deployed contracts on a lot of chains, so you don't even need to do anything. But if you don't publish the source code, then it's not going to give you a full match. I mean, it's not going to work on Sourcefy.
Any other questions? Yeah, there's lots more, and you can check the Remix docs here. There's kind of like a little trick here. If you want to just go right to the docs, you go here, and then you go to the documentation, that little thing, this little fold-up thing at the top, and what else? My tokens here.
Okay, anyway, I think that's good enough unless anyone else has any questions. Yeah? Often that's because there's a kind of error in the code. Oh, the other thing is after you compile, like, not doing it here, but you often see the gas fees on each line, on the contract line. Anyway, but there could be, or you can also go to the gas section to, let's see, over here, and up the gas.
You have to click custom to up the gas. But it's often indication of something else going on. Here, and I'll just show you a quick, we'll make a little compiler error here, and we compile it. And we'll go back over here. We see the error.
We go over here and we go to Remix AI and we see, we'll get the answer over here. Quite a thorough answer. So, that's what I got. Simon, I pass the torch. Yes?
Is it similar to Cursor? It's totally different. It's a totally different code base. And what's what model? Oh, the AI model?
It's CodeLlama. Yeah. Cool. Thank you. Rob?
Hi. My name is Simon. Do you still hear me? Yes. Okay, cool.
Yes, so thank you, Rob. So the idea of Zero to Dapp, as I said, it's kind of building up. So foundational usually is to learn about smart contracts and when you go into adapt development, but then we can have building blocks going on top, like I'm working on the graph protocols or the building block that I think is the next is using the graph to index that data from the blockchain. So we can quickly run. Thank you, Rob, again.
Through some slides, that explains how to access it, but I want to emphasize here, like in the zero-to-depth context, like having the graph is one idea. It could be other things that get data into your front end or other protocols that you can build on top. Like we had zero to depth setups where after the graph maybe tenderly came to present, or we had like polygon that showed how it works on that chain. Maybe we also worked with wallets and so on and so forth. So that's basically open.
The idea is just like that. We run through in one course and that each session builds on top of each other so that people that really take the time sit in, that they end up with something that is working. And also to showcase how nicely actually all these different protocols and projects play together because we're kind of on the same chain and have this interoperability the Lego blocks. I think it's very nice. Anyways, so as I said, my name is Simon.
I do developer experience at Edge Node. It's one of the core that's working on the graph. And quickly, who knows what the graph does? I can run through the slides. Basically, it's about accessing blockchain data.
So when we think about data on the blockchain, when we send a transaction, we always pay gas to incentivize the validators to bring that transaction into the chain. So that's why people run validators, because they can get part of that gas, or actually they get block rewards, but you know what I'm talking about. But when you want to read data from the blockchain, there is an interface called JSON-RPC that helps to get data directly out of the blockchain node, but it is not an optimized way of getting data out. It's a very low-level interface to get data. So that results in code like this.
It's actually a project that asked me at some point, like, hey, we have problems in our front-end. It's very, very slow. What can we do? And when you look through it, if you understand JavaScript, do you understand JavaScript and TypeScript? Good.
Yeah, then you see there are all these await statements, and all these await statements, it's kind of like the front-end code works with a JSON RPC endpoint, and they wait until the results come, and let's say, and this is just like showing NFTs. And if the person has 10 NFTs, that he can easily take like a second or two to load. And I mean, we are used, like if you are using Web3 or decentralized applications on an everyday basis, kind of like, no, it takes longer always, like very long. But like the next wave of people that comes in, they will probably like after a second say like, ah, this page probably doesn't work. So we need to work on this.
So one of the things that people started to do is building their centralized index, kind of like setting up servers in their server farms, whatever, or connecting to service providers that do it for them or whatever, and build that thing. And it's okay. I mean, it works. But on the other hand, a lot of these properties that we were looking for, if they center technologies are a little bit circumvented like that, I mean, it works. But on the other hand, like a lot of those properties that we were looking for, if these technologies are a little bit circumvented like that, I mean, if that server goes down, basically the application is unusable anymore.
It's also the single point of censorship. Like if there's any problems, then it can go down. But there's also often a vendor lock-in, especially service providers that provide such a service, they might or might not just change the service, change the API, change the pricing or whatever, and if you build an application on top of something like that, yeah, that can break. So that's basically a little bit where the graph, if subgraphs sit. So having like a decentralized network of indexes that basically care about that problem.
They run graph nodes, which is a fully open source MIT stack that you can also run on your own data center or local machine for development. But it is in a decentralized network. It's there and it's running, so you don't need to care if you don't want to. There are over 9,000 subgraphs published, so basically every big protocol has a subgraph on the graph network. So that's pretty cool.
It's an easy way to have data accessible. And then we end up with this paradigm that the UI sends the transactions directly to the blockchain via JSON-RPC. Then the JSON-RPC works pretty well. And then the subgraph basically watches those contracts, sees what's going on, writes it in the store, and then the UI can read from the subgraph. That's the thing.
The graph is, as I said, it's a decentralized network. It consists out of 110 indexes across the world. The big number of delegators, curators, not so important as a developer, but actually also subgraphs. It's almost like a 10K subgraphs right now. So like if you develop your new contracts, usually you write a new subgraph, but if you're interested in just getting data out of what's going on, then there might be already a subgraph that gives you that data.
But in this zero to dApp, what we do is we build a new contract. Yeah, you can think of subgraphs as something like this. There's this huge array of things of data on the blockchain and it's unordered and we want to bring it in order and so that's where subgraphs come in. Or when we go through to the example from before, like this ugly JavaScript query that we saw or JavaScript code, we can have GraphQL, but it's just like one transaction and to a graph node or an indexer, and then we have the results. It usually takes, I think, our average response time currently is 150 milliseconds, so that's as snappy as we would like to have our applications be.
Yes, and the subgraphs are customizable APIs, so it's code. So they're written in code. The code is called assembly script. It's similar to TypeScript. It has some quirks, but usually it's easy, learnable, and that whole technology by itself is like, as I said, it's an industry standard.
It's open source, and by writing subgraphs, it's also then able to publish it to that registry, the Graph Explorer, and so it's a little bit of a marketplace of data sets, or a collaborative registry of data sets that have blockchain data. And if you write a new contract, you can bring your subgraph also to that registry. Yes. write a new contract you can bring your subgraph also to that registry. Yes, so as I said, there's the Graph Explorer to explore subgraphs, but we mainly look at the graph.
com studio. Yes, so like in the workshop of Rob, who was actually following and also deployed an ESC20 token right now? What said someone? One? Two?
Nice. Two and a half. Okay. So, zero-to-death workshops usually take a day or two, and today we do it in an hour, or an hour and a half. Zero to death workshops usually take a day or two.
And today we do it in an hour or an hour and a half. So usually we are there and say, okay, now you follow here and click here and deploy and stuff. And then we have mentors around that help people to sit down and they're blocked. Unfortunately, we cannot do it here. So we run through the theory and some people might be able to follow, some people not.
But yeah, there will be the hackathon on the weekend, and I will be there, and so you can just try to do it there. But I'll show you how it goes. So I also shared the slides in the Telegram group, because I also made screenshots, but I tried to just do the live demo here. I also share the slides in the Telegram group, because I also made screenshots, but I tried to just do the live demo here. So when you go to the graph.
com slash studio, here you can sign a message to login yeah, that's my test subgraph, but usually there is here is a button to create a new one, if there isn't any I can create one, I can give it a name live devcon actually the best practice is to I can create one, I can give it a name, live DEF CON. Actually, the best practice is to give it a proper name, with spaces and capital letters and that stuff, and then here you will see it created that slug. And then when we have that subgraph in the subgraph studio, there's basically the instructions here on the right that you could just follow in order to get started with a subgraph. And it's actually pretty easy. So I go in my terminal here.
make it a little bit bigger. So that's the first command. I run this, so I'm getting the latest GraphCLI to verify that token here. Here. Here?
Yeah, I want to know from the owner, actually. Here? Ah, no. Okay, right. Thank you.
It's good to have experts in the room. Like, that always helps. Okay, so I can go over, get the contract address, and then the deployer address was probably... I can get the owner here. The deployer address was probably...
I can get the owner here. Nice. Okay, if... So you had that question, right, about how to verify an ether scan. So we did it.
So you need to have an API key added to Remix, and then it should work. Like the quirks are you need to find the contract address where you deployed it when you do it the first time. I probably spent an hour once to find it again. And you need to know the deployment arguments that you gave. One of the workarounds for me is I started to write contracts without deployment arguments at all because it's always just a hassle to verify them.
But yeah, everybody finds its own ways. But now what's important for starting to write a subgraph, what I wanted to say is, like, you need to have a verified contract on Etherscan at the moment. Like, we're working on integrating, especially with Sourcify, since this is this canonical open code source code registry but unfortunately as the state is right now ETHOSCAN has the most verified contracts and so this is wrong but having said that I think now we should have the latest graph CLI installed that looks good and then we basically just follow the steps here. So we do graph init live DEF CON. And that dialogue, is it visible?
That dialogue, yeah, kind of forces us to go through some questions. So the first is the protocol. So the graph also supports other blockchains than Ethereum, but we don't care. It's DEF CON, only Ethereum is important. Then the subgraph slug is...
So Ethereum here means EVM compatible, actually. So the subgraph slug, we take it from here. See, I said there's this slugify thing going on. So it's lowercase and dashes for spaces. But it's all automatically.
Then we can get a directory. I usually just go with the one that's there. And then we can select the chain. And it's like most EVM-compatible chains are around. We go for Sepolia.
Here we go. And now we need to have the contract address again. And since we have it here, we can get it over. And now, as you see, it fetches the ABI. It fetches the star block.
It even fetches the contract name directly from Etherscan. So we don't need to do much. The star block also is here. My token. And then the last question is like index contract events as entities, which scaffolds out the whole subgraph like database schema, mapping code and everything that just indexes all the events.
In my opinion, this is already... Come on. Accessibility shortcuts. Maybe because of the... I don't know.
It's probably because of the pointer. Interesting. Where was I? So, yeah, so we have it scaffolded out. Yeah, now actually I can show you quickly how that looks like while it's installing in the background.
So a subgraph basically is just like a simple Node.js project. You see there's a package.json file. There is a, yeah, it's a package.
json file with some commands, like there's some dependencies. But then what I do when I look at the subgraph, I look at the subgraph YAML. This is what keeps everything together. So it says what we said before, like which contract address is it? Where was that contract deployed?
So we don't need to look at blocks that are older than the deployment block. Which network are we, which blockchain thing do we have, is it Ethereum or something else, and more. There's a whole documentation about what we all have here, but like here I said, these are the event handlers, and for the contracts, for the ESC20 contracts, mostly important is the transfer event. So with the transfer event, we can basically reconstruct everything. Because in the transfer events, we see the mints, that they go from address zero to some address, and then with an amount, and then when tokens are sent around.
So that's basically it. But the orders are here, depending on the contract that you write, that's all scaffolded out. Then there is a database schema, so the schema is GraphQL. Think about just the database schema. For everybody that knows about database schemas, just table definitions with just table definitions where event stuff is stored.
And again, for the transfer, we see there's an ID, there's a from, it's encoded in bytes, which is an address, a to encoded in bytes again, the value, like how much tokens changed hands, and then the block number when it happened, the block timestamp when it happened, and the transaction hash. So these basic building blocks already would help me to write the frontend to just displace all the transactions that happened on that token. Also, some code is auto-generated here. You see it's in TypeScript. For those that are able to read TypeScript or JavaScript, it's pretty simple.
So this is a good starting point. I don't even touch any of that code. It's just a boilerplate, but I want to quickly show you how that's organized so that later on you can go crazy and do your own stuff if you want. Because we ran this thing, so then we just go further with copy-pasting out the authentication. Please don't steal my API key here.
I know the session is recorded, so I need to change later. We did already go into the directory, so we don't need to do this. Then there is this graph coaching and graph build. There's some auto-generated code out of the schema and of the manifest, like that YAML file that we looked. There's some helper code created and then like the whole thing in the end is compiled down into WebAssembly.
The good thing about WebAssembly is that it gives us a very robust sandbox so that the indexers don't need to be afraid of running your subgraph code because like some smart engineer tried to hack some stuff in. So the assembly script is really a secure sandbox. And then I can just simply run graph deploy live DEF CON. That's it. I give a version number, so I go with the default.
And that's it. And then I see here in the UI, it starts in the background to sync. We did not do any transactions yet. So we don't see anything. See, like when you go on etherscan and look at transactions, it's basically only deployed.
So it would be a little bit more interesting if you have any transactions, right? So we can go here. Was it? Yeah, it's mintable, right? Yeah, you create a mintable.
So how do we do that? So let's say we mint ourselves some tokens. Yeah, some. And what happens if I mint? Where do I see the problem?
Let's see if we can send it. unauthorized account no, I know. So the owner is set to another account. Probably set the owner to the injected account. This one.
Yeah, 5B. Do we have the private key of that account? Is it the normal one that also Scaffold Eve uses? I have no idea. I don't think it's the same one.
also scaffold Eve uses. Thank you. No, it's not. I have them. Okay.
How much time do we have left? I need two minutes and then I can fix it. Or five. Okay? Let's do it again.
Thank you. Vielen Dank. Okay, I redeployed the contract and now it's pretty simple. I just need to change the address here in the subgraph YAML so that it points to the new contract. And then I can redeploy my subgraph, go a version up.
Actually I would not even have to verify it like this. Because the subgraph, it just needs to have the ABI of the token here, and the ABI didn't change. So if you have the ABI and the contract address, then we can spin up the subgraph. So anyways, so now we have that thing deployed here. And now we have two entities.
But we can look for transfers. So let's look for transfers. So now we don't have any transfers. As you see, I can go into the playground. And then here on the right, I can open and close this GraphQL Explorer that helps to discover the schema.
But here now in Remix, I can actually send transactions. So this is the new contract. So now I try again to mint myself some tokens. Now it's working. Nice.
Boom. And we see the tokens here. Whoo, it worked. Always these live demos make me sweaty hands. Okay.
Yeah, I'll share these slides later on in the Telegram group that we have. If you didn't join the Telegram group yet, I'll get the QR code up again. Wow, so many slides today. Sorry. This is the QR code.
I will share the slides in the Telegram group. What I also have shared in the Telegram group is Google Sheets. So what we do usually at this work, or like one way to run the workshops with participants in the room is to really walk with them through the steps until they each deploy their own ERC20 token on Sepolia. So we have like a shared or like whatever testnet you want to work with. And so everybody has that token and then we ask them to add their EOA or the address that they use to deploy the token and the contract address into that Google Sheet.
Right? And then we have a Google Sheet of all the participants the address that they use to deploy the token and the contract address into that Google sheet. And then we have a Google sheet of all the participants that have the contract deployed. And then we can tell them to send now around tokens to each other. And that works.
And then each has then a subgraph that tracks its token. And then we can see the shared state that we work on. So I added an example Google Sheets there. If you want, you can also do that today or later or next week or whatever and ping me and then we can maybe do that. But that's what we do in a live setup.
Also the Telegram group. But I will also share the slides later on so you can build on top of these slides. But I think the last slide of me is yeah the screenshots of everything but yeah actually there is also like then the next step usually is now we have a smart contract, we have now a subgraph, is building a whole front end, or a whole UI, whole application. And for that, we partnered up with Scaffold Leaf. Scaffold Leaf, they have a bunch of different sessions here, workshops, I think one runs right now in parallel.
I really can suggest to check them out. It's a very, very cool project. But what's important from here is that there is a plug-in to scaffold out the scaffold.if project with a subgraph already included. So that makes it very easy, and it's very well integrated.
It's just this one command, like basically the normal command plus a dash E and then subgraph, which includes that. And they also work on other plugins, so like there's a group of plugins, or if you're working for a protocol that wants to be integrated with Scaffold Eve, like you can also reach out to them and integrate your stuff too. Yeah, check it out. I think that's it from my side. If there are any questions, we can also do questions.
Let's see if someone posted a question. Is question QR? Okay. Yes, please. .
to interact with the deploy smart contract. Now, at this level, you're introducing the subgraph. So at which level can we place subgraph? What is this really used for? I would like to really understand why we need it in the process of developing.
Is it for performance? Yes. So, yeah. I mean, the presentation is not that much about showing what the graph is, more about the zero to that, but I can go into it quickly. So, yes, it is possible for a UI to directly get data out from the blockchain with JSON RPC.
That's possible. That's also usually what people learn first. When you look at Scaffold Eve without the subgraph plugin, that's what you end up. As I said, here in this problem statement, getting data out via JSON RPC at scale gets problematic pretty quickly. So you end up with code like this.
So you send a lot of asynchronous queries to the JSON RPC endpoint trying to get that data out. Maybe you get it into your front end, then you try to crunch it together in the front end, and you end up with slow and complicated code. And then the first step is usually that you think about, like slow and complicated code. And then the first step is usually that you think about like oh maybe I should have my own server and then have your own database and then you store it then you run all that stuff and do stuff in your database on your server that you run somewhere on AWS or whatsoever but then you are again basically locked into that system that you build upon and where you host your servers, or if you're on AWS, maybe Jeff Bezos wants to raise prices, or whatever, or for whatever reason they do some IP blocking, or, you know, all that stuff that we see. But with subgraphs, or other indexing technologies like the graph, there's a possibility of building on top of industry standards that help you to have that data available for your front end.
Does it answer the question? Okay, thank you. Please, another one. Yes. Yes, once I deploy the subgraph, is there a possibility to know or to query the event that occurred before the deployment of this subgraph?
Okay, which events are you particularly interested in? No, I just want to understand. I mean, like, if you want to, for example, I can imagine that you're interested in other contracts events, right? Yes. Yes, then you can...
It's basically go to this subgraph YAML, and then you basically copy-paste the whole data sources here. Create a new one. And then you change that contract address, that star block, and then you basically tell the subgraph, hey, there's another contract that I'm interested in, maybe you want to look at these events too. Okay, thank you. Other questions?
There is one in the front. It's a simple question. What is the difference between subgraph and graph node? Node graph. When we deploy a subgraph, is there a graph node deployed behind?
Yes, so the graph node is, as I said, it's a fully open source software technology written in Rust that runs usually alongside an archive node of Ethereum. And the subgraph is a piece of code you can think of that's compiled into WebAssembly and then deployed to a graph node. And the graph node runs the subgraph. And while running the subgraph, it's basically a set of instructions to tell the graph node what data to get out of the blockchain and how to store it in the database and how to give access via GraphQL to other people. So the graph node is basically the run, the execution environment for the subgraphs.
Thank you. Wait, you need the microphone for the recording. So how does the pricing or the fees work for subgraph? Do you pay with some transaction fees every time you make a read call? Like, you can run the graph by yourself, as I say, it's open source, but if you're using the graph network, there's a paper query.
Oh, okay. Got it. It's basically you put money into the system and then it deducts for you. When does graphs start to make sense? What scale of data are we talking about?
It depends. I know. I personally like to start with the subgraph immediately. It also helps to write smart contracts a little bit more lean because, like, in my experience, a lot of smart contract developers, they end up writing functions that you only need them for data access. But you can skip those, make your smart contracts a bit more lean and more focused, and already start with indexing solution from day one.
But it also depends a little bit on your team. I mean, I'm more of a full-stack or front-end developer. I was often looped into teams when you have dedicated smart contract developers. They are solidity people. When you talk to them about JavaScript, then they become angry.
And then it's kind of like that setup, right? And then for me, subgraphs are very useful because it's basically a line of defense because I can build a subgraph in between the contract and my front-end, and whatever they do on their contracts, it doesn't necessarily immediately influence my front-end work, so it also helps with this. But, yeah, I would say, like, maybe if you're really a beginner, like, if it's your first smart contract, then you might not want to already go into the graph, or other technologies in general, although with that step that I just showed, it's also not that hard. Makes sense. And on the flip side, let's say you are a pretty old project, you have a large amount of data on blockchain already, and you want to introduce a subgraph, how complex that is?
Complex or simple that is. Sorry, can you repeat the question? On the flip side, let's say if you're an older project, you have large amounts of data already on the blockchain. Yes. And it's really slow, and you decide to start using subgraph.
How difficult or easy it is to integrate subgraph in your project? Yeah, that's the same. I mean, like what I just showed, like just going through that initialization steps, just having your events indexed is already a big plus, actually. It's already speeding up stuff, and from there you can iterate upon. So I think it's basically a no-brainer.
I mean, yeah, there is some... It's some learning curve to learn the technology, but... But integrating is fairly straightforward. Yeah, that was very often, like, actually the developer journey was like, oh, they come and want to keep their systems lean, which I understand. Usually I also try to have as little dependencies as possible to start a project.
But at some point you run into the scale issues, and then they come but yeah they could also avoid it and have it from the beginning about them makes sense thank you other questions all right thank you so much thank you rob for the invitation thank you abner thank you for coming thank you
Automatic transcript — names and jargon may be misspelled.