ZK8: Namada: asset-agnostic interchain privacy - Chris Goes - Anoma

Transcript

foreign next up we are going to be inviting Christopher goes from anoma to the stage to talk about nemata namata nomada sorry acid asset agnostic interchain privacy so welcome Chris and [Applause] thank you um according to the schedule at least lunch is directly after this talk so now is a good time to sit back enjoy you know let your brain process a little bit of cryptography and prepare for lunch if you're really tired lunch is coming soon

if you're standing out there talking you could sit here and then you could go to lunch it would be a good prep um okay I'm Christopher I work on anoma confusingly because this talk is about something else obviously called Amada we name all of our products different things and give them different color schemes you know to be determined whether this is the correct strategy but it is on purpose and this talk in contrast to many things here today which have touched upon what you might call like new shining Cutting Edge as in both it's new and shiny and it might actually cut you if you use it improperly cryptography Nevada is about old and boring cryptography accepted old and boring in in blockchain time means like two years so not really old in other sorts of cryptographic time but Nevada

is uh here I'm going to I'm going to refer to an excellent blog post by I think Moxie Marlin Spike the original creator of signal which talks about how in order to Craft products which actually protects users privacy and practice you need to strike a really nice synthesis between designing the cryptographic scheme and thinking about the user experience and you need to think about those both at once because if you don't think about them at once you're going to end up with fancy cryptography that nobody uses or you're going to end up with something usable that doesn't provide any privacy and Nevada you know it's easier to do that when you use things which are have been around for a little bit longer and think about a very particular product so

Nevada is our effort to do that for interchange privacy let me explain what that is but first let me give credit namata is built mostly by people who are not me at heliacs and you can see very small pictures of I think almost all of them here but particularly you can find Ava and Adrian and myself who are larger or not because we are more important but because we are here at least so you could find us um and please ask us any questions Helix also does a lot of other stuff and we're happy to talk about that as well so I'm only going to spend one slide on this because I think it's preaching to the choir but why does privacy matter why might you want to care about it or spend time designing systems which are

private uh I think there are more reasons than like just protecting individual you know privacy is not only individual it's also social and perhaps sometimes the individual aspect is over emphasized particularly privacy is important for National Community defense for defending against uh kinds of propaganda which really rely on the ability to collect a lot of data privacy is important of course for the protection of individual rights that's probably the most common argument I think it's important to protect against not necessarily I mean not only violations of sort of civil rights but also surveillance capitalism leading to a kind of profit-driven nudging or mass propaganda which doesn't you know doesn't in the individual

instance necessarily seem so egregious but can have pretty bad impacts over time um and last but certainly not exclusively at least privacy is kind of the historical default it's easy to forget that until recently we didn't live in a world with nation states and great amounts of surveillance and if you took someone from 50 years ago and up them in today they would find this all very strange and wondered wonder why we haven't overthrown our governments and I've got to agree with them to be honest but okay so probably you're already convinced and I don't need to convince you anyways let's talk a little bit about what would you uh what choices would you have as a user if you wanted to get privacy today in blockchains and of course many of the things people have

talked about today offer additional options that aren't on the slide the slide only includes things that are live and in production so so far users have had the choice of really two kinds of privacy options looking at the entertaining landscape they've had the choice of a sovereign chain which reuse assets of course first to the space and really the pioneer of zero knowledge proofs in this distributed systems context at all was the ccash project then iron fish and some like white sports Z cash other kinds of sovereign chains based to Z cash was on bitcoin monetary policy and sort of single asset single blockchain mentality issue their own assets and at least at the moment it's the only asset supported

on zcash iron fish why cash these other chains is the native asset so if you want to you can achieve full transactional privacy using these systems but somehow you have to get the native asset Zach in the case of zcash and you have to use it and that is uh it comes with some trade-offs which I'll discuss in a second the other option uh the other options available are privacy preserving Solutions which are built on some smart contract chain so return Aztec there's some others on ethereum which offered usually not quite as good privacy as zcash mostly due to gas costs and just the difficulty of constructing these circuits and interoperating with the Curve supported by ethereum but much better privacy than you would get using public ethereum

but both of these options come with trade-offs so if you as a user choose to use a sovereign chain which we issues assets you have to use the asset and often the asset is not the one that you want to use like this is not a super complicated argument um in particular the economic properties of Bitcoin while interesting are just awful for spending money uh usually you don't want to hold a very volatile asset um you know deflationary monetary policy is an interesting economic experiment but it's really like it it's not necessarily going to be correlated at all to the cases or scenarios or sort of everyday contexts in which you as a user want privacy in particular

um and like transactional contacts often you want privacy for payments or privacy for things that you're doing other than holding the asset and this monetary policy is not really well suited to that um privacy Solutions on Smart contracts chains are generally much more flexible with regards to which assets you can use but they tend to offer less privacy than zcash they are more expensive at least you know on average at the moment um and as we've seen recently there are somewhat more vulnerable to censorship both perhaps because you know there are real reasons they're more vulnerable to censorship like the costs of censoring and the ability of say ethereum block producers to deep sensor tornado cash transactions are are kind of they're it's easier to do that and also I think

the Optics of smart contract privacy Solutions as opposed to banking privacy into a full system by default make it sort of more likely to be censored uh based on the way these systems are understood at the moment so what do users want we postulate that users want simple understandable privacy they wanted for any asset most notably the assets they want to use but we don't really know what that is as systems designers they want it to be fast and cheap and strong security guarantees users want everything of course they do and then the final piece of this kind of puzzle of trying to sketch what the design problem is is that users nowadays live on the interchain which is the sort of ephemeral space of a lot of blockchains connected at a lot of

different complicated ways with a lot of assets it's all very heterogeneous but users live there so we have to go there users are going to use many assets they're going to use them across many chains and many applications and most relevantly with regards to how we design private systems users are going to interact with those assets across those chains kind of like Auto magically by which I mean there will be of course systems of bridges and messaging protocols mediating all of these interactions there's a specific way in which it happens in practice but users are not necessarily going to understand it all of the time they are going to click buttons and deposit into Bridges and send funds and they're going to have an asset because they know assets and

they're going to want it in a place like an application place on another chain because they know applications and they are going to click the buttons that get their asset there and the user is not going to think every single step of the way on like what Bridges or my assets being sent through do I lose privacy sometimes what are the complex implications of this whole imperative execution chain users are just going to kind of Click buttons and their asses will move so we need to design for this world if we want to provide privacy to users we need to expect that they will not understand all of the functional details of how these systems work um yeah and adversaries are going to be smart and they will Target the weakest link the weakest link is probably not your cryptography assumptions that would be great if it was eventually hopefully

we get to that world that we think is going to be a bridge it's going to be an implementation bug it's going to be like the query system uh by which users are fetching stapes the adversaries are going to go after the weakest link and the time to head off a future surveillance as long as we're not already too late is now okay so this is what Nevada is trying to do no matter is trying to provide privacy to users in this interchange world making these kind of very rough assumptions about how those users behave and namata has three phases of deployment which I will outline in the rest of these slides focusing mostly on the first the first is a sovereign Sovereign chain that provides acid agnostic privacy the second sort of code named privacy likes

company adds a lot of bridges to interoperate with other systems and the third uh hint makes those bridges private because that makes privacy win-win and later I will explain why so let's go to the first phase first phase one is simply a blockchain that provides asset agnostic privacy most of this is you know old in the sense of like a year or two old uh so old and blocked in terms the Mata is built on top of tender mate consensus so we use the well actually we use an unreleased tender bit version but we will be using tender mint with ABCI plus which is not ABCI plus plus but soon it will be Margaret's gonna kill me I'm sorry Marco um tender it's amazing it has so many ABCI versions that we can choose exactly

the one we want um uh Nevada features both cubic slashing and a trust minimized ethereum Bridge which I'll talk about briefly but mostly I will talk about how we do a multi-asset private transfers and how we crafted a incentive scheme to treat privacy as a public good and why first multi-asset private transfers so Nevada features something called the multi-asset shielded pool the multi-asset child pool allows users to do kind of exactly what it sounds like which is send money privately using any asset in particular the multi-asset shielded pool allows us to provide a shared privacy set for all fungible and non-fungible assets just tokens and it has small and efficient proofs keys for optional disclosure it's available on

the internet I know you can't I considered making the links like the full thing but then it was just super long so you can find the slides online and click the links it really is online it's not fake but the basic idea of the masp is to provide one large shielded pool for everything so that when an observer looks at the blockchain they have no idea what asset you were using and even you know anyone validating Ramada has no idea what asset you are using so it's quite difficult to censor how do we do that well basically a way of summarizing how the multi-acetility pool mechanism works is it's like multi-asset privacy with just one weird sort of cryptography trick the masp starts from as I said old crypto quote unquote the sapling circuit all of the really hard work in the sapling circuit

was done by the electric coin uh sorry electric Coin Company some reason I wanted to call it the elliptic curve company I wonder if that was intentional okay the elliptic curve company also knows the electric Coin Company they did like all the real work we just kind of modified it a bit um so all credit to Dara and strad and some of the amazing circuit designers at UCC um the masp works by adding an asset type to each note calculating an independent value base for each asset type and that is surprisingly enough so let me explain why let's go back to sapling I know sapling's old do some people remember sapling who remembers sapling you if you've used Z cash in the past few years you've probably used sapling um either you know slightly uh in the past or to turn style your assets so

um stop playing in two slides first slide notes value and sapling is stored in notes so it's like the utxo model and notes and sapling consists of four elements you can think of notes the two both four elements the first element and second element or the diversifier of the recipients show the payment address and the Diversified transmission key of their recipients Shield a payment address so these are just to specify who can spend the note V is the value of the note just a um uh integer and RCM is a random commitment trapdoor so we see here that there is no specification of what asset because sapling only supports one asset as a cash or a sec how do we check that a transaction balances so sapling uses this cute

balance check based on homomorphic Peterson commitments and the cool thing about homomorphic Peterson commitments is that they are homomorphic so you can do this you compute commitments value commitments for each there are two you see here there are four notes involved so these are two spends and two outputs and you commute compute value commitments using something called gzac which is the value base for Zach which just in the sapling protocol is just a constant then V1 V2 V3 before those are the specific values involved in your transaction and R1 R2 R3 R4 along with about equipment random in a space those are Randomness like trapdos so um using this you can use this to compute the value equipments and then

this uh the second check actually happens in public because these are like homomorphic because they don't reveal your values you check that when you sum the spends and subtract the outputs and subtract the value balance the transparent different so if you're like shielding or unshielding value balance is not zero you check that that's equal to H raised to the uh binding secret key so this because these commitments are homomorphic uh holds if and only if your value is actually balanced which means that the sum of your spends less your outputs is equal to the difference in transparent value change and you actually like knew the randomness so we can modify this by just adding new

value bases um the first way we do this so the first thing we want to do in the masp is to add an asset type and this is quite simple just take our four Tuple notes all the way back from the original sapling and add we're gonna we're actually going to create three things here because we need to do some user-friendly derivations so we first start out with the asset name and the asset name you can think of as like Bitcoin or ethereum or like my fun penguin token the acid name is the thing users are going to know and refer to the assets by from the asset name using it doesn't really matter from the circus perspective but using a hash function we can derive the asset identifier which is

a 32 byte string so fix-length string that uniquely identifies the asset a slight caveat to this or just a new Point node which I'll explain in another slide is that the asset identifier not every 32 byte string is a valid asset identifier we want it to be a valid sorry we want it to be a blade2s pre-image of a valid asset generator so we use some simple rejection sampling to derive asset identifiers from acid names and this just like simplifies our life otherwise it would be more annoying yes the generator is a valid Twisted networks curve point on job job and that's what we actually use is the value base so if we go back here to this balance check and sapling you see that

thing gzec that's the value base for Zack and it's just a constant and the only thing we're really changing in the Mas p is that we're Computing that value base now kind of dynamically and we're Computing separate independent value bases for different assets so how do we do that we take the asset name and we derive deterministically some asset identifier that needs to be valid and for it to be valid we need the blank 2s image of the asset identifier to be a valid twisted over its curve point and there are actually three ways that can fail so what are they one it could be a small order point it's very unlikely but we still need to test for it two it could be an integer which is

at least the order of the underlying field which you would think we could take modulo the order but the problem is that that's not uniformly random and we want it for security property reasons to be uniformly random um so we reject those and we reject when there's just like no point with the given y coordinate which happens approximately but not exactly 50 of the time and just iterate a nonce until the um asset identifier is valid so using that method we can derive from an asset name which is going to be like tracked and the protocol there'll be some registry of assets um we can derive asset identifiers that correspond to valid asset generators any questions on this so far cool

so now we modify the balance check and the only thing we're doing is we're just using our additional value bases so here instead of gzec we have ga1 and ga2 those are the value bases for asset1 and asset2 we compute the input and output commitments as before just using these different value bases and we the only thing we do to modify the Val the balance check is that we add there can now be vb1 and vb2 are transparent uh changes in asset 1 and asset 2 and as many assets as you have there can be that many transparent balance changes of course we can like look at what they the zero ones we can we don't need to bother Computing but um because the value bases are independent and we still have homomorphic Peterson

commitments this holds only if the assets balance independently so if I have 5x and 5y and spend to create 5x and 5y this first V1 minus V3 will check that like 5x equals 5x and the second V2 minus V4 we'll check that 5y equals 5y which is the property we want we want to check the balances um or independently conserved uh and the basic security property here is that assuming the elliptic curve discrete logarithm problem is hard previous could not obtain a relationship between uh these generators so um we have like the kind of regular

security here and as a result we get multi-asset privacy multi-asset shieldable transactions can include spends of any number of assets The Observers cannot including the the say validators of the Mata cannot distinguish which assets are involved and we retain all the great benefits of sapling viewing key uh key derivation Etc but let's go back to our users and our users are lazy and they are strategic and they want to do things which are cheap and they want to only pay for something like privacy when they need it so we can think about privacy as a public good in the following way for most transactions users probably don't

care about privacy or if they like consciously reflect on it you know do I really need privacy for buying coffee I mean am I going to go prosecuted for buying coffee in this specific instance probably the answer is no and if I have to pay for this you know I'm only really going to pay for privacy or if I have to go through extra trouble to get private transactions I'm only going to do that when I have some strong reason to do that because the private benefit for me of transacting privately is you know low or kind of negligible or hard to think about except in specific cases there's a public benefit to my transacting privately which is that even if I don't care about you know whether this specific transaction of buying coffee is private when I choose to do that transaction privately instead of

publicly other people get a larger Shield outside so there's this public benefit and for this reason we think that this public benefit of privacy should be somehow captured in the incentive design of private systems because when a user makes this choice we want them to you know if they are giving benefits to other people by transacting privately even if they don't receive private benefits for doing it and if we can find some way to send a little bit of that flow of that value that other people are getting back to the individual then we have a system which is better incentive aligned as a whole and people will have more privacy so for this reason we made another circuit um and uh traditional to the modest tactic of taking uh the sapling circuit and modifying it in the minimum amount

of ways possible this is a separate circuit but it kind of interoperates very cleanly with sapling and I will explain how so the basic idea here is that for Designing designing a sentence for private transactions is actually really hard for some pretty fundamental reasons there are kinds of you have to balance between wanting to design an incentive mechanism that gives people a reason to transact privately and not suddenly making yourself vulnerable to denial of service and not incentivizing garbage because the thing you want to incentivize is like real transactions being private and the protocol has no idea what a real transaction is so it's like there's some fundamental impossibility there but what you can do which is slightly more limited is incentivize value at rest being private

which means that if people keep value in the shield of pool they can accrue some incentives and if people sort of of transact you know there's a layer of indirection here but if people are transacting privately by default and keeping their value in the shielded pool as a virtue of that they will receive incentives for this so we built a circuit called the convert circuit which just does that it distributes rewards proportional to the amount of the amount of a particular asset and the length that amount has been in the shielded pool multiplied by some proportionality constant for the asset this works by uh actually it works by making assets non-fungible but because we're in the shield of pool we're okay with this because it doesn't entail loss of privacy so basically we tag in our system we have quantized time but it

doesn't matter you could also do this without it we have proof of stake epochs say once a day and we tag assets with the uh with an Epoch so instead of it being like you know X coin it will be X coin ebook One X coin ebook two users can use the convert circuit to upgrade their assets to the latest Epoch and when they do that they can claim server Awards so what this means is that assets earn a kind of I'm not sure about this term we're going to have to think about it yield as dangerous dangerous word but uh assets earn a sort of privacy yield over time which differs from defy yield and that it is risk-free there's no you're not like taking amm impermanent loss risk or something else it's just a subsidy for providing privacy for other

users as a virtue of holding value at rest and it's important to note that this is not I mean there are multiple kinds of privacy so if you think about the zero cash trials the cash child and masp style transaction models you might care about privacy in terms of what inputs could your transaction potentially have come from and this incentive mechanism is very good for that because it incentivizes value at rest and value at rest corresponds you know pretty directly to potential inputs which a transaction could have come from but you might also care about privacy like how many people sent transactions within this 10 minute time window and you know given that I send a transaction how big is my anonymity set there this cannot be incentivized so we can't provide that except indirectly by you

know this potentially this incentive mechanism giving users a reason to have more transactions just be private in general I can repeat the question uh the question was before I go on can I explain what users upgrade assets the latest Epoch and claim rewards means yes um can you give me one slide in between thank you um so how do we do this I promise we'll explain it um we made the circuit called a convert circuit the Circ convert circuit does another magic trick with homomorphic Peterson commitments it's the same magic trick we just do more of it actually that allows minting and burning of assets according to fixed and public

ratios so um the masp alone if you recall to the balance check earlier just checks that the homorphic value balance is zero but the masp with the converged circuit checks that either the homomorphic value balance is zero or that it is an allowed non-zero conversion how do we do this so the convert circuit it's very simple it takes an allowed conversion is just defined as a list of tuples of some assets and integer and these can be negative so you might like take one asset and convert it to another asset then the first would be negative the second positive the convert circuit takes a public input of a Merkle root and the value commitments that you want to prove is valid it takes a private

input of path and position which just inputs the marker proof um the conversion commitment um value commitment and some Randomness Randomness trapdos and checks that the commitment that you're using is a valid commitment inside the miracle trade so why do we need to Circuit at all the reason why we need a circuit at all is because we don't want to reveal uh what conversion you're using if we revealed what conversion you're using it would reveal which assets are involved in the transaction and that's the thing we wanted to make private but all this allows you to do is change the balance check so now we get to add this term to the balance check so if you recall back to the multi-asset

shieldable balance check we just had these like value commitment in minus value commitment out and here I emitted the transparent balance change equals zero with a convert circuit now we check that the value commitment in plus this new term this value equipment convert minus the value equipment out is equal to zero so this means that the difference here can be because we have the CB convert term and CB convert can be a valid value commitment for any conversion which is in the Merkle tree which we just proved with the convert circuit this means that the difference is allowed to be a multiple of an allowed conversion and because again these are homomorphic commitments um we can check this while preserving privacy the assets involved and which

conversion you know relatedly which conversion was used so um let me explain a little bit more about the epoch mechanism so the idea here is that when I as a user deposit assets into the shielded pool those are going to get you can think of them as getting tagged with the epoch so I have I have Chris Coyne right who wants to accept Chris Coyne I have chriscoin and I deposit Chris Coyne into the shield of pool this the current Epoch is 10. so this now becomes Chris coin 10. and Chris coin 10 you know some if someone deposits Chris Coyne tomorrow that will become Chris coin 11. so these are like these you know seemingly seem to be non-fungible assets which is weird but because we have this masp we already

have asset privacy so you're not you know you're not really losing any privacy by doing this um you're just always converting to the current Epoch then in this convert circuit or in this conversion Merkle tree we add tuples and these tuples allow you to convert assets of past epochs to assets of the current Epoch and they might if you're lucky allow you to claim some additional asset so particularly in namata we have a native asset called nem and Nam can be Minted as you know via some calculation as rewards for keeping assets locked in the shield pool we do this with PD controllers which I'm going to skip because I don't have enough time but it's like EIP 1559 plus plus just with an additional D term so as a user I can

convert from assets of some old Epoch to assets of the current Epoch and like claims of Rewards and this can be mostly abstracted away from users when you withdraw from the shielded pool you're always like convert acid of the current Epoch just the regular asset so it's as if um you were using something without this Epoch tagging the epoch tagging is a pretty you know invisible mechanism to allow these rewards to be calculated so phase one um asset agnostic privacy chain I'm going to skip these two slides sorry phase two um is adding Bridges to other privacy ecosystems why privacy loves company um we actually put together a proposal for a bridge to Z cash you can find it on the community forums

um we might build a bridge to ilio unless someone else does in which case we don't need to penumbra thankfully uses IBC if so all of our work is done for us and the important part here is starting to think about privacy as a promise to users so you know safe use of technology is conditioned not only on the cryptographic capabilities of the underlying protocol but also also on users understanding how it works and what kind of privacy they get and I think it would be good if we start thinking about like a wallet that only supports chains which offer this like strong privacy model right because that's a credible promise you can offer to users but now in this world of separate privacy chains we have we live on privacy Islands um and once and you can admit you've

also done it once I looked up okay are there private islands in the world can I like get a private island and there are all these advertisements for like private islands in the Bermudas and you know I thought about it and I think these people don't understand what privacy means because if you were the only person who owns an island and I have satellite photos you have an anonymity set of one right so privacy Islands kind of suck and they also suck in this case because private islands uh mean that we're competing on privacy you lose private if you lose privacy whenever you move between islands um then if I use your chain instead of some other chain you get more privacy but the other chain and uses of the other chain get less privacy so these private islands have to compete for users to maximize the Privacy they can

offer which is Sab so in phase three of Nevada we're trying to make privacy win-win and we just do that with private Bridges how do private Bridges work well in principle it sounds very simple you just keep the transfers over Bridges private if you have a zero cache style node model you could just like send the notes over IBC or something and this allows all chains to share a privacy set which means that if I use one private chain which is connected to another private chain both their anonymity sets increase which is great the one small stack we hit here is Fault isolation so let's go back into IBC security very quickly to explain what this means so IBC provides very strong fault isolation because it was designed by paranoid

people and so far this has not been necessary but IBC is designed for a world where not only validators but also whole blockchains or Byzantine and this design allows us to provide permissionless interoperability which otherwise very hard fault isolation and IBC Works via something called balance tracking which is exactly what it sounds like which means that each chain tracks balances of other chains when I send from chain a to chain B using IBC chain a tracks which assets have been sent to chain B and when chain B sends them back chain a makes sure that chain B is not trying to send back more assets than it was originally sent in the first place so this requires metering of how many assets are flowing from one chain to another privacy of

course seems like it will just break this because if you want to provide privacy on amounts and assets then how can you meet her which amounts of which assets are going to the other chain and without without fault isolation at least in the long term Bridges just probably won't work because there will be Byzantine chains so what do we do we add more cryptography um simple way of doing that is that we keep an encrypted counter for chain balances and we increment and decrement the encrypted counter in the standard ics20 as reference to the IBC across the internal spec we increment and decrement the counter in the standard ics-20 fashion and then we somehow make sure that we can test that it is non-negative when we send back from B to a and to

Somehow Here the third bullet point is the part that's like actually hard and we're currently trialling a few protocol designs um one on based on NPC and some threshold decryption to do this non-negative test as efficiently as possible the great part about this design it requires some fancy cryptography but it gives you both things that you want in all of the ways that you want them you retain full privacy and you retain the full IBC standard full isolation so we actually do have a draft protocol for this on hack MD I think link you can find it if you click that link in the slides okay very quick shout out there's a namata I have one minute left there's a mamada trusted setup um it's happening like very soon in a few weeks please participate in it it

would be super helpful um and hopefully phase one will launch later in the fall uh thank you and I probably don't have time for questions but thank you very much [Applause]