Vote on contract upgrades #2

New Issue

2018-03-12T18:57:40Z

bumi commented

2018-03-12 18:57:40 +00:00

(Migrated from github.com)

Upgrading tokens is a security risk and requires trust to whoever is able to upgrade to a new version.
We need to define a process on how to upgrade to new releases and implement the specific access controls.

Who should be able to upgrade contracts to a new version?
Will the be some voting required? Should it be some multisig transaction?

Upgrading tokens is a security risk and requires trust to whoever is able to upgrade to a new version. We need to define a process on how to upgrade to new releases and implement the specific access controls. Who should be able to upgrade contracts to a new version? Will the be some voting required? Should it be some multisig transaction?

fsmanuel commented

2018-03-22 01:26:35 +00:00

(Migrated from github.com)

I'm in for a voting! Is the proposal part also a voting? If so what would be the difference? Is it possible to abstract it to have something like a Votable concern? I think we need something like a votable_target a condition who can vote, what is the final state and what should happen if the final state is reached.

Off topic question: Is every call to the contract a transaction that needs gas?

I'm in for a voting! Is the proposal part also a voting? If so what would be the difference? Is it possible to abstract it to have something like a `Votable` concern? I think we need something like a `votable_target` a condition who can vote, what is the final state and what should happen if the final state is reached. Off topic question: Is every call to the contract a transaction that needs gas?

bumi commented

2018-03-22 08:26:35 +00:00

(Migrated from github.com)

Every call to a contract that changes the state is a transaction and costs gas.
Reading data from a contract is free - as it is just accessing the local DB from the connected node.

Voting would for sure be the best. I think the general logic what will be executed is different though. For proposals new tokens will be issued for upgrading the contract some different attribute must be set.
The Votable is a good idea. Maybe we can try that every proposal is its own small contract that implements that logic - need to see how much that would be.
I'd focus on the proposals first though.

Every call to a contract that changes the state is a transaction and costs gas. Reading data from a contract is free - as it is just accessing the local DB from the connected node. Voting would for sure be the best. I think the general logic what will be executed is different though. For proposals new tokens will be issued for upgrading the contract some different attribute must be set. The `Votable` is a good idea. Maybe we can try that every proposal is its own small contract that implements that logic - need to see how much that would be. I'd focus on the proposals first though.

bumi commented

2019-03-31 14:02:19 +00:00

(Migrated from github.com)

doable with aragon (#62 )

raucao commented

2019-04-01 07:53:22 +00:00

(Migrated from github.com)

Even though it's doable with that, this issue is still valid, no? Or do we already have contract upgrade voting implemented in #62?

bumi commented

2019-04-01 08:36:34 +00:00

(Migrated from github.com)

yeah probably you're right.
right now some access role is defined. The deploy account gets that role and we would need to give that one to a voting app. And actually I think we could even use the aragon voting app for that.
Though all this is theory and I have not tested it.

yeah probably you're right. right now some access role is defined. The deploy account gets that role and we would need to give that one to a voting app. And actually I think we could even use the aragon voting app for that. Though all this is theory and I have not tested it.

bumi commented

2019-04-01 08:42:15 +00:00

(Migrated from github.com)

but for the launch I think that is enough?

raucao commented

2019-04-01 08:43:10 +00:00

(Migrated from github.com)

Yes, of course. Just making sure we keep issues open for the things we plan to implement in the future.

👍 1

bumi commented

2019-04-01 08:48:38 +00:00

(Migrated from github.com)