search

CORIONplatform / solidity

GNU General Public License v3.0
12 stars 9 forks source link

Proposal. CORION owners system. #53

Open Dexaran opened 7 years ago

Dexaran commented 7 years ago

Abstract.

The CORION development team states that there should be no manual control mechanism in CORION system. At the other hand, the manual control mechanism is a required tool for debugging contracts, if any error occurs. I want to suggest a compromise solution.

Specification.

There are owners in moduleHandler contract. owners are addresses that can propose newAnnouncements, that are used to make any changes to CORION system. One owner is enough to make a newAnnouncement. If the announcement will not be opposited by COR holders, then the proposed changes would be accepted. There are also debugging functions. If 75% of the owners come to the conclusion that certain changes are needed, they can perform the call of the emergency debugging function without the newAnnouncement.

The problem.

owners are mostly members of CORION team and developers at initial stages. COR holders are community members. It seems that giving owners more facilities to perform debugging functions will violate principles of decentralization and censorship-resistance. It seems that giving owners less facilities to perform debugging functions will make the system less fault-tolerant, because in case of emergency error fixing, these functions are required.

Suggestion.

Introduce a mechanism for selecting the desired owners by the community voting. If a significant part of the community does not agree with the CORION team's visions, they will be allowed to choose the community-delegated owner, which can createnewAnnouncement. Even one owner, delegated by the community, is enough to create newAnnouncement proposals that will be voted by community members.

Resolution.

  1. Implement publicAddOwner(address) function. If function caller owns a significant part of COR tokens (75% of COR total supply in my example) then he can elect a new owner.

  2. Remove hardcoded debugging auto disable since debugging disabling will be no longer required.

  3. Make _addOwner internal instead of private. This change is required because of moduleHandler should now call this function.

If only owner of 75% of total COR can elect a new moduleHandler owner, then it should be a contract that can store COR, not an address (It is highly undesirable for one person to own 75% of the token). This Vote Pool contract can be used for the described purpose.

nagydani commented 7 years ago

I disagree with this proposal to become effective immediately, precisely due to the reason you usually cite: security-critical components must not have external dependencies. This proposal critically depends on COR accounting. If COR accounting is somehow compromised, this mechanism is also compromised and quite possibly cannot be invoked to fix the problem. Thus, I believe that this mechanism must not be enabled in the beginning, until sufficient confidence is gained about COR accounting. Only after that can COR voting be used for adding owners (point 1). As for point 2, I also disagree. Debugging (i.e. direct immediately effective rule changes) should become impossible even with a large COR stash.