[Music] All right, we are ready for our next talk. And for this one, I'd like to bring on Remy to tell you all about privacy and answer technologies. Please give Remy a big round of applause. Hey everyone, my name is Remy. Excited to be back in India for the second time.
I was here two years ago. And so today we're going to talk about privacy and we'll do a deep dive. So today all the blockchains have one thing in common. They're all transparent. Now this is a survey from Paradigm called Trophy tomorrow.
They interviewed over 300 professionals within TRFI and it shows that the top three reasons why they're still not using crypto or blockchain in general is because of the lack of privacy. The first two reasons, one is because of the perceived risk and the second one is basically regulatory uncertainty, but the third one here really is because of the lack of transparency uh lack of uh privacy in crypto. And so, you know, transparency in blockchain is actually quite useful. You want to verify payments, you want to monitor illicit activities. However, it's not meant to be adopted uh if everything is always transparent.
And if you think about this, right? What if I can always see your salary, your bank accounts, and what if I can always see, you know, how much money you have, right? This is not going to work for consumers, nor it's not going to work for enterprise in general. So, there needs to be a balance. A lot of people don't know this, but privacy is actually a spectrum.
Uh, so by default, everything's transparent. The sender, the recipient, the amount, the assets, etc. And then you can also hide various meta data on chain. So for example the amount here for confidentiality or for example the sender recipient for anonymity or you can hide everything with a system that's fully private. So I'll cover this one by one just to illustrate some of the use cases and then how to think about privacy in general.
So by default everything is transparent right so I can see your address I can see your balance and something that people think is privacy is actually not privacy is pseudonymity. Uh so what do I mean by this? So by default your address are just you know um a bunch of hashes. You don't necessarily know who is the actual user right the identity of the user behind these hashes. Now this is kind of dangerous because a lot of people think okay because they don't know who is behind this these wallets.
Uh they think that they actually have privacy by default. But this is really not the case right and I'm sure people who have sent transactions on chain before quickly realize this. What if you were to send let's say $5 to your friends suddenly your friend knows your address right and then they can see all your purchase histories how much money you have etc. So your identity is actually easily leaked with this default approach. Uh not only this there are actually a lot of services nowadays that actively trace track but also label identities of these wallets.
So next you have confidentiality which is uh in this case just hiding the amount that you own right. So you can hide for example how much USDC you have in your wallets and also the amount being transferred you know to different parties and so there are use cases that this could make sense. So for example things like payroll or supply chain uh payments and this is the case where you know uh you actually know who the participants are. So in the case of payroll obviously you know typically you know all the employees within the company you just want to hide the amount being paid out. In the case of supply chain payments I'll say Coca-Cola is like the typical example where the suppliers are known but you want to hide the amount paid out to different vendors.
And so example projects that you know utilize combination include the Sana cominial transfers which is part of the token 2022 standard. uh the encrypted ERC20 with avalanche and then also the combination tokens that we're offering. So next we have anonymity which is really hiding the participants on chain and what I mean by this is you know you can hide who is interacting with whom uh the amount and the asset usually is public and so there are use cases that where you do want anonymity for example if you were to visit a hospital right you actually want to hide the fact that you visited a medical facility or for example if you want to do a political donation I'm sure you don't want to reveal this to the entire And so an example project here would be rail gun that uses this uh approach. And then lastly, you have total privacy, which means you're hiding everything. So total blackbox, you don't know how much money people have.
You don't know who's interacting with whom. You also don't know which assets are being transferred. And there are use cases where you know this is uh actually useful. So for example, what if you want to transfer sensitive assets, right? They could be RWAS, some specific securities, and you want to hide the fact that this asset has moved, right?
So generally speaking, yeah, you want to think of privacy kind of as a spectrum. On one on one end, you have basically pseudonymity which is a default uh privacy and then on the other end you have basically fully private where you hide everything. And the way to think about which types of privacy makes sense for use case is really depending on you know what information you really need to hide for your use case to make sense. Now obviously with privacy you have to think about compliance and uh you know we've all heard about to turn to your cache and you know all the sanctions etc. And this is also you know there's a correlation between you know how private your system is and also the in terms of like how much compliance risk uh you could be facing and you know um so that that is definitely something that take to take into consideration here and uh there are obviously many different ways to actually privacy.
I'm sure you have seen a lot of these buzzwords. You know, ZK, FHE, TE, MPC. Um, I'll cover some of this and uh I'm sure this audience is probably already familiar with ZK. It's been around uh for quite some time and people have been talking about ZK for quite some time. Uh but there are I'll say other types of technologies what we call you know encryption based technologies which are FH, MPCTE that are a little bit less familiar to most folks.
So I'll cover some of these. So the first one is fully homorphic encryption FHE. Uh by show of hands, who has heard of this before? Okay, I'll say maybe like a third of the room. So FHE is a different cryptography than ZK.
What it does is allows you to encrypt information and also allow you to do mathematical operations on top of them without having to decrypt. And so one example I like to give is, you know, imagine you encrypt this cat picture. you can still perform math on top of every single pixel without having to decrypt. And so after you perform all these operations, when you decrypt this image, you have a filter, right? It sounds like magic, right?
So this is really just a cryptography meant for privacy, but also meant for you to run arbitrary logic on top. So in the context of smart contract compute is you can for example do things like product transfers where you can basically update someone's balance without having to actually reveal uh you know their actual plain text values. And so FG is actually not new. It's actually it's been around for almost 50 years now. It first came in the 70s uh with this proposal of you know what we call basically privacy homorphism.
The idea is that you know what if we can encrypt information and still do math on top, right? And back then was just a wild idea. It wasn't really clear if this was going to be feasible or not. It was more like a fantasy. The first breakthrough came in uh towards the end of the 90s uh with Pascal Palier coming up with partial homorphic encryption.
And back then you could basically just do basic additions, right? Which is actually a pretty big deal. Uh it's actually the first breakthrough, but you couldn't do more than this. And a big challenge with FH in general is you know the concept is you have a cyber text is that you have a plain text with some padding noise padding and some noise that's how you're masking the information but as you do these operations over and over this noise will keep on accumulating until this is no longer valid cyber text. So the second breakthrough came in uh with this concept of bootstrapping in 2009 by quite gentry and uh basically he figured out way to make sure this noise is in check and it doesn't overflow and so from there we can start doing more complex operations and also keep on computing.
Now after this breakthrough, FH was basically still very very slow and the next breakthrough that happened a decade later is what we call programmable bootstrapping which really focus on optimizing you know this bootstrapping step to make it a lot more efficient and practical. So today with FHE, you know, in the context of blockchains, if you do like a confidential token transfer, you're essentially doing a comparison, addition, subtraction, uh, and then a selector function. These are simple operations and so you can roughly do about 20T TPS with a single GPU. And then if you were to parallelize them, you can go over 100 TPS. Uh, but they still remain, I'll say, fairly, you know, limited in terms of throughput.
Uh so we're still kind of quite some time away from I would say a system that's fully scalable with FHE. The second biggest challenge with FHA is also making verifiable. So adding some kind of ZK FHE on top some kind of ZK on top so that every single FH computes is not only verifiable uh by humans but also by a machine right on Ethereum for example. And so today a bootstrap takes about 20 minutes to prove and you know something like a multiplication has two dozen bootstraps it would take you actually 28 days to prove right. So just just to show like yeah zkfg is also still quite some time away.
This other alternative is called trust execution environment. Tees by show of hands who has heard of TE's. Okay, slightly more. Um so TE's have been around for quite some time. Uh it's actually you know used everywhere.
Most people don't even realize this but your your phone um has TE's. iPhone has been using TE since uh 2013 to basically you know help validate your biometrics information like your face ID, touch ID, uh payment system. You use TE's to validate your PIN, you know, credit card information, etc. The idea of TE's is you use a hardware to basically perform computation within the hardware in a secure manner. And some of the benefits of TE's, I'll say, so one, they've been around for quite some time.
They're fairly well understood. You can actually prove that the code running the TE is exactly what it's meant to do on chain, right? So there are ways you can generate a proof which basically means that this is kind of a zk proof alternative that's you know hardware based and the second it's super performant it's just you know super fast because you are essentially performing plain text compute within a hardware enclave so gen speaking I'll says are probably the more practical uh near-term solution if you wanted to have you know verifiability but also high throughput but the long term obviously you know pure cryptography something like FHE will be the the ideal here so previously we did research collaboration with circle research on this topic of combination tokens and the idea is to propose something that is uh private but also compliance but the research also focus on recontrasting between commitment based solutions which are zk based and encryption based solutions which are you know FHFTTE and so what are some different properties between the two solutions and so I'll cover these two but basically it's mostly around the decryption rules and also this idea of composibility. So typically with the ZKbased systems for privacy you have it's usually UTXO based every single user has a separate wallet to custody a viewing key also a spending key and one let's say Bob sends money to Alice Bob has to specify Alice viewing key part of the proof generation now the reason why this system is a little bit more rigid is because you have to know ahead of time who gets to decrypt what information now what if you need to do the taxes right so this is where the Zika system is a little bit more rigid with the encryption based system. It behaves a little bit more like a blockchain because you can think of it kind of like an account model.
So every single private balance could be on chain and you can also customize encryption rules by you know uh mapping this fully on chain and then running some kind of L clients. And so if you wanted to delegate viewing you could always cast a transaction or via do V governance or sign a message. And so in the case of FHE typically you want to use a MPC network to decrypt information uh in a secure manner and then with TES you can just directly decrypt with a securing clip and there are practically reasons why you want decryption system to be uh flexible and this does touch about the idea of compliance right compliant privacy. So what if you need to delegate investigation to let's say chain analysis or the government down the line for your system or maybe within a company you have different departments you know you want to audit expenditures uh with your accountant etc or maybe if you're asset issuer you want to track the velocity of stable coins within your system. So having a flexible decryption system within the the private protocol the p the pri protocol is going to be extremely useful in programming these you know uh risk managements business logic and compliance in general.
The second point here is really around composibility. So the challenge with zkbased systems is everything happens offchain. You have this prover and verifier. Everything happens offchain, right? The circuit, the secret, the data, and everything gets verified onchain.
And what this creates is basically the lack of this idea of a shared private state. And so, for example, if you're to build a zk payment, it's really hard to compose with someone else application, for example, like a zk voting because these things are a little bit more siloed. Now, this is not how web 3 works today, right? Today you have for example like a ERC20 that's used everywhere by you know unisoft for trading uh a for lending or you can also do things like flash oh you want this idea of composibility because this is also what creates network effects and help helps us build this basically uh entire economy here uh the confidential token using a encryption based systems actually does have this composability uh property and then with this you can for example combine the combination token with a confidential voting You can also you know uh customize different logic for payments like you know streaming payments, recurring payments. You can also do private DeFi or confidential DeFi like a new money markets etc.
And with this you know it's really just a new primitive that allows you to keep on expanding use cases just like a ERC20. So you can build things like cap table, you can do blank auction uh do s some kind of betting. Uh this is what we call the encrypted garden. Essentially with these new primitives, we expect to see you know folks build things on top and then create some kind of network effect within this combination token ecosystem. And if you're interested in RWAs, uh we've also done some work uh with uh 3643 the 3643 centered uh which essentially has a identity module but imagine this identity module being confidential right so storing users credit score age geography location in encrypted manner fully on chain but you can still basically customize transfer rules without actually having to decrypt this information.
So again the idea of composibility here does open up for a lot more new new design space including identity but also programming you know all sorts of like transfer rules and compliance uh around this private identity. We're one of the co-founder of this confidential token association alongside with Zama and Open Zeppelin and we are proposing a new confidential token standard uh in the hope of unifying you know the interfaces and uh basically yeah if you're interested in being part of this definitely uh reach out to us visit our website there's a form there we're still very early you know it's actually quite important to get these interfaces right to maximize composability but also you know network effects and also integrations with different parties such as wallets ex exchanges etc So um definitely you know invite everyone here to join in the conversation. So, Inkco is a private compute layer for existing blockchains and uh we use encryption based approaches such as TE, FHPC and the reason why we think existing solutions fall short is typically there are new L1 or2 privacy chains where you do have to bootstrap new liquidity ecosystem user base which we all know is very difficult or sometimes you have to learn new DSL new languages and then install new wallets, learn new tooling which does cause quite a bit of friction and lastly you know compliance typically is hard to program within privacy and we're solving this. So we do offer the most intuitive way to write code. Um basically it's a library within the EVM that you can import with new data types operations.
You get to interact with existing liquidity, existing, you know, user base. Um and if you are a solidity developer, it will only take 20 minutes. So I think it's supposed to be light gray. It doesn't show up here. But essentially you know typically it is difficult to learn new privacy languages uh for folks who are into ZK.
I'm sure you remember the early days of learning circum and other you know um principles of writing circuits etc. Uh and with this you library you can build things like the confidential token uh where you can hide you know user balances transfers you can also customize different decryption rules. Uh you can also do things like product governance where you can hide the voting choice. Um, and I would say a big difference here compared to like a ZKbased system for voting here is because of this idea of a shared states, it's going to be a lot more intuitive for you to write these this code that involves multiple players because you know voting is a multiplayer use case, right? So in this case, you're just casting directly casting uh private votes by specifying the uh the encrypted choice and it's going to be uh a lot more straightforward.
We also also uh offer ultra randomness. Uh so this randomness is different than your typical VRF because this is going to be hidden by default, right? So if you want to build something like a poker game, uh you need to hide the cards. It's a bluffing game. And so this is where, you know, you can just call our function here.
It would return you an encrypted integer and allow you to build this use case in the easiest manner. So Inko, as you can see, we're more than just payments. Uh we're a general purpose library. So you can build new DeFi use cases uh around trading, lending, betting, even more than that and then also some new tooling and also gaming and uh we have a test on basip today. So definitely try it out.
Uh here's the link of our docs. And for folks participating in the hackathon this weekend, yeah, definitely feel free to ping us. We're on discord. Uh if you want to try something, you know, build something new that's private, definitely I would say this is a great opportunity uh to try it out. And yeah, nicely.
Yeah, so we've done uh quite a bit of uh joint integrations, partnerships, pilots. So if you're interested in working with us, uh feel free to reach out to us here. Uh you can also direct email me or send me a message on Telegram. Um yeah, so this concludes my presentation and uh yeah, super excited to bring privacy to the space and I do really think it's the next frontier here. One of the last milestone that has been solved and uh we're counting on everyone here to join in this you know this movement and try to expand on what's possible on existing blockchains.
Thank you. [Music]
Automatic transcript — names and jargon may be misspelled.