Kakarot zkEVM: Introducing the Modular zkEVM Written in Cairo

Transcript

hey [Applause] hey thanks thanks for being here I'm really happy to be here so let's talk about Kakao today um okay right so today we're going to talk about um the calculus Genesis after a quick intro on EVMS we're going to talk about on our approach and why it's it's unseen before and also the use cases and I guess we could go back to the basics for a bit and talk about the evm for a minute because it even helped me to go back to it every once in a while I'm sure everyone knows

it already but let's give it a a quick a quick intro so the evm is the Ethereal virtual machine it's essentially a distributed State machine where all the smart contracts on ethereum or ethereum like chains live so it's where all your balances live it's always where all your logic live it's where the protocol lives and essentially every execution client in the network has an evm instance and they use it to check that every transaction is valid so I have 10 each I don't with what if I had and I I send five to the protocol Guild then the evm is going to check my

signature is going to check that I have sufficient balance and it's gonna -5 my balance and plus five the protocol gills balance and in decentralized network you every single execution client is gonna is gonna run that transaction so it's some it's inefficient but it's the best way we found to eventually have a common truth that No One controls so why is that KVM right we started from the evm so it's the this distributed computer that you can deploy your logic onto so why I add that KVM ZK so quick reminder but zero knowledge is the is

the part of mathematical cryptography that aims at solving either or scalability and privacy and so far for for today we're going to talk mainly about scalability so essentially I run a transaction I send my money to the protocol Guild um I have to convince every node in the network that the transaction is valid so how do they do it well it's simple they just take the current state take my transaction and run it so thousands of nodes are execution executing the transaction essentially we would want for a better system to verify this and we found one and if you've been here today and yesterday

it's many people touched onto it but essentially we can now run once a computation and derive a proof from it and for the for the rest of the time people can just verify the proof so we're going from everyone has to run my transaction to I run my transaction once do a proof and then everyone verifies the proof and what's really cool about zero knowledge proofs and in this case validity proofs so they don't they're not privacy preserving in our case what's really nice is that they're exponentially cheaper and that's the whole gist around Roll-Ups right you have layer one ethereum maybe a transaction is a hundred dollars to give to the protocol

Guild and on the layer two maybe it's going to be five cent probably one cent in the future and maybe for fractal scaling um is going to be even less and we can come back to the history of kakarak and it started as a community project back in back in Lisbon but we can go even even back in the in the past and talk a bit about the Cairo VM and the CPU architecture of of starknet so char nice Char the co-inventor of Cairo found something very fun it's essentially Cairo and the Cairo VM it's

it's comparable to the evm but the KERO VM lets you write programs that are provable so maybe I should have explained but initially when you write solidity if you're a Dev or if you have just any app the output of this app are like transaction that you run are not provable by Design and that's why we built that kvms to add the proofability inside of it and Cairo is one of the ways you can prove computation and so he found that Cairo is a general purpose programming language that lets you write proofable programs so if you were to not write any program but actually write the VM you would get an evm that it's provable so you could verify any

transaction that goes through this evm and essentially that's exactly the definition of a ZK evm it's an evm environment or runtime where every transaction be can be verified and provable which is some side of the same coin right so he hinted at it a year ago he was like oh what if we build the evm in Cairo we should probably have a z key VM right and then Adele who is part of the lydicus lead the Innovation team at Stark work kind of started this effort bootstrapped it in a stock netcc Lisbon and that's where all the core team met so I met Danilo the co-founder and we lived all together in the soccer house and we coded and since then the family has been growing and the project has been really taking off and we right

now have more than 50 unique contributors all on our repos and the core team is about seven to ten people oh all right so what's been done so far um we have a hundred percent op code equivalence we have eight out of nine pre-compiled so this is somewhat comparable to a polygons that qvm has has already pointed out yesterday we should have a public test net by end of summer um maybe I should have done that soon trademark meme because now we're we're aligned but and we're exploring some cool use cases for zkvn one is rollup as a service so

essentially when you go up a layer the way I think about it in some sense you could think you delay finality and you get um cheaper fees and higher TPS for it so on ethereum mainnet finality is approximately 15 minutes with the checkpoints um with the checkpoints of ether 2.0 and on starknet it's right now four hours and you would probably go down as much as possible but if you go up a layer again so layer threes maybe some of you have heard of the op stack but here it's different but you could essentially do layer threes and the way you think about it is someone maybe Ubisoft I don't know wants

a platform to build video games and they would want very very cheap fees and maybe 5 000 or 50 000 TPS so they go up a layer and what happens is many transactions get executed at the layer three they get batched onto layer two and then these ones get batched onto layer one and so you see that there's kind of like this recursive exponentially cheaper compute so we could build that um Kakarot is essentially very modular this is just an evm written in Cairo so one person pointed out rightfully that if you write an evm in Cairo it's almost as if you wrote an evm in golang which is what Geth has done apart from the peer-to-peer modules and and the rest but

cakot is very modular in that no one in the team actually is a cryptographer and it can't sound bad but it's actually good because we don't need to be there is an abstraction layer that is the Cairo VM that allows us to represent every transaction as a system of polynomials and then generate proof from it and thankfully we delegate this knowledge to starkware but um our work is from the evm onward so it's solving the network effect for ethereum and what's really cool about this modular design is that down the line maybe in five years or or E five years ish depending on the ethereum roadmap um we could even improve L1 blocks I'm not going to get tricked this time I

pushed it once if I push it twice it's gonna do twice right okay I'm doing it right cool so we can touch a bit about how caca works because I think maybe it's important right now Kaka works as a evm runtime on top of starknet so it's literally a smart contract and it makes sense somehow because an evm is not a node or a client an evm is the runtime that is used by a network to run programs so get the the most popular client for ethereum is DVM but then also peer-to-peer module data storage and many other things and for us we just

built an evm so we deployed it on starknet to kind of piggyback on the approver system and the ecosystem of darknet and I'll touch on to that later but right now what happens is someone will sign a evm transaction with their metamask or UA so they'll send any transaction to a new VM Network so in our case kakara and we have an epic node that will kind of transform this or like wrap this transaction without altering it at all into the starknet format and I guess it's very important not to alter it but this is safeguarded by the signature mechanism so if you were to alter the call data or any part that touches on the core part of the transaction the

transaction will just not be valid so we just add a couple of things such as the start net corresponding address of the person and so on so their transaction reaches this dark net which is dark net and it reaches our smart contract that essentially will pull the evm byte code of their smart contract and execute it so why is why is this somewhat important it's it touches on the types of zqvm and essentially when you build a ZK system you have two ways roughly of allowing people to write solidity or any evm language and then outputting validity proofs you can have a system that is able to watch us watch transactions of evm

improve them or you write solidity transpile it to a zero knowledge provable language and then and then run your system so for example zkasync you may be familiar with it launch their zkvm what they do is you will write solidity they will transpile it to their own language and then run that so this is transpilation in our case it's it's not it's interpretation at the runtime so what can one do with Kakarot today you can deploy your solidity or evm language code base on stock net L2 without any change though this is not in production yet right but you can it works you can

interact with Kakarot using the usual evm toolbox I guess for context this is somewhat Innovative because stock Nets is not compatible with the evm or the evm toolbox so what you get on as a user and as a developer is the toolbox you're familiar with so that can help for many teams and then in the future we aim to interrupt with the really cool innovations that starknet has and that Eddie has touched on this morning such as storage proofs or even native account abstraction and then soon a real loud to dream we could one click deploy your zqvm at the lp level using Madara and Kakarot so I guess we could touch also on a Hot

Topic which is you should probably not build a zipkey VM first of all it's very hard at least if you're going the cryptography route which scroll and polygons at KVM have have undertaken and essentially you could say we don't need another zkvm the L2 space is quite congested and why add one more and then your your there's no business model or as someone said I don't think that KVM is a good idea and it might sound like a hater comment but it makes sense the evm is not was not built for ZK and as such it's not it's not very friendly to it the the example that people used to use usually take is for example the the

current hash function on ethereum which is sketchak it's very not Zedge friendly so if you were to build from scratch a zero knowledge environment and let's say a zero knowledge virtual machine so without the e a z key VM which is what stocknet has done you probably just get rid of all the Z key unfriendly things of the VM so you would get rid of ketchak and get Poseidon and and so on and so forth so why would you want to bring the evm back to ZK and kind of try to fit a rectangle into a triangle shaped floor I guess my answer to this is probably Network effects we see that many Innovations are kind of built on top of each other and sequential at least some part of it and

even today I think I don't have the name the numbers but her sticky I think when a new team is on boarded onto blockchain Technologies and devs are starting they most likely start by evm they start by solidity bootcamps they start by web dev and so on and so why build Kakarot and not just contribute to others at kvms I think we add something really cool and it's the first that KVM that does it it's a zqvm that separates zero knowledge and evm and to be fair this is good um zero knowledge is really really cool and devs rightfully should interact with it but to some extent you probably want to abstract zero knowledge away from devs that do pure engineering and

and then let them do their logic so what I mean by that is full stack is increasingly becoming harder so at first you had backhand front end now you have back-end front-end blockchain and now you should also be a cryptographer so it's back-end front-end cryptography blockchain and so you should read cryptography for the real world cryptography introduction to cryptography should be able to audit Secrets I think that's a lot and in our case we built I said KVM but used a z key VM as an intermediate presentation and that allows us to fully separate our evm to ZK one really cool thing is that our code base is very small and code that is not written will not bug

second part is any optimization that is done on the Cairo VM we benefit from it and then lastly and it's not to be it's not to be under underestimated and um you heard it during the protocol Guild talk it's essentially there are many new Innovations on the evm object format UF um same thing um 4844 so so many hard Forks in the evm are gonna so the evm is evolving with time and what's really nice for kakara is that the code base is very flexible it's very small and essentially we write the evm in a high level language so this allows us to really catch up really really

easily compared to say someone who would have to rewrite circuits for specific changes of the evm and then re-audit them and so on and then I think the most important thing and we we should touch on this is is it is it performantly it works okay it's very small it's very elegant but is it competitive and I think this is what will make the difference in three years and my my mental model about of this is there's many l2s there's many zero knowledge roll ups and there's lots of traction and so many cool positive externalities that creates kind of dust in the air and it's hard to say and then probably in two three years the dust

will settle down and we'll know like the three most performance proving systems and and zero knowledge roll ups and toolboxes and personally I think the KERO VM will be one of them because Star War has demonstrated for the last two years that in production it's very performant now people who are building ZK VMS are taking the problem by saying so is that key VMS that without the KERO VM they're saying okay we're building the azit KVM so let's take every op code that the virtual machine have has and build a like circuitry for it and then super super like over engineer but um in a good way over optimize this and this

publish would end up in a situation where Kakarot is under optimized right because people are optimizing for the evm and we're building on a general purpose is that kvn what's nice is that the benchmarks we have show that the Cairo VM is an order of magnitude more performant than other proving systems and then Kakarot is a overhead of it so it will definitely hinder this performance and my belief is that it will just kind of re-rebalance things where cacao should be on par with others definitely that's that's a belief and we'll need to come up with benchmarks and I I really appreciate the scroll team for for pushing uh Apples to Apples benchmarks

in the in the space because right now it's very hard to compare linear Z kissing scroll and all the zqvms because the benchmarks are not like super standard but I think they will be in probably six months or so I know people are working on it I forgot the names but thank you and there's so much to build um so much to build we have Regenesis coming up on starknet which means we have to rewrite our code base it sounds bad but it's not so bad we wrote it in six months and we didn't know much now we know more and it's good it's going to be it's going to be faster then I touched on it but benchmarking is very very important it's important as a as an ecosystem to know what is what and

right now we don't have it I think no one has it in in comparable ways and then we need to optimize for sure because I the way I think about it is we'll Benchmark we'll see that we lack some performance compared to others at kvms but it's very promising and then we'll go through our optimization cycle and then deploy to mainnet what that means is that will give choices to people coming to starknet and on layer twos to to decide they can come to stocknet and write the programs in Cairo if they don't want the overhead of the evm and if they want the layer of abstraction of the evm they come to us but it's in the end it's the same problem that we're solving with startware or Stark net on

any layer 2. it's how do we gain Mass adoption it's teams building cool apps and essentially you want these apps to be fast and you want them to be substance or like per transaction or even less so I think we're all on the same Mission which is adoption of crypto decentralized interactions and cool composability and all of this at the minimum price and that's the mission we're on thank you [Applause] [Music]