What the heck is Replay Protection?
The MERGE! It has finally happened.
15537394 was the first block on Ethereum that was validated using the Proof of Stake consensus mechanism.
The migration to PoS was extremely successful, however, it’s not one without contention, as some of the miners who preferred PoW, decided to fork the chain and continue with the PoW consensus mechanism.
This means that we have a hard fork and a chain split at the point of the merge.
Whenever such chain splits happen, other examples are ETH & ETC split, BTC & BCH we start hearing the words “Replay Protection”.
In this article we dive deep into Replay attacks and why it’s important to protect against such attacks.
What is a replay attack?
A replay attack in a single chain is simply an attack where the attacker can copy your valid transaction and send it to the network again. Causing your funds to be debited twice.
Imagine this scenario.
0xBob wants to send 10 tokens to 0xEvil. At the time of the transaction, 0xBob has 20 tokens under his account.
0xBob creates a transaction for 10 tokens towards 0xEvil, signs the transaction, and sends it to the network.
0xEvil receives the 10 tokens, but him being evil, he takes the same transaction and sends it to the network again, now if the chain does not have replay protection handled, since 0xBob still has 10 tokens left in his account, the replayed transaction will go through and 0xBob will lose another 10 tokens.
Generally, all chains handle these types of situations by adding a nonce which is a sequence number, and also by handling duplicate transaction hashes (No two transactions can have the same hash). With these two things added 0xEvil’s replayed transaction will fail because…
- Invalid/ Duplicate nonce.
- Duplicate Transaction hash.
Cross Chain Replay attacks
This is where things start to get a bit more interesting. When a hard fork happens the chain splits into two.
Here the entire state is copied as-is from the original chain to the forked chain. They have a common history up until the point of the fork.
This means that if 0xBob has 20 tokens on the original chain, he will have 20 tokens on the forked chain as well. Nice isn’t it?
Now if the forked chain hasn’t added the necessary solution (and we will discuss what that solution can be a little later), both chains will be exposed to replay attacks.
This is how replay attacks in forked chain work, ready?
Continuing from our previous example. Now, 0xBob has 20 Tokens on C1 (Original Chain) and 20 Tokens on C2 (Forked Chain).
0xBob decides to send 20 tokens on C2 to 0xEvil. 0xBob signs the transaction and sends it to the C2 network.
Now, 0xEvil being evil will copy the contents of this signed transaction and submit it to the original chain which is C1. This copied transaction from C2 to C1 will be perfectly valid and it will transfer the 20 tokens that 0xBob had on C1 network to 0xEvil.
Here is why the transaction was valid.
Let’s assume that at the time of the chain split, the nonce for 0xBob was at 0. When 0xBob did the original transaction on C2, the nonce incremented to 1. However, the nonce for 0xBob on C1 (original chain) is still at 0. So a transaction with nonce 0 will be accepted over there.
Along with this, the hash of the copied transaction will also be unique on C1, as the original transaction was submitted on the C2 chain.
How to protect against cross-chain replay attacks?
Now that we understand how replay attacks work, let’s see how can we add replay protection to defend against cross-chain replay attacks after a hard fork.
These types of attacks can be prevented by modifying the transaction data in a way that is unique to each forked chain. This can be just a random bit (a random piece of information) that is added to transaction construction before signing and submitting the transaction.
Usually, this is done in two ways, the first one is strong replay protection where one of the forked chains will make it mandatory to change some information in the transaction for it to be valid over its network.
The second way is the opt-in reply protection, where the users must make manual changes to the transaction to ensure that they won’t be replayed.
Adding this additional piece of information makes the transaction data, signature, and hash invalid on the other chain.
Conclusion
Replay attacks usually come into play when a chain undergoes a hard fork and hence we start hearing a bit more about them when such an event is on the horizon.
During the first Ethereum split, between ETH and ETH Classic, this became an issue as ETH classic did not have replay protection built in. However, the ETH community resolved this by introducing a field called ChainID which is unique to each EVM-based chain.
The ETHW community has decided to use the ChainID 10001. Thereby automatically protecting the chains against replay attacks.
Hi, I’m Rahil Shaikh, a computer engineer and a student of Bitcoin. If you liked the article do give me a follow at rahil471.
New to trading? Try crypto trading bots or copy trading
