ZK Acceleration: Pessimistic Proofs with AggLayer and Succinct

27 Jun 2024 · 48:56

Uma Roy, founder of Succinct, and Brendan Farmer, co-founder of Polygon, join The Rollup's Robbie Klages to discuss how zero-knowledge proving is maturing from theory into production. They cover Succinct's SP1, a Rust-based zkVM that lets developers write standard code and generate proofs without specialized circuit design, and how Polygon's AggLayer pairs SP1 with Plonky3 and pessimistic proofs to unify liquidity across L2 chains. The conversation also touches on the rise of Rust-based zkVMs and where zero-knowledge interoperability is headed next.

Speakers

Topics

Transcript

good morning and welcome to another episode of the rollup today's guests are Uma Roy from cinct and Brendan farmer co-founder of polygon today we're talking about the integration between cinc ZK VM called sp1 and polygon's aggregation layer the sp1 makes it easy for developers to use rust and incorporate ZK proofs into their applications and polygon's aggregation layer is utilizing sp1 for seamless quick and affordable interoperability between chains connected to the Ager hope you enjoyed today's episodes before we get into it a word from our sponsors enjoy welcome

aboard on our journey into the singularity this is the endgame road map for fra and fraxel the new L2 out of the fra ecosystem that is totally based on fractal scaling fractal the modular L2 blockch built by fra with modular and fractal scaling in mind fractal scaling is based on the mandal BR set of fractal images and it explains how l2s become l3s and the entire app chain life cycle goes through its Evolution the frax ecosystem is made of some of the top builders in the space and has stemmed from its OG

days of the frax stable coin it is now in the LST space the LRT space and this fraxel L2 joins the existing Suite of fra products including fra Swap and frax lend you can see fra fairy the bridge to go from any chain arbitrum optimism or main net into the frax main net Bridge your tokens and bring your FRA assets into the fractal ecosystem join today to get the best out of fraxel you are still early join today take part in our Expedition into the singularity what's going on guys welcome back to the

rollup today we have our friends Uma and Brendan to talk about the recent collaboration between succinct and polygon lot to talk about there today we have of course Rob here with our new look on our white text what's going on Rob how you doing man feeling good feels like we're Back to the Future or something we had white tax and then it went somewhere and now we're back and uh feels good talking about Back to the Future ZK endgame feels like the future and so we're g to talk about that um yeah absolute pleasure thanks for thanks for coming on uh Uma and Brendan and pretty stoked to talk about ZK it feels like we're inching ever closer to like this futuristic world where ZK is real

so I guess maybe that's the first question that all pose open-ended is ZK real I think it's been real uh Robie yeah I think that was actually a little offensive to Brendan it's actually like hard for me to actually get really offended although anyone following my my occasional Twitter battles might think differently but um yeah I I mean I think it's like the question is like ZK for what and I think ZK is is sort of like progressing along the Frontier where uh as we move forward like different things become possible and become practical uh with CK and so I think you know Uma and the

succinct team have are like continuing to push that Frontier we're pushing that Frontier um and so I think like you know ZK for a single rollup has been practical for a little bit it's getting better and um I think a big part of what we're going to talk about today is like how we're continuing to push and like what we see kind of being on the horizon for what's possible with see awesome we should weigh the groundwork a bit here for like what what is is is kind of coming out of this collaboration um Rob Rob skipped intros we we'll pass it over to to Uma and kind of maybe brief our audience on succinct um and kind of this idea of zkv M's uh this is your first

time on the rollup so I think that'd be helpful to kind of lay the foundation here uh yeah for sure sure so yeah I'm Uma I'm one of the co-founders of succinct and we've been working on a zkm called sp1 which you kind of alluded to um and yeah maybe to talk a little bit about what a ZK VM does uh ZK has been real for a very long time like Brendan has been working on it I think at this point for maybe like five years I want to say maybe longer um so it's always been real I just think it's always been very difficult to use um you'd have to have a genius like Brendan or other people who with like a

strong cryptography background really strong engineering background making all these like custom circuits or diving into these like really weird Arcane CK languages or libraries and with the ZK BM What it lets people do is it lets normal developers write regular rust code and then just use ZK so it makes DK a lot more real for a lot more developers I would say um and that's kind of like um we hope as a new frontier in like ZK accessibility and then also adoption because now it's just become like 100x easier to use for what we're building awesome I feel I feel compelled just to give a little bit more context around my question we had just done a ZK and Bitcoin uh live stream and so on bitcoin there's no ZK verifier and

so it's not real yet in Bitcoin but certainly has been real for a very long time in the ethereum space and Beyond and so that that makes a lot a lot of sense all right Brandon uh do you want to intro yourself and and polygon agir yeah sure so uh so I work at polygon I work on ZK R&D stuff um prior to that I was at uh this project called Mir uh that I started with Daniel lubov um and yeah I guess the the AG uh is our effort uh directed at solving the fragmentation problem on ethereum so I think it's fairly well understood now we've been talking about it for a long

time like there are a bunch of different rollups um on ethereum and so we have all this like block space that's sort of like floating above ethereum L1 that people can use um but the problem is like when we talk about scaling what we really talk about is like scaling access to Shared State and and liquidity and we don't have that like each individual L2 can have like some value can have some liquidity it can have some sh State when you think about what's required to like move that value between l2s um it doesn't really like make sense from a scaling perspective it's like um for optimistic rollups you have to wait uh seven days to withdraw for ZK rollups you have to wait uh you know maybe 30

minutes um and so vagare is like designed to provide two things it's designed to allow l2s to have asset fundability so the idea is that I should be able to take my eth that's on polygon zbm and move it to okx X layer chain and I should get eth I shouldn't have to worry about like rap synthetics or using market makers to like swap between versions of a token um and the second thing that it provides is like really really low latency interop so I should be able to do this really really quickly I should have asynchronous and synchronous composability across chains um and we think that these two things will allow us to sort of like Stitch together the L2 ecosystem into something

that feels like using a single chain so we can achieve scalability and like achieve parody um and surpass other l1s like like salana or you know others that that offer a more scalable environment now but we think that ethereum can can become sort of the endgate in the future yeah I don't know if you saw metalic meme post today but he had kind of like the thing like the guy from the movie with the scary mask knocking down all those doors and the next door is the uh cross chain ux interoperability door that needs to get knocked down so yeah it's uh it's going to be an exciting race yeah I mean we're we're working on it but yeah so let's talk about why

agair is a beneficiary of zkv Ms and kind of like why being able to do things in rust from your perspective on this you know goal to achieve interoperability is extremely important and I think that we can dive more into some of the technicals on on the pessimistic proof side of things as as well but broadly like why does Ager need zkv Ms and like what capabilities does succinct bring um for AG yeah sure so I can say a little bit but I don't want to monopolize um the conversation I so uh I guess for some context we we built this ZK evm and we did it with custom circuits or like what we call

like custom C processors um and this was a really painful and lengthy process and it took us a long time but we we we had this issue where where we could achieve performance um but at a great cost in terms of like developer time and auditability and all that stuff and so with the agir we we need to prove things to L1 that allow us to provide these safety guarantees that we need to to solve L2 fragmentation and we really wanted to avoid writing a bunch of custom circuitry and so we sort of had like on the one side we had this desire to write things in like rust or some you know well-known general purpose language

with really good tooling and on the other side we had Panky 3 that we've developed it's this you know Innovative proving system um I think it's one of the fastest options if not the fastest on the market now and so we had this Gap where we really didn't want to write custom circuitry and we really wanted to Target py 2 or sorry py 3 and we didn't really have a good way to like get there and fortunately Uma and the amazing team at the synct um developed uh sp1 which is basically like a library or a tool that like allows us to get from rust code to plony 3 um in a really really nice way and so it it was just like a

really natural uh you know I like the partnership doesn't end with us using sp1 for the pessimistic proof there's like a lot of collaboration that's going on right now but um this was something that was really really important for us to unlock Developer velocity and actually shipping the I yeah to elaborate on that um I think the hard part about building something like the AG is actually building like the protocol designing the pessimistic proof figuring out how all those chains are going to like connect and tap into the liquidity and then you know also even going out there and like doing BD and like getting those chains to sign up for something like the Ager and um I'm kind of of the opinion that you know very smart people like Brendan or like you know s d polygon

their brain power is probably best spent thinking about you know how do we actually improve the user ux and not spent on oh how should we you know spend thousands of engineering hours handwriting this like small circuit to enable like the actual protocol we designed so I think it's like safe to say that because they could just write the pessimistic proof program after they'd like come up with it in their heads and Norm Al rust code it was like I think two Engineers on the polygon team wrote it in like one or two weeks and I think a similar process without something like sp1 or a zbm where you had to like basically handr write all the circuitry would have probably taken like a much larger team months or

something like that so I think it really unlocked their developer velocity and I think also probably freed up their mind space to think about the actually important things that matter um in the agay protocol and from my perspective I think that is actually a really well-designed protocol I think it makes like a ton of sense I think it's like a very elegant solution to enable a bunch of different Stacks to connect and talk to each other and interoperate so it's not just only polygon cdk chains can talk to each other via the agir it's actually like any stack um there's going to be like some exciting news soon about even non rollups being able to connect to the AG and yeah just being able to have all the ZK stuff for that as almost an afterthought like oh we dreamed up

something okay cool now we can just code it write it and use S sp1 or zbm um I think it's kind of gamechanging in terms of freeing people's mind to design like protocols the right way um and enabling interoperability across a bunch of different Stacks uh in the way that it should be yeah I I would just add like from an audit perspective too like it's so daunting to undergo an audit for custom Uh custom built CK circuitry and and being able to like audit so obviously punky 3 needs to be audited and C6 needs to be audited sp1 needs to be audited but that happens once and being able to audit rust code is just like such better uh model for for being able to not only build the protocol but

also to be able to like iterate on this like like that's something that we are really focused on is like how do we shorten the cycle of like development and iteration um so that we can build better products and and like sp1 is such a core part of allowing us to do that yeah even on our side um we had written a tender light client so tenderman say consensus protocol we had written a like client for it using custom ZK circuits on our own team at that inake it a team of like three or four Engineers like many many months and like a lot of Heartache um many thousands of lines of code and yeah it's like very hard to understand what's actually going on and then with sp1 we'd written the same tendermint program in like I think 50 lines of code in literally like a

weekend so you turned like months and thousands of lines of code into like weekend project and I think it's just better for upgradeability auditability understandability now like any developer on our team can like take that and integrate with it um so it just seems like totally the future of how ZK is going to actually get used just because it's like at 100x easier love it so that we have this kind of broad understanding here of of this compatibility with sp1 and zkv and kind of how this interoperates with agair like to go a little bit deeper into like some of the core functionalities of agay um and of like just the ZK interoperability and specifically kind of touch on some core areas where um sp1

and this kind of rust programmability makes that uh process much easier so Brandon maybe you could shed some light on some of the proof uh generation or verification or kind of where there there is a a need in the AG uh kind of network if you will for uh uh for Z K and then kind of how uh using sp1 makes that process easier faster cheaper um and you know feel free to to get into the weeds a little bit yeah sure so I guess for more context on the AG design um the AG is designed to be used in like as Zuma said like a heterogeneous environment of VMS um so the idea is like anyone should be able to bring like

an evm or an svm or even like some custom rust VM that they build from scrp and they should be able to connect to the AG and to connect to this like pool of unified liquidity um the problem there is like if we just stopped there uh that would actually be super super dangerous because it means that any chain that uh that has an unsound prover or is sort of compromised by an attacker um could potentially like create a transaction that would uh you know maybe drain like you know a million eth from this chain that actually doesn't have a million e deposited and the uh like because the appr is unsound um a proof could be could be

generated for that transaction that can be verified by the agler and and it looks like it's a valid proof um but that would involve like draining this shared Bridge of of funds and and you know would reduce the security of the entire ecosystem and so what the pessimistic proof is is basically saying okay from the AG's perspective uh we don't assume that any of these chains have a valid Prov um instead we look at the uh like the asset transfers that are handled through this unified bridge and we make sure that uh that no Shan can withdraw more funds than it currently has deposited to that chain and so in this way we we can guarantee that like

even if a chain has an unsend approver if it's compromised and and you know is uh able to submit an invalid State transition um that doesn't affect the security of the entire ecosystem and so this specifically is what we're using sp1 uh to prove so so we have some Rust code that that encodes the logic that we're trying to enforce here um we use sp1 to uh to generate a plony 3 proof for that program or for that logic um and so similarly when we think about like that that that sort of takes care of this like asset fungibility side the unified liquid the picture where we are able to safely use a shared Bridge across a

bunch of different chains and when we think about the other side of that unified liquidity picture it's really low low latency interupt and so what we need to do there is allow chains to interoperate safely even at lower than ethereum latency um or lower than ethereum finality latency and so what we need to do there is we need to check basically that like when chains are depending on States from different chains or when when chains are like synchronously passing messages during during the creation of a block that they're actually relying on like the correct state of the world of another chain that's that's settled to ethereum and so we'll also use sp1 for that so we can enforce that like even if chains are

interoperating at lower than ethereum finality latency that uh they can't uh rug each other by equivocating or or sort of Behaving maliciously very cool could could you could we just kind of double click on that because I think low latency interop is something that like everyone wants um and so H how are you able to achieve this this faster than ethereum finality um and then and then execute these cross rollup transactions like you know the the confusion in my mind is like well if if this blockchain over here has a 30 second block time and this blockchain over here as a five

minute block time you you know how are we able to synchronize the state of those chains so that one one blockchain relies on the other and they can they can kind of like understand where each other is at if that question makes sense yeah so I I I think so we'll see if my answer makes sense um but so the uh the problem that we're trying to solve is um like if you have two rollups and uh one rollup maybe sends a message to another rollup so it says like okay I'm going to to transfer 100 eth from like this user is transferring 100 eth from you know chain a to chain B and chain B says okay I've received this message from chain a

I'm going to Mint uh a 100 eth on chain B but then uh this is all happening before uh you know the states of either rollups are are or either rollup is finalized on ethereum and so what chain a could do is it could say okay I'm generating this valid block that that includes this um this burn 100 e transaction and I I'm going to include the block and and the message that it sends to chain B um as it I'm going to prove it I'm going to send that proof to chain B um but what I'm also going to do is I'm going to create another block that uh equivocates and doesn't include that burn transaction and and that's the

block that I'm going to send to ethereum and so what happens is chain B is rugged it's it it has more eth on the Chain than it has collateralized in the bridge um and so what the AG is designed to solve is to basically ensure that chain B is only settled on ethereum if the state of chain a that it thinks is valid and is the right one is also settled on ethereum and so uh you might ask well okay what what happens if chain a equivocates and then there's some delay in finality for chain B and chain B has to but this is the sort of the fundamental like limitation or the choice that chains have to make between uh I don't know if it's right to say

between safety and liveness but between like guaranteeing that they'll never be equivocated and guaranteeing that they'll never be um and so we can extend this case to uh to sort of more elaborate uh situations where like maybe chain a and chain B are they share a block Builder or they're they're both using the same sh sequencer Shar proposer and there's a single block Builder that's synchronously building blocks for both chains and they're sending messages like within the construction of a single block and the agare can enforce that actually those messages that are received during block building are consistent so you know both chains can safely uh rely on this shared

block Builder without actually having to trust the Shar Builder um and so as far as like having different block times um in sort of the asynchronous case the chains would just need to wait for you know like like if if you're accepting message from a you know chain that has a block time of five minutes your the delay on that message would be five minutes or you know whenever the the uh the CH block is created but so I I like um also is uh I think an expert at at sort of cross train inoperability and and stuff and so I'm sure she has uh stuff to add here too actually a question for you Brendan is so is the agare offering like a fast finality da

layer as well or yeah how does that get settled no so so we uh like the way that we conceive of the agare is like the thing that we are building is just this like kind of cryptographic safety guarantee so so we're saying like Okay once chains have coordinated and and have submitted blocks um they can can take their proofs and their blocks and submit them to the and the Ager will prove that you know the bridging variant is preserved and that cross interoperability happened in a way that's uh consistent um in terms of like what they rely on for actual block creation like it's kind of up to the chain so so they could rely on espresso like espresso has this sort of like

early like I don't know pre-confirmation or finality guarantee that uh that exists and chains could opt to to rely on that or they could use a different guarantee um um and so like from the polygon perspective the part that we are building is intentionally I think like very minimal and it's just designed to provide safety around the bridge and and drop reply oh I see so it's kind of up to the chain to decide how they're going to receive messages from other chains or get Co like share it sequence with other chains and stuff like that yeah makes sense exactly brenan's been practicing yeah I mean you you think that I would be smoother uh at this point after how many podcasts I've done

but every every time I'm like oh like you know I need to think what the oh no no um yeah I was going to say I really like the AG design cuz I think it's agnostic to like what stock you're using like you could have an OP stock chain or an arbitrum I think orbit chain or you could also have a polygon cdk chain and it sounds like if they conform to these apis uh they can kind of pick and choose like oh what sequencing am I going to do what da am I going to use and then they just generate their proofs and then submit them to agair which makes sure a bunch of like basically invariance hold true across inter op and then all these chains can talk to each other I think it's a very smart design um and yeah it seems like a lot better than being

really rigid and saying oh only if you use this stack can you interoperate it's more like just an API for fast interoperability yeah I I I agree and I I think that was like very intentional from our part because we could have said okay like this is only uh available to cdk chains and and you know we're going to sort of build this wall Garden but I I think very much for us it's like okay if we can get ethereum to its next phase where it has like clearly I think one and like all these scalability critiques are no longer valid then that's going to be like so much better for everyone involved in the ethereum ecosystem then if like we can sort of you know by ourselves like control the the the like

ethereum execution layer of the execution environment and so yeah I mean I don't for for from my perspective it's about like growing the pie and like making like getting to like past these infrastructure limitations that have been a problem for as long as I've been in crypto um and then we can you know figure out how like what polygon's role will be in terms of like providing chains and stuff but um I think like being like heterogeneous execution environments sort of Mak sense because like all of the stacks that you identified are ebm based like cdk and uh and and arbitrum and optimism but I think that there's a lot of room for nonm execution environments and I think

that we want to support this like like even I I think even like custom rust environments that are using sp1 for proofs that's like an awesome idea like if you have a DEX and you don't want to pay the overhead of using the evm or the svm you just want this like custom Dex that You' rust that's super performant and you get proofs for free from sp1 like that's that's a really cool model um in my mind yeah totally that makes a lot of sense yeah we've been supporting that for a while now it's like some of the ethereum people get a little upset but it's it doesn't really make sense to just kind of uh stick to the single execution environment although we've been kind of getting push back on the

terminology now from those who are also bullish with us because they're called alt VMS like altv Ms and so now they're they're supposed to be named NextGen VMS so uh as a shot to ethereum but um Uma I want to pass it over to you to talk a bit about some of the tech as well from sp1 perspective um I may butcher this name but you guys have an interesting pre-compile I think it's called Uh kak if not sure how you guys came up with that but um yeah maybe you can talk a bit about that and kind of the performance capabilities there on that specific um

pre-compile cartey is your home for app specific rollups at the Forefront of developing new tools and platforms that enhance the capabilities of blockchain Technology ctei enables applications that are flexible and built to scale build on a full Linux environment and use traditional software libraries but in blockchain development go to cy. that's cy. iio to learn more about building your own app chain today yeah um I think you're probably referring to the catch precompile which is this hash function that's commonly used in ethereum so yeah for some background basically ethereum has this HJ function kjck that's used in

Computing it's like State rout um and like State commitment and things like that and then the agare um uses ketak um to verify a bunch of oral proofs and verify you know State accesses uh for computing that all the balances are basically netted out evenly now historically ketak has not been like very friendly inside of ZK VM so it'll take a lot of Cycles it'll be very expensive to prove and overall it'll end up being like a bottleneck in terms of proving time and cost um as one of as p1's very novel kind of breakthroughs was this pre-compile Centric architecture where basically we can take a really expensive function like catcha

that's called very frequently inside some program you want to prove and we make it a pre-compile so we it's kind of similar to writing like custom handwritten assembly for example uh so you kind of write this DK version of assembly and then you can really accelerate um proving of katak within our ZK VM so uh in all like it improves performance by maybe like four to 5x in some cases it can even be much more like 10x um but you have these pre-compiled that let you do things like expensive hash functions like katak or Shaw or verifying signatures like sap 2506 K1 or ed25519 signatures really cheaply even inside our ZK VM um and that's what

gives sp1 it's like really blazing fast it our performance um and I think why it's to agare is that they did have a lot of cats in their programs so I think without the catch pre-compile uh maybe using a zkm like sp1 wouldn't really have been feasible like it would have been too slow or too expensive but with ketak um their program runs like just fine and the proving time and cost is pretty cheap yeah we're we're Us in the ZK Community uh that are working with the evm are still paying for uh for the sins of Gavin wood um in terms of the choice of hash function and uh cting and uh and MPT so you know that that's just like something we have to De with is

there any data to like the scale of proofs and like how much this is costing right now because I I imagine like polygon agay especially in a in a more like fully fleshed out form is going to be generating lots and lots and lots of proofs so what is kind of the economics around this this proof economy right now and and how do you see this playing out yeah it's a good question I think for us we the proofs right now for polygon I mean they haven't finalized their program or things like that are in like the sense uh so it's really cheap um I think it's really already like very coste effective uh I think one really interesting thing for us we found is

that our proof costs with the ZK VM and our promiles actually are very similar to the proof costs in our previous circuit based world so even for example for our tendermint program we had gidden this custom handw Rd circuit and that had a proof cost of like tens of cents and then in our zkm world that also has a very similar proof cost um just because like our pre- compiles are so efficient and then Pony 3 is like super awesome so like Daniel and Brendan and like the rest of the polygon zero team went crazy with py 3 they have a lot of great optimizations and that enables actually it to be very fast and very cost effective um and I think the mental model for cost is already a lot of these

proofs cost like cents so it's like totally doable um we have some benchmarks suggesting even for like a ZK evm so like you take something like ref you run in an sp1 it ends up being like a couple cents per transaction all that stuff's going down like you know month over month by like 2x 5x 10x like I think in three months that number will go down by 10x uh because we'll have better algorithms on our side we'll have implemented you know GPU versions of our Pro are more optimized CPU versions of approver um so yeah I think cost is really point in time and already it's really effective today but that number is just going down um more and more yeah the way that we model costs is like we just look at what

users are currently paying and then if we can get within like under 10% of that in in just the proving component then then we think that's like a reasonable sort of short-term metric for for practicality and I I totally agree witha um I'm not sure that people are Ware of this yet but we actually haven't really optimized FY 3 like to the same level that we optimized py 2 and so like a lot of people on the team are about to kind of go crazy with um reducing uh py 3 um proof cost and so I I think that will just be a really nice way to to further decrease cost very cool quick joke here is that like you know Moore's laws supposedly breaking so now we have like

uma's law or Brendan's law where the cost of DK proofs actually cut in half every every year um no but there uh okay so I have I have another I I've got a question it's like a two-part question but this might be a totally silly question or maybe this is like really relevant which is that we've like seen a lot of these analogies for blockchains going into like compute and how you know if we can provide verifiable compute on par with like Cloud compute there could be a real like Mass migration away from cloud compute on to verifiable compute I think the realization is that like well that would only happen if there's an incentive to do that and there's an incentive to do that if verifiable

compute becomes more affordable than something like Cloud compute and so I'm I I feel like okay so just with that frame there's another framing where it's like well similar similar analogy to optimistic rollups and ZK rollups there's only like if ZK rollups are more affordable than optimistic rollups then we'll see a mass migration from optimistic rollups to ZK and so is that like a fair analogy do and and do you think that there is a world where ZK becomes affordable enough that it makes it makes ZK rollups more affordable than optimistic settlement and then it makes verifiable compute more affordable than Cloud compute well

Robbie do do I have your permission to just go off for a moment you know if I offended you in the beginning part of this podcast by OPP to so so I would say so this is like a pet argument for me that I feel very passionate about uh and it that doesn't even matter because it's like empirically true optimistic rollups they're actually already more expensive than ZK rollups because people look at the cost of optimistic rollups and they just look at transaction fees that are explicitly borne by users but if you look at all of the fees like let me back up there there's this cost that users also bear which is they bear like the capital in efficiency cost of having

their funds locked on an optimistic rollup for seven days to to withdraw via the native bridge and so if you look at all of the money that users have paid to skip uh the 7-Day withdrawal period and withdraw via third- party Bridge it's like $40 million on arbitrum and the cost of just proving every transaction uh on arbitrum from Genesis is like one 100th of that and so and like that's going down like like um said that that's going down like by 2X or by 4X like every month um and so I think that we can already say that if you look at like a if you take a holistic view of cost then optimistic rups are already far

more expensive than ZK rollups um I think that what's held back ZK rollups so far and and like you know cop to this for polygon is just like the tech has not been that mature on the client side so the prover actually works well like the cost is good um but we made some decisions you know on the client side that we're undoing and that that's led to like a subpar user experience um but once we get to sort of maturity and parity in terms of ux then I think that you'll see like ZK rollups like really really start to take off because um especially if you if you think about like the fact that we're moving to this mult multi-chain ecosystem um being able to bridge funds instantly without

dealing with you know a withdrawal delay for a challenge period that's like a much much better user experience than than optimistic call yeah if I may add to that rant I like totally agree with Brendan I think like ZK is like the only true form of scaling like optimistic stuff I think just doesn't actually really scale that well because we have this whole fragmentation problem like how many times have you tried to use a rollup and then you're like oh I have my money stock on another roll up okay now I have to go to a bridge okay now I have to find the bridge with the lowest fee oh then my money takes like 15 minutes if you're on the other side like that sucks like that's not that's not sustainable and I think ZK is like the only way ethereum is actually going to

scale like that's why it's the end game that's why vital is super bullish on it that's why it's like and if you actually think about it from like a holistic perspective ZK is verifiable compute like it is literally scaling like the optimistic stuff is not really scaling in the same way you have to have people also running the nodes like redoing the computation reverifying it so I think ZK is like the only way any of this is actually going to work and I think the thing holding back CK I think cost is actually a bit of a myth like as Brendan said actually today optimistic Roll-Ups have a lot of hidden costs that are kind of like disguised and shoved under the rug and the ZK stuff is already actually really cheap so I I actually don't think the cost is maybe even that much of an

issue although in the public eye I think it is I think the real um thing holding back ZK today is like the developer burden for example if you're like a founder of a ZK rollup um you know you have to spend basically 80% of your time being like Oh God like how do I think about my ZK proof system your best Engineers on your team are probably you know spending time working on all the ZK stuff and I think that is like you know a tough situation to be in as like a rollup founder because really you should be spending all your mental cycles and all your Creative Energy on like oh how do I have the best ecosystem how do I attract the best users how do I like you know think about the deps and stuff like that and so I think like with dkbm like

sp1 where now if you're a rollup founder you can use ZK as a total Black Box you don't have to worry about upgradeability and all that stuff like you can just write normal rust okay when WTH upgrades you're like okay let me cargo update and improve like bring in the latest version of WTH uh great now everyone like the most creative BD people can also have ZK rollups I think then that's when like ZK is really going to take off like it's going to be cheaper faster better better ux and also just really easy for developers to use and like with that combination of things I think it's inevitable that like every rollup is going to be a ZK rollup I think there's no way that Bas doesn't happen I think honestly even in like the next year I just see it happening and maybe that's a

contrarian opinion but it's like one that I really strongly believe like uh when the usability and devx of ZK gets good which now I feel like it has with sp1 it's just going to take over everything that was my brand I think I think not not to like create like too tortured an analogy but I think that there's like this interesting thing happening where right now if you're like an app chain founder to to um's point you have to think about like all of these like technological elements you have to think about like okay like how do I build on ZK technology and then you also have to think about uh okay like even Beyond sort of my core competency of maybe building a D5 primitive building a game

or building an nft M um I also have to think about like all this like ecosystem development so I have to think about okay how do I uh incentivize liquidity to like come into my Marketplace how do I uh bring users how do I like you know uh like connect with uh people that are are like Market making for nft or for for def5 um and so I think like in the same way that like sp1 is trying to AB ract away or sort of blackbox the technology like the agay is about abstracting away like all that ecosystem development like the the idea is that like you should just be able to focus on your core competency like the thing that

you do better than anyone else whether that's like um like again building a D5 primitive or a game or like some social application you shouldn't have to think about like okay how do I play these like token games to like incentivize liquidity to come into my ecosystem and so I I I think we're like moving to this world in which like uh Builders can actually focus on their core competency and their comparative advantage and they don't need to think about these things that like maybe they aren't as good at but are still like right now they're they're like essential and required for the success of their their app chain but in the future like maybe they won't be and maybe the only thing that will be required is uh like building a really cool game or def5 yeah it's like you're wearing two hats it's

like you're a you're a or really it's a ton of hats it's like you're a CEO or a Founder you're a market you're a you're a therapist sometimes your employees you're a you're a CTO and and and more and kind of being able to build on on the best rails and eliminating that burden as you guys are both alluding to is like that takes the acceleration of ZK to like the whole another a whole another gear so yeah um kind of wrapping up here I think Rob do you have anything else that any questions that are on your mind here or just kind of closing thoughts I guess like one one thing that might tie into like the plony 3 optimizations is is just kind of like what's like what's

left like ZK proofs are already affordable and so like those can scale so like what like what is there still to go here to to Really accelerate yeah so so we think about cost in terms of like use case and application and so again like we we spoke early in the episode about kind of pushing the frontier of practicality and making more things feasable and cost effective and so right now um you know ZK is super practical for like transactions that have inherent economic value so if someone's doing a swap they're probably willing to pay like a tenth of a cent or like you know a couple hundredths of a cent improving cost but if they're doing something where like like an application

where um uh like transactions don't have like a very high economic value or an economic component on a per transaction basis like playing a game or or using some like social app they might they might actually like not be willing to pay um you know even a hundredth of a cent improving cost in aggregate because they're you know submitting a thousand transactions or something and like this is it's just a game it's not something that they want to like pay money for um and so I think the goal there is to just like push uh the frontier of applications that are costeffective and that sort of makes sense to be ZK rollups or ZK power apps um and so that that's what we're focused on with py 3 in terms of the concrete optimizations

um just a lot of improvements across the stack so um like we sped up uh the Poseidon 2 hash function by 2x we um just working like at every level of from the IOP to hashing to ldes and um and just focused on uh like squeezing every bit of efficiency like out of the underline improving system yeah I would agree with that like basically I think the costs today are already cheap enough for example for ethereum style rollups where already the rollups are paying a lot to etherium for GA and like settlement and things like that so I think already for a lot of those cases

proving even with the ZK VM is kind of a DI Minimus cost relative to like the rest of costs of operation but then as you make proving cheaper and cheaper it kind of opens up the world of use cases so you can imagine maybe even some web 2 company decides one day to put like a lot of their server code in a ZK proof and like every time you interact with them they also give you ZK proof that they're not doing bad stuff or like I feel like there's a lot of like use cases like credit unions or things like that where it'd be really nice to know that what they're doing is verifiable and they're not just you know randomly saying someone's credit score is bad or things like that and so I kind of view um the evolution of ZK as crypto being

like the first major use case because it is this like already very expensive environment and also like the overhead of decentralization makes it like a perfect fit for the scalability benefits of something like ZK but then as the tech gets proven out here and iterated on here and we're using crypto as kind of like our first customer then over time we can even go to other other applications outside of crypto where when the cost get cheap enough that also might benefit from verifiability um and that's also really exciting to me as like an area of ZK is like how can it be used like outside of crypto as it gets cheaper and cheaper so it's it's really just like opening up the frontier of like use cases that are possible which is very exciting yeah and and I would just add that we uh like

we've spoken primarily about costs but but actually like latency does start to matter um and so like we spoke about the aay and sort of the risk of um you know malicious chains causing reorgs um if we can shrink the latency uh at which chains produce proofs then we can like minimize that risk or minimize that window when aess issue can happen um and so I think that's like that's important same for like client side improving and so I I I think you just start to see like different applications become possible both from the cost and from the latency perspective yeah I know we say like instant finality when comparing to optimistic rollups um but like like how how much of of the focus is been is

going into also reducing that um kind of uh time to verification as is uh going into the cost of generation and verification is it like half and half split or is it mostly focused on cost right now and then going back to time after or how are you guys kind of thinking about that well I guess latency and cost are like related because if you're spending less time then you're also spending you know less money for the CPUs or whatever Hardware you're using so they're very related Concepts like generally when we speed up latency we also improve cost and vice versa um yeah so I would say they're highly correlated um in general and I think we're at this stage where there's

just a lot of low hanging fruit everywhere I'm sure Brendan feels this way too where like the pony 3 team feels like they have like 10 ideas for improving latency and cost and performance overall we also feel like we have like you know 10 or honestly a lot more ideas for improving SP 1's performance um yeah so I think there's a lot of low hanging fruit everywhere where it's we're not yet having to make the trade-off of like oh we should improve latency at the expensive cost or something like that it's an overall holistic optimization cool well guys thank you for coming on and uh talking about the collaboration and congrats for that um definitely had some really insightful takes and always a pleasure so thanks

guys yeah thanks Rob thank you onwards and upwards ZK is real Rob I don't know what's going on there with Rob but CK's real