Episode 327 - Proof Aggregation with Shumo and Yi from NEBRA

Transcript

[Music] welcome to zero knowledge I'm your host Anna Rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online this week I chat with shumo and ye from nebra we discuss the ways that the high price of putting zero knowledge proofs on chain could be mitigated we then talk about their proposed solution to this the nebra universal proof aggregation product or nebra UPA our conversation covers Pro marketplaces

verification aggregation systems and the design space that this all opens up we discuss what it takes to incorporate extra proving systems into nebra UPA the benefits that these systems will bring how developers are meant to interact with them and the future work they are doing at nebra to to enable seamless cross ZK rollup applications this is something that a number of different groups are working on but often approaching it from a different perspective as a quick disclosure I'm an investor in nebra and invested pretty early on as you can hear they have evolved a lot since then and so it was really fun to catch up on what nebra is all about today and the direction that they're headed now before we kick off I want to share a message from one of our recent ZK Summit 11 sponsors the web 3 Foundation they are bringing back the

legendary conference series the web 3 Summit this next Edition will be happening in Berlin on August 19th to 21st and it's programmed by the community so if you have a groundbreaking talk or Workshop or session then apply to be part of it we're also helping to program a ZK track at the web 3 Summit so you can head over to web3 summit.com and grab your tickets today now Tanya will share a little bit about this week's sponsors namada is the shielded asset Hub rewarding you to protect the multichain built to give you full control over sharing your personal information NADA brings data protection to existing assets applications and networks NADA ends the era of transparency by default enabling shielded transfers and shielded

cross-chain actions to protect your data even when interacting with transparent chains namata also introduces a novel shielding rewards system by holding your assets in a shielded set you help strengthen nada's data protection guarantees and collect n rewards in return namata will initially support IBC and ethereum based assets but will ultimately serve as a single shielded hub for all assets across the multichain learn more and follow namada mainnet launch at n.net Alo is a new layer one blockchain that achieves the programmability of ethereum the privacy of zcash and the scalability of a rollup driven by a mission for a truly secure internet Alo has interwoven zero knowledge proofs into every facet of their stack

resulting in a vertically integrated layer one blockchain that's unparalleled in its approach Alo is ZK by Design dive into their programming language Leo and see what permissionless development looks like offering boundless opportunities for developers and innovators to build ZK apps this is an invitation to be part of a transformational ZK Journey dive deeper and discover more about Alo at al.org and now here's our [Music] episode today I'm here with shumo chu and Yong from nebra welcome to the show both of you thank you Anna thank you Anna great to be on Shuma you've been on the show before last time you were here you were talking about another project

that you were part of manta but I guess since then you've you know started this new project nebra and I'd love to hear a little bit about what prompted the change what inspired you to start on this project uh yeah so to the audience who is not familiar with Mana Manta previously is uh polka dot Paran and then still poo parach chain right now also uh pivoted into a ethereum L2 currently using op stack it's moving to ZK stack uh I think for Mana previously the vision was building the Privacy layer for polka dot I think this privacy still kind of a dear in my heart the situation is that the Poco dot ecosystem

get a lot of downturn and don't get a like a in my view still in my view the attention it deserve and then basically menta is pivoting to ethereum L2 and and uh for the ethereum L2 side I think U Mana is building a great uh Community using this uh similar strategy to blast which is this like a native y strategy and by the way I mean I can talk about that but probably shouldn't be the major focus on that but the tldr is that U menta is uh becoming a more sort of a ecosystem building phase and uh still dear in my heart is a researcher I want to More Exploring The Cutting Edge Z K uh

cryptography uh technology side maybe that's why I'm here today and also I'm super super glad m is doing very very well after I left so which means I'm probably not that important to the team all right well I see but I guess what you're saying here is that like research is where your heart is and they didn't need research anymore because they were using existing out of the box stack I think they still need research is just the kind of research they need to do uh is more about the protocol side and more about uh developer tooling side I wouldn't call that not research it's just like the kind of research I'm kind of more want to standing on the absolute bleeding edge that's just my personal uh

preference got it cool e this is the first time you're on the show so why don't you share a little bit about your background and what led you to work on nebra yeah I'm happy to talk about it um so I'm an engineer by training uh started out my career on traditional Finance side and then uh one of the cool project back in the day was building decentralized data science to engage with data scientists and mathematician all over the world for them to build a Sandbox environment to do research and I thought that idea was really cool um I didn't know that was called decentralized science back then but you know in a traditional Finance contest it's very centralized and then after that I always uh am interested in crypto I was never dabble into solidity side

and uh into the tech itself but uh in 2014 when I was uh studying Welsley I got exposed to the MIT Bitcoin giveaway uh in 2014 and that was a very interesting experience to see what people are doing with the $100 Bitcoin of a digital currency that they receive and don't know what to do with it and I think that's a great social experiment for people to understand something new and then whether it will attract them to learn about the technology whether they will use it or they will cash out immediately and then um as a fun fact one of the cafe nearby actually their FIA offramp was broken and so they got stuck with a lot of Bitcoin and then they closed the

shop so that was very interesting and lucky lucky uh incident for those people yeah yes um but I think for the rest of us I think that's the first exposure to you know like register on your back of the radar and then to understand oh there's something new there's a digital currency that's not Fiat and then so fast forward for after a couple years in traditional Finance I joined coinbase and start building consumer tooling and then focused on building the trading engine and while there I was always looking for you know like-minded Builder and I wanted to build something new and then after that I joined uh Galaxy for the their investment team and then start looking for ideas on a high level to see what's on the table what's on the

landscape and then the hope there is that I want to find a project that's actually multicycle very sustainable very Innovative and then that's building something completely undefined and then we don't even know if we can build it and I think that's how ZK caught my interest and then I met schumo in zalu last year and then that's where I initially got ZK ped and start to understand what ZK can do not only to scale layer ones that we're familiar with but also there are a lot of use cases extending Beyond blushing M nice yeah by the way I was also get peed by Brian Armstrong 100 BTC airdrop when I was at graduate school I never told people the actual

story but uh I guess kudos to bran Armstrong wow for this getting so many people into cryptocurrencies yeah the crypto user acquisition cost is exactly $100 how like tell me more about that actual story because I you both have experienced this I I actually I'm Vaguely Familiar I feel like it hit my my radar because I was in tech at the time so I vaguely remember remember this kind of thing happening but what exactly was it was it to grad students was it only certain schools could you sign up from anywhere what was this exactly the one I was talking about I think was only for MIT undergrad students and then uh it was done by Dan elizer and also uh

Jeremy Ruben cuz they founded the MIT Bitcoin Club I actually did not receive the money myself but I have a lot of friends who just use it on Boba and yeah they wish they held on to so my experience was that's that was like a two-tier airdrop from coin base it's very similar to like how Mark zberg found Facebook basically he did the first like uh kind of like speed dating saying at har so I think all the MIT student get like $100 air drop yeah and then there's a second wave airdropping all the major US universities I was graduate student at of Washington then I received I forget the exact amount maybe

$20 maybe less than $100 and then the Bitcoin price went straight up and that turned into I think $2,000 each Bitcoin I mean as a poor gradate student kind of that that was a big deal right so the every single of my fellow graduate students started talking about that yeah this is the best marketing ever especially if by chance it also just like went up really quickly after words so you could you could see the potential yeah um nice all right so I think now would be a great time for us to introduce nebra I met with yumo a long while ago to talk about neb and actually back then nebra at least when we were talking was sort of presented as aover

Marketplace it was one of the first times I he I was kind of talking about this idea but I know that since then you've moved a little bit away from this idea why don't we talk a bit about what it was what was nebra originally pitched as and what has it become so I think previously we were talking the nebra vision was two piece Lego one is doing the proof agregation and the other piece is doing a pro Marketplace and uh I think we actually never think about like PR Marketplace is our primary goal take a step back Prov Marketplace um is important in the proof supply chain but we've always been focused on hey ZK proof is so expensive on chain uh for

example you need $20 today to verify a single proof on ethereum minet day and probably one to2 dollar even on the layer twos so we want to reduce this cost to 10 cent or even less and that we think this is a ecosystem wide unlock for all the ZK project and in our view in the next 10 years every single project will become a ZK project you may even not aware that uh you are using some kind of ZK technology might be invisible to you but it's very important because ZK is the only way can trustless scale computation onchan so that everyone can share the same cordination layer which

is blockchain and then there is interesting inter relationship of the proof agregation layer and the pro Marketplace because proof agregation layer requires some offchain computation which is a recursive proving to basically compute the recursive or we call it aggregated proofs in that regard right so um it's totally possible for us to build a vertical integrated stack both doing peration and pro Marketplace so in our previous kind of thought we are planning to First build the proof aggregation layer and then build a PR Marketplace but now we don't think we want to build PR Marketplace anymore um

because there are so many great people are building Pro Marketplace I can name a few like cinc gavet and so many others and also from our our own point of view like our value capture is always not on the pr Market side our value capture is always on the unchain side so to us it's glad someone else can build that we can just like use them yeah okay I I really liked how you just put the like proof supply chain concept out there and you've now talked Al about the marketplaces and aover aggregator but I want to Define this a little bit more clearly so and we I mean we have talked about it a few times on the show but let's start with Pro Marketplace which is a little bit more understood I mean

I've definitely talked more about it so yeah let's start there what is a pro Marketplace I know there's different versions of this out there yeah great I think uh my definition of pro Marketplace is very simple basically if you want to prove something and put it on chain and uh for example you don't don't have a b AWS cluster or very great GPU accelerated machines you basically delegate your proving work to third parties and that's a beauty of DK proof you can do so if you don't care about privacy yeah for example you can just delegate the public verifiable workload to a third party and they can compute for for you and you may pay some money for the computation power then you put

the proof on chain right so then after this Pro Marketplace comput the proof then you still need to put it on chain to get it usage either to say you want to attach some historical data which is like a ZK Cod processor or you want to do a ZK draw up and there are many other use cases and uh you can see the proof supply chain is first user M getting the demand second someone need to compute the proof and third you need to put the proof on chain the first first product we call nebra UPA we primarily focus on the third part I see and also I I want to add a little bit here we don't do the

proving part or maybe in the future we don't need to do the proving part ourself is that want to have a most universal interface for the third step which is putting the proof F CH for example uh we only have a portion of our users or customers can delegate their proof a huge chunk of our user cannot delegate their proof because of the Privacy one example is word coin right for example every single word coin proof have to be generated on the consumer device which is their cell phone and we are talking to many other privacy project as well because we can lower the cost of privacy on this privacy preserving proofs or true ZK proofs you

cannot delegate your proof generation to a third party so we want to find the common denominators for the interfaces of people putting the proof on chain that's why we designed NE UPS interface uh is a purely interface for people verifying their proofs all right I think I want to dig down into what that actually looks like though so but from what I've gathered is like the proving marketplaces could use a proof aggregation tool like yourselves like that they would be potentially a partner but also the ZK applications like the people people like where you're actually creating proofs and I'm curious about this like maybe even client side would they then use this proof aggregator to get it on chain yeah yeah precisely okay

that's precisely what it is so basically we find the most generic interface for people to put their proof on chain and we try to be as unopinionated as possible so both this like Pro Marketplace or someone who run their beefy servers can put their Prov on Chan and also we can support client side zkp as well nice and they're putting we're putting them in the same pool would rollups also use you or they use something else yes so maybe that's a good timing for me to give a sort of a take a step back to give a big picture give a more generic view of what is nebra UPA right so nebra UPA is the first universal proof agregation

protocol leave onchain so we are onchain protocol we are not a offchain protocol you are a set of smart contracts that I guess are like operating on an L1 or an L2 yeah precisely and have some op component and our primary goal is to reduce the cost of people's ZK verification costs like I said today in E ethereum layer one it cost $20 on L2 maybe cost $2 is so this is too much for ZK go to mainstream so our approach here is that you send your proof to us and then we aggregate your proof and possibly with all different parties that's why the universal is important by Universal we mean uh we can aggregate

proof from all kind of different parties ZK coprocessor client side proof um ZK Roop ZK VM you name it it's kind of like a car pooling um it's a great way of talking about thinking about that because we can aggregate the proofs from different parties into the same aggregated proof and the beauty of ZK proof is that the verification cost is kind of irrelevant of how many proof you're aggregating and when you say aggregate do you mean like recurse like you'll pull together a lot of these different proofs and then do a proof of all of them into a single proof so the outcome is just like a smaller proof precisely precisely so from the

high level point of view aggregation proof just means we are generating proof of proofs yeah that's actually one of the Twitter tag of one of our Engineers I generate proof of proofs nice but practically speaking on the tech side it's not there are more collabor Innovation to help us to do that more efficiently it's not just like a just like hey we just write a verifier then we run the circuit right there are many many clever technical Innovation we're doing to make it fast but from the high level it's like proof of proofs okay it's using ZK to beat ZK yeah yeah do you live on an L1 or an L2 so we have a test net running uh on sapoia okay which

is a ethereum uh test net and we're going to deploy on ethereum menet pretty soon and uh we're very likely to deploy on all the major ethereum l2s like autism arbitrum base Etc our philosophy is we follow our users whenever our users want want us to deploy we'll deploy it we'll deploy there yeah if you're deploying in all these different place does that make your system in any way inefficient like I know it's not like pools or like assets but like if you're working on the L1 but you're also working on the L2 you're not aggregating the same proofs on both of these I'm assuming so like some proofs are going to come to the L1 you'll aggregate those there and then other proofs you're

aggregating those on the L2 but is there any connection between these two things or they like just separate tools that's a very good question currently each settlement layer or chain or L1 or L2 has its own pool if we deploying deploy that that's kind of inevitable it's not like we want to it is more like the current uh architecture of the L1 and L2 you have to have in separate pools and we are working on some interesting designs to see hey in the future can we combine them um but that's in the uh outlooking and uh uh practically speaking there are some more technicalities of this our protocol on the ethereum L2 would be a little bit

different because the exact gas cost of call data and computation the ratio is a little bit different so if you want to have a optimized protocol you need to design the protocol a little bit differently not not too much uh on the L1 L2 side got it I noticed at some point you also kind of talked about supporting different languages like or honk you you made an announcement where you're like we're supporting honk for we're supporting Noir but I was pretty confused by what that even means because if you're aggregating the proofs what does that have anything to do with the ZK DSL oh so here is a general picture of how to think about this So currently

our nebra UPA V1 we only support gross proof system uh gr takes 70% of the unchain verification right now um there are a few people like word coin like suin like Risk zero they are all they all use cross so moving forward uh our nebra upav to or have multi- proof system support then we want to support as many proof system as possible so on that regard right so we need to um have a sequence of the proof system where support so we see a lot of people are very excited about nor and we want to support nor so but to be able to support nor uh The crucial part is to support uh

hunk um to the audience who is not super familiar hunk hunk is kind of evolution of hyper plunk and with some like Aztec only secret source of making it more efficient so by supporting hunk so we be able to support nor which is like a growing ecosystem of people who doing exciting things on ZK that's a context that was a context so really the question should be about the proving systems so let's actually do that so you mentioned you're supporting grth 16 actually that was one of my other questions and now you're going to be supporting honk but I also like you mentioned succin but actually they're

using planky 3 so would you be adding plunky 3 support uh possibly but right now I had a pretty deep conversation with uh cin team including Uma right now so they have a two layer system oh their top layer is planky 3 their bottom layer is a plunk or gross team right so we will be supporting sp1 uh either plunk or gross te depending on whatever the proof system they chose to the on the second layer so as far as I understand they either going to use uh gnar's gr or using gnar's uh plankk so we will support either either of these got it

but do you have plankk then already CU you mentioned honk but not plunk we have Thea plunk okay um so on the V2 it's still a prototype but it's end to end working MH also we have another flavor of plunk called a flunk uh F which is yeah FF and that was uh used by many ZK robs including polygon zkm and uh as far as that as I understand ZK syn as well okay cool um so you can see multi- proof system support will make has more applicable to many many more applications and ZK robs nice part of your work is to implement these what does implementing them even mean in your case like what do what do

you actually have to build to be able to interface with gross 16 proofs versus plonk proofs uh I can write like uh 100 page PhD Cs on that but let me let me be succin okay uh so from the high level point of view um you want to build a verifier circuit for this proof right because we're doing recursive proof which means we are generating proof of a batch of proofs the hard question here is how do you make the verifier Universal right so this is a great journey from us uh we actually published a paper last year called uni plunk it's a universal verifier the key question is

how can you make the make a universal verifier circuit so so in our first iteration we're using Halo 2 to make the universal verifier circuit for gross 16 which means we can aggregate proof no matter what your circuit is it's a circuit agnostic proof aggregation protocol so in our thir second generation that's where your question is Anna what what does it means to support a new proof system so in our cir second generation we're actually moving to a z VM plus pre-compile architecture okay which means supporting a new proof system is relative easy basically we

just implementing a verifier of this new proof system in Rust of course it's more there is more than that is that because this is a ZK VM plus pre-compile uh take a step back right the basic base case is that you can just use a ZK VM to implement a verifier then you can out get proof already but it's very very slow we're talking about 1 hourish we definitely want to be moving faster than this then basically we take what we have learned in the nebra upav V1 to how to build the efficient verifiers in the circuit we're adding proof aggregation specific pre compile

or you can say we're adding like ECC pre compile or like a hash pre compile that's to be more specific to the ckvm so that we can aggregate these like a more generic proofs from different proof system more efficiently that's a high level okay and specifically adding honk proof means we are adding a honk verifier to our second generation architecture which is the zkm plus pre compound yeah this is leaving me with two questions one is are you building your own ZK VM are you going to use something out of the box so I think we are using something out of box so basically we try a few like open source ZK VM like uh um cing sp1 and RIS zero and also jot so um we haven't decided

which one to use um in the end but I think to be honest there like uh tax deack is very very similar uh they all having a very similar Ras compilation tool chain so right now we're building a like a ZK VM agnostic a backhand for this peration so again right so our our SOS is that we're not trying to Reinventing the well however we want to be focused on where we want to improve on the technical side got it what you described though the fact that you're actually building this Universal verifier circuit makes me start to think like are you then becoming a verifier aggregation layer yourself because that does seem to be a new type of project that we're also seeing like aligned

layer and um H like so they're doing more aggregation on the verification side would you then consider aligned layer or high lay L competitors to what you're doing I think but by the way my understanding of the aligned layer and also High lay might be a little bit Rusty okay so uh I think my understanding for Align layer is that they're using uh IG layer crypto Economic Security to uh do the verification and uh I would say we have a similar interface to the developers but having different security guarantees okay so basically their security guarantee is this igen layer uh crypto Economic Security uh to the users and our security guarantee is this recursive zkp guarantee which is pure mathematic

okay so for people who don't need a full eum security there might be some use cases for Align layer but we do see we kind of similar developer interface but a different security guarantee got it and for Haley it's a very similar situation I think they're using te which is sgx as their like a security guarantee to do the verification so we would love to see more and more people working on this verification side because to be honest if you're looking at the cost structure of a project on ZK um especially if you talk to the r of the service providers uh like outlayer uh cadara conduit they have a lot of complaint from the user side hey people

say zkp proving is a cost but zkp verification even cost more right so we would love to see more and more players join the space to help to reduce the cost of putting a pro on cool but this is actually helpful also for folks who are trying to like group together what projects are working on um some of the projects use different language but as you've been going through this I'm starting to hear Echoes of what I understood they were doing and it does sound like you're supplying a similar service to the end user or to the developer but you're doing it in different ways yeah yeah yeah cool I've also seen you sometimes refer to what you're building as a shared settlement layer but so far in what we've talked about it

hasn't come up so is that still what you're doing that's right so we are uh kind of like finding the best the most accurate way to describe the solution I think for us it's more about the last smile that gets the proof on chain and then so at one point we call it share settlement layer but I think for us is that we want to be the last mile that pulling everyone together to allow the proofs onchain and we don't care where the proof come from we don't care about which zkm generate them rollups and even consumer application so that's why we're you know interested in the carpool analogy where you know you can be very different people very different groups

but if you're going to the same L1 or same L2 we're carping it together right now as schuma said earlier if you're going to the same destination we're still having separate pools But ultimately we get the passengers to the destination faster and then by faster meaning that if we're able to aggregate more proofs then the waiting window the rolling window that we wait to aggregate the proof to advertise the cost will be much shorter so if let's say a application were a VM themsel or even the pro Network themselves they want to build an aggregation layer thems and I think that's totally fair but they might have to wait let's say an hour for 50 proofs but if you use a third party credibly neutral Pro aggreg proof

aggregation then you will only have to wait let's say 10 minutes or 5 minutes and then you get the same cost reduction and that's essentially how we find the value prop will be very appealing for users so what I'm hearing is you're not actually using the shared settlement layer term but when I read that I was kind of curious if you positioned this in any way like towards the AG layer or you know at first maybe I thought it had something to do with like shared sequencers but I it sounds like it's pretty far away from shared sequencers but in in the case of the AG layer and that sort of aggregation that they're talking about over like mostly in the polygon ecosystem but I know they they have a vision for this in a bigger way they talk about settlement and yeah I'm just curious and and sort of what we

talked about before where you're like deployed on various l2s and an L1 and you're you've kind of hinted that you might think of talking to each of these deployments yeah is there any sort of connection then to something like the Ager yes I think we're a lot more similar to Ager than comparing to align layer or highly okay it just that we're taking a more ecosystem agnostic approach for that I think schumo and the team probably have the idea about being proove aggregation around the same time last year and I I think it's that you know the fact that people are all building in this space is extra validation that it's kind of the direction that we see will make zkp accessible for end user and then eventually we'll have a killer app

that's ZK enabled yeah I think uh one addition to that is that the both us and a are still in the very early stage of the protocol development and U take a look at agay do documentation um it's pretty high level so take what I said as a grant of thought so my understanding right now is so to solve this Ro up interoperability problem you need many things you need proof aggregation proof aggregation is the most important uh technical piece in this in this puzzle but you need many many many things else for example you want to have a fast finity you need

something um like I'm not sure you cover this Anna but Justin Drake was keep talking about this pre-confirmation right so you to get a fast fast finan you need pre-confirmation and also it's a very huge design space I think both us and EG is just like a scratching the surface many many interesting problems uh to be solved I can name a few first how do how do even Define cross R transactions yeah we know how to define a transactions in a single Rob like what even is the right definition of the Cross Rob transaction that's the first question and at the moment it's just like it feels like bridging all the time exactly but I think bridge is the wrong

abstraction um I did a talk at the DBA research Day called bridges are a scam I think people need to think about the things from like a first principle in order to solve the question it's really not about hey uh egir versus nebra is all about can we actually having solve the interoperability problem for the ethereum rops I think I I want to put a like a more like higher level view of this to everyone maybe that's that's helpful right I think for ethereum it's very important to have a raw Centric road map it's it's very different because ethereum want to keep it L1 truly decentralized it's not a

performance optimize L1 in that case Rob up is very important but think about if we have all these robs but this Rob doesn't have interoperability then it's becoming kind of separate Kingdom that's fine but if you think about in the longer term then that will that will have a winner takeoff situation that's actually not healthy for the entire uh ethereum ecosystem basically these Rob ecosystem cannot share Network effect among each others and I think both us and of course agir is doing um is we're trying to designing innovative solutions to help robs interop with each other I think I

will get back to e on that but uh he has a beautiful analogy is that maybe in the future every home will run a Rob every coffee shop will run up right in that case we definitely need more interop probabilities uh in that regard so the original quote was actually from Bill Gates cuz uh they mentioned when they started Microsoft a couple decades ago they talked about a computer on every desk and in every home and then I joke to shimo about we need a ZK rollup on every desk and in every home and and every phone and every phone every like clients the idea here is that we want to lower the barrier of entry for building a ZK rollup our thesis is that once ZK

rollup have a stack that's performance and reach feature parody with OP stack we will have a lot more use cases for them and then a lot more consumer apps that haven't thought about building a rollup themselves once they reach adoption once they have enough volume enough traffic using their application they will consider building their own rollup and then it will be a ZK rollup or a ZK enable rollup or maybe in the future we just call it a rollup cuz um we don't talk about I'm building an internet startup now it's just I'm building a startup and then so I think that's kind of how we envision ZK will be a very fundamental underlying infrastructure that you no longer will talk about it right now we treat ZK as a separate sector but in reality it would

just be an element that's useful for people to do a lot more offchain compute to be able to prove something that has happened to be able to uh have native interoperability between rollup like it's a huge design space and have very different attack angle that's building by a lot of the innovator in the space I I'm still a bit confused on the how you go from the aggregation of proofs into what I've understood AG is kind of proposing which was a little bit more like settlements and movements maybe not movements around the chains but even how you described it schumo where like you'd build an application that's actually interacting with two or more rollups at the same time and like a transaction between those rollups is

actually happening how do you go from just proof aggregation which to me is sort of like there's all this proofing going on then you do an operation and then you write it to chain how do you go from that to like actually interacting between the different rollups that's the right time to to share a little bit more where are building next we previously call it a shared statement layer now we are calling it a nee OS which OS stand for you can view it as operating system or you can view it open stack so the whole idea here is that if you look at how can you make robs interoperable our definition is you need to have cross rup transactions and this cross rup

transactions need to be the first class citizen it need to be as safe as possible and how can you make a cross rup transaction as safe as possible possible you have to make the transaction sadle at the same time as normal transactions and then getting back to how does a rops transaction settle so a Roop transaction settle when the validity proof assuming it's a ZK proof uh ZK Rob then a Rob transaction setle when it's validity proof is verified by ethereum layer one by the L1 you wouldn't you wouldn't say it's when the sequencer puts it in the sequence I mean this opens a cans of warm here

about all the semantics the pr and cons of Z and optimistic Rob let's put it simple right so uh sequencer put it it's a soft guarantee and uh if you want to settle a huge amount of asset I think the way the better way is to having much safer guarantee which is the final right chain okay the the final gring to to the chain and also as a coordination layer on top of ethereum but below all the ZK rups right so basically we want to enforce the safety guarantee of the Cross Rob transactions so in my view at least the only meaningful way to of

enforcing that is that together with all the validity proofs coming from different robs we want to have safety proofs cross Rob uh transactions together we basically aggregate all this proof into a same proof and a uh settle on ethereum I'm actually not sure this is how aair is doing this but in our view this is sort of the the most unopinionated way of doing this because we are using layer One Security to ensure the safety of the Cross Rob transactions and uh also you bring up share sequencer and I think that's great angle as well so you can think of a

share sequencer as a way of enforcing this Atomic composability at much early stage and we're enforcing this cross RW up transaction at much later stage I think that's more unopinionated and more give more flexibility and sov sovereignty to the robs so in the sense that uh robs doesn't have to use a share sequencer they were happy happy for them to use a share sequencer if they want to but they don't have to to all they need to do is that the Rob give a give some guarantees or give sign some uh confirmations about hey I'm going to put this cross Rob transaction in the next batch so in this

way you can think of um it's give them more sovereignty which I generally think is good thing uh you may know the cosmos CIS right and also in practice right that's also getting from where I used to work uh with Mana I know the RO up sequencing is one of their most important Revenue source for all the rups yeah so I think share sequencing is the idea is great but if you want to convince other rups to actually get into share sequencing uh it's kind of a uphill battle and uh to put a interesting NY it's somewh somewhat similar to Central planning economics and the free market oh wow in our view

um we should facilitate the free market approach and building the infrastructure to net people forming this free market instead of we have a a sort of a centralized planner for these uh cross Rob transactions yeah I think to some extent we think that like by adopting this approach we allow the Integrity of the sovereignty uh that each rollup might want to maintain and I think uh our general approach is want to be like we want to cohabitate with existing uh infrast structure and people's design choices so in the sense that the reason we're not double into the disin Prov Market is because we think that is a very important part for a ZK VM to own

and that is the meaty part of their supply chain and they were more focused on The Last Mile verification and then here in the building uh into building a open stack for ZK rollups we believe that sequencing is a lot of the MAV retention that each rollup might want to maintain and then our approach is more focus on offering native interoperability and potentially economical bridge to make the user experience and developer experience a lot more seamless by this open stack though are you also thinking about it a little bit like as like ZK stack or op stack would people use your stack to fully deploy endtoend a rollup or is it more like there's a piece that they

would take from the nebra OS and then add it to one of those deployments um it's still in a very early stage oh yes true true I so I think there are two things first it is a entire stack people can deploy their app Chan or ZK Rob however you call it the big problem we're solving here is that by this integrated stack people can really just click a few buttons to deploy a new ZK drw up we are kind of half there but not really uh the problem right now here if you are talking about people who are building app chain is that yes they can use Cadera conduit out layer to do so but they need to have a lot of uh sort

of a business development negotiation with chin link with peace with all these oracles and also they need to have a lot of business negotiation with all the bridges like layer zero across Etc right so I think one of the benefit of using uh nebra OS is that they don't have to do so they can truly do oneclick deployment and even in the future permissionless deployment of the ZK drops and secondly what's our relationship with OP stack uh ZK stack and uh polygon agair I do think we actually want to collaborating with them and also make ourself interoperable with

them so like like I said before we're in this earning exploration space of to figure out the design space of how does the cross Rob transactions can work I think everyone is just like scratching the surface right now yeah um we definitely want to be first I think open means two things to us first is open source so the pure stack will be open source from day one and second be open to collaborate and uh interoperable which means we well actively seeking collabor operations and cross stack interop probabilities between us and other Stacks cool I think these are um these are where we are coming from and

uh also I don't view this as a zero sum game so I think we want to fulfill e Vision which is put a raw up in a single desk if you think about that we're only like a in the one% not even of the of the progress part yeah Fair um I want to bring it back to you have today so kind of bringing it back to the UPA 2 version two can developers already use that upav 1 people can already use that upav 2 we have a working prototype in house and people probably can use that after one or two months which is not too long and we have some uh initial uh very close users that already trying that we also

just want to say the upav V1 and upav V2 have the exact same interface okay for example you can just try to build a very small circum circuit to try it today cool I'm recording this it's the first episode I'm recording after wrapping up ZK hack crao our IRL hackathon do you think that like hackers building applications should already be experimenting with this stuff or you think yeah okay yeah so we would love to see if we can come to more ZK hacker houses and to help them so I can tell you one thing I'm really really happy about so we are working working with a partner uh called project Galaxy we just throw our developer Dock and Z they didn't get get back to us in one week I

like are they still interesting using us then just one week boom they already integrate nebra upav V1 in their s right no question ask and I think that's make me super happy which means our developer documentation is actually good enough and people just like no question ask and did the integration interesting to say a little bit about that NE up has a very simple developer interface basically three step as a ZK developer register your verification key change your proof verification contract to nebra and change your application logic to subscribing to nebra UPA event then that's it so uh we try to be Plug

and Play to all the ZK applications and would love to support uh ZK hacker houses in the future so that's for the sort of first part this was the UPA V1 and the UPA V2 what is your timeline for the nebra OS we don't really have a timeline right now and uh uh I think we probably want to first get a good design and ask as many people as possible to say Hey how do you how do you view about the design and then we can have a more concrete timeline here I think in my view to getting the design right and building something that is Meaningful for for people to use is more important to sort of a rushing to have have

something people can use yeah yeah yeah yeah and then I think one last bit of like call call of action is that uh not only are we excited about like going to more hacker houses and support more hackers I think there are specific design space we're actively exploring so aside from the all the amazing infa partners that we have we're also looking into specific consumer applications uh space where it could be in the defi space where there are private smart contract there are decentralized voting there are different kind of scaling solution private transaction and even um partial kyc and then um also in know social application where it's you know

in person attestation there is badging system passport and for people to have PVP interaction online and and offline or I guess onchain and offchain and then be able to utilize that I think these are all the things that were actively kind of expanding the the scope and the utility function to allow all their application not to be ZK first but be be ZK integrated and then that's how UPA could be the backend for components that you don't want to touch nice cool well thank you both of you for coming on the show and sharing with us the story of nebra kind of the work that you were doing early on how that's evolved and where you're going thanks so much thanks

for having us thanks not andna it's a great pleasure to be here as always all right and I want to say thank you to the podcast team Rachel Henrik and Tanya and to our listeners thanks for listening