7

Absolute beginner question: If I assume that my contract is complex and will need future features or bugfixes, and that it holds assets and records privileged addresses, how should I prepare for an upgrade?

Should I include a function that disables the contract and transfers all the assets and addresses to a new contract? To plan in advance, what other arguments should this function accept? How should I manage the authority to execute this upgrade - hard-code my public-key? Or should I try to separate out a "back end" with business logic, and leave the front end to find the correct back-end? How should I deal with users attempting to execute the contract after it's been made obsolete?

Improve this question
1
  • 3
    It seems to be a duplicate, but you do answer more or a bit different questions. Maybe reword this to address those not answered in the other thread?
    – axic
    Mar 20, 2016 at 14:05

1 Answer 1

Reset to default
5

I think the most practical option is to program a self destruct function (it's recommended all contract have this): 

function selfDestruct() {
    suicide(msg.sender);
}

If the contract is one with multiple depositors you would have to modify the function to send each depositor a refund before committing suicide. After that you'd change the contract and everyone would have to opt-back in to make sure they actually agree with the code changes you made.

I think it would be possible to allow changes to be made to a live contract but a contract which allowed the owner to make any changes would defeat the purpose of decentralization. Though you could counter this by having some kind of voting mechanism.

I'd be interested to see examples of functions which allow contract users to create or propose new functions though I imagine the gas cost would be extremely high.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.