Categories
- 17.3K All Categories
- 9.5K Mining
- 574 Pool Discussion
- 378 Promotional
- 1.4K General Project Discussion (non-technical)
- 485 Education
- 811 Protocol and Client discussion
- 170 web3-js
- 29 Whisper
- 16 Swarm
- 3 RLP
- 303 IoT & Hardware
- 1.2K Smart Contracts and Dapps
- 28 Serpent
- 359 Solidity
- 664 Projects
- 1.2K Reference clients code and builds
- 249 Eth & AlethZero- Cpp Implementation
- 471 Geth - Go Implementation
- 242 Mist
- 15 Node.js Implementation
- 36 Python Implementation
- 49 Mix
- 36 Other Implementations
- 170 Meetups
- 40 Other Events
- 226 Jobs & Skills
- 281 Press and Articles
- 75 Audio/Video
- 296 Ether Sale
- 1.2K Other Languages
- 96 Chinese
- 255 German
- 33 Italian
- 111 French
- 3 Hebrew
- 42 Japanese
- 75 Portugese
- 46 Romanian
- 185 Russian
- 231 Spanish
- 47 Turkish
- 125 Watercooler
How can you modify a contract after its creation?
Hello,
I read "How to make a contract updatable" post but my question is less technical and more general. I hired coders to work on my project and as a non coder I am trying to come up with the system architecture of how my DAO will actually work. I apologize in advance if I am posting in the wrong area or my prerequisite reading is missing a great deal. As an eager enthusiast I am trying to read as much as I can as quickly as I can
or if this question has already been answered somewhere else please correct me / direct me to some links.
My logic tells me that a contract cannot be modified by its creator after it is created without the risk that a malicious creator could disadvantage the principle participants. How can you be sure that the modifications are provably fair and more beneficial to the participants? If you can't modify a contract after its created how could you fix bugs or mistakes in the contract code?
I would like to create a DAO and this DAO will create a pool of insurance funds. My concept is that there will be the need of several different modules in order to collect premiums and pay out claims. Perhaps any of these modules might need to be tweaked or fixed to improve their function.
My current plan is to create a core contract which appears in the app store that has very few lines of code and is coded as carefully as possible but which calls and relys on other sub contract modules. This is the contract that would hold all the premiums and from which claims would be paid as well as holding the database of participants thus modifying its code after people have started using the DAO / DAPP would be avoided if at all possible. But the subcontract modules which perform various tasks from solving shelling point problems to holding the logic for how claims are paid out I could modify because those contracts are not directly connected to the principle participants.
Perhaps this core contract would allow people to vote upon their participation in a 2.0 upgrade at a future date which would facilitate the migration of participants to a new contract platform. But even if this would facilitate transferring over members individual accounts once premiums are paid they belong to the system not to individual members so if you transfer accounts to an upgraded contract that doesn't contain any premiums you wouldn't be able to successfully pay out claims unless your original contract contained instructions to transfer funds to a future 2.0 upgrade. But if you want to participate in the 1.0 app and see a line of code that will facilitate a future transfer of paid principle funds to a future 2.0 app that hasn't been written yet how can you know for certain the 2.0 upgrade isn't a scam?
Even if I have the freedom to manipulate the sub module contracts that are called upon by the main contract how can people know that these modifications also are provably fair? The contract modules used by the core contract would almost certainly need to be modified many times in an attempt to get everything to function correctly and to provide improved features. But this to me seems to open up doors for malicious entities to do malicious things which is why I am wondering how this can work.
What is the way it really works? What is the proper balance between fixed contract code and malleable contract code? What am I missing? Also I take this project very seriously so although I am working with a team of 2 other individuals to try and get it coded by Feb (we are still learning Python and haven't even started on Serpent yet) I realize almost immediately that even after taking our best stab at this we should seek out members of the Ethereum team for consultant support to make sure we are presenting something to the community which is fair, reliable, and helpful.
So although my question is primarily "how can I code something that can be changed in a provably fair way after people have paid into a contract" a larger question is what is the roadmap for developers who are serious about using this new technology so that they can make sure what they present to users is truly a quality product.
Again I really apologize I am incredibly enthusiastic and I am trying my best to read as much as I can as quickly as I can. haven't spent adequate time before writing this post to really research the forums/documentation as I'm sure this question is answered somewhere.
Joshua
I read "How to make a contract updatable" post but my question is less technical and more general. I hired coders to work on my project and as a non coder I am trying to come up with the system architecture of how my DAO will actually work. I apologize in advance if I am posting in the wrong area or my prerequisite reading is missing a great deal. As an eager enthusiast I am trying to read as much as I can as quickly as I can
or if this question has already been answered somewhere else please correct me / direct me to some links. My logic tells me that a contract cannot be modified by its creator after it is created without the risk that a malicious creator could disadvantage the principle participants. How can you be sure that the modifications are provably fair and more beneficial to the participants? If you can't modify a contract after its created how could you fix bugs or mistakes in the contract code?
I would like to create a DAO and this DAO will create a pool of insurance funds. My concept is that there will be the need of several different modules in order to collect premiums and pay out claims. Perhaps any of these modules might need to be tweaked or fixed to improve their function.
My current plan is to create a core contract which appears in the app store that has very few lines of code and is coded as carefully as possible but which calls and relys on other sub contract modules. This is the contract that would hold all the premiums and from which claims would be paid as well as holding the database of participants thus modifying its code after people have started using the DAO / DAPP would be avoided if at all possible. But the subcontract modules which perform various tasks from solving shelling point problems to holding the logic for how claims are paid out I could modify because those contracts are not directly connected to the principle participants.
Perhaps this core contract would allow people to vote upon their participation in a 2.0 upgrade at a future date which would facilitate the migration of participants to a new contract platform. But even if this would facilitate transferring over members individual accounts once premiums are paid they belong to the system not to individual members so if you transfer accounts to an upgraded contract that doesn't contain any premiums you wouldn't be able to successfully pay out claims unless your original contract contained instructions to transfer funds to a future 2.0 upgrade. But if you want to participate in the 1.0 app and see a line of code that will facilitate a future transfer of paid principle funds to a future 2.0 app that hasn't been written yet how can you know for certain the 2.0 upgrade isn't a scam?
Even if I have the freedom to manipulate the sub module contracts that are called upon by the main contract how can people know that these modifications also are provably fair? The contract modules used by the core contract would almost certainly need to be modified many times in an attempt to get everything to function correctly and to provide improved features. But this to me seems to open up doors for malicious entities to do malicious things which is why I am wondering how this can work.
What is the way it really works? What is the proper balance between fixed contract code and malleable contract code? What am I missing? Also I take this project very seriously so although I am working with a team of 2 other individuals to try and get it coded by Feb (we are still learning Python and haven't even started on Serpent yet) I realize almost immediately that even after taking our best stab at this we should seek out members of the Ethereum team for consultant support to make sure we are presenting something to the community which is fair, reliable, and helpful.
So although my question is primarily "how can I code something that can be changed in a provably fair way after people have paid into a contract" a larger question is what is the roadmap for developers who are serious about using this new technology so that they can make sure what they present to users is truly a quality product.
Again I really apologize I am incredibly enthusiastic and I am trying my best to read as much as I can as quickly as I can. haven't spent adequate time before writing this post to really research the forums/documentation as I'm sure this question is answered somewhere.
Joshua
Comments
http://fermi.vc/post/94090812974/ethereum-dao-code-markup
There are two levels to the DAO code. The immutable code is the contract itself: this is what you see marked up below. The contract also contains mutable code, which is what the DAO does (stored in contract.storage). This code executes when interacted with and, here’s the key thing, can be changed by voting from the members of the DAO. Think of the immutable code as the structure of our government (how judicial, legislative, and executive branches work together) and the mutable code as our laws (what our government actually does, which changes over time as laws change).
This makes a lot of sense actually and I can see how it would be possible to write the logic to reach consensus regarding changes and upgrades.
DOUG is the first systematic approach to organizing it. Basically each contract is actually a cluster of contracts and you refer to each other via a central contract that identifies each by name. So what the name refers to can be changed. Project Douglas' Eris, and Andreas Olofssons variously named variants followed.
The requirement for changing the reference can be arbitrary code. The current approach to have those changes not be malignant is basically that the parties basically vote on changes.(Eris has a whole forum system to help discuss it, decentralized on magnet links) If a change can affect a lot, you'd have to really up the ante for the amount of people that have to agree. (If that makes things too hard to change, delegative voting might be a possible, or 'absentees count less') "The parties" are also a thing the contracts have to determine.(in principle it could also depend on the decision being made)
But this doesn't seem to work for contracts holding substantial funds such as a large pool of insurance premiums. Wouldn't you need to do voting within a contract in order to migrate a pool of insurance premiums to a 2.0 contract upgrade? Same thing if a contract is holding onto some important data/database that needs to be migrated.
I can see how it would be done in principle. I know many of these things are new but in the coming months I hope peoples hunger to understand this technology will start to lead to an aggregation of information around specific topics and best practices.
To create an insurance DAO there are several challenges and I am starting to see that many of them are caused by a misunderstanding or misinterpretation of how the blockchain technology is actually applied.
I could also potentially see how someone might understand certain principles and then foolishly create a Dapp that costs ridiculous amount of gas because you are trying to use the blockchain to perform too much work. Seems like only those who regularly are writing and running contracts would have the discernment to know that certain parts of the program would be better of running off blockchain on a server system that could be publicly audited.
What options are there for running some code off blockchain to save on gas costs in a way that might still be provably fair? What type of interfaces does the EVM have to mitigate high gas costs?
I apologize for asking so many unrelated questions. I am certain there is probably a primer out there that I just haven't read (I read the white paper but it speaks about things in a general way).
Note that i used the word 'vote' but as i said, the cause for a contract to do something can be some arbitrary code.
Hanging blocks are a method of basically making 'auditable blocks'. In short you can get statements out from the hanging blocks to interact in ethereum, and getting the statements relating to before and after some incorrect execution of code can be used to show to the contract that it executed incorrectly.(that can also interact with the contract state) Its main weakness is that simply not sharing the data, you can do arbitrary incorrect stuff, a defence is to simply vote on the availability of the block.(and have people able to replace the role of block creator)
Seems like one way to deal with the issue is to specify from which jurisdiction's funds will be accepted and where they will reside. I realize that's a limitation on the potential of the technology but insurance is a heavily regulated industry like banking and it's gotta be addressed. Another way entirely is to ask whether this is "insurance" and the funds are "premium." If they are, they are -- if it walks like a duck and talks like a duck, it's probably a duck. If it's not insurance, however, calling it that raises questions that maybe aren't necessary to answer. It sounds like insurance to me, but . . .
Of course a DAO isnt an organization to these regulations, i suppose the idea of a more traditional organization that bridges to the DAO is an idea here. They would have people responsible for it on the traditional end of the bridge, but it cant be DAO if the traditional controls every aspect of it. Lets say it goes wrong, a lot of the assets are out of reach.
What about the argument that Ethereum is just the 'machinery' the software runs on? I am sure that people go like 'matter-a-fact' .. it puts it out of reach.
On the other hand in some ways the DAO could be easier to regulate, because the rules of the organization are all in the open. Even individual dealings might be, or they might possibly be "provably exposable" if needed. (not entirely sure how, but maybe something like proof of reserve)
One would distinguish between Ethereum and the "contracts" that run on it, correct? I'm actually not thinking about regulation of Ethereum qua Ethereum. in this particular use case. Ethereum might indeed be like machinery that transmits or computes -- and like a phone company or cloud server not usually liable for transmission or computation that takes place on it. Just because an insurance company uses phones or a remote server, doesn't mean that the telco or server provider are insurance companies. So too, here?
Separate (?) question is how the transactions themselves are treated by the law. And maybe from a regulatory standpoint a DAO would be an improvement -- in the US, insurers have to provide information about statutory reserves (and other data) to regulators and to rating agencies. And claim handling information is also published, sort of. The organizations are often closely tied to the insurers and also have close relationships. (As a guy from an investment bank that will remain nameless once told me -- "the deal will get an investment grade rating; I summer at the Hamptons [a fancy resort area in New York] with the guy from" the rating agency. I can see regulators liking the transparency perhaps; consumers would definitely benefit. Proof of reserve and reputation would be lovely additions to insurance.
I'm not sure what the answer is to defining a jurisdictional nexus. My gut tells me that if you call something an insurance contract, some insurance commissioner somewhere will be interested. Not an insoluble problem or unanswerable question, and definitely interesting!