zkPACT: ZK Private Crosschain Token Transfer Framework

Transcript

Hello and welcome everyone. My name is Peter Robinson and this is the Ethereum and AI group meetup. Um today we've got Elma and Stefan and um they're going to talk about ZPCT. It's a zero knowledge private cross-chain token transfer framework and um so Elma could you please introduce yourself before you launch into your slides? Yeah. Hi, I'm a fourth-year PhD student working on blockchain interoperability at Technical University Berlin. And yeah, today I will talk about our private

cross-chain token transfer framework, and I'm happy to be here in this. We are more than happy that you're here. Should Stefan introduce himself too? Do that. My name is Stefan Schulte, professor for Software Business Engineering in Berlin. Before joining Berlin last year, I was in Hamburg for six years, before that in Vienna, and before that I did my PhD at Darmstadt. And even before that, I studied among other places at the University of Newcastle, Australia. I am doing research in the field of distributed

systems; a large focus of our work has obviously been on blockchain technologies in the last few years, topics working on. Distributed systems like edge computing these days, a little bit of edge AI. Thanks a lot for being here. All right, well thank you both. So please. Present your slides. Here, can you see my slides? Yes, and

we can see your laser pointer. Perfect. So, first of all, thanks for joining. As. I will present and talk about how zero-knowledge can make cross-chain transfer finalization verifiable, how batching can reduce on-and off-chain costs, and how. Privacy can be achieved through commitments and proof-based. ZK . Before diving into the framework

design, let's look at the concept of blockchain interoperability. Blockchain interoperability is the ability of independent blockchains to, you know, communicate with each other and. Transfer assets and data seamlessly. And one simple and flexible method to do that is through a notary-based solution where a trusted entity monitors and relays, you know, data and information from and to the blockchain. Systems are simple but have centralization problems and single points of failure. So modern oracle

networks. Act as decentralized, distributed notaries. A committee of nodes, let's call them validators, retrieve and verify. So here the blockchain oracles act as bridges between blockchains and external data sources to transfer data with trust. What we have here is that these works and studies have limitations, and that is exactly where our ZK-Patch paper and work comes in. So. The motivation

behind our work: first, as I said. Centralized works have problems with centralization and gas costs and. So we add innovation with decentralized validator nodes. Let's say they are allowing permissionless validation. Dynamic committee parameters. To exit committees. Another. Dynamic slashing.

Providing to keep the validators in active participation and also let. So. Make. Another. Lower costs to. Shifting computation out of the blockchain and only submitting one single proof about correct computation to the blockchain. Another thing that we did is that we introduced a batching technique, allowing multiple transactions to be verified with one single proof, even

reducing the cost further. Zero-knowledge proof enhances user privacy by protecting transaction details on the network, and another thing we add is that commitments act as off-chain mixers, breaking links between transactions and adding a layer of anonymity, which is important for blockchain-based systems. Another Business relationships, payment methods

, and origins, so we don't want that; because of this property we add to the system, we also integrate a Know Your Customer (KYC) mechanism because we want to prevent illicit activities like money laundering, and for blockchain-based systems, it is important because they want to ensure only eligible users participate in their system; these are the motivations behind it. Introducing this, because we didn't have other papers or works that had all of them at once, so this zero-knowledge proof...In Verify, verifier, secret Is Without revealing

it Zero-knowledge proof, interactive, requires back-and-forth communication between the prover and verifier. Independently, example, interactive Cave example, imagine you want to Pass through a magic door shaped cave, so you enter through either of the two, then your friends And knowing Your friends Without actually learning

anything about This is an example, and for non-interactive zero-knowledge, we have three different types, and among all of them...Blockchain Because They have small proof sizes regardless of the complexity they are going to prove, and also importantly, the verification complexity is constant time; the time it takes to verify the proof is constant, so we can verify it easily on-chain. A bit of details: Low intermediate And Circuit Into

intermediate representation including keys: one is the proving key and one is the verifying Compiling, and we will discuss this later. On computational cost or memory, just remember that this is compiling; we also have a prover where a prover uses both public data and Private data and public keys to generate a proof; the verification Zero And Deep dive into framework design;

how the framework works: here we have multiple different components—the user who initiates transactions and undergoes a KYC verification which involves a trusted issuer, and we also need an IPFS node to store the incremental Merkle tree of the commitments, which we learned what it is, and each target blockchain has its own oracle committee, and we have smart contracts deployed on both sides to handle the request. The process starts when a user obtains verifiable credentials from Transact and submit a commitment of that transaction to the

smart contract; the smart contract on the source-side blockchain verifies the amount of the user's balance, burns the token, and emits burn events to the network containing that commitment. Update Global commitment, so Use to The token Commit and invoked The user

submits the initial transaction and submits the proof to the target chain; the target chain gets that request Against Lines and back-and-forth Verifiers Are registered and Reach consensus and apply penalties and rewards based on And the And the The smart contract verifies that proof and

mints a token for the requester and updates the state. As you know, we have different Merkle trees here; one is the revocation tree which the issuer keeps. For credentials, we have a global commitment hash kept off-chain, and two are off-chain trees. We also have an on-chain validator state tree, the root of which is periodically updated in our system. Now, what I want to do is extend and expand this. User identity.

User identity, so we integrate KYC based on ZK-SS principles. What this SS means is that the issuer verifies the user and gives them a digital credential. The user can store them and later prove, you know, that they have a valid credential. This ZK part is adding zero-knowledge proof to this.

What it means is that for a user, they are—without revealing facts—or the user's nationality, you know, belonging to the valid set without actually revealing their nationality. Here we have two terms that we should know about: one is a verifiable credential, which is a digitally signed—let's say —KYC, and a verifiable presentation. How our system works is that the hash

tree—the revocation tree—each credential has a position in that tree, and when a credential is revoked by the user, the leaf of the tree is updated and the root is also updated. So, for that, the issuer sends the revocation root to the target blockchain, and in the first instance, meanwhile, the validator defines the smart contract. First, the user just undergoes normal KYC verification with the issuer, and the issuer gives them a verifiable credential. Then, the user generates a ZK proof. They satisfy the policy, have

not been revoked, and have not expired. They send this proof back to the target chain, okay? And that's where the target chain generates a claim token. This verification by validators happens like I said earlier. This is how it all works. Are there any questions? You may ask. If there are any questions. No, I will continue. Yeah, please, do you

have any questions, or should I just continue? Yeah, I think I'm just thinking through the whole setup, so you've got the user who initially, I guess, they—you know— step zero would be they apply for a... Yeah, so 1a is the very initial revocation storage setup, and then the policy setup, yeah, all right. It's the policy defined based on the use of the organization based on the specific use case. So there should be multiple policies in our system based on the

organization. So, does the—so you had number six as the claim event. Do you need to re—you know—so you've got your ZK proof, but do you need to do steps 3 to 6 each time you want to use it so that the KYC or the revocation tree root is up to date when you want? Yep. You need to do this every time that you want to claim a token. Yeah.

That's true. But I mean, there are some ways that I was thinking about, such as using ring signatures that we can add, so that when a user burns a token, they can use it multiple times on layer two. Then, when they want to come back to layer one, they just say, "Okay, we did these communications and transfers, now I want to withdraw." But in our system right now, for each burn, you need to generate one proof. Yeah. Yeah. Ok. All right. That makes sense. Are there any

other questions? Oh, there's someone with their hand up. Mark, please fire away. Um, hi. I uh, I just...and sort of similar to Peter's question, I think . There are multiple uh proofs, um, and a question I'm curious about is how they are connected in terms of the information or data. Um, are there some plaintext identifiers essentially that are connecting, or pseudonymous identifiers that emerge that end up connecting the proofs? Um, connecting the proofs, what do we need? What do we need...we need to somehow prove that a burn is connected to a claim. Yeah. You

got a...we got a proof in relation to KYC and you've got another proof in relation to the transfer. Concise. User . Actually. Slide about our secret, what they do and what they undergo. Once this...and without this, the user ...with this, the user is a valid......

and a compliant, you know, KYC-compliant, without indicating which [one] it belongs to and without indicating their identity, nothing is, you know, revealed here. In that case, maybe I misunderstood what the relation of this workflow is to the previous workflow. Here we have the workflow, and here before the workflow, the user needs to get, you know, a signed verifiable credential for the identity which is hidden from the organization and our oracle nodes, but one thing here is that......if [they] want to...

...the paper said we......user system ......system......with......user the back door of which identity belongs to the commitment......and use...... generate......for......that may reveal the user. Identity, so here let's say

the solution is that we just use multiple issuer signatures, do like threshold signatures between them, so none of them also......can reveal a user's identity. But for now, we have one trusted issuer, assumed to be a trusted issuer, so linking...there is a kind of linking possible, but only by the issuer, is that right? Yes, yes, okay, here, yeah, yes, if the issuer goes, like, malicious, then they can reveal the identity of the user, but it's...we just put this assumption that , okay, it's a trusted government. Can I continue, any...I think [that's] good . Um. The point here is that these are

last-minute slides, and I thought it would be great to provide an overview of what each of those circuits proves, specifically the claiming circuit where the user and validators are the verifiers for what this does is first check that is connected to a valid commitment of verification; this commitment contains a secret and a destination, and the credit actually prevents double-spending backend The user request claim sends the nullifier

hash, and the first validator verifies that the nullifier does not exist in that spent nullifier list to prevent double-spending; next, the circuit checks the valid credential that the issuer is a valid issuer by checking the signature, ensuring the credential has not expired and has not been revoked, and also satisfies the policy. The other thing is that we also check that the proof is bound to the target destination ID because we don't want to have cross-chain double-spending. We don't want to allow reuse across multiple chains. So, this works as I said: the user proves that he knows a

valid commitment and his credential is valid. here The aggregator is the verifier for the on-chain smart contract; in our system, we assume we have f + 1 validator committees, and f is the maximum number of faulty validators, so even if validators validators are registered and only

counted because we want to mitigate Sybil attacks and make it expensive for an adversary to do that. Next, we check that the batch the aggregator signs is correctly bound to the correct round and batch to prevent reuse. And also check that at least f + one validators support the decision, so if some validators do not respond, we still reach a finalized batch here, and finally check validator manipulation by the aggregator. We don't trust the

aggregator. It should be that we need a proof from him. So here, with one proof , we verify the batch decision and that validators are rewarded, and updates are correctly done off-chain; by verifying this proof, the smart contract accepts and applies those changes and updates, like the earlier slashing circuit, where again the aggregator is the smart contract verifier; it is similar to the voting, but here it is for the validators who deviate from the threshold decision, so first, the circuit verifies that the

signer is registered, because we don't want to do faulty slashing, and it proves and checks that the vote really differs from the decision, and checks that the penalties are correctly added by, you know, deducting incorrect ones validator deviate works and now the

evaluation we evaluated both the on-chain usage and off-chain memory usage for computing, verifying, and proving of here parameters here, meaning sizes and committee sizes the circuit that the user uses is independent of the sizes and committee, so the Regarding computation, the constant is 50 megabytes, proof

generation is 66 megabytes, and these relate to the user. Because verifiers verify that proof off-chain, the cost transfers to off-chain memory, which is 39 megabytes for each validator. Next, the point here is that because the slashing circuit and circuit are, you know, validating circuits, but they have fewer constraints than validating, so the, you know, values are a bit less . For the computation, we conducted three experiments: comparing dynamic

sets with fixed sizes, and the committee size is here on the left-hand side. It compares with the number of sizes and also, in part, uses more memory due to the extra constraints for the dynamic slashing that it adds. Next , we change the batch size to compare operators. Generation, in the

generation as Oracle generates one per request. It increases linearly and dramatically, but in our work, we generate a proof for the entire batch, which results in, for example, 128. Size, we have times less memory usage. One thing here is that this later needs real numbers. It may be so high it is

not valid in real life. And for the experiment, constant, increases linearly. Is of generation. Both of them here seem constant because of the scale, but as you can see, the ZK Oracle increases dramatically because of the non-batched version. And for example, at the batch of 20, it is up

to 18 times lower than the ZK Oracle, showing the efficiency of the system. For the computational side, we calculate the gas used because it is important for system efficiency for users. Here, in real consumption per operation, as we have some functions; some functions are related to the user, like stake and burn, and they are

constant in our system; they don't depend on the size. Also, the aggregator functions, aggregate and submit, are also constant. But what we have here is that some validator functions, like register, withdraw, exit, and replace, they increase with the increase in committee size because they involve Merkle proof verification, so it depends on the depth of the tree. It increases with the depth of the tree and reaches up to 1 million gas. And as I said, in the real world, we don't

need this much of a committee, and these are one-time gas costs for validators, and actually, it is worth it to use our system because they gain reputation and rewards. Next, we compare our system with the ZK Oracle for the two functions of aggregate and slash here. The amount of gas used, because these two functions are related to proof and proof verification, and the amount of gas used for them depends on the computational complexity of the verification. It depends on the input structure. Verifiers need to verify in

our system; we used one proof per entire batch, and the number of public inputs is independent of the size, so we have constant gas costs. But as you can see, the Oracle generates per request, a up to 95%reduction for the gas consumption. The last part of the evaluation section is that we also analyzed throughput and latency; I don't want to go into the details here,

but and the most important thing is the transaction throughput; as you can see, when we keep the committee size fixed and increase the number of batches, we see an increase in throughput because, as you know, the constant costs of validator coordination, aggregation, and on-chain finalization are shared among more claims, and latency also decreases because, under current loads, the batches process rapidly and constantly, so the queuing pressure on each node is reduced. Next, we keep the

batch size fixed and increase the committee size; here, as you can see, the throughput decreases and the latency rises because when we increase the number of validators, each block needs to be verified by more validators with more votes, and those votes need to be processed—more validators need to be processed by the aggregator. So, all of these result in this. So now we know that the committee is the limiting factor here for the scalability of our system. And so, if we have higher committee numbers, we have higher

security guarantees, but we also have coordination overhead added to our system. Fixing the batch size and committee size based on the best option , and also maybe in the real world, as I said, having a fixed batch size, but the load of the network in reality differs, because sometimes we have more requests. Having a dynamic technique for adjusting. Now, for the conclusion, wrapping up. Using zero-knowledge proof techniques and validators by adding a

slashing mechanism to the system for future work, integrating a mechanism for reliable synchronization, and we want to define a mechanism for fragmentation to add decentralized aggregation to, you know, reduce the let's say, because if we have one aggregator, if that aggregator goes down, all the validators need to wait for a time period to get another, the other validator using round-robin in

our want and want to define a mechanism to also reduce the user latency to improve the user experience; this is it , and thank you for listening, and if you have any questions, please feel free to ask. The paper is here, and you can reach me whenever you want if you have any Thank you. Yeah. Well, thank you. I mean, uh, you don't need to be thanking us for listening. We are thanking you for presenting. Um, that

was great. Um, so I can see that Lucky has a question. Why don't you go ahead? And Stephen, yeah, thanks. Thanks for the presentation. Um, yeah, I'm Lucky; I'm also a fourth-year PhD student at UTS. Yeah, I am coincidentally also doing research on sharding, and I have a presentation on the paper. I designed a framework called FLayer. Um, the latest paper at the IEEE ICBC '24. Um,

just some feedback more than questions. Um. In my first layer first version I designed something similar. The sender uh will have the fund locked in a smart contract and then the receiver can uh claim and then this. single claim uh with on-chain and then this uh ZKP batch claim uh can be more efficient so really similar um and then there's another project called Aligned Layer.

So my design was to outsource the ZKP part to the Aligned Layer. Uh what they do is uh uh they are using EigenLayer as the data network and then they can do the ZKP part. So basically can outsource to them. Um and yeah that that's uh but I do see some uh benefit in your case because the Aligned Layer is more like a generic ZKP that you could do any uh anything um and yours is more specialized and can generate your own KYC. So yeah, that's the the good part. Um but then I I evolved this

version to my current version because I see some tradeoffs; my current version is uh MPC to release so it can provide atomicity. Yeah. the the efficiency and uh the dependency that it can only support blockchain networks that support smart contracts. My design is I wanted to support the Bitcoin network and other networks that don't support uh that that's um something that I the

reason why I use MPC to support like all networks. Um yeah, it's also some feedback but maybe your network can support uh non-smart contracts. I don't know, just yeah, some of the feedback that's related to my research as well. So yeah yeah thanks for the feedback, I will check those two papers, I would be happy also to collaborate with you on those to see how we can improve my system, but actually because our system currently, you know, only accepts EVM-based chains, not non-EVM-based chains, and also only you know blockchains because it's based on

Oracle nodes, we need some smart contracts deployed. So we need a smart contract and also because of ZK proof, we need some chains that have efficient elliptic curve cryptography. For the ZKPs, these are all limitations but we can actually extend the work. I will check your works and thanks for your feedback, yeah that that's the reason like it's yes EVM is good, like EVM's good, there's a smart contract um but The layer two is going down movement left recently the news is they claim

Chapter 11 to be bankrupt. So the layer two is going down and then that's where I see cross-chain interoperability will be good to support heterogeneous networks like any blockchain network. Um, but yeah, I do see that other features like KYC and others are also good features to support as well, but yeah. That's true actually, um, we have another research question, which is,

okay, now...We move computation off-chain and put the computation onto rollups, so assets and everything move to the rollup. Work and call it. We managed to integrate our paper on Sybil because that’s some, and not some, and there were some challenges there, but the paper is hopefully submitted to blockchain, and let's see what happens with that paper. But that's actually, yeah, the correct. Okay. I think Mark

also has a question. Um, thanks. I, I was curious about, um, where the scalability limits are in terms of numbers, but also where the bottlenecks are, um, in like normal finance, where there are batches often, um, uh, often used for various reasons, but they are often used, they perform settlement netting, often in settlement batches. Um, but those settlement batches tend to be, like, hundreds of thousands, perhaps, of transactions. So, in, in a batch. So, where, I'm just curious where your kind of limits are, where, where the numbers would hit, and where would the bottleneck be in the system?

My bottleneck in my system is my server capacity to increase the number of sizes; actually, I could just increase the server I use until then, but as far as you have the capacity and strong network and configuration. Factor is the number of aggregators because it increases a huge amount of computation, and it increases the overhead on validators, and as said, you don't need that many validators for your system,

your design choice to have, you know, validators, but in the real world, we can't have that, so the bottleneck in the system is the number of validators, and companies and organizations decide based on their need; if security needs high security, they should go for, you know, a larger committee, but to be honest, in the real world, the user does not need that high level of security and guarantees by the validator; that's why, like, the ledger , they fix the committee maybe 7 to 30 nodes, which is the, and here if everything works, I think this system works perfectly in the real world, but the bottleneck in the system is the committee size, not the batch size, because if we manage, if we manage also to, because it's easy to manage the...

Batch size based on the network request if we have a high amount of load of transactions. Requiring. Time for. And we don't want that, need to reduce the size on the network load. I was just thinking in wholesale finance, lots of transactions, but often also few validators, potentially, so maybe that sort of context is, um, your work.

Thanks. You're welcome. Yeah. So, are there any other questions before I ask one or two? So, my first question is, there are a lot of proofs going around here, but are they all necessary? You know, it's great to do ZK proofs, but sometimes in systems I've worked on, we've found we could just use a contract and verify signatures, and the total cost would actually be cheaper than verifying a ZK proof. So, um, but in this system, what would you say—

are there any ZK proofs that are, I mean...That's a really good and tricky question, because in the real world, we honestly don't need that level of privacy, okay? Because zero-knowledge adds heavy computation, but as I said, we have a specific use case where we target organizations for business systems. Yes, it's worth it because the company doesn't want their competitors to know their patterns or other stuff.

So they accept this high computation to reach and gain that privacy. We can put it in a blockchain concept; if we need high privacy, then yes, and I think these days...Zero-knowledge proofs have tons of......you know, use cases, but it is true that for most use cases, we don't actually need this...... zero-knowledge; we can just verify the signature and satisfy that. Okay. Yeah, it's based on the use case. All right.

Well, that's good. And thank you. And the other one is more of an implementer's question. What did you use for your ZK circuits? What, um, framework or language did you...I used Circom. Ok. You mean the tooling? Yes, I use Circom for that. Ok. All right, good to know. All right, are there any other final questions before we leave for today? All right, I think you're all done. So, thank you very much for a wonderful talk. Um, that was great, and good luck, um, finishing your PhD and becoming a doctor. Um, yeah, thanks for your wishes, and thanks for joining and

inviting us to this incredible talk. I really enjoyed it. All right. Well, thank you. All right. Have a great day, everyone, and talk to you all later. Bye-bye. And thanks for having us. Goodbye, everyone.