 Hi, I'm Shui-Peng Lin, and you can also call me Nicholas. I'm from Ethereum Foundation. Today I'll be talking about weak subjectivity and how the syncing protocol works in eth2. So this talk consists of three parts, weak subjectivity and eth2 sync. And finally, I'll make a brief introduction on the fortress rule used in eth2 right now. So first, I'll talk about what subjectivity means in its context and why is it weak. So what is objectivity means in its context? So objectivity in its context could be, for example, like proof of work, how much work done, how much electricity spent. And so joining the Bitcoin or Ethereum network knows it can request proof of work from any peers. And then he can use this proof of work to objectively identify the canonical chain. But in proof of state, the work could be like running state transition, creating verifying signatures. But these work are tiny compared to proof of work. So every validator can create super long forked chains secretly at any time. And so this enables the long range attack. So basically in a long range attack, for example, say Eve is an attacker. And he first requests a withdrawal on the main chain. And after some time, his withdrawal is successfully processed. She has no stake on the main chain. And later, Alice goes online. And now Eve can create a forked chain. And on that chain, she did not withdraw and continues to vote on the forked chain. And now Eve can feed this forked chain to Alice. And later, when Alice finds out that Eve has been feeding her with the forked chains, she would try to use this forked chain as a proof to prove that Eve was double voting. And she would send this evidence to the main chain. But then she would find out that Eve no longer has any stake on the main chain. So subjectivity in this context means that you need to trust some sources to identify the connectable chain. And why is it weak? It's weak because we only need to trust when, first, you join the network for the first time. Or second, you will offline for a long time. For how long? It depends on how long it takes for the attacker to withdraw their stake. And this is called the weak subjectivity period. And weak subjectivity period is going to determine if we're going to need trust when we are sinking. So next, I will talk about how the sinking protocol works in ETHU. I will walk through how the client sink in three different situations. And the first is how the client sink when you boost your node the first time. And the second one is when you go offline and locking back before the weak subjectivity period ends. The third situation is when you stay offline for too long, for longer than weak subjectivity period. First, how does the client sink when bootstrap your node the first time? You need to trust. You trust the bootstrap nodes. You trust the genesis blocks, genesis state. If the genesis is already waybanned in the past, you will trust latest checkpoint instead. So say if now you have a trusted genesis or latest checkpoint, you will connect to peers and you will first exchange latest checkpoint and head blocks and some other info to decide if you two are on the same chain. And if you are, then you will start requesting missing blocks. Or if you are not on the same chain, you will simply disconnect. So second situation, how does the client sink when you go offline but locking back in time? First, you still need to trust. You trust the bootstrap nodes, or maybe you can use the peer info you persist in the database during that connection. But now, you do not need to trust the latest checkpoint because you can use the checkpoint the less time you were online and start sinking from there. It's mostly the same. You have the checkpoint and you connect to peers and you start exchanging latest checkpoint, head block, and some other information to decide if you're on the same chain. And if you are, you request missing blocks. But note that the client will only support requesting blocks since the start of the week subjectivity period, which means that you won't be able to sink the blocks that's older than the start of the week subjectivity period. And if you are not on the same chain, the peer will notify us and then we will disconnect. Third situation, how does clients sink when you stay offline for longer than week subjectivity period? So it's basically the same as the way you sink when you bootstrap node the first time. You trust Genesis block or you trust the latest checkpoint and start sinking from there. Once we finish the sinking, we will have a picture of how the chain or how the block trick looks like. And then we'll apply the fortress rule to get a score of each chain. And then we can identify the canonical chain. So before I get to the fortress rule, there's two types of trade points. First one is finalized trade point. The second one is justified trade point. And we do not override the finalized trade point unless there's an attack. But in that case, we can know for sure that at least one third of the validating ease will be burned, so that type over here. And for justified trade point, it can be overwritten. We will switch to the more recent justified trade point. So after justified trade point is decided, we will apply the fortress rule on different four chains. And the score counting starts from justified trade point. But here, we cannot use longest chain rule, because as I previously mentioned, the attacker can secretly create super long four chains anytime. So what fortress rule do we use? We use element dGhosts, stands for latest message driven ghost. Ghost stands for greedy heaviest observed subtree. How does the ghost fortress rule works? So we have different four chains here. And the y square is the block. And the green circle is the attestation. The attestation is the validator, the vote casted by the validator. The validator would vote for the block that they think is the head block of the canonical chain at that time. So we have the votes. And then we will do the score count. The score of a block is the sum of the score of all his child blocks. And once we have the score count, we will start from justified trade point and goes all the way down to the head block. And in each state, when there is a fork, we choose the one with higher score. And so in ghost fortress rule, we will have the chain on the top as the winning chain, as the chain with highest score. Next, how does the elementy ghost works? On the post by their ex-research, summarized pretty well. You don't care test votes, whose sender might not receive other messages due to the network latency. In short, it means that we only count the validator's latest vote. So now, say, there are six validators, and these are the votes they cast. And since in elementy ghost, we only count the validator's latest vote. So this will be what the vote count like. And so we will get a different score count and apply the same choosing rule. We will have the chain on the bottom as the winning chain. And now I want to briefly mention the optimization on elementy ghost. The idea of the optimization is basically that when we run in a full choice rule, we skip the blocks that no validators vote for. And so this will save us time and memory when traversing a block tree back and forth. There's one thing worth mentioning is that we're seeing blocks, but not the attestations. So we wait for attestations to be propagated to us. It can come in as a form of single attestation, aggregated attestations, or attestations that are included in the blocks. And we take all three kinds of attestations into account in our full choice rule. But since we do not think the attestation means every node could receive different attestations at different time. So every node could have different view. They could have different vote count for each four chains. So this creates a window for the attacker. The attacker can withhold attestation and broadcast them at once to make a victim switch between different chains repeatedly. But there's a prerequisite for this attack is that there has to be a temporary network failure. And one attack is called decoy flip flub attack. And it can be motivated on the research forum. And one possible mitigation is the recent proposed, recently proposed variant of ghost is called fresh message-driven ghost. And insured is basically that we do not accept attestations too long ago. For example, we do not accept attestations from maybe two epochs ago. And okay, that's my introduction on weak subjectivity if you're seeing a full choice rule today. Thank you. Thank you. Thank you.