Rethinking Censorship Resistance: A Rateless Sharding Txs Approach

Transcript

Thank you. Thank you. Hello. Yeah. Come on. Let's keep it light. Yeah. Bear with me. Just five minutes. >> Almost done. >> Yeah. So, yeah, welcome everyone. I'm going to be talking about censorship resistance at say. So, some of the people here has been talking before about censorship for security. Well, >> for the purposes of their product in the case of say we're doing an L1 and we want to make sure that our users can have censorship resistance on whatever they want to say >> for that. This is the only more convoluted slide but you don't need to understand most of it. It's just for whoever is interested in that. The point is say like many chains is a multiconcurrent well the new version of say has multiple concurrent proposers which is good for censorship resistance.

And here's an example of a protocol that's multi multiple concurrent proposers. We have four proposers and they all propose the block these values and then they agree on in this case the value zero and value two to be included in the chain. And so that's how you can get censorship resistance. So because you don't depend on one proposer, right? Okay. >> An example of a chain that's not multiple concurrent proposer. And I chose this example in particular is this one here where there's a still four values being proposed by different processes, but there is one leader that is the one that selects which of the values end up in the chain. So that leader can censor you at least for the amount of time that the leader is the leader, right? Which is in many cases

enough. And that's what that's uh what leads to what I call the meta-opies dilemma. So most some of you might be familiar with the blockchain dilemma. Um this is why I call the meta properties dilemma. And basically what it says is you cannot get um goodput or like um basically useful throughput in your chain or slashreasonable pricing depending on where you put the burden in the user of the system. Low latency for your transaction and censorship resistance. And let me justify that. So if you want reasonable pricing as a user for your transaction and low latency, then you just send the transaction to the next proposer, right? But you don't get censorship resistance. That proposer can censor your transaction. If you want reasonable pricing and censorship

resistance, then you keep sending a transaction to the next leader, but you don't get low latency because the first end leaders or whatever might censor the transaction. And if you want a long latency and ship resistance then in a multiurren in a multi- concongurren proposer setting you send the transaction to all the proposers but then potentially all the proposers might include the transaction and your transaction appears end times and somebody has to pay for that and it's you know and that's why if you pay for that then the pricing is not reasonable. you pay too much fees, too many fees and if the system absorbs that price which some systems do then the goodput of the system is not very good right it decreases by the amount of times the transaction is included so this is a problem that many chains are facing and um here is an example of some of the

chains falcoin in terms of sooie after falcoin and hideera apart from say uh falcoin interestingly is also multiple concurrent proposer which is a lesser known fact and in the case of falcon su and what they're doing is they're absorbing the price so the user never pays for duplications. In the case of Hideera, actually interestingly, the user pays for it and that's how Hideera protects from you know unreasonable duplications. So basically DOS resistance um and also interestingly even though this issue exists the way to they protect from this in these chains is through taster RPCs. So actually the RPC is the one that can censor not in the case of fcoin though. Okay, what's happen? Um and so yeah this is

where we stand at the moment and what we propose at say is to shart transactions. So basically very quickly the what what happens at the moment is if a user wants the sensor resistance then he needs to send the same transaction to all the proposers and then all the proposers might include it and so the goodut decreases by uh an equal factor of the number of the replication factor and the fee is also the multiply by that same factor. What we propose at say is to sh with rateless encoding the transaction at the user level if he wants to depending on what's the census resistance requirement that the user wants and then instead of sending all the bits to all the proposers you only send the one of the shards to each of the proposers. And so what you get is

the same level of censorship resistance um but you only pay for uh a very a much smaller margin of the fees. And how much you pay for? Well, here is um one of the results because I'm running out of time. Um but here's u an example of depending of course this depends on many parameters. I'm simplifying for five minutes. Um but in there's of course some metadata that you need to include in the for some security purposes in each of the shards and so you get better benefits the greater the transaction size or the batch size uh that you are sharding at once and so as intoically we reach basically the replication factor of just one transaction size uh for censorship resistance.

So that's all. Thank you. [applause]