On the impossibility of incentive compatible PoS protocols

Transcript

consensus participants and so as a rational blog proposal you might want to delay your blog proposal well obviously still making sure that you end up being part of the canonical chain um and yeah I guess the reason is obvious because you want to make extract more Mev um but we'll get to the details a bit more I want to first set up um provide a bit of context so blockchain Protocols are typically evaluated through the lens of the ability to maintain liveness and safety liveness being the characteristic of essentially just regularly adding new

transactions into the chain and then safety is about securing the position of those transactions within the chain so you essentially don't want once you put in a transaction it shouldn't go out again essentially and that's what we usually study these protocols through and what we're kind of arguing for in this paper is also to consider economic fairness I feel like I mean it's obviously this is not a um sort of new idea it's very implicit kind of um obviously we care about economic fairness because what that means essentially is we want economic fairness

amongst consensus participants um because if we don't have that um we'll have essentially centralization of the validation set over time and but it does help to kind of formulate that more explicitly um with the idea of um essentially the idea is to um model rational Behavior Within These protocols and um more specifically because typically in the in the consensus literature what you have is that you you model either honest or Byzantine Behavior so either you're totally honest or you're you can do

whatever the hell you want even to your own detriment and um essentially rational Behavior then maybe allows us to to if we model rational B Behavior we can maybe hint get to this economic fairness more explicitly in our modeling um and so what that essentially means is we want our protocol um to have um with the honest specifications of the protocol should be maximally profitable um so that the participants essentially have no incentive to deviate and to make sure that there's yeah otherwise a deviating participant can out-compete an

honest participant um now the the more metaphorical way of looking at it is essentially we want these beautiful um setups I think I saw David even here some earlier so he has a good setup um but we essentially want this beautiful homestaking to be maximally profitable and be able to compete with centralized or not net centralized taking but with professional staking institutions um and this is essentially what Peak Performance should look like that's kind of what we're trying to get at in a nutshell um but our friend Mev tends to have a say in these things and

um we've gone to love and hate it but essentially makes things a bit more tricky for Designing protocols and yeah the intuition again quite straightforward Mev accrues over time as users submit transactions and so when a block proposal um Waits a bit longer there's more transactions in the mempool so they can construct more profitable blocks Etc and um so and and what we then did in this paper essentially is um investigate the possibility for Block proposals to delay their block um for as long as possible while still ensuring they become part of the canonical chain

um what does this concretely look like in ethereum so here we have a slot um time is divided into slots in ethereum in 12 seconds long each and so the the honest protocol says that a block proposal should propose a block at zero seconds into the slot so right at the beginning now um when they do that like here roughly then the testers whenever they see a valid block they immediately attest if they don't hear a block they wait until the attestation deadline which is at four seconds into the slot and then they attest um but so here the blocks on time they see the block immediately and so they immediately attest business as usual but let me introduce you to um King Louis XIV he likes power and he

also likes my me and so he's wondering what he can do with this power that he has because essentially improve or stake block proposing is a monopoly it's a very short short-lived Monopoly but it's a monopoly nonetheless um and what he's basically doing is he's using the fact that there is this time interval from zero to four seconds that he can use to by himself time essentially because the testers they wait until four seconds if they don't hear a block before and only then they test so essentially here what he's doing is he's proposing so late

that he's just about accumulating 40 percent of the committee votes which is a threshold um let's not get into the fog Choice details but basically because of proposal boost you need to at least accumulate 40 percent um to not be re-argable by the next block proposal so what you want to do is you want to proposely block maximally late so that while still ensuring that at least 40 percent of your of the committee hears you in time for them to vote for you and that's basically the game and so what we then did in this paper is and I'm not going to go into the equations but we

kind of formalize this problem by modeling the value of time to consensus participants and it's essentially a game between block proposals and the testers block proposals propose blocks it testes vote for blogs and um the payoff for proposals is increasing in time so that's kind of trying to capture this notion of um yeah essentially Mev um making it so that time is valuable to consensus participants um and then a test is votes need to be correct and fresh correct meaning they vote for the block that ends up in part of the canonical chain and fresh meaning

they can't just vote five slots later because then they will be sure that they're voting correctly because in ethereum essentially your your votes need to be included within the next block for the a headboard to be rewarded um and so um essentially do you have this kind of trade-off where proposals want to wait as long as possible but obviously they need to make sure they're early enough and sort of the same Dynamic applies to the testers they want to wait as long as possible because that gives them more information which allows them to vote correctly but at the same time they need to make sure their votes are heard early enough for the next proposal to hear

them and because of latency in the network you have this kind of trade-off for for both parties and then in the paper we kind of formally show that a testers can coordinate to implement proposals acting at any particular time and what this means is essentially that any deadline attestation deadline chosen by the testers can could be in equilibrium to which then the block proposal has to kind of adhere um and in ethereum's case um practically speaking we have these consensus clients and when we download them essentially yeah the attestation deadline is at four seconds which does serve as this very powerful shelling

Point um but it could be something else potentially um and what's interesting about this model is that we've kind of we've introduced payoff functions and can model rational consensus participation which usually again like it's not the first time um that this that people think about rational behavior of course but um it usually isn't part of the way we model consensus um but since we do care about decentralization so much um it it might be an Avenue Worth investigating further and so this kind of timing game is a particular instance

which somewhat does hint at some neat abstraction but um I think yeah modeling rational behavior in these consensus models could be isn't is definitely at least in my opinion uh interesting to to look at further um and yeah that's kind of the the paper on the theory side um do read it it's um obviously a lot more detail and more formal in in the paper um but I want to now also talk about the empirical side because um what we the the second part of the paper is essentially us looking at the ethereum network and looking at potential timing games so are they worth

playing and um to what extent are they being played um and for to to get into that um maybe like a very quick run through of math boost um Barnaby mentioned it is mentioned it it's like I think around 95 now run um Mev boost and Meb Mev boost is essentially this idea of Outsourcing the block building that a validated usually does to some specialized party um and so we have these block builders that bid for the rights to build the execution payload for the proposal um and so the auction for the content of block n begins actually in slot n minus

one and so um as time goes on and new transactions come in the builders are able to build more profitable blocks and so they start bidding more um they start bidding higher because they can build more profitable blocks so they can afford a bit more for the right to build that block and so as time goes on we have an increase in bit and these bits are submitted to what's called a relay and the relay sits between the um the block proposal and the block Builder because it's essentially a trust facilitator if you will um and yeah I mean Barnaby was talking about it I mean there's this idea of

enshrining this to essentially remove that trust component of the relay um and So eventually then the proposal goes to the relay and requests the highest bid probably signs it and then the block is eventually released um we we did kind of we collected a few timestamps that I'll be talking about in a bit but so we collected more than 150 million bits over I think like roughly five weeks in March April this year and the first question we ask is um are timing games worth it and the answer is quite clearly yes and um I think the the absolute value was

something like .0065 each per second um meaning that uh yeah but I think the the more important point is not the absolute value but noting that it's a very positive linear relationship and so as time goes on um we can we can build more profitable blocks so time is valuable to consensus participants um and so yeah the TLD of this plot here we actually so what we did is we looked at all bits so all 150 million bits and um see how how they evolve over over the course of uh over time essentially um and then the next obvious question is

are these timing games being played right and so what we see here is that um we we look at different time stamps received at is when the winning so now we're looking at winning bids only winning bids um so here we see a distribution of the winning bits they're received on average roughly um just after the um the the what's it called the the new slot begins um and the legible we can maybe ignore for now and what we then see is that they're signed out which we use as a kind of proxy for when the blocks released because once the proposal signs a block they're kind of locked in

um the only way is that they could deviate is by making themselves slushable but basically what we see here is there's quite a large discrepancy between when a Block's received which is roughly on time the winning bits roughly received which is roughly on time and then when the blocks actually signed and released on the P2P layer and we did investigate this a bit in more detail in the paper but essentially the short version is that large staking entities such as coinbase and Kraken have a somewhat slow signing process so it's kind of internal latency if you will so they re they they request

the winning bid almost on time and then or like on average I'm talking um but and then for some reason it takes a long time for them to sign it and release it but the point here is that um what's going here ah so it's a so the the point is that timing games are worth playing and they are being played but they're not really being played consciously like the the intention does not seem to be let me extract as much Mev as possible and that's why I'm delaying my blog proposal um but um instead it's it seems to be mostly the the late blocks that we see

are largely um due to some internal latency and the point is because it's possible um this could of course uh change over time um I mean these entities obviously have reputation and so this and it's very attributable but obviously that's not a very um yeah good line of defense defense um to put it that way um so that's that was the the first part of of this talk um and I want to now talk a bit um about this impossibility of incentive incompatibility um

incentive compatibility and I mean essentially I'm gonna try and intuitively argue for for this claim here a proof of stake protocol cannot achieve economic fairness amongst rational consensus participants with heterogeneous resources sounds a bit constructed it is um let's kind of go through it step by step so that's the claim um first question what does fair even mean um so the way I kind of loosely use it here is this idea of we want valid datas that are performing good enough to be maximally profitable that's at least the

intention with which ethereum historically has been designed there's the idea is you should have some leeway of having sort of quote-unquote shitty hardware and not be punished to too severely for it and essentially we want homestaking to be competitive um now on the high level before going into the into into the specifics um given any time interval that a block proposal has so what I mentioned earlier the zero to four seconds essentially is a time interval that the block proposal has in which they can propose a block and realistically still become um canonical obviously they can also

wait a bit longer um but then they will likely just not end up part of the chain um and so given this interval of time a rational proposal um and a rational actor will propose as late as possible thanks to the Mev basically and they need to make sure it still becomes canonical um and so now the the point is that a sophisticated actor who will be able to do this better and when I say sophisticated I'm basically thinking someone with special know-how Hardware um fancy Hardware setups sophisticated P2P strategies to make sure that they can release the blocks from say multiple

positions in the P2P layer so that they can essentially reach more testers more quickly and the argument is that this is centralizing and obviously bad in the long run um and now a bit more specific um so any proof of stake system clearly needs a mechanism for determining um the the block proposals and because it's proof of stake um this random selection must be done explicitly um based on the stake distribution um of of its kind of bonded consensus participants I think so far so good

um so if we assume we have this um sort of sequence of block proposing duties so validator one is supposed supposed to propose block one validator two proposing block two Etc the question is how do we how do we move through this list of Duties um and the the the most obvious one is let's just cycle through it right um let's start with the first and then just go through it when that obviously runs into the obvious problem that um you need to be resilient to a adversary plus someone that's offline so you need

a way to recover in case someone goes offline um otherwise the protocol is stuck so we need to stay live um and so this is kind of where then time enters the chart um and what I some like Loosely called deterministic time in in the proof of stake setting so in proof of work we have this exogenous Randomness essentially fed into the system um that creates entirely different Dynamics but here because we have this on-chained pseudo-randomeness that we have or need um we need a way of staying live and so what we essentially do is we schedule these duties and we say if you don't

show up we're going to move on um but in this P2P setting you you can't it's not like a block proposal can only be valid in one instance um you need essentially this time interval um and in ethereum we have these fixed 12 second time intervals um and there's other ways of doing it the pbft type of protocols what they usually do is let's move on as soon as we can but if we cannot move in within some sort of timeout then we go to the next round anyhow and it's slightly different but honestly it's same same but different the Dynamics are exactly the same the block proposal can just like

max out that time interval until the timeout or in ethereum's case the the interstation deadline um and then now given this kind of time interval and the fact that we have a monopoly um of The Proposal um yeah we basically have this short-lived Monopoly which The Proposal can uh abuse by doing these strategic timing games and um again like I I talked about it and a sophisticated actor can can do this better um I think I'm running out of time I lost I'm not sure uh

um so maybe just to um this is again the the kind of Baseline statement I was making approval stake protocol cannot achieve economic fairness amongst rational consensus participants with heterogeneous resources um hopefully that statement makes a bit more sense now um I mean one should note like it's a very drastic statement and obviously it's a bit tongue-in-cheek the point is um the question obviously is also how bad is this problem like maybe the homesteaker can not do it as well but almost as good and how bad is it um but I think it makes sense to um to be at least conscious about these

Dynamics and appreciate the fact that proof of work is very different here to proof of stake and some if we could maybe somehow replicate the proof of work Dynamics um which unfortunately I'm not sure is possible um but yeah long story short I think it's healthy to think about it um and I mean there's a bunch of things what one can think and do about it potentially um usually most of these ideas have their limitations I'm not going to go through it because I think I'm over time um thank you for listening and yeah do reach out um and yeah thank you very much [Applause]

does someone have questions it's time put your ends up where you effectively time attack there where you have to do this time attacked there we effectively just attacked by time there [Music] foreign