Ethereum Sequencing and Preconfirmations Call #6

Transcript

okay welcome everyone to uh the sequencing and pre-confirmation call number six this call is going to be uh about real time proving and real time settlement uh I have a presentation uh which I prepared which I gave at ZK Summit a couple days ago I guess this is an opportunity to uh give the presentation to those who haven't seen it but more importantly uh for folks to ask questions and to have hopefully a lively discussion around it so do feel free to interact me uh as we as we go unfortunately I don't have a great connection I'm on mobile connection so I

decided to turn off my my camera uh and I'll go ahead and uh my slides okay so um I'm going to be talking about real-time proving which to a large extent uh is is all about uh ZK A6 KN proving A6 and uh the three parts of my presentation is first of all about giving motivations as to why realtime proving is uh is valuable um why we want it and it actually goes Way Beyond on

synchronous composability part two is to try and give you a sense for the progress on knock A6 and uh I'll be able to show with you when I turn on my camera the first ever SN Asic um and then in the third part which I guess we could go through very very quickly because I think it's slightly less relevant is you know my opinions on you know what is the best one of the best designs for a a snar Asic um do let me know uh if you want to ask questions just uh just interrupt me um no need to raise your hand okay so motivation um I guess before the motivation I want to give a

quick definition um in my mind uh real time proving is when the the proof latency meaning the amount of time it takes for a proof to arrive relative to Native execution is uh less ideally significantly less than the slot time and so because we have a slot time of 12 seconds you know the 10c kind of ballark is is the minimum that you need to to qualify as real- time proving but ideally will get much much lower 1 second 100 millisecond um appr latency and you know as we all know real-time proving is one of these things that allows for synchronous

composability and um the the slide that I want to show you here is is this one where I've introduced a new term which I call the synchrony window so if we have a proof latency for example of 1 second uh relative to a slot duration of 12 seconds then our synchrony window is 11 seconds and the reason is that it takes one second to generate a proof and I need to include a proof in my block as a as a sequencer that I need to start the proving process 11 seconds and so my opportunity for synchrony is limited to the synchrony window of only 11

seconds so what I think will happen is that initially we'll have real time proving on the order of 10 seconds and that will mean that the the synchrony window will only be the very first two seconds which is probably the most valuable part of the block uh because it's the the top of block but eventually we'll be able to squeeze out more and more synchrony out of our blocks now one thing I do want to highlight is that sure we can use um SNS here for this real time passing of of messages of trustless messages um I'm going to be muting a couple people

um but we can also use another technique uh which is a slightly you know less uh trustless and and more collateral inefficient which is to use a liquidity provider so instead of actually passing uh assets uh you know immediately and trustless through through a a shared contract um or or through some sort of deposit contract or through the R1 we we can also use a liquidity providers that kind of simulate this so the liquidity provider here in the middle can immediately send tokens and assets um on the desired rollup to simulate synchronous

even though the the dash lines here the green dash line and the GRE dashed yellow line can take a very long time for example seven days so this is kind of interesting for example for for optimistic rollups or even ZK rollups today that have uh that don't have real time proving and so what I expect will happen is that we're going to see these liquidity providers fill in the gap hopefully in a few months and then whenever the hardware is ready with real time proving and everyone has opted in uh then we won't need those liquidity providers anymore yeah of course there's downside to liquidity providers there's fees intimidation and and liquidity liquidity constraints and it also doesn't work

with things like nfts very well now the second big uh opportunity for real time proving is this idea of light validation so we we have a notion of a big node with Builders relays and provs and a notion of a light node uh users on their mobile phone uh or on their Smartwatch and right now we have this awkward kind of sitting type of node which is the validator node and their medium node in the sense that they can't run on the phone uh but they don't need that much Hardware a laptop is sufficient and what I think will be happening is that one by one the clients will become ZK clients so we know G might become ZK G and Bess might become ZK B and in order to become

a ZK client that is useful for validators you need to have real time proving and the reason is that when a new block comes in you need to know within a few seconds whether or not it's a valid block so that you can sync up with the tip of the chain um and so uh yeah this this is a a a a key step in uh in in individual clients uh becoming becoming ZK clients and one of the nice things here is that it's it's purely offchain right you have uh different client teams or even you know teams outside of the client team snark ifying the client teams um and actually we uh we have a a couple projects I think uh

risk zero and um and the succinct team that have been able to uh run ref on top of uh of of of their platform so they they've already been able to snarfy you know a whole client like ref and it's it's the approvers are able to to keep up um with the chain from a bandwidth standpoint and now we're down to latency optimizations now once we have a ZK uh client for every client which is which has real time proving we're going to be in a position where we can introduce this really cool pre-compile uh which I call the evm in evm pre-compile

um and it basically allows for evm execution within the evm and what this precompile takes as input is a pre-state a post State and a a a state diff uh and some proofs and it returns true or false um depending on whether or not the state transition between the pre-state route and the postate route is a correct State transition corresponding to the state diff and the proofs are indeed valid cryptographic proofs uh for for this statement and one of the interesting things here is that um it's a very strange precompile because one of the input is an implicit input that is submitted offchain uh and it's done on a

per client basis so gef for example or ZK gef might have a specific proof system that it has adopted a specific circuit um that describes uh the evm and it it may have a certain new performance characteristic it might have bugs and whatnot and if I'm if I'm running ZK GE I will have to verify the ZK GE proof If I'm running another client I'll be verifying my own client so the advantage of keeping this proofs off chain is that we can have client diversity we don't have to enshrine any specific proof system uh it also means that the clients can just continuously update their proofs without having to do hard fors it's just a very very clean design uh which re which is pretty much

the same uh that we have right now uh without the ZK part and if you're interested in the uh where where it's placed in in thealex road map diagram it's uh it's under the Verge there's a little square here called explore evm verification pre-compile now if you are a robot have a quick question yeah is there any particular reason you chose to write State diff there yes great question so the state diff here is a data availability constraint so the data corresponding to the state transition needs to be available and this is a bit of a technical reason which is

that we want anyone to be able to produce proofs for all the clients or for any of the clients and if the the data is not available then they can't produce the proof um and so unfortunately this evm and evm promile doesn't work very well for validum uh because it requires the data to be actually on ethereum so um yeah it's really a pre-compile that's designed specifically for rollups uh because the the state diff needs to be needs to be uh available one more followup question so for instance if we are executing the set

of transactions the state def here includes the effect of the transactions or the transactions themselves like the signatures and so on are included here or some could be anything I mean technically it just needs to be sufficient it needs to be data from which you can calculate the state diff so it doesn't have to be the state diff itself it could as you said it could also be the input transactions um this is not like well defined at this point um yeah the only strong requirement is that it's sufficiently enough data to be able to recompute this St makes sense thank you perfect now a rollup that uses this pre compile is called a native

rollup um and there's a few advantages of native rollups one is that they're super easy to program like literally is like one line of code uh which is in stock comparison to what uh what it takes to deploy a an evm rollup today you know you need you know many engine erors and you need uh to invest a lot of time and effort to to build circuits and for proofs and whatnot uh the second big Advantage is that the if you if you want to have an evm equ equivalent rollup then uh this rollup is is correct by construction like you're literally reusing the logic of the clients that secure the L1 so whatever secures the L1

is the exact same logic that also secures these native rollups so there's in some sense it's it there's no way in which there could be a bug um and then uh a third Advantage is this this notion of of governance synchrony so the L1 has its own governance and this in the sense that you know we can do hard forks and we can change the evm and add up codes uh and this is a real hassle for l2s that want to stay evm equivalent because now they also need to do an equivalent change and in order for them to do that because they don't have access to the social layer they have to use some sort of governance mechanism it could be you

know a multisig it could be a governance token and this this governance is in in of itself an attack vector and it might also not be perfect it might have latency and and whatnot and so one of the nice things of native rup is that as soon as the evm at L One updates all the native rollups immediately up update in the exact same slot as the hard for happens and then there's this fourth like really cool um uh possibility which is now you can have native rollups without any gas limit whatsoever and the reason is that the gas limit is there to prevent primarily a denel of service attack on the validators that need to reexecute the block and

so uh if re-execution is constant time because you have to verify SNS you know on the of 1 millisecond then now you can uh you can remove the gas limit and basically the only bottleneck is just how fast your your computer is running to do the native execution and also to do the proving that corresponds to it and then once we have these native raps in some sense we've reintroduced the notion of execution Shing uh which used to be called phase two uh a few years ago and but it's it's actually a much cooler version of execu sharting so previously we had like a fixed number of execution shots we had 1,24 or 64 execution shots and now here you can

have as many execution sharts as you want and it's permissionless it's programmable and you can add whatever logic you you want around your your Shard so you or your rollups you can add you know governance you can add tokenomics you can add public goods funding you can you can you can do whatever you want so it's um it's a really cool kind of endgame to to and a much better version of execution shotting that we had uh compared to a few years ago okay so this is the summary slide of the motivation what does realtime proving unlock it unlocks realtime settlement for the rollups which gives us this Universal synchronous composability it unlocks ZK clients or

snar clients which gives us light validators this will happen incrementally uh one client at a time offchain and then once uh all the all the clients have been snfi then we can think about introducing this pre-compile and this pre-compile gives us native rollups and it gives us uh this native execution Shing which is super cool and one of the things I want to highlight in in this last slide is that there's actually incentives for in this case the block Builders um to invest uh in in realtime proving and specifically

to lower the latency of their real-time proving and the reason is that the more the faster your you can do the proving the the the lower the proof latency will be and therefore the greater the synchrony window will be and so therefore you can have more transactions that are that are synchronous in your blocks and those you know should be denser in the sense that they should be higher higher paying transactions another thing is that the faster you can prove and by fast I mean the the lowest latency um the more time you'll have to build your blocks as a builder and the the reason is that you know the the the block needs to come with the

proof and so if you have let's say one second of overhead to building the proof well that's one second that could otherwise have been used for Block building but instead is used for proving um and then finally um once we have these native rollups especially native rollups that don't have a gas limit then you know as I said previously you're just going to be bottleneck by physics and computation and so if you invest in like these you know really fast um executors and provs then you'll be in a position where you can literally stuff more transactions in your blocks and all of these things lead to more M uh which is an incentive to to go invest in in real time

improving okay any question in this section okay so now let me talk about uh ZK Asic progress because a lot of people you know their initial reaction is okay these A6 they is all sound great but like it it sounds it sounds also a little crazy and and far-fetched so um it turns out that um there's a lot of effort uh today that is um focused on on on on these s A6 so there there's three companies which I guess I'm calling the

flagship Flagship companies in this context which are Axel cysc and fabric and I call them um Flagship because that's the only thing they do like literally these companies were were uh were created to build one single product which is a SN proving Asic and they've already um you know in some case shipped an Asic so in the case of axial there is already a chip and uh there's like a ton of progress that's done by these a companies and uh they're also very well funded and they have a lot of talent uh in house and then there's another crop of companies which are also building ZK A6 uh but for totally different reasons uh it's for Alo mining so Alo is this

block chain where the proof of work mechanism is effectively uh snar ifying uh some some sort of statement some sort of puzzle and so through the back door in some sense these companies um are are interest in SNS through through through Mining and then there's other companies um and I L five here that uh are are interested in building these chips but they uh most of them haven't started yet so for example uh ponos is is one of them in gam as one of them arine told me that they have started the process of a of a

of an Asic for a ZK protocol but they won't tell me which ZK protocol so I don't know exactly where they fit maybe they actually fit in this green category um but you know all in all there's there's a lot of companies working on this now I mentioned that we already have uh um an ASC and it's from uh from cisc and let me turn on my video so that you can see uh what it looks like uh but yeah this is basically the the bottom you can see all the all the pins and then this is the the the top of the Chip And this this shiny area here I believe is the the the actual Dy where there's there's there's silicon and it's about

100 square um millimeter uh chip so it's a reasonably sized chip it's not excessively large and it's built uh using a a 12 nanometer process from tsmc so this is a an 8-year-old process so it's uh you know not bleeding edge but it's also like not not too shabby and so what I expect will happen is that we'll start seeing uh chips on on even better processes in some sense this is a a test chip um now what does this chip do um the way I think about is that it's a a a partial accelerator for for SN so when you when you're proving SNS you have these big workloads which

are called M msms or NTTS and this chip will basically uh do these these heavy duty uh workloads uh it also does finite field uh vector addition and multiplication and there's some amount of programmability so it supports pretty much any proof system or like most most of them and the reason is that you can configure the Prime in the context of your your your fft or your NTT um so if you have the stocks for example from stock or um or from ZK sync or from polygon or whatever it is then then you can configure your Prime and then um in the context of uh msms you can also configure your Curve Your

elliptic curve to work with uh you know BM 254 which is very standard but also other curves like B 381 and this is what the axial uh board looks like they've only kind of got it working a few days ago so they have these these four chips on the board it's a PCI board and they have 64 gigabyt of memory so I believe these are the memory chips here which are connected uh next next to your chips and this whole board here is is a a board that you can go plug in to uh to a PCI connection and and get acceleration and uh this is like the the performance that

they measured specifically for MSM and so you can see it's it's like compared to a a a a 3090 GPU so that's an Nvidia GPU they actually got uh you know they got better performance so lower number here is actually better um and it costs significantly less so it cost about five times less than this GPU and it also cost uh you know roughly six times less from a power consumption standpoint so this board consumes 6.3 times less than than this than this GPU so all in all it's a win everywhere it's a better performance it's a better cost

uh and better power consumption and also uh once once they're able to like compress this chip and make it because this is more of a test board uh I I I also think that the um the size of the board will will will be much smaller than an actual GPU okay so that's axial uh they they've come out with the vzer chip I guess and and and they have plans for uh for for for for new Chips already and but there's these two other companies there's CC uh which is taking a slightly more ambitious approach for the the first version of the ASC which is a a full end to end snar accelerator and the reason this is interesting is

because even though the msms and the entities are the major workloads once you completely accelerate them let's imagine that they take zero time you're still left with other stuff and so the other stuff starts becoming the bottleneck and and you know let's imagine that the the MSM entities take let's say 80% of the time you still have 20% of the time which is obiously Stu and so in the best case if you were to accelerate the 80% you only have a 5x speed up um which you know is is good but it's not it's not the 100x speed up uh that that that as6 really promised and so cisc is kind of shooting for this you know more ambitious kind of

100x um and then there's a company called a fabric that is basically building a cryptography GPU you can think of it as a GPU um but where the individual um uh you know circuits for example the multiplier circuits instead of being uh floating Point multipliers or integer multipliers that are used in the context of of AI those would be finite field uh uh multipliers so um you know in some sense even more ambitious than what cc is doing uh but also much more complicated so now they need to come up with their or own tooling their own drivers their

own programming language and whatnot and so you know there's a higher chance of failure but you know also potentially huge rewards because it's a it's a an accelerator that could work for any kind of heavy duty cryptography uh in including FH not just SS okay so um this is the the cisc board so this is the the company in the middle that's building a full enterance SN accelerator what they've done for their R&D process is that they've worked with fpgas which are basically programmable you know you can think of them as programmable as6 and um they basically have three fpj per board so there's two boards here um

and they connect the boards up into some sort of mesh of fpgas um and their specific setup has 54 fpga so they have three fpgas per board and 18 boards and this is the performance that they've measured um on their setup so they can do an MSM of size 2 to the 30 so that's about a billion you base points and uh and coefficients in less than 200 millisecond so in less than 1/5 of a second which this is an absolutely kind of mind mindboggling uh performance and you know similar mindboggling performance on on entities and so now that they have you know this fbj proof of concept um it turns out that the you

know the natural next step is to to shrink these boards the whole board basically into one single Asic actually they they're trying to do something even more ambitious which is to take three boards with nine chips and compress all of that into a single 100 millimeter as and the reason is that on these fpgs they're only using like very specific you know parts of it uh and so they can compress all of that into one uh one really super high performance ASC um okay now the the second crop of A6 is the Alo Miners And so Alo should you know come to mainnet fairly soon uh I

had a call with Harwood and he seemed fairly optimistic and the way that I think about it is is this continuous Z price so for those that don't know Z price is an annual pricee that actually Alo was was involved I believe in the in the founding of the price and it's it's millions of dollars it's you know something like5 to1 million doar every year in prizes to accelerate the state-of-the-art of of of of these uh of the SN proving um and here we we potentially have a z price which is 10 times a size or even more so instead of a $10 million a year it could be hundred million dollar a year or even hundreds of millions of dollars per year and what I expect will happen is that um these

these companies that I listed at the beginning the four of them um as soon as the Alo puzzles have been fixed in main net then they will they will engage in this six month race because what Alo has done is that they they've used a certain puzzles for their test Nets but they've explicitly said that they're going to use a different puzzle for main Nets which they haven't yet disclosed and so you know there's no point to build a uh A6 for the the test net puzzle so everyone's waiting uh eagerly for for the main puzzles and what I expect will happen is that instead of having just three companies that are dedicated to S6 we're going to have roughly six companies um and so that's that's going to be a

fantastic outcome from an incentivization standpoint okay any questions on on part uh one or two so far okay okay sorry to interrupt okay okay I'm from ex so thanks for having me just want to clarify one thing about uh our our chief and the r map of cic yeah we also consider yeah because in this in the acceleration of snar is also within our

consideration because because we include the the vector addition and multiplication Al also you can you can operate three operations at the same time so you can add one variable and the second and multiply with the third variable so so actually you can we can also support the end to end acceleration yeah because you can send the vector into the DD and to the MSM or and you can let this stay in the DDR and then do the do the MSM later oh we can

also yeah yeah so so so you don't have to transmit the data uh in and back from the host every time you call MSM okay that that's very good to hear I didn't actually know that so yeah one of the the down ites for example of doing acceleration on a on a GPU of msms and entities only is that you you send the data over to the accelerator and then you get the result back and then all this back and forth between the so-called host which is a general purpose you know computer with a CPU at the accelerator that that causes a lot of overhead but what you're saying instead is that the host can send the all the data in one one chunk and then

it will get stored in these DDR so presumably the 64 GB of memory which has like super fast interface to the chips and then whatever operation you want it could be additions multiplications entities msms you can do it all without commun communicating back to the host yeah not not necessarily all the data I mean because sometimes when the when the C size got very large it's impossible to put all the weakness in in the in the ddrs so we so for small size C we can put all the witness in the DDR and do um everything I mean the the whole SN

proving inside the chip and then send a proof back but for for larger ones we can use the data concurrency so can we can send the data inside and do the commutation inside at the same time so we can I mean can save a lot of time to reduce the communication cost yeah so any anyway any anyway we have we have we we are already developed software uh customize the software that we can accelate the project and the the the proof system uh with very fast in

into uh proof generation yeah okay understood thank you so much this is this is super helpful so I guess what you're saying is that if you if you're bored with 64 gbt of memory well obviously if your data chunks are bigger than 64 gbt then it won't all fit in memory uh but I guess one nice thing here is that we can just design a new board with you know maybe 128 gigabytes of memory uh because that's separate from the process of building the chip which is the the hard part and then another thing which yeah is MHM yeah that's one way to do it but it's not optimal way we actually for

Next Generation chip we are considering another way because we allows the chip chip communication so we can have two chips that each support 64 uh gigabytes memory and then we can let the communication let them communicate with each other and then we can do a very large entity together and then we can also start uh store the data uh I mean the first half in one chip and the second half in another chip yeah but that's for Next Generation for this generation we can use the data concurrency that's we can when doing the communication inside chip we we send the data in and out so that we can reduce

the the I mean we can hide the the communication time I see so you're saying yeah okay yeah yeah there are two this is great two ways to yeah there are two ways to to accelerate end to end pro pro generation because the most important thing is to reduce the time yeah because the the communication time is very is kind of smaller okay gotta so I guess H is saying that generally speaking when you want to prove these very large knocks you're

bottlenecked by communication which is to say you know input output or bandwidth between the host and and the chip the accelerator or even within the accelerator and you're not bottlenecked by doing the actual computation and there's all sorts of tricks like yes um you know sending the data while you're doing computation on some other stuff there's also the latest the Next Generation which will allow even better communication from Chip to chip yes yes exactly nice but I guess um one of the things that you said is if we have small amounts of data to start with then we're in a very luxurious position and Hardware acceleration becomes much

faster and this is one of the things that I want to talk about in my opinions about how how we should be thinking about real time proving and acceleration and in some sense this is a a codesign between the the hardware part and the the cryptographic and software part um um just before we go on uh the opinions part uh so I'm M from Tao and uh yesterday the hello to uh team at uh vfrm Foundation uh PSC privacy Skilling Explorations merged uh something called the ZK acceleration layer so uh we started with MSM and ntity will be uh next and the idea was uh to provide a

standard uh in r a r trait so that uh people in uh working on Hardware just have to implement this trait and they would support uh well for stter hello to but hopefully this can be adapted to hardworks uh there is not much to like implementing the trait is really easy uh arworks can have their own version and there is just a small adapter and similarly uh halo2 people using Halo 2 so you have in terms of rup you have scroll you also have zco processors like axum you have Tao of course um and uh you even have companies like uh I think chroma with Pyon that

are doing hello to compatible in C++ but anyway this is um a standardization for uh ZK acceleration The Next Step will be MSM uh an entity sorry and uh it actually also supports uh caching inputs so uh either the base point or um the coefficients or both uh because uh well that was a common feedback that um uh communication was uh critical uh I will send a link uh to the pr and also to the telegram chat if you want to discuss it um I think most of the hardware

providers like uh supercalla fabric um cic are already in uh yeah okay thank you so much for this note M uh yeah once we have standardization this will basically make the lives of the accelerator so much easier because we can build you know drivers and tooling to specifically match this API uh and we'll be able to go uh to move forward faster okay ZK uh AIC opinions uh which actually have some implications on on you know what kind of uh proof systems and and and statements we want to be

proving so um just as a quick 101 on on on SNS there's two parts to a KN there's a the front end and the back end and the way that they're connected is through the witnesses so you have the front end which generates the witness and we call it w witness generation and then you have the back end which consumes the witness and produces the proof and you know this is where the msms and the F ffts and then and the other stuff happens and you know just as a as a rule of firm like these Witnesses are enormous um so from a from a data standpoint they're they're extremely large hence the the big fat red arrow and so um if you want to minimize the

cost of just communicating and moving around these this this Witness you want to be doing it on chip and so my first opinion is that really we want to have one chip which does everything both the witness generation and the proof generation today this the the way it's done is that the WT generation is on a host external to the accelerator and then you know as was mentioned by by husen um we're in a position where this big fat red arrow is is slowing us down so what comes into the chip is the statement which is a fairly small ch uh statement with a a thin Green Arrow and then what comes out is also very small it's it's a small proof and all the the the high Frid stuff stays within

the chip okay uh opinion number two is that really we want to be dealing with bite-sized chunks and this goes back to this concept of memory like uh if we have a very big statement that comes in then that's going to to lead to you know very high memory requirements and so what I suggest here is that instead of sending the statements uh you know the native statements to a specific application you send in bite code and bite code basically implicitly means that there is a virtual machine here uh that works a little bit like a CPU that has clock cycles and ingests this bite code and every clock is a tiny chunk um and this is what many teams are

doing they're working with for example a risk five virtual machine or for example starware uh has the Cairo virtual machine uh which is pretty well known and because you're working with these small chunks it's it's uh it's uh memory friendly and so it makes the the construction of these uh of these chips much more feasible and then in order to have like lots of small chunks you need a way to stitch together the chunks and this is where recursion comes in and there's like the fancy name for recursion is is you know PCD proof carrying data and you know there's also this other term called continuation so you do a bit of comp of computation and then you continue it with another piece

of computation and you continue it again and again and again and uh you know we basically need proof systems that are friendly to continuations so that's uh opinion number two and then opinion number three is that uh we really want to be doing as much programmability as possible out of the Asic so programming chips is like very very complicated having chips that are programmable is very complicated but doing programmability in software is like 10 times simpler if not 100 times simpler and the nice thing is that if you have a virtual machine here which is general purpose like T in complete um then you can send bite code here that you know can really represent any

statement and so if you have some sort of high level application uh you know which is written in R Steven or some other language and you have some sort of action that's that generates a statement well you know that's fine the Asic can handle anything right because here you basically have a general purpose virtual machine uh which is uh which is consuming uh the bite code and then another kind of concern is what about the the programmability of the proof system so often times uh you have Hardware manufacturers like like Axel that are worried about the community not adopting that chip because it might not be

programmable enough and so what Axel did is that they they allowed to configure the curves and the primes and all of these things but my opinion actually is that all of this configuration should happen in software and the reason is that there's a notion of of a wrapper SN so you you you have some sort of internal SN that you want consumed uh in a smart contract but the smart contract um you know has constraints for example it's uh you know if you want really low uh gas cost you need to be sending in a a so-called b254 proof or graph 16 proof and so many many different projects nowadays have this um his design where basically they they

take an internal proof and then they wrap it to generate a wrapper proof which I call a wrap for short and then they send that in the smart contract and the nice thing about the wrapper proof is that it can translate between proof systems so you can go from stocks to gr 16 or whatever to gr 16 um and so what I think should happen is that the hardware manufacturers should be very opinionated on the proof system here one that is friendly to continuation friendly to memory friendly to Hardware friendly to all these things and then whatever they use it doesn't matter because you can abstract it away with your rapper SN at the end and so in some sense what the hardware manufacturers can do is that they can provide some sort of drivers or software

uh to do the rapper the wrapping at the end so that you can consume your proof on chain and if you look at the the top um rollups today they're optimistic rollups and they the teams don't have any knowledge about about SNS um and so they don't really care you know what curve or what proof system the only thing they care about is that you can give them something that works and is is cheap to verify and so I think it's perfectly fine for the manufacturers here to be opinionated on on the internal proof systems that is used and then the fourth opinion that I have is um you want to be embracing some of the the standards of the industry so

one of them here is grph 16 this is not super relevant because it's part of the software stack so worst case you you know you can just have a different rep but the maybe the most important one here is the the risk five bite code so if you want to be sending in Risk five bite code then you need to have a risk five uh virtual machine in here and that needs to be baked into the into the Asic that can't change and uh as far as I can tell risk five seems to be the the winning virtual machine so there's uh succinct with sp1 there's Nexus that's doing it um there's jolt from the a16z team that was announced very recently uh there's risk zero of

course and so I you know I just tend to really like the risk five uh virtual machine it's kind of this go ahead I could see some um uh how do you say Pros to also wasm uh if only for browser based proving and web GPU as well yeah absolutely uh and there's also merits for arm as well um I think there's like basically a trade-off space depending on the complexity of the the virtual machine uh I think arm is a bit too complex so it's very nice uh for programming but the fact that it has a status flag for

example addition with carry uh makes it uh I think I'm not a hardware expert but uh more painful to implement in FBG or Asic but if we can have arm we can make it much faster because um ad with carry is really painful uh when you um program for uh El cures arithmetic but it's not a it's not a problem for stars yeah so I mean my my guess is that in the short term we're going to see like these super simple um instruction sets um like like like r five that I believe only have like 40 op codes and

then we're going to go up the the complexity stack maybe with wasm and May arm I'm told that arm has now a thousand op codes is no longer a simple instruction set at all um but one of the interesting things I guess thinking fundamentally is that the proof system the proving should not be the bottleneck eventually and the reason is that you can massively parallelize it and so you're going to be bottlenecked by the the native execution and then the question becomes okay what is the fastest native execution they have what is the fastest CPUs and you know it might be the the M3 CPU from Apple and that turns out to be an arm CPU so maybe in 10 years time I would change the slide to arm but you know in the in in meantime um it seems that kind of in the

short and medium-term risk five or you know was might be a good answer here okay opinion uh number five which in some sense is a a continuation of of opinion number three so if we have the programmability that's off chip but then on chip we can just fix everything uh and this is why there's the Frozen Emoji because you're kind of freezing the logic uh that that's internal and when you freeze you can pick a specific prime a specific curve and you can really squeeze as much juice as possible so for example um in the case of axial they have these 384bit uh multipliers and so if your

Prime is 256 bits well now you've kind of wasted a bunch of you know diara and and you you consuming a needless amount of power just to support these these larger primes but even if even with 256 bit if you were to fix a very specific Prime then you you could get another kind of uh uh you know maybe 2x so the kind of a you know potentially a 4X difference between having programmability of the of of the Prime versus versus not having it um and then also just building a chip which is not programmable is just so much simpler than building a a program oh now start to

interrup please I have two questions about this about this architecture so first one that do we do the I mean the the bottom level proof and the recursion in the chip yes so the the recursion actually comes into two places one is that it's internal to the chip so you have these cycles that come in you have these little chunks and you have to glue everything together so there's some amount of recursion in the chip but the other cool thing is that there's this can be recursion that is cross chip and that allows you to scale horizontally so if each chip can only run the risk five

CPU at let's say 10 MHz or you know you really want to want to run a system at 1 GHz so you can basically have 100 chips that are vertically uh so horizontally scaled and they all stitch together with these conations that they produce okay I see great yeah so like yeah I can I can elaborate a bit more on this question on this question this is a Leo from yeah so like actually like we started the ZK V impaired Hardware Designs some not here yeah so we we found it like very Hardware friendly like in in like several aspects the first is due to this like continuation

which means you can you can basically nice execution like into next sever next segment and each segment are like independent of each other and second the io band with like for for each segment is is like very very very sweet yeah so it's like um around 15 MHz in 250 uh 250 kiloby hour yeah so like minimum uh bandwidth and the third thing which also like very very good is like the memory requirement like for each boof generation like on each like accelerator is control fully controlled by you like you can you can TW you can TW the like

the size of the segment to make sure like you you just have enough memory like to to support the proof generation there so this like three things like yeah we we have like our zvm design which we borrow a lot of ideas from from from succinct risk zero yeah and we have uh develop the corresponding Hardware component to accelerate it amazing thank you Leo for your uh for your point of view and thank you so much also for being one of those companies that's focusing on on solving this problem okay uh I I have a second question as okay so about so when we

accelerate the proof generation and the recursion fastly enough will the gross 16 rep be the bottom neck because as far as we know that in order to get small proof size onine they tended to make score 16 very large in size uh yeah so like I I can probably like also talk a little bit more on that part yeah so like so after like each proof generation you you get a like a proof like the proof of of your choice like you can have like five proof or like other proof then you you have this like two to one recursion so like you

recurse a notot you basically build a a a m tree of poofs and after that prob like the next step is a gr 16 like you you just WRA it up and then put put it on the on the on on CH yeah so the last step like it's it depends on like your design or like depends on the finality that need for for your customers so like there a lot of like factors like you can take with oh but but my my my question that the two I mean the two part in this architecture the the the first proof generation and the final proof generation C gr 16 they are totally different because they have the first is

um I mean wide and and the low in size but the second is very very tall and it's uh Smalling I mean I mean it's it's it's a narrow narrow to thing and but the first is the wide um small I mean it's count it's totally different especially for the entity right yeah so so you're right Houston like from a proof system standpoint these are completely different proof systems and what the rer does in some

sense is a translation between the proof systems now one thing that Leo said you only have to do the raer SN basically when you when you want to settle your SN so that only happens let me once a slot or once a minute or once an hour whenever how often you want to do the the the settlement and in some sense the internal yes recursion will happen like millions of times uh you know relative like it might be a million to one ratio in terms of workload between the internal one and the and the final one um now one thing that you're you're right we should be concerned about especially in the context of low latency proving is we also want this wrapping to be you know reasonably uh low latency

now the the good news is that these continuations they're themselves SN proofs like they are themselves like small uh so as an example if you have if you look at risk zero or sp1 from succinct like the continuation is itself a stock so it's uh you could actually put it on chain yes I know it's small yes it's small size yes I see yes yeah yeah I know that the final rep is happen very I mean very small the number of times yeah so maybe you can we don't need to design another

chip for it yeah okay okay I got exactly you could use the the general purpose chip which youve already built the vzero chip and that will be good enough or you could use gpus exactly yeah yeah I see I see I see okay thank you okay so I guess there's two common like push backs on this approach that I get in terms of freezing one is that uh people will tell you that the proof systems are continuously improving so you know every year you have a proof system which is three times faster than than the previous year and that's totally valid um and you know because it takes time to design a chip let's say

one year Well by the time your chip is out then the proof system is kind of already outdated there something that's three times better but like my response to this is that if we go down this rout you get a 100x and so you know sure you've lost on the 3x but you you're still you know 100x uh faster so you have still a net benefit of of 33x but uh when you when you look at uh for example the announcement from uh starware or from uh the folding Forks it's a 50 X Improvement not just FreeX absolutely this is a valid point and so in some sense you're making a bet here that you know we're starting to get

diminishing returns on the proof systems um and if you look at for example folding schemes uh like Nova style folding the constants are optimal you get a you have a constant of one um and so um it feels like we are starting to to at least soon like start hit a wall I might be you know completely wrong but uh I guess this is you're right M that we we if there's another 50x coming you know next year we should just wait and not build an e and then the the second kind of push back that I get is you know if we have if we're fixing

the the risk zero circuit here what if there's a bug in the circuit now you have to trash your AC it's garbage uh because it's it's it's fixed and this is where for more verification I think can come in and it's also another reason to have a fairly simple virtual machine here is that you can actually do formal verification on these on these simpler virtual machines and one of the things that we're we're thinking about within the foundation is actually to dramatically boost the formal verification effort across the whole industry uh because we're dealing with maret like and implementations everywhere we have you know the the A6 potentially ZK A6 but we also have ZK rollups that you know are

going to have hundreds of billions of dollars and uh we want to remove the training wheels but we also want to make sure that uh we don't have these enormous bugs that could potentially be a systemic risk to your fm itself and then we have the clients the evm clients uh that could potentially be a systemic because it could lead to consensus failures and so uh you know it's still early days but uh where you know I I and theic and and others are trying to push for this uh you know large scale competition uh to push forward for modification and so what I think is a a good approach is basically to take a specific circuit for risk five and make sure it's formally verified before you go tape out the ASC

and actually this is typical in in in as6 uh they they will generally try and prove formally verified properties of the the binary circuit between transistors and the wires because even a single bug could mean that the the whole chip is G uh Justin you mentioned ZK rollup in terms of source of bugs but um if they use ZK VM like Risk zero sp1 jolt Nexus uh the bug would be in GFF or Reef not in the rollup yeah that's that's correct so that's one of the great advantages of of of of of this uh the zkm abstraction

is that you can reuse the the existing tooling and and compilers and clients and you know we we are comfortable with the quality of Gaff and ref and we are comfortable with the the go compiler and the rust compiler these are kind of known quantities um the thing that is an unknown quantity is basically anything that has to do with circuits and below so circuits and proof systems and so this is what we want to minimize the surface area and what we want to have the highest diligence of on which is uh potentially using using formal verification and so really the form verification in the context

of a ZK client that uses sp1 for example would primarily be focused on the uh on risk uh another approach is that there are uh compiler that use uh smt a so um uh satisfiability model Lo Theory uh like CC and those can generate both formal verif formal proofs and uh uh compile to ZK circuit um like I think it's O deir something uh Turkish uh guy which is doing a PhD at Stanford that's spearheading this effort I me that sounds great if you could

message me on telegram um then I'm it turns out that there's many different teams that have already started uh for more verification efforts within like internally I think uh scroll has looked into it matabs has looked into it sounds like Tao has also looked into it so I think it would be good to uh to join forces some audit company uh there is um very dies uh I think their CTO has a PhD in formal verification and offer circuit uh formal verification for ciruit quom published some papers uh and also uh never mind as a formal verification team uh and if I were to formally verify some ZK I would go to one of those

three amazing I mean yeah let's touch let tou base off chainline okay this is I believe my my last slide um so just trying to put some numbers on on the on these ZK VM approaches so the ZK VM approach one of the big downsides is that you have very high proof overhead so you know if you have like one one cycle of risk five you're going to need roughly one million cycles of risk five to do the proving relative to the native execution um that's you know maybe a couple Vols of magnitude relative to hand handwriting your your your your statements but you know as we talked about the handwritten stuff is

not necessarily friendly to Hardware but also not to developers all to formal verification so I do think it is fine a good a good kind of Gambit to start off with this very large number in terms of overhead which is being uh you know optimized quite heavily um so I believe like later this year we're going to be in a position where the the overhead is only 100,000x now when you move to as land what you can expect just rough back of the envelope is is two ERS of magnitude Improvement so the 100,000x goes to a THX and so one thing that is kind of in my opinion possibly like totally doable is that we have this uh 100 square

millimeter chip which is what I showed you on the camera just turn on the camera again basically this this image here on the slide is pretty much the same thing as as as this and um if you look at a risk five chip um that are kind of manufactured uh there's many of them uh the the the die area is is on the order of 0.1 square millimeter so it's an absolutely tiny uh core and that's roughly a thousand times less than the the die eror that we have and so what I'm hoping will happen is that we can have a full enter Andover um that looks like this you have the native execution that's done on chip

and then it kind of communicates to all the provs around it that almost on a cycle by cycle basis or with extremely low latency uh will produce a a corresponding proof and it's possible that this Chip is going to be bottlenecked by by power right because the the way that modern chips work is that if you if you turn on every single transistor all the time it will just melt and so you know this this this red uh area might might be limited let's say to to 10 MHz or 100 MHz let's say 10 MHz and if you want to run at the one gahz well you need to scale horizontally with these continuations that I talked about with 10 different uh chips each running

at sorry 100 different chips each running at 10 MHz and that's the end of the presentation and uh we're we're at the hour so I guess I'll open it up to one last question and then we'll have the the post post discussion okay looks like we have no more uh questions in the public part of the call uh so I'll close it here and open the uh the the discussion for the the post call