Upgradeable smart contracts in Ethereum | Hacker News Reader

Upgradeable smart contracts in Ethereum

zohaib.me

98 pointszabi_rauf40 comments

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.

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.

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.

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.

> not Turing-complete programs with race conditions.

I know it's common, but please stop calling reentrancy bugs "race conditions". Smart contracts don't observe concurrent modification of state by other contracts and aren't internally concurrent. Solidity and the EVM object model have way too much implicit behavior, which can lead to unexpected control flows, but these unexpected flows aren't the result of other threads coming in and mucking up state.

Calling a simple reentrancy bug or spookily unexpected control flow a race condition lets the Solidity and EVM designers off too easily. Concurrency with shared mutable state is always difficult, but Solidity makes even simple single-threaded reentrancy difficult to get right. (On a side note, I'm a big fan of Actors/shared-nothing concurrency and think raw threads are almost always the wrong abstraction to expose to application-level developers.)

I also totally agree that Turing completeness is overkill for 99% of use cases, leading to bugs in simple contracts and makes analysis very difficult. If you really need Turing completeness, you could still explicitly construct it within a sufficiently expressive declarative non-Turing complete execution model via externally triggering repeated contract invocation. (For instance, a Brainfuck interpreter that advances one program step per contract execution.) The ecosystem would be Turing complete without contracts being Turing complete.

Smart contracts are usually not meant to be actual contracts between parties so much as something more like financial applications. For example, a common type of smart contract implements a new token type by providing an API for distributing and transferring them. This is the kind of thing that could be useful if you could upgrade it, perhaps with input from token holders. That said, I totally agree with the idea of declarative smart contracts for things that are actually contracts.

>>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 possibilities are endless. You could have pre-chosen adjucators that can upgrade a contract on majority vote. You could use a decentralized prediction market like Augur to trigger a contract upgrade if it deems that certain events occurred, etc.

Upgradability is just one component of many that will be needed to create a durable/secure smart contracting system. It's not a silver bullet.

>>The Etherium promoters want this because they botched the design.

Do you misspell Ethereum deliberately? I only ask because I've seen you comment multiple times about Ethereum with this misspelling, which comes across as very petty.

>>The DAO debacle, and this latest demand for a "state change" because someone botched a big contract, indicate that.

The latest state change request is overwhelmingly rejected by the community and will not happen.

The request is only possible at all because of the temporary state of Ethereum having several hard forks planned that a state change can be snuck into.

Once this phase of its life cycle is over, even requests for a state change will not happen.

>>Smart contracts should have been in some declarative form like decision logic tables

The point of using byte coded programs and a Turing Complete execution environment is to make features like the smart contract programming language totally configurable, rather tied to a single base implementation.

The biggest advantage to a blockchain, in fact the only thing it does better than other systems, is immutability.

Lots of people don't seem to appreciate this.

Seems like The DAO bailout prove that the blockchain is most certainly mutable...

> Smart contracts as byte coded programs are too error prone

That's perhaps a too strong statement. Bitcoin's smart contracts are byte coded programs too, and have had none of these problems. Perhaps partly because a lot of the instructions were pruned early on, and only those deemed absolutely necessary for the kind of contracts that made sense were kept.

I don't think that's a fair comparison. Would you say that something turing complete is more error prone than something that isn't?

Turing completeness isn't really an interesting aspect of the VM. Ethereum could probably remove the loop instruction without affecting any contracts of importance, but the DAO would have happened anyway.

And because almost nobody ever used Bitcoin smart contracts.

You could build a declarative contract language on top of Etherum's Turing-complete language.

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.

> Bilateral agreement doesn't seem strong enough

Why not? If you and I agree on something, and then agree to amend it, that's valid.

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.

Couldn't you say the same thing about the long legal documents that we all sign when signing up for commercial banking products?

We're all legally protected from unfair or arduous clauses in contracts because of legislation.

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.

https://consensys.github.io/smart-contract-best-practices/ge...

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)

https://vitalik.ca/general/2017/12/17/voting.html "feelings in favor of completely algorithmic governance (emphasis on “completely”) are absolutely crazy"

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?

$91 million of Polkadot ICO funds, Gavins ICO. Gavin a cofounder of Ethereum, and the creator of Solidity.

So its more like the cofounder of Ethereum lost $91 million dollars in his own wallet, using his own smart contracts, using the language he wrote.

I am against the proposal to undo the deleted multisig wallet contract. Everyone makes mistakes, some are worse than others. You can never learn if every mistake can be undone.

The article is only partly related to that incident. People have been trying to figure out reasonable mechanisms for doing smart contract updates since before the Parity Multisig matter. What is discussed in the article is being used today and doesn't require implementation of an EIP.

The desire to sort out how to do updates is motivated by much more than just that particular incident.

Yes, that is true: https://github.com/ethereum/EIPs/pull/999

It's true, but it's not related to OP's article.

You can't modify smart contract code once it's been deployed, period. Ether that's locked up in bugged out contracts is permanently lost.

This post describes a strategy for writing contracts that proxies the actual implementation of the contract to another contract. If the contract needs to be modified, a new contract is deployed and the original contract is set to point to the new contract.

Edit: I misread your comment. There has been a discussion over of a possible hard fork in order to recover lost funds, but that's not what the author is referring to in this post.

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.

It achieves the same thing though, you call a contract at address A, which is usually proxies to contract at address B. The owner of A can shift the proxy point to address B or any other address.

The danger here is that the user calling the contract is not aware of the proxy and the new contract does something unexpected.

The way I see it, if you are using a contract and you don't know that there is a sole owner that has the ability to upgrade the underlying contract to something else, which could be nefarious, then that is in the same wheel house as using a contract with a bug in it anyways.

It should be standard practice to have some governance model around the upgradeability (IE Multisig, Liquid Democracy, Aragon, etc...). Any contract that doesn't use some governance should be considered insecure and not used for financial transactions on the chain.

Maybe consensus should only be reached on certain invariants, with the underlying implementation being far more mutable.

Very cool! Not applicable to all use cases, but where it is applicable it is a great tool.

Reply on news.ycombinator.com