Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal

Welcome to your community. We would like you to take a minute and read our newcomers guide.

Sign in to follow this  
blakicious

Ethereum postponed its hard fork, but miners didn't listen

Recommended Posts

On 15th January, Ethereum developers gave a security alert that they were shifting the Constantinople upgrade to a later date. However, not everyone made the right changes and now we have a parallel universe of Ethereum mining. Without consensus from majority of the network, some miners are mining the unofficial Constantinople chain.

This delay came as a result of one of the new upgrades showing potential vulnerabilities. The statement made as regards the delay of the fork says: 

Quote

We are investigating any potential vulnerabilities and will follow with updates in this blog post and across social media channels. Out of an abundance of caution, key stakeholders around the Ethereum community have determined that the best course of action will be to delay the planned Constantinople fork that would have occurred at block 7,080,000 on January 16, 2019.

 

To avoid a violation of the consensus, a new version will have to be installed by everyone. It seems the information didn’t get to everyone. As at the time of writing, at least 10TH/s worth of mining power was still mining the unofficial chain. Also, compared to Ethereum Classic, more hashrate was found on Ethereum’s forked version. 

The vulnerability we talking about here, permit some type of spamming which takes some level of sophistication to comprehend. The fact here is that, if there’s a change in the way Ethereum charges for storage, an attack could be enabled which could cost a lot of cash to several dApps. A reentrancy attack is a unique problem which is quite different from a replay or a double-spend attack, because it is specific to just smart contracts. ChainSecurity revealed the flawed code, and explains it this way: 

To make a contract vulnerable, some preconditions have to be met:

  1. The presence of a function A, in which a transfer/send is followed by a state-changing operation. Sometimes, this might be non-obvious.
  2. The presence of a function B, accessible from the attacker which (a) changes state and (b) whose state changes conflict with those of function A.
  3. Function B needs to be executable with less than 1600 gas (2300 gas stipend – 700 gas for the CALL).

 

Although this vulnerability is nowhere close to the actual blockchain, Ethereum’s official blog has revealed that it’s better precautions are taken now in order to avoid regrets in the future: "Security researchers like ChainSecurity and TrailOfBits ran (and are still running) analysis across the entire blockchain. They did not find any cases of this vulnerability in the wild. However, there is still a non-zero risk that some contracts could be affected."

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×