The Ethereum Constantinople hard fork that activated last week may have introduced four innovative improvements to the Ethereum blockchain but the one feature that has the chaps at Parity excited is the Create2 code implementation originally proposed by Ethereum creator Vitalik Buterin.
Back in November 2017, an Ethereum user inadvertently exploited a software vulnerability within the Ethereum code that effectively froze 513,774.16 Ethereum coins held at the time by Parity Technologies using the multisig library. At the time of the freezing, these funds were worth $152 million but have since depreciated in value to $65 million.
Parity CEO Jutta Steiner said that with the activation of the Create2 functionality within the Ethereum code, Parity’s funds have a prospect of being recovered.
“If that functionality CREATE2 had existed at the time, there wouldn’t have been a vulnerability, basically,” she said, and added that “So if you think now, okay, we introduced and sort of fixed the tooling, then wouldn’t it be the right thing to do to also fix the issues that arose when we didn’t have the tooling?”
For more than a year now, the developers at Parity have been trying to remedy the situation by getting the rest of the Ethereum developers to allow for a functionality that will enable the frozen funds to be recovered without success. However, now with the introduction of the CREATE2 functionality, they have a stronger case. Steiner explains further that
“It doesn’t automatically mean that we, or all the teams that have stuck funds, get the funds back, it still requires another hard fork where that particular state change is made, but it gives a much more solid argument to why it’s the right thing to do and recover the funds.”
The CREATE2 functionality has been criticized by some claiming that it introduces an attack vector which Vitalik has vehemently denied. The code allows for smart contracts to be created with associations to wallet addresses that are yet to be created on the blockchain. This introduces a whole spectrum of incidences in which a smart contract hacker could design a smart contract with the intention to exploit the vulnerability once the contract passes initial security tests.
