An update on Jolt's development roadmap

Transcript

hi so in April we released an initial version of jolt it is now November so roughly 6 months have passed and we wanted to give an update explaining what we've accomplished during those 6 months and where we see jolt going in the coming months and Beyond so uh quick context when we releas jolt back in April we demonstrated that you know if you ignore issues like support for pre-compiled and GPU Integrations which you know are on the jolt road map but are not yet done then jolt was as fast or faster than other risk 5 zkv Ms and since then other benchmarks have confirmed that finding so you might wonder what are the key issues that uh have prevented jolt from being used

widely already and I think the main answers are the following so on initial release we were missing some basic functionality such as support for the rust standard Library which uh pretty quickly we addressed and support for the risk 5m extension which we've also addressed so for example uh if you run jolt on applications involving a lot of multiplication operations it's now an order of magnitude faster than it was back in April the other major issues for jolts wide usability were that on initial release it had very high verifier cost so proofs were well into the megabytes and the Prov space is high so as of today the jolt prover requires several dozen gigabytes of space to prove that it correctly executed roughly

1 million risk five cycles and as of now the space usage of the prover grows linearly with the number of Cycles proved right so if you prove 10 million Cycles it requires 10 times more space to generate the proof than if you prove 1 million Cycles in summary after we added support for the rust gender library and the risk 5m extension the two major issues were high verifier costs and high space usage for the prover so in the last 6 months most of our efforts and improvements have gone into addressing verifier costs so we added support for different polinomial commitment schemes which with much better verifier costs we also changed how we were uh kind of batching

different Grand product arguments so jolt proves many different Grand products over 100 of them and we are now sort of treating them all as one giant Grand product more or less which substantially reduces verifier cost further and we are just finishing up support for different kinds of grand product arguments that have better verifier costs than the one in the initial version of jolt so you put all of that together and today jolt proofs are less than 200 kilobytes in size rather than multiple megabytes and we will soon be able to go down to as little as a few dozen kilobytes although that will come at the cost of a slightly slower approver and to clarify none of these proof size Es are yet using snark composition or recursion so these are

you know 35ish kilobyte to 200 kilobyte proofs with no recursion needed now A major benefit of achieving these lower verifier costs is it sets us up to address in a very nice and clean way also the Prov space usage issue so because jolts somewhat uniquely amongst zkm today uses elliptic curve commitment schemes we have access to very efficient techniques for controlling Prov memory usage called folding schemes and so that is next on the agenda once we finish that I expect that the jolt prover will use less than 2 GB of space while retaining its excellent proving time and at that point the two major issues that

have perhaps been standing in the way of wide usage of jolt will have been addressed and I expect and hope for a phase change where jolt starts seeing quite a bit more usage we are currently working on adding support for pre compiles and GPU acceleration for the prover as I previously mentioned and we have known for most of these 6 months several optimizations available for the prover based on recent research some of which we've actually done in the last 6 months so we are finally getting to a point where we can prioritize implementing those optimizations they're sort of summarized up here at the top of the screen I'm hopeful that they will lead to another 2X or more speed up for theover so once all of that is done continuation that is space control for

theover Via folding GPU acceleration pre-compile support you know getting implemented our known prover speedups you know we hope that jolt will be the only zkm suitable for proving in resource limited environments with you know 2 to four gigabytes of space or less while simultaneously achieving state-of-the-art proving speed at that point we will turn to switching from elliptic curve-based commitment schemes to hashing based commitment schemes like the Bas polinomial commitment scheme now this will make jolt more complicated but I expect also significantly faster the complications largely come in because commitment schemes like Bas part of

their power is that they work over a very nice fields of characteristic 2 but working over characteristic 2 while great for performance reasons actually complicates certain things and I'll be blogging soon about some of those complications and details of them so that element is further off but we do hope that that will lead to kind of the fastest version of jolt I want to note that there will always be two versions of jolt one using elliptic curves and you know 256-bit fields and the other using hashing based commitment schemes that will probably work over binary Fields neither one will ever completely dominate the other my guess is that the curve based scheme will be the simplest and the smallest space for the prover

and longterm using hashing based commitment schemes will be the fast but might require more space and will also be more complicated uh the proof system beyond that we have started significant efforts towards formally verifying the correctness of the jolt implementation and generally trying to identify and correct all of the bugs that might be in it this is going to be a yearslong effort not only for jolt but for the entire Community trying to build and use these ekms they will be buggy and hence not truly securing anything other than perhaps through obscurity the bugs are there but they're hard to find that will be the case for years and so we have made it a priority to kick off our efforts you know the initial steps along the long road to getting some kind

of confidence that indeed the entire jolt implementation is bug-free and you know the prover is actually proving the statement that the developer thinks it's proving and so forth so uh we'll be releasing some blog posts on those efforts soon as well as some research papers and yeah that is our plans for jolt in the coming months the focus will be on folding and elliptic curves and in the long term we will turn our Focus to hashing based commitment schemes and trying to get another order magnitude speed up out of them