DAPPCON 2025: Privacy Scales Better - Dominik Schmid

Transcript

Thank you very much. Hi, I'm uh Dominic and um I hope we also become to be cyber punk. But let's see, we have a different a little bit of a different approach. Um but um yeah, I'm here to talk uh about how we approach privacy in Miden. And um I want to say that um our initial idea was that privacy even though it's an end goal for us, it's also a means for scalability.

And this from a high level makes sense um at least like in the terms of blockchain. So if you don't tell the blockchain uh what you're doing, then the blockchain doesn't need to re-execute it. The blockchain doesn't need to store the state because blockchain doesn't know the state. And then if you could build a blockchain that is private in the sense that execution and um the state stays at the edge with the user then the blockchain is much leaner and way faster and in that sense scales way better. But like what do we want actually is that thousand of users transact at the same time some maybe mill and we want that Alice doesn't see

and this is only possible since zero knowledge proofs become so fast maybe since two years or so the transaction um at the edge and store the state at the edge and then um we can build a blockchain around that. So um but like ZK doesn't uh give you the whole concept basically. So we needed to rethink the state model of a blockchain and apply the actor model. Um and that allows us to transact at the edge and for privacy uh we can use uh client size zero knowledge proofs that allow us that the data basically never

leaves the user's device. Uh just a refresher, the actor model. You can think about actors are little state machines within boxes. So you have a network or a database with a lot of these actors and they communicate via message passing. So they send messages to each other, trigger state changes and this can happen uh asynchronously or this happens as synchronously and therefore it can happen in parallel. This is like a model how it could look like. Um so if you can build a blockchain around this model and these actors like message uh like creation of a message and the consumption of a message would be um proven by a zero knowledge proof then you get scalability

and privacy for free and so we apply the actor model on miden in a sense that we have accounts and accounts are working the same way as as on Ethereum. So they maintain state and they expose methods or they have certain code. Every account is a smart contract and they create nodes and these nodes can uh carry assets and they have certain spend scripts or spend conditions and um in you need two transactions to transfer an asset from one account to another. So in a first transaction uh account one would create a node and in the second transaction account two would consume this note. And this is because we define a transaction

as the state transition of a single account. And here again if you rethink the actor model. So you have these little actors they receive messages change their state and send messages out. And like this is a transaction for us. So when one actor changes its state um we can prove that independently from the other actors and um therefore we need two transactions to transfer an asset but our accounts can uh change their state in parallel and um all accounts are smart contracts with code and storage and we can store any asset in the account and um the same for for nodes like nodes have like they are little smart contracts so to speak,

but were objects. So they also have code and when you need to note you need to execute uh this code and create zero knowledge proof about it and um can multiple assets and this is how we like basically our protocol works um when you understand what a transaction is I always say that like you have 80% of the protocol a transaction is just the state transition of a single account so basically It's some kind of program that gets a stateful object like account one in and results into um the account one in a new state and it can consume up to 1,000

nodes and produce up to 1,000 nodes. And this is how we define a transaction. And this is different to let's say on Ethereum where you can have a transaction where Alice sends something to Bob, right? And you need to change Alice's account and Bob's account at the same time. on Maiden it's always only one account and that's why you need more transactions to transfer an asset but you get um parallel execution and if you do it client side you get privacy for free because all the network knows is just that a commitment to a certain account state changes and this is actually the topic of my talk but I explain the protocol quite

quickly and then uh I can talk more about privacy but the thing is every transaction so every state transition of a single account uh always gets CK proven like with the miden VM it's like a stark based virtual machine but uh we can basically prove the transaction of every account and with this um like the data stays on your computer so the all the network knows about this transaction in the normal case is just that a commitment to this account changes onchain And these dark proofs can be uh uh generated in parallel. So what we have basically is um the more private the

network is being used the better it scales because like we also have network transactions or if like we have uh smart contracts public shared state but there you need to uh change that again sequentially. However, if you just do a normal transaction or like a private smart contract, then all the network needs to change is this commitment to a state. And this can be done way faster and way leaner. So, in our system, and this is like a paradigm shift to what we have on Ethereum or on other blockchains, like when you add privacy or you use Miden in a private way, it just like is cheaper

and faster. And like when you compare it to Ethereum for example, when you want to add privacy to a transparent chain, a transparent chain, I mean a chain that works by reexe like transparent chain verifies transactions by re-executing them. So you need to add privacy on top and need to encrypt something on top or you need to somehow hide information. But this is always way more complex and way more expensive. That's why like tornado cache is more expensive than a standard Ethereum transaction or like when we add uh MPC in the end or uh when we run some Ethereum transactions in a TE or whatever. So when we want to add

privacy to a transparent chain it's always way more expensive whereas on Maiden it would be the cheaper option and um yeah like so what do we know? Also miden looks a lot was inspired heavily by uh Zcash. Basically we also have these three uh databases or like C doesn't have three databases but we have three databases like with an account DB node DB and this nullifier database and this is uh how we achieve privacy um on Maiden and this concept is uh uh from Dcash is with this nullifier but like uh the accounts can be stored publicly so with the full code on chain or privately and then all the network knows is

basically this hash. So um the account with the orange circle here uh is just like a commitment to the state of the account. So every account on mine you can think of is its own validium or like no one knows what's behind this uh commitment but you on your local machine know uh what's behind it. But you can also store your account when you want to build dex for example uh you can also have public shared state and the same is true for nodes. So you can build a public node then the full node data would be on chain but you can also have the node private and then the commitment only the commitment to this node would be known by the network and there's no more data

so even in the future it cannot be uh uh uh decrypted um it's just a commitment to this uh private node and if I want you to consume this private node then then I can send you the private node data via signal or we create a private transport U via WebRTC and then you can consume it. But only you and me, we would know about it. In theory, we could even create a system with this that not even the receiver knows who the sender is. But um more on that later. And um yeah, like to create this we have like an appendon accumulator where I can always add nodes. This is we need that for um parallel transaction execution or such that I can um um have this uh node

DB basically also like a slightly older version and it would still be true uh for my zero knowledge proof and I have this nullifier database um that basically keeps track of which nodes were already consumed to prevent double spend um and this I don't know like if you're familiar with Zcash is also in Zcash or Alo or Aztec, they also have this kind of nullifier um data structure. And so now uh the topic of this uh basically um we will gradually uh level up privacy and I would be interested in uh your opinions on that. We discussed it quite a lot. There are other systems they go for privacy from day one

basically and uh but we see privacy as a spectrum and um so level zero would be that everyone sees everything so we would basically have no privacy when you look at I don't know Ethereum today or or even Bitcoin uh level one privacy would be when I use PayPal today so the transaction participants know about it and the people who work at PayPal or maybe people who access to that. Um, but like Bob would not see what Alice is doing if Bob is not in this uh paper realm. A level two privacy would be strong privacy, which would be what we wish for that only the transaction participants see everything. Um, that

would be true for cash, right? So if I give you €100 in cash, then we would know about it, but um, no one else. And this be um, something we want to achieve. And level three privacy is um that everyone only sees their data. I would send you money and you don't know that it comes from me. I don't know if there's a use case for that, but that would be the end of the spectrum. And uh in theory, we can build this with client side proofs as well. But um just a reminder, how does it work on Zcash or in that case on Maiden with this note hashes nullifiers. So how can I ensure that if you consume a node that uh we cannot somehow uh detect it and say okay

you consumed that node uh so it's not private anymore. Basically um what we like we have these two transactions uh that we need um for an transfer of assets. So in a first transaction, account one would create a node that contains 100 ether and then there is a note hash basically a commitment to this node that we add to this uh node database and um in a second transaction account 2 would uh consume this node and it would uh record a nullifier or like it would create a nullifier compute that and uh push the nullifier to the nullifier database and the nullifier and the node hash they are not um linkable

meaning that if you don't have the full node data you cannot compute both uh because it's just like a diff a hash of a different subset of the data and so only when you have the full node data you can compute the nullifier and um that's therefore like you don't see um um that a certain node is consumed. So um you only see that nodes will be added to the nodes database but not which nodes are um consumed at least on the protocol it this is privacy preserving as we've heard in other talks obviously like when you have like a small set of sequencers or so they could track the IP and there could be some links with time

and like this can be solved but not on the uh on the protocol level so far. So now our problem was um okay so in theory with this protocol we can um uh achieve a handy level of privacy but what do we want to um provide in the beginning and we decided to go for uh level one web two privacy um basically that the transaction participants um see everything and like our centralized sequencer with which we start would also see everything at least for the first uh two years and I know this is not very cyber a punk. But um what do I mean by that is like this this is how a private node uh looks like in mine today. So you don't really know what's inside. You you

just know that there is a private node with this note ID or the note hash but you don't know which assets are there or um to whom it is directed and um we don't know the nullifier. We don't know if the note is consumed or not. And um at the moment we track the sender for debugging purposes. But this is actually protocol wise you don't need to know um the sender. Um but um why do we do that? So why are we going for what we call pragmatic privacy? Uh basically for two reasons. So um one major issue issue that we have is uh debugging and I don't know how other systems do it because I

know that Aztec for example is launching like fully private in a decentralized mode but um our problem is that like in these zero knowledge virtual machines this is super experimental software um like what happens if there's a soundness bug and I'm pretty sure like in all ZKVMs like there are 25 out there at the moment there for true will always be a soundness bug. Uh at least we found a couple of them uh in Miden when I was in Polygon also in the ZKVM uh uh uh zero notch machine. There were a lot of bugs.

The problem with a fully private network and a soundness bug is like if someone finds that bug, they can print infinite money and you will never know about it. Like you wouldn't even realize it. like it's it's just like there's one person getting richer and richer and then they would leave the network, but you would you could not even identify it as a buck. And so um at least for debugging purposes in at the moment we have this kind of centralized entity that um gets all the transaction data and can in theory uh rerun them um to um yeah which helps us for debugging and in the future we want to uh obviously also become decentralized and get rid of that. But

um this was one reason uh why we start with this pragmatic privacy and the other reason is uh indeed regulation. So when we decided that it was like another administration in the US um there was like there's this uh EU regulation like Amin was talking also about uh it today that uh the EU uh tries to prohibit or uh prevent privacy coins from 2027 on. Um so actually it's like a I don't know if this will happen or um if we can do it even without EU but the problem is like um it's a super uncertain regulatory environment at the moment and like in theory we can uh make it a

switch and become fully private but at least in the beginning um yeah we were unsure if we can sustain as a project if you would start as a fully uh private project and so uh we decided to have this um pragmatic privacy and um oh yeah so uh at the beginning like this will be our approach we offer this web tool like privacy uh but the system can do way more and I'm personally like a huge fan of privacy so uh or like this is also what drives us so I hope in two years uh we can become um um real private but I'm yeah would be happy to hear your opinions on that uh or if you would do it a different way.

Thank you. Uh we're running out of time. Maybe just one question because it would be nice to share an opinion. Um okay I will ask um if you're unsure right now what kind of regulations will be uh how you approach even the state of regulations in two years and three years you will be always kind of like place safe sort of like what's the internal thinking process behind it. Yeah. Um that's a good question. Uh actually we don't know like uh or we were approaching this um like in the beginning it was a

research project. it was a super fast zero knowledge virtual machine and then we built a blockchain around that. Uh we are like we even were in contact with uh from the EU Commission or uh the Brazilian central bank or so and they were interested in this uh but we also like in contact with people who want to use it fully private and at the moment we are trying to find out uh what we want is we want to keep working on it like and we have 25 30 people now in the team and so at the moment this pragmatic way was the safest for us. Um but yeah, we tried to talk to uh people obviously also like in Polygon it was a very good compliance team so to speak. Um but it's also hard like we are not big enough to

hire lawyers that would work on all the jurisdictions and so um yeah we are not sure yet actually what to do but