ZKPodcast: Zkps & interoperability: IBC context with Chris Goes

Transcript

[Music] welcome to zero knowledge a podcast where we talk about the latest in zero knowledge research and the decentralized web the show is hosted by me Anna and me Fredrik this week we are sitting with crisco's from 10 durmand chris is the ibc lead and works on the cosmos network or in the cosmos network how should I say that I would say I'm a participant in the cosmos network and I also work on

the cosmos network those sets are intersecting not completely intersecting all right well welcome to the show Chris thank you and we have Frederik hello so I've never fully understood what you do I've met I we've hung out a fair bit I see you at full node every once in a while but what what is your focus like what is your work at 10:00 Derman at Enderman I focus on IBC which stands for inter blockchain communication IBC I would describe as a set of abstractions that we're working on for message passing ordering and authentication between heterogeneous chains so between block chains with different consensus algorithms different state machines some

common high-level properties that we can encapsulate it into IBC and then use those properties and those abstractions like like clients to the law to talk to each other in a uniform fashion is IVC as it is today the same thing that was first proposed like when was is it sort of built in the way that like IBC was specked out like researchers decided this is what its gonna be and then you've been building it or is this something that's evolved is this the same thing that was described like I don't know when it first came out I would say that IBC is has evolved over time but it is still a ideological descendant of the key idea which was to allow block chains to use like clients

to validate each other state and thereby construct a arbitrary message packaging passing mechanism between heterogeneous chains I think actually his background so we had sunny on the show last May and I think it might be useful for people to listen to that episode because that really describes like the cosmos Network and he mentions sort of where IBC lives but I don't think we went into it at all um what do you what do you think people think IBC is and what is IBC I would say there are two common misconceptions the first is easy to dispel the second I'll do my best the first misconception is that IBC is a protocol for token transfers we suspect that this arose out of our inclusion of

token transfers as the example of choice in the cosmos white paper of course the cosmos white paper is now this you know exalted document that we can no longer modify so we cannot to revise the example but in fact IBC the core protocol doesn't even reason about tokens at all it just reasons about messages those messages can contain anything that the application might care about you can't build token transfers on top of IBC you can build cross chain voting cross chain delegation cross chains taking you can build certain kinds of code transfer which then start to look like sharding if you're passing contracts around IBC is constructed as a layered protocol so in a pretty close direct analogy to tcp/ip IBC is designed to sit on top of block chains where

block chains are analogized network cards provide the transport authentication and ordering layers and then be used by applications on top so protocols on top of IBC are analogous to HTTP the tcp/ip context HTTP uses the packet sending and receiving functionalities of tcp/ip to provide web sites and you can implement token transfer we have a spec numbered ICS 20 as an application layer protocol similarly similarly on top ABC was IBC designed for cosmos specifically like in in the way that it was created in design was it like with cosmos in mind or did you take it from a perspective of let's

try to design the most generic and liked feature full protocol whether or not cosmos can actually use that yes to both questions insofar as that had cosmos in mind it had the idea of cosmos as a composition of heterogeneous protocols which means that there are things we can't assume which in some ways makes it more complex it might be possible to design something simpler that only works for a subset of consensus algorithm or subset of use cases and those protocols are valuable but that's not our goal our goal is to design something that works for most blockchains out there in the world today and that we hope will emerge in the future so you mentioned the first point first

misconception what's the second second misconception touching on a bit what I just mentioned is that IBC solves a particular problem not necessarily token transfers but that it's say that it's an interoperability protocol for cosmos or cosmos is some closed set of block chains following some prescribed list of rules that's not our goal our goal is to define a protocol which can be adopted not only by change what success today but integrated into chains which will exist in the future just like when architects of tcp/ip sat down to write a network protocol I wasn't there but I assume they wanted that Network protocol to be

supported by network cards by hardware that didn't exist yet had they built assumptions about particular existent chipsets into their protocol then no one could have ever built new hardware because people would have ended up depending on the particular properties of those chipsets so similarly we want to limit the assumptions which people using IBC can rely upon in order to allow it to support many block chains and protocols that don't yet exist would you say though like what does AI B C stand for inter blockchain communication is the core idea of IBC just like bridges is bridging a very key part of this protocol or is that separate different people use the word bridge to mean different things sometimes it's

used to mean a token bridge which I would consider an application layer protocol on top of IBC sometimes it's used to be mean a more generic message passing bridge and that is similar to IBC usually though bridge refers to a specific pair of chains and then like a specific instantiation of some validation algorithm and in that sense that's different IBC will consist of you know many bridges not a single bridge yeah I said that's my misconceptions I just thought IBC was like the bridges that's like how I understood it and I actually I had this sort of follow-up question to that which is like we did this episode on bridges and there was

these different ways that bridges can interact either mint and burn or lock and lock I think those was that the to lock and unlock kind of thing right though that sounds like a token transfer bridge all right and this is not like this isn't there's nothing in the IBC protocol that talks about this specifically or there's no model that it has to follow so there are different layers of the IBC protocol the core layer does not talk about tokens that just talks about block chains and modules and simple capabilities the minimum ontology that we think is necessary to abstract over the use cases we care about on top of the core protocol sits the application layer protocol and just like it's helpful to standardize on tcp/ip it will also be helpful to standard standardize on like

the application layer protocols for things like token transfer and we've written a token transfer protocol which describes something like mint burn lock/unlock and that can be standardized on on top of IBC got it I mean the IBC is at least as I understand that isn't software you know it isn't a bridge is software it's you know a module on this chain it's a module on that chain or a smart contract or something it's a set of relayer notes it's a game theoretic you know system of ensuring that certain things happen it's all it's just software it's like engineering whereas

IBC is a conceptual thing it's how you pass those messages between these different software components that's right and in particular IBC also tries to articulate what properties are required of these lower level abstractions like light clients what the block chains have to provide the minimal set of things that they have to provide because we wanted to make it as easy as possible to adopt and then compose those properties into some gist all security properties of the whole system so when you use IBC if your block Chane correctly instantiates these abstractions what do you get you get exactly once message delivery you get certain guarantees about ordering you get guarantees about either the message

the frente t'adore someone will get slashed this sort of thing to follow up on what you just said Fredrik what is it then like you just said it's not a piece of software like is it libraries is it rules it's a specification and the specification we hope will be implemented by many different pieces of individual pieces of software the most complete implementation so far is the one in go being developed by the cosmos SDK team tournament there are also in progress implementations in rust in JavaScript potentially another languages coming so an interesting question from me in like how far the protocol goes is sort of would you recommend that for

instance if to use IBC for across train communication because that's now we're not talking about bridges anymore it's not a bridge system at all it's all integrated it's using one shared consensus algorithm but it's still you know to some degree conceptually different blockchains talking to each other right I've actually been looking into this a little bit recently and I'm not yet done evaluating whether our abstraction stack can be cleanly mapped onto what if two wants to do and I'm not entirely sure what they want to do so I'll need to ask them more to figure that out but I think the answer in principle ought to be yes what people want to do when they're sending messages

across shards or across chains generally requires the same kinds of guarantees but we need to ensure that we've picked the right abstraction such that no performance penalty will be paid and such that we can correctly capture the varying security models because IBC is written with the minimal assumption set so the protocol itself doesn't assume any kind of shared security doesn't assume any kind of consensus synchronization between these chains that assumes that they're sovereign or operating independently when you are running in a system where that's not true such as he threw or such spoke it out you can make more assumption those assumptions should allow you to simplify things to avoid certain proofs to maybe do things that would be unsafe in the more general model and we want

IBC to encapsulate that as well it will probably take a little more work and some specific instantiation for e2 or for polkadot or something like though I suppose it's hard and like as you said it's been designed with the cosmos ecosystem in mind once you're exposed to a fresh new world it's sort of like what actually applies here what doesn't is this a leaky abstraction now or isn't it and how you iterate on that to to move outside of your originally envisaged boundaries is interesting it I mean to your point of tcp/ip people praised this a lot like the the protocol and it is

successful but I remember reading this blog post from a network engineer once and he talks about all the leaky abstractions that exist from from like how things are transferred on the wire to like how they have to implement things in hardware and the amount of hacks that is needed to go from like you loading something in your browser to something being sent over the wire is amazing it's an insane amount of hacks and needed to get there so they've been successful and they've been successful in adopting like technology that came thirty years after they invented it but at the same time you know it's not super clean yeah that's true I would say that the important part in the part upon

which I hope we will be able to standardize is a common ontology and terminological set for exposing these cross-trained primitives to developers on these systems on cosmos on polka-dot on e to writing contracts who need to reason about the security and the safety of what they're doing without understanding all of the nitty-gritty implementation details and if we can agree on things like channels for sending messages if we can agree on delivery properties if we can agree on what you know finality means in that context this will be very helpful to developers who probably interface with multiple systems does it almost have like a standards element to it what you just described

just sounds like standardization of terminology will we hope that it will we have a ecosystem working group currently composed of tender mints the interchange foundation cork and more people are invited polka dot it's more than welcome as is anyone else listening this podcast you me an email yeah more seriously the goal is to standardize and we are we want to create a vehicle for a long-term stewardship at the protocol you know independent I mean the cosmos ecosystem is a vague term it can mean the cosmos a bit can mean the blockchains correct the cosmos a bit can mean anyone who uses the cosmos software and it's up to you to define what you

mean by it but IBC certainly should exist as an independent entity you don't need to connect the cosmos up to use it and we want the standardisation process to Evers like that would you like does IBC compare to the beacon chain or the relay chain in the polka dot world for some reason I've sometimes heard it like categorized as doing the same thing my understanding is that polka dot uses has a messaging protocol for communication between parrot Ayn's that basically uses the relay chain to perform all of the verification and orderings the relay chain is responsible for checking that

headers are inserted in the right order and the ingress cues and aggress cues confusing with it anyway are like coherent lee ordered that the properties of those and seeks to provide are fulfilled in IBC that's similar to what we call a proxy client architecture where the parrot chains are relying on the relay chains verification to determine whether or not they intend to accept the process messages and how does it how would it compare to the beacon chain then or has the beacon chain change by so much yet it seemed a specific enough standard for how the beacon chain will handle message passing

and to comment on that all right yeah as far as I know I mean I'm not up to date on like the last three months of work maybe but I have not seen a legit proposal for crocheting communication in you two I don't think it's something that they've actually expect out yet yeah I think a lot of the hard problems are topological as and they will be shared between cosmos polka dot and e2 and they mainly have to do with state dependencies in cases where you want some sort of atomic commit or rollback there is probably a lot of distributed systems research or research that could be looked at more seriously before we try to invent new solutions but a lot of

the costs are different so things like mutual exclusion locks are just going to be exorbitantly expensive when locks require sending transactions to all of these shards and those transactions consume gas this sort of thing I think you hit the nail on the head there with there is a lot of preceding work in this area I think it is kind of odd to think about that we're inventing something new because I mean even the terms that you just said like queues and ingress and egress and all these things are things that are defined there is you know a whole set of work around queuing theory you know the distributed systems work has been going on for 20 30 years and

they've solved a lot of these problems so really over what we should be trying to do is just trying to bring in the context of a blockchain like what does finality mean when you're applying it in in this you know scenario we already know how akyüz behave we already know how to do message ordering or I mean know as an you know there is research on this so yeah it's it's an interesting thing to look at you know what are we bringing to the table what does a blockchain bring to the table of distributed systems research what assumptions do we have to change and

what do we have to build in to our model that you know we can't just take everything right out of existing research but at the same time we shouldn't ignore all existing research and we haven't even gotten to the game theory I mean we're still at the level in these charted systems of how do we actually route the messages to the right places at the right times we're not yet at the level and we need to get to it if it's going to be resilient on an open Internet we need to get to the level of here are the actors here there you know incentives or utility functions at least some kind of modeling of how people behave and are these security models were constructing especially with proof of stake are they coherent in that environment it's

interesting you like just to kind of go back to that when we were talking about the way that like the eath to shards would interact in this case like what could I be could it be something like there's a beacon chain with the shards underneath it and then IVC like the beacon changes under ibc because shards to me are not unique block chains so yeah like I I'm trying to picture like how they would potentially interact but they have independent execution and that is that's enough for IBC so you could even run although it would be unnecessary but if you had an on sharted blockchain you could run IBC and it would just sort of look like a loopback

client just like you can run web browser on your computer and view a locally rendered website created in a different process so where is IBC at today where is obviously at today on the internet it does that github slash cosmos slash ICS in terms of standardization progress I think it's a release candidate five of 1.0 what that mean 90% I would say it's very close and we've been surprisingly pleased to find that in the process of implementing the spec we first wrote a

spec and then wrote an implementation we've needed to change little most of it we you know modulo testing in production but most of it we think we got more or less the way we intend to do hmm so for this episode one of the things that you know we definitely want to focus on is this idea of incorporating zero knowledge on many levels into an interoperability setup and I think it's really cool that you just gave some background on IBC there's a lot of that stuff I actually wasn't as familiar with as I thought I was so I think it's good to get that update but yeah I want to shift over now towards zero knowledge the first thing I want to ask you is

what like how did you actually become interested in it in the first place did I become interested because I think I met you I mean a fair warning I am knows there are knowledge cryptographer by formal training or by expertise just dilettante but yeah I became involved in and blockchains first and found out about Sarah knowledge through pluck chains I couldn't have been point the precise time or date might have been C cash okay the thing is I know you more through like I think the case summit and stuff like that you you had been participating in a lot of these groups so what where is that connection then

like how does the zero knowledge research stuff relate to what you just explained with with the IPC work it really it's in a lot of different ways zero knowledge proof SAR really or I think they will eventually become a primitive that people build into software in a lot of different ways just like existing cryptography like just like signature schemes are used for many different purposes and blockchains you don't really you don't you don't at this point you don't start from the question of oh I have a signature scheme what can I build with it it's like what do I need in the signature scheme is one of the possible tools to address many different kinds of needs and I think the same will be true with CK B's eventually in the

context of interoperability I would say there are two categories and one has two subcategories so zero knowledge proof scan be used for broadly scaling or no cut no privacy no alterations the state machine but just allowing different chains or different modules within those chains to talk to each other more efficiently or with better security guarantees and they can be used for providing privacy in some aspect of the state machine that could be in sending tokens Alexi cash it could be in governance it could even be proof of stake whether we want private proof of stake or not different question but as possible and then within that second category I

would say it's worth differentiating between applications where all of the state of the journal system will live on a single chain so like the current South link circuit on Z cash will live on one chain or wear and the second option where that state is charted or split between multiple chains where you have some kind of just alt circuit but it's actual state you know parts of different commitment trees four sets of notes is stored on many different block chains or even different shards of a single system and in this case the privacy feature would be actually like cross blocking is that because you put that in the privacy category yeah that's right I mean I think to users what would end up being

exposed is hopefully a unified state but the actual state would be split between chains and that could be used to there are lots of implementation questions which I hope we'll get to and an example that I've always talked about with polkadot and like when you know way back when the the paper or was first released I I'm not sure if the paper talked about this case or not but it's something that we kind of explicitly tried to design around and that is allowing a privates like shard of a chain so in the polkadot world left pair of chain is like a is a shard and what that private shard would

do is in like let's say you have you know application a on pirate genie application beyond PI chain B you want a person a user of application a to be able to say you know I have this education and I'm proving this to to this other application so that I can get up loan or whatever and so you know how can this person prove that they have some education well let's pass it that then chain B is like the university chain and it has all the educational certificates of people but you don't want to like give away all that information that the university chain doesn't want to publish all of its

state to the world would be dumb in many ways so this person a you know like on application a can say please you know send our requests to chain B and have them prove that I have this education so they can chain beak and then reply with a zero knowledge proof saying yes this person has this education and they don't have to show that the certificate they don't have to reveal any more information from their system than simply to say yes they have this education and then je n'ai can go off and do with that information what they want and so you have as a whole a system that maintains the privacy of people's

education but it can still be used in the system so I think that both you know privacy points are super exciting to explore and how to actually interoperate with privacy but then the scaling stuff is like I in some weird way I think that's what will be explored first and it's like the easier thing to argue about and it might have less implications if it breaks but there's like a million scaling applications as well my prediction and you know put this on air so I can be proved wrong in good epic stomach fashion my prediction is that zero knowledge proof for scaling will be relatively straightforward and

they most they mostly just replace primitives which can be implemented in other ways more efficiently they have equivalent or better security guarantees and they don't require they don't really interface with economics or game theory all that much they're just implementing some algorithm and can be slaughtered in eras are knowledge proofs for application-layer privacy for governance was taking come with many more game theoretic considerations many more potential economic problems of you know its if it is treated as economically different to have things private or public what are the ways in which that will affect how the system is the whole paves I think there will be a lot a lot more challenging research that we should start on now in that second category and

potentially to your point potentially more in that second one it could potentially be more dangerous say it breaks and dangerous on like to a person not absolutely a system yeah let's go into the first so shall we in this context of zero knowledge proof for interoperability shall we explore what scaling or how maybe the zkp for scaling can be used in an interoperability context sure so IBC actually reduces to very simple scaling primitives IBC just requires basically two things it requires a light client algorithm a way to verify the

consensus transcript of the other chains you care about and a state verification algorithm like a usually back to commitments or a Merkel tree proof for example of a way to check if a particular packet has been committed in an outgoing queue on one chain or received in an incoming coupon or another chain and those two primitives can both in different ways potentially be instantiated with zero knowledge proof I think the most likely candidate is the former because it is the more expensive the most expensive right now my client verification currently there is some ongoing work by sello with a fork of sexy to implement [Music]

I believe it's like line verification for BLS 12 377 of either their blockchain or a future version of their blockchain in a zero knowledge proof which is really cool because you can compress all of the header checks into just one proof so you can proof like whole epic two weeks worth of headers with one succinct zero knowledge proof and I think to do that they use recursive specifically like a form of recursive snarks you wouldn't have to but I do believe that we had them on the show we should will link the episode in the show notes but yeah I think they are but you wouldn't have to even if it was you know you compressed two weeks worth of like laying proofs of headers whatever it may be there's few enough to

them a few enough of them to check and how that it's vastly better and this that what you just described there though that's sort of the CK roll-up version right where you're batching data it's similar one important distinction and one way in which the terminology needs to be clarified is that some like clients verify consensus transcript only but other like clients also verify either the entire state transition function or part of the state transition function so another like client in a zero knowledge proof is what coda protocol is working on but that is really a full note Wyant it verifies the entire state transition function from Genesis using recursion which is also a

stateless clients and yeah it's a bunch of things and it kind of makes everything complicated to talk about but I mean this is a good example of it being new and we don't really know yet like no one has proven this in a production application but it's it's it's very close and we can imagine you know with coda it's it's taking away everything and you just have this one proof and here you go you know everything here is valid but then you have a secondary problem of like how do you make this useful you still need to pass around data that that people can operate on it just doesn't happen on chain anymore right

well and there are differences in what you can do in the state machine so in Coda's case they get the benefit of being able to verify the state-transition function on just you know on phones with ones they're single zero knowledge proof but they then have to craft their entire state machine to be efficiently checkable in a circuit and that comes with a lot of constraints I want to actually correct what I just said before when I said the zk roll up and batching I just realized how different that actually is because you can't roll up is batching transactions and what you're talking about is batching headers so maybe the word batching is incorrect here somehow but like to make a light client I mean but I mean I guess you're still using a zkp here as a validity

proof right that's like the context in which it's being used but completely different data underlying it and very different use case yeah yeah different data in different use case but it's being used to simulate deeper you touched on another thing that I I want to talk about as well because I think it is important it particularly in an interoperability context is those vector commitments they were talking about Merkle proofs in almost all cases where a lot of interoperability works by saying here's a bla like if you have the like client like clients can help you decide which chain you're on rights but it doesn't usually help you decide this

block is correct or this this state transition is executed correctly and so you once you start getting into that you have to like provide the whole block and the Merkle tree or the like subtree of all the transactions in that block like if you wanted to verify that an aetherium block is correct you'd need a massive merkel proof to do so and compressing that merkel proof is actually I I think that is a super important thing to get to it's a bit more complicated it's a bit more like blockchain dependent like which exact blockchain what exactly are we trying to

do or trying to prove so it's not as generic but I think I agree with you that like probably the first and like the lowest hanging fruit and grabbing this but to some degrees the more important one is like being able to provide a succinct proof of you know here's this data and you can trust that it's correct I believe that if two intends to do that one constraint it imposes is that you have to pick circuit friendly hash functions but changing the hash function in your non zero knowledge circuit code is generally pretty easy so it's easy to adopt that and then you can do a Merkel tree proof relatively efficiently and

Sarah knowledge and this is what file coin came to the conclusion of right they they had these slow encoding structures and producing massive massive Merkel proofs to prove that I'm actually storing this file and it it proved just impractical like they couldn't actually build an application that that used that and they had to go to a zkp to compress that but let's say you now wanted to prove to a different chain that you're I'm storing this file then I don't not only need to provide the proof of that storage but also the proof that someone is paying for the storage and like that gets into the state of the chain as well as like the file so yeah I think there's

there's ample space here to explore in the future and for a lot of these things I think we have to we have to find some way of compressing and maybe these are the only way to compress that but I think it's certainly necessary to find better things than Merkel proofs for a lot of these cases just before though you described you just described a sneak a Merkel proof is that different from a like I can imagine it's different but I don't actually understand what you mean by that by a ZK Merkel proof are you thinking like a recursive proof that looks like a Merkel tree or no well that's you could also you can do recursive proofs in a tree I don't know if coda does it I would be surprised if they don't do it

but that's however different than a Mirko proof and is our announcer k't which is just creating a circuit that encodes that imarco proof with some inputs and like the input is secret because you don't want it to be stored some input verified correctly and then you check the Merkur proof in the circuit and prove that the proof checked and the verifier just text the constant constant size proof I'm still not for whatever reason I'm still not clear where the zkp is like is it because I'm just picturing a Merkel tree with like these hashes going all the way up and I'm like right right they replacing the hashes there's one zkp and it's around the whole thing okay so the zkp encodes

that the entire thing is correct the entire thing is correct and the prover when they prove has to basically do a bunch of hashes in the sarah knowledge prover transformation okay I had a like this is kind of I don't know if this is exactly scaling but it's compressing and I don't know if this makes any sense but as I was thinking about it and as I was exploring more like ZK roll-up stuff going back to that this idea when you talk about interoperability is there a way I'm probably totally off-base here but is there a way that you would and maybe that's actually what we're talking about with the light clients but would you be able to take instead of it being

off chain transactions it'd be a chains transactions and then use the K roll-up somewhere else quite possibly it depends what you want you could use one chain for data availability and another chain or chains for actual execution that's quite possible currently I think ZK roll up with on chain dot availability which is one of the most well implemented solutions that I know about uses one chain for both of those things so they use the etherium chain both for that availability and transaction transaction input data and they use it for verification using the like pre compiles for snarky verification on the theory

but you can separate those out if you have some way to communicate between those two chains I think that will actually make a lot of sense because optimizing your chain for data availability and optimizing your chain for verifying proofs or very different things and if you have one chain that does both it has to compromise a bit especially in this sort of multi chain universe where there's like chains with very different properties this might be really interesting because some of them might be optimized like one might be optimized for the data any other for a verification now the caveat is that the more chains you add into the mix and the more you split these different components of the state machine as you care about the gestalt state machine

right the user is using ZK roll-up they want to send coins they want those coins to be sent only to one place the more the components of the gist all state machine are split across all of these different chains the more complex your game theory gets and that will need to be I would really like to see more formal tools and models developed for reasoning about the game theory of blockchain there's a lot of hand waving cosmoses as guilty of this as anyone you know we continuously try to improve the state of our analysis yeah you know I'm not a game theory expert i I've never studied it and so I don't know what the academic states of game theory research

looks like or what models they use or have Alastair who works at the researcher what three foundation he used to actually work and game theory used to be you know in academia in game theory and I like I completely agree like we need to bring whatever exists if if nothing exists then you know game theory as a whole needs we certainly need to bring more into the blockchain world where we're kind of saying you know well as long as someone gets punished when they misbehave then it's fine but like really you know we probably should work out how much they need to be punished in

some exact form or like in some formal method or yeah there's also a lot of like kind of yeah they need to be punished but then some people are saying well they they don't need to be punished like the social pressure isn't right right right well I worry about relying on social pressure because I think the social pressure will go away we have this now it's tight-knit community people care about their reputations people are nice they're altruistic but we can't expect to rely upon that and the future better to stress test now so I think validator should be a little more brutal but then going but what you're talking about with

that economic challenging or these economics simulations around zero knowledge proof what does that even look like cuz you're not it's like say you did that split that we described and then you want to balance economics is it sort of like where what the validators on each of these chains get or is it something totally different what yeah what's at stake what could potentially be stolen or double spend by violating the protocol luckily zero knowledge proof have a you know well specified definition so you should be able to construct these proofs without you know reasoning about the specifics of like the polynomial equipment scheme yours or an altar fuses or anything like that you can just say that it's computationally sound and we that is good enough for most of what you're actually going to do

but you need to reason about what the chains are what the application state is what you know value it potentially has in the case of tokens or financial instruments and how that can impact the incentives for actors the protocol I mean I think as concrete example if they're in lower the prices of call data which means that it's easier to put data on chain for our availability but that doesn't bloat the states and so that's like a step forward for aetherium but imagine if they didn't do that people would need to find some other place to put their data let's say they put that on our we've we did an episode with our weave and we tried to get to the bottom of what's the probability that someone will lose your data on our weave and we

can't really answer it it's like low probably it's like a probabilistic answer first of all but but then it's also there's no like formal definition or formal analysis on what that actually looks like so let's say there's an application that puts all of its data for availability on our weave and then puts the state on aetherium you know now what's the probability that someone can double spend on aetherium or that the data is lost or that you know what's the cost of putting the data there or like if you're you're now also dealing with a distributed distributed system so you're

you have this train and hotel problem that the theorem two talks about a lot like if I only want to book a hotel if I also book the Train so I need to be guaranteed that my data is on our wave before I put this data on ethereum and so how do I guarantee that well like there's so many like questions that need to be analyzed once you start splitting this out that yeah we don't really have tools to do that analysis even so then let's go on to that second example or that second category that you mentioned at the beginning of this kind of topic that is the zero knowledge proof sort of more in the privacy context where they

would live on or actually maybe it's a few I think you had this topic and then a subset yeah how did you define it a second category is really zero knowledge proof or anything other than scaling where they are involved in application state which you care about and usually you care about I may be there I can only think for now of carrying about it because you want to make some of a private now what you want to make private can vary in the case of a currency you might want to make the sender recipient an amount of every transaction private as De Anza cash but say you want a governance system where people can privately vote then you would want to make the voter private like some details about how they voted so you couldn't identify them based on metadata

we could conceivably although they're an open question as to whether it's a good idea we could conceivably have parts of proof of stake be private to wear who delegated whom the amount in which they delegated you can't make all of the private but you can make parts of it private gotcha so some of it is sort of like keeping things private on a single chain and then trying to maybe be like interoperate because you could do I mean you could be private on one chain if you want so there's simplest model of privacy interacting with interoperability is where the state of the zero knowledge system and like what the data is so notes in the case of as he can't record that's providing the

privacy semantics he is all on one chain so the Z cache chain say could and we hope well in the future connect over obviously to other chains then users could transfer the tokens to Z cache they could shield them on Z cache send them around a shielded assuming Z cache implements custom assets but they could send them around as you know in the shielded pool they would all these different denominations while on that chain in that one circuit would share anonymity and anonymity set so no one looking at the transactions could tell whether they were easy cash or Kosmos tokens or tokens now that's the simple model because it doesn't rely on any

sort of cross chains date but that means that when you send these tokens to Z cache and send them around on Z cache as long as you're doing that they're private but as soon as you send them back out again to some other chain to do something else they are rendered transparent again in order to have privacy across the chain where you don't reveal even when you're executing cross chain transactions exactly what you're doing you would need zero knowledge proof that function with state on multiple chains got it now there are versions of that that looked just like sharding where you want you know one really big Z cache that needs multiple chains to handle all the transaction throughput and you can split up your note set for example and nullifier set on two different shards

that can execute transactions in parallel and synchronize every block or something but there are more complex versions of that where you want different stayed to be private on different chains where you want a private currency Anzhi cash but then you want to send some tokens while retaining privacy you don't want to make them transparent you want to send them over to cosmos then use them to privately vote and that will require that might potentially require like three zero knowledge proof systems the one on Z casts for Senate currency the one on cosmos for privately voting and some like special bridge proof in between to transition from a note on Z cash to a delegator entry that can vote in the

cosmos system while retaining privacy well in order to implement that bridge you have to make some more assumptions I mean then the to proof systems have to be willing to accept parts of each other state so they would be exposed you know counterfeiting with Wow bugs as he cash out once that's yeah got to want to be careful I mean that would be basically like going from like you'd have tokens and transparent you'd move them in to shield that you'd send them somewhere that remained private they were used in a shielded context and I don't know if you'd then send them back or something but like I mean that could also be create that would be like crazy in the mixing front to just picture that you like go into the shielded state you

move it to some other chain and then come out of that shield of the state over there I feel like regulators been like well it should be possible to implement all of the separated keys that see cash is implemented and especially the sapling circuit the viewing key spending key that allow for certain sorts of regulatory compliance in a cross chain contacts it doesn't really changed yeah that seems really do you think that that's what it's gonna look like that it would be these 3zk Peas there's three constructions or do you picture it like being a more unified it really depends on the economics and I'm not sure how the economics will turn out there are a

lot of complexities and there are a lot of what you might call coordination problems so in the case of shielded tokens we want you know we as users of a system who want privacy what the anonymity said to be as large as possible when we send transactions we want it to be you know we asked to be one of n where n is as high as possible possible and in order to do that everyone needs to be using the same in anybody set if you have different ZK shortcuts on different chains with different anonymity sets they could be traceable there just because yeah you can identify when people switch between them or they're too small so you want there to be one internet movie set but then that's in tension with several other considerations it's in tension with scaling then everything has to

happen maybe you can chart parts of it but everything has to happen within some consensus agreement it's in tension with potentially security because then if all of your value is on this one chain how on earth do you have enough proof of work or proof of stake securing it and it's also in tension potentially intention with programmability or configurability so let's say you want different assets to have different rules you want one particular assets transactions in that asset need to pay a percentage based fee learning a percentage based fee you of retaining privacy is tricky because if someone gets a percentage of every transaction

even if it's private so even if like I have a particular you know key and I'm the special person and I get that 5% tax then I know what the amount of every transaction is because I know that there's a rule which has that 5% has to go to me so you know maybe there are fancy workarounds for you sharp very involved yeah yeah but they're also cases they're cases when you might want that sort of supply audited auditability in between different chains where you want I you know guard against the risk of counterfeiting or something like that I spoke with so Alistair from what 3 the person that you just mentioned Frederick I actually spoke with him before this episode and I was thinking it might actually be interesting to have him come on and explain some of the stuff that he related to me but I'll try to relay it

to you which is about so with this X EMP spree those do you say that together no difference so they both help and well X EMP is sort of IBC with the assumptions around polkadot security model okay and spree is shared something out computation kind of thing yeah so in in hit the way he just he just sort of describes something kind of similar to what you had just said this sort of like overarching Z cash and using spree to do a lot of the cross chain message passing like you wouldn't have then like three zkp systems you'd have this spree that sort of acts between them as overarching

space whereas the K P could exist yeah so I mean it's pretty to explain it shortly is a shared piece of code between a bunch of different chains and they all call that specific code so they trusts that that code is correct and is executed correctly so in the polka dot world this would be a piece of code that lives on the real a chain and the relation execute it and so it's not each individual chain that is responsible for executing that code this is a problem they get into and both with charting and with building for interoperability and there are there exist many different

chains the question is how can you compose these chains I can't trust that your chain is actually going to be the same thing that it is today tomorrow if there iam changes all the time and the only way to have a guarantee that what I'm calling on your chain is still the same as if your chain never changes but in polka dot we solve this with spree by saying there is this shared piece of code that you can always trust this the same because that's the sort of guarantee that it's intended to provide so you can compose and interoperate in a better way in a more trusted way through spree and in the context of ZK peas and

what we talked about with like a shared know if I said trying to make that as large as possible you'd still run into the case of like if it becomes too large then it's still too large for spree but you could have the zkp stuff live in spree or you could have the nullifier set live in spree and then the sort of just interacted based on them it's a bit like an enclave I do and there would exist the same on every chain do you feel like is there is there more on the privacy this sort of shared privacy model that you'd want to mention one other challenge even if we solve the scaling challenges in terms of

maximizing it the anonymity set is dealing with the potential economics of stake so proof fake tokens are inflationary and that means that if you just send them to Z cash you are being taxed effectively for holding your tokens in the anonymity set this is quite a concern because for the purpose of providing anonymity we want everyone to hold their tokens in the eminent anonymity set but if you're taxed when doing that that's not going to be so popular you mean like if you were sending it from a set a different proof of stake chain to Z okay so if you send if you send your cosmos atoms to Z cash you will be able to then transaction privately but you will no longer receive staking rewards it's basically like an

opportunity cost you've you've taken out your tokens from your own validate or a delegation to somebody else and you've like right instead to be private rights now in the model of sake obviously token transfers it would be fairly easy to add another little application layer protocol which would allow the shielded pool on another chain to be delegated so you could state that the Z cos chain like has X atoms because in you know because it transparent when they leave the cosmos sub you you know what X's and X atoms you know are delegated to some validator but figuring out which that validator is maybe it should be the ZK validator figuring out what's that

validator is and figuring out how to distribute the rewards to the people who have shielded tokens because of course you don't know what their balances are are both unsolved problems well there's some next-level stuff right here so a lot of this a lot of the sort of breakdown of this kind of conversation stems from a workshop that we did this summer this last summer at the web 3 summit and Chris you and I and an Alistar and a bunch of other people were there talking about CK peas in an interoperability context and one of the things that was on the board but I feel like still is very undeveloped is this idea of what does it mean for a Dex to use zero

knowledge proof in an interoperability context could that could that be like a thing could it be like that you use roll up things roll up type constructions to improve a Dex in an interoperability context would you allow for maybe private transfers through a Dex from one chain to another this is sort of some of the ideas very underdeveloped though I would say like from our conversation I don't know if there's been any like work on that since then or if you have any more thoughts I think that both categories for scaling and for privacy of application or potentially interesting for Texas and potentially even both at once I could certainly

imagine cases where you would want some sort of private cross chain atomic swap where I want to trade my Z cash for your dots and we want to do it in private so Frederic doesn't know and we arrange something is there a knowledge that you know impacts the state of say the Z cash circuit and sums are involved sugar ton polka dot and we also have to use a proof to conduct the transfer as soon as possible I don't know of any instantiations of anything like this yet I mean I feel like just the general topic of Dex's is complicated obviously but if we're looking at privacy or from a privacy perspective then exchanges are these sort of accepted middlemen in a

world without middlemen and even even a Dex kind of leaks all information currently and it's it's a tough one to crack because yeah introducing ZK piece and everything like having a private order book in the world of finance is a known thing and and it it's not necessarily a popular thing yeah I think Ian Myers had this saying he said the Bitcoin was like Twitter for your bank account I think you could extend that to you know at their Delta I'm out of date on the etherium Dec seen but Dec says are transparent actions are currently like Twitter for your financial program yeah yeah all right it's it's a complex topic

there's definitely something that needs to be done or like needs to look into that but Texas have so many other problems just before they get to that point that I think it's a long road map for them do you see any other kind of waves like do you have any other thoughts on how like zero knowledge proof could be used and like to do things outside of what they're currently used for mmm well oh here's another here's another interesting application it will probably take a long time to be realized maybe will never be realized depends on how bad the concrete constant constants end up being but I suspect zero knowledge proof might play an interesting role in networking between

nodes in allowing nodes to prove things about state that they're going to send before they send it which can make certain kinds of like dos much harder because you can require that when you connect to a node over a peer-to-peer network the node sends you a short and sweet proof attesting to the validity of some data and then they can start sending the data and you don't have to a lot of a lot of like dos attacks on peer-to-peer networks are based on exploiting expensive computation so you can craft data to get the node that you're sending it to to spend a lot of time computing on a validating it and this is very problematic and hard to defend against but if you can prove that the data you're sending is valid and that you've already validated it and

they can just check the zero knowledge proof which has something like known time complexity that would be pretty useful I I really appreciate that we've had a chance to sort of get into this topic on the podcast we had done this workshop and I'm really happy that we've now maybe exposed some of these ideas to more people but before so I want to say thank you for joining well thank you for having me but before we sign off is there anything else maybe like related to sarah knowledge proofs or like in the same sort of sphere that you are also excited about or paying attention to i'll caveat that i know less about all of these but I think

multi-party computation could be interesting for at the moment is very interesting for a generating a toxic-waste for zero knowledge proof system setups but also interesting for other use cases potentially like keeping data private without writing a circuit you know you don't want the data if you don't want the data to live on the client but you still want some sort of privacy then you need something like NBC Sarah knowledge pierce for privacy only work if you keep the data you know client-side I think there's been some recent theoretical progress that I wouldn't claim to understand in the area of code obfuscation which is very applicable to block chains because people might want to publish secret

secret algorithms or published code to smart contracts that they want other people to be able to execute but not to be able to read or analyze and code up facin I think that Wow asymptotic costs of doing it are still very very high yeah we talked with Dan Binet and then in his episode about this and like cryptographic code obfuscation meaning there can be a smaller contract that holds a private key to something great it's a is an amazing you know think piece just like the if you think about the ability of having that it's pretty amazing you can do some very cool stuff but this wouldn't be like this this is not related then to what we talked with Sakon Arielle about this idea of like function privacy

that's just like execution of that is private but in this case you can publish everything but it's still private okay well right people can execute the code you publish it like it's like what Windows tries to do when they send people binaries without send them sending them source code but they're failing because you can take apart the binary and figure out you know the many bugs Windows actually ship to production what they what we might want to do in the future of blockchains is do proper code obfuscation so that people can ship smart contracts that anyone can run but no one can decode nice well listen thanks so much for joining and having the revenues wide-ranging conversation

it's been really fun and to our listeners thanks for listening thanks for listening [Music]