0

I'm reading here:

Centralized Administrator

All dapps are fully decentralized by default, but that doesn't mean they can't have some sort of central manager, if you want them to. Maybe you want the ability to mint more coins, maybe you want to ban some people from using your currency. You can add any of those features, but the catch is that you can only add them at the beginning, so all the token holders will always know exactly the rules of the game before they decide to own one.

(Emphasis mine)

What is a best practice to manage making changes you don't forsee when you start your dapp? Eg, suppose you only issue 1000 things, and later find a bug, need to increase to 1500, how do you handle this?

I see this document goes on with instructions for...

Central Mint

Suppose you want the amount of coins in circulation to change.

But suppose you did not "only add them at the beginning." What now? How does this square with the statements above, and how do you manage such changes?

|improve this question
1

The basic idea is that your contract has to support all the changes you possibly want to make into in in the future. So if you have some static number there and no functionality to change it, it will always stay the same. So if you have numbers which you may want to change in the future, add functionality to change them.

However, this does not necessarily mean you have to explicitly know which parts you want to change in the future. This is because of something called upgradeable contracts (see for example https://medium.com/quillhash/how-to-write-upgradable-smart-contracts-in-solidity-d8f1b95a0e9a ). Upgradeable contracts are just a design trick/pattern, but you have to add support for them in the beginning if you want to use this pattern.

If you are left with a contract which does not suit your purposes and you can't extend/modify it to suit your purposes, your only option is to write a new contract and in some fashion migrate everyone to use the new contract. Depending on the type of contract, this may be anything between impossible and trivial.

|improve this answer
  • Thanks, this is helpful. Is this the minimal and most accessible version of the upgradable contracts idea I should study for implementation? – Mittenchops Nov 14 '18 at 19:31
  • Does "in some fashion migration everyone to use the new contract" possibly mean, to essentially hard fork your own contract? Replicating data stored there, subject to your changes, but you cannot delete the old one's existence? – Mittenchops Nov 14 '18 at 19:32
  • 1
    That's a somewhat advanced article about upgradeable contracts. I'm sure you can find more basic articles also if needed. And yes, you can't delete old contract so you need to kind of hardfork the old one - migrate data and get everyone to use the new contract – Lauri Peltonen Nov 14 '18 at 20:15
  • 1
    You can also use "proxy / kernel based" upgradeable smart contracts that will let you update functionality by linking to a different contract when you need to upgrade things. Thou you want the affected parties to "agree on such changes" before they go into effect. Check out the Aragon project or the Blockbitsio project sources for some implementations that will allow you to migrate to new functionality. – Micky Socaci Nov 14 '18 at 22:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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