
Upgradeable smart contracts in Ethereum - zabi_rauf
https://zohaib.me/upgradeable-smart-contracts-in-ethereum/
======
Animats
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.

~~~
xorcist
> 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.

~~~
leetbulb
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?

~~~
xorcist
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.

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

~~~
JumpCrisscross
> _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.

------
dmart
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?

~~~
chrisshroba
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.

~~~
domrdy
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).

~~~
crispyporkbites
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

~~~
weego
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

~~~
crispyporkbites
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

~~~
weego
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.

------
akerro
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?

~~~
ancorevard
Yes, that is true:
[https://github.com/ethereum/EIPs/pull/999](https://github.com/ethereum/EIPs/pull/999)

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

------
45h34jh53k4j
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.

~~~
crispyporkbites
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.

~~~
eudoxus
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.

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

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

