Dapp versioning and community consensus

One of the interesting challenges with smart contract based Dapps is continuity.  Lets say you have a complex Dapp that relies on half a dozen different contracts, very quickly during development it becomes apparent that some sort of versioning system needs to be applied to the contracts that are deployed and which versions support what API.

Most developers wont want to bother with updating their dapp each time a new contract version is deployed.  The obvious progression is to allow the existing contracts to manage their own versioning with developer only triggered upgrades that point the contract to use sub contract v1.2 instead of v1.1 for example.

This works great, and means if there is ever a nasty bug in any of the contracts the developer can easily upgrade the contract in realtime and all users of the dapp will instantly get the new *hopefully* bug free logic.

However, there is a massive risk in that last paragraph.. “The developer can easily upgrade the contract in realtime”.   Can you imagine if Bitcoin had the ability to change its logic at anytime without any consensus from the community?

When deploying contracts that deal with a large user base that have to trust the contract rules, like a global token of value it is important that the logic/rules cannot be changed without large scale agreement.

You could of course create a voting system where token holders vote on which change/contract is allowed to supersede the previous.  And this will certainly be used in many scenarios, however most changes will require parallel changes in the Dapp/UI which will also require the users to update their software at just the right time.. tricky.  Why not bundle the code updates and smart contract version updates into the one software release.  This way consensus can only happen by physically stopping your old dapp and installing the new version and starting it back up.

This slow, physical upgrade path provides time to analyse the results of the changes, discuss with peers, code review, and gives the end users the ultimate choice as to which changes they agree with and enact upon.  Unfortunately this means fixing bugs will take hours-days instead of seconds-minutes but the trade-off seems worth it.

There will be utility contracts and non critical contracts etc that can be switched by the developer, but token related contracts should have some guarantee of continuity.

Leave a Reply

Your email address will not be published. Required fields are marked *