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.
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.
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.
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.
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?
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.
16 comments
[ 4.6 ms ] story [ 45.8 ms ] threadI 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.
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.
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.
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.
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.
Since this isn't very likely, it strongly implies the smart contract model isn't a good one for writing software.
[1]: https://www.reddit.com/r/ethereum/comments/57ork1/ive_made_a...
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?
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.
It does seem like a tradeoff.