You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The upgrade mechanism implemented in DAO 1.0 is slow and requires the user to swap their tokens with the new DAO tokens. There is also a lot of information that still is the parent DAO like RewardTokens, or old proposal info.
Even that most of this info can be queried by the new DAO, it makes the upgrade process slow, difficult and can not be done while proposals are in progress.
The idea behind this is that there are 2 contracts one for the data storage and another for the code.
The data contract remains always the same. (It is possible to add more data at the end of the contract). But the code can be upgrades with a single call.
This upgrade can be don via a proposal.
I propose also that during the first versions of the DAO, the curators can upgrade this code in a delayed manner. That is: they announce an upgrade, and after 2 weeks, the upgrade is done. In the while, DTH can split if they don't trust curators.
When the DAO code gets more mature, this functionality can be hardened or even removed.
The text was updated successfully, but these errors were encountered:
I like this design. Combine that with an inherent blockchain filtering contract: put the code on the P.O.S. nodes and the data storage on the P.O.W. nodes (peg the gas between them).
Changelog
2016-06-14 DIR created
Problem Definition
The upgrade mechanism implemented in DAO 1.0 is slow and requires the user to swap their tokens with the new DAO tokens. There is also a lot of information that still is the parent DAO like RewardTokens, or old proposal info.
Even that most of this info can be queried by the new DAO, it makes the upgrade process slow, difficult and can not be done while proposals are in progress.
Proposed Solution
The proposed solution is to use the pattern described here:
https://gist.github.com/Arachnid/4ca9da48d51e23e5cfe0f0e14dd6318f
The idea behind this is that there are 2 contracts one for the data storage and another for the code.
The data contract remains always the same. (It is possible to add more data at the end of the contract). But the code can be upgrades with a single call.
This upgrade can be don via a proposal.
I propose also that during the first versions of the DAO, the curators can upgrade this code in a delayed manner. That is: they announce an upgrade, and after 2 weeks, the upgrade is done. In the while, DTH can split if they don't trust curators.
When the DAO code gets more mature, this functionality can be hardened or even removed.
The text was updated successfully, but these errors were encountered: