Censorship and Privacy through Rateless-Coded Multi-Proposer Data Dissemination

Transcript

Thank you very much. >> All right. Well, hello everyone. Um, yeah, I'm Alejandro and I'm going to be talking about um some benefits that you get from multi-conurrent proposal. It's a proposal to get censorship resistance and maybe protection and privacy for some definition of privacy in multicurrent proposal systems. for that let me explain first what multivurren proposers are. So actually Ethereum resembles more a chain like in the bottom and this is um kind of like most chains a few years ago or four years ago

most chains would have resemble this nowadays chains are resembling more I think like kind of like the thing at the top and to explain the difference what we have here at the bottom is one leader so in every view of the protocol in Ethereum you have every slot you have one leader that has full ordering rights right he's the one who decides what's going to be the next block and then you have some round of vote team that is decentralized, right? That where more uh validators are involved. In a multi- in an MCP kind of chain or consensus protocol, you have something more like at the top where you have different validators proposing different um mini blocks or different proposals and then they get merged together into one block for this particular slot. And in the

case of this protocol um at the end the first one so v 0 and v2 are the ones that are decided and that composes the block. There are some proposals to make ethereum mcp. Um the famous ones have been fossil with inclusion list and most more importantly brakes that uh directly propose to have multiple proposals at each slot. Um and the reason why they're important is because they be they bring uh sensory resistance, right? And and in the sense that and maybe protection as well in the sense that if I'm a user, I don't rely on one proposer. I don't have to uh imagine I I see some trading opportunity and I send it to I send a

transaction but the next proposer can basically get me from me, right? That's why the whole flashbot things and TE's and whatnot. But protocol level, they can do that, right? Because they have full ordering, right? So thanks to MCP, thanks to multicurren proposers, I can send my transaction to multiple users and then I can um ensure that as long as one of them includes my transaction u I will be able to uh exploit that opportunity and even in that case this one proposer might not be so easily able to exploit my transaction because um it needs to include this block within some time limit in order to beat the other concurrent proposers. But so what I want to claim is that there's this like unavoidable trade-off between even in multic concurrent proposed systems there's this unavoidable tra unavoidable

trade-off between sensory resistance reasonable pricing of my transaction and low latency. And the reason is if I want to get uh censorship resistance and reasonable pricing what I do is I send the transaction to one proposer right uh what can happen is that this one proposer uh censors me and so I can try in the next lot with a new proposer but then I don't get low latency right if I want to get reasonable pricing and low latency then I only try once and then if that proposal doesn't include my transaction I just consider that opportunity trading opportunity perhaps I just missed it and I'll just try next time with another one for another proposer right but in that case I don't get sensory resistance and if I want to get sensory resistance and low latency

then I can send the transaction to all the proposers but then there's a possibility that all the proposers include my transaction and somebody has to pay for that because if nobody pays for that if that is free then attackers can exploit that right and reduce the goodput of the system the useful throughput in the system so if you can think for example if your system has 200,000 trans 100,000 transactions per second And as everybody sends the same transaction to five different proposers, then the good put is a fifth of that. It's 20,000 transactions per second. And so this there's a number of chains that are MCP. Um I should actually add Solana now here or say um um say Giga, Hera, Falco, and Ato. So they're all

multicurren processor. So they have to they have this difficult choice of what do they do? Who pays for the possibility of multiple transactions being included? And in the case of Hideera, they're actually charging users for that. So if a transaction appears multiple times, the user pays multiple times the transaction fee. Interestingly, even for execution, uh, which shouldn't really be the case because the transaction is definitely only executed once, but you should pay for ordering, right? They probably because I suppose I suspect they don't have multi-dimensional fees. Um in the case of Falcon at or Zooie which are systems in production, the user only pays once even if the transaction appears multiple times and I have seen cases of Falcon transactions appearing 10 times in the system and

only being charged for once. So it's an incredible attack vector, right? Why is this not a bigger problem in Falcon is um is is a whole different kind of of of reason but in Appto or Hera is not a big problem because transactions are being sent through trusted RPCs. So is the trusted RPC is the one that are the ones that are in charge of um dduplicating the transactions making sure that they are targeting a replication factor of the transactions um that is within the goals of the system. But as a user if you bypass the RPCs and decided to send transaction entirely to validators you could actually exploit this in the case of SUI and APOS and severely decrease the system severely.

Um so I like to see the evolution of sensory resistance in um kind of like this way. So first we have leader based consensus right is like uh what Ethereum has at the moment right with the slots and just one proposer per slot then the proposal to have multicurrent proposers I'm providing sensor resistance this is where I will place aftercoin then the realization that the it shouldn't be free to have the transaction duplicated it shouldn't come for free to the user and so charge users for sensor for uh denial of service resistance at the on the system side but then also realize that that implies that it's too expensive for the user to use

the benefits of sensor resistance um and in that case what we're proposing as say is to actually start the transactions so instead of sending the same transaction to so this is how it will work at the moment in suitors etc sol is if you want to exploit the benefit resistance what you do is you send the central action to multiple proposers right and as long in this case this user send to three meaning that as long as no more than two censors the transaction your transaction will be included in the next slot um the problem is this doesn't scale right the problem that I just explained what we're proposing to do with Sedna at say giga is to shard the transaction and send different shards to different proposers such that if enough

of them include the transaction they actually get the benefits of censorship resistance but because the shards are a fraction of the size of a real transaction the uh the cost of ordering that that amount of bytes is much lower and we actually approximate the information theoretic bound going to show basically this the nice thing about this as well is that it's completely protocol agnostic so it's completely a let's say like a clientf facing a userf facing um protocol so the user can decide what are the parameters that he wants in terms of censorship resistance pretty much like now right like the user can decide um in an MCP system he can decide to send a transaction to one proposer, to multiple proposers, resend

it, whatever. But now it can do that as well with parameters that imply the sharding. So how many shards in sense, how many shards are needed to reconstruct the transaction etc. Um the properties that we get of course are safety aliveness. So it's impossible to uh you know for um different proposers to reconstruct different transactions if they get different shards or something like that. Um but but in any case all the shards are being ordered. So there there even is the deterministic deterministic execution order much like in any chain of course liveness as well. So there's a number of shards after which reconstruction is uh overwhelm overwhelmingly probable likely. Um this of course is deterministically

uh the deterministic lime for eraser coding but we have a solution with rateless codes which are faster but they give you a small negligible probability of no reconstruction. In any case, this is something that um so if it is the transaction is not reconstructible, as I said, nobody can reconstruct it. So in that case, the user can just resend it or keep sending more relesss codes. And here's an interesting properties properties that actually when we started working into this, we started working into this to reduce that um problem of the cost of sensory resistance both in terms of goodput for the system but also in terms of like fee cost for the user.

But we start getting some nice properties because it turns out that because you're sending shards to different proposers, no proposer knows the content of the transaction. So you start getting similar properties that you get with encrypted meles for some uh applications because at the moment of ordering the transaction the shards the proposers do not know the content of it and it actually can be analyzed to exploit uh and to get me resistance and I'm going to explain that in a minute and also to get privacy.

Um what what I'm showing here is uh for some parameters again it has a number of parameters uh that I'm not going to get into details but how many uh what is the adversarial uh assumption that you have so how many proposers you want to tolerate censorship against you want to you do you think there's just one proposer that might be censoring you and you don't know which one it is is it that 20% of all the proposers um what is the cost of this transaction in terms of me so um how much me can be exploited if the transaction is reconstructed in in um before the transaction is included etc. But uh what I'm showing here is for some standard parameters as the well something interesting to

note is that actually if the transaction is very very small it actually pays off to just uh duplicate the transaction because it's so small and there's some overhead of metadata to identify each shard that it may not pay off to just split the transaction in small shards if the transaction is already so small. But this as very quickly as soon as the number of bytes in the transaction increases slightly it pays off a lot more to uh just um share the transaction to to get them the same amount of sensory resistance and as the transaction size increases in uh increases in size we our solution actually approximates the information theoretic lower bound. So basically you cannot get better um replication factor in order to tolerate an adversary

censoring you of the same size. Um of course the bigger the adversary that you want to tolerate in terms of sensoring your transaction it is the more that you're going to need to uh shard the transaction the the bigger the shards are going to have to be. But um in any case they always approximate the information theoretic lower bound for whatever adversary as the transaction size increases. And uh in terms of latency which is an important thing. This is as I was mentioning you get interesting properties that are similar to encrypted meles. Um in some in like a number of encryp solutions latency is kind of a concern especially now you know you have up a number of chains like say giga or or sui apps all of these chains are also

really focused on low latency and if encrypted transactions increase latency by a few tens or a few hundred millconds that is huge right and the nice thing about sharding with eraser codes and especially with reless codes is that the latency added to it is negligible we're talking here if you see at the y- axis um we're talking about one to three milliseconds. So this is like negligible and in some cases actually because of the reduction in transaction on on the broadcasting the number of buys that being broadcast to number of proposals is actually faster than just replicating the full transaction payload.

Um so I have said that Senna has provides this number of properties but I said that it depends on some of the assumptions right and um so let me get a little bit more into the details of how we tolerate an adversary that's trying to reconstruct the transaction so it's trying to get enough shards before the transaction is onchain so that it can see the content and try to exploit me out of it. So basically what is the me protection that this charting solution set gives you. So for that imagine we have a number of proposers some of which are correct they behave they're not trying to exploit me and they just get your charts and then just validate them and include them in the block and some that are evil and the evil ones the

rational ones what they're going to do is they are going to with decide whether they include the trans their charts the shards that they get for the transaction or withhold them in the hope that some other proposers will include the charts and they can download those charts and reconstruct the transaction locally and only then decide whether they include the transaction and in what order. So um of course um the user has one important parameter which is how many shards it sends and how many shards are needed for reconstruction. The difference between them is the slack. So how many shards you can afford to be censored. So if you send 10 shards and seven are needed for reconstruction, you

have a slack of three, right? Okay, you can have you can tolerate of two you can tolerate two transactions being um uh sorry two shards being censored but because still you still have uh eight that will be included. Actually this slide was three sorry. So in this case imagine there's one of the evil proposers that doesn't include your chart but you can still reconstruct the transaction but the moment the second evil proposer doesn't include the shard that you gave to him the transaction is not included. So you get a slack of one that's the slack of this transaction and there are two risk for me uh reconstruction. As I said the me um exploiting from the from the proposers as I said there's the the

me is exploited in this uh protocol when the transaction can be reconstructed by these attackers within enough time before it appears on chain. And so there's two ways that they can do this. One is withhold transact would withhold the the charge for one entire round of consensus which is the multi-lot delay that I that I just showed or actually decide that they're going to include their shot but only at the very end of the round of consensus and try and see try to to play a timing game. Try and see if they can see some shots before that and that's the within slot risk. The interesting bit is that they're actually at odds in terms of the properties that you want to so if you want to provide me protection against multi-lot delay risk. Um what you want to get is a high slack. So you

want to get you want to distribute a lot of shares such that only a few of them are needed for reconstruction. That guarantees to you as a user that your transaction will be included in this slot. But it also means that a small adversary has a high chance of reconstructing the transaction quickly within the slot. So it's easier for the attacker to reconstruct the transaction at the beginning of if it was Ethereum, let's say at the beginning of the 12 seconds and exploit that for me within those 12 seconds. So there's kind of like a dots. So let's look at things that we can do to alleviate this u trade-off between within slot delay risk and multi-lot delay risk.

The first one is what we call the ratchet strategy. So a problem that appears is um that in the naive protocol if you send a number of shards and some of them don't get included in this lot you're going to you need to send more slat more shards right in the next slot in order to include your transaction for in order to pay off for the ones that were not included. Um in a naive way you just choose randomly again and send some shards to some proposers. But of course, if you're a smart user, what you can do is uh what we call the ratchet strategy. And so in the ratchet strategy, what you can do is just learn from the fact that some proposers did not include your transaction and just not send charts to them, right? And if you and that means

that there's kind of like a punishment for these proposals that didn't include your transaction and that assuming a static adversary dramatically increases the probability that your transaction will be included in the next slot. So here's how the ratchet strategy improves the probability of inclusion. So in red will be the naive approach where you just randomly choose some proposers and in blue is the um the approach where you learn from the proposals that are censoring you and not send the transactions to them. So basically as there are more uh failed the slots in the naive approach you the probability of your transaction just not succeeding and being delayed farther um increases. Whereas in the ratchet

strategy, it resets to the original probability. The other thing that we learned and this one I really like because it's a really interesting rational property um is what we call pivot k. So another thing that um occurs is in this case there's two types of evil um participants, right? So we have a cartel here of three participants that are going to collaborate with each other, right? They're going to send their shs to each other so that they can reconstruct the transaction and exploit me together and then they share the ME. But occur something interesting occurs which is the one at the bottom gets its share of ME and also behaves correctly in the view of everyone else. So it gets paid

for the fees. It doesn't get uh punished in any way. So it's kind of like an asymmetric relationship with the other rationals, right? And so nobody really wants to be the one out of the cartel, out of the self-interested rationals that collude together in order to reconstruct the transaction to exploit me. Nobody wants to be the one that does not actually behave correctly because he can get punished. Right? This is what we call a p a baiting strategy in rational distributed uh game theory. Uh which is a particular type of punishment strategy and this already is a play with just the fees just the fees for the transaction.

But the fees for the transaction do not they are paid for every shard that is included whether that shard is important for reconstruction or not. And so um what we do is we exploit farther this property with what we call the pivot k bounty. The pivot k bounty means we're going to give an extra fee to the first k shards where k is the number of shards needed for reconstruction. So there are more shards included. they get the normal fee but they don't get the bounty. So that puts even more pressure on um evil participants to behave and not only to include the shard but to include the shard in a way that is meaningful.

Yeah. What uh okay yeah with that in mind uh here are some results. the if the takeaway from these results is the last column in the last table which basically says well actually the last row which basically says that in order to protect $5,000 of me risk so suppose you have a transaction where you're doing some trade that if someone was able to see imagine a trade on some AMM and if somebody was able to see that transaction and front run it then they could steal $5,000 from you and in that transaction using Sedna, using the pivoc bounty, uh using the ratchet strategy, etc. And in

a way that in and setting the parameters right, it only cost $2 to protect from the attacker. So with $2, you secure $5,000 and that skills, right? With five for $5 million, just $200 will uh will protect you. Sorry, just $2,000 will protect you. Um as future work we're looking into I kind of lied when I said that there was privacy and MB protection. The truth is if you get a number of shards that is not like if you're an attacker and you get a number of shards that is not enough to fully reconstruct the transaction in the normal eraser codes you can actually start learning information about the transaction. Uh we're working we actually have a paper

almost ready on providing nonlinear um decoding until you have the full decode threshold. So actually learning pretty much nothing about the transaction. Um so and really getting properties that are very very similar to uh what the encrypted meals give you while preserving the same latency. Um of course we're also another interesting bit is how you price this ordering this distribution of different charts and and yeah threshold attacks as well. So yeah that was all. Thank you.

So if you have have any question are there any questions? Nope. >> So if there are no questions thank you very much. >> Thank you.