Secure Reactive Web3 for Everyone

Transcript

[Music] all right all right hi everybody it's great to be here um do we have a lot of builders in the room infra Builders all right cool okay so um yeah so the one one thing I really like with web 3 and U I mean computer science and 1 three in particular is that uh sometimes you look at at a problem with the a fresh look and that's really and there there's really a lot of innovation that can happen with just just a few just a few people you know and uh uh and that and

that's um that's really I found it really motivating and so when I started linear around this is the problem I had in mind was uh was how to scale how to solve scalability uh and user experience for web 3 and so this talk is uh is very much kind of a result of a of a of a long process starting with with this this ambition and and and slowly understanding that we were missing uh like it's not only about transactions per second when you want to really provide good user interfaces you uh you really need to look at at the at the responsiveness of the interfaces the responsiveness of the applications and

so um and so technically you really want reactive applications and so this talk is about how can we make this a reality how can we have reactive applications in web 3 without um training of security and decentralization if there was any doubt that uh reactive programming is important we can look at what's happening in web 2 um and what's amazing is that you have Frameworks like react GS that have tens of millions of projects uh using them uh if you if you just look at the stats on GitHub um and so and so definitely this is this is a standard this is the way

people are used to program user interfaces and uh concretely what does it mean so what it means that you have a web UI that's going to maintain connection with the servers and be ready to receive notifications and what you want is that when there's a notification you want to be able to pull the data pull the updates from the server and process them and refresh the UI okay and the quicker the better the experien is for the users you may be interacting with other users you may be playing a game you want things to be fluid you want users to to never wait on the interface and so can we have this in web 3 well let's look at the at the current stage the the the current state of web 3

is that it's really mostly about transactions I mean arguably when you when you look at what are the when you ask people what is the N2 latency more often than not they tell you they they are they're going to consider what the end twn transaction latency is and uh so they're going to look at the time it takes for a client to uh initiate a transaction and and get get it final get it confirmed uh as part of the blockchain okay but it's only about the writer and you may ask okay but what happens with the second half uh what what happens once the transaction is executed and and now you want to know that the the receivers of the transactions of the receiver will have

their uh their UI updated right so so one thing that we really want to work on in web 3 is is the data latency for the readers okay another thing also that uh arguably is not perfect just yet is also the security uh of the data when you when they are being read from the blockchain uh so data authentic right and so I'm going to speak also about that so the the vision here that um we'd like to Advocate is that reactive programming should be easy and and secure for everybody in in web 3 imagine a word

where you when you start a payment the not only it gets confirmed very quickly be below a second on the right side on the on the center side but the receiver will also receive a notification in under a second that the money is there and then you is refreshed immediately wouldn't that be nice right so and now in the world of gaming for instance if you had a system where you have very quick notifications then you would be able to deliver the user reward very quickly when and you can imagine that from the point of view of a gamer it's kind of nice you're interacting with the with the game you get the rewards they are final they're onchain you can see that you have them already

so it's it's a nice it's nice thing to have right but of course now if you have an infrastructure that supports these very quick interactions between users then you can start also thinking about having an onar game on chain so like we spin um maybe we we can spin a game you uh you can you can make a move the other users see you move they react and everything is fluid uh what you don't want is if you're creating onchan games of course you don't want to uh have a round trip between the users that is like 10 seconds 20 seconds nobody wants to play chess like this right um and then finally there's a third category of applications uh that I think would benefit a lot from having

secure uh reactive uh applications it's the it's the it's the multichain what I like to call multi-chain Define so Define of course the centralized Finance is one of the domains where there's the most obvious product Market fit with block blockchain Technologies but so far it's been a lot about single chain Define so you you have Atomic composability inside a single chain you are you can run Unis swap you can you can uh and it works but we we know so the world uh has changed and now we have a lot of chains that are running and so so it's more likely that

when you want to do Define nowadays you want to interact with multiple chains in parallel so now imagine if you had um a relable and secure notification system to provide you with with with with notifications about your different trades your different um ongoing positions with the different chains a number of things would be would be possible you would be able to obviously you would be able to do Arbitrage across the chains you would be able to take several positions maybe overcommit and when you're matching on one of the chains you can quickly adjust uh adjust your bids in the other chains um and and that's what some professionals

do but it's a lot of work you need to run full nodes of all the chains you need to optimize for the latency and so imagine if we had an infrastructure that makes that available for normal users uh from their web browser or from their mobile phone how can we make that happen so let's look at the current state of uh uh developing a web 3 application how does it work currently you you have a web UI and usually your browser doesn't have a full node for the layer one or the layer two you're using so what's going to happen is you're going to talk to an API provider and that API provider is talking to the the blockchain

infrastructure now the problem is first in terms of security more often than not the browser is just trusting the data from the AP provider so we'd like to to do better there's a technological light client so you are you basically ask the API provider to prove to you that the data that are served are authenticated are correct and tied to the security of the underlying blockchains the problem the the light clients come with a number of of restrictions they don't support arbitrary calls they can't only prove to you the store data um and uh and in practice uh the adoption is very low there are also some some um attempts

to to make light PLS more appealing in particular to support arbitrary calls with Zer knowledge proofs but that's going to add serice side cost and latency and so in this talk we're concerned about latency um and so we can see that uh it doesn't seem that like lines are going to be quite uh what we uh can use for for reactive web3 for secure reactive web 3 and in general when you look at the all the existing layer one layer two um I think it's fair to say that the main focus has been historically transactions PR second um and our block our our our infrastructure they actually have a maximum TPS which is kind of scary if

you're an infrastructure Builder uh that you're not going to be able to scale above a certain thresold so everybody has been uh has been competing to get the maximum number of tpos supported by by their blockchain nowadays we're also seeing some recent layer ones making really good progress at low fil enity so the time it takes to confirm a transaction is starting to look pretty good like in some cases under a second what nobody's really looking at is the data latency the time it takes from the layer one to uh after the layer one has confirmed a trans action the time it takes for the API provider to pick to pick the changes to index them to make them available to the other users that didn't initiate the

transaction this is data agency and this is hurting um reactive programming so can we do better well of course uh some users could just run a full Noe so that solve the problem of uh trust you don't you you don't need to trust an API provider because you're running it um and and of course if you invest a lot of material a lot of Hardware you could maybe make the home the maybe make the homemade indexing uh fast enough for for a number of applications but most users if they if they're on the web or mobile they just can't run a full not of eum that's just not

practical so what can we do uh we need to take a step back basically we need to we need to redesign a system and and and really prioritize data Dy low data lency so the solution that we're advocating at Lera is to introduce A New Concept that we call micr chains so what we're going to do is going to have a separate layer that has block space organized in a different way we want something way more user Centric we want um to have users have their reserve a reserve block space a small chain of block where they can keep their assets and keep their application state

so that it's easy to create blocks and easy to replicate the data of the user from validators to their wallet it's changing the programming model it's it's a b it's a bold move we are giving up Atomic compossibility but we're going to replace that with a very rich programming programming model where you have question messages that are very cheap you have chains that belong to users but you also have chains that are shared between users um and inside the chain of course you still have composability as usual okay so how does it look concretely when you have a system based on micr chains you um so we're going to have a a

number of validators they're going to be maybe a bit larger than uh than eum validators because we're going to ask them to validate um the chains of all the users the micr chains of all the users are going to be secured by the same vators they're going to have the same level of security and we're going to have asynchronous messages between them um and so the the nice thing about designing a system like this is that you can use the internal network of validators um and make the messages way way cheaper and way faster than usual than in in Block traditional blockchain Charing system for instance and now when you look at the user wallet so the user wallet is going to have a replica of a number of micr

chains that they are interested in so in particular in this example so you have a user that has micr chain B and that micr chain is going to be replicated and and maintain and and now the user can create a block anytime they want and tell the validator okay it's my next block uh please validate this block and give me back a signature and and so in the in the simplest cases you only need to do that once you get a quorum that's it your block is final and you can just broadcast broadcast it back to the validor and then the validor are going to execute your block and then they can notify other users uh if they receive a message for instance uh that has been

just triggered by this block so what we see here is that when using micr chains we have uh split by construction it's a system that is indexing friendly we we have structured the block space in a way that we know exactly which user uh where the users are storing their data and their assets and we know exactly who to notify when there's a new block added somewhere so linear is an implementation of this ID that uh us is using a proof of stake to secure the validators and is optimized for quick finality and and and low latency client synchronization uh for the programming

of the applications we're using rest and WM we're working on uh on interoperability with evm chains and a hybrid model to introduce um a very very strong Security on top of the validators potentially even with a bridge to eum eventually uh I meant a roll up to eum eventually um and so what does it look like in our system so if you compare to the previous diagram you can see that we don't need a data provider in when you program um most of the applications in in you will just uh replicate the micr chains inside the wallets of the of the users and then the wallet will be

serving the data to the web UI so in that system the wallet is acting as a as a local data provider which is something that is uh that is very original and it's completely unlocking uh um what exactly what I was talking about the the reactive programming and the notifications fast notifications to the users to the user UI um just a quick word we we chose WM rest and WM uh it's it's actually a really good choice uh if you going to have um a wallet that contains chains and it's going to execute transactions so that wallet is going to have a VM and so by choosing the wasm VM we get a v we get the VM for free essentially uh we just

need to add some instrumentation to ad metering and suddenly we got um a portable system that can very cheap portability for um for transaction execution between vors and web client so now let's zoom in into uh this idea of having a wallet tracking chance so in uh when you're using micro chains your your wallet is going to have actual chain of blocks for the the micro chains that the user care about and um and then this chain a particular chain will have a number of applications that are being used each application has two bite code files one

that is we call the contract uh bite code and one that we call a service bite code and that's something that's really it's really interesting and kind of unique the contract bite code is uh is is there to execute transactions it needs to be U deterministic execution and meod so this is traditional blockchain um um execution model the service bite code however is is is fairly unique it's you you have to imagine that you have some code that is immutable on chain but is run off chain and that code will not be able to mutate the state of the of the applications only querying it but on the other side it doesn't need to be mattered and it

doesn't need to be deterministic and so this is where we leverage here to um to help applications create their own specific data provider for their own uis so now when you're in web UI what you see is that you have this magical local data provider you can send graph qu queries to to uh to query the state of the chain um or or to quer instead of an application and then the application will execute uh the Wim code created by the authors of the application to to answer your query so the nice thing about it is that there's no need for metal proofs or Zer Edge

proofs it's very um so it's very low cost uh and it's run on the client so there's also no need to pay for any fees uh the the the just the web browser of the client is doing the work another side benefit of that by the way is that when you want to create a block you can just say hey I want to initiate uh um this is what I want to do I want to transfer assets or I want to make a move in my Chas game or something like that and you the web UI is going to is going to um uh is going to make that intent visible by making a what a m a graphical mutation and and the wallet can actually create a block for you uh

that corresponds to your intention so that solves the problem of visualization um that is very hard to use in normal in the in normal wallets in normal wallets the URL will actually build the transaction and then send it to the wallet and so the wallet has this transaction that comes in that is supposed to sign but if the wallet hasn't specific code specific support for the for the particular eum application can be really hard to present the user a meaningful confirmation message before signing the uh signing the transaction so in our case the wallet is the one building the transaction in the first place uh based on um high level intentions that have

been specified by the web UI so it's much easier to uh confidently sign the data sign the uh the transactions before um um by the user all right um so now what does it look like reactive wrapping up what does it look like reactive web 3 when you have micr chance so you have a user wallet that is maintaining a connection with the validators that is able to uh propose new blocks getting them U approved by the valers and getting quick finality for those blocks um and then through the the connection you can be notified by the

vators when somebody is sending you AC cross and message that is kind of waiting to be picked when that's the case your wallet can uh react to notification and synchronize the missing data very quickly from the validators and in a way that is sensorship resistant by the way the um and then you get the data replicated on the wallet side what's important here is that the wallet when it receives blocks is going to verify all the all the signatures is going to reexecute the transactions if that's one of the chains that you care about so at the end of the day you get the state of the chain on the client side that is fully uh authenticated and ready to answer questions from the web uh from the webui and in fact for the same price you also

of course you can notify the webui if it has subscribed to modifications then the web UI can can quickly pull the data from from the wallet and refresh using a reactive framework so that's it finally we have a framework for a fast reactive fast and secure reactive web3 programming it doesn't require complex uh cryptographic uh systems like zero knowledge proofs uh it's it's fairly natural to program in this because from the point of view of the web UI you are just GR a local service that is using standard web two concepts like graphql or Json um and um um yeah and that's what we do and now bonus we have a few

minutes so we in uh our user wallet I said that we have some service code that can answer queries and that's using a VM that is deployed uh in the wallet and so of course the F next thing we did is to put AI on the edge in the wallet of the users and so what we did is that we programmed we did we programmed the description of of AI models on the blockchain and then and that that means that now the users I mean the UI of the users can query their wallet and the wallet is going to run AI in France for them so you're like okay but why should I run AI

inference my wallet well the wallet is a secure Enclave that is running trusted code that is either deployed by the provider of the wallet the software developers over or that is that has been deployed on chain and has been audited and this by the community so you have your your a secure uh a secure Enclave that is that you can trust that is going to run AI in France you could query the AI the model using private data you have the insurance that the data are going to stay private they are just run by you on in your wallet uh the models are just run by you in your wallet so you know uh you can trust the result of the

computation so um so that's where for instance you could have your private AI Financial agent okay to help you make decisions about trading especially I was talking about the multi-chain defi use case so seems like it would be really nice if you can have your uh have number of connections open that uh are making you aware of the changes in the auctions that you're participating with and your AI Financial agent can uh can your financial AI agent can help you um process those notifications tell you what to do next um in this particular demo on the that is on screen right now what we did

is of course more modest to get started what we did is a generative nft so the idea of a generative nft is that the content of the D nft is not going to be an image it's going to be a prompt for an llm model and so here we're using a demo that we took from a Rest Library called candle and we put it we packaged it in our own framework for um U for web3 development and so on the uh on the right side you see the prompt once upon a time there was a magical Kingdom called Web 3 and that prompt would be onchain and immutable and would be the would be mtin as anfed and then everything else the rest of the story is

the result of running the llm on that prompt and so you have a system where the nft is very short okay and the visualization the rendering of the nft is very cheap and trusted uh and so you are kind of The Best of Both Worlds all right so to wrap up um I presented a system um so most blockchains right now they prioritize um the story for rights they PRI prioritize performance for transactions but um currently uh the story for data latency for the reads um is still um I would say questionable it's still up for up for up

in the air with micr chain for the first time we propose a system where we organize the block space to be um to be indexing friendly to be structured around the notion of user accounts and potentially the user the notion of objects this uh is very convenient for uh to for reactive 3 really enables fast client inv validator synchronization and we are the first decentralized infrastructure to use that idea all right