ZK10: o1js: The dawn of zk smart contracts - Gregor Mitscha-Baude
29 Sept 2023 · 29:28
Gregor Mitscha-Baude, a product engineer at O(1) Labs, introduces o1js, formerly SnarkyJS, at Zero Knowledge Summit 10, the TypeScript library and embedded DSL for building zero-knowledge applications on the Mina protocol. He covers the design characteristics of zk smart contracts and how o1js's architecture addresses challenges zk developers commonly face, and previews Berkeley, the upcoming Mina hardfork that enables zkApp programmability alongside classical smart contract features.
Speakers
Topics
Transcript
foreign [Music] labs and ZK security presenting 01js the dawn of ZK smart contracts so thank you Gregor thanks Rachel I hope you all enjoyed your lunch had some interesting conversations they're ready for for another talk so my talk is about o1js and seek a smart contract my name is Gregor I work at overlaps I work for on o1js for about two years now
and yeah I want to I want to start with one of my heroes um italic so in last year on at Devcon vitalik laid out his his vision for for the ideal blockchain um what is what he said was imagine a world where everyone just just runs a note on their smartphone and you know when a new block comes in um you just have to check it against a snug and that's it you you know that the block is correct so there's one there's one blockchain that
actually works like this today it's Mina so on Mina we we proved the entire history of transactions uh down into a single into a single proof with recursion and so so what you get is uh you can have clients running on like your browser which have full node security they can they can verify by themselves that that's the states that they have is correct um so so you don't no longer need centralized RPC endpoints or you know you'll no longer need to trust them um that's really cool but so far there's
something missing so smart contracts of course that's why we Mina is now launching CK smart contracts so not only will will normal payments transactions be be all merged into single proof but now we will have Smart contracts running in a proof and their entire execution will also go into this single blockchain proof that everyone can just cheaply verify um but it doesn't end there because by by moving smart contract execution into CK we get additional
opportunities to to make to make it more interesting so these smart contracts aren't like plain old smart contracts so the main difference with classical smart contracts is that our secret smart contracts run of chain the execute off chain and so this picture shows you uh how this looks like on the on the left side you have like uh an end user machine and that could be for instance your laptop and you would be say you are on a website and are interacting with a contract what happens is that
the contract gets caught on this website and it executes there and it creates a set of updates to the chain and also a CK proof that this is this was done correctly and this is sent to the meaner Network and on there this this will be verified so it will actually look up your contract your address and it check will check the proof against a verification key so it's instead of having code that you Deploy on chain you just deploy a verification key yeah so this model has a couple of major benefits the
the first one of them is of course privacy you no longer have to send all the inputs to the chain it all executes locally so it can have secrets from the user in it and it's it's a CK proof so it doesn't reveal anything and this is this is really a huge step forward that smart contracts can now have privacy it it enlarges the scope of what what smart contracts can do and create we create opportunities for a lot of new new kinds of applications the second one um is unneeded computation you you no longer have to count uh how many instructions these these contracts use
um so you don't need a gas model because it all happens on the client side um then you also have a security benefit because a whole class of bugs is is eliminated um the bugs that are that are related to running arbitrary code on on a set of on-chain nodes like re-entrance re-entrancy box if you know that one um and also because we don't no longer need a Sandbox smart contracts they gain a lot of flexibility so I mean a smart contract could actually make a network request and put the result into a witness for for instance so it's it's not a Sandbox as
classic contracts have to be so one application of this could be for instance you know oracles on ethereum they they post a data feed on chain um so that other countries can use it Amina the Oracle could but just be on demand so you just call the archery contract and it fetches the latest Oracle data and gives it to your contract and it's r121 Atomic transaction that then gets sent okay so we see that there are a couple of benefits and I would actually argue that this uh this is this is all you need so this this model is so much better that you
don't really want to go back to our chain execution I think probably in 10 years if you're writing a smart contract typically it will be that kind of contract and I also claim that you don't need any any launch in contracts anymore okay so how how do we make this happen uh on Mina we will have a hard Fork and it's it's under the code in Berkeley and this this has been in development ever since I joined and ever since uh since our main at launch and we've been running public test Nets since over a year and now uh we're ready to to go to the next step
because we're pretty confident now in our testing so I'm happy to announce that we'll move to to an incentivized test net and that will be starting in October and go check it out you you can see a link there and yeah I also want to invite you to to participate there it will be interesting rewards and everything and I also want to invite you to start building on on Mina so you might never have heard of OMGs and that's because you just renamed it
it used to be called snarky.js so we rebranded it to to give it a shinier branch on your name um to give it the spotlight it deserves and also at this point I want to mention that snarky Jazz was never the same thing as Snapchats it's completely unrelated so yeah um so what is what is o1js then OMGs is a CK framework and its functionality uh so orange is the secret framework and it's written in typescript and you use it from typescript and its functionalities it consists of
two two main parts um first first of all it's a general purpose DSL so you can you can Define circuits you can you can create proofs verify proofs everything you would expect from from a ZK framework and you could you could also use this to to do peer-to-peer proving for instance or off-chain use cases of CK it can be used for that and second uh it's it's the framework for writing mean a smart contracts so in addition to to having this General CK DSL interfaces it all says API specific to writing smart contracts for mina like something to to get State
and interact with State on chain and apart from that it comes with a rich circuit Library so it has bit operations comparisons stuff that you would expect specific to Smart contracts um so you have Poseidon micro trees nullifiers and very soon we will also add ecdsa so foreign field arithmetic ketchup shuttle it's we also have a ever like Dynamic lookup feature that you can use to to do in one constraint look up any element of an array dynamically we we have infinite
recursion that's that's exposed at the at the OMGs layer so in your smart contract approved can just be one of the inputs and you can verify it in your contract with with a function car yeah and under the hood it's using a version of Planck with with some Custom Custom Gates that are made to make recursive verification really fast um it has no trusted setup because we're using IPA and also we're actively developing this so there's there's much more to come right now we're we're developing a kcg backend for some other use cases um we eventually we will have stuff like
folding and yeah so sometimes uh people ask you know why why are you using JavaScript isn't isn't JavaScript bad so the answer is no JavaScript is the greatest language in the world but [Music] um maybe to understand the motivations I want to take a step back and look at the wider landscape of CK front ends what what other people are doing so I've I've organized the different
front-ends here on two two Dimensions the First Dimension would be does it does it write circuits directly or does it write ckvm instructions and the other the second dimension is is this is this a whole new language specific to to CK or is is it using an existing language and you know there's there's different ways you can use an existing language so so this this gradient here it takes an existing language and compiles it and then runs it in in CK so you here you for instance have the CK EVMS risk zero and also the latest entry here is 013m it's the VM we we create for
optimism to run the fraud proofs and okay but oh one chess is in this gradient here which you could call the libraries they they don't take the language and compile it but they just use the language at runtime so you you were building circuits at runtime in this host language you could call uh omanjs and embedded CSL and you know I really want to say that um all of these Frameworks are great projects and they all have a good reason to do what they're doing and they're they're very very real
trade-offs between between those different choices you know you could argue for instance that either either creating a custom language or going to the VM route both codes make it easier to to write circuits but I want to argue that the fact that we're in this bucket is actually very intentional it has a reason and I think it gives you some unique benefits that you can't have with the other models and the best way I can convey this is with with a screenshot that I made so this screenshot I made a couple of days
ago you know I I opened my browser Firefox and I went I went to the to the developer console where you know I opened this on a blank page and you you know that you can just write some codes there in the console and just run it you know and so what I did is is a I wrote this code using o1js it just Imports it from a CDN and then I I Define a CK smart contract here foreign so so this this has a method which is really a CK circuit and it's just defined in this JavaScript environment
and then I compile this contracts to approver and verification keys I deploy those two minutes right in the same script I also call the contract I create a proof which is a recursive snack a random web assembly on user uses order 16 cards of my machine and creates this recursive proof in a couple of seconds right in my browser then I I'm waiting for this transaction to finish I'm observing the chain and I I exhibit the final State that's updated on chain so I have this whole life cycle of a secret SMR contract just running in this in this one runtime environment
right for starting from justify defining the contract and there's no extra steps it doesn't you there's no you don't need to have a CLI that takes some code in a lot of language compile it to something then I don't know integrate some more than file in in your browser environment and I don't know in some Frameworks there would be a trust setup here in between somewhere so it's um have more seamless and this really fully integrated seamless uh kind of way of calling your defining and calling your smart contracts is only
possible in a JavaScript runtime it wouldn't work with any of the other approaches and I think that's really worth something so so that's why we're we're going this route um so to summarize that OMGs is The Logical outcome of really embracing of chain execution because when when you go uh when when you move to opt-in execution smart contracts become client-side applications So It's Perfectly Natural to to combine them with with your entire client-side
application it's it's natural to to have them in the same code base as your your UI to just have your contract be a function that you call from your react app or whatever so we're really leaning into this okay smart contracts I'm a client side and client-side developers will will write them and call them all right with this I want to move on to the to the next topic um I I have probably convinced you that that uh secret contracts are great but you might reasonably ask um do they cover everything like can we can
we actually build our smart contracts in o1js or are there limitations So my answer is can we build all of them with oranges short answer would be yes but um there are a couple of challenges um so we've we've been running this uh these test nets for two years and I've observed people dealing with with a couple of of challenges over over those years so three three categories I'm observing again and again um our these here so first of all you you now have to program
in a CK front end um the the next challenge that is it's very related to on-chain to off-chain computation is that you have a issue with concurrency so people who who thought about secret contracts are probably familiar with that because it comes up very immediately so the difference with with on-chain contracts is that you know the first you send you send the contract cards as transactions to the chain and then they are ordered and then they get executed in order so at each step you have a well-defined global states that a country can modify
and in our model it's the other way around we we first call the contract and then send them to the chain and then they are ordered so that means contracts execute concurrently and we really want to have shared State we cannot get around that um because that's what smart contracts are all about no so we we need to find a way to to solve this for CK contracts and yeah the third one is is specific to mina you know because we want to have this fixing blockchain um we we don't allow a large amount of on-chain State
so that it stays really easy to to run a node so that that clashes with apps that want to have large state so briefly summarized uh all of these are solvable so I think programming in a secret front end um from my experience it's it's for for new developers this is the easiest one so I know we talk a lot about how hard it is and so on but uh in my experience if you have a secret SL that's good enough like a1js people will figure out to how to write the logic you know CK front-end compliant way
um so the other two ones are harder because they're less local um and to solve the concurrency issue you have a specific uh protocol feature that I wanted to highlight and it's called actions so how do we how do how does this look like so actions they they are a way to model an append-only list that lives on each account and I I made a diagram here that shows how this on chain depend on the list can be used to to treat concurrent transactions okay
so on the right side you'll see a CCAP account which starts off with a state of zero and an empty array of actions and then imagine two transactions are coming in concurrently but they don't modify the state so they are not conflicting they just each have an action on them which says increment okay they both want to increment the state all right and then let's say this is one block and they get applied and we just append these actions to the to the actions field so we end up with two increment actions here at the end of the block and then next block comes in and here we
are have now another transaction which uh represents a second second phase and we we call this the reduce uh reduce transaction and what it does is it uh it exhibits the the actions on the account and it applies each of them so it increments to say twice to go from a state of zero to a state of two and then it's it commits the the outdated state to the chain so the the point here is that modifying State concurrently is just split into two phases and only in the second phase the the actual State update is committed to the chain and
note that both of these are just off-chain contract cars there's no extra on-chain finalization phase that we have to introduce like a lot of projects so we can just run this this reducing uh action off chain and it's just another contract car and it doesn't even use any any new protocol feature so the only photographer feature that we had to add was this actions field and it's actually it's implementation it's it's not really a a list that grows in uh indefinitely but uh it's actually just a Mercury list so we only store a commitment to that to the latest state of that list on chain
just this tiny one field element that's on each account it gives us this powerful new ways to to solve the concurrency problem all right um we have many we have many of those instances where we really try to to add protocol features to give you a the same the same possibilities in our contracts that um that you you would expect on in a classical smart contract framework and the whole collection of them is what we call the CK protocol so we you know we replace the on-chain code with with an online chain verification key we have we still have on chain state but it's not pretty smart we we have actions we have composability
so we can call one contract from another contract um we we have a way to do tokens we you can get network saved and so on and this uh protocol is already used to build real applications so there are a couple of projects building with OMGs right now um something to highlight for instance is Lumina the decentralized Private Exchange yeah and uh yeah that's uh that's the that's the end of my talk so I want to wrap up here um and to recap why why you should use
openjs we have this uh powerful new way of writing smart contracts which now run off chain and we are we are launching the I would uh um probably the first production ready uh CK smart contract framework and it gives you it really leans into option execution and it gives you the unique Simplicity and developer experience of just having your entire app in typescript and not only that but the also you also get to to build on Mina and really uh be be on this on the state of the art with
respect to decentralization um whereas not just a roadmap item but it's here right now all right uh thank you everyone do we have any questions [Applause] are you raising is I actually have a question about the yeah thank you for the talk about the Mina uh I I'm not really familiar so I'm really interested like how come it's only 22 kilobytes do you have to delete something if you can like really like in layman terms explain like what's the magic yeah yeah so um 22 kilobits is is this is the size of uh data that you need to to verify your like your balance
against the you so you need a proof and like a a market path to your balance to verify that actually that's that's the true state of the of the blockchain so it's what uh it's what a client with full load security needs it's not the whole ledger so the whole Ledger is also pretty smart because it doesn't sell any history um it's just Source the current account but it's not 22 kilowatts but okay but where do you store the whole Ledger on like some notes yeah the the whole Ledger is stored on like uh on notes that run on a server yeah and I assume that's growing right like the size of it because it's The Ledger right the The
Ledger is like Megabots thank you yeah Hey so uh you mentioned that the code is not my third but the verification I can imagine it's not constant in time so is there any security like safety um concerns with the regards to that like how do you verify the proof like is it considered safe like you do you measure it or you don't need to meter it you can just verify it without any any concerns um so there's a fixed size circuit on chain that the verifiers proves and so it has a it has a maximum size of circuits that you can you can verify and
change so there's currently it's it's two to the 16 constraints and the way we want to we want to treat that is deal with that is that if you need a larger computation there will be a way that you can you can it's a kind of folding we call it chunking that you can you can have a much larger circuit in fact but we will we will fold it together into a 2016 circuit yeah so um I have a question with respect to the actions and the the reduce operation specifically and I was wondering if I have a contract and I have a regular
stream of action so I get multiple actions every block how will I ever get a stable enough state that I can run or reduce because surely I need to know the the action list that I'm reducing at that point yeah great question um so the way we solve this is we have we actually have version We version the the state of action so you have five different versions on chain which represent the the state of actions uh right now during application and at the end of the last block and at the end of the second to last block so and you only have to prove that the action state that you're using is uh is one of those uh so you can you can essentially reduce
an old you version of the action exactly you would always wait one block it's always a one block delay and then you could could talk about that state of actions okay thank you all right I think that's all the questions we have time for sorry um but yes thank you again cheers