 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 Vega protocol. That's a derivative trading platform that works on its own blockchain. If you want to know what exactly Vega does, there's a wonderful workshop tomorrow where you can spend one and a half hours playing with it. I'm talking about the lower level. So I'm doing blockchain research, MEV, fairness, and yes, diversity. In our case, tendermint, 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? So generally, why do we need validator policies? In the old days, when Bitcoin started, we had this beautiful anarchic cyberpunk 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 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. 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 is 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 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 a very bad idea. And if we don't have enough examples, so from other blockchains, Bitcoin at some point had vast majority of the mining capacity in China. So if China had not said, you guys use too much energy to 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 power in America. That's the United States, as I said, Ethereum is now a US citizen, so we have legislation over you. So congratulations, Ethereum, you're now a citizen of the United States. We had other diversity problems. Early Ethereum testnet, 75% of the validators had client code, there was a bug in there, the whole thing stopped. Solana, almost 30% of all validators run in the same Amazon cloud. So if Amazon goes down, then so does Solana, that's not really diversity. And if you go all the way back in history, Leslie Lamper actually invented the term Byzantine agreement already set. 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 way than it was originally intended by assuming failure independence. So we need to assume failures happen dependently, states fail, implementations fail, flashbots may fail or behave in a bad way. So we need definitely more diversity on the chain. One controversy 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 diversity, a validator can just lie about where they are. And that's true, they can, they can use a 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% enforceable 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 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 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 probably if you ask Netflix or Amazon, they're also pretty good at that. So it's a discussion that needs to be had, but my opinion is even if you 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. The way we normally do this or the first idea to implement policies is by economy. So Ethereum is very heavy on slashing. If you 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. That has a couple of problems. My favorite one being MEV, and we have to mention MEV here. With MEV, we don't know what the 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 they live generally of bribes. 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 fund financial instruments that can outsource flushing risks. And if it's just economics, then I have a higher incentive to cheat. So it's one approach, definitely is one's error in our toolkit, but it's not the end solution. So that's why we want to implement diversity on the consensus protocol itself. And to get there, I need a little bit background on consensus protocols, and there you see how old I am, because this is papers from 1984, so the impossibility results probably predate everybody in this room, or almost everybody. And the worst one is, it's actually bugging the whole community since 40 years by now. It's called Fisher Lynch Patterson, and they proved that consensus is actually impossible. The end, let's all go home. What they more precisely proved is no deterministic asynchronous protocol 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 the 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. The first way to cheat is, it says asynchronous. So if you use a timing assumption, you can get around it. This is what tendermint is doing, for example. The bad thing is, if you guess or your timing assumption wrong, then bad things, you get very inefficient. The second one is probabilistic. 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 the timing assumption or what was invented by Bitcoin, essentially, and it's now also partially used by Ethereum. Why terminate in the first place? If I have a longest-shame protocol, I just run it at some point, it's good enough, but technically, you never really terminate. Now, after the merge, you do, but technically, a longest-shame protocol never finalizes. You always could theoretically roll back your transactions. So this is the three ways we got around this. That gets us to the consensus map. So we have essentially three approaches. We have the randomized approach, the partial synchronous approach, and the longest-shame approach. And they all have nice properties. So both committee-based ones are finalizing, which is great. Different timing assumptions. They are disadvantages. They don't scale as well as the longest-shame protocol. Every validator, they need to talk to everybody. So if I try to run those protocols with 40,000 validators, everything will explode. So this is why people still use longest-shame. Now, the reason why I'm actually going to all of this, 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. For longest-shame protocols, 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 GUSPR, we need to talk because GUSPR is a pretty complex beast. It works there. I'm just not sure nothing explodes if you would implement it. So this would be a very good idea to actually have a small discussion. So what we want to do is call generally adversary structures. So normally, as you saw in these protocols, you have specials like only one-third of the validators may be corrupt or in longest-shame, half of them. And we want to get rid of this. So forget about specials, 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 unfortunately, we also have some requirements. We can't just say I want to tolerate everybody going bad. So there's some limits what we can do in there. And if we look at the committee-based protocols or also the Cusper part of Ethereum, you usually find somewhere in the code something like wait for 2T plus 1 or 2F plus 1 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 validators and up to T traitors, 2T plus 1 and T plus 1. If you now go back in the protocol and if they say T plus 1, what do they actually mean with this? What do they want from this property? We have three things we need. We have a threshold where if I talk to that many validators, I know at least one is honest. Honest majority or 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 1 is replaced by any set on my list of people I wanna be corrupted plus one more guy. And for other committee-based protocols, we can just essentially take the thresholds out of the protocol, replace it with our set properties and we have pretty much automatically transformed that protocol into a more flexible model. 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 must not cover the whole set of validators. So if I say I have three countries and I want 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 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 the sets we actually can generate. How do we define actually who we want to tolerate to be corrupted? Longest chain protocols are slightly different. They don't have a threshold. The thing we have here is a leader selection algorithm and the longest chain rule. So what we can do here is change the definition of what the longest chain is. So if I have say consecutive blocks generated in America I can say the length of each block goes down in the longest chain depending on the number of blocks that were generated in the same set before. So first block generated by an American validator has length one, second block generated by an American validator has length 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 coming from another country will be longer because they just can't add to the chain anymore. So we can use this approach to also secure a longest chain protocol and have these corruption sets on the longest chain base. Parameter choice is still a little bit difficult. This is where we need experimentation. That's a general problem with protocols with all longest chain protocols like Bitcoin like old Ethereum, that's a lot of guesswork. So right now we have 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 you want to go to these generalized adversary sets. Gasper is getting even more complex because it's a hybrid protocol. So as I said, I think I can put this into Gasper. I could implement it in Gasper, but given the analysis of it is relatively complicated. We have no idea if the security proof still holds. So this is then future work, put it into Gasper and then redo the security analysis is Gasper still secure in the new model. And the last thing that's important is how do we manage the sets? So we have a very flexible way now to deal with validators. So it's actually too flexible. So what we want is actually an attribute based one. And I used this already in my example. So I used 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. And if we define it by these attributes, we give all the validators attributes, we can compute the corruption sets from saying I want an entire country to fail. We can compute back what is said that we are implementing algorithm. And then our algorithm can ensure that not only can tolerate half of the validators to fail or third, but in addition, an entire country, an entire code base, an entire flashbots client, whatever. The problem in here is, and I guess that's an issue with all diversity implementations, some more attributes I have along which I want to be diverse, some 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 probably doable. Adding a cloud provider, then it's getting messy. So the more attributes you have along which I want to be diverse, the more difficult it is to actually get that 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. So the danger we have here is that we need to avoid minority stacking. That's the validators say great, I have one validator that represents all minorities on the planet. So it's own operating system, a client nobody else uses, located in Vatican State. So such a validator 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 with 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 are getting serious diversity errors. We have a huge number of examples. Economic incentivation does sort of work, but it has its limits due to new financial tools due to different business models of validators. We have a tool that we can put things onto the consensus level that we can enforce diversity properties on that level. We know how to implement this for some protocols. 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 the drawing board, but we can complete precisely calculate now what kind of level of diversity can we have. And the legal question that comes up, which was also essentially one of the new motivations with Ethereum now being American, does it actually also help to give us a legal document or 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 be created only in America. I always need non-American validators, so Ethereum cannot be under complete American law. But that's pretty the wrong crowd to answer this, but interesting questions in there. So, thank you. Big round of applause for Dr. Harris. We have you for two questions. I think we have a lot to think about in terms of diversity and it's not as clear as just more clients or more countries or whatever. Do you have any thoughts on things like Lido that are building their own node operator steps and are taking it upon themselves to kind of build their own step in the way that they see an ever step looking? There's some people that say, it's so great that we have so many homestakers, but like you've kind of mentioned, a lot of people might not be taking their own infrastructure, they might just be running like a AWS. So, do you have any thoughts on how we can kind of economically ensure that there are diverse sets and 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 Lido on a very frequent basis, so they can't completely take over, they have an upper bound on how much control they can have. 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 the more people are joining Lido, the more weight in the consensus people get that did not. 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 the validators that add 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 that add diversity, but they also would earn more money, so after a certain size, it just doesn't pay off to grow much more. So it can be implemented, 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. Well, is there any, one more question maybe we have room for one last? Very good. Yeah, thanks for the talk. Is this for a team also applicable for distributed validators? Like I think it will be difficult to get the community to be around having something that is not cryptographically sure. It's cryptographically asserted that it validates in some country, but I think this could maybe lie, could be applied to distributed validators, like there has to be networks or over or per state working on. Haven't thought about that yet. So probably you could make it on a second level. I would still hope that it gets into Ethereum even if you don't know exactly where somebody is that we prefer semi-perfect policies over 100% cryptographically assured ones. I don't see a reason why it couldn't be used with distributed validators. Maybe it gets a little bit more difficult to define than the policies 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 those different sets. So how do I combine this? I think if I get in a distributed validator, I get third one. Should be solvable. I don't see a fundamental problem, but definitely needs to be worked out what it 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 part that is still a lot of work.