With the much anticipated Constantinople and St. Petersburg forks right around the corner, you might be wondering ... why is Ethereum forking twice?

The decision to implement two hard forks comes after a bug was found in one of the Ethereum Improvement Proposals (EIP's) apart of the Constantinople upgrade. This discovery caused a delay in the initial release of the full implementation of the hard fork on Ethereum's main net.

The bug was discovered within EIP 1283 by blockchain security firm, Chain Security, just 48 hours before the hard fork was set to occur in January.

The security firm discovered that a code change caused by EIP 1283 - which aimed to lower the cost of gas while transacting on the network - created an "unwanted side effect" that would allow a hacker to conduct a "reentrancy" attack.

A reentrancy attack allows an attacker to “reenter” the same function multiple times without updating the user about the state of affairs. According to Joanes Espanol, CTO of blockchain analytics firm Amberdata, under this scenario, an attacker could essentially be “withdrawing funds forever.”

“Imagine that my contract has a function which makes a call to another contract… If I’m a hacker and I’m able to trigger the function while the previous function was still executing, I might be able to withdraw funds,” Espanol explained to CoinDesk.

Chain Security would write in January:

The upcoming Constantinople Upgrade for the ethereum network introduces cheaper gas cost for certain SSTORE operations. As an unwanted side effect, this enables reentrancy attacks when using address.transfer(...) or address.send(...) in Solidity smart contracts. Previously these functions were considered reentrancy-safe, which they aren’t any longer.

This discovery prompted the Ethereum core developers to decide on sidelining EIP 1283 while moving ahead with the rest of the proposals.

The only catch was that the full Constantinople fork was already running on some of the Ethereum test nets, prompting the need to implement a rollback of the buggy EIP.

This is where the St. Petersburg fork comes into play

The goal of St. Petersburg is to roll back EIP 1283 once the Constantinople fork hits the main net. It will be implemented on the same block as Constantinople, creating a seamless transition from fork to fork.

“For all practical means for any developer out there on the mainnet, there will not have been Constantinople really, just Petersburg … Technically in the code, you have two conditions,” ChainSecurity COO Matthias Egli explained. “One says Constantinople gets active at block number [7,280,000] and at the same block number Petersburg gets activated, which takes precedence over Constantinople and immediate supersedes it.”

These upgrades are all a step towards Ethereum 2.0 that will feature the Proof of Stake (PoS) consensus algorithm and increase the network’s transaction capacity, among other essential features.

When all is said and done, Ethereum will have these EIP's implemented post-St. Petersburg:

EIP 145
This focuses on adding shifting bitwise operators to the Ethereum Virtual Machine (EVM) for the efficient processing of information.
EIP 1014
Improves scaling solutions of the accommodating network like the off-chain transactions.
EIP 1052
An upgrade of smart contracts processing system.
EIP 1234
Focuses on reducing rewards issued to miners from 3 ETH to 2 ETH per block.

According to Cracking Cryptocurrencies' fork countdown, both Constantinople and St. Petersburg are set to come into play mid-day Thursday, February 28th.

by:

Leave a Reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

The reCAPTCHA verification period has expired. Please reload the page.