The next version of chief

[jparklev]

FOR DISCUSSION ONLY - DO NOT MERGE

The PR against ds-chief is a little clumsy since it’s a totally different contract, but if we want to make a new repo, I’m happy to push it there

Based on this gist

Thoughts?

[asymmetric]

This branch has not been deployed

Is GitHub gonna deploy the smart contract for us now?

[MrChico]

@jparklev Seems like there is no way to vote for multiple proposals right now? I would maybe change the logic of vote to be decomposed into vote and unvote by removing the clause in L79

[MrChico]

I also still feel like there should be timeout to locked balances so that people need to restate their positions for the status quo. Otherwise I think we're gonna see a huge bias for no change.

[gbalabasquer]

I also still feel like there should be timeout to locked balances so that people need to restate their positions for the status quo. Otherwise I think we're gonna see a huge bias for no change.

Agree on this. I think a technical solution would be saving the timestamp when locking and allowing that anyone can free your locked amount if the time is expired.

[jparklev]

Seems like there is no way to vote for multiple proposals right now? I would maybe change the logic of vote to be decomposed into vote and unvote by removing the clause in L79

@MrChico hmm do you think being able to vote for multiple proposals is an important ability? One consideration is that, b/c votes need to be subtracted from each of a voter's proposals when their tokens are withdrawn, we'd have to put some limit on the number of proposals that can be voted on at once. Does that sound right to you?

[MrChico]

Seems like there is no way to vote for multiple proposals right now? I would maybe change the logic of vote to be decomposed into vote and unvote by removing the clause in L79

@MrChico hmm do you think being able to vote for multiple proposals is an important ability? One consideration there is that we'd have to put some limit on the number of proposals that can be voted on since votes need to be subtracted from each of a voter's picks when any of their tokens are freed. Does that sound right to you?

I think the governance scheme of Maker has always been Approval voting where each voter may select ("approve") any number of candidates/proposals.

Maybe one do something like counting the number of proposals someone has selected. This would mean that we have to account for fired proposals as well. I'm thinking something along the lines of

mapping(address => uint256) public nProposalsSelected; 
mapping(mapping(address => bytes32) => bool) public votedFor;
function vote(bytes32 proposal) public {
        require(votedFor[msg.sender][proposal] == false);
        votes[proposal]   = add(votes[proposal], balances[msg.sender]);
        votedFor[msg.sender][proposal] = false;
        nProposalsSelected[msg.sender] += 1;
}
function unvote(bytes32 proposal) public {
        require(votedFor[msg.sender][proposal] == true);
        votes[proposal]   = sub(votes[proposal], balances[msg.sender]);
        votedFor[msg.sender][proposal] = true;
        nProposalsSelected[msg.sender] -= 1;
}
function free(uint256 wad) public note {
        require(nProposalsSelected[msg.sender] == 0);
        balances[msg.sender] = sub(balances[msg.sender], wad);
        require(gov.transferFrom(address(this), msg.sender, wad));
        locked = sub(locked, wad);
}

[d-xo]

@MrChico why is voting for multiple proposals useful? This ability is hidden in the UI rn cos it's considered too confusing.

[MrChico]

@xwvvvvwx I agree that it is confusing in the current implementation, but I think the concept is valuable; to be able to signal support for multiple proposals individually makes the system able to update multiple parameters in parallel. Without the ability to vote for multiple proposals, those updates would have to be baked together, and someone that doesn't approve proposal A will stall the approval of proposal (A & B), even though they might like B.

[asymmetric]

Without the ability to vote for multiple proposals, those updates would have to be baked together

Or there would have to be multiple votes.

This vould definitely reduce the velocity of governance, especially due to voter fatigue. But will that be a problem in practice? Also practically speaking, how confident are we that parallel voting is a good UX? (probably not at all, since it's hidden in the UI 😂)

Seems like a problem that could benefit from some user studies/more data.

[asymmetric]

A drawback with this design is that it removes the RBAC functionality from the Chief.

In MCD, we need to permit parts of the core to mint and burn MKR (for flops and flaps respectively), therefore we need to allow some contracts to call two specific methods on the token.

This seems like a pretty good match for the concepts of roles and capabilities in DSRoles, and we'd lose them in the new design.

Example:

With roles, we can (pseudocode):

• uint8 minter_role = 0xaa
• chief.setUserRole(address(vow), minter_role, true)
• chief.setRoleCapability(minter_role, address(gov), sig("mint"), true)

Which lets the Vow contract call gov.mint(), without interfering with the hat election process (as that's a separate root role).

[MrChico]

Without the ability to vote for multiple proposals, those updates would have to be baked together

Or there would have to be multiple votes.

Well, that would still change the behavior, since you would now need to split up your voting power between independent proposals. I don't think the fact that parallel voting is hidden in the current UI is an argument that it's bad UX.

Generally, I don't think that we should be limiting the capabilities of the system based on UX considerations. Parallel voting is a more natural fit since if there are proposals that essentially are independent from each other, which I definitely would argue is the case for MCD.

Wrt the UX considerations and voter fatigue I still think that votes should decay over time, to mitigate the bias for the status quo, and that we should look into secondary layers of delegation instead of thinking that everyone will vote on every proposal

[kmbarry1]

What's the status of this PR? Is there intent to merge or abandon? I'm looking at the overall Chief+MKR auth design, and any intention to replace the Chief in the near future has a big impact on that :).

[asymmetric]

@kmbarry1 have you seen https://github.com/makerdao/dss-deploy/issues/21 and https://github.com/makerdao/dss-deploy/issues/22?

What type of work are you doing around Chief+MKR auth?

EDIT: nvm, saw the discussion with David :)

Let’s move the convo to #21/#22 if you have any questions.