3

If I create a Smart Contract that pays users for sharing their data, how can I ever update this smart contract in the case it has an error, or perhaps I wish to change the amount paid for data sharing? From what I understand, I basically must create a new smart contract at a new Ethereum address and somehow find a way to re-connect my users to this new contract. If true, this tends to feel much like centralized systems again, where the smart contract writer can change the rules (payment rates) when they wish. Obviously I am missing something here... can some please explain? Thank you!

2
  • By default contracts are not upgradeable but you can design a system with upgradability in mind. Depending on the context a user might want an upgradeable contract or not. – Ismael Jan 7 '20 at 18:46
  • 1
    Does this answer your question? Upgradeable smart contracts – Achala Dissanayake Jan 8 '20 at 4:39
2

If I create a Smart Contract that pays users for sharing their data, how can I ever update this smart contract in the case it has an error

Although it is not possible to upgrade the code of your already deployed smart contract, it is possible to set-up a proxy contract architecture that will allow you to use new deployed contracts as if your main logic had been upgraded.

Proxy Patterns

A proxy architecture pattern is such that all message calls go through a Proxy contract that will redirect them to the latest deployed contract logic. To upgrade, a new version of your contract is deployed, and the Proxy is updated to reference the new contract address. More about Proxy Patterns here

perhaps I wish to change the amount paid for data sharing?

You don't need to update the the smart contract to change the amount paid for data sharing. A better way to achieve this functionality would be to set public state variables for the fees and exposing ownerOnly functions to update them.

From what I understand, I basically must create a new smart contract at a new Ethereum address and somehow find a way to re-connect my users to this new contract. If true, this tends to feel much like centralized systems again, where the smart contract writer can change the rules (payment rates) when they wish

This is true to an extent. But in case of blockchain, all events are transparent and any changes to the contract will be visible on the ledger. A few leading dapps like Kyber, Synthetix use Proxy Patterns to make sure they are able to fix code in case of a bug or security issue. You must also consider the fact that how much power the smart contract owner has if they are deploying proxy contracts.

2
  • Thank you so much for all your effort, incredibly kind, thanks! You mentioned updating public state variables to change the amount paid for data sharing... I see now that this does not need an update to the smart contract itself, simple an update to this variable. I assume only the contract issuer can do this? And again, is this can be changed ad-hoc by the issuer, where does the confidence come from? I suppose the customer must continually check the rate before selling their data? Once again thank you and sorry for the Noob question. – R N Jan 8 '20 at 7:54
  • You can do it in two ways based on your requirements. If you want a single user like the contract owner only to update, then you use a state variable named owner which is initialized in the constructor of the contract when the contract is created. Or better use the Openzeppelin Ownable smart contract library. The second way to do this would be to create a mapping of address to bool which will evaluate to true for all the addresses that are allowed to update the rate. The rate will be visible to the user before he signs the tx, so user can decide if he wants to proceed with the tx or not – Sudeep Jan 8 '20 at 19:55
1

Blockchain ensures that you can't rewrite the past, so you have to dispense with the idea of modifying it.

pays users for sharing their data, how can I ever update this smart contract

It doesn't sound like you want to change the contract. Rather, you want your users to agree to a process whereby they are paid the current prevailing rate, whatever that is.

It is usually a mistake to think of a "contract" as analogous to a legal agreement as if each user relationship is a separate instance of the contract. it will be more helpful to think of it as a reliably executing process that the users can look at and see that you can't arbitrarily change it.

Your process would have to address some non-trivial concerns:

  1. How does a user offer data and how does your contract (or another user) accept the offer?
  2. How is the price determined and how does the buyer validate the information presented?

If you work out those business processes, then you can codify them in a smart contract that enforces the processes.

It will not be necessary to modify the smart contract if the terms of future agreements stay within the parameters you have set up. That is, you anticipate in advance the flexibility anyone will ever need. For most intents and purposes you will not have the option of altering the smart contract and much of the assurance participants have stems from this property.

must create a new smart contract at a new Ethereum address and somehow find a way to re-connect my users to this new contract

In the case that the contract's usefulness deteriorates over time, then the process of transitioning to something new will be painful unless you have mapped out a transition process ahead of time.

Think of a spaceship you shoot into deep space as fast as it can go. You will never be able to catch up so the only things that will ever be onboard are the things you put there. You can still talk to it. You could, for example, deploy a new module and integrate it, but only if the spaceship was designed for component replacement on-the-fly. If it doesn't respond to commands than there is nothing to say.

this tends to feel much like centralized systems again

Every opportunity to alter the code or even important parameters (the price?) potentially re-introduces centralization. A good starting point for thinking about that is "Who decides?"

It is not uncommon for certain functions to be reserved for an authoritative user or whitelist and that is almost always a degree of centralized decision-making. An exception may be when that user is itself a contract concerned with a more inclusive, more democratic process - the app recognizes an all-powerful user, but that user only expresses the collective will of a quorum of participants.

The design of governance and the advisability of upgrade possibilities for any given function needs to be considered on a case-by-case basis. Since we have the capability of producing centralized authority, completely decentralized evolution or something in between, it's important to think about the tradeoffs and justifying every decision.

It is almost always preferable to focus on a process that is worthy of rising to the level of eternal truth rather than latching on to upgradable patterns like modular design, proxies and eternal storage. It's also vital to practice extreme quality-assurance before you launch.

Hope it helps.

2
  • Thank you very much for all your time and effort on this, it is very much appreciated. So, smart contracts are immutable, yet can contain variables that can be adjusted whenever by the issuer. Customers can be re-mapped onto new contracts via proxy contracts if the need arises. New programs and features can be integrated so long as the initial contract will accept it. I think I understand. Thanks again! – R N Jan 8 '20 at 8:33
  • There are some good answers here. You might be interested in this "third way" that addresses the centralized trust concern as well as gently explaining the tradeoffs that are always in play when playing with upgradable contracts. medium.com/hackernoon/… – Rob Hitchens Jan 8 '20 at 11:50
0

A single monolithic contract which has all the required functionality is as it is and there's no way to change/update/upgrade that. Your only option is to deploy a new contract and somehow get users to use the new contract (and copy state from the old contract) - that's a lot of work.

This is where different contract patterns comes in. Basically what you want is to separate different parts of your one monolithic contract into multiple separate contracts which are connected to each other with some mechanism and where each contract can be upgraded individually through some mechanism.

Quick googling gave for example this promising page (although a bit old): https://github.com/fravoll/solidity-patterns . There you should look especially at the "Eternal storage" pattern.

2
  • Thank you very much for all your effort here, what a terrific community! – R N Jan 8 '20 at 7:03
  • whoah, didn't even notice there were other great answers. nice! – Lauri Peltonen Jan 8 '20 at 7:06

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