 All right, everyone. Thank you for coming to my session here for Krutui Khan Lab research seminars. Today we're gonna be going over a time stepping attack that was found right before the proof of work to Ethereum, proof of stake, merged in August and September of this past year. And I wanna shout out to the team at Hebrew University of Jerusalem for being able to find this and find such an impactful attack for proof of work chains because not only is Ethereum a major L1 that was in proof of work, but there are many L1s including Filecoin and other ecosystems that are using similarities of proof of work chains. So we will get into it. What we're going to cover today is the problem, the attack and the lessons learned. So generally around this time, proof of stake was a big deal in the crypto ecosystem. We wanted to be able to move to proof of stake for a number of reasons within Ethereum for a single energy consumption, being able to make it more cost effective for, or sorry, to make it where the mining, needing to mine isn't the only way to get into Ethereum. They wanted to create ultrasound money so that people could be able to utilize Ethereum for financial and global economics. And at this time there was many motivations to want to move to proof of stake. But in proof of work, there were a lot of complexities within the chain and within the consensus mechanism. One of the common misconceptions within there is can protocol manipulation happen in Ethereum for proof of work? There were a lot of people in the research community that said, no, there's no attack vectors that could actually be possible to be able to do this at the consensus mechanism level. And so another question was, can Ethereum blocks actually give evidence of consensus level attacks? That's probably this can happen. And can miners attack the consensus layer of major cryptocurrencies like Ethereum and other proof of work chains? They use things like timestamps and block rewards, et cetera. Well, this team actually, a Hebrew University of Jerusalem went to find out. So what their actual problem was, and I love this image that they created on their medium. It's spectacular. It's spectacular. We want to go over the mining difficulty in Ethereum. So just real quickly, in Ethereum with difficulty of mining, the current block changes on the fly and decreases the longer the time that has passed without anyone mining a new or valid block. Just to make sure that you have a certain amount of difficulty or certain amount of overhead to actually make sure the block has been proposed that it's well and good. And now this is done to ensure that interblock times will not be too high in expectation. So what could actually go wrong there? What can go wrong is within the timestamping of that. So between blocks in the mining difficulty, it is determined by block timestamps. The problem with this is that miners have the freedom when setting them. They can create false timestamps. They don't always have to provide honest and truthful timestamps in this example. So in my example here, a miner can start mining a block now but set the block's timestamp to be five seconds in the past or 10 seconds in the future. As long as the timestamp is within a certain bound, the block will be considered valid. Now, these same consensus laws say that in cases of ties, there's like tie breakers in this case, between blocks of the same height, the block with a higher total mining difficulty should be picked to the parent of the currently mined block while the other ones should be produced to the uncle. And this is where the uncle maker attack comes into play. So a miner who wishes to replace that last block on the blockchain can do so by mining a new block of its own which has a timestamp, which is low enough to increase the block's mining difficulty. The last block has high paying transactions or in order to double spend a transaction contained within that block. So long story short is with any Ethereum, you didn't, there weren't actually ideas of how to be able to attack this block, and there's some gaps in between the times. So there was never a specific block that will be mined to actually nine seconds specifically. They would have a gap in between eight and then to 10, but never right on nine. So this uncle maker was able to find the specific difference in there. And so this paper in particular described the uncle maker attack and analyzed the potential strategies, showing that executing the attack in a specific way does not entail any behavior which has a non-zero probability of earning less than mining honestly. And it attacks the honest mining strategy that is held in proof of work blockchains. Now on the right here, you see an honest miner always mines a block with the longest chain. That's a common ecosystem or consensus layer fact. They always publish a block as soon as the block is produced. And in ETH, the honest miner reference refers to uncle blocks that can be produced as many as they can, but no more than two. And so an honest miner will always mine the blocks that are proposed to them. Here though in the attack, this group created an uncle making attack in the wild. So although mining pools produce relatively inconspicuous looking blocks, the F2 pool specifically, the one I'm saying that doesn't have the nine or the 18 or the 27 that are divisible by nine, they definitely do not do this in this pool. And people create different pools within mining environments because in proof of work, specifically the rewards are very fluctuating. You get one reward that's like a hundred acts one time and you'll get one that's maybe like one acts another time. So people will create specific or people, users and miners will create pools to try and level out their rewards equally as much as possible over time. Now specifically whenever a block should have a timestamp difference from its parent, which is divisible by nine, precisely the time at which mining difficulty decreases, that is when the F2 pool hangs around. And F2 pool, nevermind blocks with timestamps which are divisible by nine, instead of falsely setting their timestamps to be one second earlier. This was the main fact and critical knowledge and paper. Other pools, for example, within Ethereum, they actually have more equal out distributions within the time. So they don't actually only at nine seconds pause and then move on to the next one. And people actually within the Ethereum community and different chats and forums came out and said, well, of course we pause it at nine. That's how we actually make money. And that's how we solve so that people don't take advantage of the network. And so it was a really big research that was found in September. So some of the lessons learned are don't just trust, verify these different consistent mechanisms and chains when being able to evaluate and make sure that your pool is actually taking and proving honestly. You always wanna take time to all these different attack vectors. I know like proof of stake was rushed or everyone thought that it was delayed, delayed, delayed. But a lot of the research groups were examining and testing out so many different attack vectors to make sure things like this were not possible. And all in any L1s are not bulletproof. There are plenty of issues and things that people can get to when examining these different L1s. And one thing I wanted to go over before I finished is some of the different attacks that this group went over. The UMPLEMAKER attack was the one that checked all the boxes when it came to being able to picking funds within the Ethereum proof of war chain. These other ones just didn't meet the mark in some of the other strategies that they were able to produce as well. But yeah, I think this paper was really fascinating. Sorry, I can't really go into deep details economically and technically of how and why this came to be. But I found this to be super interesting and something that anyone that's working and developing in the L1 should be very mindful of. So thank you very much. That's pretty awesome. And yeah, to augment David's comment, yeah, super sneaky. Super sneaky. Super sneaky. And it could happen in other ecosystems too. We've got to be mindful. You said that they were from the Hebrew University of? Jerusalem, yeah, Aviv. Aviv Yai, like I believe is his name, is the. OK, no, because I know Guy from the crypto. Because this is left, she asked her. He works at that university. No, he did his PhD there, but I don't remember if it was at the Hebrew University of Jerusalem or at the Technion. Yeah, maybe maybe he might have some if he did it on the group that he might be related, familiar to the group that this does work. Awesome.