Blockchain Privacy

Transcript

[music] [music] Hello. Cool. Hey guys. Um, welcome to you all. Uh, my name is Asha Shankar. I'm the head of privacy for Coinbase. Um, today I wanted to chat a little bit about how uh your traditional privacy principles have to be re-evaluated for a blockchain space. And as the our uh introduction went on for uh blockchains given that transparency is the key feature it's also I would say a barrier for a lot of users and institutions to move their transactions on chain. So want to talk a

little bit about how do you um in essence meet your traditional privacy uh requirements in a blockchain space. Um so coming to what the real world expectations and what is practically feasible for a blockchain environment. Um as we were talking given that transparency is the key feature and today there are really no financial systems that operate on complete transparency. So that itself is a requirement that's hard to meet in the first place. And we're looking at three different user groups. So when I'm talking about end user, these are like these are people like you and me.

There's a lot of hesitation or concern about your day-to-day transactions, your spending habits, your balances for all that information to be available on the chain for everybody else to consume. Similarly for businesses, what offers a business a competitive edge? Whether it is um their strategies, the vendors that they work with, the uh financial settlements with different vendors, the payroll, these are all factors that essentially offer a competitive edge to a business. And imagine with all this information being there on the chain, how well or how is it even possible for a business to retain its competitive edge? And on the other end of the

spectrum, we have regulators. So the regulators do expect transparency. There is um uh AML or KYC requirements where they essentially require enterprises to know more about their customers. At the same time, there are several privacy regulations like GDPR and others which essentially requires companies that process and consume uh users personal data to offer protection. So there is uh I would say a lot of conflicting uh requirements from different user groups and we'll talk more about how do you actually enable or even implement some of this in a web chain web3 environment.

Uh for those of you are who are from privacy this is a term that's constantly thrown around sudonmity and as you guys are all aware this is really a myth in a blockchain space. Um, of course there are wallet addresses and the transactions are associated with wallet addresses. But there are several companies, there are several tools like Arkham Chain Analysis that essentially can tie a wallet to a real world identity. Also like if I'm talking about uh public ENS name so my ENS is Ashanka.base.eth and it's very easy for you know for for my ENS name to be associated with my real world identity. So and because it's a changed graph, it's when when there is

exposure of a wallet address and when one is able to establish that link between the wallet address and the transaction, your entire financial uh information becomes available for everyone on the chain to view. And next going into like the constraints like the architectural constraints in privacy there is a key requirement for deletion. So I'll talk about this in further slides but essentially users can reach out to enterprises which are collecting personal data about the individuals and say hey I want you to be deleting data about me or you institutions have to implement retention periods. So based on what you're collecting uh users data for if you're

collecting it for compliance reasons then you are obligated to keep it for seven years but beyond that you have to be implementing retention practices. But how do we even implement retention for an on an immutable ledger where things stay forever? Um there is no error erasure. There is no way to update information. And so how do you even enforce or implement deletion? So with that I just want to list a few of your traditional privacy requirements. These are requirements coming from different privacy regulations across the world. Um every country has a financial has a privacy regulator and these are some of the basic requirements coming from all the regulators. Again note that these

requirements were written in for your traditional web 2 space and there hasn't been any clear guidance from regulators on how do you enforce this for web 3 but at the same time there is expectation that you adhere to these requirements. All companies adhere including companies that operate on web 3. Um so four main ones that I want to talk about uh data minimization, erasure, consent and correction. I'm going to go through each one of these in a little more detail in the subsequent slides.

Um so what is data minimization? So when companies collect personal data for individuals, they're expected to collect only the data that's needed to service the customer. And there's also something called purpose limitation. If you guys are familiar with privacy and what that really means is you are collecting minimal data that you need to service the customer and you're only using it for the purpose you're collecting it. So if you're collecting to offer a product, you cannot be using that data to market to the customer. So there are clear um delineation on the data use and what you're collecting the data for. So how do you implement minimization on blockchain? Because once the data is there, it's there. There is no going back. So you I think so then you really

have to be careful around what data you're putting onchain. So in Coinbase when we implemented our first I would say onchain privacy standards we looked at different scenarios of how data is consumed or personal data is consumed. I would say broadly we classified into four categories. So one is again these this standard was essentially written to provide more guidelines to our developers how on how and when you can be using uh onchain personal data. The first scenario is where um the personal data already exists on the chain and enterprises essentially leverage that information for for whatever products and services that they offer. Uh the second category I would say is where the

enterprise essentially is uploading the personal data on the chain. The third is where you're enabling end users to actually store uh the personal data on chain. And I'll give you a hypothetical example of that. Say a user is providing their personal data for KYC purposes and they get KYC by one financial institution. Instead of re-roviding the data to every other institution that they transact with they essentially say hey I have been KYB by KYC by institution A ABC so all the other institutions where they operate essentially leverages that KYC data so that's a hypothetical example of where the user themselves will upload personal

data about themselves for a given service and lastly is where you have your um web3 developers who are developing DAPs and are essentially processing uh personal data of their users. So when we went through these four scenarios, we clear we implemented guard rails on what's acceptable for each of those four four scenarios. And I said the key is essentially evaluation of the smart contracts that are used in all of these scenarios. So we implemented what we call automated smart contract scanning which essentially is looking for any I would say any sensitive personal data that shouldn't be on the chain and essentially blocks it from committing to the chain if it

identifies any of this information and also want to talk about um typically identity information is what's recommended we keep offchain so when you have a need for a uh where you have to link an identity data with a transactional data Then the recommendation is that you are essentially hashing or encrypting and then you have the hashed value value on the chain while you're keeping the keys offchain. Um moving to the next principle which is the principle of deletion. As I said um several privacy regulations requires that enterprises that process personal data have to offer the what we call right to delete. This is where a

customer can reach out and say, "Hey company, I see that you have data about me and I want this data to be deleted. I want to close my transaction like my processing with you and delete my data." Because deletion is not feasible in a blockchain environment. We are essentially meeting that principle of deletion through cryptographic erasia. And as I was saying in my in my prior slide, if we're actually storing the hashed or the encrypted data on the chain, by essentially deleting the link between the hash and the true value, you are in a sense um achieving the principle of deletion. I mean it does not remove the onchain records uh nor it helps with you know in cases where the information has

already been shared with a third party. But if in order to meet the sense of deletion, cryptographic erasure is what companies are resorting to. Um transparency this is another requirement coming from different privacy regulations. I would say of all this is probably the least least important given that most folks who are operating on the chain are really familiar with the architecture of the chain and how it works. But there are still requirements where you have to provide inapp notifications or via your privacy policy clarity around uh what data you are storing on chain, what is it being used for, what's the purpose and what are the uh safety me safety guardrails you have in place to protect

that data. Um moving on. So as I said um the regulators have a need for performing KYC performing sanctions check and if you guys are familiar travel rule is where different institutions have to share identity information on the transactions that are occurring on on their platforms. So in all these three scenarios it really it requires um associating the transaction with a real world identity. So in all these instances we have to be um careful around what how do we essentially enable KYC sanctions and travel travel rule requirements while maintaining privacy

on the chain. So that's where zero knowledge proofs comes in. I wouldn't say this is a silver bullet but this is one of the mechanisms through which where where you where you only have a need to prove a claim without disclosing the underlying data. ZKPS have been accepted as a valid mechanism by several regulators and several institutions to essentially um where limit the use of personal data. So this is where if you need to prove an age I mean all that is needed is to show that an individual is above 18 years and what you upload on the chain is just a yes or no saying that hey this wallet address is are they above 18 without disclosing what their date of birth is

what their gender is. So ZKPs have been successful to some extent but as I said um there are um there are exceptions to this where where in case of travel rule we do have to disclose identity information between exchanges. So uh zero knowledge proofs don't offer much. Uh the reason I talk about all of this is because privacy on blockchain is still pretty nent. There are um some there are different like as I'm I'm walking through the different uh vendors and different companies there are companies that are that are currently offering um privacy mechanisms starting with private payments but there it is still pretty nent and there are ways to

essentially break that uh privacy need. So this is an area that continues to be explored and there are several players in the industry who are trying to see how do we enable private payments while maintaining transparency which is a key requirement of any blockchain. So I want to just talk about one of the case study which is the private payments on base and the way it has been envisioned here is that when a user moves funds on the base ledger you are essentially hiding the receivers's uh information. So the receiver information is encrypted and that's not in that's not posted on the chain and within the private ledger like your essentially the

transaction and balance information is what goes to the chain without disclosing the identity of the recipient and the within the chain also like your compliance checks your KYC checks all those happen within the private ledger. I do want to clarify this is privacy for the uh p for the web three but not this is not privacy for the operator because the operator still has insight into who is a sender who is a receiver again I don't want to dive too much into it because again this is still a use case I I'm sure you're all aware of the tornado cache situation where it was truly private and I think it's really we have a I would say huge uphill battle with

our regulators is to offer true private uh payments. Uh I would say this is a I would say a close compromise where you are offering private payments but I want to clarify this is privacy for the chain but not for the operator. And then towards the end when there are withdrawals happening from the platform you're essentially hiding the identity of the sender. So when you when when the funds are moving in you're hiding hiding the identity of the receiver and when when there are withdrawals being made you hide the identity of the sender essentially enabling a a private transaction to say. So there may be folks who might say that hey by correlation I can see that you know uh whatever 567 uh ETH was

deposited and the similar ETH was withdrawn. So you can still kind of correlate and say hey this was a this is the sender this is a receiver. I mean there are ways where you can essentially prevent some of that by batching transactions or by delaying again but there are constraints with how this can be implemented. So that's why I'm saying this is more of a case study. This still being evaluated on you know we need to balance between speed of transaction versus offering a true private payment. There are companies like Shopify which have started to explore more on private payments but this is at a high level the high level architecture on how this is supposed to function.

So with that said um I would say that for folks who are actually building on the chain there are few takeaways. So one is again there are no delete buttons. So you have to evaluate what information can be on the chain. You cannot implement it just from a policy point of view. You have to I mean um ideally you have to look into as I said like some a preventative smart contract scanner that identifies say sensitive personal data and prevents it from making it to the chain or um you implement certain rules where you keep identity information offchain to the extent you can and um obviously where you have a need to satisfy a claim without disclosing the underlying

identity you resort to uh zero knowledge proofs. There are a lot of other um protocols that are currently out in the market which essentially offer similar solutions as the KPS which again as I said they're all pretty preliminary and more still in a um re R&D phase and I don't think it's actually been implemented on any of the uh exchanges at least as yet. And lastly for deletion like the way to adhere or to meet this essence of deletion is through um cryptographic uh erasers or cryptographic shredding. So these are the things that I would say recommend to all the developers who are developing onchain. These have been um or I say we

have been pretty successful with our regulators by using to meet the principles of privacy by resorting to these um mechanisms. What is still lacking is as I said there is no clear guidance on how this needs to be implemented. But so far from whatever discussion we've had that with the regulators these principles have been proven effective and it's only a matter of time that there would be more uh guidance that would be get we would be getting from the regulators around um privacy principles for blockchain. I think that's all I had and I see my time is almost up.

If this [music]