A DAG-Based Mechanism for Fairer and More Decentralized Reward Distribution | Devcon SEA

[Music] [Music] yeah thank you for the introduction and thank you for coming to the session this afternoon it's the tail end of Devcon I hope it was really nice for you and I know we all a bit tired so I'll take it slow uh and show you some of our results so the talk is titled Fair rewards for more decentralized ATT testers uh I'm replacing one of our Coors who unfortunately they couldn't make it uh but I'm really excited to tell you about our work so why do we need uh decentralized ATT testers so validators are the ones who participate in proof of stake in ethereum uh as part of their duties sometimes they are asked to be ATT testers so you can think of it as the swarm of people who are making sure that the chain comes to consensus um you have thousands of people uh speaking in every round every every 12 seconds they cast votes and it's really really important for these votes to remain as truthful and as unbiased as as possible there are many many mechanisms in the protocol uh that would horribly break uh if the attestation layer was was not in a in a good shape and so we need these votes to remain truthful uh which means we also really need to ensure that the voice of these ATT testers uh is secure and heard uh the paper discusses uh an attack which I'll present in the in the next section uh essentially trying to show you that the mechanisms we have today are perhaps a little too brittle uh and so I'll show you how to how to fix that or at least a possible uh Way Forward uh most of this talk is adapted from the paper that we released earlier this year breaking the balance of power this is Joint work with rusbe who was supposed to present today uh news R Casper my colleague and Bart so let me start the talk with showing uh one of his attacks that may endanger let's say the health of the attestation layer uh it's a somewhat simple commitment attack um yeah and if you if you don't know what a commitment attack is it's it's sort of an umbrella term we use to describe any attack that looks like this somebody deploys a smart contract or some kind of commit M or threat uh to try and warp or modify or hijack the incentives of other validators to to do the correct thing so I'm I'm trying to incentivize people to to do the incorrect thing for my U let's say benefit uh usually this is a rough pattern but usually it looks like this so there's an attacker who commits to a certain course of action for instance via a smart contract uh the victims as a result of the smart contract being published uh need now to adjust their behavior if they're rational it might be more um let's say incentive compatible for them to to to deviate to a different action and what what happens as a result is this really coordinates the victim's Behavior towards um yeah just it induces the outcome that the attacker wants to happen in the in the first place so there are many interesting questions on on this like there's many ways that this reappears um there's questions Also regarding the credit ility of a commitment this matters a lot for the attack to be to be successful but in our space we don't La ways of making such kinds of credible commitments for instance via Smart contracts all right so to describe the attack a little bit uh I need to give some of the basics of our consensus mechanism which is called Gasper um the consensus mechanism is basically built from two components there's one component which is the finality service that's known as FG the friendly finality Gadget and another component which is the availability service which is uh lmd ghost and so on the chart here you can see that the chain progresses uh there's a part here which is highlighted in yellow which is the finalized ledger so every so often we come to consensus over yeah this is the prefix of the chain we have Economic Security on um yeah on that that the the this prefix will not change in the in the future so this this is like very very robust uh let's say finality but we want ethereum to make progress even if we don't come to finality immediately and this is why we have this availability component so we have a live Ledger that makes progress and this live Ledger can diverge so we can have Forks because we're not finalizing blocks every slots so this allows the chain to to Fork once in a while so how is this uh constructed so to progress the chain we need to assign duties so we have our set of validators which are the people bonded with a proof of stake mechanism and we ask them to produce blocks so every slot we sample one validator to be uh the proposer and the proposer is responsible for outputting a block the block contains both user transactions and the votes of ATT testers and the attester votes they carry data relative to the two services that I described previously so FFG data what should we finalize like what should we try to make uh fixed and lmd ghost data which is where is the current head of the chain so lmd ghost is the service that allows the chain to progress there can be many Forks so the ATT testers need to give their views on where the current uh head is in their own view so in the good case this is what happens so the first proposer makes a block then we have the ATT testers in green who cast their vote on the Block they say okay the head is this the first proposal that released the block and then the second proposer comes in links to the block that was issued previous to them uh so the first one and includes the votes of the ATT testers so here all of the ATT testers are honest in green uh and the next proposal just simply includes uh the votes of the attestor so this inclusion of the votes allows us to yeah recuperate the votes on chain uh and do out uh the rewards for the for the ATT testers at the end of every Epoch so it's very important for these votes to be to be included but now let's describe an attack so in this commitment attack a proposer can threaten to ignore the attester votes if the ATT testers don't vote for the proposer chosen block so the attack goes in in a few steps uh the first proposer issues their block that's the one on the left uh the second proposer issues their block two linking back to the first proposal's block and the ATT testers of that slot are honest so this is the nine green votes that you see in the in the bottom left and they all say okay this is the current head and they get included by the proposer in the middle so that's the first step in the Second Step the proposer on the right the third one uh wants to reorg the middle proposal so reing is essentially trying to kick out the block that was produced by the middle proposal from the canonical transcript of the chain and so to do that this third proposal can commit previous to even this uh situation happening to say you have to vote my way and my way will be that instead of linking to the middle proposer I'm going to link to the proposer that's in the left so I'm going to try and reor the middle proposer and you need to vote for the fact that I'm right like that this was the head the rightful head for me to to build on so this block uh on the left and if you don't vote my way I'm not going to include uh the votes in my own block and so that's the threat that the proposer is making and what we show in our paper is that if the threat is issued there is a nashum where this attack succeeds where essentially all of the ATT testers that are supposed to vote uh in between the middle and the right proposer are going to want to follow um the the outcome that the that the malicious proposer is trying to to achieve which is rearing the middle proposer so it's a pretty simple attack it's really based on let's say very weak uh properties but it can do a lot of damage like reorg blocks is not so nice first because the middle proposer gets ignored so they lose whatever MV rewards are in his block for instance and second because yeah we lose a bit of throughput at the at the same time so these are really things that we we want to defend against even if again the the purpose of having this availability or live Ledger is for the chain to to make progress and potentially to to get into these situations uh yeah in addition the so the the testers that are ignored by the malicious proposer they lose their reward because they don't make it on chain uh in time right so in our paper we discuss this attack we also discuss some extensions uh we show that the attack can actually happen over multiple blocks uh where one proposer uh incentivize both the proposers before them and the ATT testers in the slots in between uh to follow some kind of yeah prescribed script to to reog uh a large amount of blocks this works when we consider fixed attestor sets so when the players don't rotate between rounds but in our current the players do rotate we have different ATT testers every every slots and so we also consider the attack when we have players that are that are not fixed we also show an attack that's a bit inspired by the selfish mining attacks where you are trying to destroy the progress that some of the players some of the honest players have been making by by being um malicious right so we have this attack which is potentially yeah a bug that we can fix uh and the way to fix it is essentially to decentralize the role of a proposer in terms of including these attester votes on chain and so we show how we can do that and by the same um fail swop uh fix the rewards and try to yeah save our ATT testers so how do the rewards work in in E proof of stake uh today the ATT testers are rewarded when their head vote so the the ghost vote the vote on the state of the available Ledger is both timely so the vote has to be included by the next proposal and correct so their vote agrees with the majority of the testers right we're coming to consensus so there's this idea that you want to vote with a majority of everyone else what we see here is that the timeliness constraint gives a lot of power to the to the next proposal right since they are the one who decides whether this timeliness constraint will be uh achieved by testers that gives them the tool to to make this credible threat of saying that yeah I know you want to be timely uh so if you don't go my way I'm going to to screw with your with your rewards and so how can we try to to make that um yeah less dependent on them here's a strowman ID we could say you know we could relinquish this timeliness thing and say the vote of the attester could uh be included on chain at any point in time so that would work that would remove the Reliance on the next proposer as the ultimate includer of the of the ATT testers but we do really care about knowing the timeliness of votes like we want people to give us our view quickly and so as protocol designer we also do need the attester to do a good job and to do that job as uh timely as possible and if we allow any proposer to include them then we don't know exactly when the attest votes would have been um issued so a solution to that is to have the next ATT testers vote on the timeliness of the of the current ATT testers so instead of having the timeliness property be only decided by the next proposer we can have a full set of aester voting on the full set of aester so essentially there's um this group which is the group of the same people that's like keeping each other uh in check and what we achieve via this is decentralizing the role of the next proposer so making such that the next proposer is not the only one uh who is um responsible for the for the timely inclusion so we achiev that by proposing this uh new mechanism which we call Dag based votes uh it's quite simple so the ATT testers at slot T issue their votes as they do today so their votes containing uh the head votes for lmd ghost source and target for FFG uh and then the ATT testers of slot t+1 will issue votes on votes so the t+1 ATT testers issue an object that says I have seen the votes from the following ATT testers blah blah blah blah blah um that gives you this dag it's really like a yeah twostep dag um and yeah so that gives you the dag and what we say next is that the dag votes so the ones on the on the right column uh the evidence can be included at any time and so now even if we don't have timely inclusion of the evidence if the evidence tells us that the attestor vote was timely we know that it was that it was timely and this is actually pretty nice because uh these votes have this evidence being able to be included at any time means that uh the rewards can also be given at any time even if the yeah in if the vote was was timely whereas today uh if the proposer misses their block the ATT testers that were not included in this blog that was missed uh lose their reward and what we really want is to ensure that the attestor are fairly rewarded for their work again in the spirit of um keeping this attester layer as secure and decentralized as as possible so a quick note on performance obviously these dag votes are a new object uh we can use the aggregation of signatures to make it uh a bit lighter but that does create overhead still uh you have to write these objects on chain so that takes space you have to communicate these objects on the gossip layer that creates communication overhead uh but there are a few ways that we might tell ourselves okay in the average case this is still potentially a good thing to have so in the good case where the proposer is honest and includes all of the votes in a sense the evidence is not required like we already have proof of the timeliness and proof of the inclusion so the dag votes uh we don't even need to have them uh onchain if a proposer is missing or doesn't include everything uh then you need to have this D votes and you need to have more of them the more let's say dishonest the proposer is and doesn't include uh the votes in the worst case you have you can have a pretty large object like this evidence can get large but we think it's still reasonable if this is something that uh doesn't happen too often so you can think of it as insurance it's something that most of the time you don't need and once in a while it comes in handy to to have in your back pocket and it can also serve as a as deterrence against these these attacks happening but there's more on this uh in the paper as well uh yeah that's it I made it four minutes to uh to go but uh thank you for listening check out uh most of our work on our website and find our paper on archive as [Applause] well so if you all have any questions you can just scan the QR code and um and write your questions in um the the first one which I'm going to read out so that even the virtual audience can uh follow along how much are the profit and the costs of the attack yeah so the so let's say the revenue of the attack uh if I can pull it off as the malicious proposal there's two things I get so first I get essentially the me of the proposer that I reor because I'll be the one including their transactions uh and capturing some of the me so I will take that from the previous proposal and I will also be able to get the source and Target rewards from the ATT testers who were not included by the by The reor Proposal so yeah to make it simple in the attester votes there's like these three things that they vote on head source and Target the head has to do with the lmd ghost source and target with FFG the head has to be included immediately but the source and Target can be included over many slots and the proposer that includes them first gets rewarded for it so if I manage to reor the proposal before me uh I essentially get these source and Target rewards from them where they should have got them so yeah that's the two revenues I get then the cost of the attack is actually only the cost of deploying the smart contract so it can be pretty small I can even maybe not deploy it on etherum I could deploy it on some rollup or something that's um even cheaper or another chain if the crit if the uh yeah if the if the if ethereum State Route can be verified there so so yeah the cost is pretty minimal the revenue can be pretty high I think we give some uh estimates in the paper let's say the per block is $100 something like this that's what you would get extra as a proposal and I think about $50 for the vote so maybe yeah $150 uh do you have some idea how often we would expect dag votes to be required um yeah so today uh many slots are not missed I think the missed slot rate is something like 2% so that's when we would need them the most most of the attestations are included on time like things are pretty tight so I don't think we would need them that much yeah so most likely not a lot and also uh again in the spirit of this works as a deterent even less if we have this mechanism in presence so so yes we commit to have this mechanism that's potentially pretty heavy and that leads us to using it less than than we need to uh the other question we have is how might an attacker threaten the testers uh so they don't need to directly threaten it so the attacker just needs to deploy the smart contract and ensure that the ATT testers know about it uh I think in the paper we discuss what happens if some of the ATT testers are just oblivious like they don't know that this is happening and they don't um yeah they they just don't know that the attacker is trying to uh to hijack them um so yeah simply deploying the smart contract and telling the ATT testers that the smart contract is there uh is sufficient for for the attack to to happen and um the last question is that is this compatible with the beam chain plan yeah that's I I was reading in a group chat that everybody's getting a beam chain question so I guess that's mine uh yeah it is compatible but maybe like to say I mean yeah it's obviously compatible because it's what I what I'm suggesting here is a is a pretty small change not small but yeah it's a change to the consens rewards maybe to broaden the picture here so the idea of beam chain is to to essentially go to like this single slot finality uh which is a little different from the current cons mechanism we have which is Gasper but I think there's a lot of intuition and mechanisms that kind of need to extend to this so if we have single s finality we have obviously like a a different um let's say rhythm in the chain like we finalize more often so things need to be even more tight so I don't know maybe yeah maybe once we think more specifically about the rewards for for ssf like we realize that such things are are helpful I think they should be helpful again this idea of the ATT testers checking the work of other attest I think is is an intuition that seems to reappear quite often so I would say will reappear for ssf as well uh we have two more questions which just came in uh given the attester set per slot is set at the start of epoch should we be concerned the main risk to be proposers uh griefing the block example folk the last slot of previous block to find the preferable Set uh okay let me on this one because the main risk not sure I'm getting right I see so yeah so the attest sets are decided quite in advance like not just uh in the slot before the one that you're proposing the schedule of attesting is decided by the randow which is decided essentially in the EPO previous to the current Epoch so I think it's actually pretty difficult to to do an attack where you try to find the most favorable attester set for for you as a proposer there are some thinking around okay if I can change the last slot of an EPO then I can bias the Rend a little bit but I think it's yeah it seems somewhat difficult to pull off in practice and the other question is uh to talk more about insurance and whether transactions have some amount of Economic Security before finalization right so Economic Security I would Define strictly as finalization so whenever you finalize you have the amount of stake that was involved in the finalization as economic security behind the the transaction that doesn't mean you don't have anything when the transaction gets onchain the more ATT testers are voting on the Block uh in which the transaction was included and the longer chain gets that's built on the Block where your transaction is the more you have confirmation so we have this work on confirmation rules uh which tells you yeah almost like a level of confidence that you can have uh before you get to the to the finalization but until I think until you finalize you you have zero Economic Security in in in that sense is how I would Define it for for myself I think that's that's a clearer mental model uh and the and the other question we've got is how tag votes distinct ATT testers who deliberately delay their vote if there is no timing reward uh yeah so if if I'm an attester and I delay my vote uh the dag vote evidence will say barnabe was not around to vote he will say yeah that vote is not part of the of the evidence so if I as an attester delay my vote uh the evidence will prove to the rest of the network that I was late to to do my my duties so I won't be getting the reward so so it it it is resistant to that