Confidential ERC20 Framework: A New Primitive for Onchain Confidentiality Proposed by Inco and Circle Research

Transcript

[Music] [Music] Hello everyone. Hi, I'm Remy. I'm the founder of Inko. Today I'll be talking about confidential ERC20 framework. It's a new primitive for onchain confidentiality. So this is from a report from Paradigm. So they interviewed over 300 institutions and if you see here on the charts um p the lack of privacy is really one of the top three reasons why institutions are still not using DeFi and blockchain today. The first two reasons are really around perceived risk and regulatory uncertainty and privacy

here as we can see is pretty much on par as the first two reasons. So this is the current status of today's blockchain right? So everything's transparent. Your address, the amount that you hold, and how much you're sending to each other. Now, blockchain transparency really is what we think is the feature, right? Because you want to be able to verify that nobody's cheating. There's no double spending. But really, it's more of a bug than a feature. Why do I say this? Because how can you actually adopt blockchain technology if everything on chain is fully transparent? So by show of hands here, who uses crypto every day here or has some crypto, right?

The truth is like you can see how much everyone has, what everyone's buying, what everyone's trading. If we were to on board a billion people today, wouldn't this be crazy? Like you can see how much your neighbors has, how much you're getting paid, etc. Right? So really privacy is going to be necessary for mainstream adoption. And the reason why so far it has not been incorporated into blockchains is because we haven't had a really good way to make it verifiable. Right? So uh we should really think about privacy also as a spectrum. So a lot of people think privacy is just you know general privacy but privacy should really be seen as a spectrum. So on one side you have confidentiality and then on the other side you have anonymity.

So what is anonymity? The idea is really you want to break the linkage between the sender and recipients. So by doing so, you're actually kind of hiding how much everyone has uh but also the addresses, right? Uh so this is just obviously a rough generalization, but the key point of anonymity is that you want to hide basically who's interacting with whom. And so what are some practical examples of use cases of why you need anonymity. So what if you were to visit a medical facility, right? If you were to see a doctor, you probably don't want this information to be on chain. or what if you need to give a political donation to either party, you probably don't want this information to be on chain. And so there are a couple of projects um that are working on

anonymity such as sodium cache, real gun, ass. And again, this visual representation is obviously not going to apply to all these projects, but the idea is that you want to break the linkage between the sender recipients to achieve these use cases. And so what is confidentiality? So confidentiality is the more vanilla version of privacy. The idea here is that you want to hide the amount that people have. So I could look on chain that and see that you know this is Alice's address, this is Baba's address, but I cannot see their balance. Their balance would be encrypted. But you can still send a confidential amount to each other. So it's very similar to like a veno experience for those from the US or like a revolute. You can see your friends sending money to each other just not the amount. And so what are some practical example of use cases for

confidentiality? So payroll, right? So you want to hide how much you're sending to your employees, how how much everyone's making or supply chain. So the classical example here is Coca-Cola. We all know who the suppliers are. We just want to hide the amount that's being paid out, right? So that this is a really good use case for confidentiality. And some example projects that utilize combinity include Solana confidential transfers, Avalanche ERC20 and also combination tokens that we're proposing here. So why is this uh such a difficult topic right uh the reason why is because privacy can be problematic right hackers actually love to use privacy to launder their funds as we've seen

so there needs to be some kind of compliance in place to avoid these type of issues on the other hand actually compliance actually can also help bring privacy to mainstream if you think about things like payroll there's a lot of PI information be involved So at some point you know today most people don't really care that you're sending you know payroll over onchain in a public manner but in many ways this is actually a very gray area and actually very primatic down the line because you are actually leaking a lot of PI information. So as this space matures compliance will actually help push for privacy on chain and advocate for it.

So there are a lot of existing privacy solutions uh that are commitment based. So tornado cache which is probably the most famous one uh is essentially a mixer. So you're able to break the linkage between the sender recipient. Zcash is a privacy chain. Uh it doesn't have smart contract capabilities. And there are projects that have been trying to apply compliance uh to ZK based approach such as privacy pool. So the the idea of privacy pools is very similar to like a tornado cache. But the difference is every time you withdraw funds, you can generate Z proof that you know any address that are you know blacklisted or or malicious are not sending funds to you, right? So you're basically sort of proving that you're innocent or the funds you're withdrawing are are sort of innocent. And then cape

is another project that uses uh also commitment based approach. Uh the way they do compliance is by enabling some kind of viewing key uh that can be shared with auditors. So what we're proposing here with the confidential ERC20 essentially is a encryption based approach. So what I mean by that is basically think of MPC FHET. I'll say it's a different category of solutions than the other side which is you know zkbased solutions and the combination ERC20 framework is actually very similar to a regular ERC20. It has all the similar features.

So you can see your balance, you can send money to each other, you can do transfers, you can do allowances. Uh the reason why we're not saying it's it's directly the same is because we do have to change the data types. So obviously the fields uh of your balances, the amount you're transferring are going to be encrypted. So that's why it's actually not directly the same. Uh but you can actually turn this into a wrapper. So in that sense, you can basically turn any ERC20 into a confidential token. So if I send USDC to this wrapper, it becomes a confidential USDC or if I send USDT, then becomes a confidential USDT. And this can also be extended to add additional rules uh that I'll cover later, things like transfer rules or or block list. And um there are two things that also are can be

optional. So one is delegate viewing and the other one is um transfer rules that I'll cover in a bit. Um so in the paper we basically use FHE as an example. So what is FHE? FHE essentially stands for fully homorphic encryption. The idea is that you can encrypt information but also compute on top of it without having to decrypt. So imagine if I were to encrypt the integer 10 and someone else encrypt the integer two. we can both basically add the two together without re revealing information and when you decrypt it actually becomes 12. Sounds like magic, right? Um so decryption is actually decoupled. So typically the way FHE works is you know you use cryptography to do compute but

you're also using different type of crypto well you could use MPC basically essentially to decrypt. So these two you can think of it as decouple and the scheme that we utilize as an example is TFHE. So stands for FH over Taurus. Uh why FH over Taurus? So there actually many different FH schemes. FH over over Taurus essentially has a couple properties that are quite useful in the smart contract context. So one is the accuracy of computation. So the end results will always be accurate and the second is it does support a quite range of operations such as additions, divisions, multiplications, etc. and also known levels. So meaning that you can keep on computing uh and the the reason why this makes sense in the context of smart

contract is because you don't necessarily know ahead of time how many steps you're going to be computing, right? So you want something that's actually non-level in that sense. So you can apply FH to the EVM in a couple manners. So basically obviously as a native chain uh when you add this as a pre-ompile, the second way is really as a co-processor. So this will be enabling FHE to existing blockchains and by doing so you essentially enable new data types inside of EVM as well as compute capabilities. A couple trust assumptions that are worth mentioning. So ZKFH today is still quite expensive and kind of far away. Uh to give you some sense, a bootstrap takes roughly 20 minutes to prove. A multiplication will probably take

something like 20 20 days because it has a couple thousand bootstraps. Um so that's probably some time away here. Uh you can also come up with some kind of optimistic fraud proof where you know similar to your typical rollout fraud proof you can do some kind of bisection right. Um or this third way is really through consensus. So because it's deterministic you can have different nodes perform the same computation achieve consensus and so that's one other way to basically you can do this do it today but obviously at a cost right of replication. The decryption is going to be NPC based. So the trust assumption here is m MN you really have to trust basically uh the folks running the MC network. Um but just wanted to explain how this looks like how the

combination token looks like in practice uh in terms of code. So with these new data types eins you basically can hide your balance right. encrypted balance and when you do a combination token transfer essentially you're passing in a encrypted amount as a parameter and then in the first line of code you basically check if the amount you're trans you're transferring is less than your balance right and from that you get a encrypted boolean uh which basically you pass into the second line a slide function you can think of a if you're a developer you can think of it kind of like a turnary essentially you pass in as a the input and returns the first argument the amount if it's uh true and the second argument is zero but zero is also

encrypted. So essentially the transfer value here on the second line could either be zero or the actual amount depending whether or not the first line is true or false and what you end up doing after is you're adding basically this amount to both the sender uh so so you're adding the amount to the recipients and you're subtracting from the sender. So you basically end up adding basically the actual amount or adding zero or or subtracting zero. And the reason why this is designed in such a way is because if you think about it, right? If it's a public blockchain, dividers can run a node, you can view everything that's happening on chain.

How do you write conditionals, right? You you can't have conditionals because if you basically execute different path, you are kind of leaking information about how much the user has, right? So, this is actually one way to overcome this this problem. And then to allow for view functions, you basically have something a little bit more explicit. I can allow different parties to view my balance by calling this allow function. Uh so just a quick uh demo on what this looks like. So this is on basipoleia. You can send USDC to the robber contract. Uh so here I'm basically shielding uh an encrypted amount.

Actually sorry the the amount I'm shielding is actually public right because you are sending plain text token into the wrapper. Now to view my balance, all I have to do is sign an EIP712 message to prove that I'm the owner of the wallet and then I can send a combination amount to another party here. And so here the the number five is actually encrypted on the client side and I'm just casting a transaction um on the client side here. And let's take a look at the ether scan. So we can see that I'm interacting with the contract, the wrapper contract. The address is transparent and the amount here is what's in what's encrypted

um after after yeah so in a paper we really compared I would say two categories of solution like I mentioned earlier one is commitment based solutions so think of ZK the other one is encryption based solutions so MPCF HTTE and there are differentiated properties here. So we can argue that commitment based solutions are actually uh more scalable as we go because everything you prove is on the client side right so you're kind of distributing the work across all the users in the encryption based solutions you kind of need the blockchain all the co-processor performing all the work so it's a different type of scale u scaling challenges u but there are also you know other trade-offs here uh you can also

argue that commit commitment based solutions are also more private because the secret key that's used to encrypt your balance never leaves the client, right? Uh in the encryption based system, it's actually a share key. So you could argue that it's a little bit less private. But in terms of decryption rules, encryption based system are are going to be a lot more flexible as compared to commitment based solutions. So I'll dive a little bit deeper here on the next slide. And then the the last part is really around this idea of composibility which is also quite of a differentiated property that encryption based solutions offer. So, so why is commitment based approach more rigid, right? It's more rigid because every single user has their own viewing key. And so, typically the challenge with that is you need to

install a new wallet or find a way to custom when Bob sends money to Alice, Bob has to specify Alice viewing key part of the proof generation. And so, only Alice can view her own balance at the end of the day. But what if she needs to do taxes, right? or what if she needs to dug a view into an auditor to an exchange to train analysis. This becomes very rigid because they wouldn't have access to Al's viewing key unless she know explicitly give the viewing key which obviously is primatic because then they can see everything in the encryption based approach because it's a shared key. What ends up happening is that all the decryption rules can be fully on chain and so you can always change these rules via transaction governance uh in

various ways and you also don't need a new wallet right because there's no viewing key requirements you can also retroactively always audit investigate um backwards right versus the commitment based approach you kind of have to know who gets to decrypt ahead of time so it's it's very different paradigm I'll say in terms of like flexibility and there are practical reasons why you want maximum flexibility for decryption. Uh so for example if you a user obviously you might want to delegate viewing to your CPA account into your taxes. Uh if you are uh I would say an asset issuer maybe you don't want to monitor the asset life cycle uh the velocity of you know confidential USDC for example being transacted. Uh if

you're a government entity maybe yeah you can enforce some kind of like compliance monitoring etc. There are a couple benefits here with composibility. So one is end to end confidentiality. So there are a few projects working on dark dark pools. The idea is that they want to you know enable some kind of private trading. Now the problem with dark pools generally that most people don't know is that you are already leaking information the moment you send money into the darkpool right because everything is transparent. Now if you can send a confidential amount to a dark pool then that already uh solves a lot reduces a lot of the risk and and you know the typical like reactions that people will have. Uh the second part is composability

over this idea of a shared private states. So what I mean by that is the confidential token is actually very similar to like a ERC20. Today if you look at unis swap a compound we're all using the same primitive and I'm building on top of it kind of like a Lego right? So confidential tokens also have the similar uh property where I can extend the confidential token to build a streaming payments application governance lending etc. So what this really means is that you can actually keep on expanding and creating some kind of network effects with different applications on top of this new primitive and this is not going to work with uh commitment based approach because of this viewing key uh requirements right it's it's just adding a lot more complexity because things happen offchain

uh so one example that is quite interesting with this idea of composibility is that you can program transfer rules so we've done some work uh with with the tokeny folks on the confidential ERC 3643 Three, the idea is that you can have a confidential identity module where imagine storing user uh credit score, age, geographic location encrypted manner and you can still program transfer rules without revealing what it is. Right? So for example, if Bob and Alice are not from the same jurisdiction, you can basically essentially um know the transaction, you basically end up transferring a zero. uh or um there are all sorts of basically um rules that you could program based on this onchain uh identity that's fully

confidential. And so the combination token really is a new primitive that's quite useful for various use cases including payments crossed payments token vesting. So imagine you know vesting your arbitrum tokens, wormhome tokens or any tokens uh for payroll uh for remittance and then the idea is that is to also enable new use cases primitives to be built on top of it. Uh just wanted to quickly compare confidential tokens uh commitment versus encryption based approach. So like I mentioned earlier there are a couple different parties offering uh confidentiality via confidential tokens.

So by having a share viewing key, you essentially uh going to be more compatible with the existing wallets and tools because you don't have that extra requirements. Uh you can program basically decryption rules in a more flexible manner. Uh it's lower it has a lower cost because there's no ZK proof verification and then it is composable. So you'll be able to extend uh this to token with more use cases. uh versus a commitment based approach uh where every single user has their individual key, you are going to need some kind of new wallets or new ways to store this additional um additional components. Uh the decryption rules are going to be a little bit more rigid uh because you have to know ahead of time who gets to

decrypt and then there's typically a higher cost as well because of the ZK pro verification and then lastly it does prevent composibility. So typically uh folks will use uh these tokens to just purely do payments. Um and uh yeah, I just want to conclude saying that um the idea really of the convential ERC20 is to propose a new primitive that's more ergonomic to program in a business logic uh risk management compliance uh in a friendly way. And uh and the second part is really just enabling folks to program more things on top of this new primitives. So we're happy to chat with you if you're interested in learning

more about this. And uh yeah, I'll take some questions now. Yeah. Yeah. Go ahead. Is the confidential Yeah. Is the confidential ERC framework specific to FHE for example or to the underlying scheme? It's a really good question. Uh no. So this is what I meant before. We can think of two categories. Commitment based solutions which are typically ZK encryption based solutions or MPC FHT all can achieve the same property basically. Yeah. Um, if I understand correctly, I would be able to see the cipher text of the balances. Uh, is that right? And if so, if I have one token in my wallet and you

have one token in my wallet, is it the same cipher text or a different one? So, that's a good question. So, no, the answer is no. U, there's always some randomness added to the cipher text. So, even if you're encrypting the same integer, you'll look differently from the outside. Yeah. So speaking of basic polia demo, you said that the amount is the encrypted data and the address is a plain text. Why not make the address is encrypted as well? Is it the legal requirement or something?

So that was kind of like the spectrum uh that I showed earlier. It's a different it's good for a different use case, right? You you could also encrypt addresses uh but it would be for a different use case. And so I didn't show it on for this presentation but in my previous presentation on sable summits I also kind of explained how to think about compliance right around this the spectrum. So obviously yeah if you're offering something more vanilla privacy like confidentiality the risk are are going to be a lot lower because it would be a terrible tool for money laundering right if all the flow funds are traceable not not really great for money laundering. If you're offering anonymity this is where you have the most risk you have Lazarus who might use it uh etc.

Right? So this is where ideally you want to enforce a little bit more compliance uh KYC KYB everyone if you can. Um I I think that part is definitely a little bit more primatic and it's also not super clear what is the right approach and I think everyone's trying to figure out basically. Yeah. Oh okay. Thank you. [Music]