[English] 以太坊去中心化、抗审查性和客户端多样性

Transcript

series of Open Source T development tutorials on GitHub our goal is to provide Junior developers with a clear in actionable learning road map for for blockchain d d development while offering Advanced developers a platform for communication in collaboration today we're so excited to have guar from nethermind join us to discuss ethereum decentralization censorship resistance and client diversity before all this session goes on I want to stress on the special claiming event at the end of the whole session everyone who registers on our official website

and enters the crack password will have the chance to share in a rap packet funded by our community this is a ZK based encrypted rap packet is it it is ensured by privacy and uh it ensures your privacy in security for all people so don't so don't worry about your your password or your privacy so um the most important question where is the password so listen carefully to this sharing session it will be reviewed by batara later now without further Ado let's welcome batara to give to give us a sharing about ethereum decentralization

censorship resistance and client diversity well welcome hello how are you thank you for the introduction uh hello everyone it's really nice to meet you all uh my name is Ahmed I'm an ethereum core developer with the nethermind team we're happy to be here uh in this community and I think I'm going to start sharing my presentation uh today I'm going to be talking about um ethereum decentralization censorship resistance and client diversity these are all uh in my opinion important topics that need to be covered uh and they are they touch uh the space that we are in uh in in a deep

way because like we we should the the whole premise of blockchain revolves around these three or like some some of these Concepts um so of course you can also uh follow me on Twitter for all the latest information around nethermind and ethereum core development um and starting about uh decentralization uh decentralization in the blockchain world we we should go back all the way to the origin of blockchains and uh uh uh and decent and the whole idea behind them the uh and and you will notice that the premise of blockchain and and

Bitcoin uh when it started was that it is decentralized in a way that no one can control what happens on bitcoin and thus comes the power of of blockchain and that's why it started with with something called proof of work and this guarantees that um not there isn't a single entity that can control the issuance or or the uh block production uh in the in the Bitcoin blockchain right that's the whole uh premise and idea behind uh blockchain and this is where the decentralization of Bitcoin uh comes in um move on moving on a couple

of years later uh vitalic bararan wanted to add programmatically programability to to blockchains and that's where ethereum started also building on the same concept of proof of work the reason was not that proof of work is to be sustainable forever but to use proof of work as a spping stone to decentralize the amount of of uh eth tokens that are issued in the beginning of and the coming up of the of the blockchain of the ethereum blockchain and that's why after uh a sufficient amount of time uh uh we had the merge

where where things where where block production instead of being the responsibility of miners became the responsibility of the validators and the stakers and with proof of stake we saw the rise of a lot of new Concepts and and and Technologies around proof of stake uh one of them is uh transaction uh staking pools and liquid staking protocols like Lio uh for example or rocket pool and also the rise of other staking Proto uh uh uh uh initiatives uh like centralized taking uh institutional

uh tokens like uh coinbase and uh binance Killin Etc and if you look at the graph of of uh the staking uh ethereum staking you would notice that Lio uh has a lot of dominance over the uh Stak amount of e but if you look at Lio itself what you will notice is that Lio itself is basically a whole bunch of operators more than 20 operators that the stake of Lio is distributed amongst these operators and all of them are contributing to the

validation and the staking of ethereum thus not a single single entity has all that stake so the real largest entity that is holding the stake most stake in in ethereum is actually coinbase which is a um a a huge Exchange in the United States right um whereas Lio as as an entity itself it's true that they control the majority but under the hood Lio itself is not a single entity it's actually a lot of entities and that's why it's it's it's sufficiently also you can say decentralized there is some centralizing enforces but they're not as

much as of those of institutional stakers like uh coinbase and binance moving on uh to so so what do we gain from okay so before I move to the next slide I want to talk about what do we gain from decentralization um well the most important thing that we gain from decentralization is financial sovereignty basically we the the the owner of the assets control these assets they don't lie under anyone's else's jurisdiction there is no centralized entity that can

control uh the uh assets uh uh moving from some account to another uh there is no centralized entity that that can block a person from spending his assets Etc that's the whole premise of uh sufficiently decentralized blockchain and that's where censorship comes in because like uh the United States of America has issued certain uh uh uh uh addresses to be blocked uh uh and that's an OPAC uh there is a list of ofac non-compliant uh transactions and certain uh uh uh entities on uh who are operating on the ethereum blockchains

are are blocking uh including transactions that interact with these uh uh addresses and as you can see in this graph looking into who's censoring and who's not censoring you would notice that uh most of the validators most of the stakers on the ethereum blockchain are not actually sensoring they don't want to censor uh uh ofac uh non-compliant transaction uh whereas in in um in in ethereum you have three uh entities that are responsible of plock production so we have the

validator itself and the validator can itself produce the block but for the validator to gain a little bit more extra money it depends on a concept we call PBS proposer Builder separation in proposer Builder separation we allow the proposer of the block to delegate the responsibility of building a block to someone else and we call these people Builders and to mediate between the proposer and the builders we have the relays so the relays act as mediators between

the proposers and the builders and there is reasons to that that I can go deeper into if if if uh everyone wants me to um B so basically most of the validators they don't care about censorship they don't want to censor transactions right um half of almost half of the relays or like to be exact 44% of the relays are are sensoring whereas still the majority of relays are not sensoring the problem lies with Builders since most Builders are sensoring there is less uh uh blocks uh on ethereum that uh are including those

uh sensor transactions as such certain actions are being taken by ethereum core developers and researchers to prevent uh these type of censorship actions to to be done I will talk about that at a later stage now one other important thing uh of of um blockchain resilience is is resilience right um not most okay so I will pay attention to the comments uh most of the comments are not in my native tongue so I will focus on the ones in English most of Builders are flash Bots no not necessarily um actually most Builders

are uh uh the the highest uh Builder as far as I know is called um it's called Uh rsync Builder no not this one I think the beaver Builder the beaver Builder is the one that has the most blocks because so basically how does a builder has the most blocks it has the most blocks because it proposes the most uh uh uh like uh lucrative or uh beneficial block to the proposer the proposer always takes the highest bed that the uh Builder uh uh submits uh no not blocks route let me double check it could be

blocks blocks route is a relay I'm not sure it's a oh okay there is a block rout Builder as well let me double check or there is there is actually a resource that on in the last slide of of this [Music] um yeah it's censorship charts yes here let me open it and I will actually share that um here here we go now this website is called censorship. piix it shows exactly the state of censorship and it shows uh historical

charts as well of censorship and here you we would see which of uh which relays are more sensoring and which relays are less sensoring right so some relays are fully sensoring and some relays are fully not sensoring and some are a mix of both now there is other another one dot okay dot pix do info no I guess not like that okay pixinfo yeah okay move boost. piix on this one we can

see sorry I switched out of the presentation hope that's fine uh uh we can see here oh there's the block flow and here we can see um most of the blocks are coming from blocks route Max profit or ultrasound o ultrasound has a lot of has a lot of those but if you if you notice the highest okay let's see the builders mostly so yeah the builders Beaver build has the most uh my Boost blocks

and and then Titan Builder and then our CC Builder these are the ones flashboot actually accounts for a very low uh percentage of of Builders now if we count the people who are not using M boost so some people are actually running validators and building blocks uh in their own machine not depend not delegating the block building uh to to Mev boost and thus getting Mev uh you would see that they account for 10.3% of the network so even if all of M boosts block Builders became sensoring then this 10% of vanilla

Builders will still be able to get your transaction in in a very reasonable amount of time uh that is possibly going to be censored right um now moving back okay is okay which part is rooked pool in so rooked pool uh can use any uh uh uh any M boost because like rooked pool does not have certain operators anyone can spin up a rooked pool uh node and the operator of this rocket pool node can choose which which my Boost relays uh or

uh uh relays to use and he can choose also not to use relays at all and actually build blocks uh uh like uh uh locally right so so ret pool can can actually also like it it it's it it differs uh I think you will have to look up certain charts to know what Rook pool in particular does right I think it's actually I saw it here not sure if rooked pool is one of them one second looking here so as you can see this is rooked pool it has 7.24k blocks and you can see that it's coming from

different relays red blue and green mostly red blue and green so blocks route uh uh flash Bots and again BLS rout um maybe a little bit of ultrasound as well right uh and a little bit of uh agnostic noses so there are some so again ret pool operators each operator can choose which relays they want to operate um they have the choice to do that yeah okay going back to the presentation do you know much about stake wise V3 if so could you talk a little bit about

that I'm sorry I'm not familiar with take wise V3 no um yeah maybe we can answer the question uh in the end of the speech okay I don't mind I don't mind the interruptions actually it's it's it's fine um now um so after we we looked at uh decentralization and we looked at censorship resistance both are property of ethereum now one of the important properties of a blockchain is resilience right that it is resilient to attacks to bugs to issues right it uh it's always

have liveness it's always producing those blocks it's always uh functioning without interruption right this is a very important property of a of a blockchain that is supposedly securing a lot of uh uh uh value um with of other coins or or any assets that are on it right and thus the the the ethereum researchers and developers were like okay now we have software that runs the E the the ethereum uh blockchain which is uh go ethereum and they were like okay but if go ethereum has a bug for example then

we will be in trouble and the liveness of of the chain will be affected as such they decided okay let's build other uh software that can also process ethereum blocks and run the ethereum blockchain and thus came parity that became open ethereum and then became deprecated and thus came nethermind and bezo and uh Aragon and aula that then was used to build ref right um and when when when ethereum also switched to proof of uh stake from proof of work uh a need arised for cl clients

so consensus layer clients because ethereum then separated the responsibility of consensus and execution based on uh uh uh based on different clients so now execution is done by EX execution clients and we call that the El uh clients execution layer clients and we and and consensus is handled by consensus layer clients um consensus layer clients like prism uh Nimbus lster Lighthouse um I'm sure I'm forgetting one Teo yes um and if you if we look at um at them so so why is it again

important that we have all of these clients that can run ethereum why can't just we have one well let's say that one of them has a bug what will happen is that the whole chain will be stopped just because this single client has a bug whereas right now if a client has a bug the chain will continue to process blocks and continue to have liveness it will be a little bit effective but not to the point that it will ever be stopped also if uh any of these clients for example had a bug in let's say issuance and someone could uh exploit a vulnerability in a client that

issues a lot of eth for example he can issue himself infinite he can minant infinite ether e uh ether for example then what would happen is that all of the other clients that are functioning collect correctly will be like oh no this is invalid I will not accept this block right and that's where the resilience come from and and each like I'm going to talk about execution clients because this is what the nethermind client is it's an execution client and this is what uh I'm more most uh comfortable discussing and if we look at what makes an execution client uh work is that has so many components it

has a database it has AVM and consensus part where it agrees on the execution of the blocks it has a pt-p network to communicate with with its Speers and it has also Jon RPC to communicate with the CL layer clients and as well as with the user if it if the user requested certain requests from the node and of course a lot of other components but these are like the main components that I can think of right now and each of these uh could have bugs or issues in them right and if any of these have bugs and issues there are certain circumstance certain consequences that could

happen uh that depend also on how much of this client has market share on on on the staking of ethereum so we will look into that now so there are examples of security issues that have happened before on on on on on execution clients and all clients so nethermind had a uh one one uh bug regard uh with um un 256 modulo uh that was not exploited but was caught before uh uh exploitation and if it had hadn't been caught someone could have forked

all nethermind clients out of the main chain and they would not follow the correct chain then um also there was a recent uh binance chain consensus bug that uh certain client had I think it was uh B go gu which is not maintained by the Go ethereum Team by the way and because of that and because like most of the validators running binance smart chain were running this client they went to the other client and they enshrined they they they moved this bug into the other client and B like

complete continued continued with the bug enshrined in the blockchain they did not fix the bug and revert all of these uh blocks that had the bugs in them um other issues some client had uh used to run out of memory one of them was NE mind like two years ago when it was still in its early stages um peer disconnected because of requests or response size uh database corre uh corruption which could lead to State corruption on the Node and thus it can't continue processing blocks and there was also a bug in gu uh and transaction pool where it could would consume uh all of

the CPU resources uh another bug that was in gu also there was limit on the Block size and uh in Json RPC I forgot to mention this one and and like G itself could have produced a big block that other GE nodes would not have accepted and this is why client diversity matters we caught this on on a test net thankfully we did this did not happen on Main net or would it would have had devastating outcomes right now so again the types of Securities security issues that could

surface you could have uh security uh uh issues in P2P Network for example and in the case of a minority client this wouldn't be a big deal um it it it it would just drop certain amount of like let's say a minority client has 20% share of the network then only 20% of the network would be affected whereas if there was a majority client and if I can attack this majority client through the peer-to-peer Network then I can uh uh drop more than 33% of the network and this has certain consequences that I will show at a later uh slide same thing

with database corruption if it happened to a certain uh client it could also lead to consensus issues so if it happened to a minority client it's a medium uh uh severity event uh a fix will be deployed uh no slash no major slashing will happen to the people who are running this minority client they will lose a couple of cents or dollars uh maximum unless until the the the bug is fixed whereas if a majority client had such a bug then it would be high or even critical uh if it reached to be a consensus bug same thing with evm and consensus and moving to Json RPC and transaction pool you can get uh again it

it is medium for minority client because it basically just uh stops a a small share of the network that is less than 33% of the CL nodes and it's high for majority clients that is more than 33% of all the nodes uh and validators that are running and now I'm going to explain what is the difference between uh uh what happened so depending on the market share right so if a client has a denial of service attack that uh and this client has uh a share below

33% then what would happen is that there is no significant impact on the Chain there are very small penalties uh that are incured uh to the people who are running this client but they are very very minimal that they are like they can be called negligible like in the cents or in the dollars they're not that much and impacts on the rest of the stakers that are not running this client are minimal nothing right if if a client that has more than 33% but less than 66% has a denial of service attack then um the chain will stop finalizing and

thus something like uh we call the quadratic in activity leak starts happening where uh these uh nodes start being slashed heavily by the rest of the nodes until they become back online and they start attesting again and the rest of the stakers stop receiving any rewards from attestation um now if a client if a majority client that has more than 66% uh has a denial of service attack then uh the same as above will happen now there is another issue that could

happen which is not a denial of service attack which is a consensus issue attack and if a consensus issue happens then if the client has more than 33% it can Fork the network and it will have a new Fork that that has this consensus issue but it will not be able to finalize this fork and the other Fork also will not be that the the other actual correct Fork will not be able to be finalized and both of them will be running in parallel both of them will be slashing each other in their respective forks and whichever and when the client with the with the consensus issue comes back uh to the correct chain uh it would have been all of the people who were

running this client would also be slashed the same as if they were uh had been attacked with the denial of service attack the real problem happens where a majority client has more than 66% and it has a consensus issue because here what happens is this client can then finalize on the incorrect chain and what happens would be is that you they either fix this bug and switch to the main chain or the uh cives like what happened with binance chain would choose to enshrine the bug and actually make the bug the

correct chain which is of course not advisable right or not the course of action that uh CDs would want to do but if a lot of people are affected and to only if this is the only way to save all of these people uh and all of the stake then then then we would have we we might have to make that choice I'm not the I'm not one that would be supportive of this choice but who knows what choice the cevs would would have to take right so we we try to avoid this future as much as possible we try to not mention this and we try to avoid this as much as possible and we try to tell people okay please diversify the execution client and the consensus client that you're

running so we don't have to uh have to resort to any of these issues now and so either so so now we are faced with this this uh dilemma of enshrining the bug or not enshrining the bug and if we don't enshrine the bug all of these people that got slashed will be affected but if we enshrine the bug uh the people who did not have the bug will incure little bit of of uh um a little bit of of slashing uh but it's it won't be as severe as uh um as severe as if we did not enshrine the bug right so that would be a big

problem this is this is basically what binance smart chain did it had to enshrine the bug which which again is not something that as caves would want we would want to do and we would want to try to avoid as much as possible that's why we always advise people to switch from ex uh majority execution clients um so right now uh we have some data from uh certain uh um staking pools and institutional stakers that tell us that at a minimum at a minimum if GI market share as an excution client is around 30% and at a maximum it's around 70%

because there is some part of the network that we are not sure of so we are only showing the data that we are sure of and the rest we're showing as orange we are not sure of nether mind as well is at a minimum at 20% and at a maximum at uh 59% bzo at 99.2% at a maximum for 48.4% Aragon and ref still has some work to do on uh uh this front now do we the same thing goes to consensus clients but consensus Slayer clients now most of people are running prism and uh Lighthouse and both of them

are under 40% I think both of them are like above 30 and the rest is distributed on Tio Nimbus and lster um yeah and as you can see this data is not very reliable there is a huge range as I said for example GI can be either 30.9% which wouldn't be bad or could be at 70% which is really bad right so we do we the data is very unreliable and that's why there are things that we are working on to fix this another thing is that we need to take care of or keep in mind is validator divver client diversity does not mean Builder

diversity does not mean node diversity each of these is different right so Builders use uh block building software and this block building software could be based on G if or or or any other client if this building software that is based on a single client is is is has a bug in it then all of the built blocks will become invalid in the eye of the chain and the liveness of the chain will be affected now same thing goes for I I already discussed validators uh in the other hand nodes are a different story nodes anyone can run a node you don't even need to stake to run a node right you can run right now you can can run a nethermind node or a get node or

whatever node uh alongside the CL client of course and you can query the network using this node you can connect your wallet to this node instead of depending on uh centralized entities like inora Alchemy etc etc and if you want to do that you should probably like choose whatever uh node software that suits to you best and you feel like comfortable running the be the most but it it also uh like uh node diversity also affects how the network uh uh uh like views itself right so if you're running gu and gu has a problem then you will see the

GU Fork if you're running nether mind and nethermind has a problem then you will see the nethermind fork etc etc so you you you should keep that in mind so large institutional uh uh players like usdc for example or uh any large uh decentralized applications when they're building they keep in mind that they have to get results of the state of the chain from multiple clients just to make sure that whatever transaction or state or log that they're looking for has been accomplished on all of the major clients and not only by a single one that probably has a bug in it um so for

example let's assume that you SDC mint happens on on G and invalid on uh uh um on nethermind or the opposite happens then then they need to take care of that or a burn for example happens on a certain fork and it does not happen on the other and the other is the actual correct one and they issue the money to the to the person who burned this usdc and then they can't really get it back later because the the burn did not happen and certain issues start arising right um now so what what are cevs and researchers doing to mitigate uh uh uh

these issues um I'm sorry am I going over time I'm just double checking it's okay just go go ahead no no time limits no time limit okay great okay good um so what are ethereum researchers and core developers doing to mitigate the issues that I've been talking about so first of all to protect again stake capture by centralized entities and staking pools this is a hard problem uh to fix and there are deflecting and multiple opinions about how to fix this problem so some ethereum researchers are

suggesting okay I guess what we're doing we're paying too much uh to these uh stakers and we should probably reduce the uh issuance or the rewards for stakers and this is the first research link that I posted on this slide uh the second research list is that other people are saying No don't touch the issuance curve let's look into correlation correlated attestation penalties so for example if a large number of nodes suddenly become online and they stop attesting that most likely a staking pool or an Institutional Staker going offline and instead of uh um like punishing them uh normally the

same way that we punish all of the uh stakers or validators that they that go offline with minimal uh uh attestation uh penalties then we will actually punish them heavily because they all went offline all at once and this could affect uh liveness of course any unlucky uh Staker that solo Staker that the problem with this approach is that any unlucky solo Staker that went offline at the same time as this institutional Staker or this uh uh liquid staking pool the they will they will they will be punished at as if they are part of that uh uh staking pool or institutional Staker um

but yeah now an other parts of research search are being done also on the censorship resistance uh uh uh uh front so some researchers are working on something called the inclusion list where proposers enforce on each other that they include certain transactions that are basically uh uh uh censored so when a proposer notices okay there are certain transactions that are being censored by others then it infor it forces the Builder to include them and if it does the Builder does not include them it won't allow this Builder to propose the block for it um same thing uh for uh apbs which is basically

enshrined proposal Builder separation this one removes the relay if you remember when I mentioned that the relays are important to mediate between the proposer and the Builder and basically apbs removes this the need for relays because they have been not the best s in ethereum and they have there have been a lot of bugs in and relays recently that are showing us we can't depend or rely on these centralized entities for ethereum liveness and since 90 a little bit less than 90% like almost 89% of all blocks are using myth boost and depending on those

relays to act properly then then probably this is bad if those relays start acting AC ing improperly or start going offline then the liveness of the chain will be affected as such apbs came along to involve the builders and proposers directly in a decentralized manner so Builders would actually start joining the consensus layer Network and start communicating with the proposers directly and this would be uh the solution without involving any relays um now the last thing that we also would like to mention is that about client diversity is that the only solution to client diversity is to raise awareness about the issue about this

risk if you run a majority client there is high probability that if this majority client has a bug that you are going to be lose a lot of money so don't stake with the majority client so we need to raise awareness around this concept and to be able to do that more nethermind has received the Grant from the ethereum foundation to try and fix the problem of unreliable data around what are validators running so what what we are researching exactly is how can validators publish the uh the clients that they are using the CL client and

the El clients that they are using uh on chain in an anonymous Manner and this is what we're working on in this research uh the research has concluded we're only working on um fine-tuning some things this is uh uh by the way uh Alpha uh information and you should expect updates on this front very soon uh the result of the research and which what we came up with we have used in this research uh a lot of cryptographic Primitives like zero knowledge technology um a homomorphic encrypt um distributed um uh not distributed uh sorry um dkg distributed key uh uh

generation a lot of Concepts right uh uh cryptographic Primitives that are very interesting very Cutting Edge we have used them in this research and we came up with uh multiple ways to accomplish this task uh so expect the results to be out very very soon um so this is the end of almost the presentation I would like to also bring your attention to our internship program uh nethermind has been asking people to join as interns to work on any project of their choice they can apply and if we find that they have um the the passion to work on these projects then uh they

get accepted and they start working on any project out of uh multiple things so we work on blockchain core engineering on the nethermind front uh nethermind client front nethermind research where we do these type of research that I told you just about uh and other types of research also with Lio with DVT Etc another mind security where we audit contract we formally uh contract smart contracts we we formally verify smart contracts we formally verify and audit certain protocols if if need be I'm not entirely sure about that last one um L2 tooling we also support multiple l2s and support their uh like Stark net optimism base rollups uh uh uh we have also a div

Ops and infrastructure team that manages uh um a lot of infrastructure uh that helps the other teams in our company and that runs uh a lot of the infrastructure that actually runs ethereum right now um Ai and ZK engineering we have also teams that are dedicated to uh uh look into such projects that involving Ai and zero knowledge so please um apply to the internship program join us we will be happy to have you um and yeah thank you thank you for listening and if you have any questions um um I'm all ears okay here here here is some

question in the chat box could you explain more on relays yeah sure so basically as a proposer uh what you want to do the the reason that you run my Boost is that you want to maximize your profit right and to maximize your profit you're you you basically say okay what I'm gonna do I'm gonna do an auction amongst other people or other or Builders and I'm going to see whichever gives me the most I'm going to take his block and I'm going to pretend it is my block and I'm going to propose it to the network right

and basically this this is part of the of the of of the protocol this is this is was built in in the protocol the reason was built in is because a lot of a lot of people started modifying uh um modifying client software like G for example to extract Mev themselves while they are uh like running their proposals so doing this we we made it that nobody needs to modify clients it's actually built in protocol and the proposer can just ask Builders to uh uh on their on their bids now so the proposers can ask builders for their

bids and the builders can provide the proposers their blocks and the proposer then can choose whichever block it wants to propose the problem with this without depending on the relay the problem with this approach is that the proposer can see the full block of the Builder and if the proposer can see the full block of the Builder it can then steal whatever Mev was going to the Builder and instead uh convert it and uh into into M that goes to the proposer itself so to protect the builders from these such attacks what happens that there is a mediator between the proposer and the Builder the

proposer uh asks the relay to uh for for the bids the relay receives the blocks from the Builders without actually uh propagating those blocks to the to the proposer it just keeps those blocks in memory and then it tells the proposer that this block has this header and it will provide you with this much money and then the proposer takes whichever header it likes and whichever bed it likes the highest bed of course and then signs this header as the one that it will be proposing on the beacon chain and publishes the signature on the

beacon chain the idea is that from because of this publishing on the beacon chain the proposer then can not propose a different block because it then will be slashed heavily on the chain because the slashing condition on ethereum is that if you double sign on the same slot then you get slashed and thus the relay then notices that okay this header is signed from from the proposer I can then um push uh the the the block the actual block into the beacon chain and propagate it to all the network so this this this setup allows the builders to bid on the Block on the slot that the

proposer wants them to bid on without having to reveal the block and at the same time the relay guarantees the the money that will go to the proposer that it's going to go to proposer to to to this much to the proposer right that it will pay this much to the proposer and yeah that's basically why we have relay okay now another question is why is minority client safer than majority client is it assuming social consensus will be applied if it happen so how will Social consensus enshrine the buug of a majority client no actually minority client is safer than a majority client because it assumes that social consensus will not apply and enshrine the bug we

do not want to enshrine the bug all Court devs don't want to enshrine any bugs right and if we don't have any majority client we will not have to right because what will happen is that all of them become minority client and if they have any consensus issues they will just incur really really really minimal like minuscule uh penalties which is just attestation missing attestation penalties um and thus it will become very like way better than what would happen if a majority client would have a consensus bug right because like if a majority client would have a consensus bug whoever is running majority client would be slashed heavily

and because of the quadratic inactivity leak like I I said it would quadruple so the inactivity leak would CR qu basically would slash everyone who is not attesting to the correct fork and this would quadruple every slot or every Epoch I'm not entirely sure but it would be quadrupling and because of this quadrupling it would become heavier and heavier with time I think with every Epoch um but I I'm not entirely sure about that I I'll have to ask a consensus layer Dev um and that's why it's it's very scary to to be running a majority

client it's risky for your fund not for I mean it's risky for the whole network but it's mostly risky for the person who is running the majority client oh okay and okay be before this question I want to say that h b could you review the code for the rap packet yes of course um I believe the code is let me let me just double check just to be just to be sure yes I I will send it on the chat it's build with nethermind yes so um please use the code to to to

claim the rap packet for the whole sharing sessions don't forget it okay let's head to the questions in the chat box yeah so again some some question uh what kind of abilities are needed to do research say consensus issues like good at math no not really if you want to research consensus issues you just need to know um the evm the ethereum virtual machine uh mostly and transaction processing uh on on on on different clients and what are the rules for those and you have to look for certain edge cases right like uh Max Max uh numbers Max bytes uh minimum bites

certain like things like that that could be missed by the developers while while while operating some some kind of overflow that could happen some kind of exception that could happen from using certain invalid characters Etc right so these kind of things um internship part-time or full-time how long does it last how much time need every week um actually I think the internship is up to you it lasts for a couple of weeks I'm not entirely sure how much I think it's six weeks but I'm not super sure mil is here from nethermind Events maybe she knows Milik do you know how long the I'm

sorry to to to bring this up Suddenly on you um yeah no worries it's uh it's actually three months uh part-time but um you can always discuss with the with a person that you're interviewing with right great thank you so much I'm just like I don't have that information thank you so much and yeah I any other questions so while waiting for the the the other questions um kindly remind that Bor you can also claim the rap packet on our official website you have registered so you can

claim it oh sure let me try you can try it's interesting yeah yeah I'll try that actually should I share my screen while I'm trying to do it um yes you can share it because it will not demonstrate any privacy it's CK encrypted it's it's a traditional Chinese event rap hacket is during Spring Festival I think the older will give rap hacket to the younger and it will sometimes um people will uh the older will give like um I'm not sure several hundred or uh 1,00 2,000 un which equals to like I think one $100 or

$200 it wishes it give it Wishes the younger generation good luck has his success every good wishes yes so we so we mimic the the the traditional Chinese event okay let me try stop presenting and I'm going to present this other window here okay so I can go here and these are the claimers okay and I can put in the

password yeah yeah with NE M just I okay that's cool and then youim and then approve let's see the outcome it's random it's randomly generated let's see how much you can get oh it's random interesting yeah it's random it's random random every everybody is oh it seems that you want the most I got the highest number yeah you got highest one of the highest number that's very interesting um you're now you

you're now the indeed highest but like what is like what is this um token USD c usdc yeah us oh it's it's it's usdc on optimism yeah usdc yeah that's very cool I did not I I I would be willing to to to actually um give this uh away to charity or to D learning again if anyone wants it thank you but you can you can keep it it uh represents uh good wishes in Chinese in China oh thank you so much thank you so much and you won the highest means that

you're maybe the luckiest one the most lucky one you want the most you so much you're welcome so does anybody go ahead I'm sorry go ahead yeah I was just going to ask if there is any other questions uh again feel free to reach to me or uh to to to Melissa to to melik uh or Melissa sorry um about the internship program we'd be happy to have you so does anybody have any other questions

feel free to drop it in the chat box where open your [Music] mic okay seems it's quite clear so thank you every okay St stay you raising your hand you have any questions uh I think he wanted to to to have an reaction and then he he raised his hand by mistake oh okay cool he just want applaud but oh someone someone asked how many people are there

in nethermind I mean we're around 200 right now around 200 not an exact number but we are expanding um so yeah cool that's that's I think that's super book especially in web 3 okay I think now it's quite clear and nobody have any other questions okay let's wrap up the sharing thank you headquarters headquarter is in London thank you everyone for having me okay thank you thank you everybody for coming to this sharing session let's see you next week hope to see you again

P goodbye thank you bye byee