Ethereum

Hard Fork No. 4: Spurious Dragon

The Ethereum network is scheduled to undergo a hard fork at block number 2,675,000 on Tuesday, November 22, 2016 between 15:00 and 16:00 UTC. The countdown timer can be found here: https://fork.codetract.io/. The Morden test network will undergo a hard fork at block number 1,885,000.

What should I do as a user?

Download the latest version of the Ethereum client.


What happens if I don’t update my clients?

If you are using an Ethereum client that has not been updated for the upcoming hard fork, your client will be synchronized with the pre-fork blockchain when the fork occurs. Depending on the existing rules, you will be stuck on an incompatible chain, unable to send Ether or operate on the post-fork Ethereum network.

Importantly, if the client is not updated, it also means that any transactions you make are still vulnerable to replay attacks.

What if I’m using a web or mobile Ethereum wallet like MyEtherWallet or Jaxx?

Ethereum websites and mobile applications that allow you to store and trade ether run their own Ethereum client infrastructure to facilitate their services. Typically, if you use a third-party web-based or mobile Ethereum wallet, you don’t need to do anything. However, you should check with your web or mobile Ethereum wallet provider to see what steps they are taking to update hard forks and whether they are asking users to take other actions.

In particular, we must ensure that transactions are created using the new replay protection EIP 155 scheme.

What should I do if my Ethereum client is having trouble syncing with the blockchain?

Make sure you have downloaded the latest version of the Ethereum client.


Why do you propose a network hard fork?

‘Spurious Dragon’ is the second hard fork in response to DoS attacks on the Ethereum network in September and October. Previous hard fork (aka “Tangerine Whistle”) Addressed immediate network health issues resulting from the attack.. The upcoming hard fork addresses important but less pressing issues, including further adjusting opcode prices, enabling “debloat” of blockchain state, and adding replay attack protection to prevent future attacks on the network.

What changes are coming in this hard fork?

as follows Ethereum Improvement Proposal (EIP) Describes the protocol changes implemented in this hard fork.

  • EIP 155: Replay Attack Protection – Prevents transactions occurring on one Ethereum chain from being retransmitted to another chain. For example, if you send 150 test ethers to someone on the Morden testnet, the same transaction cannot be played on the main Ethereum chain. Important note: EIP 155 is Backwards compatible, so transactions created in the “pre-Spurious-Dragon” format will continue to be accepted. However, to be protected against replay attacks, you must still use a wallet solution that implements EIP 155. This backwards compatibility allows alternative Ethereum-based blockchains that do not implement EIP 155 (e.g. Ethereum Classic) to still play on the main Ethereum chain.
  • EIP 160: Increased experience cost – Adjusted the price of the ‘EXP’ opcode to strike a balance between the ‘EXP’ price and the computational complexity of the operation, making it more difficult to slow down the network through inherently computationally expensive contract operations.
  • EIP 161: State Try Clearing – Large numbers of empty accounts left in a state as a result of an initial DoS attack can be removed at a very low cost. With this EIP, ’empty’ accounts are removed from the state whenever they are ‘touched’ by another transaction. Removing empty accounts significantly reduces the blockchain state size, providing client optimizations such as faster sync times. The actual removal process begins after the fork by systematically ‘CALLing’ empty accounts created by the attack.
  • EIP 170: Contract Code Size Limits – Change the maximum code size that a blockchain contract can have. This update prevents an attack scenario where large amounts of account codes can be accessed repeatedly with a fixed gas cost. The maximum size was set to 24576 bytes, which is larger than any currently deployed contract.


disclaimer

This is an emerging, evolving, highly technological space. If you decide to implement the recommendations in this post and remain engaged, you need to understand how this affects you. You should understand that this involves risks, including but not limited to risks such as unexpected bugs. If you choose to implement these recommendations, you solely assume the risk of the results.


Related Articles

Back to top button