ZK12: Some like it proved: an architecture for provable apps - Lancelot de Ferriere

Transcript

[Music] hi everyone uh thanks for coming welcome welcome this will be a little more uh light on the maps and some of the other presentations here which should be good as a interm medo just before the break or G as we say in French uh what who I am uh really quickly I'm lelot I'm co-founder and CTO of highy uh we're building a blockchain network targeting provable applications or ZK apps uh what I'm going to be talking about is what we're doing but it's also what we think will happen anyways um I was previously working in the startic system on an nft

protocol uh called brick you might know some of that uh which was my introduction to zero knowledge technology and validity proofs and things like that um what I'm going to be talking about is what we think will be the future of DAP in smart contract development um thanks to zero knowledge proofs and both the impact this will have in applications and on blockchains because I'm talking about a blockchain context here so uh let's do a quick thought experiment let's say it's 2030 and you were you want to write an onchain game um so let's quickly answer the question why would you go onchain I usually stray away from answering that but there's a few good reasons why you

might want that maybe you want the censorship resistance maybe you want the composability and the liquidity AIS maybe you want to use the blockchain as a distribution Network and a few other things that are legitimate but those are like the three main big ones so if you want to go onchain still because it's 2030 you don't want to think about cold data size or gas cost and all that jazz uh you shouldn't have to think about that in 2030 and because you're making an onch game you want to have low latency you want it to be about real time you know you want it to feel like a game and because 2030 maybe somehow the metaverse is hype again and you want people to own an nft to be able to play your game or something but maybe you don't want them to have to show which

nft they're using so you want privacy and with privacy you'll have to use uh zero knowledge proofs so you have a proof of concept of your game written in Rust so you'll want to use one of the ZK VMS that you can run rust on uh there's a bunch of them but because it's 2030 you can use SP2 or risk one I couldn't find a good word play for Nexus or valida or jolt or any other ones uh leave a comment below if you find one that's for YouTube later um yeah so you're writing your application how do you put it on chain well our argument our thesis is that applications and RPS will become uh interchangeable as in both will be the same thing

essentially rups are apps and apps are just rollups in that model uh transactions you know so blockchains are just State machines you have a state you send a transaction that operates a state transition to a new state rollups just take that and apply ZK or validity proofs depending on the context to that essentially your transactions are just proofs of a state transition so you have can I point yeah um you have an initial State that's like the green blob let's say and that's just a state commitment uh it's like the iceberg thing it hi that most of the data is not necessarily stored by the chain but it's

there you just have a disc commitment and all of your transactions are just State transition so you go from the Green State commitment to the Blue State commitment to the red one and every time there's like an underlying database that's full of information that you don't really need to know about to know that the information is secure because you have a ZK proof that there is a valid transition according to your application from the green blob to the blue blob to the red blob um the key thing here is that those are order and of course you need to know some information about the program to be able to verify the proofs so depending on the system that could be a verification key u you know an image ID a bunch of other things um how do you generate the proofs uh in

2030 you'll have a few options you'll be able to do client side proving uh if you have access to the code of the application and you have access to the state of the application because all of that is open source or widely distributed you can just generate your proofs on your own computer because it's fast in 2030 or you can do a small computation locally and because the application you want to use is huge even though it's fast you want to send the rest to a centralized server to um a B2B app that wants to do their own thing with it uh to ass essentially or you'll want to leverage aov a market of some kind where you just say well I have this thing I want to generate a proof and people do it for you and you pay them for that and then the proof just gets sent to the

chain and we you know Act um the state transition once the information has been sent to the chain of course you'll need to uh read it you'll need to like see it and for that you'll need to index the information uh again this is pretty straightforward to do um you have a bunch of options but the two big ones will be that either you'll read the information yourself on the chain and reconstruct a local database that you see of the of the app information or you'll have to rely on the DB server to do it for you because they're doing their own indexing but it remains trustless even though they're doing it because they can prove to you that the information

they're showing you matches what's on the Chain so that's a miracle inclusion proof or something like that that's like the whole property you know of um of the um data Integrity security provided by the chain and you have the iceberg within the app infra so quick recap trans actions as proof of State transitions deps are just verification key and state commitment or state route users can prove client side or use Pro services and Chains Don't store the data but guarantee its Integrity which is much better because blockchains are terrible at storing data and um thankfully indexation remains trustless now let's end the F experiment

and think well why not do it right now it's 2024 and you are right an onchain game well you'll have a reality check happen pretty quickly because there's a few problems um the first is how do you do composable contract calls easily the second is that because it's 2024 proving time and proving time latency are a big issue and the third is probiz uh let's get the simple one out of the way to give an example here you want people to own a crypto Punk to be able to play Tetris I'm not going to say why because there's really no reason to but why not um if you are trying to do this conventionally you'll have to use recursion essentially you'll have to

embed within your Tetris game the verification of the proof of ownership of a crypto Punk and you know I don't know that might be like storage call on ethereum or something it's kind of unimportant but the basic idea is that if you want to change that or if you want to change the Crypt contract you'd have to update your Tetris contract because the two are embedded together you can't change one and not the other and F like that and also you need to be able to verify the proofs uh so that implies that you h you know you're doing recursion which can be slow complicated this type of thing what we think will happen in the future and what we're offering at highly is actual composability where you have two separate proofs uh within the same transaction and you have the proof that you own a crypt Punk which is doing its

own thing and then within the tetris proof you essentially say oh protocol can you check that there's also proof for the ownership of a crypto Punk and the protocol will do the check separately so it's um essentially like in a functional programming context we're pushing the side effects to the end of the computation and we're just everything that things seem to match at the end instead of doing it um along the way in a more linear um pattern so that's the easy thing but to take another example now which might be a bit more realistic you have an auction uh the auction is ending at this point that's my like red Time Red Bar on the timeline um let's say you see the

auction you want to bid but by the time you generate your proof well the auctions ended because I don't know it was terribly written and it took several hours to generate the proof well of course you're sad because you couldn't bid or and this isn't even worse problem maybe you saw the auction and another guy did it at the same time and at this point you both observe the initial State commitment of the auction contract which is this uh Green State you both craft your transaction they're both state transition from this initial start State that's green uh the guy on top is blue you end up on a red State uh the guy on stop is faster than you because he's got a better computer or something he sends his transaction first and at this point

your transaction will necessarily bounce because the proof of State transition no longer applies uh I don't know if I can go from Blue to Red um so I just don't know what to do and I have to reject your transaction and again you are sad There is thankfully one solution to both of these problems and this is what we call delayed proving um essentially it's like if you go to restaurant you can make a reservation and you can always you know claim the table when that time comes both you and the other guy see the auction contract you send the blob some piece of data uh defined by the application the auction contract and that arrives on chain immediately and

then essentially you have some more time to generate a proof that this transaction was indeed uh correct that you indeed have the money to bid or some other uh requirements the good thing here is that once you've sent the two initial transactions they're sequenced and so you can observe observe uh that you'll need to craft the second one the proof based on top of the blue State not the green state that you initially saw so you can J the proofs based on the correct State and you won't have this parallelization problem and you again won't have the time out problem because you don't need to wait for the proof to be generated to be able to send it to the chain so you can send just claim the plot start generating the proof once you

know that you're good and uh well both of you won't be happy I guess in the case of an auction but you're still happy because you managed to send the chain uh to send the transaction to the chain and do your thing so if it's 2024 but you're using highly well you can do something that's I don't have a word for it I wrote permissionless r mode and I don't like that but uh essentially you want low latency as I said earlier so what you're going to be able you're going to want to do for a game is make something that's peerto peer uh your players amongst themselves are building a consensus almost in real time uh that's something that for example the playment team is building towards and occasionally you want to like send some side effect um to a blockchain because that's where you

want to tap into that liquidity so I don't know you won a game and so you should earn some reward or something you just build your consensus amongst yourselves occasionally you send that information to the chain and you have plenty of time to generate your proof even though it's really complicated because this is a video game and even though it's uh usually like would be latency dependent because we've moved proofs out of the critical path of like blockchain interaction essentially and yeah this is good also because in terms of gas costs well the chain is doing very little we're just sequencing the information providing a little little bit of data availability because we need that and settling by verifying your transitions transactions so we call

that a lean blockchain basically seeing blockchains just as custodians of data Integrity thanks to zero knowledge proofs instead of like um I don't know like the old view of the world computer just providing sequencing a little bit of data availability and settlement and thanks to stuff like delayed proving and Native proof composability you have high performance the same level of programmability that you would have on ethereum or any other regular blockchain except you're not like interacting with five blockchains like you would if you were using different layers for all these things it's all happening in the same in the same place um so if you want to like try this thing out you have some cool idea for

provable applications uh you can talk to us this is the QR code for our telegram or you can come talk to us in person well today of course or uh tomorrow at our fancy p uh which we're organizing pretty close by um yeah and we'd be happy of course to have you and uh talk what we can build that would be cool thanks for um Coming and I guess I have some time for questions maybe absolutely but give me a hand first [Music] [Applause]