Privacy Scales Better

Hi, I'm Dominic, and I hope we also become to be cyberpunk. We have a different, a little bit of a different approach, but yeah, I'm here to talk about how we approach privacy in Maiden. And I want to say that 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, at least like in terms of blockchain. So if you don't tell the blockchain what you're doing, then the blockchain doesn't need to be executed, the blockchain doesn't need to store the state, because the blockchain doesn't know the state, and then if you could build a blockchain that is private in the sense that execution and 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 thousands of users transact at the same time, so maybe even millions, and we want that Alice doesn't see, and this is only possible since zero-knowledge proofs become so far, maybe since two years or so, the transaction at the edge, and store the state at the edge, and then we can build a blockchain around that. So, but like, ZK doesn't give you the whole concept, basically, so we needed to rethink the state model of a blockchain and apply the actor model, and that allows us to transact at the edge, and for privacy, we can use client-side zero-knowledge proofs that allow us that the data, basically, never leaves the user's device. Just a refresher, the actor model, you can think about actors, a little state machine with inboxes, 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 asynchronously, or just happens asynchronously, and therefore, it can happen in parallel. This is like a model, how it could look like, so if you can build a blockchain around this model, and these actors, like message, like creation of a message, and the consumption of a message would be proven by a zero-knowledge proof, then you get scalability and privacy for free. And so, we apply the actor model on MIDIN in the sense that we have accounts, and accounts are working the same way 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 carry assets, and they have certain spend scripts, or spend conditions, and you need two transactions to transfer an asset from one account to another.

So, in a first transaction, account one would create a node, and in the second transaction, account two would consume this node. 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, we can prove that independently from the other actors, and therefore, we need two transactions to transfer an asset, but our accounts can change their state in parallel. And all accounts are smart contracts with code and storage, and we can store any asset in the account, and the same for nodes, like nodes have, like, they are little smart contracts, so to speak, but we're, so they also have code, and when you need, you need to execute this code, and create zero-knowledge proof about it, and can carry multiple assets. And this is how we, like, basically, our protocol works, 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 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 Miden, it's always only one account, and that's why you need more transactions to transfer an asset, but you get 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 I can talk more about privacy, but the thing is, every transaction, so every state transition of a single account, always gets CK proven, like with the Miden VM, it's like a stock-based machine, but we can basically prove the transaction of every account, and with this, like the data stays on your computer, so all the network knows about this transaction, in the normal case, it's just that a commitment to this account changes on-chain, and these stock proofs can be generated in parallel, so what we have basically is the more private the network is being used, the better it scales, because like we also have network transactions, or like we have smart contracts, public share state, but there you need to 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 re-executing, like a 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 Cash is more expensive than a standard Ethereum transaction, or like when we add MPC in the end, or when we run some Ethereum transactions in the TEE, or whatever, so when we want to add privacy to a transparent chain, it's always way more expensive, whereas on Miden, it would be the cheaper option, and yeah like, so what do we know, so Miden looks a lot, was inspired heavily by Zcash, basically we also have these three databases, or like, it doesn't have three databases, but we have three databases like with an AccountDB, NodeDB, and this Nullifier database, and this is how we achieve privacy on Miden, and this concept is for Zcash, it's with this Nullifier, but like the accounts can be stored publicly, so with a full code on chain, or privately, and then all the network knows is basically this hash, so the account with the orange circle here, it's just like a commitment to the state of the account, so every account on Miden you can think of is its own Validium, or like no one knows what's behind this commitment, but you on your local machine know what's behind it, but you can also store your account, when you want to build a debt, for example, 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 will be known by the network, and there's no more data, so even in the future it cannot be decrypted, it's just a commitment to this private node, and if I want you to consume this private node, then I can send you the private node data via signal, or we create a private transport layer 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 more on that later, and yeah, like to create this, we have like an append-only accumulator, where I can always add nodes, this is, we need that for parallel transaction execution, or such that I can have this node DB basically, also like a slightly older version, and it would still be true for my knowledge proof, and I have this nullifier database that basically keeps track of which nodes were already consumed to prevent double spends, and this, I don't know, like if you're familiar with Zcash, it's also in Zcash, or Aleo, or Aztec, they also have this kind of nullifier data structure. And so now, the topic of this, basically, we will gradually level up privacy, and I would be interested in your opinions on that, we discussed it quite a lot, there are other systems, they go for privacy from day one, basically, but we see privacy as a spectrum, and 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 even Bitcoin, 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 have access to that, but like Bob would not what Alice is doing if Bob is not in this PayPal realm, and level two privacy would be strong privacy, which would be what we wish for, that only the transaction participants see everything, that would be true for cash, right, so if I give you 100 euros in cash, then we would know about it, but no one else, and this would be something we want to achieve, and level three privacy is 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 in theory, we can build this with client-side proofs as well, but just a reminder, how does it work on Zcash, or in that case, on Lydon, with this node hashes nullifies, so how can I ensure that if you consume a node, that we cannot somehow detect it, and say, okay, you consumed that node, so it's not private anymore, basically, what we, like we have these two transactions that we need for a transfer of assets, so in a first transaction, account one would create a node that contains 100 ether, and then there is a node hash, basically a commitment to this node that we add to this node database, and in a second transaction, account two would consume this node, and it would record a nullifier, or like it would create a nullifier, compute that, and push the nullifier to the nullifier database, and the nullifier and the node hash, they are not linkable, meaning that if you don't have the full node data, you cannot compute both, because it's just like a hash of a different subset of the data, and so only when you have the full node data, you can compute a nullifier, and that's, therefore, like you don't see that a certain node is consumed, so you only see that nodes will be added to the node database, but not which nodes are consumed. At least on the protocol, this is privacy preserving, as you've heard in other talks, obviously, like when you have like a small set of sequences 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 protocol level so far. So now our problem was, okay, so in theory, with this protocol, we can achieve any level of privacy, but what do we want to provide in the beginning, and we decided to go for level one, web2 privacy, basically, that the transaction action participants see everything, and like our centralized sequencer with which we start would also see everything, at least for the first two years, and I know this is not very cyberpunk, but what do I mean by that is like this, this is how a private node looks like in mine today, so you don't really know what's inside, you just know that there is a private node with this node ID or the node hash, but you don't know which assets are there or to whom it is directed, and we don't know the nullifier, we don't know if the node is consumed or not, and at the moment, we track the sender for debugging purposes, but this is actually protocol-wise, you don't need to sender, but why do we do that, so why are we going for what we call pragmatic privacy, basically for two reasons, so one major issue that we have is debugging, and I don't know how other systems do it, because I know that ASIC, for example, is launching like fully private in a decentralized mode, but our problem is that like in these zero-knowledge virtual machines, this is super experimental software, like what happens if there's a soundless bug, and I'm pretty sure like in all ZKVMs, like there are 25 out there at the moment, there for sure will always be a soundless bug, I think we found a couple of them in Maiden, when I was in Polygon, also in the ZKVM zero-knowledge virtual machine, there were a lot of bugs, and the problem with a fully private network and a soundless bug is like if someone finds that bug, they can print infinite money, and you will never know about it, and you wouldn't even realize it, like it's just like there's one person getting richer and richer, and then they would leave the network, but you could not even identify it as a bug, and so at least for debugging purposes, at the moment we have this kind of centralized entity that gets all the transaction data, and can in theory rerun them, which helps us for debugging, and in the future we want to obviously also become decentralized and get rid of that, but this was one reason why we start with this pragmatic privacy, and the other reason is indeed regulation, so when we decided that it was like another administration in the US, there was like this EU regulation, like Amin was talking also about it today, that the EU tries to prohibit or prevent privacy coins from 2027 on, so actually it's like, I don't know if this will happen, or if we can do it even without EU, but the problem is like it's a super uncertain regulatory environment at the moment, and like in theory we can make it a switch and become fully private, but at least in the beginning, yeah, we were unsure if we can sustain the project, if we would start as a fully private project, and so we decided to have this pragmatic privacy.

And yeah, so at the beginning, like this will be our approach, we offer this web tool like privacy, but the system can do way more, and I'm personally like a huge fan of privacy, or like this is also what drives us, so I hope in two years we can become real private, but I would be happy to hear opinions on that, or if you would do it a different way. Thank you. We're running out of time, maybe just one question, because it would be nice to share an opinion. Okay, I will ask, if you're unsure right now what kind of regulations will be, how you approach even the state of regulations in two years, in three years, you will be always kind of like play safe sort of, like what's the internal thinking process behind it? Yeah, that's a good question.

Actually, we don't know, like, or we were approaching this, like in the beginning it was a research project, it was a super fast zero-knowledge machine, and he built a blockchain around that. We are, like, we even were in contact with, from the EU Commission, or the Brazilian Central Bank or so, and they were interested in this, 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 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. But yeah, we tried to talk to people, obviously, also, like, in Polygon was a very good compliance team, so to speak, but it's also hard, like, we are not big enough to hire lawyers that would work on all the jurisdictions, and so, yeah, we are not sure yet, actually, what to do, but yeah.