You are currently viewing One of the main reasons for the ETHW nosedive is its chain ID |  by Harbor |  Coinmonks |  Sep 2022

One of the main reasons for the ETHW nosedive is its chain ID | by Harbor | Coinmonks | Sep 2022

Replay assaults are a realistic possibility in the Merge’s context and the ensuing fork.

Utilizing the ChainID will be one of the simplest ways to distinguish between Ethereum Mainnet and ETHPoW. A ChainID is a number that lets decentralized applications (dApps) and smart contracts know which chain they are communicating with.

With the help of the chain ID, network users can determine whether a broadcasted message — like a signed transaction — should be processed by them or dropped and ignored.

On an Ethereum network, we generate transactions, sign them with our private keys to ensure their authenticity, then broadcast them to the network so they can be included in a block.

What is a replay attack?

In more traditional markets, a replay attack may provide a hacker access to specific data on a network for the purpose of replicating transactions or transmitting verified information. Replay attacks pose an additional risk because a hacker can easily decrypt a communication after grabbing it from the network without the need for special knowledge. By simply transmitting the entire thing again, the attack could be successful.

Blockchains are susceptible to replay attacks, albeit historically, credit cards have been the more common target. Replay attacks are more likely to succeed right after a hard fork, when blockchains are most vulnerable. The technology of the second-largest cryptocurrency in the world has undergone a substantial revolution that will reduce carbon emissions by more than 99.9%.

The transition known as “Ethereum Merge” has been finalised. This implies that there will be two identical copies of the complete Ethereum blockchain, with proof-of-work and proof-of-stake versions for all DeFi positions, ERC20 tokens, and transactions. With ETHW serving as its native cryptocurrency, this new branch of the Ethereum network was given the name ETHPOW. Due to substantial technical issues, the network hasn’t exactly launched off to a great start. Since then, the value of ETHW has also plummeted.

It was soon noticeable that ETHPoW’s selection of an already-used chain ID was a contributing factor in the problem. Chain IDs don’t belong to any central registry or authority and are chosen at random. The Bitcoin Cash testnet is already using the chain ID 10001 that the developers of ETHPOW selected. As a result, after the network was live, some users started to report access issues.

BlockSec reported on September 16th, 2022, that certain attackers had harvested large amounts of ETHW by replaying the message (ie, calldata) of the PoS chain on EthereumPoW. (aka the PoW chain). The PoW chain’s Omni bridge’s use of the outdated chainId and improper verification of the cross-chain message’s true chainId is the primary contributor to the exploitation.

Unfortunately, the verified chainId used in this contract is derived from the value kept in the unitStorage storage and it is NOT the chainId that was really obtained by the EIP-1344-recommended CHAINID opcode.

The hacker first sent 200 WETH across the Omni Bridge. They obtained an additional 200 ETHW by repeating the identical calldata on the PoW chain.

The developers of ETHPoW have responded on the matter, claiming that the assault leveraged a weakness in the contracts employed by the bridge rather than a vulnerability in their own blockchain.

How can we prevent unauthorized replays?

We must make sure that any transactions (PoW or PoS) signed on one chain will inadvertently fail if they are replayed on the other chain.

The best strategy is to transfer all assets on both chains to brand-new accounts just for those chains. Because those assets are not available in Account B on the PoS chain, a replay of a transaction signed by B on the PoS account will fail, for instance, if Account A transfers money to Accounts B and C on the PoW and PoS chains, respectively .

According to the Ethereum protocol, each transaction that an account sends to the network must have a unique number. The nonce, which is the first integer in the sequence, is also an element of the transaction payload that needs to be signed. There cannot be any gaps since the protocol mandates that every transaction an account sends has a nonce of 0, which is increased by 1 with each subsequent transaction.

The case for nonce divergence is predicated on the idea that if one chain advances the nonce for an account, the other chain will lag behind in the transactional sequence, making it impossible to replay transactions due to the nonce gap. This is true, but only for as long as there is a divergence in the nonces. Replays would be conceivable once more, namely if the attacker was successful in carrying out transactions on the opposing chain and matching the account’s nonces. Replays might once again be possible if the account owner forgets that the divergence of nonces is required and unintentionally transacts on the other chain.

Closing words

As part of the transition from the Ethereum network’s existing Proof-of-Work (PoW) mining paradigm to a Proof-of-Stake (PoS) consensus process, the Merge will progressively phase out miners and replace them with validators.

New to trading? Try crypto trading bots or copy trading

Leave a Reply