Over the past few days, the Ethereum developers have been marred in a quagmire over the security implications of a proposed Ethereum EIP by Ethereum creator Vitalik Buterin.
The EIP (Ethereum Improvement Proposal – EIP 1014) is a feature dubbed “Create 2” which allows for a smart contract to interact with an address that is yet to exist on-chain but “can be relied on to only possibly eventually contain code.”
The EIP 1014 is set to be released in the upcoming Constantinople hard fork slated to activate later this month. Despite the proposal having getting approved to be included in the next code upgrade, several Ethereum devs believe that this feature will have negative security implications against the Ethereum blockchain.
In the latest developers call held on Friday 15th, February, Vitalik and the rest of the core devs took to justify the efficacy of the proposed EIP. Buterin stuck to his guns dispelling myths that the feature would cause any security vulnerabilities.
One major critic of the feature is the chief scientist at blockchain startup Indorse Rajeev Gopalakrishna who quipped in an Ethereum forum discussion earlier this week:
“Doesn’t this change a major invariant assumed by users today and introduce a potentially serious attack vector with CREATE2? Doesn’t this mean that any contract post-Constantinople with a self-destruct [function in its code] is now more suspect than before?”
One developer, Jeff Coleman, a proponent of the proposal gave his comments during the Friday call. He said that:
“one of the things that are counter-intuitive about Create2 is that theoretically, redeployments can change the contract byte code because the address is only a commitment to the init code. People need to be aware that init codes are part of auditing, […] that non-deterministic init codes are a problem.”
Vitalik, however, leaned his argument towards the future of the community and the project roadmap. He argued that,
“The one thing we need to keep in mind is more for the future when thinking about rents and deletion; that’s a way that can lead to contracts being in a state to being not in a state without a self-destruct operation […]. It’s not something we need to figure out in the next few weeks, but it’s still useful to keep in mind when getting the ETH 2.0 sharding to a VM spec very soon.”
Other than the EIP-1014 discussion, in Friday’s call, the developers also noted that they had settled on a prospective independent audit company to audit the ProgPoW code upgrade that seeks to implement anti-ASIC features to the Ethereum blockchain.