Confidential ERC20: Using FHE to Bring Privacy to DeFi — Furkan Akal | Inco

Hello. Okay. Hello everyone. Um welcome to both eat well grade and also this talk. U quite appreciate it.

Um as he presented me well I'm working at Inkco uh as a researcher coming from mathematics and cryptography background. uh and today I will try to explain our uh collaborative work with circle research on confidential ERC20s leveraging fully homorphic encryption. So yeah um trans transparency is has been a future in like in web 3 like you know everything is public everything is traceable good but like for us it's also a problem uh because I think like without without a certain level of privacy it's almost impossible to achieve the goal of mass adoption uh and that's why we're trying to bring um privacy in a you know hopefully compliant manner to web 3. Um, one other thing to I think it's worth um, distinguishing and being aware of is the difference between confidentiality and anonymity. Um, confidentiality is actually way more you know I think promising and also uh quite quite important because in anonymity we have several problems we have faced in the tornado cache stuff and the other um other alternatives in in privacy space.

uh but by confidentiality our goal is to bring privacy into web 3 in a hopefully compliant way. Um and I think this is the I think that the the like the that formula to bring the mass adoption. So what I mean by complying privacy I mean is like transparent like both keeping the transparency traceability in a private manner. For instance, assume you're going to uh make a transfer and like your address is public like probably written on your Twitter profile uh in the ENS form and I'm sure you don't want to you know expose your like transfers your investments in DeFi and the other stuff related to your money. uh and like I think the starting point to discuss privacy is a question and I think that is what exa what actually people want like don't want to reveal and probably the first answer is money like by money what I mean is salaries transfers investments um and like anything anything uh about finance and in in both personal and also um institutional manner the Other other answers could probably be healthcare uh which is quite out of the scope of this talk but I'm also quite interested in that part and I I would love to discuss any of you if you're interested as well uh in the venue.

Um so if money is one of the key things that people want people want to hide and are not willing to reveal about any any aspect then and also if blockchain technology is one of the you know revol revol revolutionizing ways of decentralizing money then why not combining these two. This was actually the uh the starting point where um where people started thinking about bringing privacy into web 3. Uh and like different privacy solutions existed uh so far. Tornado cache, Zcash and any other um any other solutions were there. Uh they're still there but everything has its own tradeoffs.

Um and the other thing which I think is important to discuss and be aware of the you know distinct like you know the distinctions is what we call commitment versus encryption. So commitment based privacy is also possible by using Z simply zk or other primitives. Uh but there is also an encryption based approach to to achieve privacy. So in this chart we simply compare uh commitment versus encryption approaches to to bring privacy. Uh in terms of compute overhead uh like obviously FH by its own nature uh it's and also the the fact that it's still a baby right now.

It's fairly new technology. It's compute heavy but like this heaviness lays in the like in the server part in our case like blockchains in the in the on the blockchain but in the commitment based approaches uh the compute heaviness actually lies in the client side because proof generations uh mostly run on the client side. Um in terms of privacy uh commitment based approaches probably have more privacy uh like especially in the in the cases where in the cases like tornado cache and the others uh but this is also even though I'm not a big fan of compliance um this is a reality for both like our future and also the uh mass adoption strategy of web 3 and the ecosystem partners um and like it's also possible to make it more private but that wouldn't be great for uh for compliance related things. Uh yes and this is our work uh with circle research and INCO um we call it confidential ERC20 framework um it is based on FH it's also possible to achieve conf confidential RC20s with different ways like these also as well um but I mean as as always um each has own its own trade-offs um we have simply um like mainly two But you know optionally three contracts the main confidential ERC20 contract is actually really really similar to the regular ERC20 contracts but the main differences which I'm also going to extend in upcoming slides we implement encrypted types and encrypted inputs for instance like mappings like balances allowances or like functions like mint burn transfer uh are done homorphically uh which allows us to uh build this contract. The wrapper contract actually is a part of the UX.

It simply um takes as input a regular ERC20 token USDC or something else and wraps it into its confidential equivalent uh and vice versa. Um possibly um it's also possible to build a uh compliant confidential artist of any contract obviously which would allow uh mostly governments uh to blacklist someone or like define some ACL uh access control uh list as a condition but obviously this is uh the the topic of future. So what is FHE? Uh I love to talk about FH and like it's probably a million times that I'm talking about FHE and I want it to be talked more than more than we have right now. Um it stands for fully homorphic encryption and the main difference between the other encryption schemes is it actually allows you to compute on encrypt data encrypted data.

Normally in other encryption schemes like uh elliptic curve based RSA different stuff we have many different schemes symmetric ones asymmetric ones they simply use a or more than one key to encrypt or decrypt a plain text or cipher text message and the goal here is to protect the confidentiality of the message while uh transfer or storage But sorry um but they they don't allow you to do any operation on top of the cipher texts. Why this is important? For instance, like big servers stores dozens of data, pabytes of data also blockchains like it's the same. We have many data stored or being transferred. But till 2009, it wasn't possible to perform like computations on cipher texts or encrypted uh encrypted data.

But in 2009, Craig Gentry um from it was Stanford uh if I'm not wrong proposed the idea like the first actually theoretically working fully homorphic encryption scheme. Uh it was based on letter space cryptography and ring learning with error cipher texts. Uh but obviously it was almost impossible to implement from the performance perspective. Um since 2009 we have developed many different schemes. Some of them are leveled.

Some of them are non-levelled. Leveled one uh leveled ones are mostly when you compute on that the level of noise which we call uh as that way some kind of mathematical error grows and you need to find a way to reduce the error actually and that was the reason why we couldn't achieve a fully homorphic encryption scheme till 2009 but recently actually FH schemes improved quite well uh from the performance perspective but obviously ly it's not still super great uh to use in our daily lives but it's actually suitable to build a confidential token on on a blockchain um as I said there are many different schemes TFHE is one of them uh it is fully homorphic encryption over the Taurus uh you can google it that way um and the next question as a blockchain person is how to apply FHE on blockchains or particularly EVM. Um it's simply there are two ways like we can make it um natively as adding a pro pre-ompile to the main EVM code but that would be that would be not that efficient uh considering that even uh 256 R1 curve isn't implemented. I mean even I wouldn't I wouldn't want the FAT pre-ompiles to be added into EVM because they are huge. So the other way the is the co-processor approach which is actually utilizing a different L1 and corresponding contracts on what we call host chains.

It could be Ethereum mainet itself or other L2s and that that way the when you want to build a confidential smart contract what you what you actually need to do is to interact with the co-processor contract to allow uh to the usage of encrypted types and encrypted inputs. So these what are these encrypted types? They are actually quite similar what we currently have in solidity. So we have unintent eu like we we have unintent booleans addresses and stuff. Um and thanks to thanks to TFHE library now we have EU in standing for encrypted uint encrypted boolean and encrypted addresses.

Um in addition to these types we need to have some methods or functions because I mean that's the entire thing like being able to compute on cipher text. Um similarly we have like tfadd subtract multiply divide or some comparison operations like greater than or equal to or equal to and things like that. And note that as it's fully homorphic you can do literally everything on ciphers x. Uh but I'm not I I cannot promise about performance yet. But in terms of confidential tokens and blockchain setup, um it works quite well.

Uh how about trust assumptions? The main trust assumption would be the usage of ZK. We we need to use ZK because in a fully homorphic encryption enabled EVM or FH EVM, users will be the ones who provide cipher text to the blockchain, right? But we need to check if those cipher texts are wellformed because otherwise that would break the other cipher text that gonna interact with. And the other thing we also need to check if the user submitting the cipher text knows the underlying plain text.

So these what we call them is zk zero knowledge proof of knowledge and that zk proof simply uh has two aspects like the submitter knows the underlying plain text and also the cipher text is indeed wellformed. Um in the blockchain setup how is decryption performed? Decryption uh is a simply an MPC setup. Um because otherwise because like the the key that you use to encrypt is a global public key. So everyone knows it.

So when a person A wants to encrypt they use the global key or another person B want they want to encrypt they use the global public key. So decryption key is also the same for everyone but no one no one has it and no one should not have it because otherwise everyone will will be able to decrypt the other people's cipher text. So the solution is to use a something we call u like linear secret sharing scheme uh built by Zama researchers. Simply it's a secret sharing scheme to you know to to split the decryption key among the validators and when someone like requests the decryption and they prove the like ownership of that like that encrypted data then the threshold network runs and if 66% of the network agrees on the fact that okay this person has a right to decrypt the cipher text then uh the threshold decryption works and the user gets its data. Um and yeah this is a example of a confidential transfer.

Um you can as you can notice the balances mapping has a really really really small difference than the than the regular one. The mapping is defined from address to u eu intu int. So demapping will look like in the first column there will be addresses and in the second column there will be gibberish cipher text and no one will be able to read it without permission or like without having the right to decrypt it. Um the transfer function like we have a obviously a you know conditional the the can transfer e boolean it's also encrypted and it simply compares the amount and the balance of the sender and this is also uh should be familiar from the regular ERC20 uh and then simply uh balance updating the uh from balance and to balance is done homorphically. uh by using tfac.

add instead of uh a regular plus and equal signs to to to perform the addition. Um and this is from uh the viewership. I'm going to skip this. And yes, composibility is a really important feature comes with FH uh you know instead of using a commitment space approach because normally let's assume you you build a confidential token and your friends build a privacy preserving decentralized application. these two separate things will interact really smoothly without needing to you know make them aligned in um in in some manner and the and this is actually uh naturally enabling um shared private states.

Um I wouldn't say this is the perfect solution but I would say for most cases um it's one of the most promising solutions in terms of privacy. Um we have also the thing we call programmable decryption and that's also something related with the complian compliance side of uh side of the case. Uh and it's also possible that you know in the contract creation level um the creator of the contract would uh grant some sort of extra access to some parties. Uh obviously this not this is not needed. Um this is something extra just to avoid uh you know legal uh problems.

Uh but yeah this is also a possible but even like even though as I said I'm not a fan of this legal things you know related to compliance um I have to admit it's kind of needed for for the mass adoption um programmable transfer rules. This is also something I really like. You can define some rules for transfers and you can treat it as something as automated uh in the in the workflow. It could be about you know salaries paid being paid in the every single day of the each month or it could be something else. So beyond this what act what what kind of use cases we have we have private crossborder payments private token vesting private B2B payroll private like you know even salary level payroll uh also in terms of defy almost everything is possible like private AMMs dark pools real world asset tokenizations uh blind auction and private lending and I'm sure there are some teams working on uh several uh of these um yeah to conclude confidential ERC20 framework offers a you know balance between privacy and usability and developer experience because it's pure solidity with extra um data types and methods.

Uh so no need to learn a new language or new um developer setup. Um and it's composable. you can build something that is going to work really well with different privacy preserving applications or tokens or I mean anything you can imagine. So yeah, we're quite excited about this and um if you want to you know quite dive deeper into the technical details, you can take a look at the research paper itself. Um I think it's a good one.

Um and I hope you like this presentation. Thank you so much.

Okay, thank you for coming for the talk. Um, do we have any questions? There's one there. Um, I noticed in the uh confidential ERC transfer function that um address is not encrypted. Uh could it be encrypted?

Yeah, totally. uh but it would need or require uh extra logic within the transfer function to uh you know actually prove if it's a legit not legit but uh you know it would be harder to let's say require the first require line and uh that's why in the first place we wanted it it to be as simple as possible and only encrypting the uh the transferred amount or minted amount or burned amount but it's also possible. Thank you.

Sure. Any other qu any any other questions?

Yes. No. Uh let's give an applause.