You are viewing a single comment's thread from:

RE: My thoughts on the debate currently occurring in the Ethereum community over The DAO hack

in #ethereum9 years ago

For big smart contracts - maybe it's doable, but what about thousands of small ones?

So this comes down to a philosophical difference I have about the usefulness of DApps and smart contracts (and part of the reason I didn't buy into the Ethereum idea). Personally, I don't think there is all that much value in thousands of small smart contracts written by various authors. And I think the synergy arguments are overrated.

But this is a very good point:

And what criteria will be used to differentiate between those smart contracts which are worth a hardfork and those which are not?

One could think of a very small smart contract as being an instantiation of an existing smart contract template with certain dynamic parameters (so no Turing complete code in that case at all). If someone instantiates that template with bad parameter values that could lead to loss of funds. Is that a bug in the smart contract code? Does it warrant a hardfork to fix (perhaps by limiting the range of values for the dynamic parameters to safe ones)?

What about other mistakes like someone accidentally sending their coins to the wrong address (one that it is virtually impossible to find the private key to)? Does that warrant a hardfork to return the coins back the original owner?

I think the reasonable answer to this is no. But who gets to make that call? Ultimately the people in charge of the DApp or platform in which these flawed operations occur. The people who have the authority to make the hardfork decision (witnesses or even stakeholders in a fully independent DPoS blockchain, or the multisig custodians in the sidechain DApp) have to have some blockchain-based consensus process to decide whether some mistake or bug is even important enough to warrant a hardfork to correct. This consensus process would normally be so difficult to reach a sufficient quorum that it would likely only be used to correct serious bugs.

Having a single chain implies only one possible path to follow: immutable code.

Yes, Ethereum's model means there are serious complications to "hardforking" to fix bugs in smart contracts. It requires disrupting the main chain to fix one DApp even if all others DApps are just fine. Which is why I don't think there is a clear good solution to this particular case with The DAO hack. I think the best that can be hoped for going forward for smart contracts running on Ethereum's model (assuming their model wasn't changed) is for the smart contract to build in the multisig judge into the code (and hope that at least that part of the smart contract code isn't seriously buggy). I just very recently (in the last hour) read a post describing a similar concept that the author of the post named contract stewards.