Diversity Implementation on Consensus level / Klaus Kursawe

Transcript

thank you and I love you too even as much as he does especially for coming here at this time of the day even though you probably are coded very hard until yesterday five in the morning you know this type um so yeah I'm Klaus I'm with Vega so obviously the most interesting thing I can talk about today is that Vega is no life and minded and people can use it and it's totally exciting so instead I will talk about policies which is very appropriate we are here at the institute for crypto Anarchy so what's a better Topic in an Institute for anarchism to talk about policy enforcement so next time I actually call The Talk policy for anarchists and maybe I get a really interesting

audience so little uh background on on who I am um I worked on consensus way too early when nobody cared I did my PhD on that topic in 2001 and then we tried to sell it nobody wanted any so I abandoned the topic I loved it but I figured at some point it should be something useful with my life that people actually use so I went into privacy Hardware security um started securing electrical power grid so if you want nightmares um invite me for blh and we can talk about the security of the real infrastructure that we all use um and then finally somebody had found a

business case for uh blockchains and I had caught on that actually it happened so I'm back now and as I said working with Vega on the in the plumbing department so I'm trying to make sure that below the ground everything which works right so that our great um Finance diet guys and UI guys can do their job and don't need to worry about the blockchain exploding um so that's enough about me let's talk about why we need validator policies so when Bitcoin started the good old days and sort of a big Cypher Punk vision is we have millions of students in their dorm rooms that secure Bitcoin and that's actually what happened and it worked and it flew and then it got really successful and being a miner

started being a business and the same is now happening with pretty much all other blockchain infrastructures so ethereum is trying very hard to keep the old vision and have a million of validators but even on ethereum it's a serious business so you now need serious people to do Mining and validating and once you have serious people doing serious stuff you get business decisions that maybe end up centralizing stuff so Bitcoin actually had this problem that at some point over 60 percent of the mining power ended up in China because that's where energy was cheap so why build a minor in Germany and where energy is expensive if you can go to China so there was a point that was in

the end thankfully resolved by the Chinese government by kicking them all out where the Chinese government essentially could have owned Bitcoin with one single law so that that's not decentralized um we have other things um or economy of scale we have regulation that some countries are just nicer to run a validator in that other some clients are easier to use than others so once people start serious business we actually have centralizing forces in there and um you know the screen fails are thankfully misari has just published a story couple of weeks ago that totally made my point they looked at a couple of major

blockchain implementations and how diverse they are on validators um so we see our lunch already 41 of all Avalanche validators are in the Amazon Cloud so if the Amazon Cloud goes down then um our lunch stops but even worse if you go by stake at 67 so if Amazon actually tries to own other lunch they already have all the hardware and that is uh through all the blockchains they locked looked at so we don't have the numbers for ethereum but from all we know it's not really perfect either so this is actually a total nightmare and if you look at things like client diversity it gets even worse geographic distribution or again

Avalanche somehow seems to make a good job in being at least centralized U.S and Germany together already have uh pretty much owned all of these blockchains so if US and Germany make a law we want you to send those certain transactions or please stop doing that either people can move very very fast or all these ecosystems will come to grinding Hall so we do have a problem and it's not very visible but it's slowly becoming obviously we need more diversity among validators and the whole all the centralizing forces we have um they're getting pretty bad and by proof of authority and I think I'm the

only person who does not use vitalik as proof of authority I'm going further back in history uh this is Leslie Lambert he actually invented our Fields this is a guy who coined the term Byzantine agreement who essentially invented consensus protocols um at least a Byzantine ones and even he already said well when I invented this and never meant actually active attackers I meant sort of random failures and as soon as you have failure dependency the whole model breaks so that's ridiculous what you guys are doing so even the founder of our field is telling us we we got it all wrong and um please do it differently and yeah we had I mentioned Bitcoin ethereum at an early Point decline failure where they found

out almost everybody is running the same client even though we have four um and the SEC has also tried to assist my point by essentially declaring ethereum in American citizens so congratulations ethereum he is your citizenship um so the first controversy and uh this is something I would actually love to discuss later on or that's a same enforceability so if I want a policy around say where a validator is how can I actually find out where validator is so of course they can tell me which is nice but they could lie if they see a financial incentive in this and we can never really for sure measure where validator is we can run policies

the tour people have actually done fantastic work in trying to find out where tour servers are but we can never be totally sure so my argument is try anyhow because not trying at all um because of fear of failure is just worse and my standard example is I know my door lock at home could be picked or probably is right now but that doesn't mean that I should just leave my door open and put my valuables on the street it still does a good job so even if we can't enforce it perfectly I'm just leaving it to Market forces leads to the slides we saw earlier and that's what nobody wants um interesting thing that came out in this conference there is work on ethereum invalid data privacy so how can

we have helped Valley data site where they are so um we now have two desirable goals that are completely contradicting each other but that's what makes science fun [Music] um so in implementing it uh easiest thing is economic incentive so you add diversity we give you more money we probably should do this anyhow but it's not uh the final solution so for one we have contradictory policies that I need to put down into one monetary award we have a validator business models that we don't necessarily understand so in ethereum most of the validators are now living by selling of mevs so how can I financially motivate you if your money

source is actually coming from the outside um so it is probably something we should do to increase diversity but it's not the solution so the solution that I want to talk about and discuss is putting it inside the consensus protocol so that if the chain progresses it actually itself enforces there was a certain amount of uh diversity in the validators so this is where um I probably lose everybody so that maybe even easier knowledge proof of competence that in the end you believe I know something but you will have to learn nothing or you will have an intuition why it works but it is always good for me um so there's a fundamental proof already done by Lampard back then that

uh if you have a finalizing protocol um you need less than uh so you can only tolerate up to a certain um of failures actually less than assert and the proof is um very simple unless it gets explained by me suppose we have three validators the two green ones and the red one the red one of course being the evil guy um so left green um hears from Red they now need to terminate because from their point of view right green could be evil so left green and red come to conclusion create a block right green and red same story right green uh C's input from Red sinks left green could be either creates a block with red and what we have is now two sets of validators that are only joined by the bad guys that have both

created blocks so if the bad guys send different messages to both to left green and right green um then we have a fork so this is why we can't Define realization and everybody is in trouble and if this is not single validators but groups of validators so the left green is 100 red is 100 and right green is 100 same logic works so the proof then is if I have a set of validators that can I have two sets of validators that have enough voting power to actually create a block they need to overlap in at least one honest party so I can't have a fork and then you can do some maths and you come and oh that exactly happens if the number of valid uh dishonest validators is less than a

third of the number of validators so this is very basic thing from 1980 um puckering us ever since now the idea of what I'm going to do is the same also holds if I go away from actually numbers and I say I want to be more flexible I allow you to write down all sets of validators that you want to be corruptable at the same time so say set a is all valid data so they're in China so I want to corrupt tolerate that all of China is corrupt even if it's 60 of my validators or all of Germany or all of the US so just write down all the sets of validators that I say they could be corrupted together they have

dependencies they have the same clients the same country the same whatever and then I can actually run the same proof and my original I can tolerate a certain of the validators turns into property of the set that if I write down all these sets no no Union of three of the sets must cover all of the validators if I have this I can do consensus if that's not satisfied um then my policy is to inhibiting and um I can't do anything so this is about a formula stop for those people who don't like formulas so what I've done essentially I went from the threshold model or the state model to a set model where you can freely write down all the sets of validators that um Can collude against

you and as long as this one condition is satisfied we can have consensus so now we can think of nice policies like um each group of code that has the same country or the same uh client implementation or less than 20 percent of the stake include against may be corrupted and I still want to have consensus there's some minor formalities there and um well the projector is very kind to not show you the formula so um they probably makes things easier for everybody that's the attempt to put latex on uh on the slide by the way anyone using latex here hello the LA stands for that's Lamport so that's the guy I mentioned earlier so

he not only invented Byzantine agreement but also the science tool that everybody is using so look him up he's cool um so we now have sufficiency uh uh um have um necessity so that was a condition that's necessary to have consensus is it sufficient and the fun thing is yes so if you look at most protocols like this is an a code line from now comet bft formerly tender mint and there you also have thresholds like two f plus one so wait until you hear f is a number of tolerated failures weight for two f plus one inputs and there are actually essentially three thresholds in this kind of protocols if you count longest

chains like ethereum form and we can translate all these thresholds into set properties and then just verify the set property in the protocol rather than counting so all tender men would need to do is give me an interface where they take out the two f plus one give me an external function where I can say wait for a set that has a property that here is if I have two of these sets say intersect in an honest party and for most protocols you actually have a pretty automatic translation of both the protocol and the proof so the good thing is if I switch into this model almost all the modern protocols still works so it's a relatively easy thing of course better still manually look at it afterwards but it's a pretty

straightforward transformation ethereum is a little bit more complicated because a Serum is a hybrid of several methods it still works um I don't have time for that now but I have a paper so if you pick me up later on I can send you a paper that explains how it works I wouldn't put it onto a Serial mainnet yet but I think nobody would let me anyhow so we are good there um so if you look at basically all the consensus protocols or all the different ways of consensus protocols out there which is my totally arbitrary choice of them um most of the finalizing we can do are longest chains we can do but we should talk and Casper we should really talk

before we put it into ethereum so this is one of my goals to get actually some of these hearing people to talk to me about it um so now we have arbitrary sets the next step is um this is getting a little bit unwieldy if I just write down all the sets of validators that I want to be able to collude uh against me and I already mentioned all the properties so that we then do uh more systematically we select a bunch of properties like geography like client implementation like a cloud provider and then we Define a policy around it like I want each of those properties plus 20 of the rest to fail and then still do consensus now the fun thing here is the formula I

presented before essentially gives me an upper bound on the policy complexity so we can now prove how diverse we can be and at which point I can't reach uh consensus anymore so I may may have to say client diversity is more important to me than geography so I drop geography if otherwise a policy gets too complex and that's of course the second thing I would love to discuss in since we now can have an upper bound on policy complexity we probably want a policy but the community has to decide which policies we actually want what which different vectors of diversity do we want to really focus on and where do we say this is nice if we can manage it but

if we can't manage it then nobody dies too or if you can't manage it then we definitely should look for more validator or pay minority validators more or find another way out um there's more research to be done but um yeah there's fun papers on other properties you want in the validator policies that um give me a lot of potential for future ease products denvers whatevers um so our part here how much time did I use yet perfect so parting some summary if we implemented the way we're doing now um we are in trouble our economic incentivation for diversity Works to

some extent but there again we have some forces like being paid by Mev or trying to put 50 properties into one number whereas it doesn't work we have a way to put policies into consensus level it is relatively easily implemented of course still needs to be done and as everything there once you actually start your software architect they will probably tell you the 50 things where it's not easy but on a conceptually research level it is easy and there's three things we need to discuss um one is which diversity policy we actually want the second one is measurement and enforcement of properties so how much do we want to trust the validator they say they're in

Australia versus the protocol actually verifies and we slash them if we find out they're not um any other thing I just learned here on the conference uh how does this interact with valid data privacy do we want validators to be able to hide their location and thus completely uh eliminate our ability to put them in based on their location do we need fund zero knowledge proof that they get relocation certificate and then we do everything in some zero knowledge part which then is fun to work for photographers again so this is open questions my goal is to put out there are possibilities to fix this problem um details like what policies what to do

about these things is something that shouldn't be done by a researcher but by Community discussion and of course I forgot to put my QR code I mean the QR codes a big security risk so there is none so you need to either write me an email or Twitter or um ask me in person afterwards thank you thank you Klaus our next presentation is in about five minutes any urgent questions [Music] foreign