Ethereum Foundation DevCon 6 - Staking & Validator Experience Track, 12 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

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

Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/beyond-stake-implementing-diversity-policies-on-pos/

We look at the challenges of implementing various diversity-improving policies on a PoS network. Economic (dis)incentivization is a popular approach, but can be undermined by non-standard miner economics such as (cross-domain) MEV or derivatives on incentivization. As an alternative, we outline an approach to include diversity support into the consensus level without requiring changing the basic functionality of the protocol by adapting the concept of general adversary structures.

Speaker(s): Klaus Kursawe
Skill level: Intermediate
Track: Staking & Validator Experience
Keywords: Staking policies,consensus layer generalisation

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

A

A

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.

B

um I'm talking about.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

A

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?

A

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.

A

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.

A

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.

A

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.

A

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.

A

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.

B

As if we Define it by this, attributing with all the validators production.

A

Sets from saying I.

B

Want the entire customer to fails.

A

And then our algorithm can ensure that not only can tolerate.

B

A

The validators to fail or assert, but.

B

A

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.

B

Implementations.

A

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.

A

Then it's getting messy. So the more attributes.

B

A

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.

A

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.

A

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?

A

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.

A

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.

B

This is the maximum.

A

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?

A

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.

A

So um thank you.

B

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.

A

B

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.

B

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.

A

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.

A

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.

A

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.

A

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.

B

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.

B

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.

A

B

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.

A

On um I haven't thought about that. Yet so probably you could make it on the second level.

A

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.

A

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.

B

Well, big wrong: Round of Applause.