ZK powered privacy preserving tokens for enterprise use cases

Transcript

Hello. I think we should get started. Thanks for showing up on the last day. Uh, and great to see some familiar faces. Uh, my name is Jim. I'm the co-founder of Kido. So, first of all, uh, have to tell you a little bit a little bit about Kaleido. This is the first time we present at ECC. we uh participate but uh we haven't presented before. Um we incubated in consensus in uh 2017 to 2020. So Joe Lubman was our Andrew investor. Uh we focus on the enterprise use cases. Uh so we have three product tiers. Um we have infrastructure, we have middleware and

then digital assets including custody. Uh we have maintainers on BESU. uh we have uh contributed uh other projects to open source um mostly focused on middleware and uh and privacy. So privacy uh since our because of our focus on enterprise use cases privacy as you can understand is very important. Um way back in 2019, we already onboarded Zether. Some of you may know that uh protocol uh to our platform to uh allow people to try out uh this uh privacy preserving token implementation based on

the paper uh by Stanford professor and and PhD students. And these are some of the logos of our a subset of the logos of our clients. uh as you can see central banks, global major banks, uh other industries as well. Okay, so let's get into the content of today's talk. Um what does it take to build a compliant um pres uh privacy preserving token for enterprise use cases? So these are the tenants you have to think about. Number one, the on onchain source must be the final source of truth. This may come natural to all of you guys who are native in uh web 3

and the crypto space. But uh this is a very important uh aspect when you think about uh the banking industry where all the current source of truth are locked in highly regulated uh uh big boxes in the data center right maintained by the banks. How do we change that to make it a onchain uh source of truth shared by many organizations? So that's a very important change. Confidentiality hiding the content of transactions, how much you are moving um anonymity, who you are sending it to and who are you uh both the senders and receiver identity should be hidden as

well as history masking. Um, if you're not careful, if you build a token that shows who uh what are even if you hide the transaction details and identities, if people can build a spending graph of one transaction to another, one value to another, so they can trace the whole uh uh transaction history of a piece of asset, that that's sometimes considered leaking privacy as well. auditability. Um, understandably the regulator wants to see everything to make sure uh the whole uh system is uh compliant as well as uh when there's law

enforcement or court order that so that the full uh trace uh can be provided. KYC is very important for the regulated industry. uh in particular we want some form of anonymous KYC. What does that mean? So the regulators care that the participants of transactions are KYCD, but they don't necessarily need to know exactly which ones of the um uh approved list are involved in the transaction. So that's what we mean by anonymous KYC.

And since quantum computers are imminent uh 5 to 10 years horizon uh all these industries are already thinking about postquantum security. And finally composability uh we want to build a vibrant uh DeFi community out of the token so many developers can create innovative uh scenarios and projects and protocols on top of it. It's very important to have composibility. So uh coming to ZTO itself uh it's a open source project uh hosted by Hyperledger Labs which is contributed by collidal uh it's based on ZKP um and it's EVM you can deploy this to

any standard EVM anywhere um can be layer 1, layer two or other layers and it's regulatory compliant. Uh it's also extensible. At the moment there are 10 different implementations. This may be one of the uh most um prominent difference between ZTO and other tokens where other tokens is one protocol, one design, one system. ZTO is extensible. At the moment there are 10 different implementations depending on what uh trading policies you want you want to enforce for every transaction.

you can build both funible and non-f fungeible tokens and it's already being deployed to multiple uh central bank CBDC projects as well as uh financial industry use cases across multiple countries and continents. So let's look a little deeper into what it um looks like under the cover. It's built on UTXOs. So this is very popular design pattern uh used by many um similar privacy preserving tokens starting with Zcash uh Monero um ASDAC um in fact Bitcoin itself the very very first Bitcoin is uh very first use case

of blockchain is UTXO based. The benefit is um this allows parallel processing of all of your your balances. Even if you uh send 10 uh 20 transactions together, uh they all land in the same block. Uh they all they don't have to wait for the others to uh to complete. So this makes parallel processing uh very uh friendly. Um so optimizations that protocols make to make transactions parallel such as what Bessu team have have been working on. Uh this allows that to be optimized.

Challenges is uh clients or wallets can be quite challenging to build. You have to index everything to make sure you didn't miss some of your uh values in ETXOs. Um, so this is how UTXOs work, right? Uh, if we look at what bit, uh, Bitcoin looks like, uh, every piece of UTXO has the values as well as the spending rules and that's all in the clear. What we want to do is we take the same UTXO idea, but we want to hide everything.

So, we hash uh the important informations to to make them the commitment on chain. And then when we do trading, we want to make sure we use zero knowledge proof to uh to demonstrate that all these proposed transactions are compliant to the trading rules. Um in particular, we use Poseidon uh which is uh a friendly uh hashing algorithm for zero notch proof. So this is what states look like. Um you have shared state across different parties. Everybody has all the hashes uh that can be indexed from onchain events but only the owner of a state has the

actual private state. So you can see um you can see uh party one has two UTXL that they own one and three party two has two and four and they have the corresponding uh private information for behind the hashes. And um now we can look at how transactions work to spend them and to create new values. So uh we have hashes represented as rectangulars and private states represent as circles. Uh in the beginning there are three different

UTXOs and all three uh parties have uh indexed them so they see the hashes. uh but only party A owns a uh one two and three uh so A has the private states and can spend them. Now we can propose a transaction for A to send uh some value new value at in uh number five to party B and then uh give uh some change back to itself in uh number four. So now a transaction is proposed to spend one and two and then uh generate four and five and then transaction gets uh zero large proof is generated transaction gets um

accepted and indexed on the chain. Uh the values gets indexed by all the parties. So now BNC also has has the hash for number five and number four. So what about the private information uh behind uh number five that B needs to have in order to spend it? Well, there are multiple ways for A to make that available to B. Either it can be sent in the secure channel in a peer-to-peer manner or it can be encrypted and sent onchain for B uh to to be the only party who can decipher it.

So now B is able to uh spend it uh because it has all the uh all the secrets plus B is also the rightful ownership of the of the token and that can continue. So anonymity is achieved by using zero knowledge proof to demonstrate the possession of the private key. Uh so we use zero proof uh circuits to demonstrate that the private key can be the public key can be derived from the private key and then hashed to match the uh consumed uh input UTXOs.

Uh and there's no need to check for the message sender. You can use any any key to sign the transactions because the entitlement is enforced through zero notch proof not through the uh me message send uh uh transaction signer any longer. And this means you can use one-time keys to send uh sign transactions and nobody can trace your uh transaction history any longer. Uh we talked about history ma masking. How that's achieved is we use nullifiers. It's a secure hash that's uh securely bound to the UTXO that it's consuming. And this is uh how it's

achieved. Remember the UTXOs are a hash of the value, the owner's public key and a randomness. The nullifier is the hash of the same value, same randomness, but the private key that uh corresponds to public key. So this allows the user to demonstrate the ownership of the private key as well as this is the unique hash that only the that only the owner of the token can generate because of the poss uh the requirement of the private key and the binding between those two um can be demonstrated in zero proof.

Again, uh this is a bit of an eye chart, but um you can look at a um higher um resolution version of this uh in our documentation, but this shows the signals, both the public and private signals, how they're pro processed within the circuit, and how the circuit um generates the proof to demonstrate all the things we want to enforce in the transaction. If you want to understand the details um you can look at our uh documentation uh to look at the charts in details. Uh we use circum which is the mo most popular uh toolkit for uh designing and compiling your circuits

into wom uh or uh C++ uh circuits uh and then um uh witnesses can be uh calculated and proofs can be generated. So I talked about composability in order to support uh composability uh which often re uh requires a smart contract to orchestrate multiple legs of a settlement. So think of a uh transaction where maybe there are three legs. There's a payment of a asset and there's asset delivery to the payer and finally there's a registration of the t

title of that asset. So there could be three different um legs of a transaction. How do you uh how does the uh asset owner know that the payer is committed to pay for the delivery and reversely how does the payer knows that the asset owner is committed to deliver right so both needs to happen or neither should happen um and because we use zero knowledge proof we can't just give the asset to a to be owned by a smart contract like we do in ERC20 uh because a uh smart contract doesn't know how to generate zero knowledge

proof uh which are required to do any transactions instead we do we use a locking mechanism so a uh UTXO can uh be in the unlocked state and then through a locking mechanism can be a locked uh and be delegated to a smart contract which means only the smart contract can spend it even the owner itself cannot spend it as soon as it's locked. And of course, we have uh escape hatches so that if the deal falls through or if either parties wants to back out, they can um they can do the unlocking after certain uh expiration period. So with this you can do all kinds of um

orchestrations through smart contracts to do a DeFi uh protocol. This is what a locking mechanism looks like. Um, so we have A as the owner of one and two and through a lock uh call uh A can uh lock number three. So this will be committed to the um uh to the asset owner of a payment right the payment lag for the uh for the settlement. So now so that now number three uh is locked and the smart contract is designated as the spender or or the delegate.

So now uh the owner can generate the proof to give it to the smart contract and say use this proof at the time of the settlement transaction to unlock and spend uh this locked state. and which then uh for the final uh settlement transaction the smart contract can use that proof to uh to spend it and generate number five and this is this is all uh uh demonstrated in our tutorials uh with sample code.

The last thing I want to talk about is um you can use ZTO to uh to create a uh regulatory conformant uh compliant mixer. So when we think about Mixer, the first name that comes to mind is maybe tornado to tornado hash. And we've all heard about the horror stories for the tornado hash team um you know between them and law enforcement for many reasons that I won't go into.

Uh even though the tornado hash team eventually achieved compliance um they wish they had built this in uh from day one. So what you can do is um make a registry and this is um uh this is a pattern that is among the 10 that I mentioned earlier that has the KYC feature. Um you can maintain a registry of uh KYC users so that only the users that are part of the the registry can participate in the private tradings with ZTO. And you can deposit or shield your ERC20 um balances into this dark pool through uh a uh uh ZTO wallet. So, as long as

your uh ZTO wallet has uh private keys that's been uh KYCed, it's allowed to uh deposit into this dark pool and then you can do all kinds of tradings and then when you withdraw, you can withdraw to a different address and as such uh achieving the mixer function. Okay. Uh and finally, auditability. Um what we want is uh if the regulators want to see the details of every transaction uh there's another pattern that encrypts all the details of every single transaction and send it to a registered authority key and this needs to be um

postquantum right so all the encryptions you want to do on chain needs to be postquantum at this point otherwise it's going to be uh very soon broken uh or uh someone can uh download the encryption uh the cipher text now and then just wait whenever the uh quantum computer is powerful enough to break them and they can see everything. So we designed a quantum uh uh safe protocol uh that's efficient. So quantum safe protocol is no news, right? But to actually make them efficient enough for zero proof uh that's still quite a challenge. So we uh did a lot of work with a team of researchers and

cryptographers in UC Berkeley as well as um uh Dr. Hart Montgomery, the CTO of Hyperledger and Linux uh foundation decentralized trust uh to add this uh postquantum secure encryption to ZTO so that we can make that encryption for the uh authorities uh to be safe and there's also a formal modeling of ZTO a paper by the same team uh the paper is pending publication and finally I want to mention that ZTO is not a project by itself. Um it's got a uh sibling project uh also part of Limb's foundation uh called Paladin that

is a framework that supports many different uh privacy uh patterns. ZTO is one of them. Uh there are other patterns and there are future patterns like even like FG based uh privacy uh frameworks can be supported there. So you're all welcome to check out ZTO Paladin and let us know your feedback. Thank you. [Applause] We have time for questions, but if you have some questions for the speaker, he can answer privately after the speech.

Thank you. Thank you. Yeah, we'll be outside. [Music]