Beyond Stake: Implementing Diversity Policies on PoS by Klaus Kursawe | Devcon Bogotá

foreign [Music] so let's try this again so I'm working on introducing diversity on the blockchain layer and the end goal would be to change ethereum but also other blockchains themselves to enforce diversity on that level as said I'm working for the weaker protocol that's a derivative trading platform that works on its own blockchain if you want to know what exactly Vega does yes a wonderful Workshop tomorrow where you can spend one and a half hours playing with it um I'm talking about the lower level so I'm doing blockchain research Mev fairness and yes diversity in our case tender mint but it's an approach that works everywhere and should also work on ethereum and that's the goal to have a discussion with ethereum developers how far can we drive this to put diversity onto the blockchain um so generally why do we need validator policies in the old days when Bitcoin started we had this beautiful anarchic cyberpoint uh point of view that we have millions of validators in the dorm rooms securing Bitcoin that used to work but now validating is a serious business and that has caused dependencies that has caused a centralization factors so some of the basic assumptions we had are wrong and Anna has just shown there's some very few validators that own an enormous amount of the ethereum share um share so it's not really that decentralized anymore so there's a couple of policies and some other works that I also would like to advertise as people actually thinking about a structural way to figure out what actually do we want from validators the bad thing is if you start with the same axioms you may end up somewhere totally differently so um this still needs a lot of debate but one thing that I think nobody needs to debate anymore is we need more diversity and centralization or an undiverse system is is a very bad idea and um if you don't have enough examples so from other blockchains Bitcoin at some point uh had a vast majority of the mining capacity in China so if China had not set you guys use too much energy get out if they just said get out and leave your rigs here then China would now own Bitcoin pretty bad idea ethereum has a similar problem that there's no so much validation in the power in America that the United States has changed said ethereum is now a U.S citizen so we have legislation over you so congratulations ethereum you know such as the United States um we had other diversity problems early ethereum test net 75 of Supply validators had a canine code there was a bug in there the whole thing stopped almost 40 percent of all validators run in the same Amazon Cloud so if Amazon goes down then so does Sultana that's not really diversity and if you go all the way back in history Leslie Lambert who actually invented the term Byzantine agreement already set um the whole threshold model just doesn't make sense that's not what I meant when I said Byzantine so we're even using his term in a totally different ways and it was originally intended by assuming failure Independence so we need to assume failure independently States fail implementations fail um flesh pots May Fail or behave in a bad way so we need definitely more diversity on the chain um one controversity in there and that's a discussion that pretty much always comes up when talking about this topic how about enforceability so if I say I want Geographic um diversity a valid data can just lie about where they are and that's true they can they can use the VPN so I can be in China and claim I'm in the US no problem there so there's a couple of things so a just because I can't 100 enforce a policy doesn't mean I shouldn't have it I have door locks at home I have friends who can pick those door locks but that doesn't mean I remove my locks and put my valuables on the street they still serve a purpose even though they're just 95 secure and we if we create a business case that at least honest people create diversity and dishonest people at least have some risk and need to show some criminal Behavior um to violate diversity then we have something it's not perfect but just giving up because we say somebody can lie about where they are that doesn't really help and there's some really fun research on finding out where you really are even if you're in a VPN and you probably if you ask Netflix or Amazon they're also pretty good at that um so it's a discussion that needs to be had but my opinion is even if we cannot 100 be sure about what a validator says who they are what codes they run where they are that doesn't mean we should just go home and say well then we all end up in China fine and we can just stop the whole thing um the way we normally do this or the first idea to implement policies is by economy um so ethereum is very heavy on slashing issue misbehave we may slash you so you better be a nice validator we can have positive incentives Like A diversity award if you run your validator from New Zealand we give you more money or something indirect like a delegated proof of stake if you add diversity to the network you're a good citizen more people stake to you you get more money everybody is happy um that has a couple of problems um my favorite one being Mev and we have to mention Mev here with Mev we don't know what's business model of the validator is anymore they don't make money by fees they make money by Mev extraction so paying them A diversity bonus is like paying police a small bonus in a country where the lift off generally of bribes um that's not the business model to get the salary the business model is getting bribed so economic incentives may not really work we have fun financial instruments that can Outsource flashing risks um and if it's just economics and if a higher incentive to cheat so it's one approach definitely is one error in our toolkit but it's not the end solution so that's why we want to um Implement diversity on the consensus protocol itself and to get there I need a little bit background on consensus protocols and um there you see how old I am because this is papers from 1984 so the impossibility results pre-pre-date everybody in this room or almost everybody um and the worst one is it's actually bugging the whole Community since uh 40 years by now um it's called Fisherman's Paterson and they proved that consent is actually impossible the end let's all go home um well they're more precisely proved is no deterministic asynchronous product coil can guarantee termination even if one validator may crash and this is a result we've been working around for the last 40 years so this is a reason why every consensus protocol is a bit messy because if it were easy we would run into an impossibility result there's others you can actually write papers with thousand impossibility results in the area which are a very fun read but that's actually the most fundamental one now of course we can cheat We Have Cheated that is why we're all here um the first way to cheat is it says asynchronous so if you use a timing assumption you get can get around it um this is what tender mint is doing for example the bad thing is if you guess or your timing assumption wrong uh then bad things happen you get very inefficient um the second one is pluralistic it says deterministic protocol so that's actually my favorite approach we just terminate with probability one which is generally good enough and then I don't need a timing assumption or what was invented by Bitcoin essentially and is now also partially used by ethereum a white terminate in the first place if ever longest chain protocol I just run it at some point it's good enough but technically you never really terminate you know now after the merch you do but technically the longest shame protocol never finalizes you always could still radically roll back your transactions so this is the three ways we got around this that gets us to uh the consensus map so we have essentially three approaches we have the randomized approach the partial synchronous approach and the longest chain approach and they all have nice properties so the both committee based ones are finalizing which is great um different timing assumptions their disadvantages they don't scale as well as long as chain protocol every validator they need to talk to everybody so if I try to run those protocols those 40 000 validators um everything will explode so this is why people still use the longest chain now the reason why I'm actually going to all of this um the technique I'm now talking about is actually very well explored for the two committee based protocols we know exactly how it works there uh for longest chain protocols um like the old ethereum Bitcoin Solana we sort of can make it work but we probably need some more statistical evaluation to be sure what we're doing and for gas per uh well we we need to talk because gospel is a pretty complex Beast it works there I'm just not sure nothing explodes if you would implement it so this is uh well it would be a very good idea to actually have a small discussion um so what we want to do is um call generally adversary structures so normally as you saw in these protocols you have thresholds like only one third of the uh validators may be corrupt or in longest chain half of them and we want to get rid of this so forget about thresholds they are boring what we want to do is write down explicitly all coalitions of adversaries I want to be able to tolerate if they are corrupt simultaneously so I could say I want to tolerate if a quarter of all stake plus an entire country goes corrupt independently on how many validators are in this country and for now I just write down these sets and say this is the sets I want to tolerate it's a pretty flexible notion we can later scale it down to make it more manageable then we want to modify the protocols to work with this and um unfortunately we also have some requirements we can't just say I want to tolerate everybody going bad so there's some some limits what we can do in there and if we look at the committee based protocols or also the Casper part of ethereum you usually find somewhere in the code something like wait for 2T plus one or two f plus one votes so this is where the thresholds come in and in pretty much every modern protocol there's exactly three thresholds they use it's n minus t for n value datas and up to T Traders two t plus one and t plus one if you now go back in the protocol and if they say t plus one what do they actually mean with this what do they want from this property um we have three things we need we have a threshold where if I talk to that many many validators I know at least one is honest um honest majority or is this is the longest I can wait before I can't wait anymore because everybody else may be corrupted so this way we now can replace the thresholds with actually sets so the t plus one is replaced by any set on my list of people I want to be corrupted plus one more guy and for the committee based protocols we can just essentially take the thresholds out as a protocol replace it with our set properties and we have pretty much automatically transformed that protocol into a more flexible model um we can do the same for the proofs although it's probably a good idea to manually check the proof afterwards but we can generically take a protocol that is threshold based and go to set-based version which is then much much more flexible which allows us to explicitly write down I want to tolerate all of these people going bad and there's some limits so the limit we need for committee based protocol we used to have a third of the validators can be bad now it's three of the sets I write down um must not cover the whole set of validators so if I say I have three countries and I want or one of them to be able to corrupt it doesn't work if I say I have four countries and I want to tolerate if one entire country goes down that works so that's our limits um on on the sets it's necessary and sufficient so we know if I satisfy this condition I can still solve consensus if I doesn't it's impossible so this is how we can compute what are what are the sets we actually can generate um how do we Define actually how who we want to tolerate to be corrupted as long as chain Protocols are slightly different they don't have a threshold the thing we have here is um leader selection algorithm and the longest chain rule um so what we can do here is change the um definition of what a longest chain is so if I have say consecutive blocks generated in America I can say the lengths of each block goes down in the longest chain uh depending on the number of uh blocks that were generated in the same set before so first block generated by an American validator has lengths one second block generated by an American value data has lengths 0.95 third block is going down 0.8 something so the more blocks are generated by validators in the same corruption set or say in the same country in this case the shorter they get so at some point just anybody got coming from another country will be longer because they just can't add to the chain anymore um so we can use this approach to also secure along this chain protocol and have these corruption sets on the longest chain base um parameter Choice is still a little bit difficult um this is where we need experimentation that's a general problem with protocols like with all longest chain protocols like Bitcoin like old ethereum that there's a lot of guesswork so right now we have um how many steps do I need until I actually trust that my block is sort of final it is guesswork it's statistical evaluation so this is what we need to redo now if we want to go to these generalized adversary sets Casper is getting even more complex because it's a hybrid protocol so as I said I think I can put this into Gaspar I could implement it in Gasper but given the analysis of it is a relatively complicated we have no idea um if the security proof still holds so this is in future work put it into Gasper and then redo the security analysis is guspaster secure in the new model and the last thing that's important is how do we manage the sets so we have a very um flexible way now to deal with valid data so it's actually too flexible so what we want is actually an attribute based one and I use this already in my example so I use countries what we want to say is I want a quarter of the stake to fail plus one country plus one implementation plus maybe one cloud provider Plus flashbots um and as if we Define it by this attributing with all the validators production sets from saying I want the entire customer to fails and then our algorithm can ensure that not only can tolerate half of the validators to fail or assert but in addition an entire country an entire code base um uh an entire flash Sports client or whatever um the problem in here is and I guess it's an issue with all diversity implementations more attributes I have along which I want to be diverse more validators I need to actually implement it so it's easy to say I want to tolerate an entire country to fail saying a country plus an implementation is pretty doable adding a cloud provider then it's getting messy so the more attributes you have along which I want to be diverse and more difficult it is actually get it implemented and I guess that's the same also in normal diversity in real life if I have a board of a company and I say I want more women on the board that's fine if I also want different ethnicities handicaps whatever then at some point I need a very very big board to accommodate all of this um so the danger we have here is that we need to avoid minority stacking that the body data say great I have one value that represents all minorities on the planet so it's its own operating system a client nobody else uses located in Vatican State um so such a valid data may get an undue weight in the system if you're not careful how we Define our sets but in general what that gives us now is I can give validators attributes and rather than saying a third of the validators can fail I can say everybody with a certain attribute is allowed to fail and the discussion we need to have as a community is then what attributes are actually important is it more important to have geographical diversity is it more important that client diversity where do we want to set the priorities and which diversity aspects actually in the end less important so that's my parting summary already so plain blockchain implementations um are getting serious diversity errors we have a huge number of examples economic incentivation dusts sort of work um but it has its limits due to new Financial tools due to different um business models or validators we have a tool that we can put things onto the consensus level um that we can enforce diversity properties on that level we know how to implement it for some protocols um this is proven this works ethereum is a bit more complex it can be implemented but we still need a security proof and the last thing is we can also calculate the limit on how diverse we actually can be so we have a mathematical way to prove this is the maximum amount of diversity I can get via the consensus layer if that's enough that's fine if you need more then we need to sit back and maybe combine consensus with economic incentives or really go back to his drawing board but we can complete uh precisely calculate now what kind of level of diversity can we have um and the legal question that comes up um which was also essentially one of the new motivations with American uh with ethereum now being American does it actually also help to give us a legal document her argument does it just make us technically more secure or are we also now legally more secure by saying well there are no blocks that can create be created only in America I always need non-american validators so ethereum cannot be under complete American law but that's praise the wrong crowd to answer this but uh interesting questions in there so um thank you for two questions okay great talk um clearly a lot to think about in terms of diversity and it's not as clear as just you know more clients or more countries or whatever um do you have any thoughts on you know things like Widow that are building their own node operator sets and are you know taking it upon themselves kind of build their own stack in the way that they see a diverset looking um you know there's some people that say oh it's so great that we have so many home stakers but like you've kind of mentioned you know a lot of people might not be taking their own infrastructure they might just be running on AWS so do you have any thoughts on like how we can kind of economically ensure that there are diverse sets and you know do you have any thoughts on people that are going ahead and doing this themselves like Lido well one thing with this approach we could actually say that Lido is an adversary set where we need blocks to be generated by not light or on a very frequent basis so they can't completely take over they have an upper bound on how much control they can have um the approach generally isn't economical so if it makes a lot of monetary sense to centralize this it's not stopping it it just gives you less weight so um the more people are joining light always and more weight in the consensus people get that did not um you can link this with an economic incentive so if you also use the same approach for the leader selection algorithm then you can also say um the validators at diversity get more block proposals so they make more money so that at some point also an economic limit on how centralized you can be so it probably would be a combination that both by consensus enforcement you say I need validators at diversity but they also would earn more money so after a certain size it just doesn't pay off to grow and uh grow much more so it can be implemented it's the only problem again is if you have too many access among we want to be diverse then we run into issues of implementability all right thank you so much we are heading for the next talk or is there any one more question maybe you have room for one last there you go yeah thanks for the talk um is this 4A team also applicable for distributed elevators like I I think it will be difficult to wonder Community um sure cryptographically assert that evaluations of the company but what I think when this could maybe well I could be applied there distributed values like their SSP networks or opal or Thursday working on um I haven't thought about that yet so probably you could make it on the second level um I I would still hope that it gets into ethereum even if you don't know exactly where somebody is that we prefer see me perfect policies over 100 cryptographically you short ones um I don't see a reason why it couldn't be used with distributed validators uh maybe it gets a little bit more difficult to Define than the policies on if you have two levels I mean it's a similar thing already which is a problem that hasn't been completely solved yet in ethereum I have two protocols that both have different thresholds and there's different sets so how do I combine this I think if I get in a distributed validator I get a third one uh should be solvable I don't see a fundamental problem but definitely needs to be worked out what that means and if the proof still goes through so the main thing is you need to still prove everything still works and that's a Parts it is still a lot of work well big wrong Round of Applause [Applause]