Contracts with terms that can be changed retroactively by one party. What could possibly go wrong? The whole point of this smart contract stuff is supposed to eliminate the need for trusting a party.<p>The article has full details on how to create a contract changeable by one party, then hand waving about "writing a contract that uses tokens and voting mechanism to allow the community to decide whether to update or not." No details on how that's supposed to work. Who's "the community", anyway? The parties to the agreement are the ones involved.<p>A mechanism where all parties to a contract could agree to replace it with a new contract would be useful. That's a normal contract activity. You do that whenever you renew a lease.<p>The Etherium promoters want this because they botched the design. Smart contracts as byte coded programs are too error prone. The DAO debacle, and this latest demand for a "state change" because someone botched a big contract, indicate that. Smart contracts should have been in some declarative form like decision logic tables, not Turing-complete programs with race conditions.
Injecting a delegate into an otherwise vanilla smart contract doesn't seem like the hard part of creating an upgradeable contract. The hard part is coming up with a consensus model for agreeing to the change. Bilateral agreement doesn't seem strong enough, let alone unilateral agreement.
Is immutability of a contract not the entire point? What security does a decentralized smart contract offer if its implementation can be totally swapped out?
I heard that story behind this is that one of close friends of ETH developers lost a few $M in smart-contracts, so they want to be able to update its source code to access the ETH, is that true? How would that work?
Upgradable infers that the underlying contract address has a new chunk of code. That is not what this is proposing.
This is simply making resolving contracts, which is best practise today.