Ethereum (Consensus) 101 with Potuz (Cohort 3, Week 4)

Transcript

all right everyone hello this is women in theorum protocol study group week four and today we have a special guest vus PO is a core developer at prison which is ethereum consensus and welcome pus thank you so much for being here hello thank you for in and before we start could you please tell us a little bit about your experience with protocol about your role at prism all right so my experience in the protocol I am a mathematician I just got bored during the pandemic because I couldn't work with my kids in the apartment and I decided to get into crypto I think I only bought some Bitcoin at the time

2020 then I decided to read a little bit more I found ethereum to be fantastic and their change to proof of stake it was happening right then at that moment I bought some eth and I said that I was going to stake it and the medalia incident just happened right there so I said okay so my all of my money is in in danger and I decided to start like working for well to help the kids that were writing the pr client at that time well slowly slowly I got involved with them and now I'm working with for them so that's do you do both research and core development well I am not really doing any research at the moment but I do still have my grad students and uh

and a bunch of responsibilities in The Institute but most of my time is uh spent in thinking on the protocol okay but pandemic changed a lot of lives uh yes it did I had a young kid and a baby at the time so it was hard to work in anything else that's great all right we are about to start ladies feel free to raise your hands if you have questions during the talk and POTUS the stage is yours thank you all right so let's get to that what I want to talk today is actually some something that is causing that I'm shocked to see a lot of misconception certainly the community gets this wrong but even among core deaths there's not a clear agreement on

this kind of questions what are the essential properties that blockchain has or that blockchain wants to have so I wrote five properties that a blockchain may have it could be the centralized sensor resistant life fast cheap safe and verifiable we're going to actually Define some of these properties later on but I wonder does anyone here feel that one of these properties is not essential can anyone like actually unmute and tell me one in this list is actually not essential and I would want someone to give me a guess so I find the word cheap can be like you know in multiple terms it can be understood so if you would like to like explain what do we mean here perfect so being cheap if we

actually manage to Define it is going going to be a one and a half it's probably not really essential but I'm looking for another one I think live live because yeah because recently I was introduced to a project that used death to do ethereum transactions on future phones so it was recording the transactions kind of like at a later stage recording them off chain and then and then using that to record them later so I don't think oh but by live okay so probably is a good spot to like move forward then live here means that the chain will eventually be able to continue producing blocks so that

lightess is definitely one of the essential properties that chain wants so life here means that no matter what happens we're not going to be in a deadlock scenario and I'm going to have a quote to a paper by balic where he gives a a loose definition of this but it really means this there's no Deadlocks and some block producer or some minor or whatever is going to be able to produce a block that advances the chain liess is something that we really want to be essentially there so anyone wants to shoot another one maybe fast one fast well fast is another one to have the one that I'm looking actually is the centralized the centralized is the only one that is definitely not essential if we could get

and I've left here in Black the three essential properties that blockchain wants to have which are being sensor resistant being live I just describe what life was being safe that I will describe in the next slide what it is but the red ones fast and cheap are properties that we want they're nice to have but de centralized is not even essential at all if we could get sensor resistance sh liveness and safety in a centralized manner we would because being centralized is always fast is always cheaper it's always better than being decentralized for these kind of things however we do not know how to get

the essential properties that we want which is being live being sensor resistant and being safe without decentralization so decentralization is just the means to getting the essential properties of the chain verifiability well before that safety actually here is two different properties correctness that means well I'll Define correctness in the next slide but essentially it just means that this chain cannot have a statement being true and false at the same time and being visan in tolerant meaning that the chain actually can support either attacks or some nodes that are falling offline or the some lack of messages in the chain these are this the three main properties

safety that here means two different things correctness and business intolerant sensor being sensor resistant which means a user can send a transaction at will eventually appear in the blockchain and being live meaning the chain will eventually continue forward being verifiable is something that I do not want to emit opinion people even C devs have different Notions of what or how essential verifiability is should it be verifiable in a watch should anyone be able to verify the chain should it be verifiable in your home computer do you need a big computer do you need a small computer do you need a huge bandwidth to be able to verify it could any person in the world verify it or not so these are questions

that have honestly different solutions different answers but the main three are the on here in black and we're going to talk about these properties in the next few slides all right so so I'm gonna start from something very very high level and I hope that it was shocking to some here that decentralization is definitely not essential but I would want to get to decentralization how we deal with it so a blockchain is well it's just a collection of blocks it's built out of blocks that carry information that this useful information for the users this information could be anything so in Bitcoins blockchain that the information that a block has is just a transfer from a token to another one

in ethereum it's an arbitrary execution of and a change of the status of the word computer in other networks there's other things that you can with those blocks but the thing is that we need to nodes achieve consensus in two different things and these two different things are overloaded words for consensus so we need to achieve consensus on the validity of the blocks the validity of that information and we need to achieve consensus on which of the blocks is the current that is if there are two blocks that are valid and both of them are not compatible which one is the one that we should consider for being part of the chain so these two things are different areas of consensus and uh what changed

dramatically in the last couple of years on the ethereum network is the second type of consensus and this is the type of consensus that I work on but first let's go to the first type of consensus which has to do with this notion of being the chain being verifiable or safety for the chain so the blockchain for a Bitcoin for example doxo model that's is not really stateful it doesn't really have a global state nodes keep just the unspent tokens that users had and that's all you need to validate a full block ethereum on the other hand has a full state of a computer in what we call the execution State and users with their transactions can actually modify that state and what

a no does when he has this state with the status of the computer today or if you're a Bitcoin node you have the state with a list of unspent tokens or unspent coins and who are the owners of these coins and when you receive a block with a bunch of transactions transfers or arbitrary execution ethereum you make a series of validations some that areain for the block so for example the block regardless of whatever transactions are within the block the block commits to the previous history of the blockchain so if you agree that a block is valid you're also agreeing on the status of the blockchain up to particularly that point

so that's the big thing with the block is that when you say this block is part of the blockchain you're already asserting on the whole history since Genesis all the way up to that block but to verify a particular block you may not need all of the history of the chain you need the current state the incoming block and you compute the state transition and you get the output State either the output State on bitcoin the whomever owns which coins or in ethereum what is the total at the output state of the computer after importing the block now verifiability for ethereum at this moment it means that you can in your own computer have the state you get a block

and you can validate that the block was it's correct or not it's the valid block or not you can compute yourself the status of the state machine without the aid of anyone so there's zero trust assumption whenever you receive a block on the status being correct after it and actually to run a Bitcoin node I stopped running a Bitcoin node a couple of years ago but up to not long ago you really needed you didn't need much disc you didn't need much bandwidth nor anything you could just prune everything you don't need anything of the history and the full State wasn't the full utxo State wasn't that much ethereum today also doesn't require that much if I remember correctly the current state the full state of the machine is about 250 g

gigabytes so for current computers that's not so much the biggest bottleneck today to validate the chain is bandwidth you need to have a decent internet connection to be able to follow the chain and get the blocks on time but that's what we mean by verifiability how about safety so safety refers to the fact that you cannot have to contending information so if you ask a node who is the owner of this token and node that has just synced this block and has the state will reply in the same way the owner of this token is this account and uh it cannot happen that one node will have one owner and another node will

have a different owner for the same after syncing the same block I'll modify this later when we talk about fors but the idea is that you cannot have a status in which one person have spent some token in one status and hasn't spent it in a different status and both of them being part of the blockchain all right so that's about what have about the validation and most of it happens on the execution layer so now I'm going to move to the kind of things that I work on which I I have them dear to my heart which is how do we decide which block is good if you receive two different contending blocks that are both of them valid which one is the true one that

corresponds to the chain and which one is not so here there are two questions first of all who can produce these blocks and second if you get two blocks produced by players that your system allows which one is the right one so these two questions are separate and they require different answers principle you could as said already the centralization wasn't really essential you could have a single entity that produces all blocks and now we're going to get to lightness definitely if we do this on ethereum WE allow only a single person to produce blocks we cannot guarantee lightess because if that entity disappears or goes offline then the chain cannot Advance by definition so therefore we see that some sort of

decentralization is needed if we want to have lightess sensor resistance the same if only one entity is allowed to produce blocks then that entity can decide never to include your transaction so a single entity sequencing blocks is not a good status for a blockchain that wants to be live and sensor resist consistent but how about a rotating set of only one entity at a time so if the entity just falls down then the second entity turns on and starts producing blocks this will guarantee liveness I mean if this the list of white listed entities is large enough you will be alive you can actually guarantee liveness and this is the approach for example that raps have

rollups with a centralized sequencer do have this and they can guarantee liveness even though there's only a single entity that is actually producing these blocks or sequencing transactions sensor resistance is a different story even if you have a rotated system of one entity then that entity that is active at the time can still censor your transactions and this is the biggest problem that rups have today it's very hard for rollups to keep the throughput and the speed and the cheapness of their Network guaranteeing sense of resistance ship that's the biggest problem that they have today another way of like deciding which one is the next BL prod producer is to Sol the hard puzzle this is what Bitcoin did and this is what

ethereum did before the merge this is proof of work and this was the big realization of the Bitcoin Network and this is a very beautiful and simple form of consensus if you receive two blocks this blocks will come with a proof that they have Sol a hard puzzle and there couldn't be a tie you would see which puzzle was harder to solve and that's the true block and that's it everyone would agree on which of the two blocks is the right one by just looking at the proof of the hardness of the puzzle that they solved so why would we move away from such a very beautiful and simple system so the system we move to is much more complicated it requires uh people holding a token in this case is proof of

stake validators in ethereum they need to hold at least 32 e to validate and uh they are assigned at random weighted by how much they're holding to produce a block every now and then so and this requires a lot of mechanism to actually work I'll describe this mechanism later on but why did we move to such a system I'll leave the question and I'll try to attack it later but coming back to our set of essential properties of blockchain here's a theorem this theorem actually is a theorem of database but the same theorem applies to blockchain and it applies in many different contexts so for databases you have three properties that you would desire to have

you would want the database to be consistent if you ask the database to read a value then that database should give you the last written value or it should error up it should be available if you ask the database give me some value then the database should return either even with an error but it should return it should tell you yes I don't have this value or this is the last ritten value you would would also want it to be tolerant in the sense that if you have a bunch of discs and some of them fail then you would still want to be able to recover the data so those are statuses that you would want on your database and in the case where your database is actually distributed then

this partition tolerance refers to you have some messages being around so you're asking for data and then this this doesn't have it it requested from somewhere else and if even if some messages are failing to get to their destination you still want to be able to recover the data that you're trying to reach and there's a theorem it's not that new actually it's not that old actually I think this was proven as a theorem by 2012 that these three things cannot happen at the same time it's just impossible to have these three properties at the same time and for blockchain the same happens if you want to be consistent you definitely want to be consistent you don't want to have this use having spent Bitcoin in the

chain and not spend it somewhere else because you will have this double spending problem and you want to be partition tolerant that means that if the chain doesn't send messages from one side to the other one then you will not be available which is liveness then you might be deadlocked in a situation where no one can produce a block and the chain will stop ethereum actually went the other way around ethereum set up in a way in which we are given up on partition tolerance under some conditions to get consistency and availability so in ethereum you will never finalize two unless a third of the network is slashed you will never

finalize two contending branches and you also are always able to produce blocks but if there is such a partition in which some chain some part of the chain believes this uh is valid and some other part of the chain beli some other block is valid then what would happen is that those two partitions are going to continue on their own chain and we will have a break up in in two different ethereums so we gave up that partition tolerance to keep the other two all right let's go back to that question why they move from proof of work to proof of stake and it's because we do not know how to get one of the essential properties which is sensor resistant without decentralization we need

decentralization to guarantee both sensor resistance ship and liveness but sensor resistance is the most important one and we just do not know how to deal with sensor resistance without decentralization before proof of stake there were only a few Miners and those miners could be bribed to not include your transaction imagine if we could have easily had a rollup Centric model for scaling of ethereum under proof of work but imagine an optimistic rollup the node operator removes all of the money out of the bridge and they can someone needs to be validated that rollup someone needs to produce a challenge to that optimistic rollup or if you're a ZK rollup someone

needs to produce a proof that for the money of that for that rollup to be contined alive so so in this situation if you're trying to challenge a rollup because they're trying to steal all of your money you need to send a transaction for the challenge protocol of that rollup and if the node operator for the rollup just decided to all miners then that transaction will never get in and they will just steal all of your money so decentralization is the only way of guaranteeing that eventually you will be able to include your transaction I mean in the extreme case if you want to have your transaction in you can just spin up a node a validator with 32 e and eventually you will produce a block unfortunately that could

take over a year now but even in the current status of ethereum in which there are much less minors than they used to be because today most of the blocks in ethereum are constructed by only two entities two Builders however we have mechanisms now to allow the decentralized set of proposers to force transactions to be included this is an EIP that is proposed and most probably is going to be in the next fork or the next one or the next one but in less than a year's time we hope to have fossil which is a mechanism to force transactions in the next block even if we were not building them all right so let's move on to this topic which is given two blocks how do we decide which

one is the right one so for choice is just literally this we see two different blocks that extend the blockchain there's this red one here that is trying to reor the last black box which one is the one that cor that is right and it's important to be able to decide this because these things happened so our chain actually looks like this we sent a transaction which is that red one there that block we send the transaction if the chain is that in red then the transaction was in I need to make sure that my transaction was in and I can only know that my transaction was in by knowing what the head of the chain is because the head of the chain determines the entire history of the chain and

therefore I can see if my transaction got in the block that is included in the chain or not so ethereum moved into a system the ethereum consensus to choose what is the right head is a mixture of two separate things that are in contention actually and they were the source of many headaches for CS one is a finality Gadget that allows to say some blocks are not going to ever be reor so if a node sees a block and calls it vinyl it will never ever move to another block on a different chain and call it final so an honest node will never even if a third % or 100% of the validators

are being slashed a node will never unfollow a finalized block so even if 100% of the validators are malicious a old will never unfollow a finalized block and then there's another one which is called the lmg ghost which is used to discern between two different blocks that are not yet finalized but both of them are viable to become canonical so here this black boxes are called finalized blocks so when we are at this stage and we finalize this block this block already asserts to all of this chain so whenever we have finalized this block here this one is final this one is final this one is final this one is

final all of these are final and moreover all of these blocks here are no longer viable I know that since this block is final can discard all of these blocks because they will never be part of the chain it doesn't matter if 100% of the validators are icious and they slash themselves to switch to this franch and there are some other notes that are called Justified if you notice these notes are just right after the finalized ones so this note here Justified and this one was finalized in the previous slide this one was Final and this is now Justified but among the ones that are not viable these are there can be some notes that are Justified and if you are following what the tragedy

that just happened in heski it did happen that holeski Justified an invalid block so this is the situation that could happen in holeski when we recover it that we Justified an invalid block and then the chain switched to another chain and eventually finalizes a valid one so that's what we're hoping will happen by the end of the month in holeski nodes typically attest so validators attest to what their head of the chain is and an attestation sends so that's what the consensus layer clients do they just count attestations and then decide which one is the head of the chain so validators whenever they see a block and it's their turn to attest they

send an attestation saying this is my head of the chain today so a validator that is following this chain will attest during this block saying this is my head this is my last Justified checkpoint and here's an arrow which is an attestation I note that is following this chain during the same block the same slot can see this block and he will say well this is is my head and this is my last Justified checkpoint and here's my attestation if we could count all of the validators at every slot that would be all that we need and this is what we would call single slot finality that is validators immediately when they see a block all of them would just validate they would just attest we will count all

of the attestations and decide whether or not that block there was already final or Justified or not so to just ified a node we need 2/3 of the validators attesting for it if two-thirds of the validators attest for a block that block is called Justified and if 2third of a test for a child of a Justified block that block becomes final so that's the big hope that we can move to such a system that is pure but unfortunately that's very very hard with that with a million validators out there we don't have the Machinery to actually count a million attestations every 12 seconds so what we do is we split the blocks and instead of only being one

block we split them in groups of 32 these are the EPO and each Epoch has 32 32 slots where validators ATT test and then what we actually justify and finalize are the epochs the groups of 32 blocks but within each Epoch we actually can reorg can move and can have very very much for situations so typically what you would see is is a long long long chain all of it is finalized but then the late the latest latest one is Fort where there are some rears that's where lmg goes plays a role whenever there's a block that achieves 66% within the epoch there might be a block

typically happens on a wellworking network by slot 22 of the epoch which is about 2/3 of 32 by slot 22 we already have enough votes for the beginning of that ook to be justified and that's when the chain works fine all right so here's a theorem of a vitalic that says that unless a third of more validators are slashed the blockchain can never finalize two contending blocks so that's goes for safety of the chain and this is a theorem with our current system you can not never have two blocks that are contending that are final unless a third of the validators lost all of their Capital so what is slashings well if you're a proposer and it's your time to

propose a block you're chosen in this slot to propose a block if you propose two different blocks you're slashed it doesn't matter if it follows from the same chain or here for example you're proposing a block based on B and here a block based on C these are two different blocks that are contending and for the same slot you will be slashed but the most common type of uh slashing is attester slashings and this happens if you need to attest in this slot and you attest two different blocks that are contending you are slashed this is the most common occurrence a validator spins up two different clients at the same time and the two clients have a different view of the chain and they

vote for different blocks and that particular time and they are slashed but there's other kinds of slashing that is slightly harder to understand which is called the surround slashing when you attest remember I told you you said which one is your head and which one one is your Source the last Justified checkpoint it may happen that you have an attestation like this from a later Justified checkpoint suppose that magically this node attested like this and then suddenly this block is no longer justified by that chain this cannot really happen on a well functioning chain but that validator if it did happen to that because of a bug in the software that it no longer sees this block as justify it will use this

block as justify and then I test in this slot to this head this is called a surround vote where the source of the next attestation is before the source of the other one and the target is after the target of the other one the same here this attestation here surrounds this attestation and this is what is happening today in holeski in holeski we Justified an invalid block restarted the validators declared this Branch as invalid and now these nodes are attesting with a their Justified checkpoint so this is exactly the situation that happens in holeski today and that's why validators in holeski can all be slashed all right this is the the

anatomy of an attestation an attestation just to give some technical detail after how attestations work an attestation has the slot at which you are supposed to attest an index which is which of the validators you are the validator that is expected to attest in this slot the beon block root of the block that you're attesting to the source which is your latest Justified checkpoint and the target which is the first block of your current eock all right and this is a theorem from vitalic where if regardless of any previous events like attacks latency or whatever it is always possible for new blocks to be finalized that is it's always possible for

validators to propose new blocks however notice that contrast this with the situation in keski this is true in heski if we didn't the validators that were running the minority notes these were validators that were running with bre or with argon in heski they could always continue proposing blocks and attesting to them but the validators that were on the invalid Branch they couldn't the only way for them to follow the new chain was to restart and actually remove the slashing protection these validat will never attest for the chain because they would be slashed otherwise and they don't want to be slashed so those validators are kind of dead L but and it's through the lightess continues so

we would have like many many less blocks because most validators will not continue producing blocks on the minority chain but the point of lightess is that the minority chain eventually sees the other chain as invalid and it Forks off and now you are in a situation where you have two different ethereums if we wouldn't have patched the validators in holeski we would have effectively two two different ethereums running in the holes Network that's how is that we accepted that we are not tolerant to partitions we accept that we might Fork eventually but at the cost of but in exchange we get liveness I'm going to tell you now a little bit about how clients works yeah so this is the

attack and this is how we count attestations so on the CL Network so an ethereum client consists of two different pieces of software a consensus client and an execution client and all of the block that contains the transactions the attestations and everything comes in the consensus layer P2P Network there are part of the block that are actually not broadcast with the block these are the blobs that rups use and validators make some very fast verification they don't check anything about transactions they only check like things that are kind of be checked immediately the most coly check is the signature of the proposer that you need to check so that's the costliest

possible check on the Block and you make this fast verification and then you forward the block to your next Pier the execution on the other hand the P2P layer of the execution is rarely used on when you're already following the tip the execution layer relies on the consensus client to tell it what's the current head and what's the latest block that has come but when you first start your execution client it needs to sync the entire State the 200 the currently 250 gigabytes and to do so they do this completely independent of the consensus client the consensus client tells it this is my current head synced on your means to this head and that takes a few hours typically where the execution

layer on P2P Network they exchange the full State once the execution layer has catched up to the current full State then the consensus layer would continue feeding it block by block every 12 seconds the blocks but transactions are that users send so the users never interact directly with validators the users of the chain they interact with the execution layer they send transactions through the execution layer the consensus client gets the block and it needs to validate both things that the consensus part is valid that the proposer was the right one that the signature was correct that it was his turn and a bunch of other things and the execution in parallel so the execution

was what we said about safety that the user had enough money to actually pay for the transaction for example so the execution consensus client communicates with the execution client via an API which is the engine API and it sends it notifies the execution of the new payload that just arrived if in addition the new payload that just arrived happens to be valid and it continues the chain then the consensus layer would tell the execution layer this is the new head of the chain most of the complication of writing a client is in caching the information that you need to validate the block you need to have a lot of information already in memory to even make sure that the block is valid you need to know which validator at that

time was supposed to be ATT testing you need to know exactly the state of the block what is exactly with the state before starting to process in the block and everything needs to be already in place in memory this is for the consensus client the execution client since the state is so large they cannot keep it in memory so they need to be very fast at ing the right parts of the state that are more often being accessed they don't need to bring it up from the disk so you perform the state transition the block is saved to a database on desk and before you do anything you need to save the block on desk because if you are in consistent on disk and memory then you might get slashed your validator so before you even check which one is the head of your chain you saved

everything to this and then you compute on four Choice what is the new head of the chain once you know the new head of the chain you send an event to every consumer in this case our validator clients or signers that you have a new head and then you start Computing so this typically happens at the beginning of the slot between second two and second four and then you have the next eight seconds to compute all of these things that you need to cach for the next blog to be able to process it very fast so this is the liter last slide performing duties a validator client is typically a separate program or actually two different programs or it might be three different programs if you use vouch but a validator client is the one

that actually performs the duty so if you are a full node you need a beon node you need a consensus client but you not need a validator client but if you're a Staker you do need a validator client and the validator client what typically look it's following this feed that says I got a new head I got a new block or every 12 seconds it checks whether or not it's Le to produce a new block or to attest to a new block and when it is the time to produce a new block or to attest to a new block it requests through another API it communicates with the beon node and it requests give me the blog or give me the attestation and I'll sign it so it signs it with the key if you're very sophisticated you will send

the message to another computer where the keys are stored and that computer is safer and that computer would sign it there send it back to you and you will send it back to the beacon via the beacon API to publish to everyone else so that's how we perform duties and that's it so this is more than my alloted time and what I had to talk about in consensus thank you for this thank you so much yeah the protocol itself is quite complicated so just ladies don't be afraid of it we should just eat it piece by piece if you have any questions please raise your hands or put your questions into the chat anything you would like like to know about the protocol what is aration who

is validator etc etc for example poos if I have um a node running on my computer so once a year I will be a validator right I will produce the block and for yes you have one cator on your computer yes it's about like once a year that you would be assigned to produce a block probably twice but you're expected to produce a block about once a year yeah and the other time I'm just a tester right I attest this block yes there's a bunch of Duties that you need to do so you are every Epoch so every 32 slots you're attesting once so every 32 slots you will be assigned to one slot to a

test once in about three or four years you will be assigned to give sync committees so these are messages that are good for light clients and you will do this for over 20 7 hours like every single block for over 27 hours you also have some duties with to serving data to other validators so you will be requested from other validators to that are trying to sync to the chain to get them like a range of blocks from the last I don't know how many ebooks and so forth there's a bunch of Duties that you need to have even if you're not even validating got it thank you Bish your question please so you mentioned holis

key you were explaining that something happened to holisky I didn't get that like what happened because you're making reference so ethereum goes through upgrades and uh even if we didn't go through upgrades we need to test our software and it's very hard to test our software in say an environment with only like one or two computers running a virtual Network because we actually need live information as close as possible main net so that we can Sol bugs before they happen on Main net so for these ethereum spins networks that are as close as mainnet as possible as close as ethereum as possible and holeski is one of those networks that is specifically

designed to have a large validator set so that we can test consensus clients execution clients don't need that much testing in that sort of environment but consensus client is is critical for consensus clients to test in that sort of network so now what happened is that we deployed the next upgrade for ethereum the pectra upgrade in heski last a couple of weeks ago it did happen that the three major El client execution clients had the same bug and then it turned out that a block that was invalid was attested by every validator running those majority clients since there were more than two-thirds that bad block was

justified and once nodes have Justified a bad block they start attesting using that bad block as their source of the attestation if you remember an attestation was an arrow with a source and a Target and they used this bad block as the source of the attestation so once we fixed the clients and if we ever want to recover the chain we fix the clients these clients no longer have this bad Block in their database it was pruned now they consider it invalid but now they can no longer attest because their last Justified block for them is before is the last Justified block

before the bad block and one of the rules for slashing is that you canot attesting these conditions so hes is in a situation where lightess is even threatened so you mentioned slashing right so please can you go back to the slide for slashing so in proof of work you weren't assigned to propose a block in proof of work let's suppose that the chain was like this it had three blocks a b and c this is the status of the chain now and now you're a minor so miners on proof of War would constantly be trying to solve the hard puzzle that that's what Bitcoin does now and when they actually do solve the large puzzle

they pack all the attestations that they can and they send the block but in principle they could try to send two different blocks but that's impossible in proof of work so if you send two different blocks they will have two different proofs of their puzzles and there cannot be ties in that consensus so their two blocks would be fine both of them would be valid if they're different but one of them would have solved a harder puzzle so one of them only would win so in proof of work if something like this happens that you're a minor you solve two different puzzles and you propose two different blocks as candidates for D the chain would just choose one and that's it and continue moving on in proof of stake the

mechanism is different in proof of stake you are a proposer I'm going to call it minor too but it doesn't matter and you are assigned during those during this slot during the slot for D you are assigned to produce a block and there's no proof that there's no make inbuilt mechanism to decide for the best block that you produce so instead you could in principle produce two different blocks and confuse the network by producing two different blocks you would cause a split because if you send one block to one aester and the other block to another validator both of these validators would have seen different blocks and they would think

that the chain that the status of the chain is different and that would cause a network split this is a malicious behavior on a validator how do we prevent it well we prevent it by if anyone sees two blocks by the same proposal at the same time and these two blocks are different then that proposer is punished so this mechanism is the same so in this situation here what happened is the proposer produced two different blocks in one of them is building on top of c and in the other one he's pretending that this Block C never existed and building on top of B so both of these situations are situations in

which a proposer has is producing two alternative ways of the chain and this is malicious behavior that we punish wow thank you so much thank you thank you vik now me your question okay I everyone so my question is sort of like what Vikes also raised you mentioned that cuz I'm looking at the holy skon chain right now and I see a lot of empty blocks that have not been validated because of the picture upgrade so I guess my first question would be what exactly is the petal upgrade then the second one would be so now that they are sort of like bugs with the holisky network are the validators going to be slashed would it

work the same way because like I see like a lot of like sheduled blocks I see yeah basically like a lot of sheduled blocks and then like the it's not justifying like I see justifying like 22.4% so yeah in this case would the value need itors be slashed since like it this is sort of like costed by a BG like how does that work okay so let's deal with the situation in holes in a tiered manner because developers doing something that would not happen in main to try to recover faster holes but let's forget about trying to recover it faster how does the protocol work in this situation the situation is that some so I'm going to go to something like here

if you look at this this slide is like this so heski was working perfectly had a finalized block a finalized block then a Justified block and then suddenly some blocks appeared this where some validators considered this block valid and some validators did not so this block appeared here and a validator said this block is valid because he had a bug the block is actually invalid but a bunch of validators that saw this block here where I have my cursor now a bunch of validator saw this block and said this is a valid block and some validators did not that see this block they say this is an invalid block those validators will not produce if when they produce a new

block they will produce a different block they cannot produce a child of this block because this one is invalid so they produce a child of this last Justified one and now validators that see this chain as valid will continue on this chain and validators that see this chain as invalid will continue on this chain now what happened in heski in particular is that the majority of the validators were on the invalid chain which is this one on top that means that a a bunch of them 66% of the network actually ATT tested for this block and they managed to justify it so this is what happened in hes now if we don't do absolutely anything how does the chain

progress okay if we don't do anything we don't fix clients nor anything so every validator on this chain will continue on this chain they will see about 66% or more of the blocks in this chain except when the validators that are from this chain are scheduled to produce a block because when the validators from this chain are scheduled to produce a block they will produce a block on this chain and they will ignore it because that chain is for them has very little weight so validators in the invalid chain will ignore this chain and validators from the valid chain will ignore the invalid ones because they are just invalid so now over time on this chain from the point of view of the validators on this

chain all of these validators here are not doing anything they're not doing their work they're supposed to produce blocks and they aren't they are producing this this useless blocks that are on this other chain and from the point of view of the validators on this chain the validators on this other chain are also producing invalid blocks which is even worse so the validators on this chain would actually kick them out when they connecting so the validators on this chain will not even connect to the validators of this other chain because they consider them malicious building on top of invalid blocks over time these two forks the validators in this chain the state of the computer network in this chain is different than the state

of the computer network in this chain in this chain here all of the validators on this chain are losing money they're being punished for not doing their work and in this chain the same thing for the validators on this one so in each one of these chains these validators have different statuses different realities and as the chain progresses these validators here will kick them out Ki all of the other ones out so from each one of these chains all of the validators on the other chain will be completely kicked out and their eth will disappear that's the punishment on that chain and at that point ethereum just continues working fine that both chains will finalize both chains will have their validator set

voting correctly and all of the blocks will be proposed because when this chain already expelled all of the validators from this other chain none of those validators is going to be scheduled on this chain to propose a block and every block here will come from validators in this chain and the same for the other one but then you will have two different chains that continue forever so this is one of the trade-offs that ethereum has taken we allow this kind of situation so that we are able to continue forever because you want to follow up right yeah I I just wanted to like ask do we know why this happened yes what happened is is a silly configuration problem and it could only have happened in heski what happened is

for the first time and you had a question as well which is what is the pectra upgrade ethereum upgrades in the sense that the condition for a block to be valid is not the same over time we add new features and when we add new features we necessarily need to change the condition for a block to be valid because now we support for example new kinds of transactions so we allow users to send transactions that today they will be nonsense but tomorrow they will give the chain a new utility so when we do these kind of things the nodes need to change the algorithm by which they declare the block to be valid or not so

they changed what we call the state transition function with this happens we need to do this at a prescribed time and in an organized manner because every single node needs to agree that starting from now we support this new feature and starting from now we are going to continue the chain with these new validity conditions anyone that is running the old software would consider the blocks in valid so this is what we call a hard Fork when we do this the chain is set to to go on a hard fork and this is back is the name for the upgrade that we decided to test in this chain two weeks ago now what exactly happened is that well there is a contract there

is one address on the computer that keeps the balances of the validators givs how much eth each validator has deposited which the execution layer never needed to know what where this address was but starting from the pectra upgrade they because of a new feature that we added the execution layer in the validity condition of the blocks they need to know exactly where this balance is being held and uh three execution clients forgot to add that address to their configuration and two execution clients did add this address and the configuration so when one of these new

features came in inside this block then the three major clients consider it valid for one address but then these two minor clients consider it invalid and that's why what we call a consensus split happened thank you Naomi do you have any questions yeah hello glor I can explain so the question was these attestations and blog proposing is it an automatical process or you should do something for it or it just goes automatically so yes so the software does all of this for you and so if you

are from the point of view of the node operator which is the the person that actually runs this software this node operator only needs to monitor the software that is just to check that is still functioning properly but it doesn't need to do this to be constantly looking at this it doesn't need to do it doesn't need to be any interaction the software would just validate the block would perform all of the duties it would do all of this automatically yeah and the owner should update right as well yeah so whenever there is a hard Fork as what happened with Petra then anyone that is running the old software would be on an invalid Branch once the hard

work is ritten so you need to change the software for a new version from time to time okay okay got so I'm wondering what could have costed an inval block if since this process is not manual and let's say everything on my setup is okay and I'm just running my note and um I'm running the cor Val of Ls and all of that so I'm just wondering what could have impact on creating block okay so if you are in that situation where your node it's a very unfortunate situation in which your node is sees an invalid block as valid and then you continue so what will happen depends a lot in the client that

you're running and the client that everyone else is running so let's forget about heski for a second and let's suppose that this happens on mainnet which cannot happen exactly what heski happen but let's suppose that you're running a not what happens is a problem in your computer and it's only your computer and no one else's and you get an invalid block and your computer tells you this block is valid so then what would immediately happened is that the next block will not be a child of the invalid block that you just syn this is because everyone else would have seen this block as invalid and then your computer would automatically set take the next block and just move on the

Chain would just continue with the next block so you wouldn't see any difference now if your computer had this problem but it wasn't only your computer it was like say 15% of the network had the same problem then a bunch of people would have seen this block as invalid but still if it's 15% of the network the next proposer will most likely be among the other set of validators that saw it as invalid will propose a block and every attester will attest for that block that is is contending to your invalid one so in all of the scenario the same thing would happen like the next block comes in probably should put

this on a slide but the next block comes in and it rears out the block that you just saw as valid while it was actually invalid so this means that in most of these situations you don't need to do anything and the problem will solve itself in 12 seconds now there is a problem is more than 50% of the chain has this bug if more than half of the chain has the bug and the block is invalid and continues now the whole chain will continue on an invalid branch which is what happened in heski and this is why client diversity is actually very important and also client diversity was kind of weakened by this problem because

three different major clients had the same problem but if only one of the five different clients has a problem in principle if the validator set is well distributed only 20% of the network will see an invalid block as valid and the remaining set of the chain would just reorg get out quickly and you would don't need to do anything now if we ever face a situation like what heski happened on mainnet that would be a nightmare scenario that no one really wants to be put on because recovering main net from something that will happen in heski is today we do not know how to

do that and if I update my note will I go back to the right fork or not oh that's a very good question but that's actually a technical implementation so what happens is let's suppose that we are in a situation exactly like heski where an invalid block was justified or finalized it doesn't matter and you were in that invalid branch and you started ATT testing on that invalid branch and then you say no I want to go back to the valid one and you update your software and now your new software tells you this branch is invalid and it doesn't sync it anymore you're going to be following the chain on the valid Branch but your validator client will refuse to sign any attestation because any attestation that

you sign on that valid Branch will slash you so the validator client will refuse to ever sign any attestation if you do sign an attestation you will be slashed and expelled and you lost money and if you don't sign your attestation anyways you're going to continue losing money forever so the only outcome for an Hest validator in this situation is to exit and then I need to exit I need to update and join the chain again right no so to exit you don't even need to have your own validator to exit you can sign a message from any note you can use a service provider you don't even need to use your own validator okay and there is some period for slashing right how long

is it when you were slashed no there is no period at all you can be slashed by an offense that you did years ago so any offense that you have I mean realistically this offenses either are saved by validators or they're not if no validator has your offense they're not going to see it again so then you might get out but what happens in real life is that all of these offenses are recorded in slasher and eventually on each block that comes they slash a new validator until all of them are going to be slashed okay sounds catastrophic so perhaps you might have been referring to

a different timeline which is when validators are slashed the penalty is actually very small except when many validators are slashed at the same time the reason being that you don't want to penalize an operator that just made a silly mistake if you just by mistake spinned up two different validators and got slashed okay tough B that's it it's you would lose now I don't know 0.003 e or something like this but the problem is that the slashing mechanism is there to protect the network from heavily stake operator that wants to double spend for example you want to finalize two contending branches to do this this operator will need to commit malicious

acts with many validators at the same time and then they will all be slashed together at the same time so the way we deal with this is we collect all the validators that were slashed in the last 27 days and after 27 days have passed we looked at all the validators that were slash and if there are too many of them we remove more money we punish them much more heavily than if there are just a few of them so we punish the validators 27 days after they are slashed we punish them again according to how many validators were slashed during that period so what's going to happen today in hes is that 27 days from now validators are going to lose a lot of

money and this L the penalties are different right it depends on the reason yes so the penalty goes from zero so you get slash a minimal penalty now which is after the pector upgrade is very small it's 0.003 or something like this up to the full amount of your Capital the full amount of your well 32 e or even more if you're one of the Consolidated validators so you may lose all of your Capital if 33% of the chain is lashed okay thank you asley you had a question as well hey yes you said the two chains in the hcap would finalize eventually I couldn't understand how two

of them could finalize okay so let me give you two comments about this so it seems to be in contradiction with what I said that that two contending branches cannot finalize unless a onethird of the validators are slashed but there's no contradiction here because actually what happened is that what will happen is that if the two chains continue and the validators just continue attesting without updating their clients let me give you two different scenarios instead of going on the on the usual Network partition let me go on the other part the other scenario which is what we happen now so what will happen now is that we actually are going to be one3 slash and that's it but in the situation

where no one updates their node what will happen is not that they will be slashed validators will not be slashed what will happen is that validators on Branch let me call them branches A and B validators that are following Branch a will see the validators in Branch b losing money constantly because from the their point of view whenever a block comes the validator branch B doesn't ATT test to this when their time to propose a block comes the validators in Branch b don't propose a block so they will start seeing that they are not performing the duties and punishing them slowly and

slowly and slowly actually when there's a lot enough percentage of the validators that are doing this then they punish them harsher and harsher and harsher so that we eject them when a validator reaches to any HTH of balance it's expelled out of the network and once the validator is expelled out of the network it's no longer staking so it's no longer supposed to attest and it's no longer supposed to propose a block so when this situation happens we have a much smaller set the every validator in Branch a before it was say 60% but now it's 100% of the network because they consider all validators in Branch b already expelled and then now

they have 100% of the network and they can actually finalize that Branch from the point of view of Branch b the exact opposite happened and every validator in Branch b is just expelled completely and from their point of view they are the only validators that are alive and they finalize their own Branch so in this situation it's not that one honest validator is seen both both branches validators from Branch b will not even connect to validators in Branch a will not never even see a block from Branch a it's like having two completely separate blockchains that don't even talk to each other yeah I see but so Branch a gets finalized I guess because they have the

majority I guess this is so if we don't update software or anything both branches will have EV eventually 100% of their validator because each branch will just expel the others and from their point of view they will have like the all of their validators are still alive so suppose Branch a has 66% then validators from Branch a will expel the 33% of Branch b and now suddenly that 66 becomes 100% And validators in Branch b will expel the 66% of Branch a and then suddenly the 33% that they were will become 100% okay they got separated completely yeah they

will be just like spinning two different ethereum networks today exact same clients exact same everything but different Genesis blocks yeah okay also I was trying to follow this hesy and I saw things like remote slashing database this things happened and but I also see they are still not finalized so what is going on like I just want okay so now the situation is this is Branch a has an invalid block and was heavily voted Branch B has a valid block but doesn't have much weight and

we want to finalize Branch b because that's the valid chain we do not want to continue on Branch a because it's invalid the problem is that uh to finalize Branch b we could do two things and one is just wait not do anything and wait until all validators in Branch b expel those from Branch a that's what actually is going to happen but so we could do that and wait a few days a few weeks it'll take a very long time for validators to expel but once it happens we will finalize we were afraid that uh clients that CL clients will not be able to handle the load of being aone time without finalizing it is very heavy on

CL clients to be on a time where we're not finalizing regularly the chain that's for a different story but the thing is that in order to accelerate the procedure to finalize that chain faster what we decided to do is to make the validators in chain a the invalid one to actually test to chain B so that we try to justify chain B by getting 66% of the votes on that chain uh but we need a lot of participation to for that to happen and moreover we have builtin software that even if we want to do to make a bad attestation our software would prevent

it because we a validator will never sign something that would make it slash even if it's the honest thing to do so validators that already attested to the invalid one if they wanted to help the valid chain they would have to actively slash themselves by a testing on the valid chain and that was why we requested node operators to delete their slashing DB which is the mechanism that protects them from slashing themselves so that they slash themselves but they move the weight to the valid Branch unfortunately we didn't get enough participation heski is the centralized there are lots of nodes operators that we do not know and those operators

didn't update their software so we didn't get to the 66 that we need to justify it on Branch b but we got many many of them slashed that means that in 27 days they their balance would be almost zero and they're going to be gone from the chain and we're going to be able to finalize so we're just waiting right yes we're waiting but then also praying because it's not really clear so Lighthouse already has a bunch of problems with the state growth I think every seal client actually struggling essentially client deaths are managing to patch their client quickly and keep their validators but normal users don't have access to these branches and are having trouble to to keep their

validators on now it's it's stable so now at least it's holding up we'll see if we can actually manage to save it that's a tough situation and hopefully it's on test net it's yes so luckily it's a test net and hopefully it will never happen again yes yes I hope so any other questions but it's also provided a good experiment I guess if anything that happens in the future doesn't it yes it's definitely a good experiment good and dangerous right any other questions please take your chance what is here ask your questions we're running now out of

time but yeah the conversation is really great if no questions anymore I think we can stop here thank you very much pus thank you for being here for answering all our questions for giving this talk um that was really really helpful for us thank you very much and all right thank you for invitation joining us yeah thank you see everyone yeah bye bye