If the Merge occurs successfully, there will be a fork between the Proof-of-Stake chain and the Proof-of-Work chain. See my previous post to learn why.
The PoW chain will probably not be long for this world, as the current efforts to organize are achieving little more than the ETHPoW account getting mercilessly ratioed on Twitter. The effort is doing some rather suspicious things, and rapidly burning through goodwill. They may not even manage enough coordination to hard fork out the difficulty bomb, and get summarily rekt by the ice age.
Nevertheless, even if it’s solely composed of miners who haven’t updated, there will be a PoS/PoW fork. And some smart people are probably going to make a disgusting amount of money pillaging the forked chain.
However - participating across both chains is going to be very dangerous if you don’t know what you’re doing.
The reason why is replay attacks.
In a replay attack, an attacker uses a valid message in a different context than it was originally intended. Example: I spy on you logging into your bank account, and write down your password. Later, I go to your bank and log in using that password.
In the blockchain context, you can imagine how much chaos it would cause if someone could replay your transactions. Deposit 100 DAI to a vault, and someone could replay that transaction, sending all your DAI to the vault until you had nothing left! Send me 0.05 ETH for an NFT, and I can replay it to drain your wallet! Not good.
To avoid this, Ethereum uses a few pieces of tech. First is the account nonce (number only used once). You assign a nonce to each transaction, and only one transaction with that nonce can ever be made. If someone tries to replay it, it will no longer be valid since that nonce has already been consumed.
However, that is not a sufficient protection in the multi-chain ecosystem. There are multiple EVM chains. You make a transaction, consuming nonce 10 on Chain A. However, on chain B, or chain C, your account has not consumed nonce 10. Uh-oh.
To counter that issue, we have the chain ID. Each EVM chain, whether Mainnet, Goerli testnet, Avalanche, Polygon, Fantom, etc, has a unique number identifying it. The chain ID is part of the transaction information whenever you sign a transaction, so your transactions can’t be replayed on a different chain.
But, what happens when you’re forking an existing blockchain?
If the forkers are competent, they’ll switch to a different chain ID. If they’re not, and retain the same chain ID, anarchy will ensue. Try to sell your PoW ETH off - OOPS, just sold it on mainnet. Any transaction on PoS mainnet could be replayed on the PoW chain, for whatever that ends up being worth. That’s the worst case, most chaotic outcome.
Assuming the forkers do change the chain ID, we’re not out of the replay attack woods yet. The reason for that is permit patterns.
Some smart contracts or tokens allow signing offchain messages which can be used as approval for onchain actions. Example: Permit transfer of an ERC-20 allows me to give you a signed message saying “User X is allowed to transfer 1000 of my DAI - Signed, Pickle”. You can then present that message to the token smart contract and take those funds, without me having to send them directly OR sign an approval transaction.
There’s one teeny problem though. Permit pattern contracts use something called a domain separator to distinguish them from other contracts. The domain separator includes information about the contract itself, as well as the chain ID. The problem - the design convention when many of these contracts were built was to hardcode the chain ID into the domain separator.
Some of you may grasp the implication of that immediately. For those that don’t, I’ll spell it out.
Any permit pattern contract which hardcodes the mainnet ETH chain ID into their domain separator will be vulnerable to replay attack - and there’s nothing the forking miners can do about it. Changing the chain ID on the forked chain won’t help.
If you sign a permit on the mainnet, it can be replayed on the fork. If you sign one on the fork, it can be replayed on mainnet.
Now, how do you deal with this? If you’re like me and plan on simply riding out the merge without engaging in fork war interdimensional degeneracy, you simply write off the PoW fork as valueless and go about your business on mainnet without caring whether someone is replaying your transaction on the PoW chain.
But Pickle, what if I’m a degenerate?
Very well. If you want to raid the PoW chain safely, do the following (IF AND ONLY IF they change the chain ID, otherwise you will get rekt).
Make a PoW chain transaction transferring your assets to a burner account
Do your degenerate business on the PoW chain using the burner
NEVER make any interaction with the burner address on mainnet, for the rest of time
The transaction to send your funds to the burner is protected against replay by the chain ID change. The transactions of your burner can’t be replayed on mainnet - because it has no balance or assets on mainnet. If you do put any assets into it, they could be at risk.
Make sure you fully understand what you’re doing before engaging in anything like that, however. If this is your first time hearing about replay attacks, you probably don’t have any business doing anything besides sitting comfy on PoS ETH with your bags. Just my two cents.
Thanks for this! Never knew about it.
Great write-up!