Sedna: How users can enforce affordable privacy, censorship-resistance and MEV protection in MCP chains

Transcript

Yeah, more or less. Okay. Okay. Well, I'll I'll take it slowly. Okay, so um First, let me explain what multi-concurrent proposers are. Um and let me explain it with two different um consensus protocols. Who's not familiar with consensus protocols? Or what is consensus? Okay. So, yeah, for those of you who are not familiar, consensus protocols are at the core of uh blockchain designs. They're what decide the ordering of transactions. And um I'm going to argue that single leader, which are the typical traditional consensus protocols uh for BFT chains, give too much power of ordering to the leader. So, what we have here at the bottom an example of a leader design, leader-based design. So, we have the leader, in this case process zero,

proposer zero, proposing a value and then there's two rounds of voting and the value is decided, right? Um at the top, we have an example of a multi-concurrent proposer design, uh where we have four different proposers, each proposing a different value, and then there's some consensus protocol that decides some of them to be included in some particular order and some of them not to be included. So, there's no single leader that controls ordering of the transactions. And this is a very popular design at the moment. MCP chains, there's Sui, there's Aptos, there's Hedera, now Solana's latest consensus proposal from last week. So, the upgrade to FGL is also based on MCP.

With Ethereum, as I said, we have Fossil, which is kind of a step in that direction. We have Bricks, which is explicit multi-concurrent proposer uh design for Ethereum. And the reason is because it provides uh censorship resistance and for some definition of privacy, it could provide uh not privacy by it can provide uh MEV protection. I'm going to argue, however, okay, who thinks that multi-concurrent proposers, like is said typically by the Solana guys, by the Aptos guys, etc., is a solution for MEV protection or for censorship again like to provide censorship resistance. Who thinks that is enough?

Okay, good. Um so, yeah, I agree with you guys. I don't think it's enough. Um and the reason is uh because of this three-way trade-off. So, if I'm a user and I want my transaction to get included and not get censored um um what I can do is if I have a multi-concurrent proposal design, I send the transaction to one proposer at a time, right? Um, and that gives me the guarantee that I'm not going to pay for the transaction more than once, and if the proposer doesn't include it in this lot, then in the next lot I try a different proposer, right? This is something that you can already do in Ethereum because we you have rotating leaders.

If um I want to exploit some low latency opportunity, I don't know, I see some arbitrage opportunity and it's either now or never, I can send the transaction and if it doesn't get included, then you know, I don't try anymore because that opportunity is gone, but then I don't get censorship resistance, right? I get low latency, but I don't get censorship resistance. And if I want both, then because it's a multi-concurrent proposal design, then I send the transaction to all the proposers, and then I'm guaranteed that I, unless all of them are trying to censor me, as long as one is not trying to censor me, I can include the transaction. But somebody has to pay for that because that transaction is going to If I want censorship resistance against F proposers, then I need to send the transaction to F plus one proposers, which means that somebody has to pay F

plus one times the price of including that transaction. And there's two different designs. On one side, we we have um the Sui guys, for exa- like in production, we have the Sui guys, the Aptos guys, or Filecoin, which Filecoin is also a an MCP chain, where the cost of including that transaction is absorbed by the system, is subsidized by the system. So, effectively, what means is that the user is only once, but he can include the transaction 100 times, for example, which means that the good put, you know, if the throughput of the system is 1,000 transactions per second, then it reduces to a good put, a useful throughput of 10 transactions per second.

And then on the other side, in production, we have Hedera that says, "Hey, you know, we provide this multi-concurrent proposal design. You can use it to to, you know, leverage censorship resistance, but you're going to pay for it." And so, if a user wants to get censorship resistance against 99 proposers, he's going to have to pay for the transaction 100 times. So, yeah, it's censorship resistance, but it's not really affordable, is it? Um also, I know that the way the reason why this is Well, to answer the original question that I did is Ethereum or these chains are censorship resistant? It actually depends, right? It depends on your assumptions on the adversary and whatnot. We are seeing in Ethereum big MEV being being extracted, you know, from users. So, it's an obvious answer that it's not really censorship

resistant or MEV protected. Um in these chains, the way this is actually alleviated is with a trusted RPC, right? So, it's the RPC the one that um selects which proposer to send the transaction to and for how many duplicates. And that's why, you know, we're not seeing an attack vector in which the good put is reduced by 100x in these chains. But that is trusted. And so, in a way, I see the evolution of providing censorship resistance in blockchains um in these steps. So, first, we have the traditional step of leader-based consensus.

From there, we uh some people in the space argued we can do better with MCP providing censorship resistance. And we could say the the Sui Aptos and Falcon guys are there. Then, the Hedera guys realized, "Oh, this is an attack vector. If we really do If we really want to do this in a trustless way, we need to charge users for this." And then finally, um realizing that this is too high a cost for users to pay and try to alleviate this cost. And this is the work that I'm going to be presenting that I I'm doing I'm doing at Sei. Um although actually, it was uh Sei with some collaborators, researchers from Sui.

And so, here's the solution. It's very simple. Um the traditional way, as I said, of of getting censorship resistant benefits from a user would be to just replicate the transaction and send it to different proposers. And then, as long as one of them proposes it to be included in the blockchain, well, uh we're good. Um what that means is to get a lead to get a censorship resistance uh that is that protects you against a linear number of proposers, you need to pay a linear number of fees. Um, and the good put of the system is reduced linearly as well. What we propose is sharding, so the transaction is sharded into smaller chunks, smaller pieces, sent to different proposers such that as long as enough of these proposers include their chunks, you can reconstruct the transaction. And so as a result you get the same or like um,

to you get the same tolerance in the linear number of proposers uh, for censorship resistance, but you pay a constant cost. And you also get constant fraction of the throughput in good put. So it's a straight improvement in these terms. So um, I have a presentation on Thursday about how this protocol works in particular and it byzantine fault tolerance on the protocol etc. Um, I'm going to just kind of like skip through that now to get into the economics. So how what is the MEV cost? The the MEV protection cost using setna using the solution that of sharding.

So for that let's first define the problem and apply the protocol in a naive way. So we have here a number of proposers, a user that is sharding his transactions and sending to different proposers such that if enough of them include their chunks, we reconstruct the transaction. Um, now what the user what the attacker can do is, you know, we have a coalition, a cartel of a number of proposers that is going to try to reconstruct the transaction with the chunks privately before it's on chain in order to exploit MEV. Because they if they just get some chunks, they cannot really know the content of the transaction.

Um, so instead of sharing the and then they can decide also to censor or not to not share the chunks. So for example here, one of the members of the cartel of the coalition decides not to include their chunk. But because Uh, there were more chunks than needed, the transaction is still reconstructed. This is what we call as lack of one. So, one chunk can be not included and still the transaction can be reconstructed. What about two? So, now with two, the number of chunks that have been included on chain is not enough to reconstruct the transaction. So, at that point, censorship has occurred.

And also, the cartel can privately share the chunks, as I said, and reconstruct the transaction on their end, and they get one extra slot where they can, uh, you know, basically, uh, extract maybe from this transaction. And here, we analyze also two different, uh, risk that can occur with set now. Or like that not that are not fully, uh, solved by set now. By this sharding solution. One is the multi-slot one, which is the one I have shown. The transaction gets censored, and so you need one more slot of consensus, one more round of consensus in order to include the transaction. The other one is the within-slot delay.

So, even if the transaction is going to make it on chain in that same slot, if the cartel if the coalition is very well connected, they might still manage to get the chunks first, reconstruct it on time, and uh, wait for that, and then once they have reconstructed the transaction, make their own proposal knowing the content of the transaction to try and still front-run that transaction. So, we analyze the two of them. The first thing that we notice is this very interesting kind of like inverse sawtooth where, um, so the user has a lot of parameters that he can, uh, tweak to its benefit, you know? It's a user-facing protocol. The user can decide how many chunks to split the transaction into, to how many lanes to share, to how many proposers to send

chunks. Uh, how many chunks per proposer, etc. What we see is, uh, the important parameter is what I was calling the slack, right? The slack is how many extra chunks the user can tolerate to, uh, not to to not be included and still reconstruct the transaction. So, um, the interesting bit is that as the slack, so in this case, we have 100 proposers, the user is going to choose 20 of them at random per round of consensus. And we assume the cartel, the coalition, is also controlling 20 lanes, some of the 100, 20 of the 100.

And they're here the bottom the x-axis is the decode threshold. So, how many chunks are needed to reconstruct the transaction? So, one thing that is interesting is here before I was explaining in the case of one round, but you can actually the user could actually and it's actually beneficial for the user to split the transaction across rounds. So, basically to require more chunks that are in that that he sends in one round. Um but what we see here is like kind of like a frequent pattern that repeats over the over the slack. So, um over basically the number of chunks needed for the construction modulus the the number of lanes that are contacted.

And what is interesting is here Q micro is the um probability of the attackers managing to get enough chunks to reconstruct the transaction within one slot before it's included, even if censorship doesn't happen. And for this one, as the decode threshold gets closer, um so as the decode threshold gets closer to a slack of zero, actually the probability decreases. Whereas for the multi-slot delay, happens the opposite. The higher the slack, the harder it is for the attackers to um to delay uh the transaction by one slot because, for example, if the slack is 19, and I send

that means that I send a transaction to 19 extra proposers in this slot. So, I can afford 19 of them to censor. If one includes it, so it's really hard to delay one multiple slot. But that also means that uh that I only need one extra chunk to reconstruct the transaction. So, it's a lot easier if that extra chunk, one of the those 20, belongs to the coalition, it's very easy for them to reconstruct the transaction quickly. So, it's kind of like an inverse sawtooth. But, this is the straw man approach. So, what kind of what kind of scam can we do um from the user facing protocol in order to protect more the user? The first one is what we call the ratchet strategy. Um a ratchet, for those of you who are not native in English like me, is a a tool that you can like a screw in one

direction, but then you cannot really go in the direction contrary. So, everything that you gain in terms of a screwing or tightening, um you gain it forever, kind of. And so, that's kind of like the same approach. As I said that we have this like situation where you can the user can decide to require more slots uh preemptively as protection. The reason why this is beneficial is because the attackers don't know how many shards are needed for the construction. It's It's not a parameter. They They can't They know once they reconstruct, but if they don't manage to reconstruct, they don't know if there's one more needed or 10 more needed. So, they have to take a kind of like a decision in in in darkness.

And um what the user can do is it can send some trans- some shards such that even if all of them are included on chain, the transaction still does not reconstruct. And if some of the shards are not included, the user immediately learns, "Oh, these people are malicious. You know, these people are intentionally not including my chunks. So, in the next iteration, I'm not going to I'm not going to message them." So, in every new round that someone censors me, I immediately learn this person is censoring me. So, I'm not going to contact this person anymore. And uh doing that, you can actually see that the uh probability of delay actually really really decrease when you have high slack.

So, basically, there's no benefit for the attacker in the multi-slot delay from delaying. In the multi-slot case from delaying farther. Um Yeah, well, this this pretty much everything I said on this. Then, here's another realization about this kind of like a different way to analyze the problem, but also a different way to exploit the problem. So, um there's two ways that you can, in general and distributed game theory, there's two ways that you can analyze an adversary. You can say, "Oh, this is different virtual proposers, all controlled by the same entity."

So, there's one person behind that is selfish. Or you could say, "These are actually different people that just get together because they can exploit more the user, but they are all independently selfish, you know? They they they come on commonly known as no honor among thieves, you know? I'm with you just, you know, if I can screw you, I'm going to screw you as well." Even even though I'm with you for the moment. And in the second case, which is more realistic, where you have the different real people that are colluding together selfishly, it's interesting because this here there's an asymmetry on the attackers. In this case, two of them must not include their chunk, their shard, for the, uh, censorship event to occur.

But the one at the the third one includes his shard, so he gets a double benefit. It gets the MEV benefit like the others from reconstructing probably the transaction, but it also gets the benefit from the fees, whereas the others don't get that benefit. So, there's an interesting asymmetry there that kind of like creates, if you can exploit it properly enough, you can create kind of like a prisoner's dilemma. Like, let me explain here. Um, kind of like a prisoner's dilemma that you can exploit even further with what we call, uh, pivot key. So, pivot key is, so a fee in a shard, like in any transaction, is given when the transaction is included, right? If you include the transaction, I get the fee for the transaction.

Pivot key says is a special fee that is only paid for the shards that are strictly needed for the reconstruction. So, it might be that we include more shards that we need to reconstruct in the chain. In that case, they get the normal fee, but those extra shards do not get the pivot key bounty, the pivot key fee. So, we're putting more pressure on malicious attackers not only to include the shard, but to include it in a way that is relevant to the construction. And so here here will be the example. So we have Imagine we include K plus D um shards, but we only need K.

So the ones who get the bounty are only the first K. And this is uh this is an interesting thing that is what we call a baiting strategy. So it's a type of punishment strategy. So it's it's it's it's it's known in distributed game theory, the notion of a punishment strategy is a strategy that uh honest people can enforced such that the threat of it already is enough for the attackers to not misbehave in the first place, right? Similar to how people don't commit a crime because they can go to prison. A baiting strategy is a strat is a is a type of punishment strategy that requires collaboration from within the criminal group to succeed. Similar to I don't know, if there's a criminal

group that is very very powerful in a society, you kind of like need them to break apart first, right? You you take some fish in them and then tell them, "Okay, if you collaborate with us, we kind of free you, but we get you to catch the rest." So it's kind of like the same strategy. And doing that, what we see is that um I Wait, okay. Yeah, I have some time. Um so yeah, what we see here is for example in the orange line over there, um means that for these parameters of This is for a transaction of a value of 500 uh whatever you want to call it, 500 tokens. And the MEV extractable if the transaction can be reconstructed and exploited is 100.

And so what we see here is that for a bounty of 20, already there's some there's some moments there's some um the core threshold under which just the bounty is enough to disincentivize uh the coalition from misbehaving. So we're just just with a coalition of 20 tokens, uh we can already secure a transaction whose extractable value is 100 and whose real value is 500. And it's actually going to be much more dramatic later on. This is just um a specific example. Uh actually, I don't think I have too much time, so let me go forward a bit.

Um yeah, okay. So, here's some examples. Here is um probably the most interesting here thing here that we haven't mentioned yet is first how the the worst-case scenario is to have a very long uh honest horizon. The honest The honest horizon will be the number of uh rounds of consensus that are needed in order to reconstruct the transaction in the best case. So, if everyone is honest, the user has created so many chunks that it takes, let's say, in the bottom line, bottom row, second column, five. It takes five rounds of consensus to actually reconstruct the transaction.

If the user has a high honest horizon horizon and a zero is lack, meaning that it cannot tolerate just one chart not being included, that's the worst-case scenario, right? The probability of delay is one in the in the knife case. And even with the ratchet strategy, it doesn't get much better. Um and so, yeah, the cost, the bounty that you have to pay to the attackers to disincentivize misbehaving is very high. So, in this case, it's a $50 for a for a for a fee of a transaction value of uh 100 tokens.

Um however, if you um use all the strategies that we have been discussing, um just to give a sneak peek of the benefits that you can get with this, just 0.04% of the maximal extractable value from this transaction as a bounty is enough to disincentivize a cartel controlling uh 20% of all the proposers. So, even if 20% of the proposers get together and say, "Hey guys, let's try and, you know, work together, share our shards so that we can extract value uh privately and like, you know, do some sandwich attacks or whatever."

Just um just with a honest horizon of two and just distributing our shares between 30 lanes, already gives the user a protection. Let's say the user has to wants to create some uh trading transaction for five Let's say Let's go like crazy, $5 million of of which if somebody can see and exploit with a sandwich attack, they can extract $500,000. Which is horrible, right? So, in this case, to protect against that, you just need $2,000. So, you just put a bounty of $2,000, and your transaction is No, against an attacker controlling 20% of the proposers, it doesn't pay off for them to attack the transaction.

And so, these are the different cases um that show um depending on how many transaction How many rounds How many How high your honest horizon is, how many rounds the transaction's going to take to be included, and what is the slack, how many chunks the user can admit not to be included while the transaction can still be reconstructed, what is what are the benefits benefits that you get. And so, yeah, the best case scenario would be uh enforcing an honest horizon of two. So, splitting your transaction into shards, not sending all the shards yet, send some of them in the first slot, and some of them in the second slot, just to try and test out which proposers are behaving.

Um and also make sure that you can still tolerate some of the shards not being included. So, have a positive slack. Announcing your slack. And as I said, yeah, the MEV protection cost is still 0.04% of the transaction value. Then as future work, um I've been kind of lying up until now. So, I said one of the properties I'm I've been talking mostly about censorship resistance and MEV protection, and how that breaks if you can reconstruct the transaction. Well, it turns out, I mean, sharding does not give you uh perfect privacy. You know, there's always some leaking per shard that you get if you if if they're smart about it. It's not uh secret sharing. It's not encryption.

So, we're working in a on a version that does some shuffling of the chunks and on the like deterministically but uh non-predictable in a non-predictable way. Uh what we call non-linearity leaking. So, basically, if you get a bunch of shards up as long as you're not close enough to the construction to reconstruction, you would not learn anything about the transaction. Oh, I forgot to say, again, this is not the come Thursday if you want to know more about concrete numbers in terms of latency or whatnot. The reason why we don't do those threshold decryption is because we're focusing on low latency for many applications and threshold encryption and decryption is not going to be negligible latency. Whereas, share sharding and reconstruction of a transaction takes like a nanosecond and it's a millisecond and it's ridiculously parallelizable.

Um then, we're still also looking into the economics of pricing the distribution of transactions. And um another thing that we found that was very interesting that discouraged us from doing threshold encryption and decryption is that most threshold encryption schemes rely on some cryptographic assumptions that are not proven and actually um we're working on a paper that disproves one of the assumptions, which means that effectively some of the properties of these threshold encryption schemes are actually broken. Um so, yeah, that was all. Thank you.

>> [applause] >> Do we have any uh questions for Alejandra? Okay, I have a question. You had um so, during some of the the claims, you said that, you know, at a assuming a 20% cartel, right, in the in the proposers. What happens um you know, as you would as you use that as a variable, right? So, what happens if you go to like Where do like how dramatically does that impact the 0.04% of the transaction value that you're protecting?

Yeah, that that's an interesting question. I mean, there's even there's even more deep uh considerations to be made there. So, um it it does increase it's especially increases drama It also depends on how you analyze it. So, if you do it again in a naive way, then it increases dramatically up to the uh 2/3 point because over there they control everything. But, actually um if if the attacker is already controlling more like let's say you have a consensus protocol that uh that is classical BFT 3F plus 1 model, you know, uh you basically move forward as as soon as you heard you hear about uh 2/3 of the participants. In that case, uh an attacker controlling more than a third of the participants in some consensus protocols can actually censor lanes. So, they're already controlling more than 33% actually gives you a 66%

control over lanes. So, um yeah, it that it I I didn't especially for the e-comp paper, I didn't want to get too much into that, but we get a little bit more more into that into the protocol's paper. Um but, yeah, it it it does get worse especially once you get close to that the more than 33% um And then what about the other way? Like, what about 10%? Like, how quickly does it approach zero when the cartel doesn't have too many participants? I I have not plotted that, so I don't know. I I'm sure I'm surely it's getting better, but I don't know how quickly. Yeah.

All right. Uh does anyone have any questions? Going once, going twice. Thank you, Alejandro. Thank you. Um may I please invite uh Chris and Tiago to the stage, I think.