Hacker News Reader

Comment by withzombies | Hacker News Reader

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.

View on HN

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.

Looks like this a known issue : 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...

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.

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.

There is a way around it, but it's complicated, expensive (in terms of gas), and thus I have never seen anything similar deployed yet.

Basically, use a proxy contract with some form of governance built in to it. The governance is comprised of all Dapp users/token holders/parties/whatever. Using this system, an upgrade can be proposed. The upgrade is a hash of the new contract's EVM bytecode. Then, there are X days for all parties to vote, until Y% approve it (of course, deny or not getting enough votes means nothing happens). Once approved, someone must deploy the new contract code to the blockchain. After the new contract has an address, the proxy contract gets a "finalization" command with the new address. The proxy contract then reads the bytecode of the new contract, hashes it, and compares the hash to the voted on hash. If it matches, then it points to this new contract. Depending on the details, there might be a migration command sent to the old contract, telling it to send coins, state, etc to the new contract and to self destruct. If there are no coins held by the contract, then the state and old code can remain on the blockchain for people who disagreed... Of course, this is stupidly difficult to fully realize in Solidity, but Ethereum has all the features necessary in the EVM. I personally think the faster we can move away from EVM and Solidity, the better off the smart contract world will be.

Yes, you shouldn't change the terms of a contract after the fact, so you only need to think of all possible use cases of the smart contract in advance, test for all edge cases, and then write flawless code in a minefield infested language like Solidity (a feat that its own creator couldn't accomplish).

Since this isn't very likely, it strongly implies the smart contract model isn't a good one for writing software.

We previously learnt this with database triggers and stored procedures, where pretty much everyone with experience says "DON'T DO THIS!" It turns out commingling your program with your data is an obfuscation, debugging and maintenance nightmare, and you should almost always keep the program manipulating your data separate from the data. And that's before the ridiculous idea of making the program super-hard or even impossible to fix bugs in.

Don't forget, you also need to make sure your code will never break [1] by an Ethereum blockchain upgrade or security fix too.

[1]: https://www.reddit.com/r/ethereum/comments/57ork1/ive_made_a...

Reply on news.ycombinator.com