ZKVs Cosmos Privacy & ZKP Showcase - Panel

Transcript

cool so what i want to do with this panel is because there was so many um and sunny just joined when you when you can't i'll bring you on there were so many questions that didn't quite get asked we kind of pushed through this so i kind of wanted to start this off with like a few questions to each of you about the projects um i want to start with you chris because i like because the like and i'm a part i couldn't hear exactly how it's working with ibc or pools like i i kind of got that it was just you know moving the funds around and there's a private way but i was hoping you could just give a little bit of a connection point there um maybe take a second to do that

absolutely so in in sort of the basic case uh noma functions as a blockchain running on tendermint uh we're working in rust for the sdk with a multi-asset shield pool so an instantiation of our extended version of ecc sapling circuit which supports shielded fully shielded transfers using standard like nodes and commitments adjusted to also shield the acid denomination so this means that there's a logical shielded pool on an ova which uh all assets can elect to share including fungible and non-fungible tokens anything that can be like represented as a combination of do you picture do you picture there being kind of like an lp token type thing happening on each of these

chains or like how are how are the how is the liquidity provided um or is that too early i'm not sure so there are tricky uh the research area which i guess i'm most interested in or which to me remains most open is in balancing the security isolation or fault isolation provided by ibc with uh the desire to have cross-chain price so the technical implementation of krusty and shielded transfers is not that difficult but the uh tricky thing is that it changes

what kind of fault isolation you can get because ibc provides fault isolation to prevent some other malicious chain from inflating your token by tracking what the incoming and outgoing uh supply is so each chain for any chain which speaks that we see any other chain which it's talking to using is 20 has a balance basically and when i send tokens from uh my chain from the noma say to the cosmos hub i track that and if the cosmos hub ever tries to send back more i will reject the transaction that's all well and good and works just fine and provides fault isolation in the sense that no other users of that token on my chain

are subject to risks only users who send it over to this particular chain so that inflation is prevented by tracking supply but as soon as you shield the transfers then suddenly that information is gone because you're feeling the transfers so what do you do um that then if you want to it's also complex just sort of implementation-wise because you're trying to track this kind of aggregate statistic across transactions namely the total value in or out which is uh sort of like design wise pretty incompatible with the way like sapling circuit works because it's not tracking any kind of state which is cross user dependent so if you want to do like addition in private then you need homework edition or something you need to connect that to the circuit and that will get very complex very

quickly although uh and even in principle you don't you can't track it exactly because if you track exactly then like just by looking at the difference if the value is public by the difference in the amount um you would know what the value of like the transfer was by subtraction so uh you need to there's like some balance maybe of tracking the supply so you can provide fault isolation but tracking it like within some error margin uh and then you have like privacy except there's this sort of bound on what the total value transferred uh in some unit of time was and maybe that's sufficiently maybe that's like a balance to be achieved i'm not sure where so would we say that it's still a work

in progress or like do you have the solution so this problem is uh not specific to a noma at all it's uh general to anyone who wants to do wants to i mean it's general to the sort of ecosystem of ibc connect change but large insofar as we all want to like share our privacy sets because the more the better but we also want to isolate our faults because the viewers are interested makes sense i actually i want to so what's so cool about these three presentations by the way is how they kind of targeted very different parts of the cosmos stack and i really like that i want to kind of move on to henry um you had sort of presented this like for anyone who's just seen the panel this panel and didn't actually see the talks

was this idea of like private validation um i had this leftover question you you kind of have a completely new thinking about that in order to keep delegations private but you talked about this cap like it being like at the at the unbonding point some sort of cap gain happening but what was that based on like would that be time spent or a mount in because if it's a mount in wouldn't you then wouldn't it reveal what you're trying to hide um yeah so uh i guess there's sort of two parts to that question if i'm understanding it correctly the first part is like how does the um you know like a reward amount on unbounding

un bonding or undelegation um work and then the second part is how do you avoid some kind of linkability between uh delegations and undelegations right so um the the way that the reward system works is that in every um epoch all of the bonded stake is inflated by a factor of you know one plus the reward rate relative to all of the unbonded stake and then for each validator some portion of that inflation is captured by the validator as a commission and some portion accrues to the

uh delegation holders and the exchange rate is account like perfectly accounting for all of that um cumulative um inflation or it's actually not necessarily inflate it depends on which sort of side of this you're picking as your reference asset which i think is also pretty interesting like one perspective you can have is um either you have uh bonded stakeholders are being compensated for taking on some risk right that's corresponding to choosing the unbonded stake as the reference token or you could choose the bonded stake as the reference token and from that perspective

people who don't bond and don't take on any risk are penalized for not doing so right so that's this kind of equivalence but there there is a problem with potential linkability where if i see that's there's some bonding amount and then there's some unbonding amount and i know that there's like particular relations between those things can i you know work through all the possible combinations of epochs and figure out whether there's like a known ratio and do a correlation and the solution to that is that actually um because the uh all of the consensus weights are only updated per epoch you don't actually need to declare

publicly how much you're bonding you only need to have the kind of net flow into a particular validator's delegation pool be public and so the solution is that when you do a bonding transaction you would encrypt the bonded amount to all of the current validators and then in the last block of that epoch they aggregate all of the bonding transactions and then decrypt only the net flow and so there's still maybe some correlation

like maybe you're the only person who bonded in that exact epoch to that validator um but that's sort of like this there's some stuff you could do to mitigate that like maybe you get client software to like you know bond in different chunks or maybe people are bonding to a bunch of different validators or you know maybe you build this system and then it's successful and then it has users and then you know if you have a lot of users then ideally you have a big enough and an do that inaudible fix that all right i'm gonna i'm gonna move on to dave's project i know sunny you get

you and sunny have been switching places but i given that i'm gonna ask a question about the presentation then maybe it does make sense that you're here um and it's actually generally about the project do you feel like the work that you're doing right now is really specific to cosmos or could that actually be like also used for ethereum and erc 20s yeah yeah so i think there's a great solution for mental privacy for anywhere where you can have this sort of bfd setting so causes sound natural because there's tendermint bass player eth and eth2 don't actually have this very naturally e3 has a design goal where if there's only one validator that's live the change would keep proceeding okay you don't actually have a threshold that you can like rely on ah

so what you could do is like you could maybe have threshold encryption where um you know the threshold could be delayed so this this then reintroduces some like i mean i mean the opportunity but for roll-ups like you can do a multi-validator roll-up situation and this works great like we directly applied there nice all right now i wanna i wanna you get safety in that hold on hold on it's safety in that context of a roll-up but you don't get why the roll-ups liveness guarantees um um because like um uh this is like a pedantic thing but like and like this is a interesting i think question for the ethereum community is going to be it's like

you know the argument for like roll-ups is you have both the safety and liveness properties of the underlying chain um for most roll-ups and if you were to add something like threshold decryption you could get safety properties from let's say tendermint um but you uh wouldn't have the liveness properties of the underlying chain like the rolex could get stuck oh it doesn't depend on your model of like do you have uh transactions to be posted on l1 first or do you have them be given to a sequencer and then batch updated on the l1 you could have this you know sequencer network still come to consensus and just keep doing batch updates to l1 so i think it still works out there you

just block on the liveness of l1 eventually like after some num after you've proceeded by some amount so i want to i want to now kind of take it more into a general context and this is a bit back to you zaki is do you think that there is a business case for privacy on cosmos like i want to bring it back to that like we've now seen these three really fascinating examples of using privacy in these different ways so i don't know if i flip business so that's what i want to throw i guess the i i guess the biggest core observation is is without privacy value is being extracted from users

right like that's the core observation is like behind all of these protocols it's like when you are transacting in public on ethereum um you're like uh value is being transferred from you to another party um usually that party is miners um like front-running bots that kind of stuff right um and like that that value capture is um and so you know the proof of stake world is like maybe we start socializing among the validator set more of that value capture and it's like game theoretically uh a fairer playing field for that value capture to be distributed more evenly um and like you see that in things like the gravity index design

where you have these like you know batches of transactions that are computed um that sort of so like that's the proof of stake world but in order to actually get to the point where the users of the system keep all the value you actually have to get to the privacy world that's the clearest that's the clearest business case for privacy right the clearest business case for privacy is users keep more of the value i mean henry you kind of mentioned that as well this like trying to i mean i think we've all we all actually thought about this this idea of like putting the making sure that these incentives are aligned do you think that there's a certain place that the alignment should happen first this question goes to anyone here

um like does it need to start from the top should it be in that like consensus level or can it be lower down well i guess um one thing about um privacy that is important to under understand is this idea of kind of like um like multiplicative decreases in anonymity sets so if you think of privacy as being about really you know control of information disclosure then it's more clear why that's important because when people are

transacting ideally they would like to disclose or control what they're disclosing but um each sort of piece of information that is disclosed ends up having a kind of multiplicative impact on the amount of privacy that they're going to have overall right if you leak one bit over here and you leak another bit over here and the third bit over there then instead of you know being three times smaller you're actually two to the three times smaller right you're eight times smaller um and so the kind of fundamental like incentive or benefit to putting

privacy into base layers as deep as possible is that it gives you this kind of substrate that you can then build other things on top of and if you have that substrate then a lot of things become a lot easier so for example in the case of um trying to have privacy preserving swaps right there's this paper um that came out recently um about how uh you know uh privacy and uh constant function market makers where um effectively all of the information in the the trades

and the prices is also in the function and so you can't really hide one without hiding the other and the conclusion of that paper is like oh well this means that privacy for these cfms is impossible but in that model it right exactly that there's there's mitigations that were proposed but yeah like there it i i know what you mean it makes it hard yeah right if you're if you're starting from like oh well we can precisely identify that this transaction was made by this person and you know the amount is tried to be protected but then we can recover it from this other information well if you had built that on top of this kind of like private

foundation where all of these uh transactions are kind of recycling the same um anonymity set and and breaking linkability then then it's much easier to solve so if you the the deeper that you build the privacy into the system the easier it is to have more private features on top of that foundation that makes sense um there's a question here jonathan asked can you talk about programmability with privacy and i guess that could actually go to anyone here oh you go ahead i'm sure i guess this is

asking about maybe the unisoft example henry's talking about where um you know you have a sort of this contract on chain and you want to have private data go into it and you know some get some private output you have this fundamental problem that you need the state update to be public and so this is the problem of yourself like you know when i do a trade against unit swap i need a uh everyone needs to know what's the remaining reserves on both sides so you can infer then you can back in for you know what was the uh transaction data or for yourself in particular you know some things you could imagine it's many to one so you can for given the public state update it's one of these uh transaction types but you can still get privacy here where

privacy then means maybe two different things going in context one is that like who did the action in is private so you know this just be like a z cash style or uh the payer system on if uh or you know in if you don't have privacy built in very deeply you have to do some other trade-offs like henry's mentioning that you have to go like one thing is like you do the aztec batch transaction thing which then grows complex it gives you less privacy guarantees because it's not built in into the l1 and the second thing you can do which is like you could hope to hide your transaction until it's finalized which is often what people may want for like trading

and it's immediately resistant stuff like mental privacy things oh sunny i think i can add sunny in now i hope i can i think sunny just joined yes okay good hey did you want to jump in and say something on this dave covered it perfectly okay okay um i wondered like is there other parts of i mean i don't know if it's parts of ibc parts of certain parts of any stack that are missing that make it i mean we talked about the rust versus go but like is there anything else that we could even maybe encourage the audience or the community to start working on

that you that that maybe a lot of people feel is missing yes oh i think exactly just had to bounce okay okay one question i've like had in my mind i've been one of these answers to is are there uh approaches to cross chain privacy where like two different chains can share the same anonymity set but efficiently and so i don't think anyone's work no one else is working this to my knowledge and the only idea i've seen a bit discussed is uh you can have uh you can hope that you have both chains share a nullifier set if you're thinking z cash style where z cash is nullifiers and

you kind of do some you make tokens encode what chain they can be spent on and you have all nullifiers go under some like cross chain agreement protocol i don't know if there's other ideas i think there's a huge design space open here that should be explored i mean henry you were i know previously you were working on sort of like a peg zone right like this idea of having one zone dedicated to that would that like does that i know it doesn't solve the problem you just highlighted but would that also be like if that existed does that open up something is that something that people should aspire to um i don't think that that would really solve the problem because in that model you still had um

uh you know the actual transfers are still um public i think to the the point that um chris made earlier about this tension between um kind of like fault attribution and privacy um that seems pretty fundamental to me if you want to have um if you don't want to you know reveal specific amounts that are moving between chains then you can no longer know about specific amounts that are moving between chains and that's the problem so you know you might be able to build something for instance um that kind of like interpolated between

those two extremes so you could potentially build some kind of a batch value transfer where um you know people would kind of queue value to be moved over ibc and then the entire batch would be moved kind of all at once and then you sacrifice attribution within that batch for for privacy and the kind of length and size of the batch has user implications for how long they have to wait for finality or like you know because if if i'm a user and i want to move funds between two zones i kind of don't want to have

like ach on the blockchain where i have to like wait three days for it to settle like that is kind of sad um and i think people are used to the idea that especially in a system like cosmos where you have like finality um i think people are used to the idea i make a transaction you know 10 seconds later i'm sure that it's been committed to the chain yeah i think there's okay sorry you can workers go ahead all right well you can come back oh okay i was excited to hear what you have to say okay i think one part of the trade-off or the like tension which is

particularly tricky is that the ibc security model is dependent on this concept of like value flow in time so if you think about some kind of potential attempt at misbehavior or attempt at byzantine subversion and double spending across an ibc channel that's happening like in time and ibc itself is composed of several layers of defense so the initial layer of defense is just like if you have you know less than a third byzantine you have all of the guarantees of like client algorithm if you like the algorithm is secure your chain doesn't fork and you're all good but even if that fails ibc has secondary layers of defense and

those secondary layers of defense work by detecting misbehavior so cases where faults are attributable even though it's like more than a third potentially that is faulted but attributable from the perspective of another chain because the other chain like has their own consensus so that they they haven't lost their ability to come to agreement on what happened so they can still see that oh a fault happened like i should start treating this ipc connection accordingly and the way in which they learn about that fault however is dependent on processes which are happening in time in time which is asynchronous across these chains so it's dependent on the submission of misbehavior evidence evidence about what the validators actually signed which in this case was

like wrong or a violation of the protocol somehow to the other chains which are interested because they're running like clients and speaking ibc and that evidence submission like happens is something that's a function of time function of like when stuff gets gossiped over the network and who could do things so fast and because of that in order to contain the faults you want to contain the flow of time or sorry the flow of value over time because you want to be you want as i at this other chain i want to know that oh like if some fold happens distributable and some information is like somebody's proofs consisting of signatures of the validators or whatever they did which was wrong gets necessary necessarily exists somewhere and i want to have time to learn about

it but before too much value was floating on my chain but then that also has tension potentially with certain kinds of privacy schemes based on batching insofar as batching might involve like sending one ibc packet which does the whole batch at once and that whole batch at once could then be timed by the validator set which is attempting to misbehave so that they could like move a lot of value at once uh so there's it's a really tricky tension uh because go is that you know we could we can use stability proofs for the flow rate like you could snark properties you want guaranteed about flow rates between chains like and then as as you know a transaction to you

i can get guarantees that i can get my flow rate guarantees even with privacy like being added in here um but how do you do the like addition i mean you need to keep you want to keep the state right of the flow okay maybe uh yeah like you know i could have this i am invariant that you know you did not mint more of these tokens that were ibc'd like you know uh [Music] you know an invariant total sum right like all these ibc lock tokens weren't inflated um maybe but then it sounds to me like you need

that kind of proof like over the whole state machine uh yes okay i think you just need it for the state route for the ibc statements and you know anything that goes in and out of the ibc state route not um the rest of the year yes if you logically isolate um the part of the state machine responsible for executing ibc and then have state validity proofs over that um that helps yes but i still don't see so if shielded transfers are happening there um how do you have you still need to like compose

somehow the amounts of the shielded transfers and add them together without revealing what they are yeah i guess we would need some sort of summon variant that like uh the sum of transactions in and out like i mean the other problem is that these are not like necessarily i mean this is like maybe a more approachable problem but the say trusted setups used for zero knowledge through schemes or even the zero knowledge proof schemes themselves are also like not not necessarily something that's going to be agreed upon by different chains in the cosmos system in terms of what counts as secure is there like is there a preferred zk construction so far in cosmos is it sort of deferring to snarks or

does it have is there any like particular circuit that people are using more do you know um i mean in my opinion like the best documented and specified zero knowledge circuit in the world is still ecc sapling and that's what we've built on top of for the msp okay um so in terms of shielded trend i think that's as i understand penumbra is like also basically an extension and lots of additions to that design yeah that solves a very particular problem it doesn't solve other problems so like to solve other problems you need other circuits in terms of serious proof scheme i don't know if there's one which is specific to cosmos halo 2 and like plonk and p lookup are kind of sort of converging towards the same

point in the design space which is indicative at least to me that that's like a natural uh uh direction it probably will result in some kind of common standard but it hasn't exactly happened yet got it um somebody asked a question here uh asking us to kind of throw back to an early to this go versus rust debate in zk land and cosmos and i'm and zucky's not on here now but he's the one who brought it up maybe you all have opinions or thoughts on that given that you're working with these yes my thoughts are that uh there's i see no issue with just using russ for compile and then doing like

static linking or dynamic linking to uh you know get your nice performance for capacitor photography and go i think re-implementing is like a not great strategy though there is now a great like go laying uh like snark library for some of the popular schemes from consensus called gervy yeah i heard about that yeah but i have i still have a preference for like just find it just because of the standardization do you then want to see cosmos head like move more towards rust generally like would it be nicer if you didn't have to make that connection point or is it just so irrelevant it doesn't matter well maybe i'm prematurely seeing

because i have not written the bindings ever myself but i feel like you know we can automate a lot of the binding difficulties and henry probably knows a lot more here than i do i don't really know anything specific to the cosmos parts or actually really about the um the kind of mechanics of doing complex bindings i do know that like most of the people who i know personally who have attempted to do some kind of um go related ffi that wasn't seago have not had a super fun time of it um go as like a design decision that they made

you know it has there's like it's very like special um and like you know it has this this cool mechanic for doing like stack handling and everything and that provides benefits for go um but it means that it's like less straightforward to do uh kind of like in process interrupt um got it well i'm happy to go out on a limb here and say that i think we should just move towards rust i think in both most aspects rust is a rust is a better language for building blockchains it loses to go a little bit in terms of

usability and familiarity and like ease of working across a very large code base especially if people are using a lot of macros or non-idiomatic rust but it wins a lot in performance in like degree of error checking and type checking which the compiler can provide of course integration to cryptography libraries and also concurrency i think so i want to finish what you were about to say no i was about to change so yes sorry there's also uh informal systems has i think a long term uh a strategy uh hopefully it hasn't changed i don't want to misquote them but to eventually work on temperament and rust they're already of course

abci bindings and we're slowly moving towards maybe maybe there will be like two parallel ecosystems maybe there will be bindings in between them and people can mix match mix and match components but i do think it's worthwhile to pursue a long term rust go ahead one one thing that i would just like finally note is the the the kind of benefit of having a more powerful type system that lets you express these more complex invariants right that's the the obvious benefit of that is okay now we have this system that we're trying to design and has all this complex behavior and we can encode it all into the type system and have the compiler check it for it great wonderful but the kind of under

discussed kind of downside risk of that is that doing that kind of encoding state invariance into the type system is like actually a kind of non-trivial skill that people need to learn i think that's part of the kind of like learning curve of like effectively using rust and if you like don't do it well then you can end up with this kind of like cemented spaghetti code that's completely impossible to change because you've like encoded all the wrong invariants into your code base so that i think is a challenge i wanna since sunny's on here and we

haven't heard from yet i hope you don't mind if i i wanna ask you a little bit about and i don't know if you're thinking a lot about this but where you would maybe like to see privacy in cosmos if you've been i know you you and dev dave you've been exploring a few different spots of using zero knowledge proofs right now you're doing the i mean this presentation was on the threshold cryptography but i want to hear from you what maybe else is on the horizon and what you'd love to see um yeah so obviously there's the threshold i mean i i try to think of it from a very practical standpoint of like you know what's the highest value use case and like you know i'm coming from like a you know we're building a product called osmosis and like which is a dex platform for cosmos

and you know i'm approaching from a very practical standpoint of like what is the features that people want to see and so from talking to people the one that people wanted the most was the front running prevention which is what we started with um the next piece that we want is you know i think dave mentioned it earlier but this like very practical idea of like hey like you know getting everything working in pro in a fully private system is not like really what or you know it's a nice end goal but it's probably not the like way to get there right and like you actually do want a lot of things that are public like you know it turns out people actually don't like dark pools as much like people want to see the order book and or they want to see the amm pools

and things like this and so having systems where it allows people to like and so you know the simple solution that we were like hey the easy v1 for this is just having a shielded pool which assets can like come in and out of uh and try to you know it's not going to give you the like full level of privacy there's all these sorts of like um things you could do to like you know like you know reverse engineer like figuring out what's happening but like you know if you're making it harder at least and like you're making giving the tools that allows people to like make it as easy as possible for people to like shield as much as they can um i think that's like at least the

first like pretty good step and yeah i i think that's what people care about most like i've talked to a lot of like traders and they're like one of one of the like people who like traditionally trade on or like market makers on like centralized exchanges one of the reasons that they actually don't want a market make on like decentralized exchanges and stuff is that they're like we're literally leaking our trading strategies like and so they're not their goal is not to compete against like state level actors here right they're just trying to like hide against like other traders from like copying them and really what they care about is like hiding in on the scale of like a couple minutes because they just don't want people copying their trades in the next couple minutes and so this is kind of like the more practical

yeah like stance that we're trying to take it's so interesting because i'm i'm hearing that not only here but in a lot of ecosystems is this like there's two privacies i mean this is fairly obvious but there's the privacy for the individual of the business from their competition or just like random people and then there's privacy from the analytics and the governments and all that and that's different um and i know that like if you're talking about a trading context then yeah i think it's mostly just like to provide like to shoot to be able to keep your strategies to be your own um and not have to share those but i wonder like it's so funny because i feel like there are also different camps of folks who like would worry that if you only focus on

the light privacy that deeper like lack of privacy will come bite you in the ass so much worse like the state actor oh and i we have one on the call but um two at least but it is it is interesting to see how these like when we talk about incentives like it there also are no incentives right now for private style like dexes who want privacy to necessarily offer that full level of privacy and their the incentive is not built for that um henry do you you put your hand up as a as a counter so what what is your thinking i just no i did a thumbs up

so i i agree i i like i i would self-describe as that like person who thinks that the like trying to draw this distinction is gonna come around and bite everyone in the ass in 10 years um like i think that um one of the the trends that you can see in uh like technology and surveillance technology in particular is that over time the cost of having some capability comes down so if you think about the way that online advertising works

it's like actually structurally quite similar to the kind of like you know program that you would need to monitor everyone's uh web browsing activity but it's just done by all these random like companies and there's people like chanalysis right that's not like people often in the community people sort of like lump in chain analysis with like the feds but chanalysis is just a company right they obviously do a lot of contracting with um like state actors or spy agencies or whatever but there's no fundamental reason to think that there is a kind of hard line that will last into the into the future

um this there's kind of an evolving landscape of on the one hand you have um privacy capabilities and there's a kind of marginal cost to effort or you know how much privacy you're getting for how much effort you're taking to use this tool and then on the other side you have this kind of spectrum of um surveillance and monitoring technologies um and and that landscape is not fixed it changes over time but that the terrain that is being contested there is fixed so you know there's only there's a you only actually get like movement in the direction of de-anonymization

you you can't retroactively like boost your mice but that's what i'm wondering about like like specific to cosmos like bringing it back to this particular ecosystem like is do do we know what the sentiment of the cosmos ecosystem is towards privacy like does is this an ecosystem that is thinking like that or is it an ecosystem that is like wants this to actually be very free-flowing very transparent in in the end oh so i don't know about now but at least i remember in tennervin office we had heavy debates about this you might remember chris and sunny where um some people really wanted the hub to never have privacy and a lot of us wanted uh like to have privacy

let's get lots of it yeah there certainly are i mean in applying privacy to particular aspects of blockchains there are dangers that don't surface when applying it to other aspects i think private proof of stake is interesting and has compelling advantages and also has like potential dangers insofar as it makes it much harder is the user to ascertain what the security of the system you're using actually is and maybe there are ways to mitigate that and maybe a good counter argument to what i just said is that users can't ascertain what the security of this is actually using is anyways uh because validators identities are difficult to discern um

you know and potentially and like all we can really do is incentive design and it makes more sense to focus on things like correlated slashing than worrying about whether the validators identities are public or not i'm sympathetic to that argument but it's like not clear to me um it's still like conceptually rather hazy uh as to like what what the trade what that trade of space looks like another one is voting right like governance voting like i think that was like one of the topics of like you know for the cosmos hub which is like do we want governance voting to be private and i think i always understand where like probably not i mean i want reputational like harm done for like malicious voting mistaking to redesign that uh sorry

private staking designs i've seen like with delegation right i guess not i've seen henry's chocolate introduces derivative tokens which is actually a huge change the underlying stinking model of security you've removed this unbonding period stuff like there's uh i didn't mention it in the talk but there is an unbonding cue oh never mind so perfect you don't get like instant settlement on that sorry i should have been more clear i mean another tony just actually added to this a little bit for the voting idea give validators the ability to prove how they voted but don't force them to that would be cool is the comment well

it kind of seems like there's a a potential distinction that you might want to do between validator votes and delegator votes so if the setup is that validators are voting on behalf of their uh delegators as a kind of a default vote i think it it does and the validators are the ones participating in consensus i think it does kind of make sense to say like validators have accountability and delegators have privacy maybe that's just because sorry oh i'm just saying and we should extend that to like liquid uh

democracy as well like you know if not just dollars been delegated too but anyone we delegate to whoever is like a your delegate uh should maybe should be public but all the all constituents can override privately with the norm instead of being constituents that entity i thought i'd like not clicking your address um trying to build some kind of um like liquid democracy style delegation of uh stakeholder voting but the thing that i got stuck on is um ideally you would want the um voting to be split out into a kind of

separate capability so for people who aren't like super familiar with sapling there's this cool like crazy hierarchy of all these different keys that are involved there's not just one key and each key corresponds to kind of a different capability of something you can do to that node that's like spend it or view it or whatever so maybe you could try to do something like having like a governance sub key that would allow you to only do voting but if the voting mechanism is kind of piggybacking on spending notes you have a challenge where the person you delegate authority to like do the voting to you might like not create a new note for you to keep

your balance right so you'd have to have some kind of like constraining that they like did the voting correctly and that's tricky but i think that would be really cool and you we we could just build it you know like well like one of the problems with with trying to do like a liquid democracy style system is that um if the idea is that you're going to implement this kind of like a delegated voting for democratic decision making and we're going to hook that into kind of like an existing democratic institution that we have then you have to like you know get everybody on board first before you can even like build and

test the system i think that kind of ties into one of the things that's like so exciting about the blockchain space is that you have people basically speed running like every single possible coordination mechanism designed that you could ever imagine like sure let's just build it let's see what happens yeah it's kind of cool all right we have three minutes left if there i don't know if there's any other questions from the audience from the folks there john gave an example of this uh delegated context and privacy and a link there um but yeah if anyone has any other questions or if you if any of you want to say anything else

about this topic of privacy cosmos i mean one you know one i think uh one thing to be like that's interesting is like i think one of the one of the major projects right now in the cosmos ecosystem is the secret network and i think they take like a very interesting approach where like they kind of you know forego all this like cryptographic like stuff and it's like you know what let's just like use like the simplest possible way to get this done and just like using sgx and like you know i you know i think in dave's talk we talked about like oh you know we're not super big fans of sdx but at the same time it's like you know for depending on your use case

i think it is actually quite a pretty uh you know i i think it solves some people's use cases and in fact i think like speaking now because actually like underselling themselves i think like the interesting side of them is not the privacy yeah because like well like i think the privacy isn't the interesting part i think that i think it's really it's like hey it's a replacement to an npc anything you need mpc for it's like hey hey you can just use this like secret network thing like the sjx is like such a hack but it's like you know if you're okay with the intel safety model like trust in intel the pro the other problem with sgx is that there's an availability problem to it right like i can just shut off my server that's running

my intel sgx but secret network kind of solves the availability problem for sgx's by creating a distributed sgx which is you know i think that's a useful thing to have well it's not useful for the goal of privacy for privates like it you know henry's point earlier like for private state this is maybe one of the worst like things you do if you want long-term security since yeah or sorry maybe most of my headaches depend on what your use case is right like i i can totally see there being some users who like find value in the level of privacy that secret offers that like i think no other production system offers at the moment i think secret network currently

provides capabilities that no other assist production level system provides even if it's not the best level of privacy you can get it's better than not having that capability at all this bringing this up by the way just made the chat blow up with lots of opinions [Laughter] so actually this might be a great moment to sort of thank all of you for coming on and talking coming to this event i'm saying coming on like i'm still doing a podcast thank you for coming to this event and for sharing all of this we're actually going to break out now into a setup where we can go to the sessions and create our own sessions so we're going to just create

another one of these i'm going to create one but i would love it if you will also all of you here create new sessions so that people can actually engage and have this conversation continue but um big thank you to everybody this was a very fascinating event i feel like i'm coming away with a better sense of what's kind of possible what the issues are and we're going to definitely be creating a report or some sort of blog post about what we've learned today and we're also going to have a forum that we're going to share with a few people to try to get some ideas around you know what other people are thinking so yeah i'm gonna shut this down i think if you all wanna bounce out of here i think it shuts it down and we'll head over to sessions thanks everyone thank you