The Go Ethereum software client has published a code upgrade that includes a list of new features, including an activation time for the Constantinople hard fork.
The Ethereum (ETH) Constantinople upgrade appears to be proceeding as planned, as a widely used Ethereum software client has published new code that includes a Constantinople activation time on GitHub Dec. 11.
The post reads that Geth, which stands for Go Ethereum, v1.8.20 is a special release that will “finally” enable the Constantinople hard fork on the Ethereum mainnet at block 7,080,000. Geth is one of the three original implementations of the Ethereum protocol. The description further states:
“It's also our last planned release of the 1.8 family, meaning that we'll start merging backwards incompatible changes onto master in preparation of Geth 1.9.0.”
Ethereum core developers agreed to launch the long-awaited Constantinople hard fork at block 7,080,000 on Friday, Dec. 7. The upcoming Constantinople hard fork comprises five separate Ethereum Improvement Proposals (EIPs) in order to soften the transition from proof-of-work (PoW) to the more energy efficient proof-of-stake (PoS) consensus algorithm.
PoS would fundamentally change the Ethereum blockchain by means of a host of new upgrades, which prevent any backwards compatibility. This means that nodes must either update synchronically with the entire system or carry on running as a separate blockchain entity.
The Friday agreement follows a decision to delay the Constantinople hard fork for late January 2019 due to a “consensus” issue that appeared during an upgrade trial on the Ropsten testnet in October.
Yesterday, Ethereum co-founder Vitalik Buterin declared that future blockchains with sharding based on PoS will be “thousands of times more efficient.” Buterin stated that, as scalability advances (driving fees down) and user experience gets better, non-financial applications will become “a bigger part of the story.” He also noted that blockchains are not about “cutting computational costs,” but are instead about increasing computational costs while decreasing “social costs.”