ZKVs Cosmos Privacy & ZKP Showcase - Penumbra with Henry de Valence
29 Mar 2021 · 19:43
Henry de Valence presents Penumbra at the ZKVs Cosmos Privacy & ZKP Showcase, an event exploring privacy and zero-knowledge protocols built within the Cosmos ecosystem. Featured on the Zero Knowledge podcast, the talk covers Penumbra's design as a privacy-focused chain and the zero-knowledge techniques behind it, part of a broader showcase of ZK-powered projects built on Cosmos.
Speakers
Topics
Transcript
welcome to the stage henry david lance who's going to be giving a talk about penumbra take it away yeah um let me just um awesome all right um let's go uh so uh penumbra is the uh project that i'm gonna be telling you about today um what this is you know really it's a kind of public research project at the moment and the idea
is trying to think about how you could potentially integrate privacy and proof of stake so uh my background is more on privacy than proof of stake but um i think most of the people who are already in this event are probably convinced that like proof of stake is you know pretty good in the future and so on um but uh privacy obviously um is is pretty important um there's a lot of you know detail about that why that is in the previous talk um i think the the the downside risk of not having privacy
is um pretty underappreciated um if you think back to the 90s for instance there was this whole thing of um uh you know whether or not you needed uh transport encryption for websites and it was only after the snowden revelations that people really kind of got onto that that that was a problem and so there was sort of like 10 years of delay 20 years of delay um but with blockchains everything is much worse because um instead of ephemeral communication we're talking about like permanent immutable data um so privacy is pretty important um how could we integrate it with proof of stake
and uh so penumbra is just sort of uh some notes and research on how that that might happen and thoughts on mechanisms that you could use to do private transactions private delegation private governance and potentially also private swaps um so i'm going to go through each of these in turn um for private transactions um as you know so the the transaction model um as was just discussed like a great uh starting point is this um sapling style uh shielded utxo model so instead of utxos you have notes
but unlike utxos uh notes are not going to be part of the public's chain state instead the chain state is going to include only a merkle tree of commitments to notes called the node commitment tree and the way that this model works you spend a note by proving inclusion of the note in the chain state and then revealing a nullifier that would prevent you from spending the same note twice there's some other steps but it's not that important and you can build transactions in this model as a sequence of descriptions of actions and each action adds or subtracts uh from the value balance of the
transaction so in the sampling scheme you you just have uh spend descriptions that create uh or that spend notes and add value into the the transaction and output descriptions that create new notes and subtract value and in this model there's no accounts and there's no long-term identity which is really great for privacy because if you don't have some information if you don't even have a concept of that information then obviously it's much easier to not reveal it because it's just not there so you could think about how you could use this model with ibc assets
the sapling design can be extended to support multiple asset types and this work is already has been done by members of the zcash team in the context of zcash where it's called user-defined assets and one of the interesting things about cosmos right is that in um in the context of z cash there's some complexity to this design because you have to work out how we're going to do issuance of these tokens how do we name them how do we absorb them but cosmos already provides standardized means for all of those things you have issuance by inbound ibc transfers absorption as outbound and the naming is also standardized so a lot of that
complexity that was sort of the open questions for the zcash proposal are you know kind of gone and what's pretty cool is you can actually do direct shielding of ibc transfers right so um ics 20 specifies this sort of fungible token packet data structure with a denomination amount sender and receiver and these sender and receiver are specifying accounts on the source and destination chain respectively so if you have only this shielded model you have this potential problem that you know there's no account but um it turns out that you know the receiver is actually just a string so you can create an output description
that proves the creation of a new shielded note and just stick that right into the receiver field so that seems like you know it all works before talking about the private delegation and private governance and so on um there's two kind of prerequisites for things to make sense that i'll just mention um the first is we need some kind of homomorphic threshold decryption scheme um and this scheme is we need it to operate on uh signed integer values um and the reason that you're gonna you're gonna want this is that you can have then validators sharing control of a threshold decryption key
and you can basically aggregate encrypted values and then decrypt only the sum um so this is slightly different from what you would have for um i know that there's some ongoing work that we're about to hear about for doing encryption of transactions for mempool privacy um this is related but slightly different instead of encrypting an entire transaction you're only having some encrypted values and you're going to try and do some computation on those values and then the other prerequisite is um in in the mechanisms that i'm going to tell you about there's an epoch system um so just for convenience and
simplicity we're going to organize blocks into epochs with a duration of approximately one day um the validator set the voting power essentially all of the kind of related parameters are going to be determined on a per epoch basis and you're going to use the epochs to do distributed key generation for the threshold encryption in the first block of each epoch so this is slightly inconvenient because it means that you know there's like one time when you uh can't make certain transactions but um probably it's it's worth it um well hopefully um oh didn't do that okay so
um just kind of with those that just with the idea that those things uh sort of exist there's some details in the notes that i'll link at the end about how you can do those um let's talk about private delegation um and and really let's first start about thinking about what the motivation is um the motivation is that there's some kind of challenge with having private staking so this is pretty familiar probably to a cosmos audience but you know in tendermint you have stakeholders delegating stake to validators the validators actually perform the consensus algorithm with voting power according to their delegations and the delegators are getting staking rewards in return
for taking on the risk of validator misbehavior and you know having these uh incentives all aligned um and if we want to have some kind of private system right let's think about what that means um if delegations are pri are public then you have this pretty severe problem that stakeholders have to choose between having privacy or getting staking rewards so there's a financial incentive not to have privacy for each individual person so you know on balance people are not going to choose privacy and also right to have the system work you need to have people staking so
if you don't have private delegations then the uh the staking part becomes this sort of um or the the privacy part becomes this sort of extra sort of opt-in thing and then you have the bulk of the value in a uh an unprivate way um and and that doesn't really work out very well for actually getting anonymity but if you have private delegations on the other hand then you have this problem of like how does the chain actually pay out staking rewards if you don't uh reveal who has delegations how do you reward them um you know could you build something that
could do that it would probably be complicated so the idea is like actually you know whenever you have a problem that seems kind of hard to solve instead of solving the problem you could just like not solve the problem and then just like not deal with the problem at all so how could we eliminate staking rewards entirely the idea is we should treat unbonded steak so i'll call that pen which you could think of as the well it is the staking token for this scheme um we're going to treat the unbonded steak pen and the bonded steak pen b as two uh distinct assets and uh this pen b is going to be actually a kind of first class
staking derivative um with delegation fungibility what i mean by delegation fungibility is that all of the delegations to a particular validator should actually be on a completely equal footing you don't need to record anything else it's just a share of a delegation pool so because each validator's risk is different pen b is really this like shorthand for a class of assets in fact we need to like specify which um you know each validator is going to have their own pool with their own shares of that pool and this notation with a v is when you need to disambiguate that um and the idea of how you can eliminate staking rewards is that
when you do bonding you're converting from the unbonded to the bonded token and that conversion rate should discount by the cumulative rewards from genesis up to the bonding point or the bonding epoch and when you do unbonding you should inflate by the cumulative rewards from genesis up to the unbonding point so i'll give an example of how this works in a minute but what this means is that delegators are just going to realize a capital gain or loss on unbonding not income um which is you know probably convenient for their accounting
but um all of the the actual uh delegations are completely fungible and you can record them just in normal shielded pool um so to to to have this system work there's some delegation parameters um the first and most important one is this uh base reward rate um which we're going to write as r sub e and that's um indexed by the the epoch so it can just as in the um uh the cosmos hub right you can have a kind of formula that adjusts based on the amount of actual stake um you have a per validator commission percentage so
you know actually running a good validator means that you need some sres and that's expensive so um there's a way to have commission and the commission is applied to the base reward rate to get this per validator rate so you can think of the um you know this base reward rate is sort of like the blockchain lee board it's like the reference rate for the whole rest of the system and the per validator reward is the um the base rate you know minus some spread that's going to be taken as commission um and this conversion rate that i mentioned um is the product of this reward rate over all of the
epochs up to uh e so this is the the formula for the base rate you can get a formula for the per validator exchange rate by substituting the per validator reward rate and this is sort of like the total amount of compounded um interest no one thing that's cool about the system is that you don't have this you know when do i withdraw my rewards and then redelegate them everybody gets caught compounded at the same rate automatically um and the mechanics of that right so if we delegate x amount of unbonded pen at epoch e1 we get x divided by
this uh per validator rate psi sub v and when we undelegate uh we multiply by psi sub v but now at e2 the epoch where we're doing the undelegation and if you compute the the total return you get psi v of e2 divided by psi v of e1 and since these are both you know two big products um the the discounting that you do when you do um delegation gets count gets uh cancelled away by the inflation that you do on undelegation and what you're left with is exactly the
reward rate for that validator compounded only over the interval uh during which those tokens were actually uh bonded to that validator but you get that without having to actually track that in any way on chain all of these delegations are still um you know everything within a particular validator's delegation pool is completely fungible and it's actually just another token right it's a first-class staking derivative so you can move it around send it you could even send it over ibc if you if you wanted to build some kind of pooled risk thing you know potentially you could do that
um there's no compatibility issue and another thing that this lets you do pretty nicely is you get to do some private governance so the cosmos hub supports doing on-chain voting but now because the holders of delegations are anonymous you can now do anonymous voting and the way that this is going to work is that the holders of bonded stake can vote privately using these special descriptions they're going to spend a note create a new note encrypt the
amount that a new note with the same amount of stake and then encrypt that amount as their vote to the validators the validators can use this uh homomorphic um threshold decryption to aggregate and decrypt all the votes and you can prevent um uh double voting by just proving that your your your note already existed before the voting began um and there's a way to do delegated voting that's in the notes um and finally you can also have some kind of private swaps um and with the the mechanics for that are
are basically that a user is going to create a swap description revealing only the asset pair that they want to swap and then they're going to encrypt the input amounts and burn those funds so it's sort of like a provable burn where you don't actually reveal the amount that you have burned and you create this kind of swap commitment that's going to be analogous to a note commitment that allows you to later establish that you did you know burn funds in a particular way once all of these are um included into the chain in a block or
maybe you want to do longer batching then the validators can aggregate all of the encrypted inputs to the swaps decrypt only the net flow um and then compute a clearing price and some updated liquidity reserves include that in a block and later users are going to use this swap commitment to mint new funds and prove consistency with the inputs that they previously burned this is pretty cool because there's actually no interaction required between um uh you know the users or the liquidity pool that's required and there's not any
actual like direct you know you don't have to manage coordinating state between these different parties because everybody gets to have their own little private state and the consensus just proves that um all of the burning and minting kind of nets out so um this kind of the current status of this is that it's just some ongoing public design research i want to try and see whether these ideas make sense there's a lot of details to fill in there's a lot of more detail than in the slides um inside in these public notes that are are linked there um and there's a discord link on that uh website that you know if you want to
talk to talk about any of these ideas um you could that would be a great place