Weak Subjectivity in Eth2

Transcript

[Music] [Applause] [Music] [Applause] so

hello everyone welcome to edcon 2020 lockdown edition and this is my presentation on week's objectivity in ethereum 2.0 uh i'm aditya and i'm a researcher at the ethereum foundation working on ethereum 2.0 research and development i'm going to start out with what week's objectivity is and then move towards the specifics of what this means for ethereum 2 and i'm going to end with a call to the community of some actionable items and uh what this means for end users who are the stakers of ethereum too so let's start out with some definitions an objective protocol is one

where any two nodes on the same network who are seeing the same set of blocks can uniquely identify the same main chain and a subjective protocol is one where nodes on the same network who are looking at the same information the same set of blocks can arrive at different conclusions about what the main chain is or probably even remain in inconclusive of what the main chain is let's look at what this means um in terms of two popular consensus mechanisms for blockchains that is proof of work and proof of stake so for proof of work the consensus mechanism is simple it's just the longest chain rule and since block production is rate limited

by extrinsic factors such as the speed the speed of the fastest hardware available we have some probabilistic guarantees that there cannot be two longest chains at the same time which means that there cannot be two main chains at the same time in proof of stake the consensus mechanism is the finalized chain rule uh and finalized here meaning that some bft consensus mechanism has [Music] come to consensus on on that block so finalizing blocks is a completely intrinsic process meaning that just the correct signatures from the validators uh on that blockchain are required so it is definitely possible to have two

finalized chains but the guarantee that we have from our consensus mechanism is going to be that a lot of stake has to be burnt in order for this to happen so usually it's going to be a one-thirds threshold which means if there are two finalized forks then at least one third of the stake has to be burned to allow this so what does this mean in terms of the block structure um so proof of work uh we look at we we are announced on a proof-of-work blockchain and we end up seeing this uh these set of blocks so we start sinking from the genesis

and somewhere down the line we encounter a fork and one of the forks uh ends at height 100 and the other four goes up till height 150. so just by looking at this we can reject this four completely and safely say that this is the main chain because our consensus mechanism is that the longest chain is the main chain in proof of stake if we encounter this kind of a block structure um and we start syncing to it where we start with the genesis we come down uh to height 129 and we encounter a fork uh so both of these forks at start at height 130 one of them ends at height 145 and there

is a finalized block at the end of it and the other one ends at height 150 and there is a finalized block at the end of it so we are we are definitely not able to determine which is the main chain because our consensus mechanism said the main chain is the one which has been finalized and over here both these conflicting forks have finalized blocks at the end of it so we have experienced a consensus failure and we cannot determine uniquely what the main chain is so two nodes who are seeing the same set of information can arrive at different conclusions about what the main chain is so what is weak subjectivity the definition

is as follows any two nodes on the same network uh and looking at the same set of blocks and having a recent state from less than n blocks ago can identify the same chain as main chain so what does this mean let's look at the previous example let's set the n year to be 10 blocks so for now let's assume that this this chain which uh this fork which ends at height 150 is indeed the main chain which uh the rest of the network is uh is considering its main chain and since our n was 10 the weak subjectivity state which is going to be kind of a checkpoint state from n

equals 10 blocks ago is going to be from over here at height 140 and we are trying to sync to the network and the information available to us is these set of blocks and the weak subjectivity state from height 140. so we start syncing we encounter these forks and we encounter the block at height 140 in both these forks which is somewhere here and we can kind of reject this fork because the state is not going to match our weak subjectivity state whereas in this fork we encounter block 140 we find the post state of that block and it matches our weak subjectivity

state which gives us a guarantee that this is the main chain so any two nodes who have this exact set of information is going to arrive at the same unique conclusion so now let's look at a popular attack on proof of stake which is called long range attack so in any proof of stake blockchain validators on that blockchain have to be allowed to cash out completely from the system uh obviously this is necessary because otherwise no one would want to state no one would want to accumulate rewards if they can never cash out so the validators have to be allowed to

withdraw their stake and completely exit the system now the problem that this causes is after the validator has exited and their stake has been withdrawn the keys of this previously active validator are now worthless the keys are not securing the network uh in terms of like their voting power they aren't securing any kind of stake so the validator itself considers these keys as worthless and now an attacker can buy these keys which were previously useful but now the validator has no use for them the attacker can buy these for dirt cheap and try to cause havoc in the system so what does this mean

concretely let's say we end up in in this situation to begin with which is we started with the genesis block sometime later there is a block c0 where the validator set at that time was v1 v2 and so on till v100 and sometime after c0 there is a finalized block c1 and the validator set there is x1 to x20 and v1 v21 to v100 so there has been some change in the validator set here some validators from here have exited v1 to e20 here have exited

and some new validators have entered which is x1 to x20 so um the what the attacker has done here is forked off from block c0 and created a finalized uh finalized block in a fork which is not the main chain and the validator set at c2 is going to be v1 to v100 which means none of the validators from c0 have exited and no one new has entered so this causes some immediate issues in our proof-of-stake blockchain the guarantee that we have we must have

from our consensus mechanism is that if there are two conflicting finalized forks then at least one third of the stake has to be burnt at least one-third validators must be slashed but since the violator set at these two finalized conflicting blocks is not the same these guarantees are not going to hold and specifically since there is a 20 difference uh in these validated sets uh the safety threshold that we have which is the number of validators who must be slashed in case of conflicting finalized blocks that number which is usually one third is going to drop uh by uh 20 so instead of 33 uh only 13

of the validators will be slashed in this scenario so how can this attack be concretely concretely applied to a network well let's say that we have a node which is trying to sync to the existing ethereum network then the node is going to ask the network to send them the blocks and these red nodes here are attacker nodes which send the attackers fork and these two blue nodes are honest nodes which send the honest main chain so these attacker nodes are going to send c2 from the previous example and the other

honest nodes are going to send the honest main chain which is c1 now from the perspective of the sinking node uh both these forks have been finalized and there is a consensus failure and there is no way that the node can determine which the actual main chain is so we definitely have a big problem on our hands here and this must be rectified um and the way we do it is by using the concept of weak subjectivity where the sinking node not only asks for blocks but it also asks for a recent state from less than n blocks ago and uh our duty here is to calculate what this n what a reasonable value for this

end should be uh so why this attacks only uh this attack only affects a subset of the nodes so nodes which are already online at the time of the attack from their perspective it seems to them that a finalized fork has like suddenly appeared and they can safely ignore this fort because well they have been online and validating the main chain uh and there was no indication of a fourth before in proof of work terms this is uh this would be similar to a reorg but nodes which try to later sync to the

network uh will definitely not be able to um not have access to the extra information that uh the nodes which are online have and they won't be able to determine which the honest chain is so the question we must ask to calculate uh the n for our weak subjectivity state uh is that what is the most recent such c0 from where the attacker must fork so that the attacker experiences a slashing of lesser than one-thirds minus d fraction of validators this one-thirds minus d is going to be the new safety margin of our proof of

stake blockchain so instead of it being a fixed to 33 percent that is one-third uh it's going to drop down by a factor of d and we'll call this the safety decay and let's calculate what this uh what this uh most recent c naught should be for various values of d so uh after some calculations we we arrive at this table and for more in-depth uh analysis you can follow this link so over here we see that so this is kind of the the duration of the most recent c0

which is the week's objectivity state or the week's objectivity checkpoint and it it depends on what the value of safety decay d is set to be and it also depends on the size of the validator set so it depends on the validator set size because that number determines how fast validators can exit and enter the system so obviously that determines how fast an attack of such kind can be conducted so the the number we are aiming for here is going to be uh 10 safety decay which means our consensus guarantees that at least 33 minus 10 of validators are slashed

for conflicting finalized checkpoints um and for more than 260 000 validators this duration of the most recent c0 which is the week's objectivity state is going to be 3200 epochs which comes out to be somewhere around two weeks so this means that nodes which are syncing to the network need to have access to a recent state from within 14 days ago and so we come to a call to the community which is that providing this latest weak subjectivity state from within 14 days

ago is essential to the security of the network it allows syncing nodes to uniquely determine what the main chain is and leaves them and renders them invulnerable to such kind of long range attacks and we expect that organizations or users who are running ethereum 2 nodes can provide the state on their website or through some other channels and if not the entire state then at least some kind of a checksum or a commitment to the state can be provided so that syncing nodes can obtain the state from elsewhere

but still verify from users that they consider honest what uh basically the authentic authenticity of this week's objectivity state um and which organizations or users might these be who are sharing this week's objectivity state uh well the the most natural kind of choice for this or or the most most natural actor who kind of has this duty is block explorers so ethers can beacon chain uh block explorer etc can provide the service large companies who are invested in the ethereum ecosystem

uh maybe something like consensus etc can provide the service uh client development teams so within the ethereum to research and development group we've had a lot of discussion on whether client development teams should host their own nodes and provide these weak subjectivity states to users of their clients and the general feeling seems to be that it should not be a duty of the client development teams to to kind of do this uh it's it's a big fiduciary duty um and this is ongoing conversation about this the last major actor who might be

responsible for this can be ethereum foundation but that requires a larger uh discussion and debate in the community and there are a lot of open questions that this um this has which is who must be providing these weak subjectivity states and what is the justification for them doing this and is there a need for a technical standard for the distribution of these states uh maybe something like um should it be verified using checksums is there a signature standard needed etc and for for users who are curious

as to what this means providing the state is actually not that expensive the total state size depends on the number of validators in the system at that point so for 100 000 validators the state comes out to be around 18 megabytes and for a million validators it comes out to be somewhere around 130 megabytes so it's not insanely huge uh the state is kind of relatively small definitely relatively definitely a lot smaller than the eth1 state and uh for for curious people who want to calculate the size of the state the fixed amount is kind of six megabytes uh total and for every 10 000 validators you can add 1.2

megabytes for it so what might this look like what might uh this look like for users who are who are just starting up their nodes and trying to sync to the network well this means that um well first they have to download some client software and before syncing their client software to the ethereum network they have to download a week's objectivity state from some provider and for example this could be like my own personal website where i am providing this week's objectivity state so maybe for example this uh in the medasha testnet if the the latest weak subjectivity

epoch is uh one two three four and the checksum is this the user can download the state uh verify the checksum against this and maybe the user can navigate to some other weak subjectivity state providers and uh see what the checksum is from them and what the latest epoch for the subjectivity state is uh and kind of verifying their own uh network of trust and download that after downloading it and and verifying its authenticity um the user must input that into their client maybe as a command

line parameter or or something else a standard for that is yet to be set with this information uh the client software should be able to reliably sync to the head of the main chain so something like this is kind of essential to the security of ethereum too that's all for this presentation and thanks thanks for listening you can reach me on twitter at this handle and if if you want to reach me by email you can email me at aditya at ethereum