How are contract upgrades performed? about moloch HOT 7 CLOSED

I guess ideally the new contract would have a way to bypass the proposal process, if that is your recommended upgrade process :) otherwise with 50+ members, the order of operations for adding everyone back seems like a complicated coordination problem ☺️

from moloch.

@stellarmagnet: Well, with the current parameters (1-week voting period, 1-week grace period before processing, up to 5 proposals per day), the summoner could actually vote in up to 70 members before the first proposal gets processed.
Of course, that would require considerable liquidity for the deposits, and the summoner would still have to communicate with each of the migrants, but at least, up to that point, the coordination effort would be linear (summoner to each), not quadratic (each to each).

So, I guess @ameensol could summon a new Moloch and just ragevote everybody in. ;)
If he can't be bothered, then we need to devise a more automated strategy. :)

As a side note, the ability to ragequit is the central protection mechanism in Moloch,
and there could be situations where a lot of members would want to quit and move on
to a new Moloch in a non-automated way, i.e. through the regular voting process:
for example, a member acquired a 51% majority, or a few whales conspired,
or some would just not be happy about the direction the Moloch has taken (in terms of past voting results).
That would be a fork, though, not an upgrade, and I agree that it is desirable to have a more convenient upgrade path than by forking.

@adklempner: It seems simplicity and even minimalism were explicit design choices. To quote from section 3 of the whitepaper:

First and foremost, we set a goal of putting only the absolute minimum set of functionality
on-chain. In the vast majority of edge cases, social coordination mechanisms (offline coordination)
can be used as roundabout solutions to problems. By minimizing on-chain coordination, we
reduce the potential attack surface that we need to account for.

@alcuadrado: Beautiful idea!

from moloch.

There's no upgrade mechanism in the technical sense. Instead, everybody can ragequit with what's left of their tribute and move on to a new contract.

from moloch.

Not too mention a waste of gas. Was there any reason beyond time-constraints that a separate logic/data architecture wasn't used for the contracts, using something like AragonOS or ZeppelinOS? Security concerns? It seem like they are appropriate for this project; they also add the potential for members to vote on contract upgrades on-chain (or not participate in the process at all while still retaining their shares)

from moloch.

I guess ideally the new contract would have a way to bypass the proposal process, if that is your recommended upgrade process :) otherwise with 50+ members, the order of operations for adding everyone back seems like a complicated coordination problem ☺️

The new dao could have a function to let moloch members migrate to it.

It should work something like this:

• The member sets the new dao as their moloch's delegate key.
• The member gives the new dao enough weth allowance to move their part of the GuildBank's funds.
• The member calls the migration function.
• This function gets the number of shares of the member and ragequits all of them.
• Finally, the function calls weth's transferFrom to recover the funds, and mints new shares.

from moloch.

with the current parameters (1-week voting period, 1-week grace period before processing, up to 5 proposals per day), the summoner could actually vote in up to 70 members before the first proposal gets processed.

Actually, the summoner could vote for 70 new members (at least), before the first proposal gets processed, but only the first 36 would undoubtedly be in.

from moloch.

We're about to find out...

from moloch.