8

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:

  1. Contract singletons, these would be librarys or factories.
  2. 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...

closed as too broad by Roland Kofler, eth Jun 21 '16 at 18:19

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I think what we have learned from this crisis is to decentralize only the necessary and not creating overly complicated contracts. Then decentralization is possible. – Roland Kofler Jun 21 '16 at 15:08
  • @RolandKofler Hmmm, I am not following. It seems to me that no contracts can be decentralized because the only way to truly decentralize is to have the development team lose control over the contract which essentially freezes the development of the Dapp. – pQuestions123 Jun 21 '16 at 15:22
  • Striktly speaking the two things are completely independent. You can use a contract as long as you like. Or use another one that is a newer version of it. The only prerequisite is that Users task is complete at one point in time. Shall we call it Usage Finality? – Roland Kofler Jun 21 '16 at 15:29
  • Task Finality and only because vbuterin seems to like the word finality – Roland Kofler Jun 21 '16 at 15:32
  • @RolandKofler That would be true if contracts never interacted with one another but they do. If you are changing some contracts in your system but not changing others that interact with them, you will eventually run into problems. Also, what would you do in that case about a contract floating around which has a critical security flaw? – pQuestions123 Jun 21 '16 at 15:32
4

"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."

  1. I agree it is complicated but backward compatible code changes are required

"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?).

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?"

  1. I disagree this is the best solution. If decentralization is of critical importance (which I suspect most Ethereum and DAPP users will agree) then central control of contracts is not acceptable. Backwards compatible solutions (no matter how difficult) are required as is "community voting" by miners for all forking decisions.
  • Well yes, of course you need the miners' votes for forking the actual blockchain. However, I am talking about changing the operation mode of the contracts themselves (i.e. upgrading software). If community voting is added to this, then critical security fixes or doing pretty much anything becomes extremely difficult. Not to mention having to actually implement a robust voting system (for every single DAPP) which is not a trivial task at all. – pQuestions123 Jun 21 '16 at 15:27

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