Why crypto has no privacy layer

Pragma Denver · 28 Feb 2024 · 23:05

Elena Nadolinski of Iron Fish argues that crypto still lacks a privacy protocol that can move 100 USDC privately between two accounts, and that legal exposure is a major reason. She says FinCEN money transmitter rules and OFAC sanctions could reach privacy protocols and their developers, citing the Tornado Cash charges, while stating she is not a lawyer. She then weighs screening at ingress, inside the protocol or at egress, setting aside view keys, encrypted tracers, consensus block lists and association sets, and describes Iron Fish choosing ingress checks through a bridge operator with real-time threat detection.

Speakers

Topics

From Pragma Denver, hosted by ETHGlobal.

Transcript

next up we have our second and only other talk for today which is around why crypto and privacy have not really found that perfect match and talking about this topic are going is going to be Elena from ironfish so please give Elena a massive Round of Applause hello okay awesome um cool so I want to talk to you about uh privacy and crypto and why we actually still don't have a solution for it um I got this work I can I can just do I think might be a click missing let's try

that that's okay okay so who am I um I've been working on a project called iron fish for quite some time now um Iron fish is a layer one protocol it's a privacy protocol we've been fully m n launch since April of last year uh we're actually the only mainnet launch privacy chain that supports custom assets Uh custom assets as well um and I've been in crypto since like 2019 and so since 2019 I've been trying to figure out how do we can have a privacy layer for crypto um and unfortunately almost five years in we actually still don't have a solution so okay let's say I have a friend uh cartic um and I want to send

him some assets um and um you know maybe I don't want to be associated with cartic for various reasons or maybe the fact that the tokens are going to be leaving my account is going to Signal some some some something to the market um maybe I'm a whale U or maybe I don't want to give a future Fisher more information about myself because now they know that they can impersonate cartic and ask more money from me um that and that's not really good either or maybe cartic is my therapist and again I don't want that transaction to be out in the open and available um or maybe simply I just don't want my transactions to be public um and again there's a lot of reasons for why people might want private transactions it's actually a very odd Paradigm that they're not um and there's plenty of

other reasons why we might want privacy in crypto for instance Financial in institutions they actually need privacy for them it's not just a moral right it's a necessity for their business um whales do move the market just by placing an order especially during The nft Craze there were actual Bots that would mimic transactions made by certain accounts um donations to campaigns stay with your wallet forever so for instance recently there was a US citizen who was also a Russian citizen from Los Angeles she went back to Russia and she was arrested because she donated $51 to Ukraine um so that stays with you forever your ens name that sometimes people use on Twitter um that is

basically a price tag over your head um and then fish speis attacks are way easier with transparency because again if I know more about you and your past transactions I can craft an attack that better targets you um if you ever wanted to do payroll with crypto it's kind of a weird Paradigm to have all your payroll information to be completely out in the open so for the duration of this talk let's focus in this just one goal which is I want to send 20 usdc from account a to account B privately and to make this a little bit more believable because I'm inflation uh 100 is the new 20 so what protocol out there can facilitate this transaction and uh I'm going to give

some other caveat so I want this protocol to actually work well and I want this protocol to give the Privacy that the users want and deserve at the price that they actually want and I don't want bad guys to use this protocol too um because I do want this this protocol to have a viable future and if you let bad guys use it then it kind of violates that rule so cryptos has had a number of attempts on privacy um so some of the OG privacy Protocols are these monolithic isolate isolated non-interoperable um protocols that typically only support one asset and so those are things like Monero or zcash or grin beam Etc um and then there's these what I call the Next

Generation privacy protocols and those are typically ZK based they're interoperable and they're overall more exciting um but they're not quite there yet so again want to go back to this example I want to send 100 UC from account a to account B privately um what protocol lets me do that and so some protocols have worldclass cryptography but are isolated and not interoperable so for instance even though zcash is has probably the best cryptography out there I can't use zcash to send 100 USC to to cartic that just doesn't work um some protocols use what what like tees which are the same for trust execution environments or enclaves um and I think

that's cheating I don't think that's real privacy so I don't think that quite work quite Works um some privacy protocols have actually pivoted away from privacy for various reasons um so for instance if you guys heard of a project called nocturn I thought they had a really cool approach to privacy um and unfortunately a few weeks ago they announced that they're no longer pursuing that goal espresso systems again pivoted way to focus on shared sequencers um and so again we're seeing kind of protocols shy away from privacy and focusing on other things um some privacy protocols have killed off their own products which is a little sad but they will relaunch um and some some privacy protocols have not launched yet so for instance Alo namada p numbra and a few others um are super cool but

they're not out yet so I can't actually use them to send my 100 USC uh to cartic um and some privacy protocols like iron fish have launched but again I can't quite use it yet um for my example but I will be able to soon um and some privacy protocols do exist in their chains but they're not quite used and honestly they're not quite they're not quite private there was one privacy protocol that actually came close uh to be to being able to solve my use case of sending that usdc privately and unfortunately it has been Sy and the crazy thing about this is that it actually shows the demand in the market for a privacy protocol because this privacy protocol Who Shall Not Be Named

was sanctioned um its governance token was hacked its Founders were arrested and yet right now if you go to defi llama it's still top 50 uh defi protocols with over with almost half a billion locked locked in there um but but I still can't use it right so for privac protocol out there it's like squid games you kind of like look around and you're like oh no am I next um so at this moment in time there's still not a single protocol that I as a you citizen can use to transfer money privately from account a to account B so aside from technical challenges of privacy protocols and

those are super fascinating um I'm actually going to talk more about the compliance in the screening section um because that is actually pretty important especially since a lot of us have unlaunched privacy protocols and I think a lot of us are thinking about this of how do we launch a protocol that again has a future and won't let bad guys use it um so really like how do we as developers build a privacy solution that genuinely deters Bad actors and makes Regulators comfortable and we are going to focus on this last one of what makes regulars comfortable um and typically for crypto people are mostly concerned about the SEC so for instance a lot of you know Founders and projects and so on spend a lot of brain Cycles

thinking of like how do I write a blog post am I allowed to publish a road map Etc in fear that the SEC May dislike that but we're actually not going to focus on the SEC at all we're going to focus in a couple of other departments um within the treasury Department itself so the treasury Department has a lot of departments underneath it it's actually a huge conglomerate and all of them are equally scary but the two that we're really going to focus on is back and fin sen so we can kind of condense this graph to just these two entities um and these two entities are extremely important and I think every single crypto project should focus on that especially privacy protocol and I'm not a lawyer definitely not your lawyer this is gr oversimplification of all this um

but we did spend a considerable amount of time talking to lawyers about all this um and I think all this is actually fairly important so for finsen you can kind of think of finsen as just focusing on the bank secrecy act um and so under this uh sorry of course not yeah so under BSA finser requires that a money transmitter or an MSB um conducts certain reporting rules to report suspicious activity to prevent money laundering or terrorism fin financing or other list activity okay that sounds great but what makes you a money transmitter and by you I mean what makes a protocol or a protocol developer a money transmitter because if you are one then again you have a lot you have to do

a lot of these other kind of requirements uh to facilitate that compliance um so you don't actually want to do that so in 2019 Vincent gave us guidance on what this means for privacy protocols in particular which I thought was really interesting um and the tldr of that is that an anonymizing software Provider by itself is not a money transmitter which is pretty great news but then what happened last year in August of 2023 um is that the two tornado cash bounders were arrested and they were indicted with three counts um and count two was actually conspiracy to operate an unlicensed money transmitter business

okay so this is gets kind of interesting because they were a protocol and there were protocol developers and now they're being tried as an MSB um that's not good and if you really read the whole court case the tldr of that is that relays provided customers with enhanced anonymity in exchange for a fee um making this fall under MSB requirements because again an MSB is a business that uh provides a service that takes a fee for transmitting value so we can kind of condense this or summarize this um as a protocol that provides users with some service any service that produces revenue is now an MSB and

this is kind of scary because it actually uh means that protocols they're not just privacy protocols should really pay attention because technically all bridges and all relays uh can fall under this requirement um if they take fees for the services that they provide of Mo moving money for their users um and even if you don't take fees directly which is kind of what this Core case uded to uh but the protocol's token appreciates and value due to you providing a service that can also count um which again is kind of interesting um because what they argued is that even though even if they didn't take like realer transaction fees if the tour token went up in value

because more people used it then effectively you are taking a fee um or taking Revenue um and unfortunately even though none of this is St in stone it makes it really hard for privacy protocols to make partnership or to work with other businesses uh just mostly because of fear so this is largely unresolved and not yet enforced so all this sounds scary but it's kind of still pretty much inlux um and there is something scary actually and so if we go back to this graph the scarier um Department here is actually ofac and ofac kind of deals with sanctions list so a sanctions list basically means if you are us person or entity you do not touch the sanctions list list um and the sanctions list is

basically you know uh individuals or even countries who you cannot interact with financially and it's unforgiving meaning that for finson you actually have to uh prove whether or not you had intent to make that crime but for sanctions it's unforgiving in terms that they have no obligation to prove intent of violation if you violated sanctions you are a fault um so then the question is well for protocols and protocol development how do they get around this because we're building crypto to be this Global product where typically we don't put restrictions on who uses it so how how should we think about this um so what is the O requirement for protocols um and

they did have some guidance um in the FAQ section of when they sanction tornado cache and they said that privacy preserving protocol where software by itself does not need to have um ofac requirements but then it's kind of kind of josed with them sanctioning tornado and so as a protocol developer this becomes very confusing of how you can actually operate under this um under this set of facts um and so for protocol developers um a US individual or an entity there's a pretty clear requirement that you do need to follow follow effect sanction obligations um so even though your protocol doesn't you specifically personally do because

whereas for finson your company might get sued but for ofac you personally get sued and I don't think anyone here in this room wants to go up against the US government regardless of whether or not you think you can win um and so one of the counts that the tornado cash Founders were um were arrested for is this count three which is Con conspiracy to violate basically the sanctions list and the argument here is that since tornado the company ran its own bre layers they received fees from sanction addresses and therefore they have directly um transacted with a sanctioned address and this one is going to be fairly easy for them to prove and out of all the counts this is probably the more

serious one that they're facing um so again this actually should be scary for protocols outside of just privacy protocol specifically Bridges and l2s because if you are running a single sequencer there's only one party that's taking transaction fees and you're taking fee from a S address then technically you violated the same thing they did um and same same argument for for Bridges typically Bridges either have a tide Quorum of validators or sometimes they even call them Rel layers um and therefore you're directly falling under the same argument that got turn into cash in trouble okay but really let's just focus on this example I know like we went on this whole tangent um but really again we just want to send money from count a

to count B privately um so how do we do this without you know being s use government and do so with good ethics um so instead of looking at like looking at it like this let's break it down in terms of this so you can look at uh interaction with the Privacy protocol kind of in three steps the first step is the Ingress value has to go from a transparent environment to a private environment um and transactions then happen within the Privacy protocol so typically people can move swap transact however they want within the Privacy protocol and then eventually a person may want to leave the Privacy protocol and go back to their transparent environment um so for us for this

example um if I wanted to do a us a transaction privately I would first send it to ironfish or another privacy pool um then I would transact with it however however I want and then CTIC or whoever else would then be able to take the money out so we have a choice on where we can do the screening so we can either do the screen on the Ingress when money comes in we can either do screening within the Privacy protocol itself um or we can do it on the egasp when money leaves the the protocol um so if we screen within the Privacy protocol it's kind of a pendor box of problems um one such example of how you can do that is you can have a global V key and if if you're familiar with a project called CAP by espresso that's kind of what they did um

so the idea is that if you have this Global vuk key then someone kind of looks at all the transactions and make sure that no Bad actors are using the protocol um while still keeping it private to everybody else and there's a lot of problems with this first it sounds bad who wants a global vuki in their privacy protocol um second it's a huge overhead on the team because now someone has to monitor all the transactions and keep track of This Global P key which is a huge obsc and a lot of risk for hack and and data loss um and if the team is actually responsible for monitoring all the transactions using this Global vuki then there's even a stronger argument to to be made that they are an MSB you don't want that either so uh there's a lot of problems with this approach um and uh so

typically let's we don't really look at that um so then we can kind of put an encrypted tracer on all the EO models or on all the EO notes um and we actually looked at this approach for quite some time and technically this is a very interesting approach uh but it does H have a lot of problems with it too so for instance again if an account wants to deposit some money into the Privacy layer um and Alice then wants to send to Bob some money within the pry layer the idea is that you have an encrypted Tracer that keeps track of all of the previous owners for that um for that note um and so you know this encrypted blob pretty much grows with each transaction um and to preserve privacy we can we can encrypted and can and it

can only be decrypted with like an NPC or a dow Etc um such that it can only be decrypted if there's suspicious cause or there's a reason for you to to want to look at that history and that's a pretty bad idea too because you have this growing data set that's not good um again having a tracer sounds pretty bad um having a party to decrypt past history sounds like a lot as well um because then the question is like well what is considered suspicious who actually does the decryption um and so overall this particular approach even though theoretically possible not super practical um cool so then we can have a consensus enforced block list so for ironfish we actually seriously consider

this approach and the the idea basically is that if we detect that there's a bad address we can prevent that address from ever creating a transaction the protocol by by consensus um and the problem with that is that time is really against you if I'm a bad person if I'm a hacker um then I'll probably move my funds extremely quickly much faster that you can update your consensus layer to prevent me from doing so in the future um and then there's a weird jurisdiction question so for instance for ironfish we have minors all around the world a lot water miners for instance are in China should they follow the US sanctions list should they follow the Chinese sanctions list um because Anie Pelosi is actually in the Chinese sanctions list so does that mean that we can't process her

transactions um so then it kind of kind of as a Pandora's box of of that question which we really did not want to address um so then you can do erass which um I don't know if you guys remember but metallic andine publish this paper and Association sets which basically means that if you have multiple parties going into the price protocol if I want to ever withdraw that money um I have to present to you an association set of past transactions that have to include my own and so the idea is for instance if I'm Alice I can say well um you know upon withdrawing I can say I'm either Alice Bob carler or David but you don't know who I am and I'm not I'm not going to include Eve

because I know Eve is the bad person um Now Eve could not say the same statement because Eve has to include herself and if we know that Eve is bad then the association said that she has to present will include a bad address which is herself um the problem with that is you have to know that Eve is bad and that's actually really hard and again you're racing against time because hackers move funds very quickly um and this kind of breaks if you allow transactions within the Privacy pool itself so while we actually did look look at Association sets we eventually decided not to move forward with those either um so incress is the simplest of them all so incress basically means that when you're moving

funds into the Privacy protocol that is when you have the most information about who is trying to use that privacy protocol um and at that point you can actually effectively utilize allow lists and block lists and the idea really is that when an account is trying to move money into the Privacy protocol they first have to go through what I would call a decision maker so this could be a bridge or a smart contract bridge where relayer or whatever part of your protocol is responsible for moving thing moving funds into the Privacy protocol and at that point that decision maker can check a list uh they can check an allow list or a block list to see that account a is not a bad person um and these lists can be derived

from onchain sanctions lists so chain analysis actually provides you an onchain sanctions list you can have any of one of your protocols check against that list first um which is honestly pretty good like you you at least say that you've tried versus not trying anything at all um the downside is that if you actually want accuracy you probably have to have like a 24-hour delay because that onchain sanctions list does not get updated instantaneously um and alternatively if you had a more of a centralized approach you could just use a real-time thread detection system um so you could use all the fancy spancy technology that possibly available if you're a centralized system monitoring all the transactions they're trying to enter the

Privacy pool um so that's actually what we chose uh so we're working with a bridge operator who is um monitoring all the transactions that are coming in with realtime th detection model um the downside is that you do have a more centralized approach but the upside is that you have a lot more control um and so that is actually coming quite soon like in roughly three months so very soon you'll be able to finally use the example that I just proposed of moving funds in and out of a privacy protocol without allowing Bad actors so that that's all thank you