ZK-Powered Payment Channels | Pranav Gaddamadugu - Provable, Aleo

[Music] hi everyone my name is pav um I'm an engineer at a company called provable we are a Labs Co that is really into ZK Tech so um today I'm pretty excited to talk about uh ZK power payment channels but only sort of see what happened was when I sat down to write this talk I realized that there were so many core conceptual pieces to go over that instead we're going to take the long way and talk a little bit more generally about private payments using ZK and uh finally touching on these interesting ideas like payment channels stable coins compliance at the very end so as a little bit of an overview uh we're going to take some time to set the stage then we'll actually dive into private payments how the model looks like abstractly then we're going to expand on that a little bit talk about the uh hybrid ZK VM that we've designed at uh provable and then in actually instantiated in Alo and then finally talk about the cool use cases at the very end so with that uh let's just jump into it so first first I wanted to just set into a frame of mind uh What uh the anatomy of a payment looks like now for most of us whenever we make a transfer a payment using crypto uh we're looking at uh some ux that looks like this now under the hood this is implemented very differently across different chains but abstractly we'll reason about a model that looks like this here we have offchain a user Alice and onchain alleged which for a token program contains some State here Alice has eight credits eight tokens and Bob has two and what Alice is going to want to do is send Bob three credits over um via the network now the way this looks like um in ethereum uh in Bitcoin kind of abstractly here is that Alice will first generate a transaction that transaction will specify the person she wants to send to the amount and a signature and Alice is going to fire that over to the network the network is basically going to take a look at this transaction process it verify that it's well formed verify that the signature is correct and then update the state and you know at a high level this is like how payments work like uh transfers work like in the account model but if you squint your eyes a little bit you'll also see that this is is how they work in uh the utxo model there is a public Ledger it contains some public balances and you know that tracks how much everybody has there's a fundamental problem here though and the issue is that all transactions are public this means that the actual ux that we expect in payments in transfers in money isn't actually represented in these sorts of constructions when we send money we expect that only the two parties who are interacting actually you know get to see the details of the payment and this is just a fundamental problem that kind of blocks a lot of crypto use cases you know if you're a whale you're very um cautious about moving your money around uh to you know prevent people from tracking your um expenditures so on if you're you know any user right you're basically under the assumption that you can be tracked so in this talk we're going to work out how we can use a different model to effectively support private payments and get the kind of ux that we want now before we get there we're going to have to talk about zkps but I'm going to keep this super super high level and oversimplified uh there won't be NE there isn't a huge need for technical zkp materials but there's a bunch of like really good resources online for this stuff so for the purpose of purposes of this talk when I refer to zer knowledge proofs I'm going to refer to ZK snarks specifically and what that means are zero knowledge succinct non-interactive arguments of knowledge now if we were to dive into ZK there's a lot to unpack here but for today all we're going to care about is the zero knowledge component basically that the private inputs to the proofs are not revealed to um anyone who has the proof itself another way to think about this is that uh with the zero knowledge proof I can create a proof Pi that proves that I know some value X which is private such that some result Y is equal to F ofx and in this case Y and F are public now that we've kind of run through this overview and kind of set the stage for payments and zkps let's take a look at what a private payment actually looks like in first from first principles basically we have in this model A different kind of instantiation of State before you had this Ledger which tracked for every account every user's balance instead in this model we're going to track these objects called records and records are individual data blobs you can think of them as encrypted envelopes each with a public ID which is enforced to be unique and some encrypted data which is encrypted to the owner in the record you know if you're coming from like the Bitcoin space or familiar with like the utxo model this effectively looks like encrypted utxos so in this setting here Alice has a record that she owns that is on chain but the balance and the fact that she owns it is encrypted so only she knows her balance here and same with Bob Bob has a balance he knows that he has five tokens but no one else knows this information now if Alice wants to send uh let's say two tokens to Bob she's going to form a transaction and and now there's a lot of parts here and we'll go through them one by one the component in the red is the records that Alice is going to use as inputs so she's going to reference records that exist already on chain and say that she's going to be spending these things and then producing the blue records that you see out there so in each of the blue records you'll see that there are two new records created one called three and one called four and one basically debiting Alice the amount that she has remaining and one giving the amount to Bob additionally there are also two proofs attached to the transaction and these proofs basically will assert using Zer knowledge proofs that the transaction is well for formed so that the encrypted data was created correctly and that Alice actually owns uh record id1 and that the balance is conserved so Alex didn't mint money Alice didn't mint money out of thin air and with this she'll fire it over to the network and the network will verify these zero knowledge proofs as well as check that the transactions well formed for example that the record one actually exists on chain and then up The Ledger and the way the network updates The Ledger is basically the network will invalidate the record that Alice wanted to spend and then uh append the two new records that Alice has created now you can follow along this model to basically work through it and see how Bob might you know um condense his state so if Bob you know right now has two records two and four each with uh five and two credits respectively Bob can basically fire off a new transaction that takes two and four his input and produces a new record five which asserts that you know just basically combines the two records and fires it off to the network and subsequently gets updated so at the end of it you know Alice has transferred two credits over to Bob and Bob has aggregated his private balance and in this whole process nobody else knows that actual balances of Bob and Alice or even knows off of looking at a transaction that it was actually Bob and Alice that sent money to each other now we kind of spent all this time talking about how we can move away from this account-based Ledger model uh similar like stuff that we see in ethereum the evm so on but there are actually some good things about it you know when transfers are public it means that they are you know easily auditable it's also very easy to manage this state and actually Implement these kind of designs versus these record-based utxo models have ux issues as well as you know you just got to do a lot more heavy lifting to implement something like this but there are desirable properties in both so at uh in Alo uh zk1 that we've uh contributed to help build up we've just kind of combined the two we have in the uh VM in the Network a public Ledger that tracks public balances as well as a private Ledger that tracks your private balances now what this means is you know if we have this kind of like traditional world where you know you have public uh on-ramps a centralized exchange a bridge and just public transactions where Alice and Bob can send money back and forth move them on and off and so on you now get this private dual world where Alice and Bob can also move into the private domain and transact between them what's kind of unexplored here which is kind of pretty exciting is what are the uh private on on and off ramps look like how do you construct private dexes how do you construct private Bridges and this is this is a bit of an open question but uh a very exciting space to kind of look at now I kind of fudged things when I said uh Alo just combines the you know public constru struction the account model and the private construction the encrypted utxo model we actually have also instantiated uh a custom designed VM where developers can upload their own programs and you know more generally write code that works with private logic as well as public logic and instead of just looking at payments as one you know as the core problem this virtual machine here kind of treats payments as as a use case as a specific program on the network and with that you can start to explore more production grade stuff so uh kind of the sort of the pseudo topic of this uh talk uh payment channels so payment channels are kind of an interesting idea uh basically one approach to scaling the speed of crypto payments uh you know alternate approaches are like actually building a full purpose L2 um this this is another approach that kind of got some popularity in the early days in the Bitcoin Community the way it works is basically at a high level you have two parties who want to transact pay uh you know send money back and forth to each other uh Alice and Bob and what they're going to do is they'll go through a couple steps where where they will open up a payment Channel via an open and an acknowledgement and then send as many transfers back and forth with each other and then finally close the whole thing the way this works in the traditional sense is that opening and closing is onchain and in Bitcoin and and any kind of like evm style or account-based construction uh this part is public but because we've designed this thing with records in private State privacy actually almost comes for free you can just copy the existing constructions out there and you have private State channels where settlement is actually truly private and then because we designed this virtual machine where you can kind of arbitrarily Define other functions other logic you can use that to add in more Rich uh spend conditions to your payment channels so it's not only just balances going back and forth you can add extra conditions that you know do something more interesting uh maybe require some uh identity verification maybe require some minimum balance something like that another another dimension to actually you know implementing these things in production or actually creating a product out of them is compliance so we spent all this time creating a private way to transfer money but um there's a problem in doing that and that's um you're basically fundamentally doing something illegal uh with private money it means that you know people can kind of launder money quite easily if you don't have guard rails in place so with this uh we're also thinking a lot about you know with privacy how do we design compliance and what's really interesting is that zero knowledge proofs while giving privacy also give a very natural mechanism for um adding in compliance that's also private now at a very base level um if you're like looking at compliance for private transfers the basic thing that you need to do is make sure that a party interacting doesn't come from a set of blacklisted addresses and this kind of fundamental idea is known as or this this thing bakes down to something known as set exclusion and we know how to do this with Merkel proofs uh it's fairly straightforward and it's also fairly straightforward to instantiate these in zero knowledge proofs themselves but other than set inclus exclusion you can do a lot more interesting things basically again we're just going to use zero knowledge proofs to kind of prove arbitrary properties about the users who are initiating or receiving payments so some interesting things you can do is use a Zer knowledge proof to um provide some identity verification uh you can use a zkp to uh check that you have your transactions are under some limits or that another set of assets have you know a certain amount of exposure before firing off a transaction you can uh require credit checks you can require uh checks on user history all through z APS you can enforce sanctions you can uh add requirements that users come from specific locations and you could even uh do uh Providence for funds before they're actually sent through here things do get more creative there do need to be parties that provide you know this sort of like raw data in the case of identity but it's really kind of an open space for application developers to really add in whatever compliance measures that they want so it's kind of like based on each use case anyone can really design whatever piece that they need here so at provable we've basically been exploring ZK tech building this stuff out and its main instantiation is in alo alo is a zk1 that um kind of implements this zero knowledge virtual machine uh with all these principles baked in so developers can immediately go on on it use a language called Leo to develop their daps and immediately have this ability to write hybrid applications that interact with public and private State and yeah that's that's all I have today um this is a general high level idea and you know if anyone has any questions I'd love to you know dive into it a little bit more I think uh we'll get a mic over there yeah I mean can you make a quick comparison of the AL like the pro provable Alo like the payments you just talked about with like things like Z cash or something like that yeah yeah um it's a it's a really great question right so just to repeat the question how do we compare payments on Alo to something like zcash and the interesting observation is that the Baseline ideas of zcash where you have these uh kind of like uh public and then shielded domain is instantiated as instead of a core protocol level implementation as it is in zcash in Alo this is a programmable piece so to actually do this in Alo you write a program that you upload to the VM and you get these kind of privacy elements in there so whereas in zcash it needed to be a native asset here developers can build their own programs add their own comp compliance mechanisms for specifically their own use cases and upload it on chain and you know run them great thanks for listening everybody