Traditional RPC Is Dying: Why Financial Apps Need a Different Infrastructure | Guillaume - Alchemy

All right, I'm super excited for our next speaker, Guiam Ponson, chief technology officer at Alchemy, who will be covering why financial apps need a different infrastructure. Please welcome, Guom.

Thank you.

Cool. excited to be here. Hi everyone. Um, okay, let's talk about RPC and the business of providing infrastructure to financial services. I'll cover a brief history of the space and give you a sense of what has shifted in the last three four years from the early days of RPC to now the requirements of self.

Brief history of our business alchemy. Um if you look back about 10 years ago, everybody was providing um a basic service for nodes. Essentially once you wanted to build an app on blockchain, you would typically run a node yourself. Then next step up from that maybe call it two three years ago um was people like Alchemy like Infura providing load balancing scaling primitives reliability on top of that. That's maybe what I would call the traditional RPC and that powered MetaMask that powered OpenC many of the big names in the space.

And then fast forward from that a few years we entered the crazy explosion of creativity. many many chains um chains specifically for some use cases chains that became very big very quickly like Solana and Tran um that call it the multi-chain era mega uh increasing complexity and creativity um then we entered the space the phase of scale institutional scale and now we have financial services company we have the Robin Hoods the JP Morgans the Fidelity the visas coming to us with much higher requirements. They're not looking for the app to work. They're looking for the app to scale and to be reliable with the same expectation as an AWS or um or GCP. And so I want to give you a sense of what is the difference between four years ago, what the alchemy business looked like versus what alchemy business looks like now and the difference in what we've built in the meantime.

So what is difficult about providing RPC? There is a number of issues and I'll go through them one by one but relatively quickly. One of them is hey you're running your infrastructure in the US. Great. Now the your US users are very happy about that but your users in Asia Pacific may not love the the extra 200 millcond of latency.

So now hey how do we speed this up? Um, problem number two is the load balancing on top of nodes and the basic primitives that Alchemy, Infura and others provided early on give you a sense of consistency like you if you see a block you will not ever go backward in time. But you will start to see corner cases as you scale as you get to millions of requests per per hour or millions of requests um millions of users per day. You start to see the corner cases where hey that breaks actually once you transition from an RPC to a web soocket call maybe it becomes difficult if you fail over from one region to another then you have maybe a little drop there. So these inconsistencies are a little jarring once you get to big scale you start noticing them.

Issue number three is that at small scale you can achieve reasonable throughput. At some point you enter the space where you actually need to provide hundreds of thousands of transactions per second. It's a whole different level of scale. Um one node cannot provide that. Even a small collection of nodes cannot provide that.

How do you actually achieve this throughput is the third uh issue we had to solve. Fourth issue we had to solve is you can start with a node uh but then as soon as this node goes offline for whatever reason the machine dies um then you're in trouble. Now you can say oh I'm going to use many many nodes but they're all in one region. If this region loses connectivity to network, now you have a problem. Um, to achieve truly high reliability, like not three nights, but four nights of reliability, meaning you go from an hour downtime per month to five minutes of downtime per month.

To achieve that level of reliability, you now need to have many redundancy at many layers. you need to do different defense in depth and really be able to um recover from pretty much any failure. Problem number five um traditional RPC as great as it is and it has power of the the very the many years of crypto the APIs are not really suitable for large scale blockchains. Um, as an example, the the typical call you will make to scan the blockchain, the get logs call is typically limited to a thousand or 10,000 blocks at a time. If you want to scan the whole blockchain, you have to make hundreds and hundreds of calls just to do one scan.

Um, it's incredibly inefficient. And finally, the sixth problem we've had to solve is as the number of chains exploded, the complexity exploded. Every chain is a little bit different. Like you can solve the problems for one chain and the problems will be similar for the next chain but it will be slightly different enough that oh now you need to understand dozens of chains like you need to interact with hundreds of teams um on the on a day-to-day basis to be able to handle the complexity. So those are all the problems we had to solve three four years ago and I'll give you a sense of how we went about them but to motivate that just to leave you with three numbers.

What are people actually looking for here? Like we now are serving financial services company, the banks, the JP Morgans, the Robin Hoods, the Poly Markets. What are they actually looking for? They're looking for way over 100,000 transactions per second. So very high throughput.

They're looking for four nights up uptime, meaning less than 5 minutes of downtime per month. And they're looking for incredibly low latency everywhere in the world. Essentially, what they want is fast, reliable apps at scale. It's very simple. uh they're looking for us to provide the same level of service that AWS provides.

So how do you go about that? That's the question we had to solve. And I give you a sense of like a few things we did um to paint like give you the intuition a little bit. So the first thing you will run into is okay, I have my data center in the US. That's the dot over there.

Uh this is AWS US East one, the everybody's favorite data center. It's the workhorse of the internet. Um that makes us US US East users very happy. The APAC users are very sad because it's 200 300 millcond of extra latency. Simple thing you can do is you go to multi-reion.

You now have four deployments of equivalent size in four regions in the world. That covers pretty much everywhere. So now if you're in Singapore, you have good latency. If you're in Japan, maybe you have slightly less good latency but good enough. So you can do that.

But once you know how to do that, then you can go crazy. You can put data centers everywhere. You can put data centers right next to somebody um trading app. And this matters in particular for financial services companies who care about trading velocity as an example or even the dexes dex aggregators in in uh traditional web three. You can now deploy right next to the consumer um deployment data centers.

The other thing you buy by doing this is that you're not so reliant on one region. So if one region goes down, you're still alive. Your system still serves traffic. Um you can fail over pretty seamlessly. You have a little bit of a hit on latency, but as a whole, your system does not go down.

So that's maybe the biggest unlock. You go multi-reion and you push that to the maximum extent you can push it. Thing number two is latency is actually more difficult than that. The multi-reion gives you proximity geographically. But to me latency is a game of details.

It's tuning the machines, tuning every single binary, tuning every layer of the stack, adding caches in the right places. And once you do that across the entire stack, you go, you can go from something like 100 millisecond down to 20 millisecond. you've knocked down every single problem that is um in the way of from the end user to your application. And in particular, like one thing we did once we've knocked down like it's a welcome game. Once you knock down most of them, the last thing we did was we realized, oh, Cloudflare is actually adding a ton of latency.

Like you you when you operate on the internet, typically you take Cloudflare for granted, but truly no. They added a ton of latency. Once we realize that we just built our version of Cloudflare and and knock down another 7x of latency at the very end. So if latency is a game of um details like precision and details um blocks like block perfect consistency is a game of perfection. There is a lot of places a lot of failure modes where you're going to go backward in the blockchain if you don't pay attention.

like once a user goes from this API to that API or um from this region of the world to that region of the world or maybe you have an outage here and the failover causes a block to um to be slightly uh out of sync. This is incredibly difficult to get right but this is the level of um expectation that our customers like the financial services customers really have from us. Uh the last one and maybe my favorite is throughput. When we talk about throughput essentially it's somebody will come to you and say hey I'm I'm expecting my app to have so many transactions per second and you say yes I can do that but what they mean really is that even if your system has issue you still have to support that and then oh by the way they will have a giant spike because it's poly market and it's election night you have to support the giant spike even though it's much much higher than the regular traffic so what they expect is throughput when it counts to them like during whatever their super bowl is you have to be there for them at potentially a much much higher throughput than they asked you for. Um to solve this is partially just you could have many many more machines than you need but that's incredibly inefficient like you're running at 5% utilization.

You don't want to do that. It's too expensive. So instead of that what you would normally do like the way you solve this in distributed system you make your machines elastic. You allow scale up and scale down very quickly. Traditionally that has been very difficult with blockchain nodes because they need a huge amount of state locally on the machines.

So this was maybe the the hardest technical problem to solve is how do you actually do this efficiently at scale but you have to to be able to uh support the throughput. So all this to say once you solve some of these issues and many more like this um you can see the difference between where we were maybe three four years ago what I call here traditional RPC and we are where we are now and where a JPM Morgan expects us to be it's much higher requirements on reliability much higher requirements on latency this idea of having perfection in the block um consistency and this idea that we can now elastically scale and provide much much higher throughput without breaking the bank. Um the other bonus and very fun activity is you actually need to become compliant. So to compliance, ISO, Dora, name it. There's five or six of those.

Um that is a requirement for the big banks and the JP Morgans of the world. The Fidilities, the visas, all of them require sock 2 and and above. So 2 is just the start. um they are if you take a step back they're actually good ideas good practices in general but they do add a lot of complexity to your operations so we did all that in the last three four years um and I'm sure our colleagues in the in the world of RPC have done similar things um the beauty of it is once you get there we call our blockchain engine cortex like it's it's trained on many many years of um of traffic patterns we've essentially put all the intelligence we had and and a number of uh AI oriented modules into that foundation. The foundation is now capable of doing scalable, reliable RPC.

Now you can build upon that. You can build more advanced APIs. You can integrate partners in a way where they benefit from the uh from the all the advances you've made. You can build tooling on top. You can then run agents on top.

So all of the rest essentially benefits from that base layer being incredibly good and efficient and reliable and scalable. Um, I wanted to touch upon the what I mean by advanced APIs. And again, it's just to give an intuition of what builders actually want that traditional RPC does not provide. But it makes a huge difference if you're a developer. Once you have these primitives, your job is much much easier.

And so examples of that is, hey, you want a data index over a chain. Great, you can get that. Can you get the same index across all chains, across a 100 chains? Can you do queries across chains? Um, can you do a get logs request across the entire blockchain, not just segment by segment?

Um, can you sponsor gas so that you don't your users do not have to worry about provisioning ETH or provisioning whatever the token the native token of the chain is. Um, can you build a new blockchain that is tuned to the specific use case of the user? All of these and more are APIs or or primitives that you can build upon the base layer and that hu make a huge difference and I'm going to show you kind of use cases where we've used a lot of these. Um I'm actually excited about the right side here. I think the the next year, next two years is all going to be about agents.

Um, one big effort we have ongoing and and a series of launches that we started last week is going to be to make alchemy usable by agents without a human in the loop. You can sign up for alchemy, you can pay for alchemy, all of these purely as an agent, not as a human. You don't need a human in the loop to be able to do the entire thing end to end. Um, I think that's actually for us as an infra provider, it's going to unlock much much um much much bigger growth. So let me walk you through maybe three examples of all of this everything I talked about in practice with specific users.

The first one I will site is Worldcoin. You might be familiar with them. Um they scan your iris and then that's what they use to give you an identity on the blockchain. They are actually pretty impressive app. Not super well used in the US but it's a van like app.

A lot of developing markets use it. Uh it also has a marketplace of many many apps in the space of crypto that mirrors of the NFT defy landing all the primitives that you're used to on the blockchain. Uh but it's very easy to use on your phone. Uh for for them in particular they really cared about the scaling and so there was a moment in time where they said hey we can't scale anymore on public blockchain. And the main the big unlock we did for them was okay let's build a blockchain for you tuned to the world the world coin use case.

So it's a custom L2 it's a rollup. Uh, one cool thing we were able to do that they really really care about is they wanted the sequencer to have a module that prioritizes human transactions over bot transactions. And so if you own your blockchain, this is the kind of things you can do. Um, and so we provide the traditional alchemy developer platform, but in addition to that, we've customized that blockchain to be prior priority human and um, bots are stacked behind the human transactions. So, it's both an interest of scale and an interest of customization.

Um, second example I would give you is uh we worked pretty hard with JP Morgan to power their USD deposit token. Um, it's a really cool idea. It lets you essentially turn your deposit into a a crypto balance on chain. It's kind of an alternative to stable coin in in some ways. Uh I think the main unlock for that particular use case was it's really inconvenient for the users of that product to have to get out of stable coins buy some ETH to be able to perform the transaction.

Uh so this is a perfect example of where gas sponsorship makes a huge difference. Now if you're using these products you're essentially operating all the way in dollars but you're performing transactions on the blockchain through the gas being sponsored by uh by JP Morgan and uh us under the hood. Um, last one, my favorite. Um, Poly Market, hopefully everyone's favorite. Uh, Poly Market is a really cool app.

Like one of the to me like really cool innovation that blockchain really makes uh much much better. One thing we've done with Poly Market, they wanted to achieve much higher throughput, but in particular during spikes. So you can imagine the debates before the presidential election from 2024, the presidential election itself. Um then subsequently the Super Bowl like all of these events if poly market traffic looks more like this baseline you end up with a 10x spike during that event for an elongated period of time. um we spend a huge amount of time with them optimizing for that throughput and this is where having seen traffic patterns for the last seven eight years really pays off like we can anticipate what um these spikes will look like and how they impact uh every layer of the stack and then tune our systems to adapt to the spike.

Um I'll leave you with maybe a couple of thoughts here. So these are just three top of the top of mind use cases. I'm really excited about the coming few years. I think these three use cases essentially prove that we've made it. We've graduated into the point where we can support large scale um financial services like companies.

And so the Robin Hoods, the JP Morgans, the Fidilities, the Visas, the uh the Revol like all of these I expect will come on chain very soon if they haven't done the that step already. And I believe we're ready. Like we've built all the primitives they need. We're able to support them. Um and I'm really excited to build with all of you and uh the new world of crypto.