 Hey everyone, thank you for turning to talk about surviving 51% attacks in blockchain. My name is Yaz, I'm a developer at CLABS, and this talk for DEFCON for the blockchain village is about what happened during 51% attacks and how to mitigate, how to minimize their impact and how to handle them in general. And yeah, let's get started. So, my name is Yaz, I'm a developer relation, been working in crypto for a while in crypto community since 2018, and I've been a community member within Ethereum was when I first got attracted to crypto back in 2016. And my background had been in software and hardware engineering. I've worked on Ethereum Classic, I've worked with the Ethereum community, and with Hyper Ledger and the EEA, and currently I work on Selo, and I really love the EVM, the Ethereum first world machine, so run EVM. And yeah, so let's get started with the talk. So for the agenda for today is we're going to first, we're going to, this is all about 51% attack and how to like handle 51% attack in blockchain. First we're going to cover what is Nakamoto consensus. Nakamoto consensus is super important, even if you understand it to some degree, to try to like define what are 51% attack and how do you occur. Then we're going to talk about blockchain reorgs and 51% attacks. Then we're going to give a recap of the first 51% attack on ETC summer of 2020. Then we're going to give a brief recap of the following two 51% attacks on ETC. We're also going to cover the impact of the 51% attacks on blockchain in general by the analysis done on ETC. We're going to talk about all the solutions that have been proposed on Shane last year and continue to do so, and also all the solutions proposed off Shane. Finally, we're going to talk briefly about, we org attacks now with MEB, which stands for minor extractable value. We're going to cover the first section. Let's try to understand what 51% attacks are before we talk about ETC. What is Nakamoto consensus? From a high level, Nakamoto consensus is a solution to the Byzantine general's problem. The Byzantine general's problem is a famous problem in computer science. Basically, from a high level, you're trying to answer the question, if you have an environment where you have multiple independent nodes, how do you create consensus around the majority of those nodes so that they all can reach agreement? Because you're presuming that some of those nodes are going to be faulty and stuff, but in that situation, you still want to start to solve the situation to get the majority of the nodes to agree on consensus. Nakamoto consensus is a solution to that problem. Nakamoto consensus also requires proof of work. So proof of work from the context of mining is basically independent computer that are competing with each other to solve cryptographic problems that are computationally heavy, and that is the proof of work from a high level. Also Nakamoto consensus requires that the longest Shane is the most valid Shane. So what is the longest? It's not the longest Shane if it has more blocks than another Shane necessarily. It's the longest Shane if it's the one with the heaviest amount of work. So the heaviest amount of work would consider it the longest Shane. So the consensus mechanism that is Nakamoto consensus solved the Byzantine general's problem up to 51% of the network, which is measured in hash rate. So in other words, if you define the entire spread of the network in hash rate, like hash rate, which is how the miners are mining and the rate of mining and producing hash is what we consider the hash rate. So the consensus mechanism solved the Byzantine general problem up to 51% of the network. So up to 51% of the network can be honest and anything higher it can start to impact the network. And if you read the Bitcoin white paper, Nakamoto consensus essentially is the most important innovation in the Bitcoin white paper. So let's touch up on uncle blocks before we go into reorg and stuff. Uncle blocks are happened when you have two blocks that are produced at the same time by two independent miners. So let's take a look here before we describe it more. So if you look at block 10, which is like the last block and then you have block 11, the one after it, and then block 12. Let's assume on block 13, two miners at the same time discover block. So what's going to happen is this temporarily split the network into two, into two chains. And all the miners will either mine on either chain at the same time. And once the next block is produced on one of the chain, in this case, the top chain produced found block 14 before the lower chain, then the lower chain would be like the block in the lower chain would be considered an uncle. So that's how the uncle gets produced. Yeah, so in Ethereum and Ethereum Classic, due to faster block generation, uncle block generation is much higher because blocks are being produced every 10, between 12 to 15 seconds. And because of the rate of production for blocks, chances are another miner is going to find immediately a block and uncle block weight is being generated higher than in like compared to Bitcoin, which is a 10 minute block window. Miners here can include uncle block up to six block headers from the chain head. So let's assume block 14, like let's assume it's a block number 19 or 20. So you can go up to six block headers. That's when you can extract the uncle and get the uncle reward up to six block. After that, it becomes a, there's no reason like it can be extracted and like there's no rewards there. Like so for every block that try to get the uncle block up to six blocks, the reward keep on decreasing on the uncle rewards. Now let's talk about reorgs. We are an event where a block that was part of the chain that was a canonical and it's children blocked or replaced by another chain that has more work generated in their force and you're longer chain. Let's talk about this a little bit more by talking, looking at the diagram. So I realized that the diagram first is talking about an attacker chain, but before we even think about attacks, right? Let's think about how would this situation happen in a normal environment or stuff. It's very rare for this to happen, especially with long blocks. We are, but let's assume there's a chance that it can happen non maliciously. So let's assume a block number 10, there's an internet outage in China or there's a firewall in China that doesn't allow the Chinese, like internet in China to communicate with the rest of the world. We know that currently Bitcoin migration is leaving China, you know, going to North America, but let's assume that's not the case for that. So assuming the Bitcoin mining operation in China is much heavier, like a hash rate related compared to like the rest of the world. So with this, let's say at block number 10, there's that internet disruption, like or disconnection between the internet in China and the rest of the world. So what's going to happen? If you look at the top one, let's assume this is not the attacker chain, let's assume this is the heavier chain because of the chain with mining pulled in China. So that's going to keep on mining locally in China. It's going to be disconnected geographically from another network than the other chain, like the global chain. And the global chain going to continue mining without including blocks from China or hash rate from China. But let's assume this only happens momentarily, like there's an internet outed in China that probably like 10 minutes or something and then it would covers. So because China has a higher hash rate in this example, what's going to happen is by block number 16 or like whenever like the internet comes back on or like it doesn't get firewalled or whatever, the geographical rest of the network is going to see this incoming block from China and realize it has a heavier amount of work than what's currently on chain. So it's going to invalidate the canonical shame and it's going to include all the blocks coming from China. So blocks 11, 12, 13, 14, that happen the moment there is an internet outed will get included in this stuff on all their transactions. So what happened to the transaction inside the canonical block or the canonical block is more if you're attacking, but like a definition if you're attacking, but let's assume this is let's call it the geographical shame, all the transaction in it will get removed and because the block is being reordered, they're going to go back to the transaction pool and they'll be waiting to be re-included back into the network, into the blocks. So this is the very rare event. However, it can be done maliciously. So malicious reords are when or 51 percent of tax is when assuming this instead of an internet outed, the attackers on purpose not connecting or peering with the rest of the network and not broadcasting their blocks and they do this because they have a higher amount of hash rate than the rest of the network and then when they feel like they have enough block depth, the broadcaster blocks to the rest of the network and that would we are different. So we're going to cover later double spend, but normally what happened in the attacker chain, it's not going to have a lot of transaction because it's not really an honest chain. It might have one or two transactions for the double spend attacks while all the transaction in the canonical honest chain will get removed and go back to the transaction pool and waiting to be re-added to a newer block. So if a block depth is one or even like two blocks, that's really normal because of latency delays, because this is a geographically distributed network. Someone who discovered a higher, like a block with a higher work than was already included in the chain, there might be a brief delay and then that gets added. When a 51% attacker or when a miner can control more than 51% of the entire half and it allows them to rewrite the chain history. So now that we covered what 51% of tax are, let's do an overview of PTC 51% of tax. So I like to call this event from like the summer 2020, the hot 51% attack summer. So 3 at 51% attack in late summer 2020 happened on Ethereum Classic. ETC experienced before that a 51% attack in early 2019 before, like in January 2019 there was an ETC 51% attack. But the one that we're going to cover for this talk is the one that happened in summer 2020 and late summer 2020. All the attack resulted in double spend, but the last one is not really clear. Like the third 51% attack of the summer is not clear or the amount that's been double spent. And the block depth kept on increasing with each following attack. The victim were mostly centralized exchanges and the losses were in the millions in USD. The mining pool that got reorg also lost under a block reward. So that was really interesting as a situation because a lot of people who are believing that the motor consensus philosophically don't really consider the impact it had on minor, especially if the block, we are depth is really super high and stuff. And what ended up being a situation mining pool were complaining. They're really suffering because all their block reward had been removed. And yeah, it really impacted the miners. So let's do a breakdown of the first 51% attack. So I've been woken up at 4am on a Saturday night by Hudson Jamison. He called me Hudson, one of the community managers in Ethereum. He did an amazing job. He called me at 4am. I was like sleeping on a Saturday night, August 1st. And he told me about the network like, you know, ETC being 51% attack. So woke up network would be 51% attack started talking to some of the engineer working at open relay who detected that attack and doing an analysis. So we started doing analysis to get it early in the morning. So we realized the block depth for this attack with 3594 blocks from blocks 1090, 4146 to 1090, 7746. So the offending minor is 0x75d is what we call him for now. But the more interesting issue on top of the 51% attack was ETC as a network was split into two networks. Like for a long time they were not like, you know, adjusting this. And the reason for this is what we call a real cap. So what is a real cap, right? So in you, like, when you think about immutability as a philosophy and a concept in network as a specification. Immutability is like, you know, data cannot be changed for like, you know, probabilistically for a long time forever. And Bitcoin, you know, immutability argument in Ethereum and like Ethereum classic, specifically, it's all about immutability. The problem with immutability as a specification, it doesn't really reflect the reality from a node and client, like Ethereum client behavior. The reason for that is because clients need to have a specific amount of reward. Limit. The reason for that is because clients need to have a specific amount of reward limit that they can include within their software. And the reason for that is because of like memory requirement performance requirement and stuff. Like if you include more than that limit, it really degrade performance. So what we discovered was and in this scenario, two different Ethereum clients had two different, we are cap. So open Ethereum, which used to be called parity, had a 3000 blocked up, which is different than get this we are cap of 90,000. Now, this is a consensus inconsistency. And that's the problem that still exists today in Ethereum clients. Luckily in Ethereum is super expensive, expensive to get over to 3000 blocked up. However, an ATC you'd really cheap at the time. Now, if you remember the real cap for parity, like open Ethereum is 3000 blocks. Now, what was the real limit, the real number, 3594 blocks that were the real. So the real, the 51% attack was higher than the real cap for parity. So parity, what happened in parity, open Ethereum saw the new incoming real that was higher than the real cap and it said, wait a second, I'm not supposed to be including you because you're higher than my we are cap. So I'm going to reject this we are. And we are like parity nodes, which are a minority on the network kept, you know, validating on the older chain. Get we org is 90,000. It's a huge number. So the majority of the network was using a forker gap called core gap. And they had the 90,000 we are cap. So they accepted that we are from the attacker. And it continued mining on the majority chain. This, from a coordination point of view, it wasn't like, it was kind of like really hard to kind of understand what was happening early on. And then it became very challenging to coordinate, but the coordination mechanism and how to fix it was basically doing an app. We kind of figure out everyone who was running an open Ethereum node and requesting that they start running core gap. Is that like what you did to get for it, because they're validating on the old chain, didn't know what the right chain was. And, you know, if you follow the majority chain, it was easier from a coordination point of view to direct people to run open Ethereum node under majority chain. Now it's like the other thing that happened with a double spend attack, which we're going to cover soon. But like, yeah, from a coordination point of view, it was easier to get open Ethereum to either re-sync the client because once you re-sync with the rest of the network, the reorg is only local information to the node, right? So if the node is re-syncing from scratch, it's not going to get any reorg information, it's just going to continue syncing with the majority chain. So that was another option. So let's cover double spend attacks. So if you remember this diagram from before about reorg, right? So let's say I'm an attacker and I start to like, on block number 11, I'm not broadcasting my blocks and I'm just like mining privately without broadcasting my blocks. So how would I attack the network through a double spend attack? On block 11 below, the one with DX, here's what they normally do. So basically the attacker deposits a large amount of Ethereum or Ethereum Classic in that case and exchange wallet. So the exchange wallet like Binance and stuff, Binance or like Coinbase and stuff, these are the, like an example of the centralized chains. Basically the block, like from the canonical on a screen, if you have a high value Ethereum or Ethereum Classic, you basically deposit it into the coin, into like a centralized exchange account. Now what you do after is you trade that deposit for something that is not related to that network, like let's say Bitcoin. So you put your Ethereum, you deposit it into Coinbase and you trade it for Bitcoin. Then you move your Bitcoin out of Coinbase or Binance. Now your Bitcoin is on your own, like privately owned, like externally owned account on the Bitcoin network. It's no longer part of the centralized exchange account. So what happens to the attacker while mining on like privately while they're doing this attack? So on block 11, remember on block 11, on the canonical chain, they moved their funds. So block 11 on the attacker chain, they can move their Ethereum to another Ethereum account and we'll go over a second why they do that. But yeah, so they do that and then, you know, they mine enough blocks to be heavier than the canonical chain and then they broadcast it. And then we covered what happens is when you broadcast it, if you see the red X marks here, that creates the reorg. So what happened in the reorg, the transaction that you, like the attacker did to send the money originally in the canonical chain to Coinbase. Here in this example, we'll get invalidated. And then we'll get pushed back to the transaction pool. Now, if it gets pushed back to the transaction pool and it gets we mined in a future block, it would still transfer that same transaction with the same account back to the Coinbase, back to Coinbase deposit and stuff. So you don't like, if you, the attacker doesn't want to do that. So by moving in block 11 on the attacker chain, by moving their Ethereum to another account, another Ethereum account, the transaction and the canonical chain, when it gets we mined, it will be invalid because there's no more money in that account. So that way that's how they double spend. They double spend by using that same account and trading it on the canonical chain for Bitcoin. So now they have Ethereum and an equal value with Ethereum and Bitcoin. So let's talk about the impact of the first 51% attack this summer. So because of this, there'd been a major migration away from open Ethereum as 3000 block, we are capped with 2 risky. So folks decided like this is 2 risky if you're ready to 51% attack with higher than the we are capped. So it was good to stay around. Clients like Ethereum is mostly adopted with core gap and hyperlegger based through core gap with the majority of the network and hyperlegger based through which is an Ethereum enterprise client. People started running that as well. Some people like we just discussed earlier shows to we start to open Ethereum node even though they were discovered and encourage more to support core gap and hyperlegger based through that would lead to a brief issue around centralization around core gap being the dominant node in the network and having one client development team building on that. But the tradeoffs were, you know, like compared to staying with open Ethereum was like it felt it was better just to move everyone to core gap. There's been a heavy increase in block confirmation depths on Coinbase. Other exchanges followed. We will cover that in a sec. And then there's risk of delisting ETC surface transfer. And then there's risk of delisting ETC surface transfer. And that's mostly from OK exchange. The first like OK exchange was as well. The victim of this attack and it resulted in 807,000 ETC stolen in that double spend attack. So that was like a number in a multi millions. So let's cover a brief summary of what happened for the two following attacks. So the first one started in like July 31st. And the second one is August 8th, 2020. The block we are here with 4,236 blocks. The one before that was about 3,500. The double spend amount was 465,000 ETC, about 3.3 million. So Bitfinex was one of the victims and not the only victim because the attacker started moving allocation of funds separately to some exchanges and to other accounts and stuff. And Bitfinex was one of the victims. Majority were geth nodes as network moved away from open Ethereum. So there was no another chain split because by then people were being directed away from open Ethereum to get. So the interesting thing about this where the attacker used stolen funds from the first attack to do the second one. And this is based on the analysis done by Bitquery, which also discovered Bitfinex with one of the victims. For the third attack, which followed on August 29th, 2020, the block we are here was 7,000 blocks deep. That was about two days worth of block reorgs. Nobody at that time did any double spend amount, like analysis and how much was double spent. By then it was a weird attack because there was very suspicious timing. It happened right when the community decided to have a call about mitigating those attacks and how to mitigate them. So it was a very suspicious timing. So here's a cool thing that, you know, most of the attack came from NiceHash. NiceHash would tell you that it doesn't come from them because they don't own any hash rate, but they're just the marketplace for hash rate providers looking to rent after hash rate and people looking to bid on rentable hash rate and stuff. But yet being the market maker and not doing any KYC, they should, you know, have some sort of blame for this, but that was like the gist of it. But like the attack came from NiceHash or from the rentable marketplace that they do a market making operations on, you can notice that the first attack happened around 1st of August. So the attacker rented hash rate on NiceHash, and that's how you see a spike. So the spike is basically the price of like, the price here for the rentable hash, for their ETH hash, which is like the hash and algorithm, it spiked up. What is spiked up means there's less amount, and so the price increases for the remaining amount. So that spike was used for the duration of the attack. The second attack, you can totally see the spike as well around the 6th of August is stuff and that was like that. And this diagram came from Bitquery, but like the image is actually like NiceHash dashboard. So let's talk about like what happened, the impact of those attacks and the mitigation strategies. So what is the impact of the 51% attack? So we've covered this briefly before, but centralized exchanges increased their block confirmation. Many have increased it to two weeks of blockchain confirmation, at least for the ETC, including especially Coinbase. Now, the reason you include your blockchain confirmation during the double spend, if you remember before, the attacker would have to like, you know, on the, on the honest chain, let's go back to this. Yeah. So the attacker on the honest chain would have to send their money to a centralized exchange and deposit it, and then they would have to convert it to Bitcoin to withdraw. By centralized exchanges, when they increase their confirmation, so the longer the confirmation is on the exchange, before somebody on that exchange can use that money, the harder or the more expensive it is for the attacker to pull up the attack. Because remember, at the same time, the attacker is mining on a private chain or like a hidden chain, and that costs the attacker money as well. So by increasing confirmation time for two weeks, that means the attacker would have to be mining for more than two weeks in order to pull up this attack, which is super expensive, even for Ethereum Classic. So yeah. So that was like the resulting mitigation strategy by exchanges, which was actually recommended to them by the Ethereum Classic community, like increase your blockchain confirmation. However, there's also philosophically, there might be better alternative that where you do it, depending on the transaction size. But yeah. Then there was a discussion about majority honest miners to fulfill Nakamoto consensus security assumptions. Now I understand this is a mouthful, but basically if you read the Bitcoin white paper, Satoshi Nakamoto talks about majority honest miners, like that's how you can fulfill the security assumption of Nakamoto consensus. You can only fill majority honest miner security assumption if you have, if you had a dominant network using that hashing algorithm. So this, in this case, Ethereum Classic was using ethash mining algorithm, but it was not a majority honest miner situation because ETC using ethash is also the same reality with Ethereum. Ethereum uses ethash and they're a majority net. So in this example, ETC is a minority chain. So a majority honest miner on Ethereum might not necessarily be honest miners on ETC because ETC is just like a smaller halfway compared to Ethereum in this case. The other thing that was being done with KYC on nice high-style order, which didn't work. Basically some folks on ETC Labs requested that nice half need to do KYC on all the buy orders to know. So once, if you do KYC, you can tell where the attacker is coming from because you know who the attacker is, but nice half didn't want to do that. So the ETC lab team worked with Cypher, Trace and legal work against nice half. The angle they had was that it's in violation of the CFAA, which stands for the Computer Fraud and Abuse Act because the argument was they're enabling selling hash power as a cover for money watching. And then chain analysis was consulted on cracking stolen fund. The problem with these analysis as well is the attacker can be using stolen identity or stolen account per exchanger in order to do this execute use attack. And the moment that the money transferred to other exchanger in different jurisdictions like Russia, it becomes super hard to crack down where the money going. And then the other impact which we covered before, honest mining for looser rewards and that was like very painful for them. And like it was something that was like, you know, it inspired like trying to figure out more solutions so that miners can continue honestly mining. Do it also we talked about delisting with like okay, change with the major one of them. And finally, like network stability is a big issue because in a way if the consensus are destabilization situation where the consensus is keep like getting reordered and stuff and for the average user it's like inconsistent user to network. So let's talk about the solution proposed on chain of stuff. So the most popular, like one of the most popular one is the hashing algorithm chain. So we covered before majority honest minor to fulfill Nakamoto consensus security assumptions. So the best way to like, you know, fulfill the security assumption of Nakamoto consensus is if you have a dominant hashing algorithm especially specifically for your network, that way you can create a new marketplace for this algorithm. Miners can build like ASIC if they desire and it becomes the majority chain that uses that mining algorithm. And that way you don't have to rely on e-tash in order with e-tash is more dominant on Ethereum. And that way ETC does not become a minority chain. One of the proposals was like KShack 256 which were shot three and that was the most popular one. So it's a popular story, but it hasn't been even a year later implemented. The other thing was mess. Mess stand for modified exponential, subjective scoring. It's been controversial, but it's been implemented on a node level. So in other words, it did not require a hard work. It was on the node level. So any get node can implement like toggle mess in order to mitigate or minimize the impact of 51% attack. Now, what does it do exactly? It basically mess at subjectivity to how node perceive new block that appear much later than what is considered cannot. So the longer it takes for a new block to appear that might attempt to reorg there's an exponential function there and it makes the node more subjective about how it perceives them. So it takes longer for it to appear with a new chain and stuff. It doesn't really mitigate 100%, 51% attack, but it heavily discusses it. Checkpointing was proposed by IOHK. It was not a very popular choice because it relied on an external node and it removed the need for Nakamoto consensus. So that has not been a very popular choice because in ETC, the community is very almost malicious about Nakamoto consensus. Merge mining with Bitcoin proposal from root stock would not popular either. So the problem with merge mining is you rely on the entire security of a larger network like Bitcoin, which might make sense, but like if you think about it, anytime anyone wants to sync up a node with Ethereum Classic or any other network that is smaller that is merged mine, they also need to sync up the larger network and that's like, that proved to be very from a user experience really bad. And at the same time, merge mining philosophically doesn't really fulfill like honest mining with proof of work and Nakamoto consensus because you rely on the security of another network. So the proof of proof from very block, it's not been very popular. It's been discussed, but it's like a solution that the best way to describe it, nobody wanted because it removed the need for proof of work because you're mining on another chain and stuff that is more according to their paper environmentally friendly. They even been proposed kind of proposed this on Bitcoin and it's not been popular. So there's a penalty system. There's multiple Pearl Guard which is enabled on Pearl and Callisto and it was inspired by the horizon network penalty system. Basically with this setup is on chain. If you have a VR depth of higher than 60 blocks, there's a penalty system involved and that penalty system would force you to pay the penalty in order to include your longer chain here. The problem with this approach is that introducing a new type of attack that can fragmentize and split the network cheaply and also eclipse attacks can happen with this model. So the solution proposed that have been off chain solution, one of them is defensive mining. So in defensive mining you have a collection of mining pool that are honest miners. In the event that a chain is getting reorg defensive mining can trigger and try to remind the whole chain from that block that got reorg and try to include all the transaction pool like the way it's been and stuff. The problem with defensive mining is it's going to be a net negative attack between the attacker and the defenders and the only one who wins it, the one who doesn't run out of money because it's become expensive and more expensive to reorg each other stuff on a longer chain. Other off chain proposed solutions are monitoring system. So nice hash monitoring, basically monitoring the order book for spikes. So anytime there's a spike in nice hash you get an alert and stuff. So that would one of the approaches. Poor quarks, which is my personal project is an example of that. So reorg monitoring, monitoring is basically when you monitor reorg and your alert participant when reorg and double spend happens. So immediately when there's a reorg you get notified right away and it can help like mitigate against who's getting reorg. Mining pool monitoring has allowed you to monitor pool for suspicious work that doesn't follow the chain header. So let's say I'm unmining with a pool and the pool previous block header doesn't match what is public on chain. That can indicate that they're mining offline away from the public network. And there might be some malicious reason for that. Pool detective is an example of that by MIT DCI and reorg monitor, which we covered. We are we are cracker is by Jane club. So then another approach to dynamic block depths for confirmation basically whenever an exchange. So an exchange doesn't have to have a hard cap value like two weeks worth of confirmation. It can have a confirmation number based on the value being deposited. So if somebody wants to deposit one E and stuff, it doesn't really justify doing a long block confirmation on the exchange but rather shorter one to reflect the amount. But if it's like millions of dollars, you're better off doing waiting a longer time for the block confirmation. Another approach has been would centralize it changes instead of doing longer block confirmations. You do a medium or like whatever amount you already had confirmation, but you delay withdrawals. So you make sure that the attacker cannot withdraw after like, let's say they trade or Ethereum for Bitcoin. They can't withdraw it right away. So that way it minimized bad user experience and incentivizes more people to just continue like using their centralized exchanges. All right. So now that we covered this, let's talk about reorg and MEV briefly. So what is MEV? I'm going to brush over it really briefly. MEV is what we consider minor extractable value, which is a term coined by Phil Dan and blockchain transaction to design to be included in the network, even if not necessarily added to a block immediately because during the transaction but blockchain design never specified transaction ordering or how is a transaction ordered and a block. So MEV basically allowed minor to order transaction in the transaction pool in order to copy profitable like DeFi arbitrage transaction with front running, back running, and sandwich attack. So in a simpler terms, basically if I'm a minor, I look at the transaction pool, there's a lot of DeFi happening in Ethereum and there's like a transaction that would allow for a very profitable arbitrage. So me the minor even using flash loans and stuff, I can mimic that entire transaction with zero cost and put my transaction on top of the original transaction when I submit that block. What that means is that front running, by the way, what it means is it allows minors to front run the user transaction and take the profit for themselves and stuff. And for the for the rest of the PN they still can take the gas fees from the original transaction. So companies like FlashBot seek to minimize MEV by creating a blind auction for arbitrage or what they call searcher to bride minors to include a transaction in minimizing impact on the transaction pool. So let's cover MEV reorg attacks. So given what we know about MEV in general, how would you reorg attack happen? So and it can you attack vectors specifically to Ethereum just because of that you like did a high MEV found in the transaction pool. It's one of the latest areas of research into 51% attack vectors. It differs from other 51% attack that require a double spend due to a smaller block reorg steps. Basically it's minding pooled in theory. You can see a minor like a block that was published with high MEV and reorg the network one to two blocks deep to capture those transactions. So I'm a minor. I see the new block being submitted that's been published. That block has a lot of MEV value in it and it's like super profitable for me if I took that MEV instead and I reorg that network even though it's been published by another minor. So what I would do, 51% attack the network and try to take all those transactions and add them to my block instead. And that is like essentially what the attack is. It's a 51% attack that is one or two one to two blocks deep because you're taking a lot of extractable value of arbitrage opportunity that belong to user to our reminders. The problem with this attack is it causes a negative effect on the entire network and major consensus instability because let's say I'm a minor. I find an MEV that's been published and like high MEV block. I reorg it one block. I take that MEV to myself but there's nothing stopping another minor with the same amount of hash rate from capturing it back and different minor reorg in each other and like it comes down through like how much they want to reorg and stuff. And it's like this is like an important like point because this is going to be major consensus instability. So mining pool to have said that they want reorg the chain. Like they said they don't have intention of reorganization to extract MEV but that's still to be seen. So let's talk briefly about like finally about potential mitigation and minimization strategies. So one way is to increasing uncle block rewards. It doesn't really mitigate but it allows by large uncle inclusion reward when incentive by better mining. So more miners would mind under canonical chain try to include more of the uncle block just to get their reward. And if it's higher it's more incentive for people to get those uncle block rewards. Another way is include like include the uncle hash rate and longest chain calculation. So under canonical chain a minor is including an uncle block and uncle hash rate within the canonical chain would increase what's considered the heaviest chain and that way it's heavier than any private chain that find a reorg and stuff. And otherwise it's monitoring uncles and we used to find if any reorg MEV happened or for uncle block uncle bandit attacks. So we covered like monitoring system so very similar to what you would be able to do. So you can do this with a layer 2 or like uncle and stuff and allow you to steep any monitor up to any misbehavior. Layer 2 at Oracle to determine canon chain. So let's say if you're using optimism or arbitrum and you have an Oracle there to monitor the layer 1 solution like layer 1 network and you have some sort of solution always need to write back the layer 1. So if there's a reorg happening on layer 1 let's say a layer 2 saying oh reorg happening this is not the canonical chain. Me the attacker on layer 1 can reorg that transaction and exclude it. So that L2 becomes problematic because it's like a separate network that can got reorg and stuff. Timeliness detected by the Vitalik has been proposed in a blog post by the Vitalik and it's a very interesting one because it like allowed note to perceive time how time goes by and when a new block or a new chain emerges like it can be very like subjective based on the time that it appeared on. Another one is social pressure. So for mining pool that reorg the network it would in theory destroy their brands and allow miner be like hey I don't want to go to the mining pool and I would rather mine with an honest mining pool. And that happened well in Bitcoin before I forgot with mining pool but it almost had 51% of the network like in terms of pass rate and miner immediately started leaving that mining pool to go to other mining pool and that mining pool like became even like one of the smallest mining pool in terms of pass rate as a result. Finally another one is the network Ethereum and that mitigate the one that allows us to specify the parent block header so if I see the parent block header I submit a block I submit a transaction I say I want my transaction to tie into the current block header that I'm seeing right now so that gets added to the transaction pool if the reorg happened the reorg happening will tie it to a different transaction in ballot so that would be an interesting approach specifying an expiration date how many blocks deep like how long until the transaction gets added to the transaction from the transaction pool to the block and if it goes more than that how many blocks deep then it becomes invalid otherwise like if you know the specific mining pool that are misbehaving having a way to whitelist specific mining pool misbehaving that mining pool can be one way to mitigate against this so yeah thank you I hope you enjoyed this talk about how to survive 51% attack through analysis and stuff you can email me at yas.curieatgmail.com and you can find me on twitter at yasinator so thank you so much