ALP04: Delegation Chains

[lkngtn]

Proposal: ALP04 Delegation Chains

Author(s): Luke Duncan

Last updated: Dec 5th 2017

Abstract

This proposal extends the functionality described in #3 to include delegation chains where Alice might delegate to Bob who might delegate to Carol. The purpose of allowing delegation chaining is to allow for bottom-up chains of trust.

Proposal

At a minimum a successful implementation would enable the following user stories.

• All user stories which are included in #3
• As a delegate, I want to be able to delegate my influence as well as the influence that has been delegated to me to another user.
• As a user, before I delegate I want to be able to know if the transaction will succeed prior to paying gas.

Rationale

Rather than a typical user having to make a decision between one of many expert delegates, they can simply delegate that choice to a friend who they have a high level of trust but who is more engaged in the project. This process helps mitigate issues where well know figures become super delegates simply because they have a high profile in the community. This also minimized the amount of effort and knowledge required of the average voter.

Open Issues

• To ensure a delegation is valid and does not create a loop, we have to process the delegation chain at the time of delegation. This means the cost to delegate may vary. We can limit the length of delegation chains in order to put a minimum and maximum on this cost.
• To minimize the cost to delegate, we can make the validation of chains happen client side, allowing users to make any delegation choice they want and do the tabulation and validation in batches at the end of a poll. To make tabulation less expensive, it may make sense to move this process “off-chain” with a solution like Truebit. This approach is discussed in #5 .

[medied]

To ensure a delegation is valid and does not create a loop, we have to process the delegation chain at the time of delegation. This means the cost to delegate may vary. We can limit the length of delegation chains in order to put a minimum and maximum on this cost.

One idea we could explore is quadratic voting on delegations, or quadratic delegations if you will. Idea being the cost of delegating is what increases quadratically per hop, not the number of votes. So there's an inverse relationship between the cost increasing and the number of votes decreasing, both quadratically. Translates more or less to 'the more I care about an issue, the less inclined I will be to delegate'. Creates a natural, mathematical constrain on the ability to delegate: for a said amount of votes, delegation chain will reach an end once the square root of votes per hop approaches 1.

Does that make sense? Gotta continue brainstorming this with someone else though, still lots of details untouched. Open questions: would the cost of delegating have a penalty increasing the gas used to transact instead of aiming to control flow of votes attached to identities? would that keep erc20 compatibility if we focus strictly on a transacting function? how to avoid circle delegations?

[lkngtn]

Idea being the cost of delegating is what increases quadratically per hop, not the number of votes

I think we should distinguish between the cost to delegate (e.g. gas) versus the potential modulation of magnitude of votes due to delegation. This cost would only be incurred when delegating or changing a delegate and must be paid to miners/validators.

That being said, personally I don't like the idea of discouraging long chains (beyond the the fact that long chains already cost more gas), if it weren't for the gas/computation overhead I would say that longer chains are better than short chains. In a long chain I might be delegating to someone close to me who I know very well and trust to have values that are aligned with my own, if Im incentivized to maintain a short chain I'm likely delegating to a popular outspoken community member who I don't know particularly.

I do like the idea of scaling voting power quadratically for popular delegates as a way to minimize the centralization effect of "super-delegates". The typical challenge with quadratic voting is the idea that without a sybil resistant identity mechanism, people will split their votes, but in the context of delegates that exactly the behavior we are looking for. 👍

[medied]

Interesting to think about the advantages and disadvantages of longer chains vs shorter chains. I do agree we should be aiming to have individuals delegate to people they know well and trust, rather than the outspoken community member (though there's nothing wrong with that if some trust is built with that member, specially if delegate can be revoked at will)

[knarz]

To ensure a delegation is valid and does not create a loop, we have to process the delegation chain at the time of delegation. This means the cost to delegate may vary. We can limit the length of delegation chains in order to put a minimum and maximum on this cost.

Which problem would preventing them solve exactly other than maybe accidental cycles, which should be easy to reverse anyway and probably cheaper than trying to check for cycles in the smart contract?

I would imagine that delegation chains don't end up being very long, although it'd be great if it were a diverse network instead of just some bright community stars, so the probability of ending up with cyles might be fairly small. A cycle could also point to a more general problem, where participants are either not sure who to trust with a decision—should a decision be made at that point?—or someone, who was able to gather trust from others acts maliciously and nullifies the ballots of their trusters, which they could've just done by not casting a ballot.

So, having cycles could be a feature and not a bug but I'm just sort of thinking out loud here.