Anna (00:00:05): Welcome to Zero Knowledge. I'm your host Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. I chat with John Light and Samuel JJ Gosling. We talk about DAOs, privacy at different levels of a DAO, MACI and how new zk and privacy tools can be used within a DAO context. This episode was born out of a recent zkSessions event we did, where we covered this topic. Still, it's an underdeveloped space and something I think would be very cool for teams and communities, maybe even the zk community, to be exploring. Anna (00:00:52): But before we start in, I want to let you know about the upcoming ZK Jobs Fair. It's happening on July 29th. And we will be hosting some of the top zk projects, who are looking to build their teams and hire. Most jobs will be technical, software engineering and cryptography focused. So if you are looking to work in blockchain and the zk space, this will be a great way to meet some of the teams and get to know them, as you apply. We host this on gather.town, an awesome video game style, interactive online space. I've added the link to apply in the show notes. I hope to see you there. You can also always check out the Zk Jobs Board on our website, where we have an amazing list of open positions at any given time. Anna (00:01:30): I now want to thank the sponsor of this episode, Mina. Quick disclosure, I'm an advisor to this project and the ZKValidator runs a block producer on the network. This is a project that I've been following for many years, and we've actually covered on the show before when they were working under the name Coda. Now, Mina is the world's lightest blockchain, powered by participants. Mina is a layer one protocol creating a private gateway between the real-world and crypto. The entire chain is about 22 KB, even as it scales, thanks to zk-SNARKs. The layer one protocol replaces the traditional blockchain with a zero knowledge proof, ensuring a super light and constant sized chain that allows participants to quickly sync and verify the network. And SNARK-powered dApps called Snapps, allow access to verified real-world data from any website for on-chain use. The ecosystem is growing fast and Mina's mainnet is live. If you want to jump in, visit minaprotocol.com to find out more. So thank you again, Mina. Now here is our episode about privacy and DAOs. Anna (00:02:34): So for this episode, what I want to explore with this week's episode, is the topic of DAOs and privacy. And this topic came up in an earlier zkSessions event that I hosted, where we actually were looking at privacy in NFTs and privacy in DAOs. And I felt like the conversation around privacy in DAOs was really rich. And so I wanted to put together an episode, which allowed us to dig deeper into this. I have two guests this week, who I think are going to be great to help explore this intersection. So I want to first welcome John Light, who was previously head of governance at Aragon, and is now working on community governance for Sovrin. Hi, John, welcome to the show! John (00:03:15): Anna, thanks for having me. Anna (00:03:18): And the second guest is Samuel JJ Gosling, a Tornado Cash contributor, and recent addition to the MACI dev team. Welcome, Samuel. Samuel (00:03:27): Thanks for having me, Anna. Good to be here with you, John. Anna (00:03:30): I think we should probably learn a little bit about both of you before we dig into this intersection topic, the topic of privacy in DAOs. So John, you worked at Aragon and actually you and I worked together a little bit earlier this year on some zk events. So why don't we dig in a little bit to your journey into the space of governance and DAOs John (00:03:50): Yeah, sure. So governance has been something of just a personal interest of mine, pretty much for as long as I've been interested in politics, really. I've never really got involved in party politics, but I was always interested in governance and the deeper, underlying issues of a lot of the political problems. And so I started looking into governance, research economics to see how these subjects interplay to create the political dynamics that I was seeing, where I live, in the United States, and researching to see are there any good alternatives to the governance systems that I saw as being deeply dysfunctional. DAOs in particular were one of the interesting use cases that I saw for more expressive smart contract systems, such as those enabled by Ethereum. And so in 2017, somebody that I knew was working at Aragon, doing legal research for them. And she had mentioned to me that they were hiring for somebody to work on community governance. And I was excited to see that this technology that I've been interested in for a while, DAOs, there's a team who's actually making a good solid effort to make DAOs happen in a way that is secure and easy to use. And it's like the dream that we had in the early days of the Ethereum project of you having a point and click, just spin up a DAO, and it just works. And Aragon was, I think, the first out the gate to really make that happen for people. Anna (00:05:54): Where you dogfooding it? It was the tool of Aragon, but there's also you yourself were running DAO, you were running these votes, I guess, and trying to use them. John (00:06:06): Exactly. So actually using the tools that we were building to do community governance for Aragon, and these experiments started very simple, the very first experiment we ever did was just polling. So there was really, you call it no binding effects of this vote in any way. It was really just sentiment gathering or polling on the blockchain. And then the next step was to actually commit to doing what it was that the community was voting for. Anna (00:06:44): Like the on-chain governance idea, where you're committing to something and then it automatically happens? John (00:06:50): Not exactly. So it's like on-chain voting with off-chain execution, where basically we set up this process, the Aragon governance proposal process, where community members could write up proposals within a few different categories that we set up and then those proposals would get put to a vote. And the proposals that passed, the Aragon Association, which was the nonprofit that was the steward of the, or really still is, the steward of the Aragon project, would commit some resources to fulfilling the proposals that were passed. And then the next stage that we were working up to was fully on-chain governance, where you'd have on-chain votes and on-chain execution. So actually putting funds and smart contracts and other aspects of the protocol under the direct control of the token holders. Anna (00:08:00): A point of contention in certain communities, whether or not on-chain governance to that level is good or bad. I know that there's very different philosophies in different groups about how much power should you give in a way, like the crowd over what the protocol actually does, without certain levels. That's cool. Did Aragon actually do that? Did it get to that point? John (00:08:26): I don't think it's gotten to that point yet. We were pretty close. And then most of the team left due to disagreements with the leadership at the Aragon Association.That's, I think the most succinct way that I could put that, but I think that is ostensibly still the ultimate goal. Anna (00:08:44): What are you working on now? John (00:08:47): So currently I am working on community governance for the Sovryn, which is a DeFi protocol on the RSK blockchain. I'm working on a few different projects over there, but one of the things I'm doing for them is I'm an editor of their governance proposals. So every time someone has a governance proposal, I will help them review it, format it, make sure that it's clear and make sure that it's internally consistent and just help shepherd these proposals through the governance process. I try to do my best to answer questions and keep token holders informed about what's going on and how to participate in the process as voters or if they have proposals of their own. And I'm working on a few internal development projects related to governance and the administration of the governance system. Anna (00:09:49): All right, Samuel, I want to hear a little bit about you, let's do a little background. This is the first time that we meet. So I'd love to hear where you started and how you got to be working with Tornado governance and MACI. Samuel (00:10:02): So it's a long story, but I'll shorten it down. It started in around 2017, where I got a fascination for cryptocurrencies, mostly to it being, let's say, an investment opportunity. That quickly evolved into a curiosity behind the technology, mostly with Ethereum. And I started, let's say, experimenting with some open source repositories on Github around... One was with the tipbot for Bitcoin, and I ported it for an altcoin. It started very small, but eventually evolved into smart contract development, front-end using React. And I was freelancing from the years of 2017 up to 2019, and then earlier last year I was part of the founding team of a small DeFi protocol called Indexed Finance. And after that, I was looking for my next, I suppose, passion. And I forgot about how privacy is one of these things that's very underappreciated or underscoped, not enough people care about it. I don't think yet. I thought deep in my brain, what is the one thing that has provided a fundamental, let's say, right to privacy on Ethereum? And of course it was Tornado Cash, the same guys I saw back in ETH Berlin back in 2018 surviving off grants. And they recently launched their governance token TORN. And so I made it my initiative to get involved and that was just contributing through the forums. And it was actually through there, where the Ethereum Foundation saw me, the zk applied branch of the Ethereum Foundation. Then that led me to the opportunity of working with MACI, with Wei Jie, which has been an incredible experience so far. And it's only the beginning. Anna (00:11:47): So Wei Jie was on the show and he introduced us just before this episode, but he was on the show, I think a year and a half ago, where we did do a deep dive into MACI, MACI coming out of the EF's applied ZKP group, working group, I think, is what they call themselves. And what we went into, we went into depth of how it was built, what the zk does. And I think we had one use case that we talked about, which was the clr.fund at the time. But I know that one of the reasons that I wanted to have both of you on the show was that that combination of a lot of DAO experience and these privacy tools, I want to start to explore through this conversation, how all of these things can actually work together. I was thinking maybe before we jump into the privacy DAO, it might make sense to actually give a little bit of a recap of DAOs in general, because I'm 100% percent sure I've covered the term DAO at least 3 times over the last 3 years on the show. But I do think for any listeners who aren't super familiar with the format, with what it is, I think it would be good for us to define it. So I'm going to throw this to you, John, given your longstanding experience with DAOs, what is a DAO? John (00:13:09): Yeah. Talk about terms that are contested. That's a great question. Well, the acronym itself stands for Decentralized Autonomous Organization and you can break each of those terms down and maybe debate exactly what they each individually mean and then what it means when you put all those terms together. But I think in practice, what people are referring to when they talk about DAOs is basically a smart contract system that's living on a blockchain, that is able to take in the signals or votes that are cast by stakeholders in the smart contract system. And then output some decision. I've heard somebody describe this as a glorified multi-sig, basically, where you have multiple people or users, entities, whatever, could be robots, I guess, but multiple token holders in this smart contract system. And they want to be able to make a decision together about a state change related to that smart contract system. It could be the movement of funds that are held by the smart contract. It could be adding or removing token holders or increasing or decreasing the weighted stakes of the existing token holders. It could be actually updating the smart contracts that are underlying the smart contract itself. There are a bunch of decisions that these token holders could make about this smart contract system. But in any case, the smart contract system basically exposes a set of permissions and says, "Hey, these specific Ethereum accounts have these specific capabilities to make these specific changes on this smart contract system. And maybe we also have some rules about how the rules themselves can actually change." And you can think of this as a way of encoding rules that, before blockchains, would have to be executed by a human bureaucracy. Anna (00:15:35): Yes. Lawyers, administrators, some sort of org. John (00:15:43): Yeah, an organizational, institutional entity with policies that are either in people's heads or written down on paper, and then they're enforced by either just social norms or maybe even the actual legal system in most cases. Anna (00:16:03): And maybe at the most extreme the military. John (00:16:06): At the most extreme, yes. By just raw physical force. And whereas with smart contracts and with blockchains, we're now able to write these rules in code and have them enforced automatically by the blockchain. So basically as long as you're able to get a transaction confirmed on the blockchain and you have the right capabilities, according to the smart contracts, you're able to affect whatever change you're trying to make within the organization, provided you have the right number of votes and so on and so forth. Anna (00:16:48): One thought I have about, also going back to your story drawn about working before at Aragon. And one question I have for you is has the vision for DAOs actually evolved a lot, because back then... By the way, interesting fun fact, it seems like we all got into it in 2017. I'm also a 2017 adoptee to the blockchain community. But back then, it was much more like broad orgs would be replaced with these very generalized DAOs. But I feel like what we see now the most, I think I might've mentioned this on a previous episode too, the most popular DAOs or the most famous DAOs, the ones that are being used the most with the most value tend to be in a quite narrow field that'll be a DeFi DAO making decisions about the percentage coming back to the liquidity providers, very numeric, narrow decision space. And there you have a very powerful, very active DAO. Would you say that's true, from where you're sitting? Do you feel like it's gone from more of a generalized DAO space to narrow-focused popular DAOs? John (00:17:56): I don't know if I would characterize it entirely that way, although I would say that there are, I think, more of those and perhaps some of the largest DAOs out there are more of that nature then I think people were envisioning in the early days. So I got interested in DAOs back in 2013, it was either Dan or Stan Larimer were blogging about this early on, around the time of the birth of the BitShares project. And they were actually conceptualizing even Bitcoin itself as a kind of, they called it a decentralized autonomous corporation. And the idea was that Bitcoin was like a decentralized PayPal. It's a payment system, a monetary system that you could generalize, think of it as a corporation of sorts that is just decentralized, the institutional infrastructure of the corporation is decentralized. So you have all of these people who are autonomously coordinating around this protocol to provide the service of payment processing. And they were trying to take that concept a bit to the next level with BitShares, where you would actually have shareholders in this corporation that would be voting on proposals and things like that, of how to actually upgrade the corporation and provide better services to customers and so on and so forth. And then the Vitalik Buterin, founder of the Ethereum project, started blogging around the same time about how can we take that concept and then even go even further to where you generalize the concept of the blockchain itself so that you could build any kind of organization on top of the blockchain and not just a decentralized PayPal. And so that's where the concept of the decentralized autonomous organization, I think, started to really be shaped within the minds of the early enthusiasts in the technology. And there was a lot of creative thinking about how this technology would be used. I mean, a lot of people were thinking on grand scales of like, "Oh, now we have infrastructure for new global governance and we can solve huge, world scale problems, using this decentralized coordination technology". And bringing it back around to your point, what we've actually seen is that DAOs are perhaps most effective when they actually have a very narrow goal. And perhaps even when their activities are primarily confined to only affecting things that are happening on-chain. And so like MakerDAO, I think their's is a quintessential example of this and, for all of its faults, and new faults are exposed, I think, almost every year in that system, it's a pretty well-functioning system, its purpose is to create a stable coin and DAI has been relatively stable through several cycles at this point. And so, I think that on the one hand, there is still that vision for more human-centric DAOs and I think that those DAOs actually do exist. I think, for example, the Moloch DAO community that has sprung up around all of these different flavors of Moloch DAO, you see them, but a lot of them are about supporting people and not so much supporting protocols. Even if the people are working on protocols, it's still more about the people than it is about the technology, but then you also have these other DAOs that are managing large treasuries and such that are primarily focused on governing protocols. And so it's interesting to see this diversity emerging from these core primitives that is DAO and smart contracts, Anna (00:22:14): Samuel, I want to throw it over to you, because you are actually a multi-sig key holder of a DAO that deals in, it has a very specific goal in mind. I'm curious what you make of this concept, the idea of the generalized DAO versus the more specific DAO from where you're sitting. And also maybe give us a little brief on what Tornado Cash governance even looks like, what it's for. Samuel (00:22:38): Sure. Well, I think over the past few years, DAOs have evolved a lot, cause remember back in 2017, there was little talks of decentralized governance, prior to The DAO, and I know Moloch maybe initiated it around then. So it was a very new topic to the scene, not many people were familiarized with it or fully understanding the applications of it. And I do believe we saw a huge... Because the only really conference I went to and I found a love for was ETH Berlin, I was there at the time, everyone was obsessed at DeFi, but it was, this is DeFi without governance at that time. And so it was a weird time and I was in a different head space then, I was trying to create little, let's say new forms of governance that didn't use the token-weighted model, more about reputation, more like someone's commitment. That was actually my submission to the hackathon. And so I think we went to a bit of a Renaissance point with DAOs, in the sense that a whole new direction was orchestrated for them, because when we looked at Moloch, there was an entry requirement, you needed to have a specific of ETH to contribute to the DAO. It is still — DAOs are still pay to participate. The analogy everyone made was that skin in the game, that's the incentive to align with these DAOs and that still applies today with tokens, but I suppose we've seen a more interesting initiation and issuance of governing power the past year even, look at Uniswap, look at Tornado itself. These did retroactive distributions to paso users, which has been a really interesting way of aligning people to participate in governance, but also try many different protocols. And it is very true that these are very focused on specific goals, let's say in the case of Indexed, it's about adding new strategies for indexes. And then, so I didn't even familiarize you guys with Indexed. Indexed is a protocol for passively managed indexes on chain. Anna (00:24:45): This is the project that you were working on before all of this? Samuel (00:24:47): Before all of this. Anna (00:24:47): Before Tornado. Samuel (00:24:48): I was on the founding team. And so governance in this specific, let's say, body would be aligned towards adding new indexes, developing new strategies, liquidity mining, it's all sorts of these incentives by the user or users and that applies to token holders also. So with there, it's more focused on efficiency and radicalization of the protocol to create new strategies. It's a very, let's say, focused towards a financial edge in the market. And there's things like Index Coop, which do things a lot differently to Indexed, I would personally say. Anna (00:25:27): When you talked about this Tornado and Uniswap post-use airdrop, it's so funny cause actually I'm putting it together now where it's like, what it did. And just for our listeners who might not be familiar, both Tornado Cash and Uniswap were non-token projects for a long time, running with users, and then airdropped tokens to those users who maybe use them to different levels. So if you had just sent one thing into Tornado, if you've done one, I don't know what you call it in Tornado Cash, but like a mix or deposit, you maybe would get some small token reward in this airdrop. Whereas had you been very active within it or maybe contributing to the project, you'd get more. With Uniswap it was like whether you were a liquidity provider or just somebody who used it to trade, you would basically get a different amount. And so here you actually saw tokens being allocated in different levels to different usages. And then I actually didn't put this together though, because if you're using the amount of tokens to represent your voting power, you are also distributing voting power to your users. Whereas previously, if you look at any sort of investment tokens from 2017, we can give that example, people would invest in it, but it had nothing to do with the usage of it. The people using the project may be completely different from the investors. And in these two projects that you just listed, the users are the "investors", AKA the stakeholders who could vote. I find that actually very interesting. And I want to dig into Tornado Cash with you, in terms of what does Tornado Cash governance decide? Is it a broad thing about what kind of contracts, what kind of libraries? Or is it extremely narrow? What is the focus of the governance? Samuel (00:27:18): I would still argue that Tornado Cash governance is still forming, it had a bit of, let's say, maybe a rough start, I'd say in terms of issuance by airdropping to past users, as a lot of past users use burner accounts with Tornado Cash. So a lot of that allocation was not claimed. And so we've had some votes so close to not reaching the quorum and the actual issuance of Tornado, the rate at which it has been issued has been very slow, but it's growing steadily. I may say. At the moment we've only had seven proposals, but it was about most recently setting up the community multi-sig so that key contributors could come together and allocate resources, percent of the Treasury's resources to align the community. As you know, we're pretty low on reaching governance participations quite low with the state of the circulating supply. And so I've recently been added to that multi-sig. Was it yesterday? So we are now using Snapshot for vote signaling, since the creation of the community multi-sig, as the community multi-sig can pass proposals or create proposals, sorry. And one thing has been more focused on, I suppose, because it was initially laid out that there was anonymity mining. So that was giving an incentivization for users to use the protocol, like liquidity mining, except you deposit and the longer you deposit, the more APY you gain and you could swap that to TORN. Anna (00:28:51): Anonymity mining. So this is this idea of you're adding extra anonymiity... This is the whole issue with anything like Tornado Cash, whereas if you only have one, say, one person adding, contributing, you can easily figure out who that is. So I had Tornado Cash on the show, but a long time ago, before any of this. So this is also a bit of an update there. And you're using something called Snapshot, which we did touch on on a previous episode about Safesnap with Martin from Gnosis. There we talked about how the Gnosis multi-sig and this is maybe speaking to what you said, John, about a glorified multi-sig. In a way it's like the multi-sigs become the tools for voting. Samuel (00:29:36): I'd like to call it a vote signaling, it's to get the sentiments and then, if the sentiments are good, they would be brought on chain then. Anna (00:29:46): And it's also funny. I didn't realize, I didn't think about the Tornado Cash with the burner. That's so unfortunate actually, this goes against this idea of the fair distribution, the idea that all the people who've used it, will be properly incentivized in this case. I guess that wasn't the case. Samuel (00:30:02): Well, you got to take into context when someone requires privacy and how they want no accountability to that origin address. So it kind of makes sense. That's only a speculation, mind you, maybe these people have never claimed their TORN yet. That will become invalid to claim in the next few months, once we reached the year, there's a year cap on it. But yeah, so Tornado would be more focused towards improving the protocol. Let's say, integrating new features, rewarding contributors and contributors could be anywhere from marketing to smart contract development, to many other branches of what an organization would do to uphold itself. Indexed, as I said, it's more niche towards its utility. So it's the same with Tornado, as John reiterated that these DAOs are kind of niche to what they do and they are internal, they're focused only on their own sustainability and their health. Anna (00:30:59): But they are also not replacing, they're not replacing necessarily all parts of an organization either. I know that the way I always understood a DAO was this, and also the way that I understood Aragon was building out those tooling, was that it would be able to take care of all these different parts of what a company does, but using smart contracts and stuff like that. And now maybe it is that we're seeing more experimentation or even just use in particular parts of that, that make the most sense for DeFi projects. John (00:31:30): I think it's worth digging in there a little bit that nowadays there's kind of a bifurcation of DAOs. So I think using the phrase DAO to actually classify both of these categories might even be a bit of a misnomer, but basically on the one hand, you have people who are trying to replicate traditional organizations in an on-chain setting, like using smart contracts to replace the LLC or something like that. And then you have DAOs that look much more like, say, just protocols that happen to have some human intervention on a regular base, formalized human intervention for managing different parameters of the protocol. Both of these categories are organizations in a sense, but one just looks a lot more like an organization, as we would recognize it, based on our experiences working for companies and other kinds of organizations, then the protocols, which are much more, I think anarchic in a way. And also just very focused on that very narrow use case of, "Okay, you have this protocol, it has some parameters. And there are these stakeholders that have some sort of aligned interests together to ensure that the protocol is well-governed." Anna (00:33:00): I think it's a good time, I might want to come back if we have some time later to some of the other issues that come up with general DAOs and governance structure. I know we've just scratched the surface here in this intro to DAOs, but I do want to dig into the DAOs and privacy topic that I've brought you both here for, and if we have some time at the end, we can revisit it. Now I know that in the zkSessions event, John, you did this really great rundown of the places, where you could imagine in a DAO structure where privacy could live and it's not even the verticals necessarily. It's the levels, how deep into the protocol itself privacy could be found. Do you want to maybe just share that with our listeners, because I thought that was really useful, as a primer for this intersection. John (00:33:48): Yeah, sure. What I was actually doing as I was going through that in the zkSessions thing was actually just imagining the Aragon dApp and going from app to app and thinking of basically each of those sections of an Aragon organization and what could be private there. But so I think it starts with the actual stakeholders, in terms of what could be private in a DAO. And I'll say maybe this disclaimer upfront, which I mentioned in the zkSessions show, which is, these are things that could be private, not necessarily things that either should be private or things that maybe are technically feasible to be private. But if you were trying to, say, build a private DAO from scratch, and you're just thinking of all the things that could be private, you would think about who are the token holders. So basically what are the addresses that have the ability to interact with with this DAO? What is the voting weight of each of the token holders in the DAO, when there are votes, how does each token holder vote and what is the weight of each of their votes. And then you can start thinking of things on the DAO level, where you think about what are the votes actually about? What assets are the DAO holding? It's possible to individually conceal what assets you're holding on chain today, using things like Tornado, or like Aztec, but everything, the assets that DAOs hold are still completely public in all DAOs that I'm aware of today. What addresses are the DAO sending payments to? Once again, as an individual user of the blockchain, I can send a private payment to somebody, but DAOs have to send off their payments in the clear today. And then finally something that people might not think about, but what are the rules of the DAO? Could the rules of the DAO itself actually be private so that only the members of the DAO know what the rules are and how to interact with the DAO. There's an interesting new technology that's being deployed to Bitcoin right now called Taproot, which enables the technique called Merklized Abstract Syntax Trees, where you're actually able to conceal the different paths of a script that your coins are encumbered by. And so as a user of this script, when you go to spend your money, you can choose to only reveal part of the script and then keep the rest of the script private. And so you can imagine something with DAOs now would be this way, where maybe there's some emergency protocol that stays encrypted or hidden off-chain until the moment that it's needed. So that it's harder for an attacker or a hacker or something to figure out how to hack the DAO, because they can't see the script, it's not stored directly on chain. That's just an idea. But having the actual rules of the DAO itself private, I think, is something interesting to think about. Yeah, those are, I think some of the various levels, and maybe there are things that I missed. Anna (00:37:36): I love it. I actually want to almost just recap it, because as you were going through it, this is what I was hoping we could clarify too, which is privacy for the stakeholder and it's privacy for the functioning of the DAO in a way. That seems to be like these two are like the DAO itself. And so on the stakeholder side, it would be the privacy of who the stakeholder is, their voting weight and what they voted and then privacy for the org would be, what are the votes actually happening? What assets are held, what addresses this distribution may go to and what are the actual underlying rules. John (00:38:13): Exactly. Yep. Anna (00:38:15): Cool. One thing I just realized we should probably do is discuss why we would even want privacy and then are there tools that are there to actually create some of this privacy that we just outlined at all these different levels? So let's start with should we have privacy? Why do we even want it? Is it super necessary? I wonder, Samuel, do you have any thoughts on this? Do you think we need privacy? You do work on a few privacy-related projects. So I feel like you're might. Samuel (00:38:44): Yes. I actually came up with some points of sensitivity of a DAO that could be privatized for such reasons as collusion from voting. So when someone votes in a DAO, their action is public and also the outcome of that action. So whether they voted for a proposal or rejected that proposal, it's completely public. Everyone can see that, therefore bribery is almost incentivized, as you can prove actions. So private voting would be very suitable to inhibit collusion, or let's say decrease the chances of it occurring, as no one can prove the execution of an action, they can prove the execution of an action, but not the underlying, let's say, decision taken within that action. Anna (00:39:26): And by collusion, in this case, you mean the idea of a number... Do you mean entities forcing other people to vote in a certain way? Or do you mean cabals getting together or..? What does that mean exactly? Samuel (00:39:41): Collusion could either be internal or external. So internal collusion would be participants would collude together to try incentivize a certain outcome, and that could be done through bribery or blackmail. And it's very open-ended. And external, it could be applied similarly, but it could happen in either way. And so the aim there would just be to completely anonymize the action and, using zero knowledge, that is possible. For example, in MACI, we should come back to that in a bit, but liability is also a very sensitive point within a DAO, because some DAOs specialize in certain functions, for example, dOrg, if you've ever heard it, is for smart contract development. I only thought about this maybe a few nights ago, because my friend used to actually work for them. If one of those delegates or participants is applied to develop a smart contract and that smart contract is then used in production and creates complications, is the developer who authored that liable and not the DAO itself, there will be a trace there. And so I think that if a DAO could privatize the details of executions and keep that actor anonymous over its consensus reach on delegating that actor. And also payment, as John previously said, these would be 2 links to the creator in that DAO, or let's say the participant in that DAO. That was only just one place where I thought it could be quite controversial, because smart contracts are quite expensive things to develop, but also they maintain certain structures that may hold a lot of assets. And then thirdly, which we've already touched on is assets under management. And I think that in certain DAOs it only applies. I don't think it's applicable in every single form out there today, but let's say an investment DAO may have some complications in building positions or liquidating positions in a selection of assets, as they could influence markets through those actions. I then also I know it was touched lightly in the zkSessions, bidding or selling of non-fungible assets could be also another point that would be interesting, but then also without assets under management, they could be targeted to attack if they hold large positions in multiple assets. Anna (00:42:06): I feel like you've just outlined another level in the framing that John had first articulated, which is this: John, you mentioned the privacy of the rules, the underlying rules and, Samuel, you're suggesting the privacy of the creator of those rules, who contributed to that, who deployed it, I do feel like that is almost like sitting underneath that, it's who built the DAO. It's basically privacy of the creator of the DAO. Samuel (00:42:34): Well, not really that, it's more about like, say, me, Anna and John create a DAO. We delegate the task of creating a smart contract to John. John creates a smart contract, which we're affiliating to a different party. That smart contract has an exploit. Is John accountable or is the DAO accountable? That's what I was trying to get into. And I think dOrg is the perfect example there. I'm not too sure how they handle this, but it could be something that it could be susceptible to. Anna (00:43:04): I guess there you're talking also about more like anonymizing who performed something. And it's not necessarily saying that everyone in the org is unknown, this is sort of the decentralized idea, everybody is somehow responsible. Samuel (00:43:18): Exactly. It's the body, it's represented by the body and not the actor. And I think that's important. Anna (00:43:26): So you've mentioned now a few reasons why privacy would be useful. I think the example of collusion is very, very clear. I think the idea of the responsibility within an org, personally I think that would almost need to be thought through more. I wonder if that is something that people are super ready for, to take that responsibility as an entire organization for an individual's bug potentially. Samuel (00:43:50): I don't think organizations are prepared for collusion, if you ask me, even multi-sigs, a lot of multi-sigs don't have timelocks. I know lots of people contest this. And funny enough, we've actually been looking for one for Tornado Cash community multi-sig, because there was some scrutiny over the current structure. And I tried to do some research over some former projects, trying to create a timelock that is dependent on token holders, and I saw recently with Tally, if you've ever heard of them, they're a governance platform, they're creating this Gnosis timelock structure called Safeguard. So it's pretty interesting. So the Tornado Cash community multi-sig colludes and tries to take some assets, there's obviously a timelock on the execution, token holders can intervene and stop the action from happening. Anna (00:44:38): Okay. So this is a mitigation, but this doesn't have that much to do with privacy though. Samuel (00:44:42): It doesn't, but it helps prevent collusion. So that's how it was relevant. But I do say that, yeah, DAOs are not really prepared for collusion. That's what I'm trying to tie into. There's multiple multi-sigs that probably could participate in collusion. Anna (00:44:57): I see. Are there other reasons why privacy at maybe some of these levels would be very important? Why do we even care about this topic? And I have an example here, which is, if you're a business, if you are an actual functioning business and you want to start to incorporate a DAO into your work that maybe doesn't deal just with a public facing, negotiating a percentage of a fee, that's one thing. But if you're talking about revealing your entire treasury, that maybe isn't initially public, but you want to use a DAO, you want to have the immutability of a DAO, but you don't necessarily want to reveal to the entire world everything that you have, potentially if you are paying a supplier through this DAO, making a decision for assets being paid out to supplier, and maybe you've had negotiations with other suppliers and it would be really weird for everyone to see what you paid. I mean, this is the regular doing business type stuff. You don't necessarily want all features of the business to be public, but yeah. John, do you have any other ideas for why we should want privacy for any of these things? John (00:46:04): Yeah. I think, that's a great example right there is that not every organization is public by default, either is or should be. And in fact, I think probably most organizations in the world are not public organizations. And so for various reasons, whether that's the privacy of their own finances or the privacy of the people that they are making payments to, doing business with privacy might be valuable for various reasons. That's at the organizational level. Another thing is, I think I mentioned earlier, if you're able to actually hide the rules of the DAO itself, this could be useful as a security measure, because if you can't see the code, then you can't exploit it. So that might be one aspect. And at the level of people participating in the organization, I think it's useful just for various individual privacy reasons, like you might not want everybody that you make a payment to, to also know all of the organizations that you've ever interacted with. A lot of this stuff in certain jurisdictions might have questionable legal standing. And so what might be permissible today, might not be permissible tomorrow. So you don't want this history attached to your addresses. That that might be called into question at a later date, cause certain jurisdictions aren't shy about retroactively punishing people for things that weren't illegal in the past. And so just for legal or regulatory reasons, you might want more discretion over the information that's linked to your addresses. Those are a few reasons that come to mind for me on top of the ones, that you all have already mentioned. Anna (00:48:10): In having this conversation, like you said, your preface to all of this was, here's why we want privacy. Here's where you could add privacy, but it's not necessarily that we should or can. And I think that this conversation is definitely just an exploration of where in the stack this is possible, not to say that it would actually be in a regulatory framework that it actually would be... There are certain things like, for example, if you were to create an entirely private, intransparent DAO on every level and that it was used for horrible, horrible things, I think that would be very, very bad for all purposes, and I think this is something that anyone in the privacy community or people arguing for privacy should hold dear: that, of course, we want smart privacy, but we don't want crime privacy ever. John (00:48:58): The thing is that the same tools that criminals use for privacy are going to be the same tools that the normal person will be using to protect their own privacy. This goes back to the age of old crypto wars, back when crypto meant cryptography, discussion over consumer grade strong encryption, PGP in the early 90's. More recently, the discussion has come up because of Apple encryption or Signal. These tools don't have back doors. And this is a good thing for the normal law-abiding end users, who just want privacy, because if they had a back door, the back door would almost certainly be exploited by criminals, by authoritarian governments, by, maybe not even necessarily authoritarian governments, but just bad actors within an otherwise well-functioning government. There have been plenty of examples of that within First World democratic regimes. And so I think it's important that whatever level of privacy that we give to people, that it'd be the strongest level of privacy possible, because that is going to be what protects them from these other bad actors, who would want to get access to that information and exploit it for personal gain. And we have to, I think, accept that bad actors are also going to use that technology themselves to conceal their activities and that anybody who's interested in countering those activities, whether it's law enforcement, private investigators, whoever has an interest in fighting bad actors, they're going to have to find other ways of tracking these people down. They cannot rely on back doors or golden keys or any flaws that would allow them to penetrate the encryption in these technologies, because if we had that, then everybody else who's using those technologies would be vulnerable. Anna (00:51:16): Yeah. But going back to the DAO part, in this case, we're not talking about an individual per se, we're talking about an organization. Would you say from the list of places that there could be privacy, are there some that you would say are most important? Would it not make sense to maybe have certain levels of privacy that are so fundamental that they must be built at the origin of this protocol in the thinking and construction of an organization? Whereas there are some other parts where transparency could be very beneficial. And so we do want to leave some public. John (00:51:49): Yeah. I would say it's up to the organization to decide that for themselves, but I would, if one was asking me for advice, I would say you definitely want to do what you can to prevent collusion, because this could just undermine the effective governance of your system, your organization. If people are able to collude or be coerced into colluding, I think having an environment, where everybody's votes are publicly linkable to their known addresses is a recipe for toxicity, because people can look at the votes and say, "Hey, why didn't you vote the way that I would prefer you to vote?" And apply pressure to people this way. And especially in organizations that are hierarchical to a degree, it could exacerbate power imbalances that already exist. And so I would definitely say, at the very least try to figure out voter privacy and anti-collusion mechanisms. Anna (00:52:57): So let's dig into one of these. Samuel is working on MACI, which we had covered on the show. I'm curious, Samuel, listening through those different levels and where privacy could be used, help us understand MACI, let's dig into that and how that could be a tool in this theoretical, private DAO that we're talking about. And maybe what level, cause it doesn't protect against everything. It helps with one piece. Samuel (00:53:24): One piece. Correct. So it's basically around voting, it's more specified towards privatizing. And so MACI stands for the Minimal Anti Collusion Infrastructure, it was proposed by Vitalik back in 2019, looking at the ETH Research post. And so it wants to inhibit collusion resistance, so it doesn't want anyone, but the coordinator, to be certain of the validity of votes. Basically the way that MACI is structured, it has a coordinator who, let's say, coordinates the whole structure. And unfortunately right now, if the coordinator needs to be honest for MACI to work effectively, if the coordinator is dishonest, then the whole system is not going to work as intended, but it exhibits collusion resistance, because no one, but the coordinator, can be certain of the validity, of reducing the effectiveness of bribery, but also no voter may prove their vote to external parties, partes except the coordinator. It's uncensorable, it provides privacy, unforgeability, the correct execution of votes. So not even the coordinator can mess with the execution of votes. And so I'll go into a little top level description of how it works. It requires a trusted setup, as many zero knowledge, or zk-SNARK, systems do. And this would create keys for the coordinator to operate within the system. And there's also 2 other contracts. So we have the gatekeeper contract, which basically is using the registration of users to the system. Any deployment of MACI could configure it so that only individuals holding a certain ERC-721 or ERC-20, or is a part of a DAO, could sign up to MACI. And so there's a sign-up period, in which people can sign up to vote in that deployment of MACI. That is a limited timeframe. So if you can obey the conditions set out in that gatekeeper contract, you can register within the sign-up period. And then also there's a voice credit proxy contracts, which you can define how voting weights are defined among participants. As we see with clr.fund, that's using quadratic voting, it could be a token weight, it could be one individual/one vote model, it's completely up to anyone's preference. Anna (00:55:46): Are the adresses actually unknown in this? Or are those public? The individual voters, is that a transparent thing where you can say "these voters are in it, but we don't know how they vote or the weight of their vote"? Or is it we don't even know who they are? Samuel (00:56:02): So the voters who participate with the system are known, because they have to broadcast transactions to MACI. It's the outcome of their actions that is not known. And that's how it inhibits collusion, because they cannot prove that they voted in a certain way. But I can give you a little example of how it works. So imagine we have Alice and Bob, and Alice signs up to MACI during the sign-up period. Let's say, a poll A comes up and Bob approaches her and says, "I want you to vote against poll A", for some sort of agreement, either compensation in the form of... Anna (00:56:43): Either carrot or stick. Samuel (00:56:47): Exactly. And with the way that MACI works is that individuals publish messages, which are like encrypted commands, and inside a command, you can either change your key pair so you can change your voting address, and you can also vote. So you could do this in the same transaction. And so this is how you would prevent bribery is that in the same transaction, you vote for what that briber would want, or maybe not, because they will never know, but in the same transaction, you change your voting address, and therefore, if you want to avoid that initial vote, you then vote from the new address, which invalidates the other action. And therefore it's not viable anymore. And then the briber will never know if it's actually been confirmed or it hasn't. Anna (00:57:31): Do you prove that you vote? If there's this person putting pressure on you, can you actually show, "Oh, I did vote the way you wanted me to."? At least it looks like it. Samuel (00:57:41): They don't know that, you could still send the transaction hash and say, "Oh yeah, I've done what you've asked", but they can never know if you actually have, because you can just broadcast the transaction from that new address that you just set and just void that vote. And then the coordinator comes afterwards and tallies the votes. And as I said previously, the coordinator could not mess with that tally of votes. They could potentially not tally the votes, which would probably halt the system, or we can't go forward to figure out the outcome of the vote. But that's the only way they could stop the system is if they're like, "Okay, I'm not going to touch this". That's how they could intervene at the moment, but they can not affect the execution of those votes, the tallying, the actual results to what they tally to. And I suppose, in a distant future, we're hoping to, and hopefully my participation in MACI will be decentralizing the coordinator and completely making that a non-human position, I suppose, a non-human operator position. And that's how Macy inhibits collusion, or at least reduces it. Anna (00:58:41): To bring it back to that list of levels, basically this covers 2 out of 3 places in which privacy could exist for the shareholders or stakeholders or voters. Currently the address is public still, but the voting weight and the way the vote went is private? Samuel (00:58:58): Correct. Anna (00:58:58): When you're talking about the coordinator, just for the listeners, the coordinator is actually more in the mechanism, this isn't in a DAO setup, this is in the SNARK itself, there is a coordinator that you're saying is currently a centralized entity, if that coordinator was in some way corrupted than this entire awesome system doesn't work. Samuel (00:59:21): Doesn't work as intended is probably the right description, because people can still vote the specific ways, the coordinator can not mess with the way that people vote, but he could decide not to process those votes and therefore stop the system. Anna (00:59:34): I see. Okay, the coordinator could break it, but they wouldn't necessarily reveal the underlying data. Samuel (00:59:41): It's unforgeable, so they cannot manipulate it. The only thing they could do is put the hands up and say, "I'm not doing any more further actions to stop this process". So at the moment that is the sensitive point of MACI and it's definitely somewhere I would like to work on in the future, removing that and making a completely permissionless process, where we don't need to depend on an honest human to execute the system. Anna (01:00:04): Would you call MACI a product or would you call it an architecture? I know that it is developed and it is implemented and people can use it for clr.fund stuff. But is this something that could be replicated? Is this something that you would almost love to see reimplemented? Is it still in the design space? Yeah, I'm curious what you call MACI. What is it? Samuel (01:00:26): I was having this discussion with Wei Jie on our first call and I came out to call it a standard, but that wasn't obviously effective there, but it's definitely a piece of architecture, a component that you could integrate to your architecture. I wouldn't say it's a product per se. It's very configurable to your own preference. And so I think that's the whole incentivization behind the Ethereum Foundation supporting the development of this is to have it integrated in many different forms of governance, after it's been produced. And it can be integrated at its current state now, but it has a lot of, let's say, constraints. And then also it depends on where you integrate it, because if you integrated this on mainnet, you would be paying a lot of money to even operate this thing. And so L2 is probably the only solution right now, within that sort of cheap bracket of maintaining it. We do know that clr.find, I'm not too sure of the architecture behind, how they have integrated MACI. I presume it's L2. I know Gitcoin actually had some relevance with L2. Anna (01:01:34): But I don't think they implemented MACI yet. They do quadratic funding, but they don't do... I asked Wei Jie last time, unless it's changed, but I have a feeling, I mean, they're now working with zkSync, which is an L2, but as far as I know, there's no zk tech, other than zkSync, just to go onto the L2, I don't think there's any zk tech under the hood. Samuel (01:01:56): I know they were looking at it anyways. Anna (01:01:58): Yeah. If there's any Gitcoiners out there who have to say different, get in touch and I'd love to hear about how you're looking to integrate this or if you have, but yeah, as far as I know, it isn't. What I like about this is, through this interview, through this conversation, we've covered what DAOs are, why privacy is interesting, the levels. And now we're talking about a tool that aims to solve one part of that. I have a question to both of you. Do you know of any tool that could solve the other part, the privacy of the DAO itself, the privacy of the assets, privacy of which addresses receive? John (01:02:33): That's a good question. I think that there are two potential paths here. One would be creating a DAO or something approximating a DAO in zero knowledge using a zero knowledge programming language. Aztec, for example, is working on this programming language called Noir, which will enable some degree of programmability within their fully shielded zk-zkRollup. I don't know how expressive the programmability is or will be with Noir, so I'm not sure if you could actually even code up a full DAO, I think that would be an interesting question to ask them. But given that they will have a programming language, it could be possible, if not right away then maybe in the future. And then another possible way would be using some trusted execution environment magic, like Intel SGX magic, where you have the smart contracts for your DAO living and executing in a completely private environment within these trusted execution environments, which some projects started to experiment with for "secret contracts". Of course, SGX has a new vulnerability that comes out every quarter, it seems like. Anna (01:04:13): I'm glad you're saying that, I was about to... Our listeners definitely were thinking it. Okay. John (01:04:19): Yeah. They're pretty notoriously vulnerable to side channel attacks and various other exploits, but accepting that as the bar, that is a thing. But other than that, I mean, I mentioned Taproot earlier, I think techniques like that, where basically you just put a hash of your contract on chain and then you're able to selectively reveal parts of the contract, when you're on the happy path, and then maybe selectively reveal a different part of the contract, if you're on the unhappy path, it could be a way to preserve some level of privacy at the level of the organization. Those are the ideas that come to mind. Anna (01:05:05): One word that comes into my mind, especially with the what assets are here, is this concept of the selective disclosure. I talked about this, I think a few years ago. I know Ben Fisch is the first person who ever told me about it. Ben Fisch is a cryptographer and founder of a few privacy projects. But what he had talked about, when I first heard it, was this idea of being able to prove that you have something without proving how much you have, or basically being able to do the selective disclosure, you prove that you fall into a threshold. So you do have between this X and Y of a certain token, you have somewhere in a range, but without revealing exactly how much, and this is sometimes thought of as interesting for funds or any... If you had to prove something to tax authorities, you could actually do the selective disclosure. And here I wonder if there couldn't be some interesting tools. I just don't know that there are any tools that do this yet. It's more like there's currently protocols being developed or thought about, that definitely have selective disclosure in mind, but that made me think of it. This idea of which assets do you hold? Do you actually hold enough to do what you say you're going to do? Do you have the types of tokens you say you have, without necessarily revealing which ones they are. Samuel (01:06:25): I can't think of anything that comes to mind that is trying to develop something what you said, selective disclosure, and keep their assets privatized from the public. I don't know anything at this moment that is working towards that or has, let's say, a tangible lead on it, because it's a topic I wouldn't even myself know how to start tackling. Anna (01:06:50): Although I would say, if there was to be a tool, I feel like it would come out of the Applied ZKP group probably, cause you guys are doing amazing experiments in there. Samuel (01:07:00): Definitely. Funny you're talking about the Applied ZKP branch, Semaphore, if you've ever heard of it, that's another place where you can privatize voting as well. Wei Jie worked on that previously, so it is worthy to mention that also. And it also about some other utilities too, as in mixers. And another one was private logins as well. It was in authentication, which is another application of it. But for assets under management, I can't confidently say that I see anything on the horizon that will solve that problem. And obviously because we have zkRollups and L2s, and that's not going to solve that. It's really only for scalability and actions within that L2 and not bridging over, which would sacrifice privacy. I do think liability is definitely something about, let's say, you could use zero knowledge in the fact that we are delegating a task to someone, but not revealing who that person is, even if they're in the organization or not. I think that could definitely be solved with zero knowledge. I don't know anyone working on that. It seems in theory though, it could be applied. Anna (01:08:12): I mean, this is the point of this episode is also share with folks the design space. And obviously if anyone's interested in jumping in on something like this, there's a lot of work to be done, to think through some of these things. Samuel (01:08:25): Definitely. Anna (01:08:25): I do hope that people do walk away from this understanding why having privacy within some of these infrastr... Especially just picture, if DAO structures start to take over really important parts of our world, right now they still live in the land of experiments and DAOs for DeFi governance and financial tools. But what if they start to really be these entities, these powerful entities, deciding things in our world and things that we participate in all the time. I think then this idea of having privacy in it becomes so much more important. And I think right now is the time that the experiments have to happen. And the things have to be tested, fleshed out, developed, thought up, architected, and then some of them might fail. Some of them might not make sense. But I think that if these things do grow in power, which I actually believe they will, I think now's the right time to start thinking about it. So one thing... Sadly we're at time and we didn't get a chance to go into the other issues facing existing DAOs, that's such a bummer, but is there any thought or last thought that you want to share, that relates to that? Something that maybe we could keep our eye on to further that design space around DAOs? Samuel (01:09:44): I would have loved to have it brought in, if we got into that other topic, it was using the metric of the Banzhaf power index in governance systems. There's actually one done for MolochDAO that I think Jake Brukhman of CoinShares or CoinFund, he created a little website showing the Banzhaf power index in MolochDAO. And basically the Banzhaf power index shows the ability of a single actor to skew a vote in any direction. And it's like 50% for the top 2 holders, or let's say stakeholders, in MolochDAO. I suppose if that voting weight was privatized, we wouldn't even know the skew of voting distribution either. Anna (01:10:26): Is that bad? Samuel (01:10:27): Yeah, that's bad.That is bad, because the DAO could just be a theater, as some DAOs are today, they are literally decentralization theaters. Not many people want to admit it. John (01:10:41): I think for Moloch it wouldn't be terrible if it was private, because if a vote went the way, if somebody really disagreed with a vote, then they could just exit. Samuel (01:10:51): And have that rage quit function as well in Moloch V2, didn't they? John (01:10:56): Yeah, that's what I'm referring to. Even if one person controlled the DAO, if they tried to do anything really evil, people could just rage quit. Samuel (01:11:03): And take their ETH out. Yeah. Interesting. Anna (01:11:07): I do want to say a big thank you to both of you for coming on the show and helping to scratch the surface and dig into this problem space with me. John (01:11:16): Yeah. Thank you so much for the invite, Anna. It was a pleasure to chat with you. And you as well, Sam. Samuel (01:11:23): Thanks for having me, Anna. It was great to go over some of the sensitive points of DAOs and where privacy could be integrated, based on service and context, as we discussed. And I do think privacy will become a more, let's say, discussed topic, going further into the future, as governance evolves. Anna (01:11:40): Totally. Cool. So thanks again. And I want to say thank you to the podcast producer, Andrey, the podcast editor, Henrik, and to our listeners. Anna (01:11:48): Thanks for listening.