Dark DAOs and Private Coordination

All right, hey everyone. So I'm Sarah Allen and today I am going to talk about dark DAOs and private coordination. So my goal today is that I will first introduce the technical concepts that you need to know to understand dark DAOs. I'll give a state of knowledge on the research that's been done since they were identified in 2018 till present. I will introduce some recent research contributions and then I'll talk about active mitigations for projects that may want to proactively defend against dark DAOs.

So first up let's talk about private keys. So private keys are must be kept secret to be secure. They're assumed to be held by one person or entity. Any signature given with a private key is assumed to be created by its owner. And anything signed is assumed to be signed with that owner's consent.

So the assumption here, baked into many of our modern systems, is that private keys are exclusively held and used by their owner. And because of this, the assumption that a private key is equivalent to an identity is often made. But what if an owner could share or rent the right to sign with their key? In that case, private key could no longer be used instead of identity. And this is the case with encumbrance.

So what is encumbrance? A secret key can be generated in a trusted execution environment and the key then continues to live in that TEE. The TEE can then be used to apply complex policies to that private key and to its use going forward. So here you can see a user who's generated a private key within a trusted execution environment. They then have access to that key, but their access is going to be mediated by any programs that are being run by the TEE.

So in the presence of TEEs and encumbered accounts, while the private key must still be kept secret to be secure, that's the role of the trusted execution environment in the case of an encumbered key. You can no longer assume that that key is held by one person or entity. You can no longer assume that any signature that has been made was done by that person or with their consent. So the single entity address ownership assumption is what's broken by encumbrance and given that that assumption is made in many current blockchain systems this has wide-ranging implications. The implications of this broken assumption were first identified toward DAO voting in this 2018 post on-chain vote buying and the rise of darkOs, by Philip Dyan, Tyler Kell, Ian Myers, and Ari Jules.

And in this post, they identified a dark DAO as a decentralized cartel that buys on-chain votes opaquely, so in the dark. Potentially nobody, not even the creator of a dark DAO, can determine the total number of participants, the total amount pledged, so the treasury of the dark DAO, and the precise logic of that dark DAO. So here you can see the model of a dark DAO. So you have a collection of voters who've all generated encumbered accounts. They've pooled their encumbered keys.

And now a program can be run across all of those keys together. That's the dark DAO. The program can be this sort of automated vote buying in which an adversary can bid for the right to run the program across all of their votes. So it is this coordination trustlessly done through trusted execution environments that could be coordinated to vote in DAOs. So that 2018 blog post suggested the concept of dark DAOs, but it became more concrete in 2023 in DAO decentralization, voting block entropy, bribery, and dark DAOs.

This paper was co-led by James Austin and Andres Fabreja. I contributed, as did Kushal Babal, Mahim Nikhelkar, and Ari Jules. And this paper had two main contributions. So the first was a new concept of decentralization in DAOs, which we call VIBE, or voting block entropy. VIBE conceptualizes decentralization in DAOs as the blocks of voters with aligned utility functions.

And so that contribution aimed to model decentralization in DAOs as something that would be sensitive to things like private coordination through dark DAOs. The second main contribution of the paper was this model of a dark DAO led by James Austin. So we were able to create a prototype of a dark DAO that could currently be used in Ethereum DAOs. So we did two different prototypes. This is the first one.

And I'll provide a research list at the end of this talk and also share it on Twitter if you're interested in checking out the repository. But this first one is a set of contracts. So they're Solidity smart contracts, which could be applied to Ethereum. They use Oasis, which is a trusted execution environment blockchain as their backend. And you can see here that they could be applied.

So the policy that I've highlighted here could be applied for voting in snapshot. Secondly we created something called a dark DAO light. So this you can think of this as sort of liquid staking for governance votes and this is more user friendly because users wouldn't need to encumber their own keys rather they would deposit their voting tokens in a smart contract which would then give them something we called the DD token, which is a token that would have the value of their votes, plus the value of any bribes paid to participants in the dark DAO. And we have a demo available here too that you can find in the research list. And these two prototypes proved the sort of proximate and practical reality of dark DAOs, although we're not aware of any currently operating.

We posit that this is because dark DAOs are an effective coordination tool in a truly decentralized DAO. And so the current means of sort of collusion and coercion or private coordination in DAOs haven't yet needed dark DAOs to support them. However, the goal in releasing these prototypes was to highlight that this is a threat that DAOs should start thinking about and taking proximate steps against. And I'll point out those later in this talk. But in the creation of that sort of dark DAO light, it occurred to us that actually what's happening here, this encumbering of private keys, has much broader implications than dark DAOs themselves.

And so we call that liquefaction. Liquefaction is an encumbered wallet platform which allows users to attach rich multi-use policies to accounts. It enables the credentials and assets of a single end user address to be freely rented, shared or pooled. And it accomplishes these things privately with no direct on chain traces. So broadly it enables the transfer of things thought to be non transferable.

So what is impacted by liquefaction, this broader tool? So first let's talk about private DAOs. And the important thing to note when going through these impacted areas is that liquefaction is this general tool that has both pro-social and anti-social consequences. So this first one is a particularly pro-social one, which is that you could create a DAO that is privacy preserving, so its treasury is not known and its participants are not known on chain. This would have been particularly helpful in the case of Constitution DAO.

So Constitution DAO was a DAO that was coordinated to try to pool funds to participate in an auction for a copy of the U.S. Constitution. Constitution DAO did not win that auction. It's not possible to know whether they could have won the auction it had they had a privacy preserving Dow however participating in a public auction with your max bid known aka your Treasury size certainly put them at a disadvantage so had they incorporated as a private Dow they may have been more competitive as a group next up quadratic voting and quadratic funding so liquefaction and encumbrance are important things to note for system designers who are considering doing quadratic voting or quadratic funding, even if they do have strong identity systems.

This is important because, so quadratic voting, quadratic funding, as I expect many of you in the room know since we're in the DAO track, these are systems designed to subvert tyranny of the majority. So they aim to empower many small voices as opposed to direct token voting. However, the problem with empowering many small voices in the case where small voices are able to sell access to their accounts is that it would allow a whale to potentially square their voting power or their funding power. So if a whale were to separate their account funds across many small accounts and those accounts were encumbered, so they're able to do that in a way where they can trust that they can vote on behalf of those accounts and they can vote with their own token weight from those accounts and then return the funds to themselves after the election, that whale is able to command much more power than in direct token voting. So definitely something to be aware of for people designing those systems.

Next up, soulbound tokens. So soulbound tokens are designed to be non-transferable NFTs. By being non-transferable, they're supposed to have this special sense of identity that sits with that user account for its whole lifespan. However, if a Soulbound token is sent to an encumbered account, then the user who owns that account is able to rent out, fractionalize, or potentially sell the access to that Soulbound token while retaining the Soulbound token in their initial account. So they won't have broken the policy in any detectable on-chain way for that soulbound token but that soulbound token will no longer be non-transferable in practice next up rights to airdrops and activity-based rewards so rights to airdrops um are often or can be predicted for accounts ahead of time.

However, there has not been a way, to my knowledge, for this sort of speculator class to arrive for individual airdrop rights. But if individuals encumber their accounts, to which they may receive future airdrops, then they could potentially sell the right to receive airdrops to their account in a way that is trust minimized for these speculators who might buy those rights, but would unlock liquidity for those users at an earlier date than the airdrop itself. And then similarly, activity-based rewards. So decentralized exchanges and some other services provide, for instance, better trading fees for users who do a lot of volume, do a lot of trading, have a long history. An encumbered account could be shared across many users, even those who don't know or trust one another.

And so they could sort of pool their activity to get these rewards like lower trading fees together on their accounts. Next up, dusting attacks. So dusting attacks are the sending of potentially unwanted tokens to many addresses. At least to current date, there isn't a way to prove whether or not you have custody of those funds. So they've been sent to you, now your account is potentially tainted.

However, using an encumbered wallet, you can prove whether or not you have access to those tokens, and whether or not you truly hold in custody them, so you could provide a proof that you do not actually own or command those tainted tokens. Next up, locked tokens. So when projects issue tokens for grants to investors to early project participants, often those tokens are locked and have a vesting period, and that can be automatically enforced. However, if they're deposited to encumbered accounts, then individuals could credibly sell the right to those future unlocked tokens while not transferring them from their current accounts. This might be desirable for those who don't want to show an on-chain transfer that they've done this, but do want to unlock liquidity or decrease their stake in a protocol earlier on.

Next up, on-chain and off-chain transacting. So transactions among encumbered accounts could bend what we currently think of in terms of what needs to happen on-chain versus off-chain. So for instance a set of encumbered accounts could trade with one another but send only a few transactions on-chain or messages on-chain that they are making transfers among themselves. So this would be an interesting strategy to minimize gas. Next up, multisigs.

So in a multisignature scheme, if you encumber one member of that multisig, you could do two interesting things. So the first would be you could add additional security by creating this multisig of multisigs that wouldn't be visible on chain. So you could have many signers not identifiable on chain for this multisig who need to command each visible signature. But the second is also a more sinister one. So an adversary could potentially rent the use of a signature as part of a multisig.

And then lastly, allow lists. So it's much more complicated to think about what it would mean to create a binding allow list in a world where users can trustlessly share accounts through encumbrance. And there are more potential implications, both prosocial and antisocial, in our upcoming liquefaction paper. So stay tuned if you're interested in more. So now that I've gone through the many potential implications of encumbrance, I'm sure many are wondering, what should one do in settings where you don't want undetected encumbrance?

You want to be sure that these things are not possible. So you'll need to use something called a proof of complete knowledge. This is a cryptographic technique that was created by Mahim Nakelkar, Kushal Babal, Phil Diane, James Austin, Vitalik Buterin, and Ari Jules. And a proof of complete knowledge is a way to show fully unencumbered knowledge of a secret. It goes beyond proving that the key...

It does this by proving that the key, it does this by proving that the key has been leaked over an insecure channel and it can be done with either a TE or an ASIC. The TEE version of this is possible to do on the local enclave in an Android mobile phone so that's the more likely one to be applied. So where is this all taking us? Encumbrance in TEs breaks assumptions underlying blockchain systems, and additional measures like CK will need to be added to systems that want to ensure that a signer is the account owner, is also a single individual or entity. And the most practical implementation of CK relies on TEEs.

So in summary, undetectable encumbrance is already practical, and the defense against undetectable encumbrance will likely rely on TEEs. So what's next? We'll need to crowdsource a more complete list of systems that rely on assumptions that are broken by encumbrance. We'll need to spread awareness that the signer may not be the account owner in current systems and designed to either accept this or take measures against it. For those wishing to take measures against it, they'll need to adopt CK.

And we need to focus community effort on deep research on TEEs to develop an open TEE for our open systems. And this one's important. It's a big project, and we're just now starting. So if you're interested in getting involved here, I would suggest that you head to the Flashbots forum. We call this project Trustless TEE.

And there are some posts already available on the writings website where you can check out those sort of early understandings of what's going to be involved in developing truly open hardware. And I have a resource list here with clickable links to all of the papers and posts that I've discussed today. I will also be sharing this on Twitter, and I believe the organizers are sharing the slides as well. All right, thank you for your time and attention, and thank you so much to the organizers. Thank you so much, Sarah, for all of this.

And people, you haven't started asking questions with the QR code. So before someone starts placing questions, there's someone who wants to have the microphone and start breaking the ice with the questions. There. Cool. I'm so sorry for the very basic question, but just to make sure, encumbrance is basically like lending someone your ID to get into a club or something and then just getting that ID back.

Is that about accurate? You can think of it as lending somebody your, that is like one policy that a trusted execution environment could enforce here. So you can think about it as sort of lending your credentials similarly to lending your ID, except that it's trustless. So you could lend anybody your ID anywhere in the world in a way where you don't need to know or trust them, and it's automatically enforced, and you can be sure you'll get it back exactly when they've said they were going to give it back to you as opposed to having any doubt or trust. Nice.

We have the first question here in the queue area. So what are their most likely dark DAOs now? So I'm not sure, and I don't want to give an answer as though I am sure. My assumption is that there are not dark daos currently operating. The places where dark daos might be more credible threats are places that are the most decentralized, where coordinating voters to have a sort of overwhelming share of power would not be practical to do person to person anymore.

So if you think about daos that are centralized, where a few whales might be able to coordinate personally to ensure that a vote goes in their direction, I would not expect that to be a good candidate for a dark DAO currently. If you think about a system that is truly and ideally decentralized where it becomes totally impossible to coordinate people individual to individual to get this overwhelming share of votes that you need to pass something, that's when a dark DAO starts to become relevant. So it's as our systems reach these ideals that we've set for them for decentralization is when we need to both be on the lookout for these. Fantastic. And we have our next question is, is there an example implementation of CK?

Yes, there is. So there are a couple of example implementations of CK. You can find them on GitHub linked through the paper that I have shared in the resource list. One of them relies on an ASIC. One requires on Intel SGX, which is a trusted execution environment.

And one relies on the enclave that is in an Android mobile phone. It's likely also possible to develop this for the enclave that's within iOS or an Apple device, but it hasn't yet been built. Awesome. Someone having problems with the QR code and wanting to ask a question? We still have time for more questions?

Who wants to go ahead? Ah, we have another question. Seems like it's a way for CBDCs on public blockchains. I'm not sure I understand the question. A CBDC, a central bank digital currency, is think, probably unlikely to want the particular set of privacy properties that a dark DAO has.

But I'd be interested to hear more if someone wants to elaborate. Please, the person who wrote the question wants to elaborate. So it seems like a way for centralized entities to control multiple wallets and to implement like a soft version of CBDC on a public blockchain. So you mean it's a way for an entity who wants to control some aspect of a DAO or a public blockchain to seize control in an undetectable manner? Yeah, yeah.

So I would say it's likely a large coordination and building lift to do this currently. Like, I would be surprised if this is currently ongoing and we're unaware of it. It's hard to speculate on where dark DAOs will go over time, or if they will become this sort of relevant problem. I could imagine them being tools for useful private coordination for groups that have a lot of funds to deploy. So I can see your concern, but it's not one that I've considered.

Thank you. Okay, awesome. We don't have more questions. Yes, we have one more question. That side.

Hi, thanks for the presentation. I had one question. What would be the difference between an oligopoly and, say, dark DAOs? Because I feel the difference would be between legal and illegal. Is that correct?

So I would say that the dark DAO does not have to be lasting. So it would depend on the structure it takes on the program that's being used. It would be possible for a dark DAO to be launched for just a single vote. So somebody coordinates a dark DAO and then somebody launches a program that only coordinates a group of voters or bribes a specific group of voters for that particular round of voting. Then once the vote that is relevant to the whale that's paying them is over, then the program is changed.

And so those voters that had been aligned in that earlier dark DAO are no longer aligned. So I think the, as I understand oligopolies, a dark DAO might create a circumstance that looks similarly centralized for the round in which that program is operating, but it would be less lasting than an oligopoly in like a token system. No? Number three. but it would be less lasting than an oligopoly in like a token system.

So it's kind of like a bot network, but it can be turned on and off. I'm struggling to understand what the incentives of creating a bot network is and then for just one proposal and then turning it off. Unless, of course, that proposal means the collapse of the DAO, right? So I think it's possible that one would be created and then immediately dissolved. But it would be likelier, my assumption would be that one would be created, but then it would have different programs, so different sort of adversaries who want to buy its weight for different votes.

So rather than one individual who's consistently commanding this network over time, it might be more temporary based on who has the highest utility from that particular vote. Yes. Hi. One possible solution to the problem could be using soulbound tokens with a liveness check at the point where you need to vote or, for instance, claim your airdrop. So you can't really sell or rent access to your private key if you need to prove that you're still the same person at that time.

So it would depend on how you structured it, but I think you still actually would need to add proof of complete knowledge to that Soulbound token, so the sort of liveness check would need to be inclusive of this proof of complete knowledge, because otherwise somebody who wanted to restrict the ability to vote in an election could permission it so that you could still succeed at that liveness check, so provide the proof necessary from the Soulbound Token account that it's still sitting there and alive, but then limit the way in which you can vote in that election. So it could still say, you can produce a liveness check, but then you can only vote yes. But that would be built into the rules of the DAO? That would be built into the program that would be command into the rules of the DAO? That would be built into the program that would be commanding the use of the secret keys within the enclaves.

So the dark DAO would create this set of rules by which you could cast your votes, but you can do anything else from your account. So what you need to prove is actually that full unencumbered access to the secret key. Yeah, okay, I think I see what you mean. Okay, people, thank you so much. Let's please give a great applause to Sarah.