The Ethereum network is set to experience a hard fork at block number 2,675,000, anticipated to take place between 15:00 and 16:00 UTC on Tuesday, November 22, 2016. A countdown timer is available at https://fork.codetract.io/. The Morden test network will also undergo a hard fork at block number 1,885,000.
As a user, what actions should I take?
Ensure you have downloaded the latest version of your Ethereum client:
What are the consequences if I do not update my client?
Using an outdated Ethereum client during the upcoming hard fork means your client will synchronize with the pre-fork blockchain after the fork takes place. You will remain stuck on an incompatible chain following previous settings and will be unable to send ether or function on the updated Ethereum network.
Crucially, if your client isn’t updated, any transactions you initiate may still be vulnerable to replay attacks.
What if I use a web or mobile Ethereum wallet such as MyEtherWallet or Jaxx?
Websites and mobile applications that facilitate the storage of ether and/or transactions operate their own Ethereum client infrastructure. Typically, you need not take any action if you utilize a third-party web-based or mobile Ethereum wallet. Nevertheless, it is wise to verify with your wallet provider regarding the measures they are taking for the hard fork and if they require additional steps from their users.
Specifically, you should verify that transactions are produced using the new replay protection EIP 155 framework.
What should I do if my Ethereum client struggles with syncing to the blockchain?
Confirm that you have acquired the latest version of your Ethereum client.
Why is there a proposal for a hard fork of the network?
“Spurious Dragon” represents the second hard fork in a two-stage response to the DoS assaults on the Ethereum network during September and October. The preceding hard fork (also known as “Tangerine Whistle”) addressed critical network stability issues caused by those attacks. The forthcoming hard fork will tackle important, albeit less urgent issues, like refining opcode pricing to avert future assaults on the network, enabling the “debloat” of the blockchain state, and adding replay attack safeguards.
What modifications will be included in this hard fork?
The subsequent Ethereum Improvement Proposals (EIPs) delineate the protocol adjustments enacted in this hard fork.
- EIP 155: Replay attack protection – prevents transactions from one Ethereum chain from being rebroadcasted on an alternative chain. For instance: If you dispatch 150 test ether to someone from the Morden testnet, that same transaction will not be replayable on the main Ethereum chain. Important note: EIP 155 is backwards compatible, thus transactions generated with the “pre-Spurious-Dragon” format will still be acknowledged. However, to guarantee protection against replay attacks, you need to utilize a wallet solution employing EIP 155.
Note that this backward compatibility means that transactions originating from alternative Ethereum-based blockchains that do not implement EIP 155 (like Ethereum Classic) could still be replayed on the main Ethereum chain. - EIP 160: EXP cost increase – modifies the cost of the `EXP` opcode to align it with the operational complexity of the action, effectively making it harder to disrupt the network through computationally intensive contract operations.
- EIP 161: State trie clearing – enables the removal of a significant number of vacant accounts that were introduced at a drastically reduced cost due to earlier DoS assaults. This EIP ensures that ‘empty’ accounts are eliminated from the state whenever ‘touched’ by another transaction. The elimination of empty accounts considerably shrinks blockchain state size, allowing for client optimizations, like quicker sync times. The actual process of removal will commence post-fork by systematically performing `CALL` to the vacant accounts created by the assaults.
- EIP 170: Contract code size limit – alters the maximum allowable code size for a contract on the blockchain. This update averts a potential attack scenario involving repeated access to vast segments of account code at a consistent gas cost. The maximum size is established at 24576 bytes, which surpasses the size of any currently deployed contract.
DISCLAIMER
This is a rapidly developing and intricate technical domain.Should you decide to apply the suggestions in this post and persist in participation, it is imperative that you comprehend how it may affect you. Recognize that there are associated risks, including but not restricted to unforeseen bugs. By choosing to apply these recommendations, you alone accept the risks of the outcomes.