Episode 330 - Frameworks for Programmable Privacy with Ying Tong and Bryan Gillespie

Transcript

[Music] welcome to zero knowledge I'm your host Anna Rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online this week GMA and I chat with Ying Tong and Brian Gillespie we get to know both of these researchers and what brought them to work on ZK specifically we talk with Ying Tong about her work on zcash working on the Halo 2 system and some of her subsequent contributions at

geometry research we learned from Brian about his journey to working on ZK also via zcash and has worked today at inversed Tech we then dive into their recent work which examines programmable privacy in distributed systems we tease out the classifications and framework that they introduce to better evaluate and compare different applications that offer limit order auctions using ZK or related Technologies now before I kick off I just want to let you know about our upcoming event ZK hack Montreal happening August 9th through 11th in case you don't know ZK hack is another project that I'm involved in it's a hub for ZK learning which is very much community-driven and as part of this we produce virtual as well as IRL ZK

focused events the next one of these events is ZK hack Montreal bringing our IRL hackathon series to my hometown now zck Montreal will be happening as mentioned August 9th through 11th and it promises to be a very special one being the first time we host our hackathon Series in North America some of you may be attending SBC the week leading up to the ZK hack weekend luckily it's just an hour flight from New York to Montreal so you can easily do both events plus you get to hang out in beautiful Montreal for the weekend and hack on ZK tools meet experts in the field and maybe meet your future collaborator ERS or co-founders at ZK hack Montreal you can apply and also find out any updates about partners and judges over on ZK

montre all.com I've added the link in the show notes so yeah we hope to see you there now Tanya will share a little bit about this week's sponsors Alo is a new layer one blockchain that achieves the programmability of ethereum the privacy of zcash and the scalability of a rollup driven by a mission for a truly secure internet Alo has interwoven zero knowledge proofs into every facet of their stack resulting in a vertically integrated layer one blockchain that's unparalleled in its approach Alo is ZK by Design dive into their programming language Leo and see what permissionless development looks like offering boundless opportunities for developers and innovators to build ZK apps this is an invitation to be part of a

transformational ZK Journey dive deeper and discover more about Alo al.org and now here's our episode today garmo and I are here with Ying Tong from geometry research and Brian Gillespie from inversed Tech welcome both of you to the show hi I'm so glad to be on ZK podcast yeah it's awesome to be here hey G what's up so Ying Tong I feel like this episode came about because I mean we started talking about having you on I've known you for a few years um but I'm really curious to find out from you what got you excited about cryptography in the first place what was the thing that brought you to work on

these kinds of problems well I was trained as a physicist and I really got into cryptography via the ethereum project and just the shared hallucination of a world computer um and when I first joined the ethereum foundation I worked with Barry White Hat on implementing I think one of the first ZK rollups oh cool um from the there that was the gateway drug really into zero knowledge and when um the zcash team published their findings about Halo and recursive proofs without sex inness that got me really excited

about the possibilities of Zer knowledge I joined zcash worked on Halo 2 really a lot of the workshops and educational Outreach was centered around Halo 2 and that was really fun really um productive and I'm continuing that Journey now at geometry research as well as continuing to work on these problems of programmable privacy the design space that uh zcash remains very interested in I had not realized that you had actually first started at ethereum and then worked at the ECC I remember meeting you I think it was for like a ZK Summit you

gave a talk and and at the time you were more part of the zcash world going back to that like early experience at ethereum though like how did you connect with those folks coming from like physics that was about to be my question I was like a fellow physicist you know how did you come to the dark side or the Light Side depending on how you look at it I guess well the ethereum foundation had a headquarters in Singapore where I was studying and and they came around my school recruiting not just computer scientists as you would expect but also physicists they explicitly stated that they wanted physicist and I think a lot of our the physics training is not

directly transferable however the reasoning skills and the ability to pick up new Concepts um with a high level of rigor I think were very valuable and helped me a lot in learning cryptography and zero knowledge nice that's so cool I want to come back to for example like the Halo 2 uh workshops and stuff but I I want to first ask Brian to share a little bit about his background tell us a little bit about what you've been working on and why you got excited about this yeah absolutely so I'm uh coming from the the other side of theoretical uh academic backgrounds I have a a mathematics uh PhD and eventually

decided that cryptography was the best thing everol I I too have a connection with the the zcash side of things uh the the blog posts by uh Ariel gabison and others um on the the snark technology in zcash was one of the first things that that inspired me to start looking in this direction um kind of the first and second year of the pandemic I realized that this was just the coolest thing ever and so I took the time to to pick it up and and learn some of these things taught a one semester course uh upper division undergrad at the University near me and uh then I uh I got a job through Twitter through Twitter nice what what kind of math were you doing before though so my uh PhD was in the uh

area of algebraic combinatorics um this uh is looking at kind of discret mathematical objects objects that you can enumerate and count and trying to understand them by looking at at algebraic constructions like polinomial spaces and more complicated things you can say say about them and so it actually really relates a lot to the uh the constructions that you run into in in ZK technology um I'm finding that actually my background really relates fairly well to the the sorts of things that we do when we're studying ZK snarks or uh multiparty computation or other types of cryptography that you're encoding data into into these uh mathematical forms so cool so a random

quick question so like just to get a little bit more of s like algebraic combinatorics would would be things like generating functions or generating polinomial would be like one object that you might study in this particular field I assume yes absolutely um and uh and the idea is to use kind of heavier algebraic constructions like uh people talk about algebraic geometry as a basis for for cryptography you can also use algebraic geometry to understand these these other discret objects in a really kind of deep and useful way what was the first comp or project that you got involved in when you jumped in my current job is actually my first job in the space oh nice um aside from that course that I mentioned earlier uh then I taught at University um so inverse

Tech it's a uh a relatively uh recent cryptography Consulting upstart and I just reached out on Twitter and said hey just wanted in case there's anybody out there looking for somebody with my background to uh say that I'm available and looking for work and uh and my boss uh Daniel uh reached out and and uh and we got in touch nice incredible don't just let your dreams be memes it's very important that you really can keep posting through it I love it an inspiration for us all absolutely that's amazing uh yeah I think this was before Twitter became X but uh the point remains it's still Twitter in our hearts I think yeah so this is Daniel who was also one of the people who kind of

started the ZK proofs event series he used to be part of a group called kit but yeah so I mean we've known Daniel for a long time that's really cool that you that you landed there what kind of work do you do at inversed Tech you sort of mentioned it's Consulting but like is there any particular problem spaces you're tackling yeah it's a really wide variety of different specific types of work uh but broadly it's in the uh the the Privacy space um we're really interested in contributing to open web technologies that present opportunities for people to maintain their personal privacy so this uh this research project that we're working on for uh for programmable privacy as part of that and helping out with other technologies that

are are trying to provide people with the opportunities to stay private and keep their data out of the pen Opticon out there is is really like a big part of what we care about cool all right I want to now Circle back to you Ying Tong and talk a bit about those Halo 2 workshops that you mentioned because to me like when you were hosting those I think you were doing it with the xerx park folks right like I think your workshops influenced a whole batch of projects who have since at least started building on Halo 2 after learning it from you I just want to go back to like how that Workshop idea even came about what it takes to put something like that together like you were part of the team

that developed it so I'm imagine you have you're in it like you're already deep in it but yeah what did you have to do to that material to turn it into a workshop yeah I think Zer park has this incredible energy for finding talent and making these resources available to them and really I was just one person in a really motivated team so yeah What it Took really was just reaching out to people a lot of them came from universities a lot of them came from like the open source projects that we're already familiar with and just a lot of like random

hackers as well preparing the resources and just getting the people together to show up every week be it virtually or you know at a physical location we had a few popups in New York City as well as Boston and San Francisco and it was fueled by this enthusiasm and this sort of eagerness and willingness to learn to explore to build together so at that time yeah Halo 2 was perhaps one of the more advanced ZK proving Stacks out there and since then we've had uh lots of variations on

the original Halo 2 we've had uh significant Forks that are popularly adopted and we've had uh completely new proof systems become open source uh and available such as plony 3 for example ah so yeah I do hope that this culture of learning and sharing continues to grow and I I'm very excited for the next generation of proof systems and I'm excited to see for example client site proving become a reality definitely this tradition of building in the open and

and sharing information and resources with each other is something very precious in this space and I look forward to seeing it continue that's so interesting yeah I just just as an aside I just just today actually met with Zach um from Aztec and we were talking about that idea of like the building in that open way and I was realizing that we live like we're kind of in this very special moment in ZK where there's like well-funded efforts to build in a certain direction and then because there's not an ER of scarcity in terms of just like people feeling funded and like they're not like scrounging for

like being able to live they actually have the space to live and then they can just do the research they want to do you've had this acceleration on the ZK front but it's not replicated in other Industries it's not even necessarily replicated in other parts of like cryptography or math it's just like this really cool moment where people have been able to drive it really quickly but I like that because I think it shows something like it's kind of an example potentially to other fields that like there is this way that you can accelerate things that you think are impossible much much faster than you than you would have imagined and it's not just by like having big companies do it which I think in the past you kind of required like the capital intensive large corporation to

make something like this happen here it's happening from lots of different companies lots of different individual contributors people also of all ages who are kind of empowered to do what they want yeah it's really cool absolutely I think it's a competitive advantage to build in the open and to allow easy adoption of your libraries and your products and there's so many benefits for example more eyes on your cat means more bugs will likely be surfaced that's one of the top advantages of making your code open source I think as the industry matures we're moving more and more towards standardization and having your library accessible means that you're part of the

standardization conversation it means that your tools are not going to be just obsolet with the next wave so building in the open building collaboratively is such a competitive Advantage I think it just makes sense to do it that way I do think there's one other piece and we've brought this up a couple times on show but this is about like patenting things and like locking them down there are even adjacent Fields where you see just more of an effort to patent early and I feel like history sort of shows that like a lot of times in fields like this if you patent early all it does is like

slows down that part of the research and ZK luckily has sort of like accelerated past any previous patent efforts and other patent like what was it like like fet Shamir orn like these the patent expired and all of a sudden you could use it and it just like you saw like this boom happen I think seeing that happen play out should be an example to all practitioners in these adjacent fields that maybe like be careful with those heavy patents even if your company is locked down people may not be able to use your Tech in the long run it's a topic that I'm seeing more and more clearly kind of come into view and I feel like ZK is the counter example of like this is what happens if you don't

immediately try to lock this down early but you actually leave it for like a larger Community to play with before we move on from the Halo 2 work I have sort of a dumb question that I'm pretty sure has been answered at some point on this show which is is Halo 2 using fry is there a connection between fry and Halo 2 the original Halo 2 uses the IPA polom commitment scheme so that's zcash Halo 2 okay whereas there have been sort of forks of Halo 2 that have adapted the front end to work with Fry on the back end to work with small field fry in particular okay so that's one of the

advantages of having a modular proving system is that you can swap out the back end um and you can for example put in different lookup arguments um you can put in different fields different polom commitments but the original Halo 2 used the IPA polynomial commitment okay this might be why actually I didn't know the answer to that it's like I probably have asked maybe back then it it didn't use fry but then I've heard it did use fry okay this is this is exactly why I don't know if you're still following that but like did you see the stir work yes yeah I'm just curious if you have any like

thoughts on it given that it is sort of interrelated with some of the Halo stuff I've heard that stir can just work as a drop in replacement of fry I think it would be really a great Improvement if someone were to implement that I will say one caveat um it's also why standardization is so important so when composing different elements um from across the pring stack we have to make sure that certain security and variants are preserved for example uh whether or not your commitment scheme preserves your knowledge so these questions are what uh standardization efforts aim to

guide and aim to provide a template for but in general it's been inspiring to see just the amount of experimentation that's been done on Halo 2 yeah there's really any number of back ends that have been swapped in and haloed to even like multilinear back ends what was the system that you feel like captured mind share after just in terms of like the chronology of it like just timing wise uh what's caught my eye is plony 2 plony 3 okay that group yeah yeah for example I think sp1 and valita both use plunky 2 or or PL 3 mhm I think

really the speed UPS from the small field um optimizations are very compelling I do think that Halo 2 belongs to an earlier generation of proof systems I would like to see how Halo 2 can be adapted to newer proof systems that are more efficient by the way very dumb question when you say small field fry like what does that mean is it like a small Prime that's like below to the 32 or something or is it like some binary field like what is a what is a small field I guess in this case just for the people who have you know very little idea what ZK is the small field really can go down to

32 bits um that's the baby bear field that risk zero uses for example and it's called a small field because we're used to working with 128 256 or 381 bit fields in cryptography um Fields over which the short zipple Lemma is sort of very secure whereas small field fry pushes the boundaries of that and the reason they're able to get away with that is that they don't rely on discret log hardness they don't rely on having access to a cryptographic group and

because they just use Simple postquantum Primitives namely hashing they can get away with very small fields that are efficient on most computer architectures so I want to shift gears a little bit and start talking about a recent work that you released was focused on programmable privacy in distributed systems this is also partly where this episode comes about Ying Tong when I reached out to you you were like let's talk about this work and we are bringing you on Brian to kind of cover this yeah I want to sort of dive into what this is to me it reads a little like a I mean it's a really good explanation of a lot of the ways of thinking about different systems the

choices that you're making in order to like actually evaluate various projects like companies using variations on some of these systems I think of it as like a bit of survey so yeah tell me a little bit about this work what was the motivation where did theide come from and then we can dig into some of the topics that you cover so this s so originated from the zcash foundation wanting to explore options for introducing programmability onto zcash and really this survey was to get us up to speed with the state-ofthe-art in the industry and also to make recommendations for the path forward for

zcash got it so in my mind there's kind of three flavors of programmable privacy that are sort of dominant in people's minds the first one is this idea of selective disclosure meaning that you can program what you reveal and to whom so sort of The Logical conclusion of selective disclosure would be witness encryption like you spend specify exactly what condition someone must fulfill in order to decrypt some data and this metaphor of selective

disclosure to me is closely related to purpose limitation and access control which might be more familiar metaphors outside this industry and the second kind of programmable privacy is you're programming the attributes that you verify about private data so for example in zcash we want to verify ownership of a note we want to verify that the note hasn't been spent before we want to verify some range checks on the value of the note and a Leo or zi uh generalizes this statement to basically any NP

relation um so programmability in in the sense that you can verify whatever you want about private data and this is also Den notion that's used in Aztec and meam for example is that still in the second category you have the first one with Selective disclosure the second one is this like attributes but like to me it's like programmable verifiability okay programmable verifiability would you so you are putting Aztec Alo all in the second category still I am okay and I'm also putting all the K rollups in there oh wow as well so what's the third the third one is programmable computation

over private data so you think like homomorphic encryption FHA NPC that you have some structured encoding of your data on which you can actually perform any arbitrary computation and this third category was actually the focus of our paper we call it the mediated computation phase uh you'll hear more about it from Brian later but yeah these are the three sort of metaphors for programmable privacy that are the most common in in the industry I think it's really good that you just teased out those three too because programmable privacy yeah I've

I've heard that refer to lots of different kinds and I think it's cool to to see them really outline here you focused on this programmable computation over private data and you sort of mentioned some of the other systems like MPC FH that are used for this but I know that in the work you also do highlight ZK projects so I guess there is a way to do this even in ZK systems is it more complicated I know we're going to probably get to that but like do does ZK actually offer an advantage or disadvantage when you're trying to tackle this problem so I think that the real bottom line is that ZK is a powerful toolbox for doing a certain

type of computation which is private offchain computation where you have access personally to the private data that you're Computing over um so in some sense the ZK class of protocols allows generic computation over your own private data but what we found is that there's kind of a different class of cryptographic techniques we mentioned FH and secure multiparty computation and different approaches whiches maybe even tees yes yes a little bit of a complicated debate over their usage um but there is a usage for them um but which allows computation over private

data from multiple parties so the real real distinction is whether you have the ability to do this computation in such a way that the compute nodes themselves can't see the private data which is very relevant in a lot of Def sorts of applications in particular where you need to kind of combine these pieces um in a in a synchronous way from multiple parties when you say offchain do you mean client side is this like the proof and all of the Privacy is remaining in the hands of the individual or do you mean like it's in the hands of this offchain system but it could still be shared it's kind of both actually ZK snarks view them as kind of a glue

between uh different regimes of trust so one computational engine can do computations and in that computational engine you know certain things and then you want to relay that to a different computational engine say the onchain blockchain virtual machine or something like that um the snark proofs allow you to demonstrate that the computation was done correctly without revealing any more than you need to it's a connector between these different computational uh engines that allows you to separate out the different privacy regimes that are important so this work in particular when I started to read through it like your focus was on limit order auctions or dexes more broadly I don't know if

you know this but like GMO who's here with me he when we met it was in 2021 and guo Alex and tun had done some work kind of almost like debunking that you could even have a private deck but like now in your work you definitely showcased that like there are efforts to do that gam I don't know if you want to weigh in and yeah I mean it was uh the the original version of it was just uh remember people being like Oh just you know take a DEX and just like put privacy on it like you know like the Elizabeth Holmes do a chemistry like version that was like cool but like that just totally doesn't work um because you can just like back out from like really basic information what the underline thing was uh of course in that work we we suggested some random things like you

should batch together trades and that will give you some some guarantees depends on the size of the trades blah blah and then we have a different work suggesting like even crazier method which like Cuts up a trade and then does a bunch of stuff and like Blends it together using some prng and then like you have some differential privacy which like that's like super that was the differential privacy with sort of your so that one that one gets like quite quite deep into the the like very lost in the sauce in that case but it's it's much you know it's the like if you don't have this nice batching you have like some a little bit more annoying type of thing like how do you do it and then uh penumbra was also similarly I think after this work was Henry realizing that uh you know you can

use kind of these I believe it was some partially homomorphic encryption to to kind of construct these batches automatically and so you actually really can get like private batch uh kind of exchanges um but it has weird properties and we have another paper analyzing like what that means for like Arbitrage but anyways the point is yes this it's very funny this is actually how how we met and I I feel like we've come full circle on this one it's this is like a callback you know yeah we saw this batch auction design in panum as you mentioned and interestingly enough also in secret Network basically any implementation of an amm where the prices are public so in secret network if you're trading on an amm and your

trade is the only transaction in a block then it'll be super obvious exactly what the amount of your tra yep and yeah it was interesting to me that it's the same batch anonymity set guarantee as penum so in penum if you're the only one in your batch similarly you're not going to get any privacy yeah but I will say that the order book implementations were had different privacy properties so uh we looked for example at Renegade fi so the implement and order book deck where the prices are private and you run a matching algorithm in a two-party

computation and if your orders do match then you form a balanced transaction that is submitted on chain that conceals the amount of the individual orders if your orders don't match then nothing happens and either party in the 2pc uh learns nothing about the other party's prices interesting you just mentioned sort of three examples there you had penumbra secret Renegade fi was there another project that you looked at or was just those three that you were kind of comparing in this work uh the final project we looked at was Zsa swap similarly to Renegade F they Implement an order book decks where

the prices are kept private so Zsa swap is not a real protocol yet very much it's in the design phase okay okay but that's cool I mean let's tease out even more the differences between these and I know cuz you also introduced these other ways of thinking about computation um I don't know if each one of these projects uses a different type of computation or if they're all kind of playing in the same area but yeah maybe Brian you can share a little bit about those three categories that you had in there yeah absolutely so uh We've mentioned all three of the techniques that these protocols make use of right now so uh the secret network is uh leaning heavily on on tees or trusted execution

environments um which are secure Hardware enclaves uh that allow computations to happen in a privacy preserving way because it's very difficult to exfiltrate any data of any sort from within the hardware that's doing the computation some people have discussions about how much one should trust uh the hardware implementations from companies that maybe don't have the best track record of having totally bug-free Hardware but uh in many cases this uh trusted execution environment approach is is very effective at at just keeping a trustless network from having to trust too much yeah and so secret network uh does all of their their main computations in The Trusted execution

environment and that's how they allow private data from multiple parties to come together the Renegade fi approach is a really interesting one because it uses secure multi-party computation um and these cryptographic that comput to use mathematics of pooms and crypto systems to combine their data in a way that nobody sees anything except the expected output of the computation um it's really quite magical um the downside is that there are some inefficiencies in doing these sorts of computations um a lot of uh of communication costs in particular between the parties tend to add up but uh uh renate approach is just to do a

secure multi-party computation between two different parties um this is another aspect of their protocol which is is limiting two-party computation is often reasonably doable um if you want to do computations with more parties than that then it gets complicated but it does a really good job of doing a particular matching protocol for limit orders and it kind of accomplishes the Privacy characteristics that they're aiming for very well penumbra is really an interesting protocol from my perspective um what I really like about it is it puts together just the smallest kernel of computation in this what we call mediated computation phase um is just a just a little part that allows you to to do something with private data from

multiple parties to achieve this this differential privacy that GMA was mentioning earlier and so all it does is it takes the requests for trading some type of asset for another type of asset and it adds them all together in this very small multi-party computation it's just a threshold decryption scheme um and so everybody encrypts their amounts to the same public key and then a threshold of validators are required in order to decrypt the outputs um after they've been added together so kind of all of the trades that happen at the same time are added together before they're decrypted um and so it relies on kind of the validator set not deciding to decrypt early as a group um but uh trusting a group is easier than than

trusting any individual validator by themselves so quick question you you alluded to this um this part I don't what you called it it's uh mediated computation I think you have this very nice framework in the paper which I I really appreciate it which is like it seems that all of these protocols uh kind of the way they they work if I recall correctly I could have misre this is they have kind of three I believe three phases right for for how they're doing and I thought this this was a lovely framewor so if you want to just go into how they all have the same um structure uh that I think it's a really lovely framework for thinking about uh these things things the real big picture here is that there are different cryptographic techniques that can accomplish different effects um in this distributed trustless space ethereum

started out by exploring kind of the public replicated virtual machine the global computer um and no privacy properties included and then this kind of ZK thesis of chains allow offchain computation to occur because of either either specialized signature schemes or or general ZK sarks um which allow you to verify computation that happens offchain and kind of these two regimes of computation have a lot of uh study put into them and kind of have well understood cryptographic properties but then there's something else that's needed to combine private inputs from multiple parties like like those two techniques can't accomplish this by themselves and the problem ends up being

that the techniques to do this are difficult they're complicated they're subtle uh they take a lot of cryptographic sophistication to implement properly and so what we found is that most computation should be put into the ZK snark offchain computation side or the onchain global computation side for purposes of of cryptographic uh suitability and for purposes of computational efficiency but new privacy chains are incorporating kind of some special sauce of some sort and generically what is needed is a separate step in kind of forming a block or forming a new computational unit um which does this extra task of combining

private computations or private inputs from multiple parties um and so what we realized is that how blockchains are doing this is starting with offchain doing some kind of mediated computation phase which either is is some separate protocol that's not even related to the the blockchain that it's ending up on or perhaps it's something that's provided by the blockchain by the validator or by some separate software that validators also run um in order to combine these inputs and then produce something that can be ingested by the onchain uh systems for computation yeah as Brian said we noticed this structure of three phases independent mediated and Global computation and the independent

computation happens often where only the users's private data is involved and the global computation happens on chain where the consensus and the networks validators are actually uh verifying actually guaranteeing the correctness of the state update and we noticed where these protocols differ most significantly is in the middle phase of mediated computation oh wow and the scarce resource here always is the network validators it's the resources that uh the whole consensus has to be involved in uh and for example pen number actually involves all of its

validators in um this threshold decryption effort secret Network as well uh every validator runs a te whereas if you look at Zsa swap they relegate the mediat computation chain to some offchain solver that is not creating this extra strain on the Network's resources but at the same time the Privacy guarantees uh that the users have are solely depending on uh this offchain operator so we did notice in this three-phase structure that there is a trade-off happening in the middle

phase of privacy versus expressivity that if you move your private Med computation offchain you're free to perform a more expressive arbitrary computation but your privacy guarantees uh are weakened uh and they rely on some entity that is not secured by the Network's consensus and by the network uh Economic Security whereas if you choose to perform the mediated computation on chain you are placing burdens on every validator in the network um burdens of synchronicity burdens of compute uh but from that uh

you get this very strong um privacy guarantee for example a kfn thresh out guarantee that you wouldn't get in the first case oh that's an interesting finding so you're choosing the sort of privacy expressivity axis but are there any other characteristics like is there any like security or like is there other things that get affected by the choices that are made here so one of the interesting characteristics of these systems that we observed is that very conveniently the design can be put together so that the Privacy properties are the main thing that is on the line uh for H mediated computation is designed um generally because computations are consumed at the

consensus layer uh using some kind of proof scheme uh the correctness of the applications involved is not at risk um so so when you're looking at the mediated computation technique a lot of the question is is it possible for this private data that users are submitting to be to be revealed to the compu nodes or to other parties okay cool cool so it's just it's like how private is it is going up and down depending but it's yeah the proofs are still proofs that's right another tradeoff that we noticed was um expressivity versus security but on the developer experience level like how easy it is is to add a bug or not

kind of by accident exactly okay the more freedom the more access you give the developer to this low-level privacy Primitives the greater the chance that you expose them to a foot gun or some pattern that is unintentionally disclosive so for example if you let them vary the size of the encrypted inputs and outputs that could leak information on what these inputs and outputs are if you let them vary storage access patterns for example and your usual almost site Channel attacks on timing frequency the size of queries another possible example is this

branching pattern whereby let's say in an auction in a private auction contract you have some winning bid that is updated every time a higher bid comes in so how you would naively Implement that is if the new bit is higher then update the secret bid but the very fact that the commitment to the secret bit has changed tells me that the new bid was indeed higher than all the other bids and so patterns like that that are trivially disclosive may be exposed with a twoo expressive interface oh wow and this is true as well in MPC you can

write trivially disclosive MPC circuits so yeah this is another tradeoff that we noticed uh it was not the focus of our paper but I would say for all practitioners and for anyone who's actually writing programs on um these programmable privacy systems this is absolutely priority uh for developer experience and for user privacy yeah I honestly think that it's a an important research priority to try and identify good design patterns and good language designs which make it harder for developers to introduce these sorts of

bugs um and also to understand the kind of computational engines that go along with difficult to introduce bugs uh systems after this exploration do you have any strong opinions about how languages should be designed to avoid such things I don't know any like highle like here are some invariants that like it would be very cool if you know your compiler would check for you or your type system would check for your so I have no idea I'm just but I'm curious so we actually made a start on UC style definitions of a bunch of protocols in our s so UC means Universal composability okay and it's a simulation based proof Paradigm basically it uh

simulates the view of an adversary in an idealized functionality uh versus the real world protocol and tries to ensure that the adversary cannot distinguish which version It's interacting with MH so we made a start on UC style definitions but we didn't actually get to UC proofs I do think that an interesting line of further work would be to look at UC proofs um and to look at them in a machine checkable way so if we could somehow write our programs in terms of

their UC ideal functionality then we could uh check the desired information leakage and check these privacy invariants this would make the coding on like a developer experience much better because they could have something to just like make sure it catches those those things that you worried might the code could output guarant the compiler could output guarantees about what's actually being upheld versus like things that are being leaked for example is I guess exactly if we reenter the developer experience on privacy in variance then that would make very explicit uh the information leakage that's intended versus

unintended there's a line of work on privacy Notions based on game-based proofs so this 2018 paper called on privacy Notions in Anonymous communication it defines a bunch of privacy properties for example uh Stander receiver linkability standard receiver observability standard message linkability receiver message linkability and so on it defines this in sort of this tree of implications and we could make use of these privacy Notions and have the developer specify which notion uh

they're interested in preserving and which Notions that that in turn implies the zerach paper also had a bunch of Notions around indistinguishability so as Brian said it's a very interesting research question of how to inor incorporate these Notions into dsls into interfaces that developers would find intuitive into interfaces that would be safe for users interesting I want to just ask a little bit on who the developers here you're talking about are because in the examples that you highlighted the the ones that you really look at penumbra secret I don't actually

know the other two very well but like are you talking to the developers of those systems or developers that are interfacing with those systems and you know we we are talking also about this like programmable computation environment so I just want to make a slight distinguishing of who can make the mistakes or who are you speaking to with a lot of this stuff yeah I think the real target audience for these sorts of tools are Developer teams that do not have as much uh cryptographic sophistication as some of the primary developer teams of these these protocols I see it's like someone building another system like this the guys over penumbra know know exactly what they're doing with all of this cryptography you know

um we're not we're not designing a DSL for them um but but more so for protocols that are aiming to make these sorts of functionalities these sorts of underlying computational engines available to development teams more broadly who don't have an in-house cryptographer or who don't have a big budget for that type of security and still want to produce applications that make use of of the mediated computation phase um so one one interesting point where we see an opening in the space right now is that the main place where real programmable privacy is being implemented in actual blockchain protocols is primarily using tees as the as the foundation so it's kind of

skipping the cryptographic scheme entirely if you're thinking about multi-party computation homomorphic encryption like it's just saying let's use secure hardware and it'll it'll work um but the problem ends up being that the giving full access to the underling underlying compute node opens up these sorts of timing attacks or branching logic attacks um and it puts some of the burden of of security on the development teams that are using these things so for instance the secret network has a really useful and interesting page on things that you should keep in mind for making sure that the privacy of your application is maintained and it's like very good stuff to keep in mind but ideally a DSL would abstract that complexity away from developers so they

don't have to think about it cool you sort of talk a little bit about Intense or that comes up and I know like the focus was this limit order auction maybe that's why that was mentioned but there was one system that was not mentioned there which is like aoma I know namada is launching it's not a de it's not doing that so I get it but like I was kind of curious if you even explored what they're building or if you really see that as like so different that it it it wouldn't have fit into this anoma was certainly an inspiration for us in the S the reason we chose limit order auctions as the specific motivating example was to just minimize the complexity of the

applications that we're studying as to capture a minimal set of functionality that's still non-trivial so as far as I understand it the privacy of intents on anoma is orthogonal to their main protocol it's extra protocol and it's sort of delegated to their solvers who are matching and solving these intents offchain and then submitting them as balanced transactions onchain so in that sense anoma is similar to Zsa swaps Z at assets swaps in that that the privacy of the intents

and the actual mediated compination of matching and solving them is offchain or extra protocol got it cool so I feel like I mean I've reached the end of the questions I had on particularly this work but like now that this work is completed and you're kind of like looking forward where do you see a lot of the systems that you just described like the MPC and the ZK and the interactions and these this sort of mediated comput area where what do you see kind of coming from there one outcome that we want from this work is to further discussion on best practices and the safe designs in programmable privacy systems so one Trend that we did

notice is that Zer knowledge proofs are used as a primitive in almost every one of these designs so for example in Renegade five uh the matching algorithm is carried out in a two-party computation but both parties at the same time also produce a collaborative ZK snark of the validity of their computation and this is posted on chain and is publicly verifiable so we see this again in fhe where the encrypted input is accompanied by a proof of correct encrypt

so that the validator notes know that they're not receiving garbage uh that they're receiving some input that was actually properly encrypted to them and lastly in tees we've again seen proposals for getting the te to run a ZK PR and basically removing this dependency on the te for integrity so we're limiting the responsibility of the te to just confidentiality and we're asking it to produce as a publicly verifiable ZK proof uh so that anyone outside the te can check um that it actually run the

program it was supposed to run and there are multiple other ways to stack these Primitives so defense in depth um best practices this is one of the sort of outcomes we would like one of the takeaways we would like to communicate with this work programmable privacy systems actually consider how they can make full use of these different cryptographic Primitives nice I mean it's interesting because like the combinations of the ZK and FHA ZK MPC we've covered on the podcast before but it's it's interesting here that like your position in it much more as like ZK being used as a tool and not necessar

because I mean we've also seen like MPC be used in a ZK scenario if you talk trusted setup or something like this but here you're sort of saying like in the MPC itself you're using the technique of ZK to like prove something about some computation that's happening in that private environment often yeah I like I like thinking about it in all of those ways that's cool yeah yeah that's cool before we sign off I want to hear a little bit about maybe other future work that you yourselves are working on like kind of directions that you want to explore even further beyond what we've already talked about on the show so one of the directions that I think is really interesting that I would like to spend some time uh investigating at some point is looking at in particular uh more

Dynamic uh MPC based mediated computation so using multi-party computation with a trust based on a threshold of the compute nodes um to provide some general computational functionalities um like in particular where you see MPC used in a lot of protocols right now is very specialized functionality um threshold decryption or some particular uh circuit that needs to be computed and it's part of the reason for that is that you can really optimize the multiparty computation in that context um to get good efficiency in good security properties um but I don't think that people have spent enough time thinking about efficient generic computation in MPC um and how that can be used to really uh accentuate the

Privacy properties of these systems for for distributed chains cool what about you Ying Tong I'm actually interested in a taxonomy of classes of applications that would benefit from programmable privacy and relatedly the best practices and the Privacy preserving design patterns that correspond to these different classes of applications in this s so we chose to narrow our Focus to limit order auctions uh and I do do think that covers a a great deal of interesting Dynamics in programmable privacy but yeah I I think it would be really interesting and really valuable

to Define more generally the types of interaction required by different classes of so-called privacy preserving applications and then correspondingly The cryptographic Primitives that they require at the minimum to realize that's interesting I was actually going to ask you exactly that about like looking past just the limit or order auctions but can you just share like maybe a handful of types that you have already identified even like what would they be called are they always in the context of like dex's or like trades or would it go into stuff like message passing or something like that isn't Dex related I've seen lots of applications

that are hidden information games so someone once described it to me as uh you're hiding in a bush and I throw a spear at you and I want it to be reflected in the global state that this event happened and that your health decreased oh okay like for a game I guess yeah yes so uh well games are so useful in surfacing these Dynamics um well another application that's interesting to me is m TCS or multilateral tra credit settlement and this is sort of extending the interaction to sort a cycle of

participants instead of just a pair wise so this sort of uh Atomic settlement in a cycle of participants yeah it it it's a an extension of what we've um studied in this paper and I guess we came across a a bunch of applications that had really fewer requirements so they had only commutative updates for example I think voting you can achieve that just using ZK snarks each time you're just like adding something Plus One MH auctions you could do that similarly so yeah there's certainly applications with um greater and lesser

requirements on interactivity of private state but I I haven't quite seen um a rigorous classification of them yet so I would I'm very motivated to make one cool that's awesome sounds fascinating and maybe that will be something we can talk about on a future podcast yes nice all right I want to say thank you to both of you for coming on sharing a little bit about your background what got you excited about this work and then obviously our dive into the programmable privacy and distributed systems s so um yeah it was so great to have you on

thank you for having us on this was lots of fun yeah it was awesome to be here yeah thanks G I'm just here don't mind me all right and I want to say thank you to the podcast team Henrik Rachel and Tanya and to our listeners thanks for listening