zkSummit6: Breakout workshop – Interchain Foundation Session

Transcript

[Music] uh i've asked anya to to come and talk about some work that she is doing at nim um the entertainment foundation uh also has a grant uh with you guys to um to develop this as a general purpose uh cosmos sdk module so we're hoping this becomes a piece of public infrastructure that other cosmos chins can can deploy and um this is kind of complementary to the work that you're doing at nim um so it helps nim is a state-of-the-art mix network

and it uses tendermint to ensure mixing quality and service provision so um we thought this kind of paired well with the talk or the rather the the workshop that chris will be giving after anya's talk and he's going to be talking about multi-chain shielded pools that are based on a zcash circuit design and we're hoping to potentially fold in um maybe insights from from your conversation into into chris's discussion um chris is works at interchange in baja here in germany he's a colleague of mine

and he's also the co-founder of metastate which has a focus on cryptography and chris notably chris is the the lead protocol designer of the entertainment in a blockchain communication protocol uh which ensures uh the kind of primary feature of ibc is to ensure kind of false isolation between different chains and we think this is particularly well suited to developing and deploying new cryptography so i hope that chris kind of uh inflects that and and um describes how that can um

that that property can be retained with uh shielded assets um and for for chris's session he's gonna he's gonna give a short intro to kind of frame the problem and then open it up for discussion so please uh put your questions in the chat and i will get rid of my audio and video and uh hand it off to you on you thank you great thank you so much um let me know try and share my screen give me a second and uh let me know i'm i'm also here uh

i just turned off my video so people don't just watch um but if i'm happy to read questions off the chat you can read them if you'd like if you have a second if you have a second monitor or sam you can feel free to as well so again if you guys need to leverage me at all uh i'm i'm right here i'm just gonna turn off my audio true a quick question can you guys see my presentation did the screen share work yes great okay so um hello everyone my name is annie petrovska i work as the head of research at nemt technologies at nem is a company which is building a decentralized and instant device communication infrastructure

network to give the internet users privacy and during today's talk i'll introduce you an outline of two main components um that name is using the first one is the name mixnet the mixnet is used to ensure the network level privacy for the users and the second component which i'm going to present you is the name credentials which are the anonymous selective disclosure credentials which in very simple words allow you to anonymously prove that you have a right to access certain service or to use a certain service and so on

so let's dive into it so let's start with that then they mix it why in general do we need network level privacy so if you're into privacy you are probably familiar with applications like signal telegram whatsapp maybe protocols like pgp which you probably use to encrypt your communication so such applications or protocols like pgp allow for the end-to-end encryption which means if you're sending a message or any type of communication you can protect the content of your communication so the end-to-end encryption gives you confidentiality or maybe for example you are um interested in cryptocurrencies and you

want to use them but you want to use them in more price preserving ways so you might be using monero z cash maybe some coin tumblers maybe the lightning network so such private coins or the techniques which enhance the the privacy of coins give you privacy on chain but both end-to-end encryption and any on-chin private privacy techniques they don't give you privacy and the network level what it means if you have the adversary who is observing the the flow of the packets in the network he'll be fully able to de-anonymize you so he will just observe which ip address is sending a message or transaction to each other ip address

and that's how your privacy is broken and this is very important because privacy is a bit of like a holistic property if you have a system um if you're leaking information in one layer of the system doesn't matter how fancy cryptography or encryption schemes you're using in the other layer of the system the leakage in one layer will undermine the privacy properties which you're having in different layer so how can we protect the network level privacy the the nim is using a mixnet for that and what is the mix network mix networks are around already for quite some time they're pioneered by david chum in the 80s and a mixed network is just a set of

cryptographic relays which for which process and forward the packets and the traditional mix networks was just a multi-hop network in which the mixed nodes were arranged into a topology to which we refer as a cascade so they created like a long chain and the packets were flowing from the first to the second third and so on uh makes note so the packets were flowing through the whole cascade and how the mix network protects your level your network level privacy so when you're sending a packet via the mix network it's layer encrypted or as we refer to it also onion encrypted what it ensures is that if i'm the

adversary and i'm observing the flow of the packets in the network i cannot correlate those packets based on their binary representation because after each make note that mixed node the binary representation of each packet is changing so it gives you something to what we refer as bitwise and linkability so we cannot correlate the packets based on their binary patterns but protecting the binary representation or hiding the binary representation of the packets is not enough to actually give you anonymity at the network level because the adversary can still perform the timing analysis which means he can just observe the mixed nodes and if the mixed nodes are processing the packets at the

first in first out order what happens is that the adversary can can correlate the incoming and outgoing packets so at the end although your packets will go via multiple hops the adversary will be still able based on the times you observe the packets coming in and out to correlate who is communicating with whom and that's why the mix mix nodes protect against such timing analysis what happens is that a mixed node each one of them in the cascade instead of forwarding the packets at the face in first out order what they do is they instead of batch the packets so what happens is that a mix node is running

and he is waiting for a certain number of packets to arrive let's say a thousand so he's waiting for a thousand packets to arrive and once he gathered a thousand packets what he does he is processing them cryptographically so he removes this like one layer of onion encryption and then he shuffles them following a secret permutation and forwards to the next hop so what happens right now is that the adversary cannot create the packets neither based on their binary representation neither based on the timing of the packets and what the mix network ensured is that you're anonymous at the network layer even if the adversary is able to observe all the links between the mixed nodes

moreover you're also fully anonymous if all the mixed nodes except one in the cascade are dishonest so as long as one mix is honest you're anonymous so you might ask why although the mix network gives you such a strong anonymity we actually don't have any mixed networks deployed like how this happened so as it turns out the early xiaomi and mixed networks had a few very severe limitations the first one the first one was scalability as you can probably imagine the cascade topology doesn't scale good so the only way to scale your cascade is to make your mix nodes

more and more and more powerful which means for the people who are running the mix not just pay more for the servers and pay more so this obviously doesn't really help to deploy the system on the large scale the second limitation was that the mixed networks imposed very very high latencies and and for those highlighters there were two reasons to happen first one was that the onion encryption scheme used by the traditional mixed networks was using the public key cryptography which is quite expensive the second reason why the traditional mixed networks had very high latency was that

the patch and reorder mixing techniques which the mixons were using were imposing very high latencies and you can think about it intuitively in the sense let's assume your batch size is a thousand and now the volume of traffic in the mix network is low what it means is that mixnot will wait a very long time to gather those thousand packets so automatically your latency at each mix node and then your end-to-end latency will be much higher but even if the volume of traffic is large still your latency um the end-to-end latency at the mix network will be also large because all the facts are the packets are coming very quickly

you process the batches one after another so a lot of packets will be queuing to get into another batch and be processed so the high latency made mixed networks completely unusable for any applications which are latency sensitive and the third limitation of the traditional mixed networks was that the anonymity size offered by the mix network was limited to the size of the batch in each mix node so again if your batch was a thousand it doesn't matter even if you had five million users using the mix network you are anonymous only among those thousand packets with which your packet was mixed in the batch

and also as research showed the traditional mix network were vulnerable to the traffic confirmation attacks and to active attacks the traffic confirmation attacks are those attacks which some of you might know from tor when the adversary is controlling or observing the entry and exit node and he can observe the sending and receiving patterns of the users and based on that he can correlate the flaws so how name is fixing those problems let's start with this callability issue so instead of using the cascade topology uh name is using this stratified topology a stratified topology

is a topology in mixed node in which mixed nodes are grouped into layers and each mix node from one layer the first one is connected with each mix node in the second layer and then each mixing in the second layer is connected with each mix on the third layer and so on so the traffic is flowing always from the face to the last layer and the advantage of this topology is that it scales horizontally meaning by adding more and more nodes you can increase the overall capacity of the network and obviously when you're building an anonymous communication network you want your network to scale because anonymity loves companies so the more users you can support the better and actually the stratified

topology was shown to be optimal for scalability and an anonymity so out of all the possible topologies which you can consider like cascades or multicast case or peer-to-peer the stratified topology is the best and the packets in them are source routed meaning that the center picks the path which the packet should take and the center does that by picking randomly one mix from each layer so that's how he composes the path okay so once we cover the scalability issue let's look into the latency and that's much more complicated problem now we have here two things first of all is the onion encryption and how can we

make it a bit faster and the other is the latency which is imposed by the batch and reorder mixing technique so at name for onion encryption we use the sphinx cryptographic packet format some of you might know it from for example the lightning network it's a probably secure cryptographic packet format which not only ensures that the packets are bitwise unlinkable and they're the same size all the time it's also very compact and very computationally efficient which means the processing or creating of the packets is much faster than it used to be in the traditional mix networks and on top of that sphinx also gives you

a few properties which are very important like for example it gives you resistance to tagging attacks and replay attacks so these are attacks in which the adversary try to for example target packets to be able to trace it later in the network or tries to enforce the user to send multiple times exactly the same packet to try to you know increase his chances to the anonymize the users or de-anonymize where is his ending and then another important property of sphinx is that the intermediate nodes which are processing the packet learn only the predecessor and the successor so they only learn from whom they receive this packet and to whom they have to send but they're not learning any other

information about the path or about the sender and receiver so that's the first part we've made a choice to use sphinx to make the cryptographic operations much more efficient and to not in such a way that they don't impact negatively the the overall latency in the system but what about the mixing technique so i told you that the patch and reorder mixing technique had this problem that the end-to-end latency was unbounded the user had no control over how long it would take for his packets to you know uh get to the destination so that's why name is something what we refer to as continuous time mixes and what it means it's simply that

instead of batching the packets together each mix delays each packet independently before forwarding it so how it works is that if i'm the sender and i want to send the packet for each mix in the path which i selected i also pick a random delay and this delay is drawn from the exponential distribution and once i've picked those delays i put them inside the sphinx packet format so that when the mix node receives the packets and strips one layer of encryption he can see the delay so he knows how long he should keep the packet before forwarding it and using such mixing technique has two important properties first of all because

the sender is picking the delays i as a sender can estimate the endolate at the end-to-end latency of my packet so i know how long it should take my packet to go through a network assuming that there is no congestion right another advantage is that because i control the delays which i pick i can adjust um the end to a latest scene which i would like to achieve depending on the application for which i'm using the name mix set and how it works is that there's a bit of math behind it but it's very simple the average delay which the exponential distribution will give you is determined by the mean parameter of the exponential distribution

so you can tune up and down depending on your application on service this mean parameters so either your delays which you're picking still randomly will be lower or be higher but it gives the senders the control to really control the end to eight latency and because of that the mixer can support applications or services with very different latency constraints okay so we covered this scalability we covered there i covered the high latency let's look a bit closer into the anonymity so i told you that in the traditional charming mixnets the your anonymity is limited by the size of the batch which the mix node is using

so how do we solve that problem at them well it also boils down to the mixing technique i told you that when the sender picks the random delays uh he is using the exponential distribution and we pick this distribution for a reason the exponential distribution is actually the only continuous distribution which has a property called memorylessness what it means it means that the past has no bearing on the future um so in simple words imagine that packets are arriving into the mix node and you're the adversary and you observed let's say 10 000 packets arriving to the mix node and now one packet is leaving what happens here

is that from the perspective of the adversary observing the mixed node this packet which is just exiting the mix node with equal probability it can be any of the packets which arrive to the mixed nodes so the ones which you observed arriving to the mix this is because the time at which the packet will leave the mixed node from the perspective of the adversary is completely independent of the time when the adversary observed this backhand arriving so what it gives us it ultimately tells us that your anonymity set is not anymore bounded by the size of the batch your anonymity set can be much much larger because now each packet coming into the mix node

contributes to the anonymity of your packets and this is very important because what our study shows is that while in the traditional cascades the size of the batch was determining your anonymity and it doesn't matter how many users are using this mixed network at name it's different the more users are using the mix network the better the privacy properties so you can see it on this simple plot which i did you can see that while the number of user is growing up the the anonymity in the name mixnet is also going up whereas in the cascade topology which is using the patch and reorder technique it remained all the time constant and

there is nothing you can do about that and the last limitation was that xiaomi mix that had was that they are vulnerable to traffic confirmation attacks and active attacks and this is quite a serious problem because users tend to have very distinctive behaviors and sending or receiving patterns so based on that the adversary would be uh able very quickly to the anonymize the user so how do we protect against that um imagine the adversary who observes the the entry and exit points of the mixed network and he a sudden burst of packets from alice and at the same time suddenly bob starts to receive

many more packets probably you can correlate that alice and bob are communicating so in order to protect against that and the name client uses something what we refer to as poisson process to schedule packets to send in a nutshell how it works is if i want to send a message and i click in my click on my application the button sent the name client instead of immediately sending this packet it adds it into a buffer it's an internal buffer which you know it works like a queue for the packets which are scheduled to be sent and in the backward route there is a poisson process running which from time to time checks this buffer if in the buffer there is a real message to be sent

it just grabs this message and sends it but if there is no message to be sent the name client sends something what we refer to as a loop cover packet a loop cover packet is a packet which is indistinguishable from real messages it's a packet which goes through the mix network and as destination has your own address so it's like a loop which is coming to you what it gives you is that if um the users have very distinctive patterns of actually communicating and sending in their behavior once they they submit their messages to the name client from the perspective of the adversary they all behave the same so as long as a client as a user is online or his name client is online

the adversary is not able to infer any information about your behavior because the only thing which he observes is that you're sending some packets but he can't tell whether you're actually communicating or are those only cover packets and the the the other properties of those loop packets is that it's not only heights this your sending pattern but because those loop packets are coming back to you you're actually also hiding your receiving pattern so we're obfuscating the descending and receiving patterns so we're making the traffic confirmation attacks much more challenging to the adversary but on top of that the loop cover traffic also allows to detect the

active attacks both for clients and mixes active attacks are attacks in which the adversary controls some notes and is trying to for example drop or delay your packet or he's trying to inject more packets all this type of active attacks which would allow him to increase his chances to de-anonymize you and such loop cover traffic allows to detect them and we actually use this loop cover traffic to measure the quality of service provided by the mix nodes in the network and we later use that for our proof of mixing which is a scheme which we use to not only detect the misbehaving nodes and kick them out of the network but also to reward uh the mix nodes

which are good which are doing a good job in processing the user's traffic so here you have a quick comparison between the name mixnet and other and other anonymous communication systems and as you can see uh the nim mix set is currently the only system which provides you both scalability strong anonymity properties uh support for application of both high and low latencies but it in addition it also gives you incentives so while for example tor is fully based on volunteers running the nodes uh the the name approach gives rewards to the

operators of the mix nodes and we also use the decentralized pki which is in contrast to the previous designs which had centralized approach towards that um are decentralized pks in the blockchain and as it was mentioned that we are building this using tendermint so let's now look into the name credentials because the name mix that gives you the network level privacy and this is great and this really boosts your privacy overall but imagine you want to use your name mixnet to let's say read your favorite magazines at new york times right probably to read them you need a membership now if you use the name mix network to

access the service provider which gives you access to the new york times articles and then you show the membership which identifies you probably that's not what you wanted to have so you'd like to have a way to somehow prove that you have a certain membership or that you're over 18 or some other information about you that you have some right to use a certain service in a way that does not allow the service provider to identify you and this is when the name credentials come the new credentials are based on the coconut scheme but before i will tell you about the properties of the coconut scheme let me give you a little bit of a

background of what the selected scholarship credentials are the idea behind this is very simple imagine that you would like to go to a bar and you would like to have a drink you obviously have to prove that you're over 18. so what you need is that you go to the issuing authority and you would like the issuing authority to issue you a credential a credential might be a password and in this passport you have multiple attributes like your date of birth your nationality your name your surname and so on and so on the issuing authority issues you search credential and now you go to the bar or you go to any you know website in which you have to

prove that you're over 18 and you're showing this credential to prove that you can have a drink or that you have a certain membership or you have certain access the verifier can verify your credential to confirm that indeed you're over 18 or maybe you have access to a certain service and so on so the the basic properties of selected disclosure credentials are first one is the verifier is always convinced that the credential is valid so the prover cannot forge a valid credential and the second property is that even if the issuing authority and the verifier are colluding so they are both

malaysians and they are cooperating with each other they still cannot learn anything more than just the information which you disclosed so whatever the prover is showing to the verifier that's the only thing which the verifier is learning okay so the selective disclosure credentials um there are different schemes but they have a few limitations the first main limitation among all of them is that they rely on the centralized issuer which means there's only one issuing authority which is a problem because the malicious one can just forge a lot of credentials which are which then can be used although he shouldn't do that uh the second problem or question is

that not all of the selective disclosure credentials allow you to issue credential on private attributes without learning the value so usually you have to go to the issuing authority and show exactly the attributes on which you would like to have credential and you cannot blind them in any way and the third problem is that we would like to ensure that if i have a credential and i show it multiple times so for example i access the new york times service provider multiple times i would like to make sure that the verifier is not able to link those different showings that they come from the same person and this is when the coconut credentials enhance the name credentials come

so the new credentials have a few properties uh the blindness the anglicability threshold authorities non-interactivity and efficiency so what it means first of all the blindness means that you can ask for a credential on a private attribute which means the issuing authorities can issue you a credential without learning on what attributes they're actually signing the credential the ending ability ensures that even if you have a credential which you show over and over again uh those showings cannot be linked between each other uh the big thing of the new credentials is that we have the threshold authorities which means there is no more

centralized authorities instead of that we have a set of them and only um a subset of them has to be honest and cooperative to issue you a valid credential each one of them can issue a partial credential then you can aggregate it into one big credential uh also the the the authorities don't have to interact with each other they can issue the partial credentials completely independently and importantly the name credentials are very efficient uh which is important especially the verification is very fast and what makes the the name credentials so good is that a they can be used by platforms which um support smart contracts because the the threshold issuance allows

uh issuing credentials uh through smart contracts so how those two combine is that if i want to access a service uh and i'm using the name network and not only i protect my network level anonymity by forwarding my communication via the mixnet but also the service provider doesn't really learn my identity so i can anonymously access services and be anonymous visa with the service provider but also any global network adversary so if you would like to learn about nem uh we have the very detailed documentation which also can help you spin your own mix node our code is open source so you can go

check it out if you would like to know more details about things which i was talking here on medium we have a lot of blog posts covering that even more in detail so check it out and you have questions you can always send me an email and i'm happy to answer it and i think i just ran out of time uh thank you very much india really interesting talk thank you for sharing and uh yeah and now i think we have up to the plate christopher uh who's gonna be presenting christopher if you can hear this uh over to you hey there can you hear me yes we can hear you awesome never quite

sure all right let me see if i can share this so i will give a quick overview of the problem and then my hope is to have this be a somewhat interactive workshop that may or may not be a success but we'll try i have some an online whiteboard tool which i can share with people so we can work together on the whiteboard to brainstorm some solutions to this problem but first let me just give a quick overview um let's see let's do it this way um cool can you see i realize it's not the presentation view but i don't think i

could find a way to do that you can at least see the slides yes awesome so i'm going to talk about fault isolation and privacy and cross-chain shielded transfers which are two desitorata that happen to be slightly at odds and my hope is that in this workshop we can brainstorm some ways to potentially uh make them a little bit less at odds so uh a very basic overview of the problem is that we want to design for a multi-chain ecosystem where there are lots of different chains and many of them have different privacy features those privacy features might be based on a sampling circuit like zcash and that's the model i'm most familiar with but they might also be based on something like the coconut anonymous credential scheme which anja just talked about my hope is maybe we can in this workshop figure out

whether those might even be able to work together but right now we have multi-chain ecosystem with lots of bridges but only single chain shielded pools so maybe there's a coconut conventional scheme running on one chain or they're stop playing on z cash or maybe the sapling circuit is being added to tesla's an upcoming protocol upgrade uh potentially different blockchains in the cosmos ecosystem will adopt privacy features but all of these privacy features right now only exist on one chain and that means that when you transfer over a bridge if this is regardless of whether this is a bridge um constructed using icmp or ibc or some sort of trust approved authority you are losing privacy so um

currently uh then the advantage of these bridges or the advantage of having uh completely transparent bridges is that they can provide fault isolation by tracking the supply and that fault isolation requires that the supply tracking be done in public which means that these need to be unshielded transfers so my question uh or the question i want to brainstorm in this workshop is can we get some measure both of privacy so can we combine somehow or the anonymity sets or partially combine the anonymity sets from multiple chains so that instead of having a lot of little anonymity sets split all across the multi-chain ecosystem we can have some uh one larger one or at least some partially combined ones while still preserving this extremely

important fault isolation because usually here we're talking about different chains with different consensus algorithms different proof of stake tokens different validators that's different security models um and they don't want to be exposed to each other's because that's a small risk so i'll get into why those are at odds in a second but i also want to note that this is separate for now from the problem of network privacy uh so uh just give a presentation on the new mixnet uh network privacy is also absolutely integral luckily it is pretty much orthogonal um and it's probably much easier to combine network privacy for different blockchains than it is to combine the shield pools although maybe i don't want to make that statement in high confidence because i

do not work on the extents but hopefully it's easy so uh what i want to work with for this workshop is a pretty abstract model of what a shielded pool is so that we don't need to get into the nitty-gritty of like the particulars of these zero knowledge circuits or even anonymous credential schemes because i don't think it is all that relevant to the problem except in like the abstract model of what we can and cannot do so when i say shielded pool i'm talking about a pool of tokens that have been shielded using you can think of it using like a sapling style circuit or using an anonymous credential scheme such that when someone is looking at the public chain the owner of those tokens is unknown transfers within the shielded pool is uh are

uh you know indistinguishable from each other except that they're going to this particular shield pool and that they came in at some time step or something like this um if a single chain has a single shielded pool there will be um some supply in what's called the unshielded pool and some supply in the shielded pool and although you don't know the particular balances users have in the children pool you can subtract if you know the total supply just subtract the balance of the unshielded pool from the total supply and you'll know what the total size of the shielded pool is so um here we're kind of talking very roughly you could say that the anonymity set is proportional uh you know both to the size of the shielded pool and to the frequency of shielded transfers how many

times per block are people sending um transfers to the shielded pool and you can't distinguish them other than they are a shielded transfer operating on this particular pool now depending on what kind of analysis you're interested in defending against um you know whether the adversary whether you assume that the adversary has access to network level data about transactions or can has partial access to the transaction graph and maybe could eliminate transactions from the set they're trying to search you may have more specific statistical criteria but here we're just working at this high level so the basics of a bridge in this abstract model are that it's a way for uh two trains to transfer tokens between each other uh by default these bridges are public

meaning that supplies tracked at both ends for example this is what's implemented in the ics-20 standard and ibc and i believe that icmp has has a close equivalent this public token tracking means that supply inflation is preventable what do i mean by supply inflation i mean that when my chain let's call it chris chain sends tokens to another chain let's call it anya chain sorry for including you involuntarily in all these examples but um figure it's polite since you see with the prior presenter and you have a different privacy technology which is awesome so um if i send tokens from christian to anya chain uh then i can track how many tokens i've sent when they leave my unshielded pool because that amount is public and i can ensure that no more than that

number of tokens ever comes back that's what i mean by preventing supply inflation so even if anya chain has some kind of consensus fault um it uh you know the worst that can happen is that the people who transfer their tokens to anya chain will get them stolen but uh supply inflation for chris token is prevented because um i simply block transfers past the attract amount of supply that originally went out of course however this means in order to supply tracking the tokens must be unshielded when they are sent over the bridge which means that the two shielded pools operate in complete separation as if they were two different blockchains with no bridge between them at all i mean you could transfer tokens between them through the unshielded pools but you don't get any additional privacy so what we want is to find some way to

combine anonymity sets from both chains in ways that increase privacy or some degree of privacy for users but preserve some modicum of fault isolation which is very important uh then i will share two sort of two easy approaches and then some advanced approaches i've thought of so far and then i want to see if we can brainstorm anything else or brainstorm how in particular this might work with anonymous credentials because i haven't thought too much about that yet so uh the default approach which is sort of what is currently going to happen uh if no one does anything in particular to solve this problem is that transfers will happen over unshielded bridges which provides full fault isolation because the supply can be tracked but provides no increased

privacy so that's what will happen at the moment in the first version of ibc as far as i know same thing for polka dot even if there are shielded pools on all these different block chains they're going to be completely separate then another possible approach i don't know if anyone's pursuing this but it would be possible to completely combine the shielded pools in a sort of naive fashion where you ignore consensus fault risk so then you can combine by you know combining the note sets nullifier sets etc so then you can run bridge run shielded transfers over the bridges um but you don't get fault isolation um and there are some other slight difficulties but this is at least possible you just give up fault isolation

so uh an advanced approach and i'll pull up a diagram to explain this uh aleister says we'll be doing combined shield pool as soon as possible do you want to join alistair maybe you have more data information than i do i don't know if you can click like uh hey so alistair if you're in here you should be able to just share uh okay yeah and i actually think we might have oh wait aleister says he's going to wait and listen in the meantime i think i have to increase the number of participants so you go ahead christopher and then if else come up let me fix that and make sure that's possible gotcha okay so more advanced approaches um one advanced approach so the the key restriction here is that

um in order to enable shielded transfers um over one of this some of these bridges uh when we enable shield transfers we no longer have access of course to the balance transferred in each cross chain transfer because it's shielded so what we can do is that we can require that um you know we could change the circuit right so we can acquire require that you know maybe the balance goes somewhere else first before it just gets released into the shield to pull the second chain or maybe the user has to submit an additional proof of something what we cannot do at least not just with ckps is uh encrypted supply tracking so if we had like some kind of fully homomorphic encryption then maybe we would have to do this in the circuit so it's probably going to be

incredibly inefficient but at least in principle we could uh require that the user like encrypt their balance and encrypt the balance of the transaction and then add that homomorphically um to some tracked counter um and like uh you know somehow some check needs to be performed over this encrypted value that it doesn't exceed that the amount transferred to track in over some bridge doesn't exceed the amount transferred back out i am not familiar enough with fully homomorphic encryption to know exactly how that would be implemented but it's certainly you can't do that just with ckps because you need to be um keeping this like encrypted counter um but one thing you can do with just

ckp's is create a sort of temporary purgatory and this is the best solution i've thought of so far so i'm hoping we can come up with something better but it is perhaps um a nice uh point in the trade-off space between the two extremes so a temporary purgatory means that you basically create a what i'm calling this purgatory and i'll pull up a diagram in a second which will probably make it more obvious but i'm calling this purgatory uh what i'm calling this purgatory is a place where once tokens are transferred over a shielded bridge they will sit temporarily and in miss purgato instead of when you when you transfer tokens over shield a bridge you'll provide a zero knowledge proof that you uh you know uh burned uh that you had the uh

utxos to spend on one end and you'll send them over the bridge that proof will be verified on the other side of the bridge but then that that new note will then not immediately go to the regular shielded pool on the second chain instead it will go to this purgatory and this purgatory um basically means that it will be locked for some period of time and that period of time could even be dependent on the value of the notes because this proof can be done in the circuit so just for simplicity's sake say that it will be locked for a day um and during that day you can't transfer it to the second shield pool so uh you would like in order to transit the second shield to pool you need to provide a proof and so our knowledge that some amount of time has elapsed

since you uh created this note um uh because the time step is public so that people concluded in the public input um and that proof won't be able to succeed until a day's passed so for this day this uh this new note is locked in this purgatory and no one can see what amount it is but if there's some kind of consensus fault let's say it's it's discovered that um the other chain which sent this zero knowledge transfer had a fork then someone can provide a proof of that fork you know in regular clear text using some like client verification algorithm to the chain which received this note um and that uh this purgatory can sort of be locked such that some state variable would be changed on that chain and then all attempts to transfer

from purgatory to the regular shielded pool would fail so you can think of this purgatory as like this temporary shielded pool with an additional requirement the tokens are locked in for some period of time and this doesn't give you supply tracking but it does give you the ability to deal with um you know to prevent supply inflation caused by bft consensus faults which are detected within a bounded period of time so this may make particular sense for um you know bridges like ibc and icmp which have the ability to detect faults and handle them in some fashion now this doesn't specify anything about if you have a fork what do you actually do with these tokens in the purgatory

how do users potentially recover them you know that is out of the scope of this kind of um this kind of decide but at least in the happy path you end up with uh you know the statistical analysis becomes more complicated because it's not exactly the same shielded pool but at least after the delay period they could be transferred to the shielded pool and you never needed to unchill them along the way if that makes sense so um i want to pull up a whiteboard here because i think spatial view will help and theoretically this whiteboard is one that i can share so i'm going to paste this link but i'll also screen share and if you could open the link

you should be able to um okay i'm going to switch my tab all right can you see this hopefully yes we i we can see it awesome can you read the text is it zoomed in enough uh i can't really read when you're screen sharing it but i clicked on the link there you go that's a little bit better uh for me gotcha

yeah thank you okay this is my experimenting with live whiteboards so here is a spatial rendering of what the simple bridge looks like we have janae on the left here spa that's shield of pool a uspa unshielded pool a the unshielded bridge between the unshielded pools jane b with its own unchilled pool and shielded pool does that make sense to people do these sort of logical divisions of shielded and unshielded pools makes sense it's like that as a yes i can't see anybody yeah you're getting yeses in the chat awesome um so if we then implement this kind of i can see

people's cursors that's pretty cool okay so if we implement this kind of um more complex purgatory then what we're going to have here is we've got the shielded pool got the unshielded pool i've got the purgatory this is that's the purgatory on a this is the shielded pool on a this is the unshielded pool on a which is no longer going to be involved in the bridge then we've got chain b over here

we've got purgatory on b we've got the yeah someone's helping me out that's awesome um shielded pool on b and we've got the unshielded pool on b so uh oh man you already know how to draw these arrows whoever the purple cursor is great cool christmas uh is this a plant did you did you put a plant in there no no no no i thought my power presentation would be so confusing that

i would need to pull up a whiteboard but clearly someone has already figured it out maybe they just solved the problem years ago and i'm already behind the times but yes that is exactly correct so except that this these arrows should not be going from you drew them to the right place but not from the right place so these arrows should be going from the shielded pools because in this bridge we don't actually need to touch the unshielded tokens at all so let me just straighten these out a little bit so if we think about what's going on here when you send a uh we'll call this the purgatory bridge so when you send a transfer over the

purgatory bridge you're providing a proof that you've removed the note from one shielded pool so one shield of pool on chain a and then you transfer it to this purgatory on chain p and after some delay period you can transfer from the purgatory on chain b to the um shield of pull-on chain b you just write delay then the same holds true for transfers in the reverse direction so you can create a proof that you've spent some note in the shield to pull on b send it over the purgatory bridge you'll get a temporary note in the purgatory on a and then after some delay period you can um spend that temporary note in the

purgatory on a and get a regular note in the shield to pull on a so you could go all the way around and keep your token shielded you can see my cursor circling counterclockwise here in the direction to the arrows although you will need to tolerate this delay in transferring from the purgatory to the shielded pool on both chains so then let's say um let me just copy all this stuff let's say a fork happens what do we do so let's say we have tokens coming into the purgatory um we're just going to look at one side here so on chain b we discovered that there's some fork and at that point in time we

have like we know so we don't know exactly what the balance of spurgatory is but we know like abstractly at some n tokens um so when we have a fork on chain a then that proof of fork gets submitted to submitted to some like client and what we do is we draw a i don't know quite do this um well we get rid of this arrow so we

block the transfer from the purgatory on b to the regular shield of pool on b let me color that red and that means that these end tokens are locked so if there was some fork then as long as we get the fork proof within a bounded period of time um uh you know it can't be used to mint tokens um because they will or it can but they will never get out of the purgatory does that make sense cool um do you want to chime in anya do

you is this abstract does this abstract model also make sense for um like shielded tokens or whatever you call them when created by anonymous credentials would you have the same logical separation of shielded and unshielded pools uh yeah i mean it makes sense uh i think that would be quite similar although i'm not really familiar with this topic so i can't say for sure but it actually makes a logical sense so cool um sam you said seems like the end game with this approach is something like a cross-chain mixture that does periodic swaps do you want to expand on that curious i'm sure i can expand

too much but um if you're considering you know many chains then then maybe you would want to have you know a daily or an hourly kind of transfer that um that had a regular amount or something and and so you end up with with this kind of multi-chain um mixing service that you enter into do you mean like automatically transferring um you know tokens between the shielder pool just just to increase the anonymity set let's see i see so maybe if there's um it seems like that's a public good which

would need to be subsidized somehow for sure like individuals might not want to do that but sounds ended as a a good approach right so i guess one question i have is this purgatory approach um you know doesn't provide supply accounting so it can only deal with explicitly detected forks and it introduces kind of bad ux because users have to wait um you know you can make that at least dependent on the amount so you can have um you know the amount is in is encrypted it's private but you can require that when some uh note is transferred from the purgatory

to the regular shielded pool that someone proves that like you know if their amount is less than five an hour is elapsed or if their amount is more than 500 a day is elapsed something like that that works but um it's still you know a delay in user experience am i am i missing some way in which you could track supply without like really fancy cryptography or is it is it just non-existent i think the yeah um dara do you want to chime in here that's possible sounds like you've done something similar just a quick note chris so there's like a little bit of a lag and also said he can join too

uh you stop sharing i think you have to i try to update the settings but i don't think i can do it while it's ongoing so when you stop sharing your screen i think if if else guerra wants to raise their hand or just share then i can let them in as a moderator and then they can chime in and we only have just just a note we only have a couple um and so we'll probably make this the conclusion here hopefully this works uh i stopped screen sharing i think okay all right cool oh sweet it did work hey awesome so maybe restate the question that you

wanted uh also to address chris so so the first thing i was saying is if you if you're forced to use until the amounts you people can still split their that the amount they're trying to send and get some privacy but you still know the amount that's being gone over so one solution you might consider is to let's reveal to one person like the validate who is slashable my amount and have them do something crazy um and then if i combine that with splitting uh i don't have to trust any one person um so you would like encrypt your amount to a single validator

so we've been we uh have been supervising manufacturer a master student who's trying to do a collateralized bridge shielded which is also impossible and um but how does the validator does the validator like submit a secondary proof or they're just slashable if they fail to perform that they'd just be slackable just like more than the amount if something happened i see um but how do they provide like supply of it into the chain

or how would they provide like let's say um the validator doesn't you know allows you to double spend because you paid them on the side if i'm understanding this model correctly if you encrypted your amount to just then would they have to publish the amount to the chain in order to or would someone have to say something about the amount like they they did have enough collateral to cover it they they were splashing i see and you know they're amounting you know so you get a balance so you may be about to know that then you split it if you have lots you'd have to split it if you have lots you should split it and then no one would actually sure right we're right so with that i gotta actually it's not going to sorry chris i got to cut you off there

because we're out of time for the session that said uh you can create your own session that's actually possible to do if you go to the sessions tab so if anybody wants to like follow up on this discussion you can either go point-to-point video chat or you can create your own session and you guys can continue but i uh we got the next session coming up ckv folks but thanks everyone for watching thank you chris thank you anya thank you sam and uh and hopefully we'll see you around the event thanks take care bye