ZKVs Cosmos Privacy & ZKP Showcase - Threshold Decryption for mempool privacy with Dev Ojha

Transcript

okay uh hopefully you can see the screen uh yep looks good so hello i'm dave oja today i'm gonna be talking about threshold description for mental privacy i'll give it like a brief intro for myself uh i've been working i started working on cosmos things around three years ago uh working a variety of things around l1 scaling and research and just also design for things like feed distribution and i've done a lot of things across stack if you check the github you'll probably find a variety of issues for me and i've also been working on like snark research uh naming personal snack research the last couple years currently uh help maintain live iop live snark and from the artworks repos

so i'm very excited about xero knowledge proofs and the like but today i'm not talking about zero knowledge fruits despite them being near to my heart we're talking about threshold decryption for mental privacy so here's the plan for the talk uh first i wanted to kind of motivate what is privacy then pool and like why do we care and it's just me two reasons sensory persistence and mvb then i kinda wanna talk about you know what is special decryption and some of the subtleties that i don't think have really been gone into like you know preventing silent failure here which i'll explain later how to handle gas and fees and some like notes on the dkg and then i'll conclude by just aside on the trade-offs of different private mental solutions okay

so let's let's dive in uh oh i guess maybe it's a bit of a spoiler but uh on the trade-offs like i think special decryption is has the most appealing trade-offs hence that's the overall focus okay so privacy temple currently mempos look like this where we have a bunch of transactions that are public and a private mempool roughly is like we want to make it so that you have no idea what's in the transaction all you see is the fee uh and just because you basically need the fee in order to do simple resistance so informally i'm going to be using the term private mempool to mean like a blockchain where you can make such that only the

transaction creator knows the data until the transaction is final included in a finalized block and once it's in a finalized block there must be a guarantee that the transaction data will be decrypted and if it's not decrypted then the blockchain will literally halt uh this is important to just you know stop the miner from like just withholding a decryption for instance all right all right i'm also going to be using minor and validator interchangeably on block proposer uh it's all the same for this talk like uh and your but special description is really only going to make sense in the proof of stake setting cool so here's one of these cases of it censorship resistance so

there's two kind of properties of blockchains today miners can choose any transaction that has uh confused any a transaction include that have some minimum v and cosmos this minimum is literally zero in ethereum post efu1.9 it'll be above this you know network threshold minimum for burning and then second property is that the miner can see the entire transaction content prior to choosing what they want to include and combine these two properties and then we get that a minor or a validator can like censor my transaction for whatever reason you know they just not like me and want to block me from accessing my funds maybe my transaction caused them some

financial loss like i don't know i'm buying something on uni that would uh make their token go down in value and they don't want this uh so this is uh sorry this is bad you know uh maybe here's a more like serious another serious reason is that maybe there's a government uh agency who wants to block some certain some group of people from accessing the financial network for uh nefarious reasons and so we don't want to let them do that and you know things like feather forking makes this actually very plausible even if you have a small percentage of uh stake slash hash rate so the goal is we want to eliminate the

ability for block proposers to see transactions like transaction data before uh before the transaction is finalized and we're going to be using memphis privacy to eliminate that and therefore like eliminate this censorship on purity uh quick note there's still more you can sensor on like the iphone active sender and we're going to need uh some p2p anonymity tricks to fix that uh this is why nim is very exciting or tor for p2p things okay so then i want to switch to like motivating the second thing which is you may be more familiar with it's like mev or minor extractable value where essentially block proposers in blockchains have some special powers that uh you know normal

full nodes don't so uh well they can read transactions with their mempool which i guess everyone can uh control inclusion transactions in their block proposal and reorder them and they can do like some census boat censorship like selfish mining things but i'm going to ignore that for this talk so but these three properties reading transactions controlling inclusion reordering gives them some kind of scary powers uh or maybe not scared nefarious so you may remember the theorem as a dark force post from dan and georges uh basically on ethereum there are some hacks uh and people wanted to get a white hat to turn

the funds but there were bots where uh basically stole the hacked money and gave it themselves so you know you can steal arbitrage opportunities these uh and says you get financial assignments to do so the second thing that's bad is like front running where uh i'll switch this to like flashing context i'm explaining like the simplest form of front running where i want to buy i don't know a million eth on a btc eth uh so the miner sees i want to buy a million years so then they instead will buy some eat right before me like i don't know and then and then i buy eve so the price goes up

and they sell their eth and so i the buyer got a worse price but the miner got kind of risk-free profit there's a lot of there's a large amount of things in front running but uh i just keep this the simplest one for now uh yeah that kind of decide because zocco is asking for business use cases and i didn't have much on it earlier so you know to quantify a house how much of a problem this is uh there's this group called flashbots we've been doing lots of mev research and so there's this post from february he's showing that in their initial uh in their initial tooling to underestimate the amount of mev that's on ethereum they found over 300 million that could be stolen like this

so this is actually a real problem so we're going to want to use uh like mindful privacy to fix this so all those powers i listed earlier that kind of implied those above attacks uh we can solve reading transactions to the member by having mental privacy this is kind of like a direct implication by the definition because you can no longer see the transaction data therefore you can't really front run or arbitrage uh you cannot we can also block your ability to control inclusion of transactions in your block by having multiple validators or uh contribute transaction data for a single block it's kind of like we take leader

election our leader like block proposals and make them a little bit more leaderless or like a multi-leader and then we can reorder uh we can solve their ability to view our transactions in the block proposal by memph well one mempo privacy kind of eliminates the useful things that we order based off of so with just that they could just try to make themselves the first transaction the block and last but by also adding having multiple nodes contouring transactions and doing a provably randomized ordering of uh of transactions we kind of eliminate their ability to choose the order

because you can you can imagine that to get approvally randomized ordering like once some encrypted transactions are finalized and decrypted you uh kind of take the decryptions and uh yeah basically you see that into some pseudoran function and get a new order and you can prove that this is uh or then you just exit execute or across this using this new reorder version so basically like if we have mental privacy we can kind of use these generic techniques in the proof-of-stake setting or to eliminate these other powers or you know significantly lower their uh their concern hence this is why mental privacy is uh

an important thing to be going for so now i'm going to switch to threshold encryption and kind of try to explain what this is but before i can explain that i'm going to explain classical bt consensus so classical pft is kind of like tendermint or hot stuff so a bunch of validators and they all have the same block proposal okay so then everyone votes on a small proposal there could be multiple rounds of voting but for now we're just going to care about the last round of votes then they gossip around the votes and then uh some and once you get a threshold of votes on a given block proposal you can finalize that block

so note this by having a little nice little lock here and then okay once we have a finalized block uh we basically all right let's finalize block we just go to the next block and then uh you know keep proceeding but the key thing is we need a certain threshold of votes to be given and in tenurement or eft in general the best you can go or you kind of want two-thirds to be uh of votes this is just because of some things where in bfp this is the best you can achieve or this gives you the best tolerance so now threshold encryption within tendermint so

what we do is it's that before the block proposal had you know just plain text transactions now they're going to have encrypted transactions and these transactions are each going to be encrypted to some like special public key that violators have so like as a client when you when you make a transaction you encrypt it before gospel network okay then what we do is before we used to all just vote on a block but now when i vote i'm going to vote with a decryption share uh included so a decryption share is like what it's doing is for every transaction the block i'm including using some of my private key some extra data

and then if i have enough of these extra data on these subscription shares you can combine them to get the underlying data so everyone includes description shares along with their votes then we all gossip our votes and decryption shares and then we gather all the votes and decryption shares together here so you know we need a given threshold of votes for finalizing block and now we're going gonna make the decryption threshold the same as the voting threshold so since i've received two thirds of votes i've also received two thirds of decryption shares and then using those two thirds of prescription shares i as the next block proposer can then uh decrypt these transactions that were

finalized so the important thing is that since i had the votes on this on this block we know it was finalized so when i decrypt it uh i can still see oh there's minor okay so i can decrypt these transactions using this then uh so i is a netclock proposal or uh you can see the transaction plaintext okay i guess these should still be blue and green it's my bad so now when i propose the next block what i'm going to do is i'm going to include these plain texts along with some new cipher texts like this red and purple thing is my new blog proposal

so i'm including the last blocks decryptions and the new blocks like ciphertext and i gossip this to the network now everyone else every other validator upon receiving my new block is going to check that uh these new these decrypted transactions are equal to the uh encrypted transactions are a valid decryption of those transactions they had before and then we proceed with consensus on uh both this pair of like new encrypted transactions and old plaintext transactions and so then like we've we've done a full round of consensus and gotten new plain texts

along with the new set of ciphertexts to uh start consensing on so summarizes that a bit that's kind of technical when a block is proposed all constituent view transactions are going to be encrypted then when a validator votes on a block they include their decryption share for those new transactions in the block so and then the next block composer or uses the crypto shares they got along with those votes to create a plain text like the plaintext of the transactions and then when they propose the next block they include these plain texts along with the new set of encrypted transactions and then basically all full nodes are

able to verify that the plain texts correspond to the finalized blocks ciphertexts so like there's a kind of cool property here where only the next block proposer had to receive all the decryption shares the full nodes and even other validators don't have to so these decryption shares don't actually blow up like the cost to sync or cost me a full node it's only extra bandwidth cost for the validators though i guess i'm an addict aspers but you know this is actually a kind of notable extra bandwidth cost like uh per validator is around 200 transactions sorry 200 bytes per transaction and it grows the number of transactions

if you want homomorphic uh threshold encryption it grows even more but this is still like a very nice property to be happy so uh a question we have is that you know can we slash misbehavior all right like you know we need a threshold of valors to not be colluding so you know in proof of stake what we do is we say that uh if i detect you colluding thing you get slashed like if i detect including here's like double signing in proof of stake uh and we say that we write things such that uh oh sorry i gotta think i don't know if it's from john oh okay i'm told i am running out of

time okay so i'll just go through this part and maybe skip the other things so typical strategy for uh proof of stake is that once uh we have pas uh like we say one third cabal doesn't form because if it does because anyone in cabal can report everyone else get them slashed and then keep proceeding so an idea is maybe if i see decryption share so to stop including here maybe i can say i see decryption share for a transaction that's not already finalized i'll slash who created that decryption share but there's a problem validators conclude to decrypt transactions within sdx um since the decryption shares never be

sent to other users they can only exist inside of sgx's so this means that uh the validators can collude inside sgx and then each validator can then just get the description for transactions but and see them if they included and not be slash four thus we can't actually slash validators like this but there is something cool where we can use sdx's and special encryption together in order to uh like basically block validators from being able to include uh i guess i'm running out of time i will skip this actually since i'm running up time uh maybe i should just blaze to the end where uh okay i guess

there's another problem i want to talk about where for gas and fees we need the gas and fees to be public so uh like you basically need to prove that the transaction sender wanted a given gas amount and a given amount of fees uh so we can solve this by making an aad-like scheme in this threshold setting uh i'm just gonna skip dkg notes as well okay so i'll switch to hop in and see the questions uh okay so from virtuge what properties you need

of special encryption doesn't need to be non-malleable somehow okay so yeah i guess that was the thing i skipped the aad side so what we need is that when i have a threshold encryption ciphertext for a given transaction and no one else we need two things one is that anyone can publicly verify that this transaction this is the valid site for text the second thing i need is that uh yeah it's non-malleable uh and it's non-valuable including this public text data like uh namely the gas and the fees if the gas wasn't was malleable then basically we could you could use this by uh changing the

gas to be one including in a block having the transaction fail and you get to see the transaction the decrypted contents uh second question from henry is why does the data per transaction grow in the encrypted the homomorphic case so this is because the way threshold decryption works or encryption works is that the user makes a kind of a symmetric key yeah and uh they make it symmetric key and they encrypt to the uh and they do special encryption on the symmetric key and they and they encrypt their transaction content uh with the symmetric key so you only have to threshold decryption on this like nice symmetric key but if you want to be homomorphic

you actually want to have kind of two blobs one is a symmetric key and the second is whatever you want additive homomorphism on which then requires more data per share so you have to have uh you have to basically do special properties on both homomorphic thing and the symmetry key uh can you make your slides available yeah i will do so uh okay so are you writing your own homomorphic encryption scheme or is there a library uh okay so i'm not writing a homework encryption scheme or like we're not for threshold description we don't need that there is this paper that uh we're collaborating with helix folks oh i just wanted to give a shout out to joe beville who's been doing a great job on like designing the job from helix he's been doing a great job

selling a dkg that's suitable for this use case and so we're collaborating with them to write a threshold encryption library using this paper called bz03 which is kind of based on bls uh you might not need to do pert from another question finally you might not need to do per text decryption in the homomorphic case oh that's valid okay if you only wanted to threshold encrypt just the uh what you want to be home morphic then it probably is equivalent you're right we'll uh go ahead and wrap it up there thank you so much dave for the talk super interesting and uh we look forward to getting your slides once they're online

so folks can check out the rest of the talk