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 think the point isn’t so much immutability for the sake of immutability but rather immutability for the sake of keeping power out of a centralized entity. With the scheme proposed in this article, you could do things like have contract changes only be authorized by, say a 2/3 vote of token holders, or any other complex logic you want to implement in a smart contract. Of course if there is some contract that has a single individual with the power to make arbitrary modifications, it likely won’t be successful, but with decentralized ownership I think it could work.
Yes, that sounds reasonable. It's kinda worrying that some popular smart contracts implement "Pause" functions, callable only by one address (usually the creator of the contract).
You, as the user, can see those functions and choose not to use those contracts. With a closed source or black box api you don’t have that power as an individual
So in this wonderful future we're building anyone who wants to safely execute a transaction should be a specifically skilled programmer? Sounds more dystopian than other possibilities
You mean how in the current world we live in to do pretty much anything you need to know how to boot up a computer, login, open up a web browser, connect to a remote server over a tcp protocol, navigate through a series of special documents rendered by the browser, access a separate protocol called email, reopen a hyperlink from the email in a new instance of a web browser, and then finally you can actually do something?
The reason all those things are so easy to do is down to years of work optimising the UI and handling errors well- we’ll get there with smart contracts too one day
I get what you mean, I feel like transparency should never be a "if you're in the know you're protected, if not you're taking a gamble".
This is probably a good case for natural language as a program. If smart contracts can be immutable natural language contracts that can be proven to compile to code in a repeatable manner then we're making progress.
Pause functions are actually considered a matter of best practice. It's a way of mitigating the contract's risk. Now, who gets control of the pause function is an entirely separate discussion worth having. The controlling address could be a contract implementing a multisig scheme, allowing for the decision to be made by more than just a single individual.
All state transitions are forever visible in the blockchain. Since addresses can be set dynamically in Ethereum, it's possible to update the contract addresses which make up the business logic pipeline. This sort of pluggable design is not a requirement, and some contracts are completely immutable.
Decentralization and immutability are entirely separate subjects. The security benefits of decentralization are not lost just because pipeline components can be altered.
The problem is for other contracts that want to use upgradable contracts - before you could be sure/analyze correctness but now you need to consider the underlying contract's implementation can change in arbitrary way, it's outside of your control, ie. if the upgradable contract you're calling is hacked it can turn malicious towards your contract - something you didn't have to worry about before.
I don't think this functionality is anything new, it's just a design pattern. As for safety, you're absolutely right. Best practices dictate that when calling other contracts, you should mark the code as untrusted, and treat it as such. It's somewhat analogous to running untested dependencies, and stipulating in your requirements that the latest version of those dependencies should always be deployed.
It's not new (if we're allowed to say that anything in system created less than 3 years ago can be "not new") but the core functionality (delegatecall opcode) was added to support linked libraries. Delegatecall's abuse to use it for "upgradable contracts" is relatively new, the opcode was not designed to handle this "pattern", it's somehow undesired consequence of introducing it that it can be abused in this way. Noting more than that. Really, I don't think most people realize what it actually means and what can and cannot be altered in "upgradable contract".
Exactly, now when you're writing contract that calls upgradable contract, you need to consider that its implementation may turn into hostile code. And it goes deeper - you can call normal contract but if that contract is calling upgradable contract - you may have the same problem (that's harder to track).
IMHO it violates basic guarantees of the blockchain that things underneath you won't change. The focus should be on designing correct contracts upfront, patterns, automatic provers etc. not "solving" the problem by allowing for arbitrary change.
Also "upgradable contracts" sounds nice but it's extremely difficult to actually upgrade more complex contracts, you can't just modify things the way you feel, the original storage can't be changed, this means you can't introduce/change/remove fields in existing structs etc.
This is a good point. However, there is still fairness through: 1) transparency 2) adding fair criteria to upgrade.
Criteria to upgrade: like chrisshroba mentioned, one can use a decentralized algorithm to vote on upgrade, making it more fair. Altnerativley there are things like SageCoin in which a fair 3rd party can step in to settle a dispute. This is more centralized, but still blockchainers seem to appreciate this. Below is a quote from Vitalik that I think roughly applies here. (also im not trying to favor the latter method)
