 Cool. OK, I'm Nikhil. I'm the CEO of Alchemy. Hopefully you're here for this talk. If not, you should just stay, because it's going to be hopefully good. We're going to talk about designing protocols for APIs today, and it's going to go into a couple of details about Ethereum and some of the projects that we've done. So quick roadmap, talk about the background, a little bit about what we do, why developer APIs are even important, talk about how to enhance Ethereum, and then go into cheese wizards and a few design principles. So a little bit of a brief background on me. We've been pretty quiet as a company, so just want to share. So my background is actually an artificial intelligence at Stanford. I did a bunch of research there. And previously, my co-founder Joe and I did consumer apps, and one of the apps we built, kind of for fun, ended up being the number one app in the app store. So we did that for many years, and then we started doing blockchain stuff. So what Alchemy does is we power infrastructure and developer tools for a bunch of different people across the space. So we've kind of been in pseudo stealth, but we're about to do kind of a big announcement. And our goal as a company is we want to push blockchain development forward. We want to push the whole ecosystem forward by really, really making it easy for people to build applications. Because ultimately, what we think and what we believe is in order for blockchain to reach its full potential, we really need to have users using real world applications and getting value from that. And what you need to do that is you need to make it really, really easy for developers to create applications. So our whole focus as a company is doing that. And feel free to come by and ask me any questions afterwards about this. So what is a developer API? And I know this sounds really basic, but I just want to go back to the core of what it means to create an API for developers to build products. And ultimately, what it means is it's just a way for programs to access data. And I think the thing that we need to really stress on as a community is the goal is to make development easy. We need to make it as simple as possible, and that should be our whole focus. And today, right now, as Ethereum's evolved, people are building really incredible applications. And those applications need more power than Ethereum was initially designed for. And we'll go into a couple examples of what that means. But basically, and actually, the reason that this is so important is I alluded to this earlier. But what happens is we actually want to have more people using real world applications. If we want billions of people to use blockchain, we need to have real concrete applications that provide tangible value to them in their daily lives. In order to do that, we need to make developers' lives much easier so we can have more applications. So that is our whole focus as a company. So to give you, how many people are developers in here? OK, I didn't expect everyone to be. So this is probably a little obvious. But the reason that good tooling, people actually often underestimate how much good tooling matters. And it matters a lot not because it helps you build products faster, which is what it does. But it actually lets you create new types of products you weren't able to before. So let's say you were baking. You're baking a cake. You have oven. You have a timer. You're measuring a cup. You can make a really cool cake. But the challenge is imagine if you just had fire, no timer. You're just measuring stuff by hand. You're just kind of guessing on your time, kind of like me right now, seeing how much time I have left. So you're going to end up with something like this. So we really want to make it easy, easy, easy to create new products and also enable new products to happen. And that's why developer APIs are really important. So let's go through an example about Ethereum. So right now, a very common use case for a lot of people's applications, wallets, games, is you want to list all the transactions that an address has. And this is actually very common. We see this among a lot of our customers. But it's actually very difficult to do. In order to do this, you need to go block by block and inspect every single transaction. Like let's say I had Coinbase wallet. And I want to show my transaction history. Coinbase has to go block by block, look through every single transaction in the Ethereum blockchain, and see which one is relevant to mine. So out of the millions and millions, maybe I'd have 10 transactions. So you can imagine, it's just not feasible to do. And you actually can't build an application like that. It would take an hour to load the app. So one of the things that we do is provide an enhanced developer API. And what that does is it indexes and stores the blockchain with a lot of infrastructure. So then for the user experience, it just turns into one API call. So get transaction history by address, right? And then you just get all your results immediately. And what this does is provides a building block. So now, as a developer, you don't need to go build all of that from scratch. So I give this example to show you, this is almost like a building block. So now when you look at an application like CheeseWizards, then you take these same concepts and apply it to making that development experience even better. And you end up with something really great. So how many of you have heard of CheeseWizards? Raise your hand. OK, cool. So CheeseWizards is a new game by CryptoKitties. How many people have heard of CryptoKitties? OK. So basically, CryptoKitties was one of the most popular games on Ethereum about a year and a half ago. They came out with a new game. And they came to us and said, hey, we really want a really, really cool developer experience and a developer community. And the reason for this, and this is one of the cool things about blockchain, right, is since it's open, people can build any kind of application they want with the CheeseWizards data. So the goal, in order to create a really flourishing community, is you need to make development as easy as possible like we talked about before, both on the infrastructure side and on the tool side and on the API side. And back to kind of how we were talking about Ethereum transaction history, a lot of these things were not feasible to do if you're doing it on the standard Ethereum API. So if you're just trying to load all the CheeseWizards and we'll go through a couple examples today, it's actually you just can't do it unless you build your own database and infrastructure and all these things. So that's kind of the motivation behind why they wanted to create a really great developer API. So really quick highlight of what the game is, what it does is it's kind of like a rock-paper-scissors game. You guys haven't played it, you should definitely check it out. And you have these wizards and they fight duels. And basically it lets you, you have these moves like wind, fire, and water, and you fight each other and it's just like tournament and you go up. So, and I'm just showing you this so you can get a little bit of understanding when we go through the examples. So how do we think about the API? So the first part is we want it to be just really simple. Like when you look at it, it's almost like deceptively simple, the user experience, right? And that was on purpose. And it's actually one thing, as you guys know, it's actually more difficult to design simple user experiences than to design complicated ones. Cause you have to put in a lot of thought and a lot of infrastructure on the back end. The other thing we want us to do is have a powerful querying system so you can actually get the data you want so you can build applications really easily, right? And the third thing is we want it to make it really easy. So you don't have to go spin up your own node. Like if you're building a website, you don't have to like spin up your own server and do all this stuff. Like you just open your text editor and start typing. So for blockchain, we did for cheese wizards, we didn't want you to have to spin up a new EC2 instance and install a node and sync it from scratch and then do all this extra stuff. So we're like, we just want to make it super simple, web API so you can just prototype and build really quickly. So under the hood, what we had to do is actually build a ton of complicated indexing infrastructure that allows us to serve and query this data very, very easily. So let's go through a couple examples of what that looks like. So you can think of, let's say we're building a leaderboard. So we want to show all the cheese wizards and who's the most powerful one and who has been winning these fights, which are called duals. So this is what it would look like without the API. And this is actually, so this is actually a shortened version of the code. We were writing this last night and one of the years was like, I actually had to cut out like two thirds of the code because it wouldn't fit on one screenshot. But you get the idea, right? So don't try to run this, it won't actually work. But basically like this, you would have to write this much code just to get all the duals. And you know, that's actually not the hard part because you can write this code, right? But the thing is it takes like 10 minutes to load a page because again, this is going through every block and every transaction and all the logs and figuring all that stuff out, right? So it's not feasible. Each query will take like about a minute. So you need many queries on your page. It's gonna take a long time. So you can't build and no user is gonna click a button and then wait 10 minutes for something to happen, right? So with backing with infrastructure, you end up with something like this. You have one API call that just immediately gets you back all the data that you need. So in one line of code, and most importantly, the application loads instantly. So that's kind of one example. And this is an example where the smart contract, and this is a distinction I'm gonna make between this example and the next example, is a smart contract actually doesn't have any methods for getting duals for wizard. You actually have to go explore all the logs and the events and all that stuff. So this is not built into the smart contract, right? So now you say, okay, what if it is built into the smart contract? What does that look like, right? So here's an API call that actually is built into the smart contract. There's, we wanna do, let's say we wanna get all the wizards owned by Joe, right? And we wanna see, does he have any cool ones? Do you wanna fight him? So the smart contract actually has a method that's called get wizard by ID. But the challenge is we don't know the ID of the wizard. We want Joe's wizards, right? And that small tweak in the smart contract is makes it so that you actually can't get the data unique. So the challenge here is that in order, there's no way the smart contract can have all of the methods to any kind of way that people wanna build applications. So if it's not exactly what you want, you still end up with something like this, right? This actually fit into one screenshot, so we left it like this. I think we cut out a few variable definitions and stuff, but it's essentially like a bunch of code you have to write. It's really complicated. And most importantly, it's the same thing. The smart contract method exists, but it's not exactly what you need, so you still have to go through all the logs and events, and it takes about 10 and a half minutes to load a page. So now with the API, you end up with something like this, one line, and it loads instantly, right? So that's kind of a couple examples of why it's important. So hopefully you can see that this is a really, really huge difference in developer experience. Not only is it easier when you write less code, but it's also enables you to do things that you couldn't before, unless you're gonna go sit there and say, oh, I wanna build a cheese wizard game, but first let me spend like a week building out all the infrastructure to do all this, right? So let's go, finally, wanna go over a couple principles of API design. So we now power, I don't know what I can say publicly, we now power billions and billions of queries for hundreds of companies around the world, so a few things that we've learned from talking to hundreds of companies. So the first thing is, it's really important to understand your goals, and this sounds very obvious, but it's actually not, and the reason is you kind of sit there and think, oh, okay, cool, yeah, we want developers to use this, let's just put something together, but I think there's actually a very big trade-off around how easy is it to use, how fast is it for developers, how much time do you wanna invest, are you gonna be building out the full end-to-end experience, and there's a lot of trade-offs here, and really clearly defining your goals is really, really important in that. Again, something that as an engineer, when I look at stuff like this, I'm like, oh, this is obvious, but then when you actually sit down and do it, this is one of the really most important things, know what you want. The second thing, and again, something that sounds really obvious, but makes a huge, huge, huge difference, really talk to your users and understand what they want. You think that you know, but you might know, but you probably don't know all of it. So one of the examples was when we built this consumer app, it was called Down to Lunch, we actually put, so it kind of started off as this thing where we thought no one would use it, and we put our phone number in the app, and anybody could text us, and we thought it was just gonna be our two friends, ended up being millions of people around the world. We started getting 10,000 text messages a day, literally broke the iMessage infrastructure. I had to email Tim Cook to see how the app would be like, we were almost neighbors, you have to help me, I spent three days at the Apple store and they didn't help me, right? And the result of this is like, we were actually really, really, really in touch with our users. So right now I see some of our customers out here, we have a telegram chat with every single one of our customers real time, and it's super valuable for them, but the most important thing is it's really valuable for us, for getting feedback on what's good and what's not and how we can improve it. So really, you know, I can't stress this enough. The third thing is keep it simple. One thing that we see in a lot of developer tools and API designs and documentation is that's really complicated, like, and you have to remember, building, let's say you're building cheese wizards, when you have these developers coming to use your platform, that is not their main objective in life. Their main objective in life is not, how do I build the best cheese wizard application, right? They're coming to this thing, they have 30 minutes, you know, free between, before the Game of Thrones episode, they just want to make it, see if they can build something cool. If you can't capture their attention and make it really easy to do, you're gonna lose them. And this is something that a bigger theme around building products for blockchain, we need to approach it as a focus of, hey, we need to treat this as, this is something we need to really engage people on, and it's not something that we should just take for granted that they're gonna devote their whole life to blockchain. The last thing is testing your API. And this, again, all these things sound super obvious, but when you go to build an API, people understand that this is really important. So basically, what we found is there are a lot of edge cases, especially with smart contracts and people querying stuff. So having a tight feedback loop and testing a bunch of stuff before, we've done this good and we've done this bad. Like sometimes, you know, there's been a couple of times where we launched things and we thought we had good coverage and people would have like a really crazy edge case. So I think this is really, really important. The other thing is we found, oh my gosh, creating good documentation. This is probably the highest leverage you can have on your own time, because what happens if you don't create a good documentation and people ping you all the time with questions? And it's super, super, super important, not only for the developer experience, but also to save your own time. And then the last thing is, or second to last thing is getting feedback and iterating. When you ship something, it's not done. It's like, you've got to continually, continually iterate on that and make it better and better. And this is really what separates the good products from the great products, right? And the last thing I think to think about is really think about solving the user's problem. It's not just, oh, we built this API, we're done. You need to literally have the whole experience covered, right? You need to, the best experience is like, oh, I don't have to spin up a node, I just have a web API. And then it's like, oh, I don't need to even write my own HTTP wrappers, I can just use an SDK, a JavaScript. Down to like, oh, the app just calls them in Uber to get to their office in the morning. You need to make this, think about it end to end. And this is what really makes a great user experience. So, in conclusion, it is maybe not the key to life, but it is definitely the key to creating blockchain applications that people really use and ultimately pushing forward the success of our whole industry. So I think we see this on every single, this is like what we eat, sleep, breathe and live at Alchemy. So it's very kind of ingrained in us, but I want to emphasize how important it is. For those of you guys who are building developer products, put a lot of thought and care and you'll get many, many, many times over rewarded in the dividends. So, thanks, I'll be around. Does anybody have any quick questions? Great talk. Thanks. Happy birthday. Yeah, thank you. Yeah, I have a question. You said that you used the owner instead of the ID and there is some logic that you had to add. Do you process that by your team who builds the logic with the transformation like something like the graph protocol, something like that? Yeah, that's a great question. So the question was, you know, when we go back to this slide, this one, right? So like it's slightly different than the smart contract and where does that data get processed and is that on our side or is that on the user side? So there's kind of two ways to handle this. Like one is we actually provide a bunch of different transformations of the data so users can access in any way. And then there's also, we have plans for like a decentralized system, but what we found is most of the time people just want the centralized version first and then you can make it decentralized. So does that kind of answer your question? Kind of? Can I run my transformation? Can I create my transformation? In cheats, in some of the things we do, yes. In cheats wizards particularly, no. There's like standard APIs. And the reason for that is we basically thought through every single kind of use case that people would want and we provide like parameters. So you can say, for the API calls, you can say query wizards based on fire type, based on wind type or based on owner or based on dual. So we basically think of everything you need and build a flexible system. So, yeah, question. Great talk. Thanks. So I saw that your API queries a lot of data, but do you also post transactions to the blockchain with your API? Yes. And do you use meta transactions or how do you do it? What do you mean? Do we batch transactions together? I mean, as a developer, I sign a transaction and send it through your API or how does it work? Yes, so we don't hold any private keys. So the question was how do we do transactions and how do we do transactions in the system? The answer is we don't hold any private keys. You kind of like, the way to think about it is you package this transaction and you hand it to us and we're just kind of like the pipe to the blockchain. Kind of like your internet provider gives you internet, we give you access to the blockchain. So we put it in and it like goes to this little tube and that comes out on the blockchain. Yeah. So like this API that you build, is it like you build a custom one for each one of your clients or is it like sort of an automated product where I give you my contract and it sort of generates an API and how does it work? Great question. So the question was do we build one at custom one for every client or do we, is it kind of like an automated one? So typically we mostly focus on Ethereum API. So we build kind of a standard API and so we support the standard JSON RPC API for Ethereum and then we build a suite of Ethereum APIs. This is actually the first API that we built for kind of a specific customer. And typically we don't do these but the short answer is this was custom but we do have kind of a way to do it automated if we wanted to but it's not kind of like a big area that we're focusing on. Okay, so second question. It's kind of, it's not like a lot of the questions. I just really want to try to understand. So like pretty much every DAP if they want to have like good usability and good like fast responses, what you do is you take your smart contracts, you just listen for your own events, you save them on your APIs and then you index all the stuff by whatever you want and then you expose your own API for your app. Is this the same thing you're doing? Or are you like taking a radically different approach? Yeah, it's similar. So I think for Ethereum, and I think this is probably like ask me afterwards, I'm happy to go through it but basically what we do for Ethereum is we basically take each piece of Ethereum data and it's not we would just dump it into a database. We actually index and store it in a bunch of different ways so you can query it in really flexibly. So for example, the simple naive way of doing it, you just take all the data, dump in a SQL database and you return it but you can only query certain things like that. So we have like time series database, we have caches, we have Redis, we have MemSQL, we have like all these different things that we use that enables you to query like really, really flexibly. So the short answer is like, it's kind of like, you know, if you're bicycling, is that the same thing as like a Ferrari? It's like, you know, kind of but a little different. Okay. So in this case like to get the wizards by owner, this was like your client that gave you like a requirement if he's I want to get them by the owner or he just like built something so generic that it also supports getting it by the owner. It's a great question. We actually did the process I talked about earlier. We sat down with our customer, we sat down CryptoKitties and we brainstormed and we talked to some developers and we said, hey, here's what we think it should do. And it turns out in this case, it was actually pretty easy. We did like three or four iterations and we were done because the game is very small subset. You can only do a few things. You have wizards, they fight and there's duals and that's about it. Something like Ethereum is much more complicated because you can query in any way possible. We basically took the approach that I shared earlier. Thanks. Yeah. All right, cool. I think we're at a time's up but I'll be around. I have stickers and I have answers, some answers to some of the questions you will probably ask but come find me. Thanks.