High Performance Apps with State Channels | Louis Bellet at Pragma Taipei 2025

[Music] So, I want to jump right in and introduce our next speaker. And for this one, I'd like to bring on Lewis to tell you all about the new things you can do with state channels. Please give Louis a big round of applause. Thank you. Hello everyone.

Nice to meet you. It's really a pleasure to be here. Um, where did I put the slider? Here we go. So, yeah, before we get started, so I can adjust uh the speech to the audience.

Um, who in the audience is using NeoVim? We got two. Okay. Uh, who is using who is developer? So, about half.

Okay. So, let's try to work with that. Uh, yes, I tried to balance. Uh, state channel can get technical. Um let's get right into it.

Inject Nitro in your stack. Um how to accelerate decentralized application DAP um on top of existing smart contract and we usually speaking here about layer three. Um so everyone knows the layer one layer two scaling mechanism 10 years ago has been initiated and supported by Vitalik himself. Um the state channel scaling mechanism and this has been a painful road of research development and failures. Uh one of them that you probably all know that is a live network in production is lightning channel on top of bitcoin and this is powered using state channels.

Uh state channel though on ethereum um are much less rare in production or popular project. So how to build high performance apps with state channel? Before we get started, I'm going to ask a question to the audience. How many MEIPS do you think the Etherum mainet is supporting? Meips being million instruction per second.

This is kind of an old way to measure CPU speed, I would say. So, does anyone in the audience want to give a wild guess? 1 * 10 - 5. Well, because these are million, uh, it's a little higher than that. Uh, in every transaction, you can pack little more instruction, but it could be slow actually.

Anyone else? 80. 10 minus uh exponential minus five right so like yeah I can't even describe the number like 10 instruction per second 800 instruction per second um so I'm going to give you another scale another hint um a recent Intel processor is about 400 billion. Let's go on the next slide. I'm going to inve somebody else wants to give a wild guess how many meips this is really important.

You know, Ethereum is a global computer and we measure those kinds of computer by myips most of the time. Now teraflops for the floating number for the AI people but MIPS used to be a very important one. So it's number of instruction a CPU can like process per second. Okay. So let's put it down on a scale.

the Intel i9 CPU 400,000 MIPS 412 billion instruction per second. Now for the older people who ever had one of these Atari about one MEIPS it's it's already pretty good actually there is a typo 1 million instruction per second don't read 1 billion it's a typo here is Ethereum a third of a mess 350,000 instruction per second that's not bad and that means with consensus of all worldwide connected nodes agreeing on every instruction. We shouldn't be comparing a network with a CPU, not the same thing. But it it gives you an idea of like scale and we can speak about global demand where the internet the cloud computing has been doing and this is a hot topic now with AI we need more and more data centers compute power okay a small word about myself it's traditional in the talk he already made me an intro so I will go quickly Um, yeah, I don't know if it looks like me. This is my AI version.

Um, so I'm the open source maintainer of state channel.org, which is historically um the initiative for state channel. I'm the initiator of an ERC called 7824. I invite you guys to have a look. And my work is to build the next generation of financial infrastructure high-speed trading network.

Hence why we use state channel. And in the last month I been spending more time speaking with AI than with real people. like today might be the maximum of myself speaking to human. So yeah to give you some perspective back to like where we are with blockchain we don't even utilize you know our compute power to the maximum currently on blockchain. So the adoption is not here but the rest of the world we're talking about close to 12,000 operational data center which each one of them have thousands of Intel Xeon processor which process billions of meips per second and we're talking about 5% of global world power consumption.

This is ridiculous. This is growing. This might be doubling in the next years with the AI race. Um, so yeah, I can't even put a scale. If we would compare Ethereum and 12,000 data center, but the data centers are a network of compute.

So, Ethereum is but that's not the essence and the idea behind Ethereum. It's very important to understand that it's a shared ledger where everyone agrees on the execution of the instruction. Most web free application must though adhere to the real world environment. this um hungry for compute society mass consumption that we are facing um and this has always been a recurring topic Ethereum scaling how do we scale there and there is this Ethereum road map we're talking about L2 this is accommodating the micro fraction of us DeFi user which is absolutely not representing the billions of user using the internet. Um so yeah, maybe now it's fine uh because we just are the 0001% of actual blockchain users.

Um later on you can imagine it's obvious that web free application are going to need to scale like you know Tinder scale, Twitter scale, YouTube scale kind of applications. Hold my beer. We might already have the solution. As I mentioned state channels are already 10 years old. nothing new.

Uh the first mover of Bitcoin already were thinking Bitcoin is never going to cut it. We're going to need to do like Visa type of payment flow processing. So let's come up with lightning network. So state channel are not something new. We just were struggling with an adoption system.

Um, so there are a way to teleport yourself away from a blockchain offchain and transact offchain without any fees and let's say latency finality. So there are the true peer-to-peer TCP IP connection. It can go as fast as the hardware gets and this is very important. So the state channel you can think of it as an elevator from the blockchain to the fast compute world. So this state channel could be the bridge from you know our smart contract layer to real world compute use case.

So it offers instant ofchain interaction natively chain agnostic. This is the oldest chain agnostic technology we know of much older than crosschain intent and this has been around for a while. And back in the days, people at Bitcoin figured out, let's do some hashtime lock to swap Etherum with Bitcoin without central authority. 2013ish. It's fully horizontally scalable.

Um, any blockchain is not horizontally scalable. Horizontally scalable means you add more server, you will have more throughput in in a scalable way. There is no bottleneck in state channel. So most of us actually already use state channel. When you log fund and go offchain, for example, perpetual decks, you log a deposit in and then you you trade with a offchain order book.

So this actually quite common just people don't call it state channel though they mimic exactly what a state channel is every time you escrow and do business offchain which probably many game fire industry are doing because they need the performance the real-time gaming um so they already do it. So what's the problem? So let's go from the theory to practice. At yellow um we are we have been four years using state channel and we moved from the theory to the practice and it was a painful journey that I'm here for sharing it. So in theory they are simple but in practice you need to come up with an offchain protocol and they are very hard to design.

There are nothing alike that most of us developer know it's not like clean RPC you need to come up with new offchain state machine I pass you the detail they are very difficult to design and you can discuss with your engineers for weeks and weeks without coming to a consensus on the architecture of your protocol it's painful it's scalable But you're gonna need to design your own peer-to-peer network to be scalable. So, are you going to use lip pee? Are you going to do your own routing, network mapping? How do you build a peer-to-peer network from the ground up? What's the direction?

This this is not a small architectural endeavor to design a peer-to-peer network. It's crosschain but there is no developer consensus on the on what is a state channel how we should describe it and what are the types. Uh this is one of the big pain point of the practice. As long as there is no chain agnostic crosschain norm state channel are hardly crosschain because everyone use another long wage to express it. for the story.

Um, in Texas consensus, I was with the, um, Cardano CTO, French guy, great guy. And he say, "Oh, I love State Channel. Uh, we supported natively on Cardano." I was like, "Oh my god, why why somebody would do that?" You know, because they are great.

They have a great potential but it's untapped gold mines today and obviously a Cardano state channel would be radically different than a EVM implementation or a Bitcoin um hashtime lock. So the solution obviously is ERC ERC ERC standardization and not only ERC the new stuff called I guess CA the the chain agnostic um RFC and um we need to write documentation we need to get you developers involved commenting this is a request for comment and only then When we have a developer consensus, we can build on this our SDK. An historical project that started maybe almost yes eight years ago um gave birth to a framework uh called Nitro. And Nitro is great. We love it.

We worked years with this guy trying to make it um um going to production and this is where we had those pain point and in practice we couldn't see the end of it. Hence the initiative of Nitrolite which is a simplified version of Nitro um within the same ERC and we trying actually to provide more responsibility to blockchain for setting up channels. So the developer have to do less painful work offchain. Our entire focus here is developer user experience. So our work on state channel recently we have simplified um the legacy nitro made it nitroite which means dynamite.

We created a RPC message protocol a standard based on RPC for request response which can be understood as state channel states. So people don't need to come up with new messaging protocol every time they want to use state channels. We created a TypeScript Go SDK to allow rapid development of apps and since we abstracted the back end and the solidity uh from the developer from the RPC there is no need for you guys to eventually you can start making a nitro app like a DAP and you wouldn't have to worry about making a custom solidity adjudicator. This is our contract. Um, in EVM, you just need to implement an interface.

Um, and you wouldn't need to write like a custom RPC backend server peer-to-peer network. It comes out of the box. Okay, I got two minutes. How does it work? So you can see that you know those layers are what made the internet great.

We could build with layers and only focus on improving each layers rather than rebuilding the entire internet stack. And you know blockchain will have this layer one layer two. On top of it you can deploy the nitrolite smart contract. The contract is simple enough to work in pretty much every runtime, EVM, was you name it. Um, and Nitrol light is a state channel management service that focuses on escrowing digital asset and communicate with teleport.

And teleport is a mesh network, a peer-to-peer network that makes a virtual ledger on top of every blockchain that has nitrolyte. So we can expand our layer free network by simply deploying nitrolyte and anyone can check in some collateral and teleport this collateral on the virtual ledger. So once you the virtual ledger is operational, somebody that checks in asset from say Solana can be using an app that was intentionally developed for base chain. Um and there wouldn't be any compatibility, recoding, adaptability. this would work out of the box.

Um, so I I show two use case. One of the use case is that you can just do for example games, two players playing snakes uh through their screen or chess or tic tac toy with money at stake. Or you can think of nine players poker table playing with web clients and entirely um checking in their There are chips in the teleport infrastructure and then they just send RPC message to each other um about any play they are doing and out of the box this will adjudicate um who is the winner of the game. Um and the last one you can just have typical client server architecture something everyone is familiar with through this you know proxy middleware that will give you you know this blockchain virtualization layer. So you don't need to speak to blockchain anymore when you code your apps or your server.

You just need to understand the virtual ledger at least has a,000 USDC. Okay, you can trade. Okay, you can play on the table, etc. Well, my time is done, so I'm going super fast. You can install and visit the GitHub ERC7824 npm install the Nitrolite package and you can get things started with the Nitro RPC.

And yeah, that's it. Uh, please feel free to scan. It's going to bring you to the website. You're going to see some um user doc and we'll update it soon with the Nitrolite SDK. Thank you everyone.

[Music]