Theory to Code: Building the Breakthrough zkVM Jolt

Transcript

so I've been stunned myself at just how tightly the parallels seem to go between kind of the right way to design snarks and the right way to design like real Hardware this is particularly surprising because like people definitely didn't think this would be the case until recently and I'd say even now many people still don't think this is the case so what lasso and jolt strongly indicate to me anyway is that exactly the properties that make some instruction sets really nice for real Hardware also makes them really nice for [Music] snarks hello and welcome to web 3 with a16z a show about building the next era of the Internet by the team at a16z

crypto that includes me host Robert Hackett today's all new episode covers a very important and now fast developing area of technology that can help scale blockchains but that also has many uses Beyond blockchains as well that category of technology is verifiable Computing and specifically snarks so today we dig into zvm or zero knowledge virtual machines which use snarks and we discuss a new design for them that the guests on this episode helped develop work that resulted in jolt the most performant easy for developers to use zkm to

date the conversation that follows covers the hist history and evolution of the field the surprising similarities between snark design and computer chip architecture the tensions between general purpose versus application specific programming and the challenges of turning abstract research Theory into concrete engineering practice our guests include Justin faor research partner at a6z crypto and associate professor of computer science at Georgetown University who came up with the insights under pinning jolt along with collaborators from Microsoft research Carnegie melon and New York universities he's the first voice you'll hear after mine followed by Sam Ragsdale

investment engineer at a16z crypto and Michael zuu research engineer at a16z crypto both of whom brought jolt from concept to code as a reminder none of the following should be taken as tax business legal or investment advice see a6z crypto.com disclosures for more important information including a link to a list of our [Music] investments so the benefit of a blockchain is that everybody in the world has access to this computer and therefore has both the incentive and

potential ability to attack the computer and yet they can't so despite the blockchain being sort of an incredibly expensive incredibly weak computer it's still a useful computer uh it's a computer that accomplishes something like no other computer in the world you know before Bitcoin launched in 2009 or whatever year was could achieve and so anyone in the world has sort of maximal incentive to attack that computer and convince you know the computer that they have a billion dollars when they don't and the blockchain can withstand that so it's a very slow very expensive computer nonetheless useful because of this guarantee and you said a weak computer but you're referring specifically to processing power there because it's very strong in certain respects which is like

the ability to make commitments around who can tamper with it and the fact that it's going to run as intended I'd say it's very secure the computer kind of works in this the world's most adversarial possible setting but uh that comes out a cost and that cost is it's very difficult to get this computer to do a lot of processing as a result and so snarks in general and zkv Ms in particular have a lot of potential to let that computer do more work than it can do today without sacrificing the sort of security decentralization property and the reason being that you can have anyone in the world you know totally untrusted adversarial entities do a lot of the processing and merely prove to the world computer to the

blockchain that the processing was done correctly okay so even though you know no one in the world trusts this entity that's doing the processing well they don't have to so a snark is a cryptographic protocol that you know lets the untrusted entities come up with a very short proof that they did this work correctly the proof is very short and very fast to check it might be just a few hundred bytes and take just a couple milliseconds to check and that's what the S stands for in snark too it's succinct right yes succinct means exactly the proofs are short and fast to check and so the world computer the blockchain nodes out there only have to store those proofs and check the proofs they don't have to do all the work that the proof is proving was done correctly okay now what is a zvm it is a

particular kind of snark where the statement being proven in a ZK VM is in the form of a computer program expressed in the Assembly Language of a virtual machine C of v and that's just a simple computer and to unpack like the implication of that technical definition is it's a very usable snark because developer who wants to deploy a Zer knowledge proof doesn't have to know anything about how the snark itself works so they can just write the computer program the same way they would if there was no snark you know being done and the zvm just lets them uh you know generate proofs lets anyone in the world generate proofs that they ran that program correctly so the developer just

has to know how to program it doesn't have to know anything about the snark can I dumb it down a little bit please please make it as dumb as possible okay cool cool I'm good at that assume zero knowledge zero knowledge perfect so if I think the the way to think about it is decentralized systems in general are ones that push the authority systems to the edges and so blockchains are very good examples of these the way that you keep the entire world computer in check that everybody can trust is that all of the users all the nodes on the network check all of the work of all of their peers and so what this literally means like in the case of ethereum there's about 600,000 nodes the number jumps up and down on a daily basis but around 600,000 nodes they run this single-threaded process where they check

all of the work of their peers and make sure they're being honest and if they ever see that their peers are being not honest there's like a dispute resolution strategy such that everybody can continue participating in this computer and know that all of their peers are being honest as a sweeping statement of what that gets you that gets you in Chris Dixon's words computers that can make commitments right a computer that you can build on in the future and you know that it'll have the same properties tomorrow as it does today at least with you know fairly specific guarantees about economic and compute security but if you you know if you listen to what I said I said that 600,000 computers do the exact same work over and over again like from some non-technical but utilitarian perspective you should see that as inefficient and a problem and so like

can we do better and before snarks the answer was sort of no right like the only way that you could get a computer with this property is if everybody does this redundant work and that's sort of like your ticket to ride in the network your ticket to get these properties but what that means also is that the entire throughput of the network ethereum in this case or Lana or Bitcoin or whatever is limited in throughput the whole thing by the minimum computer that you want to support ethereum makes this limit rather low salana chooses to make the limit higher but still what they're doing is the same they're checking the same program over and over again and so like a fair question to ask might be do you have to pick one right do you have to pick either the decentralization of the network and allow a lot of people to

participate with a lot of different diverse Hardware or get good throughput and until now answer sort of been yes but starting in 2016 people have proposed snarks as a solution and the idea of a snark is that you can take the validation program itself and you can basically compress it you can make it much smaller by doing a lot of additional work applying a snark to it and then when you distribute the proofs thereafter the validators have to do a lot less work but the trust assumption hasn't been lost so the prover on their behalf can do the validation program which compresses it creates a proof and then the validators at the edges of the network can run the proof instead in a lot less work than actually running the validation program but there's been a

lot of issues with these and let me just clarify to you posed this tension this tension between decentralization and centralization for a given blockchain Network and also between how efficient it can be and maybe beforehand there was this idea that in order to achieve real efficiency you needed to be more centralized whereas decentralization was going to hurt you and you were going to pay a cost for that but now we have this new way where it seems like the technology is enabling us to have a middle path where you can actually have decentralization but it can also be quite efficient hopefully yeah that would be the dream but I think there was there's a bunch of issues with snarks when they first came out I mean they

were a new technology like any others Michael do you want to talk about maybe like the three main issues that snarks ran into starting in 2016 yeah I mean for like a third perspective I kind of think of snarks as existing on this Continuum on one end you have like Sigma protocols which are these like super restrictive but also very efficient snarks they can prove these very specific algebraic relations between numbers but you know to massage that into something practically useful is difficult and then on the complete other end of the spectrum is zkv Ms which are like fully flexible you get all the sort of devx benefits of having a full VM but the flip side of that is that they tend

to come with a bunch of performance overhead and a bunch of complexity which has historically been a sort of barrier to their adoption and when you say devx you're basically saying that developers like having this virtual machine environment because it it's very flexible it's generally programmable and they can kind of do with it what they would like there are fewer restrictions yeah exactly so you can just write programs in whatever highle language you'd like as long as it compiles to the particular VM B code supported by that ZK VM and I think like particularly the other programming style was this algebraic circuit thing which required not only different programming languages but also like a fully different programming model I tried to learn a few

of these as well and wrote some circuits in them and they're just highly unwieldy I kind of analogized zkm to what happened with JavaScript where JavaScript was like one of the worst web Technologies it's slow it's interpreted there's this whole mess that happens there but because so many people know how to use it and it's so easy to learn it means that people are much more productive in it right people are writing server backends in JavaScript or typescript today despite it being the least performant language to do that just because the devx is so much better and more people can contribute to a large codebase I think the same thing ends up happening if you say you either have to make snarks in algebraic circuits and they'll be fast or you have

to make snarks in a zkm but you can use roster python or whatever I think the benefit of jolt is the zkm isn't that much slower you probably pay some cost for doing that rather than hand wirring it but that is well overcome by the devx improvements and the productivity improvements of your engineers I would um add that in the snark setting developer experience is not just uh developer experience issue it is a security issue when you deploy a snark the prover proves it ran a computer program correctly on some data in blockchain settings often what that computer program is doing is it's like validating a bunch of digital signatures testing that the transactions were

actually authorized by the entities initiating the transaction that's what prevents people from being able to just take money out of your bank account on the blockchain is the fact that you know you have to sign the transaction you they can't just put it out into the world computer like oh send all this person's money to me if that person didn't authorize it right so you know snarks are cryptographic protocols and they're used to protect valuable assets so if the computer program the Prov proves it ran is not the computer program that the developer thinks it is then the prover is attesting to having done the wrong thing having not actually validated those digital signatures and

that is what can lead to billions of dollars of losses in fact even today these s are extensively securing billions of dollars of value they're very complicated especially if you're handwriting circuits these circuits like always have bugs in them and that means they're just insecure well yeah humans write bugs in JavaScript but it's a lot easier to write bugs into like arithmetic circuits that you know look like something like hand wirring a computer from the 60s I think with zkm you know not only is it just nicer for the developers but it pushes the surface area for bugs into a more constrained place right so just imagine we live in a world and I hope to live in this world a few years from now where you know the

jolt zkm has been formally verified for correctness whatever that means you know so we just know there are no bugs in the proof system itself okay that means that whenever somebody wants to use jolt apply it to a new computer program that's validating you know some new digital signatures or something that means all we now have to like the only surface area for new bugs is in the computer program the developer wrote right and if the developer wrote that computer program in a high level language like rust or something we should have a lot of formal verification tooling to bring the bear on making sure that that computer program matches a specification that the developer intended or whatever and so it's just much better if all you have to do is formally verify a Russ program right we

should we don't need new tooling for formal verification the code is easier for human to audit everything is just much better and the the big problem today standing in the way of this other than you know the three years of effort it would take to like get high assurance that our jolt implementation is actually bug free is performance okay so the zvm just the pro proving it correctly around the computer program is just vastly more expensive than just running the computer program with no proof so i' say the two issues today with zkv MS and why you know they haven't already taken over the world is pro are super slow and they're very complicated code bases and it's going to take years of work to make sure that they're bug free so speed and security how do we tackle both of those

problems well we tried to take major steps towards both with Jolt now they are still only partial steps but we think that jolt has introduced new techniques that not only speed up the prover but also substantially simplify the implementation Sam and Michael can say more but I think the entire jolt implementation is about 25,000 lines of rust code that includes the the pro imp ation I think the previous ZK VMS were more like 50,000 and up even even 100,000 and there's a lot more performance at least if not also Simplicity to squeeze out of this we're sort of just getting started on that front I think that starting with the security side the way that I would think

about a zkv m is it allows you to program in highle languages some zkm have like a custom subset of the languages others that Target risk 5 for example will allow you to program any High Lev language that can be compiled down to risk 5 risk 5 is an open source instruction set used for running computer programs on chips it's a alternative to x86 or arm or or any of the like x86 being what Intel pioneered and is kind of what runs PCS and data servers yes exactly and specifically risk 5 can be targeted by llvm which is the backend for most of the highle languages we know and love today which means that most highle languages can eventually Target risk 5 just as they

can Target x86 or arm Etc risk 5 has generally been chosen because it is a relatively small instruction set so the variant that we currently support is RV 32i that's about 50 instructions the equivalent in arm is something like 550 instructions and that just means there's some fixed engineering cost that has to be done by the ZK VM developer her instruction and so the smaller the instruction set the the shorter the build time so what the reason for going with risk 5 is this a bet that risk 5 is going to be like the predominant chip architecture moving forward definitely not it's simply that the risk five instruction set is very small there's a fixed cost that you have to do in

engineering time per instruction and as a result the smaller the instruction set the shorter time to Market and the less surface area for bugs honestly as well yeah RV 32i is like the smallest instruction set that you can compile highle languages to we briefly looked at like WM and mips which are also you know candidates and some ZK VM teams are are targeting those but even those are are more complex than the RV 32i instructions set and then the other consideration is that you have the highlevel language support as Sam was saying so you know languages like go and rust are able to be compiled down to risk five instructions which is ultimately like achieving the the devx

that we we want to keep going with the the security point though so zkm allow you to write snarks of programs written in normal highle languages it's easier for a developer to write a correct program because they're not writing in some strange programming model but that algebraic model still lives inside of the approver and the verifier of the ZK VM right so still in order for most zkm to function the zkm developer has done sort of the gross work of making a snark and there's still a chance an equally High chance that that gets screwed up and so the simp the internals of the ZK VMR the more likely you are to be able to trust it and the higher security it has and so most of the other ZK VM work

that is done is based on Starks they end up looking quite similar under the hood whereas jolt uses lasso which was launched with the jolt paper in August 2023 and it uses lookups for pretty much everything which we won't get too into the Weeds on that but it basically means that the programming model for the underlying VM sort of the one that gets exposed to developers is much simpler and so rather than again programming in these weird constraint systems and algebraic circuits and all of that stuff you end up writing about 50 lines of rust code per VM instruction so in this case per risk five instruction RV 32i instruction and our thought our thinking is that that Simplicity beyond the

Simplicity of the high level language rust or go or whatever that can be compiled to RV 32i the Simplicity of the underlying snark also allows you to trust this thing substantially more yeah and maybe just as an anecdote a couple weeks ago we realized that we wanted to do lasso lookups for the risk five store and load instructions that required implementing those lookups so and it ends up being like five lookups that we had to implement and I was able to like crank those out in like one or two hours and be pretty confident that it was working correctly we have these rust macros that basically lets us do sort of like a light fuzz test comparing the implementation of the lookup table

against effectively like a native rust implementation of of that instruction so there's no new abstract programming model such as algebraic circuits or errors or any of this stuff it's pretty simple fairly hard to screw up rust code tried and true I want to talk about jolt from the Inception of the idea all the way through to the execution maybe we can talk about the intellectual underpinnings here where the ideas that would manifest themselves as jolt actually first came from I can give a brief overview on on this so my entire research career in snark design dating back to 2009 basically has been focused

on a certain technique called the sum Che protocol which is due to L for now caller off in Nissan some of the very very early work on verifiable Computing from the late 1980s early 1990s so some of the earliest most important theoretical results uh on this technology led to the subject protocol right right out of the gun right so a lot of my work has been recognizing the power of this protocol and implementing it and making it practical and ever since then I've kind of been trying to get people to appreciate its power and use it right and it's been a bit of an uphill battle Justin what did you see in the SU protoc that other people overlooked or failed to

appreciate my perspective is that a key determinant of Prov cost in snarks is the amount of cryptography the prover has to do okay so in these snarks the prover commits to a lot of data what that means is the prer would like to send a very big proof to the verifier but that would violate s sickness and make verification very expensive so that's not okay so instead of uses cryptography to not send all that data to the verifier but make it as if it did okay that's what commitments are all about and that's that's where you get the sickness from okay cryptography is expensive it is slow to commit to all that data on top of that the more data the Prov commits to the Prov later has to you know prove to the verifier that

all the data it committed to was well formed you know that it actually committed to the data it was meant to commit to so that that's my perspective cryptography is expensive you want to minimize how much cryptography you have to use in the snark so you're actually able to achieve these speed ups and this this concision because you're removing cryptography from the equation there's this give and take between the provs and the verifiers and how much computation each has to do and cryptography is this funny little subset of computer science where you want everything to run really slowly but you're like okay let's strip that out and actually not not rely on those you want any successful attack to be very slow but the honest prover you want to be fast despite that it's still

the honest prover know the more cryptography it uses the the slower the honest prover is and so the sub protocol I view it as a way to force the prover to do work so the verifier doesn't have to do the work but without using cryptography so it's cheap it's FAS for the pr okay you cannot get a snark without some cryptography so I view the sun protocol as a way to minimize the amount of cryptography you have to use to get a snark but the the reason I was captured by it was just it was I mean it it's simple it's beautiful it's powerful it just blew me away I first learned about it in a course as an undergrad and I'm so fortunate there was a complexity Theory Book by uh Sanji veror and borz Barack that was just coming out then now

it's like the standard for the field and they put this you know pretty Advanced concept like into the book and is just you know beautiful um that's great we'll put a link to that book in the show notes sounds good anyone who wants 400 pages of complexity Theory but uh definitely recommend it so when I got to grad school I started trying to implement the protocol and make it useful and fast in a particular context it wasn't until much later that we fully understood that you know you could kind of get a snark by taking this Su Che protocol which has no cryptography and combining it with commitment schemes which are cryptographic and put them together and you get a snark and as a result I think I sort of had a different perspective on the techniques in the area as it developed and you know I've

read like every snark paper that's like ever been written with the subject protocol in my head and very very frequently it's the case that you know like the paper can be reduced to a few sentences of the form like invoke the Su Che protocol if the authors had the subject protocol in their head gives you a very keen appreciation for the power of this protocol that you can maybe only get by always trying to apply it's the one hammer you reach for every single time and seeing Oh everything's a nail for this thing and people who were designing snarks just were not aware of it they had not studied complexity Theory to the degree that you had so many of them had not all of them I think as Snorks were becoming practical people

came at it from several different angles but certainly I was more aware of it and its power than most okay and I think this is largely because the way the literature developed it took a funny path so first people introduced the notion of interactive proofs in which uh there's no cryptography allowed the security notion required is this information theoretic security where it doesn't matter if the pro has trillions and trillions and trillions and trillions of years to try to trick the verifier it still can't succeed and this is sort of mimicking like two mathematicians who you know one is trying to convince the other that theorem is true but doesn't want to write down the theorem line by line so instead the skeptical mathematician is asking questions and getting responses and asking more questions getting more

responses that's an interactive grp no cryptography that's where the Su Che protocol was developed in like you know kind of that initial setting that we were looking at and then after that people considered a variant sounds kind of funny but where there's more than one prover so here the typical analogy is you take two suspects in a crime and you don't want to interrogate them together because then they could try to like coordinate their story on the fly or something you know as they both hear the question they can figure out how to respond to it together you know some coordinated lie so you put them in two different rooms and interrogate them separately and when you do that the proof system becomes more powerful it turns out because the two suspects can't coordinate with each other as they learn what the interrogation action is anybody

who's familiar with a police procedural drama is going to that Mak sense too yeah it's funny the analogy I think is not quite perfect but it it gets the gist across anyway and then the final sort of thing considered is what people call probabilistically checkable proofs so here you go back to the notion of a proof that's written down there's no interaction there's no back and forth between the verifier and the prover the verifier it's just going to ignore almost the entire proof it's only going to read like three symbols of the proof so the proof might fill up a whole book but the verifier is just going to turn to three random Pages read like one letter on each page and decide if the proof is valid or invalid from those three letters and so you know it's insane that you can actually prove

complicated statements with such a restricted verifier but you can and these probabilistically checkable proofs turned out to be like really fascinating they actually led to an entire area of theoretical computer science called hardness of approximation which has nothing to do with snarks and verifiable computing and all of that and theorist just went crazy for them as they should have and it turned out that the first snarks that people developed were kind of a variant of pcps that made them much simpler in a sense and the Simplicity came out a price we don't have to get into that and to remove those downsides that came from the pcps people have been gradually working their way back towards the interactive proofs and so in my view like the the working their way back has

been sort of partial and to make it complete you actually want interaction both in the interactive proof the non-cryptographic part of the protocol and in the cryptographic part of the protocol the commitment scheme so I think it's already become pretty popular and and well accepted that it's useful to have interaction in the commitment scheme but the subject protocol is the final step to get the interaction also the actually quite a bit of interaction into the non-cryptographic part so that that's the subject protocol it makes me wonder like how many other advances are just lying out there to be had you know just from like the original literature but people have delved into such other Niche areas sprouting from it yeah it does make you wonder and of course you

know the intellectual lineage here is all entangled right because you know there was a path in One Direction and a path and another and people pick ideas up from one line of work and apply it to another so it is all untangled but you know it kind of reminds me the development of the field of AI where you've got like a seminal paper in the 1940s that kind of lays the foundation of neural network works but it isn't realized until you know very recently yeah and I think that's accurate and this this is quite common in you know all sorts of scientific and intellectual disciplines where things come back around some idea kind of goes out of favor for like 30 years and people think it's just not the right hammer and then someone has a new insight that addresses the issues and boom this method strikes

back and is is at the Forefront again so this was like a funny a little bit of funny thing where I implemented the Su Che protocol back in probably 2010 maybe even early or 2009 we used that code Michael and I when we were learning Su and learning lasso back in the day we used Justin's 2010 C++ single file code as our starting point for for writing lasso oh I didn't realize that was from 2010 I thought you would like reimplement or rewrote it recently no I haven't even looked at that code since I graduated I think I was amazed you were able to find the files actually yeah yeah they' probably be best lost to history at this point um sounds like were valuable though they were valuable

it was also just like you get an insight into like you know how the stuff was come up with and how Justin thinks and all that but it was entertaining that we it came from a single C++ file like the field was in there the sum check was in there like there was an implementation of the vectors in there all that stuff in 2012 we put this on Cuda and the single uh yeah I guess this would have been pretty early Cuda days and I think I had implemented a beautiful protocol called the gkr protocol after its author is gold waser K Roth Blum and it was you know I had one C file that was like 2,000 lines implementing the protocol and then to get it to run on Nvidia it like grew to like 6,000 lines all in one

cc file or something so you guys are lucky you didn't look at that that that's for sure so uh you know so I've been advocating for the power of this protocol and trying to explain this perspective that it's really a hammer to minimize the use of cryptography and cryptography is expensive and it's just been hard to get people to see this I guess I don't quite know it didn't catch on and over the last I don't know 18 months or something it really has caught on and that's been both gratifying and and exciting people are seeing this now so that's great and and so sorry yeah 20 minutes ago you asked me a question to come back to that the lineage of jolt all right there's an important primitive that jolt Builds on which is called a lookup argument in particular the lookup argument lasso which we introduced last

year lasso came about because people who not using the sun protocol had recognized the importance of what are called these lookup arguments and developed you know very very sophisticated and and clever lookup arguments not using the sun protocol we've been talking about this about lookup arguments I just want to ask like if I were to distill this down to its most basic essence you know something that like somebody in elementary school could understand is this effectively like time stables for snarks like I'm going to memorize you know like five time six and five time 8 or whatever so I don't have to keep Computing it every time I can just instantly serve up the answer that's a pretty good analogy yeah maybe logarithm

tables are another analogy but I figur that go even simpler I think that's perfect actually that's okay cool you write it all out once and then you just look at it later one of the additional cool properties of it is that when you look at it you can check that it's right like a human can check that it's right very easily but the um one place where the analogy sort of fails and this is like really important in in lasso and and jolt is that in many settings in the lookup arguments no one ever has to ever write down the whole table so you sort of only pay a price in terms of performance for the lookups that actually happen for the stuff that's actually looked up so it's like if you have two numbers that you could have

wanted to multiply together but just never multiplied them together you just wouldn't pay anything for that so it's not that you're showing the solu Sol it's just that you're proving that you applied this methodology to put these two numbers together and spit out some answer so I'm going to try to give a very actually precise technical answer that I hope is also a little bit intuitive actually I'm planning a blog post on this this is a perspective that I think will be novel even to very technical people who study you know these snarks too great um so a typical snark that doesn't use a lookup argument if the pro wants to prove it evaluated this function and you know in our example here this function just takes is input two numbers and multiplies them but you know in general might be slightly more complicated than that if

the pro wants to prove that it computed this function correctly most snarks will make the prover actually prove it like ran an algorithm to compute that function step by step so it's like the pro will prove to multiply these two numbers it actually ran this procedure to put them together and get the product yeah it added eight plus 8 plus 8 plus eight or whatever to like five time eight yeah or it went through digit by digit and did the the grade school like multiply these two digits together compute the carry digit so it's forcing the prover to run a particular algorithm to get the right answer so it's like you're tying the Pro's hands very tightly you're making it run this very particular procedure to get the right

answer and it's secure you know it's a very it has to run that procedure to generate a correct proof but that comes out a cost it's like now the honest Prov kind of its hands are also TI kind of tight so it's not free to move as much as it would like you know so it's just slower right with a lookup argument and this this only turns out to work well if you evaluate the function many many like a billion times or something or a million times or something the prover is free to compute the answer anyway at once okay so you're not tying the Pro's hands as tightly you know all the verify cares about is that it gets the right answer it doesn't care how the prover got the right answer and as a result the honest prover can be more efficient because its hands are free it can move

in a less restricted way to get to a convincing proof and so that's the benefit of of lookup arguments over the traditional way people design snarks before they were using lookup arguments and then the connection of lookup arguments to a zkv like lasso is the following what does a VM do a virtual machine a CPU you know these are all kind of words for the same thing it repeatedly executes the fetch decode execute logic of the simple CPU so this is just how people design CPUs in computer chips the computer program sort of runs for many many steps but each step is very simple and so jolt very closely mimics that three-step procedure but the main point is that a CPU is just

doing the same simple thing over and over again fetch de code execute fetch de code execute fetch de code execute trillions and trillions and trillions of times lookup arguments are very efficient snarks when you do the same simple thing over and over and over again so it's a match made in heaven so of course you know your zkm should be done with lookups and so that sort of the ethos of jolts it's sort of why I have quite High conviction that it's if not the right way to design zkm at least one of the right ways but I think it's a very natural approach to the space I think it's an improvement over current approaches and we'll we'll see how it evolves how big of a coincidence is it that this lookup approach happens to exactly match the typical functioning of a computer and CPU so I've been stunned

myself at just how tightly the parallels seem to go between kind of the right way to design snarks and the right way to design like real Hardware this is particularly surprising because like people definitely didn't think this would be the case until recently and I'd say even now many people still don't think this is the case so you know snarks have performance limitations the proof are still very slow and six months ago a year ago two years ago the pro was even slower right people thought that they had to design new VMS new instruction sets tailored to the limitations of the snarks kind of trying to strike a delicate balance between the Primitive instructions being sophisticated enough that they can get a lot of work done so you don't need a

billion instructions just to like add two numbers together or something like that but somehow simple enough or tailored enough to the snarks that the snarks could prove each instruction quickly right so there's this attempting a delicate balance and designing these new VMS that were designed with snarks in mind and you know no computer architecture person would ever design themselves what lasso and jolt strongly indicate to me anyway is that exactly the properties that make some instruction sets really nice for real Hardware also makes them really nice for snarks and that seems like feels like a bit of a cosmic coincidence but as a result it seems that the parallels between what's good for real hardware and how we should design snarks go quite

deep I think you can understand a lot of the snark design space if you already understand basics of how we design today's Computing infrastructure without any snarks around I think with the one giant caveat that currently we're over a 256bit field which is not very computer friendly say so like for example like a lot of the current performance strategies rely on gpus they rely on the work done by like the gaming world and now the AI world that is driving people to make faster and bigger and cheaper gpus at scale those things largely Target 16 or 32-bit floats either way very small data sizes a lot of the other snark approaches can sort of piggyback

on that effort and the you know the billions or trillions of dollars put towards making those things fast whereas our field size is still massive at this point it's a 256-bit field it would be really nice if we could go back to 2003 and convince the gaming people that they needed 256bit shaders so that we could also have the acceleration today but I guess there's a path as well to getting rid of that constraint that is not Hardware friendly so I I can give a little more context for what Sam just said yeah and I'd love to know what has to be done to make this compatible with gpus given how much energy and enthusiasm is going toward that right now yeah great question so I'll give some context and I I'll try to answer that question and then Michael and Sam

should add on top of that so Sam just talked about 256bit numbers and a field so what is that so like all snarks work over something called a field it's not really important exactly what that is but it's basically the numbers that arise in the proof system right so the the proof is literally just like a bunch of numbers and the size of the field tells you how big those numbers can get okay and Sam is saying that the way drol is implemented now the numbers can get as big as two to the 256 so it takes 256 zeros and ones just to write the numbers down the reason the numbers can get that big is because right now we're using a certain kind of cryptography in Joel It's the commitment scheme the only

place cryptography comes into snarks is the commitment scheme essentially we're using something called elliptic curve cryptography there elliptic curvs work over these big fields and so that is not the nicest for current Hardware although that's an particularly like at a 256-bit field if you compile that to x86 or arm where most of these things will be run not the zkm context but like the actual machine where the prover will run will probably be x86 or arm if you compile the 256 bit field multiplication or addition which is like the core operation that gets done billions or trillions of times inside of the snark that ends up being between 80 and 100 native CPU instructions that's how many

cycles it takes to execute a single one of those really core instructions to jolt whereas some of the smaller fields 32bit or 64-bit can be between one and five native instructions which means one and five clock cycles of that CPU and so that's the hardest thing the hardest wall that jolt runs into of course jolts algorithm is is very different than these other things and as a result the number of total field multiplications or additions field operations you do is smaller and so we catch up despite the fact that there's a 40x overhead is for our field but it is the least Hardware friendly thing that we have going on in jolt and so yes so to say just a little bit more about that there has been a

narrative in like the snark design and engineering community that using elliptic curve based commitments is slow in large part this sounds very plausible because the numbers arising are so big multiplying two of those numbers as Sam just said is like 80 times more expensive than multiplying two numbers like on your computer you know that fit in one 64-bit data type so the numbers get really big it's really slow to multiply them you should avoid that right that's been the The Narrative roughly one thing this turns out to miss or I think a few things that misses is that with snar based on the Su Che protocol fewer of these numbers arise so the pro just does fewer multiplications and so even though each multiplication is very expensive the pro is doing few of them and you can come out of ahead

and there are other reasons that also offset the cost of these multiplications being so expensive that in the end you know jolt with elliptic curve based commitment schemes turns out to be faster modestly so than the current fastest dkv mday that I'll avoid Cur but to be very clear the ideal case would be that we get both right we get the sum Che protocol which means the number of field operations we do is less to be able to prove the same statement and we don't pay a 40 to 80 times overhead for each of those field operations and so that's that's the ideal future that we that we want does does this require extracting elliptic curve cryptography from the methodology here it's sort of a dropin replacement you can use like any commitment scheme and so today jolt is

using elliptic curve based commitment schemes and you can just kind of hot swap out one commitment scheme for another so the other commitment schemes that especially the zkm projects have been deploying today the only cryptographic primitive they use is something called hashing what happens those commitment schemes is the prer like add and multiply a lot of numbers but then after it's done adding and multiplying a lot of numbers it does something called hashing them which kind of scrambles all the numbers up in a way that this is like cryptographic compression and so this is one of the algorithmic techniques that you're thinking about employing yes so we know how to design these commitment schemes either from elliptic curves or from hashing right now we're just using the elliptic curves ones we can use the hashing ones when we go to use the hashing ones there are Downstream

complications or just side effects of it the the benefit of using the hashing ones is largely what Sam said before about being able to work over these small fields to keep the numbers nice and small essentially and so to fully exploit that uh in the jolt context because jolt is a very different approach than existing ckvm requires effort and things but my expectation is that after we go through all that work on CPUs on arm machines and laptops Intel machines jolt will be about 10x faster I hope than it is today after we go through that change that's a huge leap in performance it is I mean my view is you know I think the drill prover is about 500,000 times sort of slower today than just running the computer program

that is about six orders of magnitude so 10 is like one order of magnitude so we turn that six into a five I mean that's a big deal even then it'll still be a lot I do want to just clarify one thing I think they're switching over to these hashing based techniques in the way that we plan to won't necessarily be friendly to gpus so it's possible that if you really want to use gpus you actually should stick with Jolt and the elliptic curve based schemes and there are some other benefits of using elliptic curves that don't necessarily come out in the numbers we can profile today but they will come out as we build J out more and and so forth so you know I don't think that switching over to hashing is like

it you switch in there you throw the curves away and you never use them I think these things will coexist and it's very possible that you know if you want to use gpus in the future you stick with the curves and you pay for these 256bit numbers that arise but it's still pretty fast because you're taking pretty good advantage of the gpus again the 256 bit numbers are like never nice but they're also not the end of the world and then you also reap the benefits I'm being you know completely vague about you pay that price you get some benefits you know you don't get no benefits for the price I want to double back on one of the things Justin dropped there that the jolt prover is roughly theover overhead the amount of extra time that you need to do to compute the proof

versus Computing the native program is about 500,000 times and that's today at some point in the future maybe that goes down to 50,000 times with some of these algorithmic improvements if you Circle back to what I said at the beginning where one of the like comically poor utility things we do in blockchain networks or ethereum is that we have 600,000 different validators that run the same program they run the exact same compute back to back if theover overhead is is significant there's other cool properties you get but like if theover overhead is higher right let's just say it was like 10 to the 8 or 10 to the 7 as it used to be you know 10 million to to 100 million then it doesn't make so much sense to do this pre-compression

step like just not from like a technical perspective but purely like a utilitarian or something perspective to have aover that runs you know 10 million times more work and then distribute that to $600,000 nodes you sort of might as well have just had all the different nodes do the original work right they sort of might as well have just gotten the original program and each of them run it and if you sum the work that was done across all 600,000 nodes it's still less than one machine doing 10 million times overhead and so in a certain sense slow provs there's not that many uses for them but as you bring the prover overhead down snarks become more and more applicable over time so this is why we're so focused on this is the number of use cases where people are willing to

to spend the 10 million times overhead which translates to literal dollars on some Cloud spend or like your machine could be doing other things it could be mining bitcoins or something like that as you bring that Pro overhead down the number of applicable applications for snarks grows dramatically we don't know exactly what it grows to what the new applications will be but we're excited about bringing that number down so to your point how confident are we that we can get these performance improvements that are going to make this a worthwhile Endeavor you know I'm thinking back to when I was a kid and thinking about like getting a terabyte of data storage and that being like some fantastically big number and just super expensive and now you can get that on a thumb drive like is that the kind of pattern matching

that we're looking at here are we expecting improvements of that sort or is it going to be a real slog that we're gon have to fight for every like 10x Improvement so I think I think definitely well whether or not it'll be a slog I guess is subjective and depends on who's doing it if it's the engineer or at the academic level but I think so Starks started getting invested heavily in in 2018 from an R&D perspective and like we've seen like a steady March of improvements there I think that you can expect the same thing out of the new strategy or the some Che strategy this multivariant land where people will hopefully continue improving them this is one of the goals of us releasing it is we wanted more people to see that

this stuff can be state-of-the-art and please come help us make it more state-of-the-art right do all of the incremental improvements from here because there's certainly things we haven't seen like the majority of like the backend work was done by Michael myself and arisu who's on the the jolt paper and so three of us have spent the time like staring deeply at this thing over you know seven months or so whereas the Starks have probably hundreds of Engineers working on them and that's great right like we want more people looking at this stuff and we think that showing that a new approach could work and that so few people have looked at it means that there's probably a lot of lwh hanging fruit and it's it's easier to find a fruit to squeeze if you will and we can sort of get those steady improvements and then I think further

there's there's obvious stuff like just Hardware improvements so that'll only happen if there's clear demand for it but so far there's clear demand for snarks people spend about I don't know 10 billion do a year settling on ethereum and so there's $10 billion a year of block space if you can make that cheaper and more reliable and more decentralized and all this stuff then people will probably make hardware for it as well so so we expect a market will form there in some capacity as well I can elaborate on a couple points there one is further improvements in snark design are going to come from three things better protocols just like better algorithms you know faster protocols where things are just faster than proofer does less work then better engineering and finally like specialized

Hardware so better engineering might be for a CPU which is not at all specialized to running a snark prover but you might take the final step of developing an Asic which cost tens of millions of dollars or something and takes years to build out to take that final step of having Hardware like all it does is snark proving completely specialized on snark proving so these things will all sort of come together and build on each other and of course my work has maybe until jolt where I didn't write a single line of code but I sat there and uh commiserated with Michael and Sam and arisu as they suffered through it you know has been on the the first thing like protocol design so I think we're going to get more improvements there I think we've seen major improvements just in the last year I mean you have lasso you have jolt that

partially inspired the folks from vatana Ben diamond and Jim Posen who introduced the new hashing based commitment scheme we plan to use called Bas I think that's a very exciting development yeah I think we're we're seeing these sort of algorithmic protocol level developments happen at a very exciting rate I was actually not so optimistic that this would happen you know if you asked me two years ago I'd be like people have to use the Su check protocol that'll get us like a speed up but that's that's about it it's going to be incremental beyond that and we're you know we're seeing what I think is non-incremental and then eventually we will have the as6 right and my view there is it's so expensive and takes so much effort to build those

as6 that you don't want to go through that effort before the protocols have sort of converged a little bit this is one reason why I've sort of been anxious to make my views on snark performance known if I'm right we should switch to a larg extent how we design these snarks and if I'm really right we can then converge we'll see I mean that's very optimistic that people generally like agree that this is one of the best ways to to do things I'm probably going to regret these words and you know't doesn't work out but if you do converge enough well now it makes sense to invest in the Asic and then you get potentially an extra final like two orders of magnitude off the the pro time at the very end there so you know you can hope for one to two more orders of magnitude

here from the protocol level and another 5x from the engineering level and then 100x from the as6 and figure out how many orders of magnitude that took off from where we are today and you get to the ultimate slowdown for the prover compared to just native execution with no proof this kind of reminds me this might be uh an analogy that's really far a field but since three body problem is on TV now just thinking back to the books there's like this one character who he wants to influence the path of how like spaceships and propulsion systems are going to unfold and so he sort of takes matters into his own hand to make sure it develops in the way that he thinks is the right way no spoilers people die but uh yeah

anyway no some check related deaths so far that we know of no people were harmed in the making of this some check based approach yeah I have many more gray hairs than I did when we started this but other than that I don't see him you look you look uh spry as a spring chicken the zoom filter the zoom filter and I'm dying it now nice Michael speaking of Genius engineering before I want to make sure we hear from you is there anything that you know we've touched on here you want to elaborate on yeah so we talked about how lasso and jolt come from this sort of different theoretical lineage than a lot of popular systems today which are you know primarily based on Fry and Starks there

are a bunch of like theoretical reasons that we were expecting jolt to be so performant but when it came time to actually like engineer and Implement jolt we realized that the existing tooling the existing infrastructure wasn't ready to leverage those theoretical reasons like there were like engineering things that we had to do to make sure we were actually reaping the benefits of those theoretical improvements um Right theory is one thing but actually putting it into application and practice is a whole other animal yeah exactly so one of the reasons why jolt is so performant is that the prover only has to commit to these small numbers well maybe I should just clarify sorry Michael A major benefit of of lasso and jolt is the

prover only commits to small numbers even though those numbers live in like a 256bit field right so like Pro commits to small numbers but elsewhere in the protocol outside of the commitment we do have these very very big 256bit numbers AR Rising so just very in the weed's clarification but I just didn't want confusion right so you know in theory since the Prov is working with these relatively small numbers we're talking like 32 bits or less it should be much more efficient than if they were working with these 256bit numbers and the efficiency gains should come from a bunch of different places so for example when you're converting the number to a field element in our case we're using the BN 254 elliptic curve like this is really in the leads but you have to you

know do this thing called converting it to the Montgomery form and doing that with a small number turns out to be uh I think like a quarter or 30% faster than if you had to do it with a full 256bit number but this is not something that arcworks which is the cryptography library that we use was taking advantage of because like prior to lass and jolt you didn't really have these systems which had this property of of primarily working with these small numbers so there was really no reason to implement these what was then kind of esoteric efficiency optimization so we had to basically roll all these things ourselves and I mean I think we saw this across the board where you know

when we we planned this out after lasso you know lasso like we built um as a fork of Spartan one which was by seretti one of the authors on both the lasso and jolt papers and that required some some changes here and there when we planned to jolt we sort of decided we would take you know all of these off the shelf pieces we'd grabb them we'd glue them together and I think when we we started jolt we actually described I think in October or November all we have left to do is the glue which is just you know slap all the off-the-shelf pieces together and call it a day it's going to be fast we found that when we glued our makeshift thing together it happened to be much slower than we were expecting and that's just because those dependencies were not expecting sort of

like our call pattern and our strategy it wasn't because any of those dependencies had any problems so things like like circom Great Library a lot of people use it it just happens that the way that we were using it where we were calling the same circuit over and over again was very slow same thing for Spartan Spartan is probably the fastest way to prove R1 CS at this point this is Sereno said's Library but again when you do our call pattern where we run for every cycle we run the same R1 CS circuit it's much slower than it needs to be because you're doing some work that should be amortized across the entire program over and over again so we had this pattern over and over again after we did the glue phase where we decided we basically had to vertically integrate everything because our call

pattern is so strange so where a lot of the other lineages you know maybe this the Starks and other stuff A lot of people are working on the same thing people run into the same headaches and the tools have these fixes already built into them we ended up having to do a lot of this ourselves and we're excited for a lot of people to come and and check out what we did and help us make it even faster because we certainly missed a bunch of obvious stuff so when you were first setting out you were like okay here are all these off-the-shelf tools that we can use and as you were working on it it was like oh actually we're going to have to change this we're going to have to build this from scratch we're gonna have to make customizations here I think what we realized is like being

able to use these off-the-shelf libraries and tools is kind of intention with performance optimization where when you're trying to really heavily optimize something you want to take advantage you want to leverage the sort of structure that's unique to the problem that you're trying to solve and this is kind of like a recurring theme that we encountered while working on jol is like where can we find structure that we're not currently taking advantage of like where are we being General where we could be more specific so this is intentioned with like using libraries which are intentionally like general purpose but again like we ran into this situation where we realized we'd get a lot more performance by sort of vertically

integrating introducing some optimizations that would only really be applicable in the context of jolt there's kind of a fun analog here too to lasso and jolt itself like lasso takes advantage of the repeated structure in a CPU program right there's 50 instructions and you do one of the 50 each step for a billion or whatever however long your program number of steps and the proof system takes advantage of that right it looks at that structure and says like you know how can we simplify the whole proof system so that the prover is faster and we get all these other cool properties and we ended up doing the same thing when optimizing the prover program where we looked at like the repeated structure of what was actually happening on our silic and we

went okay how can we speed that up like how can we make it more obvious to the computer like what it should be doing and you know what stuff is wasted based on the structure like how can you expect certain inputs how can you make your program faster based on knowledge of what the shape of the inputs looks like I mean really that's the only trick that we have right when optimizing software is trying to exploit structure so I mean I sort of come from a a background of gas optimizations or gas golfing in solidity and you know I was kind of surprised but also happy to find out that like a lot of the sort of fundamental skills even though it's like a completely different language completely different programming Paradigm are still relevant and useful

for optimizing rust in the context of snarks yeah I so I thought I knew rust before I started this project I did not know Russ before I started this project I think Michael particularly like learned a lot of his rust knowledge throughout this project and I think we learned an enormous amount together where we really got into the weeds very efficiently of like how to measure the performance how to figure out what is slow why it's slow what system limits are we actually running into how can we get rid of those how can we shape this thing so that it still has general purpose functionality but has the performance characteristics we want out of this repeated structure I want ask also how unique is this partnership between the research side Justin and the

engineering side Sam and Michael Justin are we uh basically PhD students what's the level Beyond PhD then maybe you should get that oh boy in terms of suffering engineer so I think I can speak to that a little bit when I got into crypto I was like very much practitioner not academic like that was never in the cards for me and I think that the way that the engineering World communicates and the way that the academic world communicates are entirely different where like one of my favorite examples of this is like Justin will often say you know don't worry it's trivial you know and that triviality will be like have been like a month of implementation work which is just really meant to say that it's just like getting through the

details and it's certain that it will work but in somebody else's problem and specifically your problem yes exactly and so I think there was like a lot of especially in the beginning and I think we've gotten better at this over time but just trying to figure out how to bridge that knowledge and information Gap and I think on our end like getting better at understanding the information from papers directly but I think also on Justin's end being willing to not say it's trivial and getting to the weeds with us on the details right like actually how do we manipulate these bits so that we can make this prover program run fast and then you know like after we get it to a certain point making sure that the entirety of like the algorithm and where we spend time and how the CPU Cycles are are spent is transparent to

Justin and Sereno and arisu so that they can say you know that looks too long like the relative proportion of the time that the algorithm spending here looks too big there must be a bug and then we can go through it together we can go through line by line and figure out sort of like why is this prover not performing ASM totically as Justin and Sereno and arisu are expecting so I think we both started on opposite ends of the spectrum and we each sort of came a little bit closer to the middle in terms of willing to get dirty details and also willing to think more sort of like longterm theoretically Michael what's been your experience similar to Sam I think I was fortunate in that so I guess going all the way back what sort of got me into the crypto space was I

was very interested in like number Theory and by way of that cryptography in school and then kind of really due to Career life planning on my part I ended up taking a lot of theoretical computer science classes but never actually doing any research so I just did like software engineering internships all the way through through college so didn't didn't really uh have the option to go down the PHD route but I was always interested in cryptography and kind of the more theoretical side of things any desire to go back into Academia maybe I never had any desire and I still don't Justin how about from your perspective being able to work with you

know Engineers to bring your ideas to fruition yeah this has been a dream really the whole thing is just sort of magical and couldn't have you know ever expected this and it's it's been some of the most fun I've I've had in my whole career it's not clear to me that this really could have happen in many other places and I'm super grateful that it did so give me the immediate next steps that you guys are planning to uh execute on and then also maybe just sum it up and give you the end game too like what is the world going to look like once all of this is assuming it it it all goes successfully and according to plan Step One Vacation okay vacation that's a good plan step two dot dot dot step three profit profit

yeah so I think there are a lot of things that we are focused on there are sort of some tech debt things that we left behind in the race to get this out the door that I think that we will clean up I think in that process we'll sort of it's hard to do this without getting too into the weeds but um we'll be able to make the interfaces more generic to be able to support many future directions we are still taking input from everybody that wants to use this thing the reason that we built this thing and we made it open source was one to prove the idea that the sum Che based stuff works in a risk 5 context and to prove that it can be state-of-the-art speed but we want people to use it and so we are talking to a lot of teams that are thinking of

integrating this stuff in various ways down the road we want to make sure that our road map reflects what they need out of it because it wasn't just to sort of put a flag in the sand but rather it's hopefully that a lot of people will adopt this Tech and people can trust kvms more broadly on a shorter timeline so I know you probably don't want to be too prescriptive and be divining what the future might hold but if I could urge you to put on your speculative hat for a moment and just present an application or two that you're extremely excited about that you think could come out of this work what would you say Michael's got some good ones one that I have been coming back to is verifiable compilation so this is a feature that

you see on like block explorers like ether scan where you can view the source code of a smart contract that's been deployed to a certain address right and how it happens right now is just the typically the deployer of the smart contract submits the source code and ether scan runs the compilation themselves to verify that it does in fact compile to the bite code at that address so with ckvm as long as the compiler of the highle language whether that's Soul C or clang or or whatever can itself be compiled down to risk 5 then you can prove that the compilation was done correctly right so you can prove that a certain bite code was compiled from some source code and I

think that has some interesting applications both for The Ether scans of the world but also for just general software package Registries like mpm or crates I think it could be interesting and could you know maybe help mitigate some software supply chain attacks but we we'll see I have uh two other hyp specific applic like there's the broader ones like you know use it for Block space or something like that but the two hyp specific ones that I've been playing around with are something we're seeing in sort of the consumer crypto land forecaster Etc decentralized social and one of these things that people have been talking about is like a and they've been talking about this with Twitter actually for many years as well but is like a bring your own feed algorithm

right like people are very concerned that centralized entities Facebook X Etc they own your feed and therefore they own your brain I would add Tik Tok to that list as well I think that's probably the one people are most concerned about they own the the algorithm so they own own your feed maybe they own your brain and maybe they can you know influence you in some capacity and you don't want a centralized entity to do that so the The Narrative goes that you'll come up with a bring your own feed algorithm instead and you'll apply your own algorithm over the distributed data whether that's farcast or another decentralized social protocol one of the issues with this thing is that like this feed algorithm almost certainly is sort of like there are ml models right there are a bunch of floating Point weights that don't mean

anything to humans right like we try very hard on the interpretability domain and a lot of very smart people are working on that but currently it doesn't look so good like the best strategy is basically we sample the thing and we see what it does and that's how we know whether or not it works well you can actually do that sampling process in a zvm right like you could take any algorithm blackbox run Monte Carlo over it with some sort of depth you can create a succinctness proof of that and then when you are in your bring your own feed algorithm in your client you could pick one and your local machine can actually check that it has certain properties um so you could actually rest assured knowing that the feed is complying with your selection and your preferences this could almost certainly

be back door in some capacity but like it's a direction that you can think about right where you you can use a succinct proof to sample otherwise a black box thing and reveal some details about it and then a very low power device such as a mobile phone or even like a third world Android can run this stuff and be confident when it's connected to the network that you are getting like an experience that cares about you rather than like the platform's advertisers or something like that that's really interesting you said two hypers specific applications okay I'll okay so I'll give another one one of the things people are particularly concerned about recently is that in order to get access to put your software packages your applications on people's devices more and more you go through an app store of some description that App

Store ostensibly is there to guarantee that the software has certain properties so that all the users of those devices get a similar experience right you know the obvious ones would be like it doesn't have malware it doesn't have like harmful content Define harmful content as you want to but like most reasonable people would agree on what those things are how Apple justifies its 15 to 30% App Store tax it says that they're curating it they're taking care of the security making sure nothing bad gets in and so they they have a manual process that is a lot of work right I don't know if it's 15 to 30% of all app store Revenue work I like I'll leave that to the lawyers to decide but it's some significant amount of manual work for people and people with like some

engineering talent to go through and pick through this thing and say subjectively does it meet our criteria or does it not and so like you ask like you know how might you decentralize that how do you remove the intermediary because that is also the intermediary that gets to say you know like I don't want to get into controversial area here but intermediary could potentially say certain businesses that are not aligned with them don't meet our subjective criteria you're kicked off of the app you don't have access to most of the high value consumers in the western world for example and that would be a very bad thing for business right like you don't want your business to be dependent on something like that and so some future App Store you still want it to have the properties where like I'm not downloading malware but you also

don't want to give up full power over your ability to run your business in the future and so you could imagine an app store that's fully decentralized but requires succinct proofs of certain properties right like you know you run a malware scan over the whole thing whatever that looks like you run various other things that check for malicious content Etc of course the main concern people will have here correctly is like as soon as you make that Target public it becomes very gameable right as soon as you make like an antivirus Target public immediately the virus company start gaming it and so there's there's issues there as well but it it gives you an idea of maybe the design space you could lean into yeah the dream the vision that you're presenting is this idea that you could drastically reduce platform risk while also getting rid of

intermediaries and you can't really imagine people doing that with like arithmetic circuits but if it's just you have to write rust that checks does this have a malware that seems like a very normal thing that people are used to doing right you already write the malware Checker and if you can just compile it to a succinct thing and then deploy it to a some sort of decentralized network like that's actually a very reasonable future to expect Amazing by the way Justin I have one quick question too ZK VM I know you've taken issue with people using ZK and zero knowledge to describe things is that still the proper way to talk about this stuff yeah I I don't love the term ZK VM but I'm I'm less concerned about it than ZK proof because ZK proof has

like a very formal technical meaning that's important for privacy you know the proof fleeks no information about the data that the Prov is proving it knows zkm is a bit of an informal term I don't really think you'll find a precise definition of that but it's basically a snark that lets the pro PR correctly run a computer program step by step specified in the Assembly Language of some virtual machine so because it's a less formal term I think it's more clear to people that ZK doesn't mean ZK here it really means succinct if it were up to me I would replace it with like svm or SV VM or you know something where the marketing people kill me svm has already

been taken by Sal SV svm is taken by salana but you know the key property of a ZK VM is really succinctness so it should be succinct VM or it's like a VM that not only runs itself but also outputs a proof that it ran itself correctly do you need a term for that and there's no zero knowledge there I mean it could be a zero knowledge proof or it might not be what you really care about is this proof at the end that the VM was run correctly and you want that proof to be short and quickly check no no alternative term that's gained any sort of colloquial traction ckvm is right I think that we should keep using that for now I I can live with ckvm with proofs I'm like just C us a sync proof and then it's clear what you mean and

there's not a danger that somebody thinks the proof is preserving you know privacy of the witness when it's not with ZK VM I think people know that it doesn't actually mean ZK I think there's less danger that that leads to some kind of privacy breach down the line or something well I've already gotten DMS asking if they could use a jolt to do like private auctions or something yeah okay so it is dangerous maybe we should think more about uh replacement term but you know I haven't really made much progress with the ZK proof issue either everyone says you know don't it's confusing don't well not everyone but a lot of people say that and then everyone call them ZK proofs anyway I I really try to say succinct proof even though

it's requires effort to do it zkv I haven't really fought that hard what do we think about suck VM you know it's got a ring to it I think we're gonna have to push for that suck VM I I'll think about it more yeah well maybe I just say one more thing um yeah I think the security issues cannot be overstated I think they are the biggest threat to snarks not fulfilling their potential and even like being that negative for the world everybody sort of focuses on performance and I think that makes sense because performance is preventing people from using these things today but they need to be secure

they're not now they're riddled with bugs really if you use one today you're really protected more by obscurity you know there's like a very small number of people in the world who can find the bugs and hopefully those people are not going to attack the system so the snarks are not protecting things today the fact that it requires so much expertise to break the snark is what's protecting it right not the security property of the snark itself so that needs to change and I'm much more concerned about that than performance I'd like to make some progress on that in the context of jolt in the nearer future rather than the far future we could have gone out on a high note but you had to bring down the moon well I think that's in character so stick with

that well I hope you guys all take a a long vacation have some serious RNR after all this incredible effort you guys put in appreciate it yep definitely we'll try to find some time yes all right well hey thanks again for joining this has been a great conversation yep yeah see you see you [Music]