Users become vulnerable to replay attacks when a blockchain goes through a hard fork. After The Merge, Ethereum Proof of Work, a fork of the original Ethereum Blockchain suffered from a replay attack. What can we learn from this incident? Let’s join&nbsp;<a href="https://www.builder.news/" alt="Builder.news" title="Builder.news" target="_blank" rel="" class="">Builder.news</a> to find out.<img src="https://cdn.builder.news/news/11ed43913e20536da8e6023f659fee92.jpg" alt="Replay attack post Merge" title="Replay attack post Merge" width="600" height="334" class="lykafe0"><h2>What is a replay attack in blockchain?</h2>Before we dive into the post-Merge Ethereum's replay attack, it is excessively important to know what a replay attack exactly is. In short, a replay attack happens when hackers steal users' assets at the time a blockchain splits into multiple hard forks in a form of a fundamental infrastructure upgrade. The recent historical event on the Ethereum network, <a href="https://www.builder.news/crypto-insights/the-merge-a-pivotal-event-for-ethereum" alt="The Merge: A pivotal event for Ethereum" title="The Merge: A pivotal event for Ethereum" target="_blank" rel="" class="">The Merge</a>, is a&nbsp;representative example of a chain upgrade from one to another consensus that leads to various hard forks to be created. Well before The Merge even happens, blockchain professionals had foreseen that replay attacks were absolutely indispensable.<h3>ChainID - Decisive factor in a replay attack</h3>The concept of “ChainID” in a smart contract plays an important role to help users to understand replay attacks more thoroughly. ChainID is a unique identifier included in a <a href="https://www.builder.news/crypto-insights/blockchains-backbone-to-call-smart-contracts-InrUS" alt="smart contracts" title="Blockchain's backbone to call Smart Contracts" target="_blank" rel="" class="">smart contract</a> to make sure that users will be interacting with the right blockchain. Different blockchains have different chainIDs. For example, Ethereum Mainnet’s chainID is 1, Ropsten Testnet's chainID is 3, while Binance Smart Chain’s chainID is 56.When a blockchain goes through a controversial upgrade that will fundamentally change how it functions, much like an Operating System change, its community tends to split. Hence the name hard fork. When a hard fork happens, usually, the upgrade acquiring the majority of supporters gets to keep the same chainID as before while the supporters of other upgrades (or none at all), the minority, must adopt a new chainID, and usually take on a new name as well. If the fork creates two different blockchains, with two different chainIDs, no replay attacks can happen.However, if, for whatever reasons, should the developers of one of the two blockchains do not change their network’s chainID to distinguish the two after a hard fork, replay attacks will lead to a big concern. For a certain period of time, before any new transactions with new upgrades are verified as a new block on each of the two, both will share the same history. Therefore, all users’ digital assets on the original chain will be duplicated, that is, available and valid on both blockchains after a fork. As two identical chains are operating alongside each other, it is not just users’ digital assets that get duplicated, but any transactions they make on one chain will also be valid on the other.&nbsp;<h3>Replay attacks in example</h3>For example, a blockchain forks into chain A and chain B, but the two blockchains still share the same chainID.On Chain A, Lily signs a smart contract that sends 100 tokens to Alice. Since A and B share the same chainID, the smart contract already signed by Lily sending 100 tokens to Alice on chain A, if it works, would also be valid on Chain B. It is just not transmitted on chain B yet.&nbsp;On Chain B, suppose that Lily does not do anything to protect her assets, Alice can potentially “copy” the already signed and executed smart contract on chain A, “paste” and execute it on chain B, and it will also work, sending her the tokens. That's how replay attack happens.<img src="https://cdn.builder.news/news/11ed43913e205ca6a8e6023f659fee92.jpg" alt="Blockchain" title="Blockchain" width="600" height="400" class="lykafe1"><h2>Recap of the replay attack on Ethereum Proof of Work</h2>Now let’s look at a real-life example. A recent replay attack happened with the Ethereum Proof of Work blockchain after The Merge.&nbsp;A few months before The Merge, a group of mostly Ethereum miners had set up a new community to maintain the original Ethereum Proof of Work (ETHW) blockchain. They even declared how Ethereum moving to Proof of Stake (PoS) would mark the end of Web3. So their intention was quite serious, raising rumors among the community that they would not change their chainID, thus competing directly with Ethereum PoS to be the one and only Ethereum network.&gt;&gt;&gt; Related:&nbsp;<a href="https://www.builder.news/crypto-insights/pow-compared-with-pos" alt="PoW vs PoS" title="PoW compared with PoS - What solution is optimal?" target="_blank" rel="" class="">PoW compared with PoS - What solution is optimal?</a>But in the end, when The Merge successfully took effect, they announced the change of their chainID from 1 to 10001. Now, if they already changed their chainID, how could they be vulnerable to replay attacks? It turns out that the exploit wasn’t targeted at the ETHW blockchain but rather towards the OmniBridge smart contract deployment address&nbsp;whose smart contract did not update on time with ETHW's new chainID.&nbsp;This loophole inside OmniBridge allows allows the attacker to rerun a smart contract that was valid on Ethereum Proof of Stake on Ethereum Proof of Work. Here is how the exploit happened.<img src="https://cdn.builder.news/news/11ed430e191b5d55a8e6023f659fee92.jpg" alt="Replay Attack Ethereum Proof of Work" title="Replay Attack Ethereum Proof of Work" width="600" height="311">Simplified graph of how the Replay Attack happenedOn Ethereum PoS, the attacker first transferred 200 WETH through OmniBridge to an address on Gnosis Chain. Since the chain ID of ETHW was already changed, the first part of the duplicated smart contract was invalid, therefore not executed on ETHW. Because of the outdated code of OmniBridge, however, the later part of the duplicated smart contract that ordered OmniBridge to transfer 200 WETH to the address on Gnosis Chain on ETHW was valid.<iframe width="550" height="400" src="data:text/html;charset=utf-8,%3Cblockquote%20class%3D%22twitter-tweet%22%3E%3Cp%20lang%3D%22en%22%20dir%3D%22ltr%22%3EHad%20tried%20every%20way%20to%20contact%20Omni%20Bridge%20yesterday.%3Cbr%3E%3Cbr%3EBridges%20need%20to%20correctly%20verify%20the%20actual%20ChainID%20of%20the%20cross-chain%20messages.%3Cbr%3E%3Cbr%3EAgain%20this%20is%20not%20a%20transaction%20replay%20on%20the%20chain%20level%2C%20it%20is%20a%20calldata%20replay%20due%20to%20the%20flaw%20of%20the%20specific%20contract.%20%3Ca%20href%3D%22https%3A//t.co/bHbYR4b2AW%22%3Ehttps%3A//t.co/bHbYR4b2AW%3C/a%3E%20%3Ca%20href%3D%22https%3A//t.co/NZDn61cslJ%22%3Epic.twitter.com/NZDn61cslJ%3C/a%3E%3C/p%3E%26mdash%3B%20EthereumPoW%20%28ETHW%29%20Official%20%23ETHW%20%23ETHPoW%20%28@EthereumPoW%29%20%3Ca%20href%3D%22https%3A//twitter.com/EthereumPoW/status/1571445910290468864%3Fref_src%3Dtwsrc%255Etfw%22%3ESeptember%2018%2C%202022%3C/a%3E%3C/blockquote%3E%0A%3Cscript%20async%20src%3D%22https%3A//platform.twitter.com/widgets.js%22%20charset%3D%22utf-8%22%3E%3C/script%3E%0A"></iframe>It is worth noting that for the smart contract to work, at the time of the exploit, OmniBridge’s deployment address must hold that much money. At the time of the exploit, the exploited amount was worth around $1000-$2000.Again, in plain words, when the smart contract is replayed on ETHW, the address of the attacker on ETHW did not transfer any tokens to OmniBridge (the different chainID made it invalid), yet OmniBridge paid 200 ETHW to the same address on the other side of ETHW.&gt;&gt;&gt; Read more:&nbsp;<a href="https://www.builder.news/crypto-insights/how-ethereum-proof-of-stake-affect-miners-swTcG" alt="How will Ethereum's Proof of Stake affect miners?" title="How will Ethereum's Proof of Stake affect miners?" target="_blank" rel="" class="">How will Ethereum's Proof of Stake affect miners?</a><h2>How much did replay attacks cost users and platforms?</h2>The attack on Ethereum Proof of Work itself left minor damage to all parties, but it undoubtedly played a big part in a series of problems that triggered the ETHW sell-off. During the two days post the attack, the price of ETHW fell almost 4 times from $40 to $10.&nbsp;To be fair, compared with other blockchain exploits, replay attacks are rather straightforward, making them easier to prevent. Furthermore, because they require some anomaly around chainIDs, replay attacks often occur only around hard forks.<img src="https://cdn.builder.news/news/11ed43913e209b11a8e6023f659fee92.jpg" alt="Blockchain illustration" title="Blockchain illustration" width="600" height="400" class="lykafe3">One replay attack incident included the Ethereum Classic Hard Fork that gave birth to Ethereum Classic (ETC). When some users were withdrawing ETH to their wallet from a centralized exchange, they found out that free ETC was sent to their address and they kept depositing and withdrawing ETH to get more ETC. After this and other incidents, developers have paid more attention to chainID, making replay attacks less common and serious. The case with Ethereum Proof of Work is also not a true replay attack that happens to blockchains but rather an exploitation of outdated codes.&gt;&gt;&gt; Check out:&nbsp;<a href="https://www.builder.news/crypto-insights/how-the-merge-affects-investors-etIkc" alt="How The Merge affects investors?" title="How The Merge affects investors?" target="_blank" rel="" class="">How The Merge affects investors?</a><h2>How to prevent replay attacks?</h2>So how can users protect themselves if two blockchains with the same chainID somehow appear again in the future?&nbsp;Whatever the solutions, they will have the same purpose, which is to ensure that any transactions on one chain will become invalid on the other. There are a few ways to do this.&nbsp;<h3>Use different wallets on two different chains</h3>This method is quite simple to execute.Suppose Ethereum PoW does not change its chainID post Merge, leaving PoW and PoS with the same chainID. After the fork, create 2 new addresses: Wallet B and Wallet C. Make sure you are the owner (you keep the private key) of these two addresses on both PoW and PoS. Then in order, transfer all your pre-fork assets in Wallet A to wallet B On PoW and transfer all your pre-fork assets in Wallet A to wallet C on PoS. This way, transaction-A-to-B on PoW cannot be replicated on PoS and transaction-A-to-C cannot be replicated on PoW. Nonetheless, it is still advisable to watch for any abnormal activities regarding the two new addresses.<img src="https://cdn.builder.news/news/11ed43913e20aa70a8e6023f659fee92.jpg" alt="Blockchain" title="Blockchain" width="600" height="400" class="lykafe4"><h3>Creating nonce difference</h3>Another approach is to create a nonce difference between your transactions on the two blockchains. Nonce here just means order. Transactions performed by a wallet on the blockchain are counted and numbered, much like an order number. This number is also included in the smart contract to differentiate between transaction-1 and transaction-2. The nonce of the contract must be the same on both blockchains for them to be valid on both.&nbsp;Suppose Ethereum PoW does not change its chainID post Merge and you want to sell your newly duplicated ETHW for profit on supported centralized exchanges. Before The Merge, you will need to anticipate how many smart contracts/steps you would have to send to the blockchain to swap all of the tokens into ETHW. Call this number of smart contracts N.Then, after The Merge, on Ethereum PoS, you will need to increase the nonce of your transactions on Ethereum PoS to prevent any of your moves on ETHW from being replayed on ETH. You can do this cheaply by sending yourself 0 ETH N+1 times. Yes, you are paying validators just to increase the nonce of your transactions on Ethereum PoS. Now head to Ethereum PoW. Before doing anything, recheck the nonce to make sure that no self-sending transactions were replayed. As long as there is a nonce difference, you are safu. Once all transactions on PoW are executed, you can just send ETHW to the centralized market and sell them for profit.<h2>Closing thoughts</h2>Replay attacks are less likely to happen again <a href="https://www.builder.news/crypto-insights/ethereum-landscape-post-the-merge-hLhTq" alt="Ethereum Landscape Post The Merge: A Deep Analysis" title="Ethereum Landscape Post The Merge: A Deep Analysis" target="_blank" rel="" class="">post Merge</a> unless there is a fierce civil war inside a Web3 community. When dealing with hacks and exploits like in the case of replay attacks, users should stay informed and equip themselves with up-to-date knowledge of the blockchain they are interacting with.<div class="pr-block-special">Disclaimer This article is intended for reference purposes only. The information provided does not constitute advice or recommendations that any investment or trading strategy is suitable for any specific name.</div>

Ethereum Proof of Work suffered from a replay attack recently. In this article, builder.news discusses what a replay attack is, its degree of risks and how to prevent it.

Replay Attack and its relevance after the Merge