The "world computer" is ensnared again in a heated debate.
Sparked by a controversial code proposal called EIP 867, ethereum's development forums have become something of a battleground, crowded with bitter commentary, snide pull-requests and coordinated attempts to erase the idea from the platform's repository.
For those unfamiliar, the conflict surrounds an effort to make it easier for ethereum users to reclaim lost ether (ETH), the network's cryptocurrency (now valued at $870), outlining a process by which such requests could be submitted in a clear and executable format to those who maintain the technology.
No small problem, fund losses on ethereum have become frequent.
High-profile cases, such as the deletion of a code library from leading software company Parity Technologies saw 513,774.16 ETH or $421 million rendered inaccessible last year. And just months before, the same company lost 150,000 ether, or $123 million, due to a code error.
But it's not just Parity. Last year, a faulty ethereum address generator saw Kraken exchange and wallet provider MyEtherWallet lose hundreds of thousands of customer funds. And many more, whether due to glitchy software or simple typos, have lost money on platform -- one address even holds a total of $6.3 million in ether because it too closely mirrors a call code that automatically locks up funds.
But while some users think refunding the lost ether is acceptable, a side effect of enabling digital fund ownership and the accountability that entails, others are vehemently opposed, believing that such efforts threaten the integrity of the ethereum platform, while raising potential legal liabilities.
Indeed, one core developer even stepped down from his role as code editor citing legal consequences that might ensue down the line.
Still, the conflict is nothing new, harkening back to a controversial decision enacted on the platform in 2016 -- in which ethereum refunded 3.6 million in hacked ether in a system-wide upgrade, or hard fork.
Founder of ethereum, Vitalik Buterin, wrote on Twitter:
"To those who thought that the DAO fork set an unbounded slippery slope and lasting precedent, I encourage you to see the reactions on this thread."
In this way, the conflict emerging from EIP 867 shows the two sides of this debate have yet to reconcile, and that there's subtleties at work within each subset. Broadly, each side can be understood as having a differing interpretation of ethereum.
What is EIP 867 anyway?
In ethereum software development, an EIP, or ethereum improvement protocol, is the process by which code changes get accepted onto the platform.
To add new features to ethereum, software changes are executed in the form of platform-wide upgrades (sometimes called hard forks), but to get to this stage, proposals are subject to a rigorous acceptance process, consisting of roughly four steps:
First, if a developer has an idea for a software change, it should be presented as a pull request. As a pull request, changes can be easily made onto the proposal, and community feedback is welcomed. Here, it also falls under the scrutiny of the EIP editors.
If the EIP editors find the request to be technically correct and in tune with the "ethereum philosophy," they can "merge" it as the draft into the next stage.
Once merged, software implementations, in the form of various ethereum clients such as Geth and Parity, can occur, and if they work, the proposal can be finally "accepted."
Once accepted, the platform can be updated with the EIP-- providing the various nodes running ethereum software decide to upgrade.
However, in this process, EIP 867 is a little different. For one, it doesn't propose any software changes in itself, but simply documents a framework for proposals to follow.
In this, it falls into another category, called a "meta EIP," which is a way to collect and formalize EIPs that fall within a certain category -- in this case, recovery proposals. Because of this, the developers of EIP 867 have given the meta EIP a unique name: Standardizing Ethereum Recovery Proposals, or ERPs.
There have been a few proposals of this type.
Following the $421 million fund freeze last year, Parity Technologies drafted up several options to recover the funds - all of which were harshly rejected at the time. There is also an EIP named EIP 156, which, written by Buterin, details a method to return funds lost by Kraken and MyEtherWallet, as well as some other popular cases of lost funds.
According to EIP 867, the failure of such proposals is due in part to "the relatively ad-hoc nature of such requests and the subjectivity that is often required to evaluate the merits." As such, the EIP provides "a standardized format for fund recovery EIPs and an objective standard by which to measure future proposals."
Finally, if accepted, the class of EIP named ethereum recovery proposals (ERPs), would be subject to the same evaluation process of any code proposal on the platform.
Currently, EIP 867 is stuck in phase two of the EIP acceptance process -- it is an unmerged draft. Former EIP editor Yoichi Hirai initially rejected the proposal on account of its failure to align with the "ethereum philosophy"-- one of the categories of judgement in the formal EIP process.
Hirai later stepped down from his position as EIP editor, citing legal concerns that may result from permitting the draft to continue.
And due to its divisive nature, ethereum developers have said that prior to any further action, the EIP process itself needs to be further reevaluated, to clarify whether things like subjective judgement can come in to play.
View 1: "Code Is Law"
When ethereum upgraded to restore funds lost in The DAO hack of 3.6 million ether -- now valued at over $3 billion -- a portion of the community abandoned the platform to create a new cryptocurrency named ethereum classic.
On ethereum classic, which is now valued at just under $1 billion, the ethereum platform exists as if The DAO fund recovery of the 3.6 million ether never occurred, but instead, remain permanently lost on the platform.
Influencing this decision was the belief that "code is law," which means that on a blockchain, all executions and transactions are final and immutable and cannot be overwritten or corrected, especially when regarding real money. In this perspective, code errors, like software faults that can be hacked or broken, are painful but necessary lessons for development.
Because EIP 867 could make such corrections more frequent, hundreds have stepped up to voice their opinions on Github -- with some threatening to migrate to ethereum classic.
"If you don't like the possibility of recovering funds use [ethereum classic]. This debate was settled two years ago," blockchain architect Cody Burns tweeted.
Because The DAO was largely led by ethereum developers with ties to the Ethereum Foundation, many saw the 3.6 million refund as a "bailout," an allegation of developer corruption that persists in the EIP 867 debate.
"If you want bailouts you should stick to fiat," leading voice on the opposition, Marius Kjærstad, wrote on the thread.
Arguing that such changes damage the incentive to maintain decentralized ledgers, software developer Charles Cooper wrote:
"If this process exists then ethereum can no longer be called a blockchain, it is just a central bank which happens to use miners to validate the majority of transactions."
Shadowing this, is the concern that EIP 867 would give developers too much power over the ethereum platform. Citing a Japanese law, Hirai argued that the movement of funds, especially in the case of unclear ownership, was beyond the capacity of developers and could make them liable to corruption, coercion and bribery.
"I want to be a software developer, not a lawyer," Alexey Akhunov posted on the thread.
On the more moderate side, other voices on this side of the debate argue that The DAO was a one-off, and software-wide upgrades for fund recovery should be "rare and increasingly exceptional" as the platform matures -- a position which Buterin himself has supported.
Toward this, developer of ethereum's Mist browser Alex Van de Sande has proposed a system whereby fund recovery could be possible without software upgrades, but instead by setting up an insurance pool for ether refunds.
View 2: "Code is a process"
On the other side of the debate are some of ethereum's top developers, who argue that, in cases which fund ownership is clear and indisputable, recovery should occur.
"It really seems to me that the case for recovering lost ether where it's easy to identify the true owner, and recovering it imposes a low burden on everyone else, ought to be fairly clear and uncontroversial," ethereum core developer, Nick Johnson, wrote on Twitter.
And such cases are relatively common.
In the examples cited in Buterin's EIP 156, funds lost in certain cases could be redeemed, and according to some, rightfully so.
Jesse Powell, the CEO of the cryptocurrency exchange Kraken, wrote in response to EIP 156 two years ago:
"Speaking on behalf of Kraken, I would characterize this more as recompense than rescue. We did take on some not insignificant losses as a result of the mentioned bug in the old ethereum javascript library. At the time, losses were covered out of Kraken's pocket to protect our clients."
And Kraken isn't alone. Indeed, EIP 156 is littered with commentary from others who have been impacted in various ways, each appealing to the community for justice regarding funds lost at no fault of their own.
"MyEtherWallet just burned me for 121 ETH," an infuriated user wrote on Reddit.
According to some, ethereum has a responsibility toward its users in these cases. Plus, by providing protection for lost funds, the risk of using the platform would minimize, leading to increased adoption.
And while community consensus is essential for changes to occur on the platform, concern has been expressed that the strong opposition to EIP 827 isn't representative of the wider set of ethereum stakeholders.
Speaking to CoinDesk, James Tevy from Taptrust, one of the developers leading the proposal, said, "One of the tricky things now there's a vocal minority, I don't take it for granted that the public response was totally representative."
Tevy added:
"The large silent minority want the network to function, and the value of ether to grow. They don't have a dog in this race."
Finally, because EIP 867 isn't a lost fund proposal in itself, but rather, a standard with which to formalize lost fund proposals, there's the argument that the current EIP in itself won't necessitate any controversial changes at all.
Instead, if accepted, ethereum recovery proposals (ERPs) would go through the same rigorous vetting process as standard EIPs. In the end, if a controversial proposal is implemented, users could choose not to update their software - thus falling out of sync with the dominant chain.
