
How smart contract upgrades fail in practice - dguido
https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/
======
pag
The Solidity language is deceptively low level, which partially stems from
implementation details related to how the solc compiler chooses to implement
language features.

Developers coming to Solidity from a language like Javascript or Python expect
names in objects (~Contracts) to be significant determinants in terms of where
the data associated with those names are stored. This is due to Javascript
objects basically being dictionaries.

I think this problem could have been avoided early on if the storage locations
of contract variables were derived from keccak256 hashes of their names. This
type of implementation decision, though, would likely require disallowing
shadowing of contract variable names in inheritance hierarchies (something I
think is a good idea).

If you're not familiar how the solc compiler compilers Solidity to EVM, then
using a keccak256 to determine where in persistent storage a value is placed
might seem kind of crazy. In fact, this is par for the course. For example,
solc implements Solidity key-value mappings by hashing the key along with some
other stuff, and then writes the value into memory. This means that mapped
values are spready out wildly through the persistent store -- so why not do
this for variables?

~~~
jacobush
Very diplomatic. I'd say tire fire.

------
jnordwick
People writing these things want a trustless, secure, easily changed, pseudo-
anonymous contact.

I'm fairly sure you can do all those at once.

I think they are fighting a losing battle and we are going to see more dApps
go back to central servers and just use the blockchain to hold certain
ownership information. The rest of the account and logic will be in private
servers.

~~~
mike-myers
Did you mean "cannot do"?

It does seem like a tradeoff.

~~~
jnordwick
Opps. Yes.

------
techfyii
Smart contract programming requires a different engineering mindset than you
may be used to. The cost of failure can be high, and change can be difficult,
making it in some ways more similar to hardware programming or financial
services programming than web or mobile development.

~~~
dboreham
True, but why do we need to assume that all code should be written by
web/javascript developers? Software is a big space.

------
withzombies
I've been thinking about this problem for a few weeks now and I'm not certain
you can safely upgrade any deployed contract.

I know a lot of dApp developers want to be more agile with their deployments
but you shouldn't be changing the contract terms after the fact.

~~~
Animats
_You shouldn 't be changing the contract terms after the fact._

Exactly. The contract having an "owner" other than the parties who agreed to
it is just wrong. Any real-world contract can be changed by mutual consent of
the parties. The company that printed a contract form can't change a signed
copy of that form.

 _" An agreement to agree is not an agreement"_ \- legal maxim.

~~~
dboreham
Looks like this a known issue :
[https://github.com/ethereum/EIPs/issues/763](https://github.com/ethereum/EIPs/issues/763)

although one of the proposed solutions involves having the contract maintain a
list of owners. The list being maintained by ... the owner...<doh>:

[https://github.com/christianlundkvist/simple-
multisig/blob/m...](https://github.com/christianlundkvist/simple-
multisig/blob/master/contracts/SimpleMultiSig.sol)

It seems to me that you'd need to extend Ethereum such that contracts were
created with multiple owners, by having each owner sign the creation txn. Once
created, contracts could subsequently permit additions to the owner list by
quorum logic implemented within the contract.

~~~
Animats
_although one of the proposed solutions involves having the contract maintain
a list of owners. The list being maintained by ... the owner... <doh>_

That retains the control-freak EULA approach common to web design. The site is
in charge, and you peons will take what we give you.

