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!
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.
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.
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:
- How does a user offer data and how does your contract (or another user) accept the offer?
- 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.
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.