Building Scalable, Reliable, Data Consistent Web3 Apps with Alchemy - Elan Halpern - @ETHDubaiConf

Transcript

what's up everyone i'm alot i'm alan this is my backup dancer albert keep him up here to give me background noise um so i'm alan uh i'm from the alchemy team for those of you who have not heard of alchemy we're alchemy.com um and we're a developer platform for the for web3 applications for the blockchain um my talk today is on building scalable reliable and data consistent web 3 applications so who am i i am a developer advocate at alchemy i've been at alchemy for almost 2 years now so if you don't know what developer advocate is we basically just make sure that whoever's building with alchemy and building in web 3 is having a really

good experience and advocate for all the developers building in the space so whatever tools products features you're excited about or need it's our job to make sure that that happens i also started an organization called we three that's focused on women in non-binary education in the space to make it more inclusive and i started an ice cream company called crypto creamery that makes ice creams make ice cream on the weekends for fun so building scalable reliable and data consistent applications i chose these words very specifically for a reason and you might be wondering like why is this hard to do why is it hard to accomplish all of those things when

you're building in web 3. and here's the problem the blockchain is run by a network of nodes and for those of you most of you probably already know this if you're not very technical maybe this is still a little bit new but the entire network is actually run by a bunch of nodes that are running software on their computers every node maintains a copy of the blockchains it's not like physical blockchain it's just all of these nodes maintaining a copy of the state of the blockchain right and developers use these nodes to make requests so any reads any writes that you want to communicate with the chain has to go through a node endpoint that

means if i want to send a transaction that goes through my node if i want to read someone's balance from the blockchain that goes through a node so it's a really critical part of the developer infrastructure of building web3 apps is this kind of node endpoint and ethereum was really designed for developers to be able to run nodes actually like in ideal world all blockchain networks have individual developers running their own nodes they run a piece of software on their computers and they can connect and communicate with the blockchain that is sort of how it was designed to make it as decentralized as possible as accessible as possible right so you can just run a piece of software on your computer and for a weekend hacker for

someone who's not sending a lot of requests maybe i'm doing some mev stuff maybe i'm just kind of sending transactions here and there that actually works okay you'll still have to spend time syncing the node right because nodes have to maintain the state of the blockchain so you have to make sure it's up to date and sync all the previous history you still have to maintain client updates you still have to pay for the cost of running the node and a bunch more other stuff that kind of happens under the hood but generally if you're not sending a lot of requests you should be able to run your own node that's kind of how ethereum was designed but what if you're someone like openc what if all of a sudden in the past year your traffic looks something like this how would that work if you were running

a singular node and you were no longer just a weekend developer sending requests here and there every so often this is where we introduced problem number one of it being really hard to build web 3 apps and that's scalability right if you're someone like openc what are the implications of running node infrastructure whoa not sure what just happened there i think i clicked the skip ahead button okay sweet sorry technical difficulty

um so nodes can hold a certain threshold of requests and this is pretty logical i don't know if you guys ever use your computer and you're doing too much on it and the fan starts to overheat and then it shut down like computers can only handle a certain threshold of requests before they start to fail so if you get a huge spike in your usage right if you're doing an nft drop this is actually a screenshot from one of alchemy's customers on the day of their nft drop this is what their traffic looked like it was pretty steady pretty slow and then all of a sudden they had a massive need to be able to handle an insane amount of traffic so if you have this crazy spike and you're running your own node it just won't work it'll completely

crash and burn and all of a sudden all these users that arrived your application who are really excited about getting your nft or using your product can no longer use it what happens when a node goes down remember it's a really important and critical part of the developer infrastructure of your application so when a node goes down your users can no longer make requests they can no longer interact with your application anymore and it makes your product virtually unusable and that's because all information that goes to the blockchain has to run through this endpoint so if it's not up and running then you can't send information to the blockchain anymore and you might be thinking can't we just spin up more nodes right there's a very logical solution to scaling it's like

create more of it when you create more of it you can handle all the requests the problem there is that nodes actually can take weeks to sync and one of our back-end engineers omar's actually in the audience right now he syncs alchemy's node often and he can tell you about how how challenging it can be so if your application crashes due to a large spike and nodes can take weak to sync churn happens in seconds i don't know if you guys are like this as users but when an application isn't working for me i completely close the application i'll probably never return again the same thing can happen with your web3 application if it's not up and running so you can't really spin up more nodes if you're in hot fire right now and this introduces problem number two

which is reliability your node reliability equals your product reliability remember this is because it's such a sensitive part of your web3 applications infrastructure even if a node is 95 reliable right which is like a pretty auspicious number 95 that's one and a half days of downtime for your application so an entire 36 hours every single month or your application is down if your node is just 95 reliable not only is that frustrating for your application it's also frustrating for your engineers your engineers are now spending valuable time maintaining this back end infrastructure

and trying to upkeep this node endpoint instead of working on your actual product they're just debugging so maybe you get smart and you're like all right i know this is going to happen i'm expecting a huge push so i'm going to spin up a bunch of nodes ahead of time you know a week weeks ahead of time i'm going to spin up all my nodes and then i'm going to be ready for all the traffic that comes this is where we get to problem number three data consistency and this is a little bit more of the trickier problem it's kind of harder to get visible visibility into at first and so we're going to look at it through an example so why is data consistency really hard to do in web3 applications

there's a logical scaling solution to reliability and scalability and that's using what's called a load balancer and for those of you who don't know what load balancers are they're basically this in-between layer between your application and your nodes where you can funnel traffic to different endpoints so if i'm getting a ton of traffic on my application and i know that one single node can't handle it all i'll spin up a load balancer when i get a request i can funnel those requests to different node endpoints so that no single node can get overrun this is super logical it's a it's a simple scaling solution it's a very web 2 scaling solution and in fact a lot of node providers in the web 3 space use this to scale up right so they're

running a bunch of node infrastructure under the hood they slap a load balancer on top and then that can funnel traffic to different endpoints so it's super logical what's the problem with this remember blockchains are run by a network of nodes and how do what implications do a network of nodes have on this data consistency issue well every node because it's run by a network every node might have a different sense of what the latest block is the way nodes communicate is i'm a node i have 10 peers those nodes have 10 peers those nodes have 10 peers until we reach the whole network and so if i find out about information my peers and their peers might not also

have that same information and that's the implications of a network that's how networks work so depending on what node you're sending requests to it might not actually have the same sense of what the latest block is because blockchains are run by this network so this means that load balancing right so sending requests through a load balancer that funnel to different nodes can return inconsistent data and this is where it gets a little bit tricky so if i'm the green user and i ask for the latest block through my load balance node infrastructure maybe i'll get block 102 at the same exact time if i'm the red user and i ask at the same exact time for the latest block

maybe i get funneled to node 3 and they tell me the latest block is 101 this is the implications of using a simple load balancer you might not get the same data because this is how blockchain networks function now what does this mean for actual users for your actual application let's walk through an example so i'm a user i buy a mutant ape and i use a load balance node infrastructure to do this and remember load balancing is a very common solution in web3 if you guys aren't using alchemy you might actually be using a load balance solution node provider or running your own nodes so i buy a mutineep that gets funneled through through the load balancer into node two

so i get my mutant ape the transactions confirmed in block 102 i'm stoked i'm happy i have an awesome mute nape and i know it's in my wallet let's say i refresh my feed i buy the mute nape i saw it there i hit refresh button remember all engagements with applications go through a node right because you're querying from the blockchain so even just a simple refresh on data that read goes through so i refresh my page it goes through the load balancer but this time instead of getting funneled through node two it gets funneled through node three now node three in this load balance infrastructure isn't yet aware of block 102 and what that means is my purchase of

that mutant ape is now gone not because it's actually gone right it lives in block 102 but the node i'm communicating with isn't aware of block 102 which means my application is telling me hey you don't have your mute name i know you said we said you just bought it but now it's not there anymore because we're not aware that that existed so this is where data consistency is extremely important and it's often overlooked in a lot of web 3 applications and a lot of node infrastructure platforms so what do you do i've been i've been yamming about how hard this thing is and all the challenges that you face when running node infrastructure in web3 so what can you actually do well there's a simple solution to this

you build out a higher level infrastructure engine this is what it looks like for you you have one endpoint and it's done you don't have to worry about data consistency you don't have to worry about scaling you don't have to worry about reliability that's it this is all you have to use in order to make this happen this is what's actually happening under the hood and this is our kind of high level infrastructure diagram for what we've built out at alchemy so we spent the past two three years you know two three years ago we've been we've been live for about a year and a half now but we spent the first two or three years just kind of in stealth mode building this out really thinking about what are the extremely challenging

problems that come with running node infrastructure in web 3 and coming up with this higher level infrastructure engine that solves for these issues so no it's not actually really easy under the hood it's really easy for you because all you have to do is spin up a free account and just get access to this endpoint and it gets funneled through this larger infrastructure engine that we spent years and years building refining and mastering and are continuing to iterate on to find those niche issues so what are the key components of this there's a coordinator service that kind of helps funnel different requests there's a consensus mechanism that we built remember this is all on top of the node so yes blockchains and nodes all

have these things too we built out our own versions of this that sits on top to make sure you don't hit any of these issues there's a consistency layer we use diversified node client so i don't know if many of you know but there's a bunch of different node clients out there and if you're just running one and that one has a bug in it then you can no longer actually serve requests and engage with the blockchain so we make sure to run a diversified set of node clients we index a bunch of data source we also provided caching layers that requests are served to you a lot faster than they otherwise would be what does this mean for you how does implication for the end user you get consistent data you don't have to worry about users experiencing changes in their mutineed purchases or their nft

purchases you have instant scalability so if you are open c we do power all of open c so if you are open c and you have this insane spike we don't have to worry about upscaling your nodes and running a bunch kind of instantly you've increased reliability we also have a bunch of enhanced apis built on top of the platform to make indexing things a lot easier and free archive data of course so if you don't want to spend 200 in archive data it's completely free on the platform at a high level we've developed a proprietary distributed blockchain engine that provides infrastructure and solves for these three really challenging issues scalability data consistency and reliability

our platform has a bunch of other tools for developers as well we're built on a bunch of different chains but really the the bread and butter here is the supernode this infrastructure engine that i've been talking about this whole time other products that we offer for devs are off me build monitor and those are both debugging interfaces like dashboards and more insights into your requests we have a notification system so if you want to get notifications on your blockchain applications you can do that the enhanced apis that i've talked about and we have an awesome support team you never talk to a bot when you're when you're using aqua you always talk to real humans so yeah this is our product suite the main the main premise of my talk was on our supernode engine so i won't get into too much on the other tools that we

offer but happy to take questions from here yeah thank you [Applause] so i have a question uh is it safety to create some kind of battery apps only with front-end and contracts so uh i put the link to the lcm in front and so uh the malicious sector can steal my my link to then enter or to the lcm and try to use my paid note so what is the

best practices for it yeah that's a really really good question i was actually just just yesterday we were talking about that with a bunch of people and so this is just to kind of repeat the question here one issue that website applications have is that they often don't have a back end right the back end in web3 applications is the blockchain itself so an ideal world you have a front end you have a smart contract and all of those requests go to the back end right so you're not actually controlling or storing any data because the back end is the blockchain now if you're using something like alchemy then your key kind of lives in that front end application and so this question was like what's the best practice there because you have this api key uh that i showed you guys earlier

and if it lives in the front end then in theory you know a bad actor could come and take it and use it my you know short kind of frustrating answer for you is that this is a really hard challenge to deal with when it comes to not having a back end in web applications because you can't protect it some solutions that we do have right now but like really you know this this this oddly enough doesn't come up as much as i thought it would so like surprisingly not enough people are doing this but again our platform is free so like you could always just spin up a free key and use it um but there's things like like whitelisting so you can do whitelisting of domains so that only requests from your domain can go through so if i copy your key and then i try and send a

request from another application it won't work unless your domain is whitelisted you can do ip waitlisted so you can only take requests from certain ips there's ways to do ip blacklisting too so if you notice an ip that's sending a lot of traffic and you don't recognize it you can blacklist that ip there's rate limiting you can do so you can rate limit certain certain keys and users so that if you see people using a lot you can start to throttle their requests and then they're no longer incentivized to use your key in general it's a bit of a tricky problem that that has to do with how web3 apps how their stack kind of works but yeah it's a really good question there are a couple solutions to it right now that exists hey how's it going

um have you been thinking about zika vm any um in terms of like uh stateless um multi-chain proving so that you can serve data in a in a secure way because um many of the evms will be compliant once they have native zkvm right so you can have alchemy type consensus around the fact that you've recursively proven a chain and then serve up data with you know miracle proofs that the data or your transaction exists in that blockchain within zero knowledge with a small like maybe 20 kilobytes proof or something like this what are your thoughts like would that be the consensus layer would it be completely stateless or have you been thinking about it at all yeah that's a good question so i i'm not

quite sure if if i'm completely understanding you're saying basically like validating that data served is correct through like some sort of some sort of zk proof is that kind of the thing well you can have a rolling uh recurs recursive proof like uh through ivc or some other mechanism but you can have like a a system that just keeps track of the ethereum blockchain and recursively prove it since the native zkvm exists now you can recursively prove it and then a service in a back end could be trustless and censorship resistant in terms of giving you data that you know is correct the only thing is you don't know if the blockchains roll back or not so if the blockchain's final then you know for sure it cannot be rolled back and you can trust it but i wonder across multiple blockchains multiple evms some

service like that like a decentralized interfera needs to be stood up that you can not have to trust a consensus or something like this yeah yeah totally no i think that's absolutely fascinating um it's definitely something that our team talks about a ton i think it's actually not a trivial problem to solve which is a big reason why no one has solved it yet um and so the big need that we're we're hyper focused on solving at alchemy at least for this moment is making sure that like apps can scale and run and serve consistent data um so that's kind of first and foremost like how do we make sure that web applications can actually like scale and exist in the nature that they want to and then that second layer is doing stuff like this so we've absolutely talked about it as a team and thinking

about what kind of ways we can do this especially across multi-chain which is some of the things that you're getting at in your statement i don't have a definitive answer for you like yes x y and z things but i think it's a really really fascinating space and something that we've talked about a ton sure thanks [Music] yeah so can you blink once if there's going to be a token air drop and blink twice if there's not going to be a token air drop um yeah or blink three times if you know yes or no maybe something yeah i've never blinked in my life so i can't i take your silence as a yes no um we you know truthfully like

there's not really an eminent need for us to have a token right now um just the way our kind of platform functions so um and i think as a company i don't think we're super keen on like launching a token just to launch a token um and so if and when there becomes a strong need for us to to do that and build out a platform where the incentives are aligned and things make sense then like i'm sure we would um but i i don't know what to blink anymore because i forgot your rules so just now i'm gonna avoid avoid that um yeah so the the short answer is no but um it's not like we're strongly against tokens or anything no worries thank you so much [Music] oh thank you

first of all i would like to appreciate the way that you express your solution it's an amazing way i believe that this solution represent a single point of failure because at the end it's centralized solution isn't it how do you guarantee that all the time your solution is running this is question number one and question number two this url represent to me [Music] a way to get the data from blockchain what's the guarantee that you are not tampering the data or nobody is

tampering the data great question yeah yeah yeah great question so i'll take i'll take number two first um so the question was like you know we're serving blockchain data right so we're you're reading requests from us and we're serving it back to you so what you know how do you guarantee that we're not tampering with that data when we do serve it back to you and the shorter answer is like those incentives aren't aligned for us like we have absolutely zero incentive or like initiative to want to do that to you and the reason being is because you can always this is the nature of blockchains as they exist you can always always always use something else you don't have to use alchemy ever right if we're in web 2

and you have these centralized servers then and i decide one day to be malicious and i shut your server down maybe i stopped feeding requests maybe i i you know modify data there's no way to recover or get that data in any other way right because they're on centralized servers in web 3 if you woke up one day and you were like you know what i don't want to use aqua anymore you absolutely could and all of the data the whole history of your application and everything that's going to happen next is still there it's on the blockchain you can access it by running your own node you can use another provider you can go through your wallet like all the data still exists and is there so there's no real incentive for us to like modify or tamper with your data because then you'll just turn off of us and you will

no longer use us right we don't have a product anymore or a business if if we do that um so that's kind of to answer your second question um and your first question is around like centralized point of failure um and so yeah so if you if you think about like kind of the beginning parts of the talk around like running a single node data consistency all of these issues that occur when running node infrastructure that happens all the time with applications and that's kind of the reason why i mean that is the core reason why we built this out is because now there isn't a singular point of failure under the hood so you know taking a step back this is more philosophical question of like what is centralization what is decentralization um and so from this perspective

we're not we're not running a singular node so we don't necessarily have a singular point of failure we're running a bunch of node clients we're running a bunch of software and consensus mechanisms above as well so our our infrastructure engine as it exists is just a lot more reliable than a traditional node infrastructure engine is [Music] i'm not talking about your solution is scalable yes i agree with you however at the end it's if the infrastructure for any reason went down the whole solution will went down

while the infrastructure is running you have the guarantee that you will serve me got it yeah so is there in i'm thinking that if we think about i'm not talking about that your solution is bad or not no yeah i think about an alternative scenario for like for example let's imagine a serverless node yep yeah so okay i see what you're saying as you're saying like what if what if the entire thing was done yeah and i think this is like uh so the short answer is like look polygon went down for like a week and a

half two weeks ago the entire polygon chain went down and people were like oh like you know stuff's not working and if you're at me all these things like no like the entire polygon chain went down like happens right like things can just can just go down so the risk is like right what if what if alchemy goes down like how does that you know what can you do there yeah yes the whole idea is that failures happen things happen ethereum can go down pogba all these things happen we're reducing that risk i think you're exactly kind of summarizing it in a really clean way um you know by using stuff like this by building kind of this higher level implications and stuff it reduces the risk

yeah good question though any more questions yeah it seems that everyone's spoken so thank you very much for talk and it was really educational [Applause] oh one last thing we have swag over there a bunch of alchemy shirts so these these shirts this shirt and a bunch of stickers yeah so if you want swag there's not that much of it because people like took a like a lot yesterday so definitely go grab some swag if you want to you