Censorship Resistance: How to Uphold Credible Neutrality

Transcript

okay censorship resistance or censorship resistance should I say very important topical and you know interesting topic so um why is censorship resistance important it goes to the core of what it means to be ethereum to be incredibly neutral as a settlement layer for the Intensive value and if we don't have resistance we don't have credible neutrality which means that we can't have legitimacy which means we can't have monetary premium and monetary premium I've been arguing for over a year now that this is it's really important for

the success of ethereum as a settlement layer for the internal value for basically two key reasons number one is that we need security and monetary premium gives us lots and lots of Economic Security and we also need economic bandwidth for defy uh and that's also um unlocked with monetary premium okay so can we come up with some sort of good definition of of censorship and it turns out that there is a very clean definition thanks to eip1559 you might not have guessed it but basically we have this idea of dynamic block sizes so we have a Target which is right now is 15

million gas per block and we have a limit which is two times that and we have these variable block sizes where on average we're using 15 million gas per block and what this means is that the the majority of blocks we actually have unused gas they'll have free space and so what we can do is simply say that a transaction is being censored if it's paying for the transaction fees it's valid it could be included in the next block because there is space but it's not being included and so there's there's all sorts of blocks that are coming in with different usage and in the first two if a transaction is not is in the mempool but not being included

then it's considered to be censored if the block is full that's not considered censorship right because there's maybe not space for that transaction and if there's no block if it's a so-called empty slot that's also not considered censorship and so if the transaction eventually makes it in this fifth block then you know what we can say is that there's been a two block uh censorship okay now it's very important in my opinion to clarify two different types of censorship a weak and strong censorship because they have completely different roots and problems and completely different solutions so weak censorship is this

idea that a transaction is Centered for a very small period of time just a few blocks and then eventually it gets included and so basically it's as if your transaction is delayed on the other hand strong censorship is when your transaction will never make it on chain it's like fully and permanently censored and you know that's obviously a much worse problem so in terms of the cause of these different types of censorship weak censorship is caused from the Block production process there's this whole complicated Pipeline with lots of different participants so-called block Builders block proposers relays and on and on and if the some of these entities

in the block production pipeline are censoring then you get some form of weak censorship on the other hand strong censorship stems from effectively a 51 attack on the Chain the economic majority the so-called attestas will basically not attest to blocks that contain a specific type of transaction thereby that they buy permanently preventing transactions from going on chain now in terms of weak censorship you know we have this ux degradation for for some subset of users like the transactions take a bit more time to to go in and so just to take an example if 90 of blocks are censoring then the inclusion time

will grow by roughly a factor of 10x and so um instead of having a one slot confirmation time which was 12 seconds you have a 120 second time inclusion time which is two minutes which is still you know significantly faster than Bitcoin but but not great another problem with weak censorship is that it's a vector for so-called toxic Mev uh whereby uh someone can try and extract more value from delaying transactions you could try and delay for example Oracle updates or you can try and delay the inclusion um of of Market orders like buy and sell orders to try and manipulate the price of a specific asset

but also very importantly weak censorship is a form of loss of legitimacy because the perceived the censorship resistance of ethereum is at Play Even though ethereum itself is not doing the censorship right ethereum can process transactions members within the ethereum ecosystem are censoring and that's bad for for legitimacy in terms of the problems of strong censorship they're pretty obvious right one is you lose permission permissionlessness and the reason is that you have to ask the sensor whether or not you know to Grant you permission to use the chain you also lose self-sovereignty because effectively you have to play by the rules of the sensor and so if the sensor happens to

be a government I don't know U.S government Chinese government or whatever it is then you end up with a U.S chain and a China chain and this is not what we want and you also lose credible World War III resistance because you know you've been 51 attacked and so we want the chain to be able to resist these attacks even in the worst of conditions uh such as World War III and the the solutions also completely different so for weak censorship we have fully Technical Solutions which basically try and improve the auctions that are involved in Block production there's two different auctions there's a so-called transaction auction and there's a block auction

and it's just a matter of incrementally improving them until we remove weak censorship on the other hand strong censorship has both a technical component and a social component and really what we want to try and do is to maximize the automated and Technical aspect and minimize the the social cost of doing these so-called recovery Forks from 51 attacks Okay so the next part of the talk is split in two parts one looking at solutions to weak censorship and then the second part looking at solutions to to strong censorship

so again weak censorship stems from the Block production pipeline so what is exactly in that pipeline we need to understand that before we can start addressing the solution so we have a user who has some sort of intent they go to an interface um with that intent the interface produces a transaction that transaction goes in the mempool it gets seen by a Searcher Searchers build bundles these bundles um get given to a block Builder which puts into a relay so to a builder um the the the builder then gives the block to your relay and then the relay will

give a block header to the proposal so there's these six entities in the pipeline and basically each one of these six entities could be subject to censorship so let's go through them one by one and see if we can convince ourselves that we can solve weak censorship so the first one is at the user level is basically rooted in civil rights if you have if you're in a in a jurisdiction where you have property rights and you have freedom of speech then as a user you should be able to own a private key and you should be able to make your own transactions and so you know if you don't have that for example if you live in North Korea then you know right there at the user level you're

going to fail uh the the censorship resistance the other aspect is the interface layer so we've seen you know metamask we've seen uni swap do do censorship and part of the reason here is because these are centralized interfaces so we need to decentralize them use things like ens decentralized domains instead of centralized domains like.com we want to be using ipfs we want to be using systems like the graph which allows you to do these queries on the blockchain in a more decentralized fashion so that's something that we can solve it's just a matter of doing the engineering to solve it

searches are not really a problem in the first place because their role is basically to insert transactions right they're gonna front run or back run or insert Arbitrage transactions but their role is not to to censor in the first place so that's not a big deal now I'm skipping the Builder and the relay because the builders are harder so I'm kind of walking going back from from proposes upwards proposes it turns out we have a solution to essentially completely remove the proposals from the equation which is called Mev smoothing and Mev smoothing is this idea that proposes are forced to choose the highest paying block at every

single round so right now a proposal can really choose which block to include on chain but with mev's moving they have to pick a very specific block relays is a temporary thing with something called Mev boost It's Gonna Last for you know maybe a year maybe two maybe more but eventually is going away with something called enshrined or native PBS so this this role will completely disappear and now we're left with the final boss which is the Builder how do we make sure that the Builder doesn't censor and here we have basically two solutions one is this idea of an encrypted mempool

and the second one is this idea of inclusion lists transaction inclusion lists and so in in this section I'm going to try and talk about Mev smoothing encryption and inclusion lists okay so Mev is moving what is it so we have the builders it's a at every single slot they produce blocks and right now the proposer has the freedom to choose whatever blog they want it could be a sensor block it could be an uncensored block so that's the status quo today and maybe smoothing changes this picture a little bit where basically the proposer is asked to rank the blocks by value so each block comes with a bid which is the

amount of money that the proposer will receive if they include the block on chain and Mavis moving says the proposal must choose the highest paying block and if it doesn't then the testers are not going to attest to the proposes block and the block is not going to make it Unchained so the proposal has only two choices either to not include a block at all or include the highest paying block they basically we're removing the discretionary power of proposals from the equation okay good so now let's move on to um Builders and here we have this idea of an encrypted mempool what is it it basically says that um when you encrypt sorry when you make a transaction first you're going to

encrypt it off chain you're going to have it be encrypted in the mempool and then you're only going to decrypt it once the transaction is included on chain so it looks like this you encrypt off chain you include it on chain you decrypt you execute these last three steps could be done in in in in in one slot and it happens on the chain and you see here where in a position where as a sensor I don't know what transactions I'm including on chain because they're encrypted and they only get decrypted after uh the the transactions go Unchained now why are encrypted mempools important and it basically goes to this this the

economics of being a centering Builder so there's there's three types of transactions that are that a builder could include in the block um there's basically transactions and that are a handicap to a sensoring builder and and the reason is that if I'm a builder and I want to sensor a specific set of transactions I basically have to abstain from extracting the the value that these transactions provide and so I'm at a fundamental disadvantage I have a handicap versus any other Builder that is not centering and this is good right because it's the highest paying blocks that win and so we want these block builders that are censoring

to be at an economic disadvantage we also have neutral transactions transactions where basically extracting the maximum amount of Mev is essentially trivial because the only Mev is the tip and so this includes erc20 transfers nft transfers if transfers and and these really don't provide much of a they're not really relevant in this in this picture of of censorship uh economics and then in the uh in terms of the opportunity to censor basically a censoring builder needs to have some sort of an edge over all the

other builders to be winning this these block auctions and there's two types of ways that you can have an edge one is to look at Arbitrage transactions which are basically transactions that are orthogonal to user transactions they're just inserted to do an Arbitrage between the real world of chain and the on-chain world and you have front running and the idea of of of of encryption is is to basically take all the user transactions and encrypt them and that that has two very positive effects the first one is that it um greatly increases the handicap for a

censoring Builder and the reason is if I don't if the sensor transactions are hidden within the non-sensor transactions then I I have a choice um if I if I really want to censor the the sensor transactions I have to censor all the encrypted transactions and so if there's only one percent of transactions which I want to censor that are hidden within 99 of other encrypted transactions then my handicap basically increases by a factor of 100 like two orders of magnitude which is a great thing and the other interesting thing is that it reduces the opportunity for censoring attackers to have an edge and the reason

is that sandwich transactions and then basically front-funding transactions are no longer possible because you don't know the content of the transaction as a builder and so you can't go front run these transactions okay final technique transaction inclusion lists so here the idea is that the proposer who observers observes uh some transactions not going on chain can tell the Builder I want these transactions to be included in my blog if there is space for these for these transactions and so basically it's a list of transactions and the Builder responds with a block

with the additional constraint that eating whoops that it includes the transactions that must be included if there is space so in this picture there is some unused gas some free space and so all the transactions in the inclusion list must go in this in this block and basically it's a way to to prevent against this very extreme Edge case where like even for example all the builders are censoring there's no competition um uh what whatsoever okay so I only have a few minutes for the second part um so I'll go quite fast

but remember that strong censorship is this idea that a hundred percent of the blocks are censoring a given type of transaction transactions just can't go on chain because you have a 51 attack and so what we want to be doing is to coordinate a fork um and here I kind of like these two emojis because there's a technical aspect with the fork and the knife where we need to be forking and we need to be slashing with the knife but there's also a social aspect which is that as a community we need to come together and coordinate the fork um so this is basically the the recovery of 51 attacks

um and there's the fork and the forking and the slashing involved okay we have a choice around when we do the recovery do we do a soft fork or do we do a hard Fork I'm not going to go through this um in detail but basically if you do a soft Fork you're quite constrained in what you can do because suffolks actually a form of censorship so it's kind of ironic but soft Forks are about censoring the sensor and so what can we censor we can sensor blocks from from the the attacker we can Center attestations and we can sensor exits and the nice thing about the soft Fork is that because we're very constrained

it's much easier to to come to consensus it creates a shelling Point as to what the next steps should be because there's only so many steps that you can take but it has disadvantages because it leads to for example the finality Gadget stalling for many uh weeks and months same for the sync committee and it could lead to very long executes and so the the advantage of hard folks is that you can do a cleanup you can re restart the system you can kind of reboot it with a clean uh clean slate and that includes rebooting exit finality and the same committees okay so let's just uh ignore this detail of soft versus hard fork for now

and just think about this idea of can we try and automate the process of forking away right in theory this should be possible because phone phone nodes or nodes in general are in control of the the social consensus and so if they can observe censorship then really we should be able to automatically Fork away from a censoring majority but there's kind of two fundamental limitations one is technical you need a so-called synchrony so you need your node to be online you need to be observing the mempool right you need to be observing transactions not getting in and you also need relatively low latency and not all nodes have this so for

example wallet like clients most of the time they're offline what about smart contract like clients well they don't have the ability to observe the mempool and so some type of nodes fundamentally will have to be manually updated and can't have this automatic technical forking process there's also social limitations to automatic forking the first one is um is was this a false alarm right it could be that there's some sort of of bug uh you know one of the clients is accidentally censoring do we really want to trigger like a very expensive uh recovery process for something which is

just a false alarm and will be fixed in a few days um are we ready for folk right if for example usdc has decided that they will choose the censoring majority then do we really want to collapse a large part of D5 and and and and risk a catastrophe if we're not ready and also there's a question around harshness we have the ability with proof of stake to heal by basically penalizing the attacker and like how harshly do we want to penalize the attacker um and that's not something that we can necessarily fully uh nail down just technically okay last set of slides

so basically the the strategy that I'm putting forward here is this idea of semi-automatic forking right so we want to some subset of the nodes those with very good synchrony they're online they're observing the mempool they they benefit from low latency to be able to automatically detect censorship and create a fork template right and they do this in two phases the first phase is the attribution phase where basically they're observing the ethereum chain and the Pittsburgh Network and they come to some sort of consensus as to which transactions are being censored and who is doing the censorship

and then there's this other phase which is the upgrade phase where once we've come to consensus on how we want to proceed who we're going to penalize etc etc um then we actually need to manually update at least some of the nodes that can't be automatically forking and then we also have this unwind period whereby um we we basically we we need the community to be ready to to to Fork off this this majority and in the case of usdc for example we need to give the community enough time to be able to redeem usdc for real usds and basically opt out

um of of services that wish to to to to censor and one of the things that needs to happen here is that things need to be very very slow and very um very structured so that you you reduce the amount of decisions that need to be done and one thing that might be reasonable is having these these basically these uh social forking points every four weeks um and so if we have an attribution phase which is at least four weeks and an upgrade phase which is at least four weeks then we have at least two months basically to to really fully prepare for these folks

fully unwind and to fully update some of the nodes that can't automatically Fork off in particular the like lines and that's it I'm very optimistic on sensitive resistance because we have the technology to solve weak censorship and we also have the technology to largely automate the recovery from 51 attacks and we only need the social layer to basically put a final stamp on these automatic Forks to recover from censorship thank you