ZK Proof Generation & Verification Explained

Transcript

what's going on guys welcome back to the roll up today's episode is with Rob and John from ZK verify this one was really fun we talked more about ZK proofs and ZK verification on Horizon's ZK verify we also talked about proof aggregation and specialized verification with ZK verifies purpose built chain for ZK verification at the end we talked about the road to mainnet so stay tuned for that before we get into it a quick word from our sponsors [Music] [Music]

[Applause] [Music] welcome aboard on our journey into the singularity this is the endgame road map for frax and fractal the new L2 out of the frax ecosystem that is totally based on fractal scaling frax the modular L2 blockchain 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 frax L2 joins the existing Suite of frax 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 fraxo

you are still early join today take part in our Expedition into the [Music] singularity cartey is your home for specific rollups at the Forefront of developing new tools and platforms that enhance the capabilities of blockchain Technology Cy 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. to learn more about building your

own app chain today what is going on guys welcome back to another another episode of the rollup today I am stoked to welcome our friends Rob and John from ZK verify to the podcast for another exciting conversation on ZK G be going deep on both verification as well as all things ZK um yeah without further Ado I mean uh Rob John welcome to the podcast uh you guys want to go ahead introduce yourself and then uh we'll get a little bit more Technical and into ZK sure I I'll just jump in because Robbie we we share the best names out there so uh I think we should take precedent there I'm Rob vone I'm the you know co-founder and CEO of horizon labs and uh it's our company

that's kind of seeding the the initial technology into ZK verify so we're just really proud of the Legacy that we have within the that segment of the industry and web 3 more broadly real quick background on me so I I was started my career as a a scientist originally physicist mathematician with the US Air Force I was in what's today called the space force but back then it was was just Air Force space command uh and then got into more operational intelligence type stuff um took a break there once I got into Bitcoin because bitcoin's amazing and I think was was a game Cher and something that I just kind of jumped on is like this is going to change our world so it it gave me the opportunity to kind of break from that career go

back to school and I got my PhD in finance I just loved uh you know that switch from hard science into social science and economics was just really cool and I think uh very relevant for building you know crypto ecosystems um so so that's my story in a nutshell and then excited to get into Z verifi awesome welcome to the show John welcome yeah thank you uh Hey everybody I'm John cardo I lead the product team here at Horizon Labs uh I started my career in Commercial Banking uh about 10 years ago actually uh worked in a variety of areas of of a pretty big Commercial Bank mostly data analytics and uh and product

management uh about three years ago I joined Horizon Labs uh as a product manager and uh kind of been working you know in that capacity ever since uh really excited to be here to talk about ZK verify which is the project that I'm kind of spending uh the bulk if not all my time on uh so really happy happy to be here and excited to get into it awesome yeah welcome both guys um that's uh that's really exciting that you guys are now building ZK verify I think uh our audience has enough background to understand ZK in a nutshell is kind of two sides it's proof generation and then proof

verification um and the idea of of ZK proofs is that uh they might be somewhat complex to generate but once you generate them they're very easy to verify so when I first approached this concept I found it somewhat perplexing almost that there would be an an ENT enre project if you will totally based on verification because in my in from my understanding ZK proofs were like this succinct thing that was supposed to be easy to verify um you know why looking at ZK proofs what are some common misconceptions and then you know why is it that we need something like ZK verify to exist in the market I'll just jump in and say I think that every new

technology follows a very similar kind of a m like a adoption curve and it starts off with everything being generalized this kind of What new technologies are one sta in our sta I think you summarize it very well where you have this kind of expensive and complex proof generation and then much more simplified and uh lower cost verification but the reality is that holds for certain volumes and as soon as the technology itself starts getting enough traction and adoption what we're seeing now what we started seeing as of last year basically was the cost of verification on chain started to explode because of adoption and and ZK itself is a phenomenal technology and like our our um you know team at Horizon LGE was the core team behind the third ZK project

that was out there called zencash back in 2017 when we launched and the state of Technology back then was very rudimentary I mean we used snarks and like the first implementation of snarks on chain and now the the technolog just become much more complex also much more useful and you're seeing it integrated into many more interesting products everything from rollups um they have succinct you know State proofs of entire execution layers to applications on chain even things like ziky IDs so we started to notice basically as of last year because we've been in this segment for years is that the cost of verification was starting to finally become meaningful enough to get a company like ours to start paying attention to it and then if we extrapolated that even further and said

okay if this trend persists and we don't think it's just going to linearly persist we think that ZK is going to hit this kind of a option point of the curve where it goes exponential and and even it goes beyond web 3 and you see you know like SQL databases using ZK proofs to all types of web 2 applications as well having a common trusted secure verification layer for all the stuff just makes a ton of sense so that's why we started to get really interested in it I think the only couple things I'll add I agree everything with everything that Rob said um but I I mean like the so on the on the proof generation cost absolutely expensive but we all have to sort of recognize that that's on the hardware side and that proof generation is typically done

offchain when we're talking about ZK applications like some of the ones that Rob mentioned like rollups they need the verification to be done on chain and while the verification could be done offchain in a very inexpensive way and very very quickly it does obviously consume resources of whatever blockchain it's being verified on and when you like have these proofs that are being generated you know at relatively high frequencies or what could be relatively high frequencies in the future um they're all going to be competing for Block space and on ethereum for example that block space is is already being pushed to its limits or has been pushed to its limits in the past which therefore has contributed to some pretty you know astronomical costs for for certain types of proofs to be verified

on chain um so I guess that's the one just like little distinction that that I would make there is that you know yeah it is very cheap to verify these proofs but when you're talking about doing that in an environment where there's competition for resources um you know it it could turn into a very significant cost um and so that's sort of why we've decided to build a blockchain that's entirely dedicated to verifying proofs so we cut out all the other sorts of things like pii transactions and whatever else is happening on ethereum or frankly any other blockchain um so yeah that's that's the only thing I out there makes sense yeah and that that way you guys are able to avoid this Noisy Neighbor problem where if there's a a

really popular nft Mint or some defi you know fluctuation and there's some volatility in the market gas prices go crazy because everyone's trying to push transactions through and then hence it makes it very expensive to verify some proofs um but if you push that into a different chain almost like an app chain for verifications you guys are able to avoid kind of like all of those noisy neighbors that are generating uh transactions and just isolate your transaction environment to your own chain so actually um a point that I I started before but didn't properly complete was um you know this kind of Arc of um you know technology development is ultimately get to the point of specialization and Robie to your point of this Noisy Neighbor

problem it's all about specialization I think that this is where the industry is going to go is you're going to see specialists in certain segments of the value chain and within ZK that value chain can be defined as kind of proof generation proof verification in simplest terms and now we're specializing in the verification component of so that we have like from a product perspective one like we we reduce costs and that's awesome to get an order or two magnitude reduction in costs but it's also about stability of cost so that the volatility of pricing just gets normalized so from a product perspective you don't have to worry about you know like some massive nft Mint or some other congestion that we can't foresee today this going to hit ethereum next month right um so so that's part of it but then also because

we're specializing now it um collapses or removes the constraints that you have on what types of elliptic curves can you actually use on ethereum today you right this whole thing this idea of this like you know lopsided barbell of proof generation being super expensive and the verification being cheap is because of the elliptic curves that were chosen because we knew the constraints of ethereum we knew the constraints of a public blockchain but because we have a specialized like optimized chain ZK verify we can actually stay ahead of the ethereum dev curve and offer different types of cryptography the product um developers can actually choose and still operate on ethereum verify with us and you can use completely different cryptography Rob I'd love to dig into

some of the like the elliptic curve cryptography it it is something that I hear a lot about and I tend to think it's really fundamental to to the both the economics and generally the coordination of how everything happens in a secure way on ethereum um and it's also kind of an intersection of both the hard science and soft science that you mentioned earlier and so I'm curious like could you just expand further on on like how these elliptic curves were chosen why they were chosen what the differences in those curves mean for the economics of this system yeah I mean so just at the highest level and then John please feel free to chime in because he's actually directing our product road map for which ones do we want to add

next um but even Even vitalic Now talks about different types of cryptography that would be interesting like Bas as an example that you just can't do on ethereum today and the way that it works is the curves that are chosen were those that are heavy on the computation because that can be done offchain and then on the verification side you have to be light because to have a solidity based smart contract actually running that computation for every single node every every block that's that's generated is super expensive so you want to choose a curve that has the verification super super cheap um and and not just that but then promiles are actually done and added to ethereum selectively on certain kind of like primitive that would help your operations as a product developer but

what we can do because we can just jump to like adding a new pallet to like our our ZK verify as an example and we can add a pallet say it like on a monthly Cadence we can just keep on staying ahead of that ethereum Dev curve so that we know that at some point like as an example take Bas right now Bas can't operate on ethereum but and we're probably not going to integrate it in the very near term on zik verifi either for certain like technical reasons but just take as an example uh we could um integrate that in Zin verify well in advance of any pre-compiled that would take years to actually uh get approved and integrated into ethereum and product developers could use that with us today right versus waiting the years that it

would take for the pre compiles to exist on ethereum it's just an example and that's just how we look at it is we're sort of like an advanced incubator for ethereum and then other chains like and talk about Bitcoin you can't do proof verification on Bitcoin today and I know with opcat you groups like Stark where talking about adding like a a stark verifier natively you know onto Bitcoin that's probably a long time away and even if they do it's kind of like one thing at a time and probably super expensive to actually do the verification computationally on a chain like Bitcoin but if you offload that onto a specialized chain you can actually still operate with the same types of cryptography or or with the types of cryptography that you want or need for your product based on Form and Function and then still settle onto your

L1 of choice and I guess just to just to chime in there on a couple of points so I guess like going taking a step back one of the things I I constantly ask myself i' challenging this assumption that Rob brought up earlier which I fully believe in but I I continuously challenge it in my head which is you know do we actually like really expect to see this like proof generation and proof verification volume sort of explode in the future and I I constantly come back to this like it feels like a very like chicken and egg problem right like if ethereum made it super efficient to verify proofs would there'd be a lot more proofs that were being verified on ethereum and I believe that that's true uh which is kind of why we're sort of

building this ZK verify thing to begin with um but if you kind of think about like what has to happen to have a proof verified on ethereum there are some uh uh groups that have sort of like built you know verifiers for ethereum but in reality what they're sort of doing in the background is they're taking a proof that's been generated in one type and converting it to AIC proof or one of these simpler proof types that that Rob mentioned and those still like at ethereum gas cost today kind of cost around six or seven dollar so if you think that like for example I think ZK ID was brought up earlier how many times a day do I log in and need to verify my credentials for any particular app probably at least three four five times

a day um should it really cost $30 for me to you know log into Google or whatever uh so we're really trying to like sort of tackle that and and by enabling these different proof types to be verified on chain we're really sort of uh doing a couple things one we're trying to D we're going to help you know drive down the actual proof generation cost because there certainly are more efficient ways to generate these proofs and if they don't have to be converted from one type to another before landing on chain like that's a huge cost reduction on its own um but then we're enabling you know sort of different types of crypto cryptography where both the generation and the verification site the timing to actually create and then verify these proofs can be super super

low and so we can hopefully you know enable a bunch more use cases that probably don't really aren't really feasible today or at least aren't feasible on chain and so yeah I'm really glad you take the step back because I do want to dig into some of the op cat stuff um and like what that means for the economics of ZK proof verification as well as for Bitcoin but but John to your to your point there I think you know when you say uh you don't want to convert them you're you're kind of alluding to this idea of the general purpose risk five ZK VMS right and how uh that those ZK VMS make uh these proofs in Rust which is a generally more familiar language for developers and so

you're saying that we can circumvent that I'm I'm curious as to how because we see risk zero we see a bunch of these ZK VMS start to pop up and so what is kind of like this alternative path that that you described where we can actually keep the proofs in the more in their kind of like native tongue if you will the more complex one uh without them having to go through some sort of transply you know transpilation process yeah so this kind of goes just like to the general like I guess life cycle of a transaction within the ZK verify space which is kind of the way that we're imagining uh so I can kind of walk through that but uh I guess just to take a step back yeah that's exactly what I was alluding to and and just to to plug what we've done so far we recently

launched a risk zero verifier so anything that's generated with the risk zero with a risk zero proof um can be verified directly on ZK verify and so now if we take the step back I think the way that works in ethereum today is you you run your uh sort of computation through the risk zero VM uh the proof gets spit out but it gets converted to Groth 16 and then verified directly on ethereum what we're sort of envisioning for ZK verify is that instead of you know having to go through that process of converting the proof before it lands back on ethereum we just ask you know the prover that's created the proof to send the proof directly to CK verify uh

after a couple of blocks or after a number of proofs are verified on ZK verify we're sort of posting a bunch of data in a really Consolidated way back onto ethereum or whatever other whatever other host chain uh might be you know hosting the application that's generated these proofs um and then the application that needs to know that those are verified they may be optimistically assuming they're verified um if so they can continue and check later if they need to see the verification they can look up that that data structure and very efficiently find uh the verification uh confirmation in in that data structure got it okay okay and kind of bring that

full circle to the to the General assumption that you you kind of brought up that still seems like it holds true but you know want to remain skeptical is that uh this cold start problem of of uh ZK proofs at scale you know significant volumes of ZK proofs flowing through blockchain this is something that I've I've kind of Tangled with as well because you know we see how everything right now runs on cloud compute um through these centralized companies and so I I've kind of brought this question up I've got some mixed answers and I'm curious what you guys think and I think a lot of this ends up being an uh an incentives question because arguably uh it would make more it would be more

secure to have a ZK proof verification system running on like like verifiable computation rather than Cloud computation but for to get that verification you know we have to like Co cooperate across all these different nodes they have to gossip to one another and we have to do this like replication process to verify what one you know what the other nodes in this network are doing and so do you think that we'll ever have verifiable compute at par or more affordable at at more at greater scale than Cloud compute at greater scale and more affordable uh John why don't you as the product guy talk about

that one uh and like I I will say um just I think sometimes it's it's like a a binary outcome of like all this or that it's kind of like a segmentation thing so like what type of compute would segment in a way that is valuable to be um verifiable versus what type of compute is perfectly acceptable to do in the cloud space is the way that I would look at it and then so like rather than kind of hoping that what we're doing now in the value chain for ZK can ultimately lead us to cheaper verifiable compute than what's available in the cloud I would look at it as okay assume that it's more expensive but what segment of the market would that be valuable for right but how you feel about one that wants more secure compute but is okay with paying a little bit of a premium

for that security that's how I look at it and that's how I would forecast the coming you know near term like in terms of years um but I don't know John if if you're more optimistic on it even that to me is an optimistic story and super cool I guess just a question uh like isn't that sort of like what blockchains are are are I mean we're building a blockchain right to verify proofs but it's not just like one node that's verifying the proof it's the entire network that we're asking to you know ensure ensure you're paying like a premium there right because it is being distributed across the entire network but isn't that kind of like what this is aimed to do yeah I I think a f more fundamental question to ask is like how important is decentralization yes you

have salana which is just trying to max out you know the the scale of its single machine and then you have ethereum which is a much more decentralized machine and trying to scale off of the L1 and have this rollup Centric road map obviously decentralization being way more important for ethereum than salana but both have users both have arguably have like product Market fit you know that's very relative but yeah I think I think you know you're right that is a valid question to ask like you know what is what are we really doing here um on chain yeah but I think it's a it's a segmentation thing though because like you said Robbie there there's a perfectly valid market for the Solana world and a perfectly valid market for the ethereum world and a perfectly valid

market for the Bitcoin world right like there's going to Form and Function for all of them that's why like as a fun example I'm not a Bitcoin Max you probably stopped being a Bitcoin Max in like 2013 right so it's like there there is absolutely room for a form function product Market fit for different segments of of value yeah so so getting back to the Bitcoin you know kind of like the improvements that are that are happening there um you you know you guys have been in the space for a long time bitco coin has remained stagnant for a long time and now there's some like Resurgence of building and and uh Innovation that's happening there um I heard from a little Quantum cat that expects op cat to be online like this year it's a pretty aggressive timeline

uh because I I realized that it it's kind of it seems like it should be years away but might might be much closer and so I'm curious how does you know how does like just from the basics how does having a Stark verifier on Bitcoin work versus having something like ZK verify that verifies in a different place aside from the Bitcoin L1 um maybe it's best for me to start more General yes joh John can go into more of the tech but uh the way that I look at it is um so you will have a very specific type of proof that will be verifiable with a start verifier on on bitcoin uh now there will be computation involved there and the ability to write a verifier into you

know into the chain using opcat that nodes can choose to run is great and it it is I would call it a tech breakthrough for sure but it's for very specific type of proof uh what I look at what we're doing is uh offering kind of a generalized attestation mechanism attestation of verifications that it links in with ZK verify so that basically ZK verify you can think of as like a One-Stop uh source for verification any type of like proof type you know for any type of source Web Two web 3 doesn't matter could be Groth 16 could be bjim could be you know Eon whatever right and you can run your your computation and whatever proof system you want verify with ZK verify and then

have a generalized attestation mechanism on bitcoin that that proof can verification can be settled onto Bitcoin whereas and it's done in a way that is super computationally efficient because it's literally just writing data on chain kind of like inscription style um versus is actually performing the computation on on bitcoin with kind of the the Stark embedded verifier now they each again like getting back to like segmentation and Form and Function for what I think really matters and this is where like we we always question well why are we doing this is it just cool technology or is it actually serving a purpose on the market well uh you know for um plenty of different use cases and for plenty of different types of proof

systems you probably just want to write that data on chain and you probably don't need to actually do the verifiable computation on chain for certain types of high value use cases that use a specific type of proof system with Starks cool use the verifier but I would bet and again like I I want to be optimistic on it because I think the team is absolutely brilliant it's doing it but still just the way that it works it's going to be an expensive form of computation right and just imagine like every minor having to do an expensive form of computation that automatically segments the type of problem that you can solve with that you're not going to be you know doing the whole buying a coffee type of problem with Bitcoin you know using a stark proof that you're settling on on bitcoin clearly but that's not why it's being designed

anyway right it'll probably be working for different types of like um you know l2s they're going to operate um but anyway so it's just kind of like a a product form function thing and we're like the generalists that are super cheap um the way that we're trying to do it versus the Specialists that have a much more expensive but again high value operation yeah I guess the only thing I'd add there is just like I think um certainly you know computation is going to be need going to be needed to be done on chain there uh I would also just question like like to Rob's point about you know which Market is this serving like it's serving a market that doesn't need you know high throughput like super fast execution uh whereas you know we're building a chain that is meant to do this proof verification you know within

a block uh so you're talking about you know six seconds versus minutes uh and the six seconds number is is potentially going to go down but uh you know we can you know take in many more proofs verify them much faster than I think they'll be able to be done on on bitcoin at least if my understanding of the the whole situation there is is correct coent is solving the longterm data availability problem where a lot of the data availability providers today in the modular space when you post data to them they actually only hold that data for about 12 to 16 days and then it's basically they can go into archive note or often times it's just kind of put

away into the abyss and what Coal's trying to do is build this long-term data availability solution which can plug into something this modular data availability providers and provide this longer term Perpetual data solution so what we try to think of this as is when you post transaction data onto Celestial or Veil or any of these mod da Solutions or even ethereum coal is able to provide a long-term data storage and data availability platform for that data after the time period blockchain are Billboards not databases and you know we need these providers in the space to be able to kind of hold on to the longterm data that is provided from these

providers and these blockchain State this is where coent comes in they just had a nice Rebrand check them out on Twitter as well as the website thank you for being here hope you enjoy the rest of the show mantel is a layer to blockchain with one of the biggest onchain treasuries in all of crypto and they have a 100 day campaign called metamorphosis live now what this is is it it is a campaign for their liquid staked eth token and eth as well as their upcoming liquid reaking token CM where you can utilize this token on the mantle Network in a variety of different apps some of your favorite reaking protocols and defi protocols and earn yields in the form of powder which will eventually be turning into a

governance token Mantle's been around for a while we like them because they use their own form of Ian da they have a good ecosystem and they're growing so check out this 100 day metamorphosis campaign and hope you guys enjoy the rest of this video yeah once again kind of like a the segmentation you know I I I think that's a great framing for this um you know something like uh clearing between Reserve Banks right if we get more El Salvador online uh and they're shipping M they're shipping Bitcoin back and forth right we may want that computation to be done entirely on chain depending on which balances are moving um something like a gaming application on a Bitcoin L2 that just wants to like

post the end State back to the L1 uh that is a good better use case uh for something like ZK verify that is going to have quicker uh proof times uh cheaper proof times uh and then handle the the computation off chain but then post the end result uh back to the L1 and and gaming I think is is a pretty good example because you guys have an integration that recently came online uh with AP chain um and so we'd love to hear more about that how that's going and generally like what the process was like kind of building that out and working with an nft Community like the Apes yeah John if you want to Ty in on that one please yeah yeah I can I can provide a little bit of uh an idea of what's going on there so essentially um you know when we originally built the

proof of concept for ZK verify we were imagining a very different world than you know we realize exists today uh so we we were very like rollup focused rollup Centric like we wanted to verify proofs from ZK rollups and therefore we built out this attestation thing that we've been talking about uh that post data directly back to ethereum since then we've sort of you know looked at the market we've heard from potential customers and realized you know there's a whole world of potential other types of ZK generating ZK proof generating applications like games to your point and so uh we've been working with uh the ape ape coin

Community for I guess the better part of two almost three years now um ape chains obviously being built so we said hey there's a big group of you know gaming Centric developers that likely will exist on AP chain let's start posting our data back to uh the AP chain test net right now and ultimately when it goes live main net uh so essentially you know we wrote a contract the contract lives on AP chain now it lives on ethereum as well and um Horizon's e which is an evbm compatible blockchain and quite simply you know any proof that's being submitted to um CK verify the verification of that the confirmation of the verification is being posted to ape chain with the hope

that you know any type of of game developer there could potentially utilize this for something like uh there's there's a really interesting card shuffling algorithm that involves zero knowledge proofs and so I can imagine you know not only like casino type games like Blackjack or poke but you know even you know uh Magic the Gathering or Pokemon like collector card games where you're playing against somebody and you need confirmation you know that their cards are shuffled they have a full deck all that kind of thing so we're hoping to sort of spur some I guess innovation in that space uh and hopefully you know verify a lot of proofs that come from from these types of applications and and obviously many others as well that one hits home I uh I got started in the space playing playing

poker with Bitcoin so yeah that that one's uh that one's pretty cool um sweet that that makes a lot of sense um both uh with with respect to the gaming uh developers on ape chain and kind of like how you're going to uh verify the proofs uh on onto ape chain and so you know as as this sort of uh continues down the line like you know you guys are trying to to to push scale um I think you know we see more and more of these chains popping up it's not just ethereum know you guys are on on ape chain and and Horizon and theoretically down the line more and more chains and so one of the things that we've heard a lot about you

know I I mentioned that kind of before we started recording we recently spoke to Brendan and Uma from succinct and and agir and AG is doing you know exactly what it sounds like they're doing proof aggregation right and so they're trying to do that with network effects and kind of build like this not just very easy interoperability across these different chains but potential Network effects in the form of shared liquidity um and cross rollup transactions and so just starting very broadly here I'm curious what your take on this proof aggregation concept is um and we can get into like what the implications of that down the line for user experience are I'll just start by saying I think it's awesome and we know those guys and it was a great podcast that you did with them um so I I

think that it's an absolutely necessary and needed part of this the value chain of ZK so it's really cool that they're uh leading that uh I would say different than what we're doing in the sense that so they're going for Pure cryptographic aggregation which is phenomenal where when you have a homogeneous kind of ecosystem that you can aggregate across um but there's trade-offs in that and the tradeoffs are like it's still computationally costly and it takes time and sometimes aggregation could take hours before you finally settle on chain um but again for segmentation you know for certain form function use cases that's perfectly fine and they're going to drop the they're going to amortise the cost of transactions by orders of magnitude by doing it but it'll still be limited it'll be expensive it'll be

slower um clearly but for use cases it's absolutely u a great option what we're doing is is sort of like a what I call like heterogenous aggregation and I don't know if the team like hates me for using this term but uh I I call it heterogenous aggregation in the sense that we're verifying across many different types of proof systems and then we're aggregating those but we're not cryptographically aggregating you can view it as a form of social consensus is the blockchain is aggregating them per block and then having this condensed kind of Merkel tree where the root gets stored onto your your L one of choice um so it's just again different trade-offs this is kind of near real time in in the sense of block Cycles versus kind of like waiting hours for aggregation and it's computationally super cheap to do right

and it's one that we can add a new verifier literally as like a substrate pallet every I mean we do it in like Sprint Cycles like two we Sprint Cycles but say like a month we can add a new proof system uh you can't do that you can't add a new aggreg you know like proof system in a month it it'll take a long time to do that development work and you know it probably won't be feasible for many different types of proof systems right so that's the way that I look at it I think that what they're doing is absolutely great uh we we um are very supportive of their efforts but we're just in a different segment of the market totally yeah and you know you you mentioned uh the ZK uh proof uh uh I forget exactly how you mentioned

it but like the the supply chain essentially the ZK proof supply chain um heard you mention a couple times so just kind of broadly could you explain that supply chain and just kind of work through that I think at a high level you know we all kind of get get the general idea but yeah what does the ZK proof supply chain look like in practice well I mean the way that I look at it is it starts by uh having a need for some sort of proof right some some sort of uh computation that's done that warrants a proof and then you have uh some some Hardware that's running software that generates the proof right so you can think proof generation then there's kind of a supply chain within proof generation you've got proof generation networks now like Pro Network as an example uh and then you've got the

hardware on the back side of that trying to accelerate proofs and make them GPU optimized and so forth uh and then you've got you know things that uh you know kind of the intermediary Stu like what you're seeing Ager doing what you have projects like neb doing which are actually aggregating proofs you to try to okay well these things are super expensive let's just Jam them all together and advertise costs down and then you've got all the way down on the value chain the verification side and verification historically has just always been like smart contract on ethereum you know some sort of verifier in a web browser depending on the proof type right and now what we're doing is we're offering just specialization of that layer right and then yeah it opens up completely different trade-offs and

like the way that you have to look at this kind of value chain is it's all about tradeoffs it's about what are you trying to do and ultimately what is that problem you're trying to solve that this type of cryptography or you know technology is suitable to solving awesome um John anything to add there on kind of like the economics of the ZK proof supply chain um not a ton I mean I think I want to highlight maybe the point that Rob made which is you know the the sort of proof aggregation thing is very great for you know a number of things right like the interoperability component which I don't know if we've seen really in practice yet but the promise of that is is super uh interesting but again like it it it

involves these tradeoffs that Rob's mentioned a number of times which I fully agree with right um and it's just like a I guess like sort of a totally different Market uh sort of focused on versus us where we can you know essentially decrease the time to I guess hard finality like onchain finality um in the sense of uh you know as soon as the proof is verified we are essentially sending you know the confirmation back to whatever chain which certainly opens up a number of use cases like you know if an exchange needs the proof verification you know immediately or on chain and therefore funds can be released to a user more quickly maybe we enable some of those use cases more than you know the interoperability side of

things um it's just a a sort of conscious decision that we've made not to go down that path uh but I think they are two different sort of segments of the market probably with some overlap in the middle but um just sort of different Market segmentation that done you know uh one thing to say is like I I I Envision a future like a mixed a mixed set of Solutions in the future where you can Envision a certain type of transaction that gets kind of U you know 80 90% of its finality needs from ZK verify but still goes through an aggregation process right for kind of like deeper cryptographic proof right and collapse and cost that way potentially but because maybe a certain type of transaction might have a need

for releasing funds or releasing an end-game asset or or something like that um you would use ZK verify it's super cheap it's fast right and then you would still send it through an aggregation process totally awesome I I think that makes a lot of sense and it and it kind of shows how you can get the best of both worlds through this segmentation um and this this is something that we're a big proponent of uh calling it modularity where you know you guys are are totally focused on your segment um and then there's uh uh not irely orthogonal very similar but um but different proof aggregation service that these a layers uh nebra those guys are doing uh to crypto cryptographically

aggregate these proofs and and amortize the costs um but what you guys are doing is able to take those proofs uh verify them and then broadcast them back to the the relevant L1 uh so that everyone on that L1 is apprised of the latest State and the latest proofs and have a has a insurance that those proofs are verified um as we kind of wrap up here getting back to like some of our higher level philosophical questions about decentralization and whatnot um you know I remember when I was first on ethereum um it was 2016 and I just wanted to get some coins in my wallet because like I said I was playing poker with Bitcoin but I knew that there was a lot of other exciting things out there one of them

was ethereum but at the time I had to download the entire blockchain in order to hold some coins and so it was like they were forcing me to run a full node and now you know a lot so much of this is abstracted away like you know user experience would never have anything to do with that and so I'm curious like how important is it to you guys that you know we have everyone not trusting the chain but verifying the chain themselves um we've seen light nodes come out people running them on their refrigerators you know Celestia was a big proponent of this and light nodes and will have ZK light nodes sometime soon um you know when I think of a verification layer of sorts in ZK verify it's important to accelerate and

scale the entire ZK proof process but it doesn't remove the need for decentralization to verify at like the the individual level for the Assurance of what is going on in the chain so I'm just curious again like at a philosophical level how important is it do you guys think for everyone to be running full nodes and and be verifying proofs themselves um or is it is it sufficient to kind of have this like one verification layer um that is then passing those verification and insurances back to the to the L1 and the root chain I I can maybe jump in here I don't know if we've talked very much publicly about this but um I I guess

just taking like a major step back like I didn't really give an intro on CK verify as ZK verify you know L1 blockchain but uh it's built using substrate which uh you know is the technology stack sort of behind polka do kasama and a number of other networks uh and sort of one of the the really uh cool things about substrate uh they have all these pallets that we can take and sort of like you know modularly compose into whatever we want and we made a decision to implement uh sort of nominated proof of State consensus which is a little bit different um from you know delegated approv of State for what you'll see in sort of the ethereum space um and the the major difference is that

you know it essentially is a consensus that allows for people with lower amounts of tokens are being held to have a much you know bigger voice not only in the consensus but also you know beyond that in governance and that kind of thing and so to answer your question I I I know it might have been a little bit of a Meandering path to get there but uh we we do you know want to promote like a high degree of decentralization this will be you know a community project um and so that was part of the reason that we chose this consensus we wanted to make sure that you know even people with 100,0 tokens can actually nominate a validator by nominating a validator by

the way your stake that you're putting up with that validator is uh you know potentially could be slashed if that validator misbehaves so there's there's much more of a focus on you know not having these big whale type validator nodes um and it sort of like I don't know allows for the the little person the little uh the little fish in the big pond to you know have a bigger voice um and we're going to try to keep you know the requirements for nodes down so that you know people can decide to run them without having to expend a ton of money uh to do so so I I I I hope that answers your question with respect to the the dis Central we're not imagining that you'll be able to run a note off your phone um but we are you know trying to incentivize

everyone to be involved with this uh and sort of through this nominated proof of stake we're we're able to achieve that can I just weigh in here is on the philosophical side of it is I I think decentralization for us is super important um and it's super important for us specifically because the the function that we're performing with Z verify is literally ver verifying computation across web three and maybe web to R stuff so the the Integrity of that that verification is absolutely critical and therefore decentralization is abnormally or much more important for us than it would be say for like Salam users uh and that's perfectly fine um so so that's the way we're approaching it uh and we're going to put a lot of

effort into our infrastructure and like John said the choices that we're making on the technical and the governance side of things are all waited very heavily towards decentralization perfect yeah I think uh I I think the nominated proof of stake is something that um is very cool we don't see a ton of projects doing that and so John just you know another word about the nominated proof of of stake H how is it that you know I I think the proof of stake is pretty self-explanatory like you put up stake it gets slashed if you misbehave in the in the context of a ZK proof verification if the verification you know you say that it's true but really it's false you get slashed or vice versa you know that that's a a case of

misbehavior what is it you know how how does the stake and the nomination work how how do these uh these nodes that are nominated but maybe have some smaller stake and and not as much that could get slashed how do they have a bigger voice just because I'm I'm not as familiar I think our audience may not be as familiar with nominated proof of stake yeah I'll try to simplify I encourage everybody to the polka dot govern the polka dot consensus documentation is actually pretty good and more or less for you know going to be um taking a lot from there but essentially like starting from the very end like there's a group of validators that are selected uh to to forge blocks that group of validators ultimately were nominated but once you

get to this like last phase where there's the active set of validators who are actively going to be forging blocks for the next 600 or so blocks the stake that you have doesn't actually matter so it's more of like a randomized round robin kind of situation um and then like before that there's actually a bigger subset of validators that can actually become active and that active set of the non-active or like the pool of potential validators those are all based on you know who is nominated and um the nomination process sort of encourages you to spread your stake out as opposed to put it all like in one particular node and you can sort of see very clearly like for particular nodes like

how what's their uptime been what have their offenses been like all this is very transparent so I guess like I I say that I say the fairness I brought up the fairness point just because you know you're spreading out your stake across a bigger number of nodes you have a higher chance of ultimately getting into that the end active validator set and by doing that you don't end up having you know one person with you know 20% of the the total stake or 5% of the total stake of the network sort of running things they're disincentivized from having one node with a ton of stake allocated to it that should actually be spread out from a game theory you know optimization Point of View to a lot of different noes so you end up with a with a situation

where you know if I'm just nominating with 10 tokens or whatever I do still have a chance of you know being a like a a part of an active validator with a you know I potentially share like quite a bit more than I would if I was nominating or delegating to somebody with you know a huge huge huge number of tokens where my percentage of the reward would be much less than it would be in this in this world um and that doesn't do you know the best service to nominated proof of stake I do encourage everybody to take a look at it but it but it is much fairer than than uh the delegated proof of stake God and and what is you know is this process available let's say our community is listening they want to get in there they want to verify proof uh and become a

validator in the network uh is it possible for them to do that how how would they go about becoming a verifier in the in ZK verify so we we do have pretty extensive documentation on doc. ZK verify. uh tells you all about how to set up a node whether you want to run a boot node a a validator node or just you know an RPC node um we don't have any like real incentives that are announced or you know around that right now for the for the test net phase um but you know if you choose to you can you can definitely do that they requirements are very low right now uh but they'll likely change as we proceed uh also on that documentation site you can find ways to

generate proofs um with command line arguments and then submit them to the chain um and it's pretty comprehensive in terms of you know going from not from writing the actual like computation that needs to be verified but from generating like a toy proof and and submitting it to the chain um and then yeah like I said the node um the node setup is there as well and and we have some public uh user interfaces where you can actually go in and nominate uh particular validators if you want to go through the process of of trying that out that that piece is not fully implemented yet it will be over the coming like month or so um but you can certainly you know play around with

that and try it and and see what your reward would would theoretically be Everclear is pioneering the clearing layer the clearing layer can almost be thought of as splitwise when you go on a trip with friends but for the blockchain what I mean by that is when users are sending cross chain messages there's often times fillers and solvers who have balances left on different chains that they need to rebalance and reset their positions this is where evercar comes in ever is pioneering a collaborative approach to the chain abstraction future and they are willing to work with inoperability Partners solvers and other providers in space to build a interoperable and chain abstraction

future please check out Everclear ever clear.org and welcome back to the low up awesome perfect yeah I I think that sounds great uh we might have some people in our community that are eager to try that out um on testnet and uh yeah I guess my last question is like uh and feel free to take this you know uh into some closing thoughts but like you know what is the rob you know we can start with you what is the path to main net um and Beyond so Bia it's funny John's probably glaring at me because he's uh executing on the the product plan here but um so we're we're um probably going to be code complete with what we want for mainnet as early as literally this month July um and it it

depends on ultimately when we choose to green light a launch um and there'll be a lot of other factors that go into that some of them out outside of you know the projects control so uh that's we can't specify exact timelines but what we want to do in the intern though was kick off an incentivized test net so that people can actually get out there start using the technology set up uh your use cases you know Robbie maybe want to set up uh you know some poker on achain would be great uh and start sending proofs to to ZK verify and then start earning you know what would ultimately be the you know the token that ends up launching for the network uh this is really important it's a critical phase for us as we solidify the tech we learn a lot more about um the product itself when

you think about the protocol as a product we we need to know how it's actually being used in frankf this so that we can modify things as needed to make it more user friendly and and that's why we would kick off that kind of incentive as test night and then we're going to roll into a big launch and then the launch again there's GNA be a whole bunch of um kind of launch uh criteria they would have to go for the community to Do It ultimately though the thing to say is U like Horizon Labs is kind of seeding uh some technology here But ultimately it's a community project and that's why we're getting out there like on on this show as an example is just to to help build that Community to get it out there because ultimately the community is GNA take this thing and and

run with it ding ding ding incentivized test net you guys know what that means John um yeah I'll just add a couple of things and and uh be a little vager in some cases but a little more specific in other cases so um just to go back to the node conversation I would actually encourage people you know if they want to run a note fine but like the bigger thing that I would like to see people do is start to build applications that use ZK verify for proof verification that's a much higher value um item for ZK verify and you can extrapolate from there where it might end up being more valuable for the community um whether you know between if you're making a

decision between running a note or submitting a proof submitting a proof is much higher value for us and and so we encourage people to do that are you being vague or specific John uh I'll be vague in other places don't worry that was the more specific part um in terms of the path to main net I think from a from a proof verifier point of view we have pretty like extensive compatibility we have Groth 16 risk zero and then we are able to verify proofs that come from polygon cdk which is ZK rollup and um ZK sync era we would like to add more verif if iers and we're in the process of adding one more right now there will be more uh as the year precedes and as we hopefully get you

know requests from the community and and sort of feedback from potential customers on what Pro types they'd like to see verified um other than that we're sort of like you know now working on preparing for this sort of midet launch uh so we we are in the process of sort of implementing uh tokenomics and and governance pieces and uh so that should sort of evolve over the the re remainder of the year um but I I guess like all that to say on the verifier side I think we're we're pretty in a pretty good spot we do want to add more and we encourage people's feedback on that uh you know if you have a proof type that is super fast and efficient

you can't you know generate that or verify it on another chain let us know we're more than happy to take a look and potentially implement it in just a couple of weeks um but we are really sort of going now heads down on all of the stuff that actually makes a blockchain operate right um which is super critical and important for for the mainten net launch so that's kind of like the state of the the state of ZK verify as we see it today um and I guess like the one last thing is if you have a chain that you want the atst stations to go to you're interested in building out a totally different chain uh the process for us to to kind of move uh or send the confirmation to whatever chain you want is pretty straightforward so happy to

hear any any requests or or feedback on that as well um and we can certainly work with with anybody who's willing to uh reach out and and request that so can can I add one other thing here to to uh the the both um vague and very very um tailored uh set of sequence of things is the Horizon Community just ratified a proposal to actually migrate the entire stack on top of ZK verify so it the specific thing there is because we're building ZK verify as a a substrate um chain they could actually uh Implement Horizon as aair chain on top of that and actually benefit from either promiles

that can be loaded in there or a direct XM bridge to ZK verify itself why does that matter is because Horizon then actually can kick off a very targeted program for ZK applications and then those ZK applications SCH just natively run with ZK verify um so on on that evm you par chain so that's kind of a cool thing that I I don't know how public we or loud the community's been about it other than like there there was this proposal that was ratified and now there's just like a ton of effort to get this thing as like kind of the first big anchor user of ZK verify it's like a whole ecosystem building on top of the ZK verifi ecosystem so that's something I think is uh super bullish in the sense

for usage because it's an evm it's an evm that'll have these native uh Primitives that could be used for like ZK applications awesome guys thanks thanks so much for coming on and and sharing uh your knowledge about ZK uh and talking us through Horizon as well as ZK verify uh both from a technical and non-technical end really appreciate it cool thanks Robbie thank you