It seems like the All Core Devs meetings is where the final decisions on governance are made.
I think EIP-867 is the worst idea, as it makes core devs responsible for evaluating every ERP. How many ERPs do its proponents think will be drafted? I can easily picture a situation where every All Core Devs meeting involves going through 100s-1000s of ERPs, the vast majority without merit. How could the process not be abused? Bitcoin maximalist trolls could fill out tons of ERPs for very little effort.
I’m less hostile to EIP-999, but I do think that the community needs some objective criteria on what sort of smart contract screw-ups should be fixed through ad hoc hard forks. Until we can come up with that criteria and have the majority of the community agree with it, I’m against EIP-999
Unfortunately, even measuring what the majority of the community agrees with is contentious.
Trolls can already spam the EIP GitHub repo, the ERP system won’t change that. The first step is getting to draft which means getting past the editors which make sure that the proposal is at least sound/grammatically correct/technically complete, so the only things that will make it to the core devs meeting are ERPs like similar to EIP-999 where someone has a complete solution drafted up and it is well described and implementable.
This is incorrect. The All Core Devs meeting is where the various client dev teams discuss what each client team is going to implement. Ultimately the individual clients can choose what to implement but they generally prefer to all implement the same things to avoid a fork. Ultimately the final governance decision is what economic participants decide to run. Even if all of the clients implement a thing, if no one upgrades their client to accept the changes then it doesn’t matter.
I think this EIP would set dangerous precedents if accepted. This EIP outlines the recovery of a contract that was used in an unintended way where the contract contained no underlying flaw, rather it was simply misused.
Personally, I have issues with this EIP. It outlines a specific contract recovery rather than generic recovery (EIP-867). This would set precedent to create another EIP when some subjectively non-trival amount of ETH is lost by misuse of a valid contract. If I set the wrong owner on my multisig contract and lost all of my ETH, am I entitled to my funds to be recovered? The amount lost is not significant to the network and poses no risk to others, but it was my entire stash.
The decision to leave the network that is called Ethereum is a very final form of “governance”, but it’s not useful to bring it up in the context of deciding on the future of Ethereum.
The definition of what the network called Ethereum is, is decided by All Core Dev meetings. This is why we don’t call Ethereum Classic the “real” Ethereum.
I’m fine with this centralized governance, but I think the value of Ethereum will be greater if the community can agree ahead of time that certain things about the protocol should not be altered.
I think the process needs to look much closer to something like this, as that is basically a final signal that entire network sees nothing wrong with the proposal. Getting a measurement of support/no-support from the entire community would be required to vote effectively on outcomes like this proposal.
I avoid this debate, because I don’t really have any novel points to make, but I guess it’s at the stage where decisions are made by a vague sense of how loud the shouting is.
So here are my grumbling reasons for opposition:
Moral hazard. We’re not paying attention to the less influential voices who have lost a much less money, so we’re implicitly endorsing a “too big to fail” incentive model.
Future distraction. Ethereum’s competitive advantage is in a large, friendly community of contributors, working hard on scalability and usability improvements.
Making this change will ensure that we continue to revisit requests like this on a regular basis. That will continue to distract us from efforts to improve the technology for everyone. Becoming a project which constantly debates fund restoration EIPs will make Ethereum a “not much fun” open source project to contribute to, thus deterring new contributors.
EIP is an open process, everyone can file a proposal, everyone is entitled. If you are not certain about the feasibility of your request or unsure about technical details, it’s worth to create an issue first to outline the idea before actually submitting a proposal. I am happy to advise other recovery proposals, as I have done before.
These are really solid arguments to make, especially about the community being friendly and doing really awesome work, and how too much noise from recoveries would affect that.
My question is how do you stop requests like this? I think there an equally likely chance these kinds of requests continue to happen because the people who lost access to their funds are pretty well incentivized to continue trying any tactic that gets them what they want to accomplish. So we will keep seeing proposals like this occur from this hack and others like it where large quantities of valuable assets are lost.
What happens the next time an “economic threat to the entire ecosystem” occurs? What if Casper or Sharding contracts have a bug? What is the process for handling that? I think there’s balance to be struck where only the most important bugs and exploits are incentivized to go through a very complex and long-term process to ensure near-universal consensus on how the recovery should be handled.
That only happens if we are willing to discuss this as a community instead of pretending it will go away with time.
This EIP adds nothing of value to the chain. All it does is redistribute wealth from the current owners and give a little bit back to Parity. You can’t perform such an action without either tyranny of the majority or tyranny of the minority benevolent as the action may be.
Current consensus protocols are clear; put it to a vote to the miners. That’s the whole point of Proof-of-Work.
It seems incredibly, incredibly foolish to me to change the fundamental operating assumptions of a block change for an issue that negatively affects less than 1% of the total supply. I can’t believe it’s even a discussion.
I am philosophically in favor of being able to perform actions such as EIP-999, but only after a very thorough analysis of potential outcomes and engaging in a very careful ethical and legal review.
Beyond being in favor of occasionally “intervening”, I would advocate that the community generally be prepared to alter the shared state in order to prevent harm to individuals or organizations.
Tools and governance processes need to be in place.
Still, I understand and appreciate that there is a widespread expectation for immutability in Ethereum. This is a special property which has many measurable benefits. However, immutability of information systems is unprecedented in human history. This property does not absolve us of moral or legal responsibility for what happens in the Ethereum network. It may be dangerous to enforce this immutability absolutely, or simply to be unprepared when we as a community must suddenly act to alter the shared state.
Perhaps with EIP-999 and other ether recovery EIPs we can attain and manage an extremely low mutability in our system instead of assuming immutability.
I oppose this EIP, and I oppose the way discussion has left GitHub and is now on this new site.
Ethereum is as immutable as you design it to be. The Parity contract was designed to have an immutable reference to a library that got deleted. What more is there to say?
Should someone get special treatment because they have a lot of money? I don’t think so. If this EIP goes towards a production state I will be the first person to maintain an Ethereum blockchain that has not been hardforked to restore the parity library.
Decentralization is not an end in and of itself but a means to eliminate the risks that come with a centralized system. Specifically, decentralization provides the means to protect against centralized control that would otherwise threaten an individual’s right to control his or her own assets. Decentralized blockchain systems have value as a tool because they can protect private property rights in a way that was not previously possible. However, to the extent these new systems introduce new ways that prevent owners from accessing that which they own, they fail to be useful.
Also, the blockchain is not immutable, nor would it be of any use if it were. The current state of the blockchain mutates with every transaction. However, client logic is designed to prevent unauthorized changes. An account owner authorizes the client application to perform actions on his or her behalf by signing transactions, thus proving their ownership and intent to mutate their portion of the blockchain state. To be clear, owners grant permission to the client to modify the blockchain state on their behalf, not the other way around.
How, then, should a decentralized system behave when users are prevented from controlling the assets they own?
Proof of ownership and intent are of primary importance. If ownership and intent can be demonstrated (e.g. through signed messages, data on chain), what grounds do we have to prevent owners from controlling their assets? Why should we sacrifice the ends in support of the means?
But how much is occasionally? What schelling point are you advocating?
The reason “immutability” is popular, is because it’s an exceptionally good schelling point.
If you don’t have an equally good schelling point to offer, I don’t see how the community can be be prepared to alter shared state, no matter what harm might be the consequence.
Immutability is a far simpler schelling point. By choosing to manage low mutability we do incur costs and risks.
Perhaps a scheduled intervention should be so rare as to be newsworthy. This way, users can expect to a well-publicized notice about a proposed intervention that may affect them, and plenty of time in which to voice their concerns.
It may be appropriate to set the bar very low for how much individual damage of losses would oblige an intervention. If 10,000 people experience a very small loss correctible by shared state alteration, and performing a recovery has a very low cost in effort and risk to others, the only requirement may be ensuring due process and well-publicized notice.
For Ethereum platform to retain its value proposition retro-active irregular stage change should not be institutionalized or pushed through unless the entire platform is in jeopardy. EIP should be for protocol improvement only, not for retro-active correction of a selected sub-set of errors that have been made by some vested interests.
I believe funds currently locked would have benefited the ecosystem & good intention of EIP-999 proponents but can’t say the same about future actors that will try to go down that path again.
Internet services got hacked zillions on time and the internet is still being used. Planes crash every now and then but the airline industry has been flourishing.
Work should be done to make Ethereum / DLT tech much safer and usable doesn’t equate to irregular retro state changes should be made in this specific situation. There are plenty of other ways to make DLT much safer:
Solution 1: Mutualisation of risk: Companies & ICOs can create common issuance pools to cover part of the loss when missteps are made.
Solution 2 - Innovation at large: Formal verification, develop better practices, etc.
Do you think it is reasonable we will be able to restore any and all lost funds, including a single dollar in a failed testing application? No? I agree, that would be completely unworkable. So there would need to be some kind of cut-off what will be restored and what not. This is the dangerous part. Who will decide what should be restored and what should not? How do we prevent these entities from being bribed or extorted? Again, a blockchain where extortion and bribery is possible is not useful to me.
And that is not the only issue with that. There are more nuanced and indirect consequences of such a system. The fact that only some funds will be restored, because they are worthwhile (hundreds of millions vs a single dollar) means there will be a preferential treatment by definition. And this will bring forward a “too big to fail” mentality. Assume for a moment there is party A that runs a smart contract for multisign wallets and is the largest by far. Then party B comes with a new smart contract for multisign wallets. People like how it’s used, however, why should you use this new smart contract that is dealing with much less funds? Due to preferential treatments and “too big to fail” mentality it would be better to use an older, perhaps even inferior version, simply because it is dealing with larger amounts of money and hence in the event of lost funds, there is a greater chance they will be bailed out. This would then be a very strong force that leads to monopolies (centralization) and uphold these monopolies.
This “too big to fail” mentality reminds me one thing: Banks. And not in a good way. Please, for the love of Blockchain, let’s keep such a mentality away from Ethereum. We need real, workable and sustainable solutions: Formal third party code audits. If Parity had done their due diligence this would never have happened. And I agree, even with formal audits, things like these might still happen. So let’s solve this in a fair way: Insurance. Decentralized insurance funds could easily work for insuring against these kind of code bugs. And they’ll bring about loads of other positives: They will probably enforce code audits, or they refuse to insure a smart contract. They can be used by large parties, but also by smaller parties, hence no preferential treatment. And most importantly, disputes will be handled between the insurance fund and the affected party, instead of being handled at Ethereum’s base layer, which brings decreased immutability for everybody.