[AlexSolution]

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.

[mirekrusin]

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.

[AlexSolution]

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.

[mirekrusin]

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".