This is kind of a theoretical question with respect to Ethereum DAPPs which I have been trying to learn lately (and of which I will admit I am still woefully ignorant).
Basically (using my limited knowledge) I would describe a DAPP in this way: A DAPP is a collection of smart contracts (which interact with each other through public API's - each contract has one).
Each smart contract is an decentralized program running on the block chain. In other words, when a call goes out to the contract, every node in the ethereum network runs the contracts code and updates its state. This essentially means that the state of the program (its data i.e. how much ether it has, its members or whatever...) is not stored in a single place and is not subject to a central authority changing it at will.
Because an application is the sum of its parts, and in a DAPPS case the parts are contracts, this means that the DAPP is also decentralized (i.e. not subject to a central authority).
However, after trying a bit of implementation, I quickly ran into some issues which basically boil down to: If I have deployed some smart contracts to the network the question becomes (especially in light of the recent DAO hack where there were several people other than the actual hacker who were aware of potential issues), how can I update contracts (for bug fixes or enhancements)?
To be a little more specific, to me it seems that there are basically two different classes of contracts:
- Contract singletons, these would be librarys or factories.
- Contracts which have been produced by factories.
An example would be a futures exchange where (in a very simplistic case, I know), the exchange would be the singleton factory and it would be producing futures contracts which are of type 2.
That said, the question becomes: How does this futures exchange upgrade its software to a new non backward compatible version given that at any time there will be various futures contracts floating around that will expect the futures exchange contract singleton to have a certain API (that corresponds to the previous version). In another case, if a critical security flaw is discovered in the generated futures contracts, how does this exchange introduce a patch to all the futures contracts (of type 2) already in existence?
After reading up (and thinking through it a bunch - still without a very clear detailed picture of how this could be done), it seems this might become complicated. However, one thing is clear, in order to do this in a safe way (without some community voting that might waste critical time), the exchange must come up with some contract scheme (using some contract name registry etc.) where it retains the ability to modify the API's and state of all contracts that it has created (the contract's state may have to be altered in order to enhance or fix a bug in the contract, is this avoidable not sure?). It might do this by introducing some library with a constantly evolving upgrade function that upgrades contracts or something (I don't know - I don't have enough experience with ethereum to clearly think this through).
Still, this leads to my question: If the exchange (or in general a DAPP's development team) must keep all contracts under their central control (so that they can modify their functionality or state), then what exactly is decentralized? If this development team were ever hacked (i.e. their private address stolen or something) the system would be just as vulnerable as regular web application? So what exactly is decentralized in the DAPP other than the actual running of it (i.e. being run on several nodes) which is just a technical difference (no different from running a traditional web server in AWS really...)
Thanks in advance, looking forward to being corrected heavily =).
Edit: I guess one could make the argument that contracts' states could never change (which is the equivalent of freezing an application's data-model, or at least parts of it, I think). Even if that was accomplished, the actual methods of all the contracts would be centralized which are modifying the contracts' state...
Edit2: Perhaps one could always follow a pattern where any contracts of type 2 (i.e. generated contracts) would not be under anyone's control (for patches, fixes etc.). In that case the contract should never assume anything about another contract's API (because that might change at any time). Not sure what could be done about security flaws in the contract itself though...