3 ms·

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 wan

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.

deleted 8y ago
[deleted]
Animats 8y ago
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 8y ago
  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/master/contracts/SimpleMultiSig.sol 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.
  - Animats 8y ago
    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.
- earlz 8y ago
  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.
briatx 8y ago
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.
- davidgerard 8y ago
  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.
- earlz 8y ago
  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_list_of_contracts_which_will_be_100/ https://www.reddit.com/r/ethereum/comments/57ork1/ive_made_a...

deleted 8y ago

[deleted]

Animats 8y ago

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 8y ago
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/master/contracts/SimpleMultiSig.sol 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.
- Animats 8y ago
  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.
earlz 8y ago
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.

briatx 8y ago

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.

davidgerard 8y ago
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.
earlz 8y ago
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_list_of_contracts_which_will_be_100/ https://www.reddit.com/r/ethereum/comments/57ork1/ive_made_a...