# Cryptarchia Consensus & Blend Broadcasting for Private Blockchains

- Channel: [ETHBerlin](https://streameth.org/ethberlin)
- Date: 2025-06-17
- Duration: 25:29
- Watch: https://streameth.org/watch/685139e24ac43bf73d1c5680

## Description

This talk introduces Cryptarchia Consensus and the Blend Broadcasting Protocol. Cryptarchia is a Private Proof of Stake (PPoS) consensus protocol designed to conceal validator identities during block proposals. Blend is a specialised mixnet designed to strengthen Cryptarchia by anonymizing block proposals through encrypted broadcasting, artificial traffic, and timing delays.

## Transcript

So today I'm going to talk about two protocols, Cryptocurrent Consensus and Blend Broadcasting. One is a private proof of stake consensus algorithm that kind of looks like proof-of-work actually and Blend Broadcasting is basically the result of some of the issues we found as securing validators on the network layer. So here's a question, are you going to submit a block proposal or relay a transaction if it meant that a government is going to kick down your door and arrest you and put you in jail? It's an unreasonable question to ask these days due to recent events over the past couple of years or so, that's certainly been the case and people today are going to jail for social media posts, which are a lot less benign than financial transactions. According to MevWatch at least, even over the past 30 days, 42% of the people are considering that kind of course of action of self-censoring. So we want to prevent this and the reason for doing that is because if we care about impartiality or credible neutrality of our networks, then we need to be able to secure our validators. We need to protect the people who are actually making these networks run, right? And if we don't do that, then we basically undermine the entire value of crypto at all, right? You might as well just use a regular database and even the regular banking system. So this can basically be distilled down into two properties that we want to address. One is this idea of linkability, which is understanding which node actually proposed a given block. The more stakes you have, the more likely it is you are going to win, and therefore you can become more transparent on the network. And stake inference, right, basically the same idea, but it's related to how much stake you actually have in the consensus, because you want to target the big ones. So we want to make this very, very difficult or more costly for an adversary to learn. So when we think about a blockchain network in particular, you can kind of split it up into four domains of concern. You have this sort of network layer, so peer-to-peer communications, how are these nodes talking to each other. We'll address this with blend broadcasting. We're talking about the consensus layer. Obviously this is where you're actually securing the network, proposing blocks, and there's stake or mining, however you're securing the network behind it. Then there's the transaction system, so what's happening on the ledger. We'll talk a little bit about that. The mempool is also another domain of concern, but that's out of scope for this talk. We're really only talking about the first two in this talk. So even though I said that, we do need to touch on the ledger just very quickly. Basically, we're talking about Zerocash semantics here. If you're not familiar with what Zerocash is, it's a UTXO privacy-preserving protocol. If you know the Zedcash project, shielded transactions, you know what I'm talking about. In Nomos, however, we use UTXOs, but much more like a general data model for a thin execution layer on top of it. We are tracking not just one ledger, but we're tracking multiple ledgers. In Nomos notes, we actually keep the semantics, but we change it a little bit. We update the cryptography. If you're not familiar with Zerocash, basically what the ledger is tracking is two proofs, two Merkle roots. One is commitments or minted notes, so these are the notes that you can spend. And another proof, which is, in our case, nullifiers, or the notes that have been spent. In something like Zedcash, you would have this notion of serial numbers that get revealed, and you have this long, linear, ever-growing set of serial numbers that you have to track. We actually compress that inside an index Merkle tree. Not even the serial numbers get revealed in this. It doesn't really matter. Basically, minted notes, spent notes. And if you can produce a proof that says that my note is in the set of minted notes, and I know my secret key, and it is not in the set of spent notes, then I'm allowed to spend. So we want to get to consensus. We want to get to that party. But first, we need a bootstrap. We need to get up-to-date to get to that party, right? So there's a bit of a problem in synchronizing from scratch, right? It's like, okay, let's say a stranger shows you two immaculate blockchains. They look identical, but if you choose the wrong one, you're going to get rugged, right? You don't want that. So Cryptacea actually belongs in the sort of Ouroboros family of consensus algorithms, and specifically, we are borrowing all the semantics from Cryptinus. And they take their fork choice rules from Ouroboros Genesis and Prowse. So when you first bootstrap into the network, you're basically getting all these blocks, you're going along, but when you find a fault or a fork, you're basically choosing the densest out of a certain set window, like an epoch or two, which I'll get to in a second, right? And the reason for that is because it's going to be much, much more difficult, they prove it's much, much more difficult for an attacker to be able to create a denser blockchain against the whole bunch of honest nodes that are proposing blocks in a certain time period. And then once you're fully synchronized, you kind of fall back to a longest chain sort of fork choice rule within like a certain, you know, not going all the way back into affinity, but just to a certain interval. So once you're synchronized, basically, you will start to notice how the game is being played. And so in Cryptarchia, and in this sort of family consensus algorithms, time is split into these epochs, right? And in every epoch, you have a series of slots, right? These are all potential block allocations. A slot is basically every second you can think of, right? And we target a block production rate parameterized in Cryptarchia of roughly one block out of every 30 seconds, 30 slots. But within an epoch, there's actually sort of three phases that are going on beyond the normal sort of block production, like growing the chain, right? And so the first phase is really about coming to consensus on what the sort of validator set is, right? However, in our case, we can't know the validators, and we can't know the total amount of stake. So we're actually coming to consensus. What we're actually doing is we're using at least one epoch, so the first block in the last epoch, sort of commitments in the transaction system, right? That spent notes and minted notes. And so that becomes this sort of aged notes idea, right? And so by then, like by the end of the first phase, everyone should have confidence, at least the honest nodes, what that commitment set is. Then we basically continue to accumulate more information. And at the end of the phase two, we'll have our epoch or our randomness revealed at that point, along with a total stake estimate. And I will get to that in a minute. And then like the phase three is just making sure that it's deep enough for honest nodes for the next epoch. So by the end of that finalization, the end of the epoch, we'll have these sort of three main constants, right? So the C-lead is that sort of aged note commitments that I talked about, at least an epoch old. We'll know the sort of randomness that has to come after the sort of leadership eligibility to prevent grinding attacks. And then we have our sort of total stake or our difficulty, our inferred stake. And once we have all of those constants, we can finally play the game, right? We can roll the dice and we can see if we actually are able to propose a block. And the logic at face value is pretty simple, right? So like basically you need to get the randomness, that's the epoch. And then we check that randomness against our total stake, I'm sorry, our stake in the network versus the total stake. And if the randomness is less, we get to propose a block. That's essentially what the game is. Yeah, so we know the randomness, like we know our total stake, but other people don't and we don't know theirs. So that's a problem. And not only that, because we don't know theirs, they don't know ours, we also don't really know what the total stake is, right? So how do we figure that out, right? And what's kind of interesting is this starts to look a lot more like Bitcoin's difficulty adjustment. So back in the sort of 50s, Robbins-Monroe proved that you could learn unknown value through a corrupt or noisy signal. And this basically gave birth to a whole class of algorithms called stochastic approximation expressions. And so basically this is very similar, if you're familiar with Bitcoin's difficulty adjustment, it's very similar to this. And this actually starts to look a bit more, even though it's proof of stake, it actually looks a little more like proof of work because you don't know how much the hash rate is out there or the amount of stake is out there and you're having to adjust. So what is this noisy signal that we're looking at? Well, what we're actually doing is seeing how many proofs of leadership, how many blocks are being proposed within a time window, within those sort of first two phases of an epoch. And by doing that, we're able to essentially compare that against our sort of ideal sort of rate of block production that we want, right? Here is that one over 30 that I was talking about. That's what the natural log is there. That's sort of one minus F is. And then we just basically do signal up, signal down, depending on the learning rate. And it turns out that this actually works. And the estimator, at worst case, has a sort of 3% difference or error rate through this noisy signal. You basically treat this as Bernoulli trials and you'll find that out. We also simulated this doing large mass approximation over 70 epochs, even in the event that you had like a centralized stake, I mean, which is super, super fascinating. That's one of the points that I wanted to bring up here, but I've lost it. So even though that sort of one-liner logic of what the proof of leadership is doing, the actual proof is a lot more involved, right? Don't have to really worry about too much of this. I think the condition two is just basically that sort of leadership eligibility, but also showing that it hasn't been spent in that time either. Conditions three to five are essentially that logic, checking the randomness against your relative stake. The difference here though is that to fit this in a circuit, we have to basically do a first and second order Taylor expansion to approximate the threshold. Otherwise, it's not possible. And if we can do all of this, we can get a proof like this. We can have basically an authorization that says, yes, this block is, I have the right to propose this block. You don't know anything else about me and do with it what you will. There is one extra thing that we have to take care of, which is this sort of condition six and seven, which is one other issue against an adversary. So this comes from, this construction comes from Christinus. The basic idea is that an adversary might be able to find your computer, that you use to propose blocks with in the past. And if they can, they'll be able to take your keys and they may be able to recreate those blocks. And so that's a problem when you come back to this sort of dentist's foreclose rule. You might be able to create, and if you can do this enough, you might be able to create a dense enough blockchain to be able to change the course of history. So what we do is we basically take the, we create a Merkle tree and use the root as the sort of secret key that controls the fake. And within that Merkle tree, we basically generate a whole bunch of key pairs and put them into that. And within the proof, we're showing that we know a path in that Merkle tree to that particular key pair and we've signed it. And then basically it's up to the honest nodes to be able to delete those keys as they go along. Okay, great. So you have this block proposal. You're able to propose a block. No one's going to know that, how much stake you have or who you are, but you now have a new problem. And then you're going to be able to, how am I doing? Yep. You're going to be able to send this onto the network, right? And this is basically how every blockchain, not every, but vast majority of blockchains work, is they will broadcast this block proposal to the network. Now, what we're going to be doing, it's like, if my explanation sucks, is just imagine a game of pass the parcel. Show of hands who's played pass the parcel as a child. Not too many people.  Okay. Well, that analogy sucks. Basically it's, if you can imagine like a toy or a gift, you know, as you get as a present, but every single layer, it's wrapped multiple times, right? And usually there's a piece of candy between each single layer. And it's like, kind of like musical chairs. Like you basically run the gifts around the group and when the music stops or whatever, someone gets to open it and they get the candy and then they pass it on, right? So it's a good sort of onion wrapping thing. The dad there who has a very stern look, he's probably had a really bad day, is our adversary. He probably controls two kids and can strike the fear into everyone else, right? Okay. So you might be thinking, well, why not just use a mixed net, right? Or why not use an onion routing? I can be covered under that. Surely that's what these anonymizing communication networks do. And, you know, if you're doing a transaction, that's a reasonable assumption. If you're even doing consensus and you're the only one who has that idea, that's also good. But what if you're not the only one? What if it's 10 people, 100 people, 1,000 validators, all participating in consensus? Well, that's where both onion routing and mixed nets start to kind of start breaking down. And the reason for that is because of the nature of this traffic. So if you think about it, right? where they're basically producing blocks every, you know, potentially every second, but, you know, ideally parameterized to, in our case, one every 30 seconds. And so they're creating this sort of like wall of traffic on a heartbeat that's going boom, boom, boom. They're synchronized senders. And that's a huge problem because mixed nets rely on exponential delay for their non-entity, which means that as you have this kind of wall of traffic flowing through it, the delay will go beyond your block production rate, which is a problem for safety and liveness. And onion routing is notoriously bad for, well, it's very well known, weak to sort of traffic correlation attacks. So we actually need like a Goldilocks protocol, something that's not too hot, not too cold, right? And so we need to raise this cost of linkability, like this time to inference, while maintaining a maximum delay in the network of lower than our block production rate. We target 20 seconds. We now need to allow for network churn. We need to minimize method censorship. We need to incentivize cover traffic on a one second schedule. We need to mix messages. We need to minimize spam as well. And we need to use minimal bandwidth, right? So it's actually a very challenging problem. And so to answer this problem, we've come up with this notion called blend broadcasting. And you can imagine it's something like a hybrid between all of these. It's a sort of mixed net flooding gossip. It has these sort of five linear paths of three hop sort of multicast circuits that are created in it. It has geometric delays, pull queues, and it has that cover traffic, right? So here you see this sort of blue circle that the block proposes, let's say, and it's broadcasting down five linear paths of three hops. That is not the peering degree. That is the peering is done on the sort of flooding notion. The linear paths are kind of emergent through the mixing. And ultimately, you're expecting a terminus at the sort of broadcasts of the entire blockchain consensus algorithm. So why blend? Well, we don't assume a global passive adversary because it's a very weak adversary, actually, and it's also unrealistic from a global standpoint. So we assume a partial active adversary. In our case, we assume the network is 10% adversarial nodes, 10% faulty nodes, and we parameterize the network with these sort of five linear paths of three hops each under a peering degree of four. And with these assumptions, we believe that we can raise the time to infer by 300 times for a 50% confidence in a proposal by an adversary. The difference between having this and not having this is having the government kick down your door in 12 days versus 10 years. Yeah, so I'm running out of time. So basically how this works is you have to register with a directory initially. This is backed by stake. We're not going to get into this. The main thing here is the provider ID because this is going to be used with a Diffie-Hellman to open up messages addressed to you. Now, we're trying to do two things. We're trying to create a lot of traffic at the same time, but we want to prevent bandwidth use, and so we need to have it spam rate-limited. And so we actually need every message to be uniquely identified for a session or for the epoch. And we also restrict how many nodes so how many messages a node can make, right? So basically what happens at the beginning of every epoch or a session is you have to basically create a whole bunch of ephemeral keys up to your allocation, which is a protocol parameter for the session, and you have to create proofs for all of them. So this one basically is a ticket that says, yes, I'm part of this registry, and I've generated this public key, right? And it's under the quota limits. And you also have to do the same thing, but with a proof of leadership, where you basically say that this is a proof of leadership. So this is a separate parameter, so you can still allow for covered traffic and valid proof of leadership to come through. And then you wrap both of those proofs into a proof of quota, right? So this is kind of like the first part of a candy inside the parcel-to-parcel game, right? So you open up a sort of wrapper, and you'll see candy, a bit of this candy. I'm running out of time, huge problem. I'm too ambitious, I apologize. So basically, when we were ready to send a message, we have to sample 15 nodes to create these five linear paths to the network. We have to generate what's called a proof of selection here, which basically proves that the public key is mapping to the index that you've chosen, right? So when you're taking off a wrapper, you get to look at it, and if you can take off the wrapper, it's because the encryption worked. And then if you look at it, this will tell you whether it was actually designed for you to broadcast or not onto the public channel. And if you collect both of those, and then you can use this for rewards, which we won't talk about in this talk. And then you use that to look up the Pride Rider ID to set up a Diffie-Hellman to encrypt the payload. I'm basically out of time. Message encapsulation is basically like Sphinx, if you're familiar with it, except we add some of the proof of quotas to this, and the private header is basically the same, but it has this proof of selection for the second part of the candy associated with it. So yeah, through doing that, we incentivize people to send message or relay messages within the network, but we also restrict people from sending any more messages than they're allowed to. Basically out of time. Here, I think when a node receives a message, just look at the last two lines, you actually immediately relay everything that you get, and then you put it into a processing queue, right? And the reason for that is to prevent any timing attacks. So you're always kind of flooding. Once you do that, I've already kind of walked through this, you basically get this blending token, which is the proof of quota and the proof of selection, so you can use that for reward proof later on. And yeah, so every round, here every round, that's every sort of slot activation, right? So every one second, but it's not every one second that you're doing your broadcasting on the mixing side. It's a little bit of jiggle associated with it. So yeah, we're also running this cover scheduler that's basically injecting more cover messages into the queue if you have a budget. Yeah, and that's basically it. I'm sorry, I had to speed through some of that towards the end there. There are some limitations. Again, so the mempool is a huge problem as well, susceptible to tagging attacks. So an adversary could be able to specifically target certain nodes with tagged blocks or transactions or whatever and see how it propagates to the network to be able to identify them. The other thing is that even though we're raising the confidence for block proposals or leaders to be able to emit blocks here, leaders can still self-censor themselves for whatever reason, right? And an ideal here would be is that we could force a leader to include transactions, right? So we're working on these. If you're interested in working on these, please reach out to me. And the other thing we haven't covered in this talk is edge node anonymity, right? So if you're not part of this validator set, how are you anonymous? And for that, we have two answers. We work on the WACU protocol, which is a pheromone peer-to-peer messaging. And we worked on a libp2p mix specification, which applies to our protocols as well. So yeah, if you have any questions, feedback, hit me up on X. I'm sorry, can't ask questions today. Bunch of URLs.