 I'm Luya from REI-X. REI-X is a blockchain startup based on Tokyo and working on CASPER research and supported by Ethereum Foundation Grant. So today, I will talk about my research on the security of CASPER. So, you know, CASPER, a consensus protocol, has two properties, safety and liveness. So the talk is divided into two parts, safety part and liveness part. So first, I want to introduce CASPER is not that different from traditional protocols, and CASPER FFG and the CBC is not that different also. So first, PBFT, Tendermint and CASPER FFG and CBC are all categorized into a synchronously safe consensus protocol. So I mean safety does not require any timing assumptions. So basically, in these protocols, finality comes when sufficient number of validators is locked on the block. So let's start with Tendermint. So in Tendermint, a block is called notarized when two F plus one validators is bought on the block. So here F is resunching for the threshold. And the block is finalized when its direct child block is notarized. And when validator is bought for notarized block, that validator is locked on the block. So he cannot vote for conflicting block. So in this case, the first block is finalized. And here, the votes must be collected in on-chain. This is really important point. So here, the reason why we can say the first block is finalized is we know that these validators bought for the second block knows, we know that this validator is locked because we know that the votes are on-chain, right? This is why on-chain voting is very important for these protocols. The reason why finality comes when only when its direct block is notarized is there might be another block in the middle. And we discussed locking is necessary for safety, but if locking is too much, too much strong, does not create some liveness property. So here, we have some unlocking condition. So in tandem, a validator locked on the block is unlocked when he see a higher notarized block. So in this picture, I voted for two, but I'm unlocked because I see the new notarized block here. So let's start with the next is Casper FFG. The Casper FFG is fundamentally similar to tandem, but it's more like chain-based, leaderless tandem. So in Casper FFG, we do not finalize block. We finalize checkpoints. So in this picture, we have blockchain, but we finalize on, say, every 50 blocks or every 50 slots block, right? So yeah. And again, both are still on chain. And the difference between tandem is the fork choice itself is doing the similar role of leader. So in tandem, every validator bought for a block which is decided by the leader of that round. But in Casper FFG, it's a fork choice that decides the view. And unlocking and locking is super similar to tandem. So in FFG case, they are unlocked when they see higher notarized or just justify the checkpoint. So finally, Shibushi Casper is also locking-based consensus protocol, but the locking and unlocking is purely by the fork choice itself. So in Shibushi Casper, every message both block must follow the fork choice. And in tandem or FFG, we included the both on chain. But in Shibushi, we can do the same thing, but more flexibly, we can allow the message to point to the every open both or block. So in this picture, the block B is pointing to open block, but the reason is okay, so yeah, additional explanation. So in this case, this block is invalid because they know that the different chain is more heavier, so this is invalid. And the unlocking condition is super abstracted into equivocation condition that every vote must include his previous message in its message. So in this picture, this block is invalid because he has previous message here, but does not include it in on chain, in message. So the similarity of Shibushi and FFG is that the both is chain-based, so every vote block is voting or supporting for the same ancestor, right? So in FFG, what two point no, they include all from votes in on chain because they are supporting for the same checkpoints. This is also same for Shibushi Casper, but it's more flexible way. So the exact finality condition is something I do not talk in this talk, but we finally finished our formal verification in IZAPL-HOL. It takes more than half a year, but it's a great job, I think. So yeah, pretty much summary is Tendermint, Casper, FFG, and Shibushi is basically based on some locking idea, and the difference comes from whether the locking is based on the notarized checkpoint or block or folk choice itself. So I want to move to liveness, but liveness has a lot of design strategies, so I cannot talk in this 20 minutes, so I today want to focus on two point no liveness. So basically in two point no, liveness strategy is super simple. It's just LMDGhost plus Casper FFG. So LMDGhost is a variant of ghost in which the latest message is only counted. So in this picture, the traditional longest chain rule, this chain is a head. In normal ghost, this chain is a head, but in LMDGhost, we only count the latest message, so the third chain is a head. So to talk about the liveness based on LMDGhost, we need to define when the chain converges. And in LMDGhost, a block is not offered when the chain is supported by more than majority of honest votes. So in this example, say there's 100 total validators and the blue chain is supported by more than 51 votes. In this case, whatever adversely do, the top chain does not be organized. So this is a convergence condition of LMDGhost, but this cannot be observed by protocol foreign validators. This is why we want Casper to detect finality. But for liveness analysis, this is a convergence condition. Yeah, so before I introduce attack on LMDGhost, I want to introduce some fairness property on folk choice. So basically in any consensus protocol, we want some property called fairness. So I mean, any player cannot increase their power against their stake or hash power. But there's something break this property called saving strategy. So adversely can skip their votes. And the later use their votes to flip-flop. This does not work in longest chain because so say we divide into timing to slots, six seconds or 10 seconds. And every three block or vote is adverse for adversely. And in this case, adversely with hold will save every block. But in longest chain, we can add some validity condition that every block or votes cannot extend the future block. So here after some network failure, they cannot use the saved votes to prevent liveness here. But in ghost, every votes does not expired. So here, there's a huge two folk from early days. And but you can use the saved votes in ghost. The folk choice is based on every best children selection on each height. So every vote does not expired. So this turns into creating a new attack on LMD ghost, which I call decoy flip-flop attack. So basically what I want to do is to flip every votes into another chain and go back to another chain and continue. The difference, the big difference in normal goals and LMD ghost is the flip of votes decreases the score. In longest chain or normal ghost, some score of a chain, monotonically increasing. And every liveness proof is based on that property. But in LMD ghost, we cannot have that property. This is the simulation I have. So imagine that two chain, red chain and blue chain. And we continuously flip-flop just before the chain converges. And the result is the necessary saving which the adversary needs to prepare exponential decreases against the adversary power. And for some parameter, 33% attack can prevent liveness for 100 epoch. It's like a few hours, 10 hours by five epochs of savings. And for more big adversary, it takes much longer for the chain to finalize. Yeah, small mitigation of this attack is FMD ghost. It's a variant of LMD ghost to mitigate the saving strategy. So in LMD ghost, we count every vote, every order brought if it is the latest. But in FMD ghost, we only count a vote from the current epoch or the previous epoch. Someone say that it's kind of introduced a new synchrony assumption on consensus, but it's not that true. Because in two point no case, the FFG is decoupled from the chain. So the synchrony assumption does not change. But here still decoy flip-flop is possible because we can have one epoch of savings. So this starts pretty much a new question that why LMD ghost in the first place compared to non-LMD variant of ghost. Especially there's no CBC Casper in two point no for now. So it's a bit easy to manipulate the fork choice. Another interesting topic which I cannot talk today is flip-flopping LMD ghost in CBC Casper. Because in CBC Casper, every message is imposed to follow the fork choice. So the analysis gets a bit complicated, but basically it's mighty case that flip-flop strategy. So a bit no incentives. So you might say savings can be detected and thrashed, but basically to punish liveness failure is as I explained by the Vitalik in this morning, it's different or difficult to distinguish between no malicious failure because it's just my honest no to just get down. So in two point no has some incentive mechanism to punish liveness failure called inactivity leak, but it's just kind mild punishment. So the current parameterization with decoy flip-flop attack, 33% attacker can prevent finality for a few days with 1% cost of the stake. And you know liveness attack sometimes has a lot of reward because there's a lot of layer two solutions in which there's some challenge period and if they can censorship on the flood proof, in plasma and lighting, adversely can get a bunch of money from the layer two construction. So I think it's a new question to how to analysis incentive compatibility in liveness failure. So I think I have a time, so I quickly introduce some attack on Casper FFG which is funded by last year. So in FFG, the original FFG removing the leader in kind of bad way because so these squares are not blocks, it's checkpoints. And remember that unlocking rule in Casper FFG is observation of higher notarized checkpoint. And so in this case, imagine there's 100 validators and this checkpoint is close to two source but it's not notarized yet. But adversely can justify this checkpoint arbitrarily anytime. So in this situation, the folk choice favors this side of the chain so creating a new checkpoint which is close to the notarization but exactly the same at the time, adversely flip the head of the folk choice in that way. And in high synchrony network, adversely can continue this attack forever. So why this does not happen in tendermint? It's simply because leader decides the view of the current round. So what we should do is to have some sort of stickiness property in FFG. So there's a lot of construction to prevent this attack. It's one idea is to not allow the change of the view in the middle of the epoch. For example, you do not allow any new justified checkpoint if it's in the middle of the epoch. Yes, I think it's finished. Thank you.