Sreeram Kannan 🛸 Increasing the Observability of Attestor Censorship

[Music] today I'm going to talk about rever it's the name of a gadget we've we proposing for censorship observability in ethereum why is censorship important right I think we we all know this but I'm just going to take a couple of minutes to say this so censorship is about um you know you want to get transaction you want to get transactions included in the blockchain and you want to be protected against all kinds of economic attacks for example you're running a liquidation protocol you know you may get liquidated if you're transactions get censored so there is economic reasons to worry about censorship resistance there is credible neutrality you know you want your protocol to not depend on jurisdictional cons considerations different participants may have to adhere to the jurisdictional constraints but together the protocol should not have to take a dependence on one geographic region you also want this property I call Meta sensorship resistance what is this normally we talk about censorship resistance as though it's a property to only users of the platform but I think smart contract platforms like ethereum have a more generic sense of censorship resistance which is even more important maybe which is that developers building on top of this platform cannot be censored so imagine somebody's running a social network and you know one of the big features of blockchains is immutable open API access to other builders to build composable open Innovation on top and you know what if you know the rollup developer or somebody or the blockchain nodes all censor any new deployments new smart contract deployments on top or calls to these new contract new smart contract deployments on top so as to make it unusable for any other developer to build new features so this is another important property that uh we need to worry about so when we're talking about censorship resistance we think of it as though it's some kind of a binary thing you know is the system censorship resistance or or not but really there is a Nuance to this which is what we call time to censorship resistance which is what is the time scale at which the system expresses the sensorship resistance property I send an honest transaction into the system which is paid enough base fee then am I going to get included in the blockchain how long is it going to take to get included in the blockchain imagine you have things like shortterm expiring options um or like a fraud proof period which gets over within the chart period then even though my transaction gets in afterwards I don't get any benefits so there's a time to censorship resistance which is what we need to be thinking about um another reason which you know one of the things we know from blockchains is when you convert these philosophical things to more measurable economic metrics there is a lot of incentive for different people to optimize it one of the important things is for example when you think about uh economic efficiency of let's say like an optimistic rollup you know in an optimistic rollup there is a settlement lag you know maybe a 7 days or whatever and inside the settlement lag people have to front the capital in order to do any kind of faster transaction so the capital efficiency of the optimistic rollup system is determined fundamentally by the fraud proof window and the fraud proof window is determined by the censorship resistance time so censorship resistance has consequences all across the Spectrum to permissionless Innovation to usability to Credible neutrality to Capital efficiency imagine you're running a stable coin protocol what is the over collateralization factor that you need to keep for the protocol it's dependent on the time to liquidation the volatility during the time to liquidation the time to liquidation is dependent on the time to censorship resistance so there is this temporal aspect of censorship resistance I think we should all think more about okay so you know the goal of ethereum is to be resilient Beyond majority trust with alic just gave a talk explaining where majority trust may break you know majority you know in the normal model you know many blockchains are built on you just trust that the majority of validators will be honest but in a sodony world it's not robust to assume that a majority of these nodes will be honest because who knows who they are so the goal is to build systems that are resilient to the majority of validators not being honest okay so there are really two two aspects when you're building a system in a blockchain or any distributed system there is safety which is that if something gets confirmed it should not get deconfirmed you know or reared so it's very easy so ethereum is built on this principle of uh slashing which is that if a majority of validators loot to attack the protocol you can actually attribute them and slash them so if there is a safety violation then you know they sign two conflicting blocks with the same block number and it's easily attributable and we can actually slash uh these notes however when you think about slashing for censorship it's much more difficult and intricate so imagine a majority of the validators collude and like not uh you know make sure the transactions are not getting included H how is the protocol going to know in a rigid way that this was actually happened because you know from the there may be users that claim that yeah I submitted my transaction and the blockchain validators may say I I didn't receive the transaction so there's a he said she said kind of a thing which is not there in uh safety violations so censorship is difficult to attribute in slash onchain okay so given this context what are the types of censorship that can actually happen there are two fundamental types of censorship that we can categorize into number one is proposer censorship you're a block proposer and you fail to include you know transactions that are valid and perfectly good for whatever reasons for legal reasons for economic reasons you took a bribe and you want to censor somebody whatever the reason may be so proposal censorship is one kind of censorship another kind of censorship is a tester censorship a tester censorship means somebody's proposed a block with certain transaction and you know I as an attester so in in ethereum you have this kind of a protocol where there is a chain of blocks being proposed and then ATT testers ATT test to these blocks and what you can do is you know ATT testers can all kind of collude together and not certify any blocks that contain certain transactions so if you want to compare these two types of censorship uh you know it's much much easier to solve for proposal censorship why is that it's because proposal censorship can be mitigated by having even a small fraction of honest proposal okay imagine that the network has 5% of honest proposal they will just follow the protocol include whatever transactions satisfy basic validity conditions and include them that is actually enough to solve for proposal censorship because if you have 5% of honest proposals you will get one in 20 blocks be built by them and the transaction go through there is a reduction in the throughput of you know censorship resistant transactions because only one in 20 blocks can comprise of censorship resistant transactions but still the fundamental fact and the time to censorship resistant resistance can be controlled quite significantly even by having a small fraction of honest proposals this is one of the important reasons why in the ethereum community there is an emphasis on home stakers solo stakers even if they're not in the majority small percentage still makes a big difference because proposal censorship can be solved using a small number small fraction of honest validators okay so but a tester sensorship is actually much more difficult to solve why is this um let's say 33% of the stake is adversarial 66% is actually honest okay but the 33% of the adversarial stakers are not just failing to include transactions from others they actually will not build on a block in which those transactions are included why are they doing this maybe they're doing this for legal reasons maybe they're doing this for economic reasons somebody gave them a bribe to say that hey I don't want this this guy to like refuel his collateral before liquidation occurs you know you guys all go and make sure that that transaction never gets included so this is a significant problem in um uh in in censorship okay so an example of an attested censorship is when uh you know when blocks are being built you know there is a block this uh this Uncle block that you're seeing here in dotted lines and nobody Builds on top of it you know and starts attesting only alternative blocks so now what has happened is there was a proposal which included the transaction it just never gets into the main chain and therefore it is as though it didn't exist at all so this is a big issue okay so what can we do about this can we try to enhance the observability of Uncle blocks how do we do this um so the first thing is if there is a certain fraction of adversary stakers and they're actually like um you know censoring these uh these blocks then what happens is if you are using any standard bu and and fall tolerant protocol you know a protocol which just like finalizes each block as it comes what will happen is this block will get proposed and will not get enough certificate and you know therefore there is not even a block in regular bft protocols ethereum actually has a little bit of a different kind of a protocol called Gasper in the consensus layer which basically has a layer of liveness you know blocks keep getting proposed they just don't get attested and finalized it turns out this is actually performs a vital function of observability okay so you know this is one of the kind of code designs behind the ethereum consensus protocol is that there is a layer of liveness and a layer of safety built on top of it and so you know you can start seeing that there is a pattern of blocks there's a bunch of blocks and then there you can see this proposed block which is not on the main chain and people have not voted it uh so actually this is you know this is already very useful however there is a problem the problem is if you see a pattern like this where there is a bunch of blocks and then there is a fork uh block you cannot attribute whether it is because of network latency that this block didn't get included or it is because of intentional sensoring because both of them look alike you know if this block came in and the nodes basically didn't observe the block and then they continued building or it might be that this block um was intentionally sensored how do you disambiguate between the two when you see a pattern like this so that's what the rest of the talk is going to be about okay so what we propose is this gadget called R uh which is a mechanism to solve for a tester censorship so the first point here is a slight change in the inclusion rule it may already be what uh most of the uh consensus notes use the transaction inclusion rule is when a proposer proposes a block it must include transactions from recent Uncle blocks whose transactions have not been included in the fork so you see a transaction and if you're proposing a later block you must include these transactions that's a rule okay and you can set some threshold you say like the fork transaction should have at least paid you know significantly over the base fee or something like that so that you know you don't have to force include every transaction but somebody who's trying to get their transaction in we need to give them a certain quality of service that actually they will get included so this is a transaction inclusion rule okay if you're running a client you have to follow this if you're using PBS you have to make sure that the relays will have to make sure that this is actually the case for the um uh the proposed blocks okay so now something powerful starts happening if you see a pattern like this and you see this transaction and then eventually in the chain that transaction gets included you're like okay you know these guys are not intentionally censoring because you know this transaction was eventually included they used the proposed inclusion rule and eventually you can see that um the transaction is included so you can infer or assume that it's because of network latency that this block didn't get included in the main chain however if you see this pattern where you see a transaction as an uncle block and then other blocks keep getting proposed and this transactions never included anywhere in the future then you can infer that the cost is a tester censorship okay so that's the basic idea you have this me pool rule which is that take extract the transactions which are paid Beyond a certain fee from reason blocks and then you you have to include them in your block if you're a proposer and this rule basically enforces a social consensus where by looking at the structure of the blockchain you can infer socially whether ATT tested censorship is happening or not okay so now how do we propagate this information so who's observing this and how do we propagate this information so one of the problems with any of these methods is we need a lot of nodes to be observing the blockchain to see for these patterns in order to establish social consensus that at you know censorships actually happening and one way to do it is you can start building sophisticated light clients which can enhance observability so what is the idea here you know a a slight variant of this like client rule is basically that you download and do sampling you know which is just to ensure that the block was available you download block headers should say download headers you download the block headers and Sample blocks not only blocks that are well attested but also blocks that are proposed by valid proposers but not attested you do this so now what's happening is everybody who's running a light client actually is seeing the pattern of headers this structure from the previous slide is transparent to anybody who is actually observing the blocks even though they won't see into the blocks and see the transactions they definitely know the structure of the block headers and at what times these block headers are released so this actually creates a very significant um incentive for um not doing ATT test of censorship because now like clients can bar testimony to whether censorship is happening or not so instead of light nodes only being checking validity for their own selfish purpose which is one way of using light clients here what we're doing is using the light client as a technology to enforce and monitor the commons the ethereum commons and make sure that validators are behaving according to the covenants that they signed up for so once you have light nodes B testimony to a tester censorship there is a strong social consensus that has been established on whether censorship is happening or not all of us know you know whoever is running a light client has observed the pattern of headers and can later open up the blocks and see that oh this transaction was proposed here it is not been included in the series of blocks and immediately you can use this to do slash ability for a tester censorship so this is really um you know and there are technical details in how you can use uh inactivity Le to perform slashing this is already uh well known in the ethereum research Community Okay so what this does remember I proposed not only that the concept of sensorship resistance is important but also we need to get the sharp time to sensorship resistance and you know one way to think about it is if a transaction is censored by a testers Beyond a certain time then you can actually slash these guys so that's what this this kind of a the the observability gadget rier gives you is this information that the uh a testers are actually sensoring is now widespread and available to everybody who cares to monitor the ethereum system via light node and you can use this to actually then establish strong social consensus to uh sensor sensor nodes what this does is along with an assumption that certain fraction of proposers are honest and will include transactions which are pay a certain fee you can actually start getting tight economic guarantees on censorship resistance if transactions get censored Beyond a certain point you can be sure that you know you see this pattern in the blocks and because you're seeing this pattern in the blocks you will be able to slash a majority of the stakers so with that I conclude the talk I just want to make one point here which is you know how this idea fits in with the ethereum road map one of the ideas in the ethereum road map is that even if Builders are centralized block Builders are centralized you know and high power block proposers can remain decentralized what we're doing here here is to take this one step further we saying even if block proposal are centralized to some extent only a small fraction are decentralized by having light clients to be highly decentralized who are monitoring the commons we can actually ensure that these bad proposals are held to task bya slashing so that's the idea of the talk thank you so much for the [Applause] time