Marek Moraczyński - Client Diversity - A Nethermind Core Dev Perspective

Transcript

from nethermind Team I'm a theum core developer and today I'm not going to talk about anything revolutionary it want be a hot conference topic like ziki cryptography magic or account abstraction instead I will be discussing something well known to core developers and to staking Community however due to importance of this topic and its current state I decided to talk about client diversity from a orev perspective in ethereum's early days a crucial decision was made to go with many protocol implementations I don't think there is a single cev who consider it a bad

decision so let's briefly talk about pros and cons of client diversity firstly having multiple clients is an effective way of testing new changes because if there is is any difference we will notice it immediately secondly having multiple clients allowed us to attract many C Core developers skilled in different programming languages and this mix of expertise has enabled us to come up with new and Creative Solutions to problems however having many clients can be

challenging if we had just one protocol implementation we could move much faster potentially developers are working more or less on the same thing same eips but in different clients in different Technologies so if we had one client and the same number of developers we could deliver more eips in the same time furthermore due to our use of multiple clients we encounter challenges in standardization of non-consensus critical areas such as Json RPC integrating can be complex for dab developers without

standardization dab devs have to handle all possible options from different clients to check uh error codes for example as shown in the slide managing errors related to insufficient balances can be quite messy nonetheless all these pros and cons aren't as crucial as the security benefits of client diversity with great client diversity there is no negative effect in case of consensus bugs what's more if we had just one uh ethereum implementation one team could manipulate the state three so account

balances as they wish so client diversity means being safe from Insider attacks however there are more benefits and let me explain it by example so in March of this year Marius V vien noed the attack on gly network and to be honest we don't know the motivation of attacker and I'm not sure if we should even call it attack however this situation is intriguing from a client diversity perspective so what happened Marius had been working on dos vulnerabilities in transaction pool and he found issues and he fixed them he prepared a PR but

obviously all ethereum clients are open source so someone noticed the fix analyzed the code and prepare the attack based on his findings as a result some notes started to consume lots of resources on gly network fortunately the attack stopped on some point uh and it was only gly test net not main net and the fix was released quickly however this situation shows that client diversity is not only about uh consensus bus but also about for example Performance related issues but there is there are more benefits so

imagine if you have uh your client and you find um security issue in your uh repository then if you fix that someone can notice your fix and prepare an attack before your release and or before people upgrade nodes so client diversity is the only way to mitigate such risks moving on to how ethereum proof of stake is related with client diversity etherum proof of stake rules clearly guide us on how we should think about client diversity we will require at least 2/3 of validators to be online and in consensus to finalize the chain

finality means that the chain cannot be reorganized and in simpler words final finalized block will remain in this chain forever so when considering proof of stake the the consequences of consensus bugs vary depending on the percentage of validators affected therefore it's really important to consider your client's market share I presented all possible options in the slide and let's go through them one by one before I start I've made one assumption here I'm talking about a bug due to differences in transaction execution like One op code was implemented differently in two

clients so as a result some blocks may be seen as a valid from one client perspective and invalid from another client's point of view so first row presents the situation when we had a consensus back in a client below 33% of market share in this situation the network will be still able to finalize resulting in no serious issues on the ire network stakers of affected client will get normal penalties as for being offline in normal healthy Network so roughly speaking it it means that if your validator was offline for one day you

would need slightly less than one day of operation to break even stakers of other client will earn rewards as nothing but had happened the situation worsens when we have a consensus back in a client between 33 to 66% of market share in this situation the network won't be able to finalize and stakers of affect their client will suffer due to inactivity leaks penalties will increase for them quadratically and without finality there are no rewards for all stakers um from attestations even those

who didn't use the affected client so this highlights that running minority client is much less risky and the last situation when we had a consensus backing a client above 66% could be catastrophic for the network because it would mean that we will finalize incorrect chain this situation would leave us with two unfavorable option First Option fix the B in super majority client and uh switch to the chain created by minority clients second option accept the BU as a canonical behavior and introduce the

same bu in all minority clients and switch minority clients to the chain created by super majority client so for super majority client users the first option would be extremely painful as it could mean mean that those sters will lose a lot of their stake even up to the whole 32 if in extreme situation surprisingly uh the second option would mean for them normal attestations as nothing but had happened however choosing the second option would be highly controversial perhaps even more controversial than Dow fork and in some

cases it won't be even possible to choose the second option for minority clients stakers the situation is better because in the first option they will not get rewards from attestations but not get any penalties as long as the minority chain will finalize and in the second option they will get normal pen penalties for being offline so my description here is a bit simplified overview however I've highlighted the most crucial aspects here there are strong incentives for stakers to diversify their infrastructure and to run minority clients what's more this table shows

that we shouldn't have any client above 66% and ideally we should have all clients below 33% and moving on to the current state of consensus client diversity a a year and a half ago vitalic tweeted that we had won the Battle of consensus client diversity and it's true perhaps it's still not perfect however starting from that point we have achieved an acceptable state in consensus client diversity there are no super majority client risks anymore both Lighthouse and prisp have uh are close to 33 to 50 %

range additionally we have three other excellent clients teus and loer vitalic had mentioned that it's time to work on execution client diversity and indeed we have achieved substantial uh progress in this field on the left we can see the state when vitalic wrote his tweet at that time G had almost 84% while all other their clients combined accounted for 16% only now the situation improved significantly at first glance the state of execution client diversity seems to

be similar to consensus client diversity so we don't have any clients above 50% we have two clients in 33 to 50% range we have other excellent Alternatives and ref is expected to gain market shares soon so we won many battles on client diversity didn't we but but there is a small issue here the thing is that regardless of Statistics presented to us we should always strive to understand how they are measured and the main point here is that on the previous Slide the number of notes was

presented not valid ators so we should mention we we should think about many types of client diversity for example blog Builders diversity or diversity in serving data to other peers however the most crucial for ethereum is validator diversity and it's often being confused with nodes diversity and of course you can run ethereum node to St your e and become validator however nodes have more use cases such as obtaining data for Json RPC or sending transactions privately what's more one note can be responsible for running zero 1 two three hundreds or

even thousands of validators so we need better data to assess execution client diversity and if stare commun Community is doing the best to gather such data for us so let's explore all the data that we have about execution client diversity so on the left once again we have nodes diversity and the problem here is that it's of course not validators and we don't know the methodology because the crawler is not open source on the right we have data about validators and as we can see this data

shows lack of client diversity G is the super majority client with 84% of market share nevertheless this data is also not perfect so we should mention how this data is being collected it's not onchain data but a survey involving big staking players so it's not possible to include home stakers here what's more this data doesn't change dynamically so you have to repeat the survey to gather new data and because of that it's really hard to maintain and very easy for human mistakes of course the effort of

gathering such data is super important because it shows that not all problems about client diversity are solved so unfortunately we lack comprehensive data on execution client diversity and in my opinion this is the topic that require far the research because we have critical thresholds highly important for ethereum and for stakers but we have we don't have any way to measure it so what is the status of execution client diversity well we don't know exactly however the available data allows us to draw several conclusions and I will

summarize it along with the entire presentation so client diversity is crucial for ethereum because it brings many Security benefits we have critical thresholds for client diversity at 60 uh 33% 50% and 66% there are incentives for stakers to diversify the infrastructure and to run minority clients we have achieved an acceptable state of consensus client diversity and we need better data to assess execution client diversity I didn't cover it during the presentation but blog Builder diversity

and diversity in serving data to other peers must improve currently GF nodes have the biggest responsibility in those areas thanks to huge effort from for example if stakers it seems that home stakers have played their part and some of them switch to minority clients I think we can correlate it with increase of nodes diversity based on the available data which is not perfect we can observe a strong preference for G among major staking players and last but not least we have made significant progress in client

diversity and we are going in good direction however not all problems are solved and that's all I wanted to say today thank you for your time for further reading and exploration please check out these resources if you have any question I I don't know if we have more time right now so if not feel free to catch me later thank [Applause] you uh we do have time so questions okay then we have a small break and then

we continue at uh uh 425