ZKV Presents... zkEvmos: Bridges & Interoperability [Audio Fixed!]

Transcript

um works here for vtxmos uh an event where we're going to be talking about bridges and interoperability in Atmos context is a topic that I think is becoming extremely relevant and using ZK in bridges and interoperability is sort of the the thing that we wanted to cover today this is brought to you by the ZK validator where you've been around since 2019 we're validators on a number of networks including a number of Cosmos networks I think I have a slide about that no and what we do is we we often like we will either be working with projects or networks that have ZK built in or we work with networks where we think that

we could potentially bring something to the table we can introduce them to ZK Concepts we can start building communities to start thinking about that and seeding that kind of development as I was just mentioning we are already on four different kind of Cosmos ecosystem networks we started on the cosmos Hub osmosis of most we're also on some other networks including a few on polka dot and near Mina cello we are also on a lot of test Nets so you might see us around there as well I want to share a little bit about you know who we are what we do so yeah we're we're here to sort of like I

said we're working with a lot of networks that either have ZK built in baked in or we're actually bringing that and the way that we do it is we become advocates for privacy on those networks as well as EK Tech we participate in governance we support emerging teams through either introductions or sometimes as well through funding and then we launch initiatives to promote and fund ZK Tech this is our team and oh and we're actually missing someone we're missing Pierre I just realized and we also are hiring so if you're like interested in kind of what we're doing and you think you have something to share we are looking for specific roles usually people in the UK but if you are interested anyway I think we're always

happy to hear from you um yeah ignishka do you want to share a little bit about the goals of this event of course uh obviously we want to introduce ourselves to them a wider Atmos Community but we also want to hear from you we want to hear about your knees your interest in ZK uh space so if you have anything that you you would like us to um discuss further maybe in the next sessions just put it in the chat of course we want to explore the topics of interoperability and ZK in a cross-chain context so this is what we're going to discuss today uh hear about new projects building these Technologies I'm pretty

sure we're as excited as you are guys just to listen and and learn about all those new projects and Technologies and we want to identify where we are um what are the opportunities for ZK in fmos so this is the goals for the event today and our schedule we are bringing really really exciting projects for you today so this is then the schedule for today our introduction so this is what we're doing with Anna at the moment we're going to start with election Labs put garvet goel who is already I see ready for his session after that we're gonna

jump to Yale University uh after that we're going to have no foundation with Mika komarov who is a founder of the Nell foundation and we're gonna finish with a big boom with Fireside with Nixie from Evan we're gonna Grill them a little bit I saw the questions and they're really really good so stay with us on the end and of course at the end we're gonna have a wrap up and also we'll try to answer all your questions during the the event so on the under the sessions you see q a this is where I'm gonna pull out all the questions that you have one thing that we didn't mention on the presentation and I think it's very

important to say as well please do not um click the blue button share audio video this is only reserved for the speakers so if you're gonna share it unfortunately you're gonna be rejected so that's for everything for today the next slide oh I can't hear you Anna nothing you muted I just want to say one more thing about the interface because I know a few new people have arrived if you're not familiar with hoppin there's two chats there's an event chat and a sessions chat so for this session try to chat in the sessions chat otherwise you're sort of chatting in reception sort of a funny little Nuance of hopping all right I'm going to share a little

bit about some other initiatives that we have going on um so ZK validator kind of co-created along with the ZK podcast something that I host we co-created something called the ZK hack it's an event series as well as there's whiteboard sessions and it's kind of like a community of VK Learners so if you're here more on the ZK front be sure to join ZK hack actually maybe we can dig up a link to that um at some point in the next few minutes so we can share just sort of how to get into the ZK hack Discord um and yeah this is a place where like if you're actually interested in learning about what you know how ZK works this is a really good place to start we're actually spinning this out

into a new org um and there is an event that I just want to mention that starts on November 22nd we actually do a multi-week DK workshop and puzzle hacking competition it lasts for four weeks there's a ton of workshops and sessions and some really good way to get yourself onboarded if that's what you're interested in another thing that zkv has championed and done is this open legal report so we've brought together a number of lawyers and team like product people and Founders who work in the space in ZK specifically in order to understand what the challenges are around working with CK and privacy Tech obviously this summer we learned through the tornado cache uh sanctions that like there is some work

that needs to be done and there's some understanding that needs to be had by all these teams in order to like better operate we also do another thing and that's early stage funding and funding support so we actually co-ran the get coin a recent git coin ZK Tech side round with CRX Park and um we also do invest ourselves into ZK projects so I just wanted to highlight that it's something a lot of people may might not know about CK validator all right the support for this event actually comes from the cosmos Hub we over a year ago had a grant to do a number of events for Cosmos we actually satisfied the grant but had a little bit of extra funding and we decided to do another event focused on the cosmos

ecosystem in this case we decided to focus in on evmos so thank you this I mean it's just a little little leftover bits to fund it but I'm really glad that we that we had that funding so it's nice oh um the media partner is my podcast and the videos for this will be on the ZK podcast YouTube channel afterwards so there's usually a zkv presents playlist and that's where we put events like this things to look out for just a reminder DK hack runs from November 22nd till December 13th so do check that out it's the hack3 and also we have this amazing Cosmos newsletter and I don't know if

everyone here has signed up for it but I think we're at like issues 50 or 60 at this point but in it it's sort of like a really short summary of The goings-on in the previous week and it's very very useful if you want to just stay up to date it's not just the Hub it's really looking at all Cosmos ecosystems ethmus is often featured in it so yeah do check that out and I think agnesia if you want to take it from here yes so this is where you can find us as well you can follow us on Twitter if you have any questions or any suggestions about the events this is our um event um email and I think we're gonna start so I would like to

um introduce to this stage gavit goal from electron labs see you later [Music] okay garbage you should be joining soon hello so the stage is you yeah thanks Lord just a second uh let me just start a presentation uh uh I hope everyone can see my screen uh just a second yeah I think so I'll just

get started Yeah so basically uh as Anna just introduced that uh ZK IBC and basically ZK based power bridging is becoming pretty interesting uh so we are the company that uh if you guys recently saw on Twitter we talked about ZK IBC and how we can basically use zero knowledge proofs uh to bring IBC to ethereum uh and yeah we are the company behind building this so just to get started uh like there are two parts to my presentation here uh so first I just wanna talk about a bit about the vision and what the problem statement really is that we're trying to solve and after that I'll get into the technicalities of of the kind of solution we offer and towards the end I'll just discuss a bit uh what is our roadmap and how basically evmos and other Cosmos app chains uh can

integrate this uh and start using it uh yeah so just to uh okay so just to get started Yeah so basically like uh if we talk about like the reason why zq building is important so like we've seen with ftt recently and in the past also uh you know at the onset of this beer market we saw several companies that were centralized D5 players uh go down as a result of being centralized uh the idea is that in the long run only those products survive that are truly decentralized and in case of bridging right now uh existing bridges that we have uh are highly highly centralized in custodial so the future we believe is that we should

really have non-custodial like clients now the problem is that the reason why we don't have non-custodial like lines today is because like if you talk about the most popular blockchain like for example ethereum then running these uh you know in order to achieve uh decentralized uh bridging you essentially need to verify the consensus of one blockchain on the other one and if you do that on ethereum today the transactions will cost you you know at least thousand dollars per transaction and it can go up to ten thousand dollars per transaction so this is clearly not feasible right and this is the problem essentially that we're trying to solve that if you do uh decentralized bridging today it's going to be way too expensive uh right and if

you specifically talk about the cosmos to each ecosystem it's it's uh you know the because of the lack of ed25519 pre-compiles this is a problem that exists so the solution that we have proposed for this uh is we use the compression property provided by zero knowledge proofs in our case we use snarks where we can basically take a batch of validator signatures and create a ZK proof of that uh and that basically allows us to achieve 100x2000 X scalability in terms of the amount of computation that you will have to run on the ethereum blockchain so that basically brings us in the feasible realm and allows us to conduct uh cross chain transactions powered by IBC uh for just five dollars today so that's

broadly the reason why ZK bridging is is becoming so important and is basically the future uh it basically makes Lifeline bridging feasible uh so just to just to give a bit more context uh as to how this technology integrates quite seamlessly into existing based technology if we talk about IBC for example uh the actually the process is quite straightforward uh you can say like all all IPC and Litecoin which is basically have this on-chain module where they have uh the concept of this light client uh which is running on chain we simply swap that out remove the part which is actually doing a signature verification and add the part where uh we are we are just basically verifying the proof itself and

nothing changes on the front end nothing changes at the interface level so all existing applications just run the way they were running so for example all your IBC modules such as interchange accounts interchange queries they're all compatible from day one uh on top of ckibc uh so I think that's that's quite quite an exciting feature that you can retain the model but still upgrade the security model uh just to go a bit deeper into our solution at this point uh so basically zkibc like it's not like that it's a you know it's a it's a perfect solution uh zero knowledge proofs come with their own performance penalties uh and right now they do introduce an additional cost and time uh of 3.6 minutes and five dollars uh to the bridge transactions uh

while these are uh not you know not desirable they're also definitely uh you know they're not too bad that you one can actually use these Bridges today uh having said that we would like to definitely reduce them over time uh and and get the latency down to a couple of seconds and basically get the transaction cost overhead to virtually zero uh and that's sort of our goal going forward also to improve the performance of the bridge in terms of the latency and the transaction cost uh so basically we are using two approaches to achieve this uh the first one is uh in fact uh one of the we are actually talks with multiple Hardware companies today uh to understand how we can use specialized Hardware such as

fpgas and Asics uh to really achieve and I think the initial numbers that we've been uh we believe are possible are 5 to 10x reduction in fact I think we were just today itself talking to one of the speakers uh that that represent uh uh going forward uh in in in this in this session today uh another approach that we're taking is use of recursive proofs uh so the question has this Grace property that allows you to combine uh multiple different proofs into a single into a single proof so basically imagine that all the different headers coming from all the Cosmos app chains in the ecosystem uh could be all reduced down to a single proof so one would be submitting one single snap proof on

ethereum for the entire Cosmos ecosystem and over time even for other blockchains also so basically the idea is that uh you know you are able to achieve this uh sort of this header aggregation or the way I like to call it basically Network effects that as more and more uh chains join this network uh the transaction cost on a per transaction basis will continue to go down and basically the transaction overhead of the ZK proof will become virtually zero and this will basically allow us to achieve a bridge performance that is at par with custodial and centralized Bridges and basically at that point there will be no reason to use a centralized Bridge because you get the same performance uh in terms of transaction cost and latency

while having much higher levels of security so we believe that recursive flows will really enable that kind of future to be realized uh yeah I think I just want to talk uh about the roadmap here so I think most people right now uh think that uh zika bridges are probably a year away or several months away uh but I just want to say here that we uh we are looking at internal timelines in in terms of number of weeks uh so this is coming quite soon uh not not that far out and in fact we already published some of the numbers uh when we posted our our initial proposal on each research uh so in fact if you're an app chain uh you can actually reach out to us and we'll start shipping the

integration docs quite soon uh and uh just to talk about some some interesting angle here uh so like what is the purpose of shipping ckibc and where does it go from here so I think uh Cosmos ecosystem has a whole uh can benefit significantly for example if you talk about the concept of interchange security uh that is becoming really interesting in terms of producer chains and consumer chains and mesh security I think once IBC is connected to ethereum even ethereum can start providing uh its security to various app chains uh I think that's one of the very interesting research areas uh that could become that could become important in future secondly I think over time as the number of app chains grow in the cosmos

ecosystem the transaction overhead of verifying these IBC connections could basically significantly increase and start occupying a large amount of the block space uh uh in intending blockchains and at that point to basically enable point-to-point bridging uh you will need ZK proofs to really compress down to all those connections and and and submit them on chain uh uh so at this point I just want to talk a bit about our team so we are a team comprising of people who have strong experience in across web 2 and reply domains uh have sort of strong experience in shipping great products and working in deep technology and uh yeah are very well positioned to basically bring this product to Market uh yeah and I think finally the most

important I I consider this the most important slide as I said uh this is actually coming much sooner and in a couple of weeks and uh anyone any any Cosmos option that is looking to use this can reach out to us today uh and uh we can start the integration process very soon yeah that's all from my side yeah thank you thank you very much garbage for your presentation I'm pretty sure it was as exciting as uh for everybody else's for me so thank you very much and the next presentation um inviting to this stage fund and I will talk about ziki purchase so fun you should be able to join now

thank you yes we hear you well so please start your presentation okay let me um okay can you uh can you guys see the okay can you see the screen I'm assuming uh you can [Music]

um all right well thanks a lot for having me um so I will take this 10 minutes to briefly introduce the recent project um done by a collaboration of uh of people from Berkeley from uh and Stanford and Texas and Yale and the qinghua university uh this project is called the ZK Bridge um we uh through ziki Bridge we want to make trustless question Bridges uh more practical so um I think the previous talk set up the stage well so I guess I can just jump right in

um the core functionality of of a of a bridge is pretty simple right it allows a smart contract uh on you know a chain two to access the state of the different gen of shn1 right the API can be as simple as uh just uh like that you'll get the state at the particular address at a particular height um the the concept of bridge is related to the notion of light clients State proofs cross-chain uh swaps Etc but uh bridge is different in that it requires a a set of a different set of properties right we want the bridge to be generic and to be Universal in that it should

support uh many different applications and it should be efficient to to operate the unchain and uh with particularly crucial for infrastructure like a bridge uh we we should um we should minimize the trust in that we should not uh we should try our best to not try put the extra Trust on the operator or um yeah um or uh on a community or uh basically to avoid the extra trust as much as possible to achieve all these properties at the same time seems uh seems challenging right existing Bridges can be roughly

divided into two categories um you know generally one approach is to introduce a intermediary uh to to facilitate the bridge such as a side chain or a committee or some other uh architecture this approach typically enjoys very efficient very very efficient unction verification typically the receiver chain only you need to verify a rather simple cryptographic evidence such as a multi-seed the downside however is they introduce that's where trust in this intermediaries either in the form of some threshold assumption or you know assuming certain parties have these

independent interest um well the second approach is to try to get rid of the intermediary by running a light client protocol directly on chin right uh like the previous talks um introduced as well uh the idea is to run the let client verifier unction but uh of course the downside of this well the upside is the now the proverb uh the proverb in the Lite client protocol is only trusted for live news they they are not trusted for security they are only there to provide the proofs um which is only needed for live news but as a previous talk also mentioned

the cost of running light client protocols option directly is quite prohibitive because like client Protocols are typically designed for option parties um I I can uh one example in this category of solution is uh nears uh Rainbow Bridge for example uh they have a light client protocol implementation as a smart contract but um in order to um avoid the expensive unction verification they had to introduce a watchdog service um to make this uh somewhat a optimistic uh protocol um so it seems like neither trade-off seems to be very desirable we want both trust

and minimization and efficient auction verification so can we achieve both um with dkp yes we we can zqp is a Ideal tool that uh that achieves uh both properties we desire with zero knowledge proofs we can replace Unchained replace honest assumptions with cryptographic Assurance right we can ask the committee ask the sidechain or um however you call it to generate a proof instead of trusting instead of trusting in their uh honesty right and they're not proofs typically are efficient to verify unction right they're um

and and the verification can be uh even independent in verification costs can be even independent of the option computation so you can verify a lot of computation in a very short and concise proof this is how the high level uh architecture of ZK Bridge it generally follows the light client approach um so we run a lifetime verifier uh contract called a updater contractor um a contract on the receiver chain however instead of directly running the like client protocol the verifier contract only checks the proof right generated by untrusted approver

so the proof essentially proved that the chain has advanced from a previous state HT to a new header HT plus one the exact statement of this proof Pi is closely related to the consensus protocol but but for for many proof of stake blockchain it looks like a statement that there's enough signatures on this new Header by a committee that that's identified in the old header HT and this architecture also allows the developers of applications to um to work with the the chain in a more modular

fashion and that's the chain at the the bridge provides a simple and unified interface which is the updater contract and the application developers can build a more complicated application Level proofs on top of this um using using the modular uh design so the the advantage of this architecture as I have mentioned is uh this kind of achieves both minimize the trust and the efficient function verification right purpose build snarks is far more efficient than directly running the light client and it's permissionless and the decentralized by Design because proofers are not trusted so anyone can

join as a proverb and it's extensible and Universal as I said developers can develop their own applications on top but so far I have been uh avoiding one unpleasant juice that is uh snarks are generally very expensive to generate all right and to make things worse blockchain Protocols are not designed to be exactly ZT friendly in that they're not designed to to to uh to be proven uh using their knowledge proof right for for example uh common digital signatures like eddsa is actually quite expensive to express as a zero knowledge approved circuit

um so as a result because State transition usually involves hundreds of signatures for verification even simple tasks like proving um verifying all the signatures in a particular blog header it can be extremely can be prohibitively expensive you if you compute the proof naively so our core technical contribution in the recent paper is we came up with a series of ideas that make this proof generation time to reduce the proof generation time significantly and to make the the cape rage architecture uh practical so one of the core idea is a new uh Stark

protocol uh called the d-word goal this is a distributed version of the Virgo zero knowledge approval protocol the speed up stems from the fact that we there is a lot of data parallelism in the circuit that verifies uh signatures for a block header right basically divergold takes makes a use of parallel machines to speed up execution and it enjoins what we call Optimal parallelization for example if you deploy 100 machines to compute the Virgo proof you essentially get a 100 at 100 times speed up

um so the scale is perfectly linearly with the number of machines uh this is quite optimal also we further reduce the proof size and the verification caused by a recursive proof right we've we run the verbal verifier in Cross 16 and only post the gross 16 uh proof uh action another idea that can further reduce the cost is by batching verifying multiple headers in in one book so to show this uh rhetorically the Virgo has very fast the proof generation but it generates relatively large uh proof in relatively speaking cross 16

like protocol is slightly slow is slower but it has constant proof and the verification but um by combining two we cannot get the best of both worlds we can get a constant size proof and verification with only a slightly increased uh proper time so in the interest of time I will I will invite you to check out the performance numbers in the proof I for for with this slice I I just want to show you the with just a little bit more on five seconds more in proof generation we can reduce the proof size by several orders of magnitude so use the uh verification cost um so I will uh basically uh wrap up

here um so ZK bridge is um is this um trustless Bridge with uh snarks and uh to learn more uh please go to our website where you can find the paper and and the contact information for all of the authors and we are uh you know more than happy to talk with all of you about uh uh what to do next because the technology is this is merely the beginning uh we have we have the uh the protocol but there's a lot more to be done to make this you know to to deploy the system to make it really um a ecosystem open decentralized ecosystems based on the technology

there's a lot more to be done we're more than happy to chat with everyone who is interested uh sorry I'm running a little bit uh over time but uh I will stop you uh thank you very much fun again for a very very interesting presentation I'm very happy that we're super uh on time so the next presentation I want to enter introduce on the stage Michael komarov from Nielsen foundation and he's gonna show us the data proof tool chain for bridging and scaling so Mikhail I hope you're you can join us now yes hello hello yeah hey yeah um okay let's just I don't know

it's not okay it's not really a podcast if we don't bump each other with questions but simply do presentations but Let's do let's do let's do whatever we have okay I'll wait till you start presenting yes everything should work so the stage is yours yeah well uh basically uh trustless Bridges or how they are being called right now ZK Bridges um what's that about right what what's like what what what this was started with this was started with well effectively this was started back in the beginning of 2021 uh this whole thing with trustless Bridges with State proof Breeze bridging uh it was a mutual effort of uh it was a mutual effort of

uh initially us uh I mean the foundation each foundation and as long as the nation Falls um we spent kind of a year hyping this up doing these things with uh again with I mean the trustless bridge well they call it ZK bridge now but anyway okay whatever works for you um with solanus ZK Bridge how they called it this way and basically uh what I'm going to talk about today today is um well first of all I'm kind of very where I'm I'm very excited this has become a thing very excited to see that people are actually building other state proofs for the sake of as they call it

ZK bridging even the project came up with the name ZK Bridge it's it's more than exciting and I thought that would became a thing but anyway it became anything it's a good it's good I mean I'm really glad so um what I'm going to talk about today is uh about our about our issues we faced uh during building that state roofs why it didn't work out that easy why it took you know so much time what we learned and what we're ready to help with what we would be happy to help with to any other team building State groups building ZK Bridge Building Decay data transfer or whatever data accessibility solution okay that's

what basically we have it is building here so basically anyone's building ZK data access to build a solution is well what we are ready to help with but we're ready to facilitate with what were our mistakes what was our experience um basically okay trussell's data accessibility uh what the hell is this what am I talking about right uh well it's quite a widespread notion that there is such thing as data availability data availability usually supposes that we're talking about uh you know provable read-only data that approve that somewhere a data is available to be read data accessibility is supposed to represent is supposed to be

um is supposed to be an ocean for uh read and write it's basically not only a proof that some data is available somewhere for reading but also a proof that some data was well basically uh written in some product into some protocol um what about the state accessibility well what about the status stability it includes as one of the use cases ZK bridging as well so uh what does it need well first of all it needs various particles data um we on our side facilitated that with our dbms basically it's like makes the data

available the data of the data of a various cluster available via Unified interface just like you would have done with the regular dbms like with SQL alike in the basement sample you know so that's pretty much the same and also uh what the what such date accessibility needs it needs well first of all stay proofs for data sampling like Google approves the read part which is about like data availability right and it needs also State proofs for data insertion like DK bridging thing a right part and well an example of such a DK bridge in like the first DK Bridge ever is basically well yeah it's it's like an example it was like it was the minaith

thing uh or media TVM thing uh so it's it's basically if you're about to verify that with evmos or any other evm compatible protocol application protocol you're good to go so it's like everything which comes out of a everything which comes out out of our thing is compatible with is is is is compatible with ebm so yeah the mechanism is pretty simple you get uh so it's like you get the commit log of a cluster you target it can be not not only it can be also like Solana it can be easy it can be like whatever whatever works it can be Cosmos it could be it could be any IBC project with help of Electro Labs folks if

if they desired help yeah it can be any protocol you basically get the commit lock from it uh you put it together into a single proof like small short description of the whole commit lock of a cluster of a whole commit lock of a protocol we're trying to bridge this somewhere uh we're processing that we're generating this proper State proof and then well if we need it somewhere then we submitted to a particular cluster we're bridging that to eth uh whatever EDM compatible evmos works as well uh so as we noticed um it all goes down to State proofs so State proofs is the most complicated

part well data source is complicated part as well but well State proofs are the most complicated part right now because well first of all uh guys design and state proofs is hard I mean it took us eight months to design a media State proof circuit design it took us eight months more to design Solana State proof circuit design and um what I'm talking about these timings I'm not only talking about I'm not only talking about like you know just a circuit design with circum or something it required a custom proof system uh will come to why State proofs actually require custom proof system and why for example like circom or any other approach well it simply doesn't it

simply doesn't cut it to be honest uh well from my experience Maybe Maybe I'm Wrong maybe I'm wrong but it simply doesn't got it second the second thing uh is yes well State proofs they prove the whole product will commit log um it's actually a lot of computations I mean if we're talking about the actual the proper State proof uh secure version of such one with a properly designed one uh it means uh really a lot of computation for example from our experience Mina State proof took I don't even know how to pronounce this number I mean I just calculated it with python I just put it into um it's not a random number it's basically uh two pow 34 that's what it is and I don't

even know how to pronounce this number this amount of multi-scale multiplications and um guess what this thing has to be verifiable with the VM yeah I mean it has to fit uh the proper amount of gas or force or for example like Solana State proof so long stay proof it actually requires verifying uh 4 000 etdsa over ed25 519 signatures it is well as folks have already mentioned very unfriendly to very unfriendly to proof system it's a signature scheme which is very friendly which is very unfriendly to be expressed as a circle within the proof system so basically

it talks it takes a lot of computations the problem we faced with this is well first of all let's say this way um if we're talking about it's like there's always uh there's always um there's always a choice between security and um you know and very verification and verification cost right so if we're talking about like the absolute security like trustlessness at it at its at its best uh we're talking about soundproof system which doesn't require trusted setup so we can't use growth we can't use kzg we can't use anything which requires trusted setup um because well basically like nobody wants

this to become a broken ZK Bridge Okay so yeah um so this has to be a proof system which uh doesn't have a trusted setup that's the first thing uh second thing it has to have it has to produce a circuit which is as close to which is as close to be theoretically packed uh you know with with the most density you can with the most density you can you can achieve uh so it could be possible to verify that on EDM well in the cheapest way so this required us to build a specific proof system for proving a lot of computations

to EDM um well so basically in this case fit this thing as long as case fit the stink uh well just in case I mean a produced I mean it's like meeting requires uh this amount of multi-scalled multiplications to be proved every every 15 minutes soon it will be more Salon requires this amount of Etc signatures to be proved every I don't know less than a second yeah well of course it goes down to batch and of course it goes down to recursive proofs but anyway recourse of proofs has to be done with a proof system which doesn't require trust the setup as well um well yeah this made us uh this made us to design a proof system with the blankish organization over hash

based commitment scheme which disable which which removed trusted setup uh with adjustments to the arithmetization which made the verification as cheap as possible well it's pretty close to theoretical limit to be honest uh it's called so what so what have we achieved uh what were we what have we done what uh we hope will help uh those who desire to prove a lot of computations to EDM uh or to or you know to Simply prove a lot of computations uh what we hope will help them what we designed is basically Ezekiel will be I'm thinking it's well hello VM it's a usual compiler we all love uh but it's it's capable of generating provable

code from CPT from rust from whatever llvm front end out there so that's basically it generates so so that's that's basically what we resulted with have to build in two or like three state proofs and uh reporting our state proofs and uh we're reporting our state proofs to that and well we're going to use it ourselves and I encourage everyone who builds State proofs as well to Port Theirs to this as well well because first of all no trusted setup long kiss alike proof system the cheapest verification on evm would you need more yeah uh then uh basically um what's what's the difference with what's the

difference with the compilers what's the difference with uh provable computation Solutions which are already out there well it's basically not a virtual machine it doesn't contain any virtual machine inside it's just a compiler it just packs the computation inside a circuit as with as with with you know as close to each other as it's possible with the biggest density it's about with the biggest density it is like theoretical with the best density it's possible so uh it's not a virtual machine we don't have a virtual machine and sorry to interrupt you you have one more minute yeah okay that's fine that's fine I mean that's the last slide great and also well we resulted since we understand that state trees are going to

be required to be proven to different clusters not only eth uh not only evl well we introduced verifiers for one like for for slana for paltita because like simply compiling the verifier to the webassembly is not a big problem so building State proof with zklvm means being able to prove it to whatever place you can imagine yourself and yes it does generate verifiers automatically from the circuit definition in CPP invest in whatever you like for EDM well EDM as faults you can use it it falls polygon everyone you can use it it's for you for BPF it's a lot of false here you go [Music] um

I don't it's like it's like it's like um well okay it's mentioned that there are others but there are no others right now I gotta admit so no no there are no others right now so this is what we can this is what we came with this is what we got uh as a result of our you know two-year um working around of our two-year work around State groups we hope this will be helpful to any who to anyone who wants to prove heavy competitions to eat to Solana like who want to build State proof because well yeah you don't have two years to spend we spent we spent two years already four year folks so here we go

thank you thank you very much and please share those links in the chat so we can also okay okay thank you once again and now I would like to invite on the stage once again Anna Rose and Nixie from evmos okay fireside chat interview let's wait for Nick okay the stage is yours guys hello Are You Gonna Be video free I think so I don't know I think my video is working at the moment unfortunately

well then I may do the same that's okay we're gonna it's gonna be a conversation between ZK hack and question mark unless people really unless it's too awkward to watch two voices with no no video um maybe let me know in the chat if you really want one of us to have a video um but I think okay podcast style exactly okay so Nick I wanna I wanna start off I wanna get to know you a little bit and understand what your role is in the fmos community what are you doing what got you interested in this totally totally so I'm uh I'm an evos co-founder uh

alongside uh Akash and Federico um I think you may have spoken to Federico in the past he's certainly been in the cosmo Sphere for a while now and I've known him for a while um I've been in Cosmos since 2017 just as a spectator and when Federico uh mentioned to me last year that he was working on uh bringing etherment to Market um I jumped at the opportunity to join him in in doing that um it's been a long time coming for Cosmos I think like this is like version three of ether Mint or something and so yeah

um yeah we we finally put it out do a lot of people know the history of etherment and the like the sort of change into evmos maybe you can share a little bit about that actually totally totally I mean we could do a whole podcast podcast episode which I think you are dude we are due to do um for this event we're gonna not do the full Deep dive but yeah just maybe sure sure yeah the tldr the tldrsa is so uh ether mint has an idea started off uh about around the same time as uh Cosmo sort of uh the the real work on Cosmos started so after Bucky and and Jay got together like in 2016 uh well they got

together much earlier but you know that formally uh Cosmos lore begins in 2016. um with working off uh later on in 2017 and that's sort of the earliest record I can find of etherman being mentioned um and of course there's that video from 2018 if Chris goes talking about etherment uh version two uh being worked on at that point so that this is 2018. uh later on a company called chainsafe based out of Canada uh tries to yeah yeah they they try to bring ethereum into Market but at the same time uh Cosmos Hub is is launching or you know

Cosmos Hub 4 is launching formally um and I think at the time Federico if I have this right and Federico would really be the voice of authority on this but Federico was Contracting with chainsafe uh and uh and this is sort of the introduction then right right right right and etherman sort of gets gets dropped as a priority in favor of all of the like Cosmos Hub launch stuff that's happening um with uh Stargate and whatnot uh and uh Federico just says hey you know what I can you know we can still do this and build a team around the etherment idea cool so it's it's really coming from that core

I like the the core Cosmos group and research and thought process it was already there on the map and now we get to actually enjoy it which is so cool and use it right right and yeah and so one last thing I think is important to mention here is that uh for a long time I mean evmos just announced it's it's Rays uh this month but for a long time uh etherman project and evmos itself was Grant funded through proposal number 44 of the cosmos Hub making making uh the ethernet launch one of the first uh Grant funded L1 launches I think if I'm not mistaken out there cool cool all right I want to ask a question about

the of most priority list basically or Focus areas rather um the reason for this is obviously I mean this session was very much focused on CK Bridges we are here in a way to also explore just generally what kind of opportunities are there in Atmos 4zk type things but yeah if you were to sort of say what are the three Focus areas that the community right now is looking at and wants to like highlight and I don't know if there's a way to rank them maybe they're equally important but yeah what do you think is most important totally totally so um the reason I brought up the the grants funded Point earlier right before we transitioned to this question was because uh I wanted to sort of highlight

the fact that um avmos is a very very Cosmos oriented project what I mean by that is like it's the cosmos ethos is kind of enshrined in in avmus's development and we as the utmost development core team try uh to stick to that as much as possible in supporting the community and driving the atmos road map forward to that end I think the the priorities that I can talk about um are twofold one are driving use cases on evmos that you can't really see anywhere else in on any other evm chain so there are things that are unique to Cosmos like IVC

um of which Federico was was part of the core team for but but uh Cosmos chains are one of the few if not the only chains that come built in with a light client Bridge compliant interfaces um that support you know things like IVC and interchain accounts etc etc and other sort of IBC based specifications um like forthcoming ICS 721 uh specification which is a specification for interchain nfts essentially and again this would be built over over IBC and so keeping this in mind and thinking about Atmos is positioning in a world that's overly

saturated with evm block space how can we think about differentiating providing a differentiated uh product a different block space for developers to build on top of and to offer unique use cases to their users and thinking about how we can build a use cases are how we can Empower developers to build use cases around the evm smart contract so that's like you know that comes with all the evm tooling that you know and love like Foundry uh solidity Etc but adding in the IBC superpower there to build uh interchain uh applications I think that's Point number one uh to consider

here um but uh what about uh you know supporting interchange use cases for chains that don't have IVC support and I think that's yeah so like ethereum the ethereums the polygons the gnosis chains of the world that don't support IVC out of the box what do we do there how do we connect uh users and assets and developers uh from avmos or from the broader Cosmos ecosystem to those chains and I think that's kind of topical here because that's where I see at least Ezekiel evm come in IBC itself is is trust minimized

and as much as possible we want to avoid uh having trustful bridging between of most and uh the rest of the non-ibc compliant ecosystem yeah if that makes sense yeah so you're saying like you're looking for almost like something as secure or almost as secure as an IBC type setup or system but also but it potentially extending out um so those two so this is like unique to esmos IBC and then these like non-ibc but cryptographic Bridges is there any other areas just since I had asked for three do you have any

other like a third area that's interesting it doesn't necessarily have to be about bridges either it could be about anything totally curious totally so so to complete the the the Trinity so to speak here uh again I I always go back to the fact that evmos is built with the cosmos ethos in mind the reason I came to uh to Ether mint was because I thought Cosmos was really cool not because I thought uh EVMS necessarily were really cool or anything like that not not that there's anything wrong with EVMS but there are there is an unexplored design space uh that I think that is a little under underappreciated with EVMS um and also that ethereum itself the

ethereum core development team is not inclined to explore or to to sort of Branch out towards uh and then you know at no fault of their own I mean they had there's a lot of responsibility in you know developing the various ethereum clients out there um of course vitalik published the roadmap and uh you know ethereum development generally tends to move slowly and carefully and I see that as a place where evmos can sort of stand to innovate um and and try out new things and so like the the third and last sort of point I want to highlight here is building a highly modular and extensible evm so Atmos itself is a proof of concept for

etherment um and this is you know if we talked about a little bit about the history of etherment we might have gone into this but ether mint and evmos are both projects that live in parallel ethernet is built as uh the evm module that slots into evmos got it so evmos is like this live proof of concept of of etherment but there are many other ethernet chains out there that have launched since avmos went live so uh you know for example Kronos is an example of an Ethernet chain uh Kanto is an example of an Ethernet chain kava is an example of a chain uh that did not use ethernet but

later adopted ethernet um okay yeah and this is sort of the power of like building with the cosmos SDK and building uh uh you know a modular with modular uh libraries right on the application layer of an L1 when you see the word when you say the word modular I just want to check this so do you mean modular in the context of like Cosmos SDK modules or do you mean modular in the way that like Celestia talks about it right yeah availability because yeah I mean it's good it's a great word but it does it have like nuance yeah there is a collision there right it is a little overloaded so when when I say Atmos is or the almost core development team is building out uh the

most modular evm out there uh I kind of mean both um okay so in in one respect you can sort of extend uh the evm itself you can send ethernet to do all sorts of things you can extend it to um to add in custom pre-compiles for things like uh uh you know to make things like uh certain kinds of cryptographic signatures easier easier to compute or more less gas intensive um you can extend it with custom pre-compiles to support things like uh calling uh staking and voting functions from the evm itself or IVC transfers

from from the evm itself [Music] um but in addition to that uh what we want to do is we also want to explore uh you know certain Innovations across the modular stack which is I think sort of what Celestia means when they talk about the modular stack which is like how do you replace the uh data availability layer how do you replace sort of like the consensus mechanism that uh that the chain uses and there have been several Explorations here uh from other teams from third-party teams so you may have heard of sevmos which is Celestia plus evmos that I think may have I have not heard of that that's a real name right so this is this is again not not the

atmos team uh that is doing this but a third party team that uh spun out of Celestia I think or was is still internally part of Celestia I'm actually not sure exactly where they're at today in their Journey um but yeah this is something they're exploring in in adapting um the way the way evmos settles uh to use uh Celestia by default as as the d8 layer um in the past we've also had Explorations by uh folks like Georgios from Paradigm uh replacing uh the default Cosmos SDK uh mempool and consensus engine uh you know tenderment

with uh uh narwhal and bull shark um and so like enabling these sorts of like uh Innovations across the stack I think is something that Atmos will be exploring and again of course um what I mentioned earlier uh extending being able to extend the evm lends itself really really nicely to the topic du jour for for this session or for this event um which is ZK Bridges you know thinking about how do we make it easier for ZK Bridges to deploy to evmos and actually slot into the dapps that have been deployed to Atmos to allow them to take advantage of that permissionless connection into chains like ethereum

polygon Etc very cool yeah and I wanted to actually bring it back to the bridge topic as well a little bit like from where you're I mean I think right now everything we've talked about is very Pro lots of bridges we're like lots of connection points and I do Wonder given what we've seen and I know I mean we I think we know that given what we've seen with Bridges this past six months or so um there's been a lot of bugs there's been a lot of hacks it's been really rough on people I think we can say like the difference here is we're talking about cryptographically enabled Bridges we're not talking about economic game Bridges we're not talking about

independent sort of you know um trusted Bridges so that's good but there is always that chance for bugs or you know breakdowns as well so are you worried a little bit about evmos kind of having too many bridges like that you know if there's if it's bridging out and there's IBC and all these things that something could get broken uh yeah good question I think there's always going to be a risk I think when you're dealing with uh bridges that are trustful that rely on on things like multi-cigs um for for you know as a custodial backing

um you know the the risk the the attack surface is just much wider and so like by relying on like client proof uh like client Bridges um or ZK Bridges I think you've minimized the attack surface a little bit um but you can never sort of remove that you'll always need to rely on Bridges and sort of this goes back to like vitalik's whole uh you know like separation of security zones kind of argument when he talks about like uh cross Chain versus multi-chain uh where you know in his opinion um like users will want to stay within you know certain security zones

um they won't want to move across uh security boundaries um whereas I think a lot of like the cosmos ecosystem is built around the idea that things are going to be interchained across chain um and and things will be constantly moving across security boundaries and because obviously atmos's security is much different than for example uh osmosis is security which is much different than ethereum security um and so really our mandate there is like to remove third-party security we don't need an additional uh uh an additional attack surface there like an additional area that can be exploited and this is of course falling in in the footsteps of of the uh Nomad

exploit that happened earlier this year that hit at most um and many other Bridges quite hard oh it did hit you hard I remember this yes although it was still pretty nascent right I think had you just had you kind of recently done that integration yeah so luckily you know liquidity on The Nomad bridge wasn't as entrenched as it it was it wasn't as mature as it was on chains like Moonbeam for example um and so yeah the brunt of of the pain there was felt by uh non-evmos chains but it's still something important to recognize that it happened early on and Atmos is in in

atlas's lifetime and something that we'd want to address sooner rather than later cool I have another question this is going a little bit off the bridge topic but it's more on the ZK topic are there any ZK uh oh agneshka you just jumped on but I have a bit of time right uh yeah we have three more minutes and there's actually one question about I saw that I saw it if I have time I'm going to ask it no prob um okay so yeah I had two more questions so the first one I wanted to ask was about ZK snarks and just general CK Tech like is there are there um other use cases that we didn't I mean today was really focused on interoperability but

are you seeing sort of ZK projects are you are you seeing sort of and this is I mean this is a bit of a selfish question maybe on the zkv side but we're really curious to explore asimos and what's what's out there so yeah have you have you heard about any cool projects do you think that it's coming to evmos maybe it's already there let us know like yeah what's what's happening in the ZK for on the ZK front totally totally yeah great question um there's not much I can talk about right now in terms of like daps building on on evmos using ZK I think like there were quite a few and they all got scared off during the the sort of like the tornado cash uh incident um but what I am excited about for for like the I

guess like people always have this sort of dichotomy for for ZK Tech which is like oh it's used for either like this like uh compression slash scaling property um like the succinctness proper property basically um versus like the Privacy property right and so you know within Cosmos more broadly I've seen like uh tons of use cases around uh uh the Privacy property pop-up and this is you know in in the coming months you'll see a lot of uh you know uh Integrations with uh other uh projects like uh Nim Noma penumbra for things like ZK custody over like uh or

like private custody using um you know enormous Tech over you know things like IBC or even over uh interchain accounts allowing uh users on avmos to sort of programmatically using smart contracts on Atmos programmatically control assets or custody Assets in uh private zones um so that's like something that I've been somewhat interested in exploring further mm-hmm so I think we're just about at time there was a question from the audience that I I'll ask I don't know if this is something that you're able to answer because this seems like it's more of a

ZK Bridge focused question but when will the next major update for evmos be involving ZK Bridge yeah yeah great great question so we've actually started uh speaking to a few uh teams I you know I don't know if ZK bridge is like the uh you know proprietary like trademark name uh that electron uses or like the concept of ZK Bridges is used more broadly I tend to just use like any any Bridge built you know vaguely using zero knowledge I just refer to a ZK Bridge let me know if I should stop doing that um but uh We've started speaking to a few teams out there who uh leverage who

are building uh essentially uh like client proofs for for tendermint who've already built like client proofs for for uh ethereum twos uh consensus um and uh yeah seeing thinking about what the what the GTM what the go to market is for for this technology so we tend to take a product minded approach to to a lot of new innovations that come to avmo so not just like adding in an integration and hoping somebody will build on it but thinking about what the end-to-end uh use case is for both developers and and the end user so you

know we will you know build out uh or help a bridge integrate and then take a look at what use case can be built on top of that bridge and a few things have been like oh you know what if we could let dapps on the Avenue side understand what a user's balance is on the ethereum side look like what could they do with that Etc um and so yeah taking it from there cool um Nick thank you so much for for this Fireside and sharing with us this insight and a little bit of the history of etherman and evmos this has been really great totally I've enjoyed it a lot and uh thanks for the rest of the speakers as well I really enjoyed their their

conversation I think one last thing if there was anyone watching who wants to sort of get involved in building on evmos what should they do where should they go yeah great question um so we've had several hackathons happen over the past few uh months um where there's an ongoing hackathon that just kicked off the covalent hackathon right now the best way to find out about it is just to visit the evmos org evm OS org Twitter page uh and we've got a bunch of tweets out on that um it is the covalent 1 million wallets hackathon so take a look there um we were actually uh talking to zkv

about potentially sponsoring a track for that hackathon but I think we decided I don't know if you know if if this is a scene or not yeah I think it's fair to say so yeah we were talking about probably not this one because it didn't quite fit our mandate but I think we were talking about another one so a future one where we could actually do something like a ZK track totally hackathon I think we're interested in that for sure yeah don't want to make any promises here on that on no not not at all not at all but I do think it could be cool um if you that link you just shared if you want to put that in the chat after I think that would be amazing and so people can find you and I guess everyone keep an eye out for that hackathon

coming up cool it's ongoing right now so yeah yes or look at it now thanks again Nick take care everyone thank you yes thanks for listening to that impromptu podcast by the way everybody that was that was cool um that's actually how I like to do these conversations like no video uh so that was that was good yeah so I just wanted I think we wanted to just wrap this up I definitely want to highlight once again CK hack3 I know that we now have all the links in the event chat so that's there's some useful links and I think the discord's there as well which is fantastic if you want to participate in ZK hack 3 which is very much for learning and getting into the ZK space do join our Discord that's where all the

Learners are we also have to study clubs and study groups and whiteboard sessions and all sorts of things to do there um and as mentioned sign up for the cosmos newsletter if you haven't already I want to say a big thank you to you Agnieszka for putting this together let's do a little clap thank you very very cool participants yeah and everybody who joined us today very nice and also awesome design I've told me today I thought I thought it had been from somewhere and she's like no no I did it myself and I'm like this is amazing so yeah the slides here and everything thank you so much I can ask you for putting that together thanks for coming out everyone and I hope to see you at a future happiness event

either a hackathon that we're helping with or another one of these