Implement basic delegate() function

[medied]

This feature can take from PR #7. Implementation must come with its respective tests in the corresponding test file

[aecc]

I'll be writing here some possible requirements for delegation:

A. Glossary:

1. Delegation: one voter giving its voting power to another voter
2. Representative: receiving part of a delegation (Representee ---> Representative)
3. Representee: giving part of a delegation (Representee ---> Representative)

B. Initial assumptions:

1. Every voter has a single unit of voting power, it can delegate it to another voter, or keep it
2. Delegations are publicly visible for any voter
3. No GAS optimizations are done, however it should be stated every time a decision of arguably big GAS consumption is made
4. Cycles-capability is not possible

C. Functional Requirements:

1. Only registered voters can delegate
2. Every registered voter can receive delegations
3. For simplicity, every voter has a delegation
4. For simplicity, initially, a voter delegates to itself (a loop is made)
5. A voter delegates exactly 1 vote of its own.
6. A voter can receive delegation from [1 to n] voters. n has no upper bound
7. A voter can transitively delegate x votes from representees.

D. Non-functional requirements:

1. It's necessary to be able to fetch the status of all the delegations (voting power of every voter) just by reading the blockchain (no transaction should be made to compute the whole delegation)
2. Every time a delegation is changed, a transaction should be made to the blockchain and all the delegations should be recomputed (this is probably very expensive, and unfair as it will be more costly for delegations made later than others)

[aecc]

@medied let's discuss things here that could be changed/improved from the proposed requirements, and after we agree on each point I'll make changes to the original requirements

[medied]

Looks good @aecc, glad we went over it. I went ahead and created a similar spec the same for #11

[aecc]

@medied I just added B.4 . Something that will not be implemented in this PR. I managed to make cycles work on the previous implementation of Delegation.sol . I'll create it on another issue to encourage the resolution of smaller tasks/issues

[virgile-dev]

Hey guys, @medied @aecc

Just read this from Alessandro's post.

Every time a delegation is changed, a transaction should be made to the blockchain and all the delegations should be recomputed (this is probably very expensive, and unfair as it will be more costly for delegations made later than others)

I was wondering if this wasn't the right time to start thinking of what happens on chain vs off chain. Here is a few thoughts I had written down, (Santi went over it).

---

The client will interact with a smart contract library that will move around the vote token and settle transaction in the blockchain. We want things to move fast even if operating with a blockchain. For that we should consider what happens off-chain and on-chain.

• Off-chain:
  • Delegations
    • Need to operate strictly under a logic of Quadratic Voting to prevent formation of monopolies that can disincentivize participation. This means that when an identity delegates tokens to another identity, the cost becomes exponentially more expensive. Alice can delegate Bob strictly 1, 2, 4, 8, 16...N tokens and no value in between.
    • When you think about them delegation are almost like payment channel in the lightning network. They require trust between parties, some degree of anonymity etc.
  • Ballot creation
  • Hashtag creation (can be flushed on-chain once attached to a ballot that received votes)
• On-chain:
  • Voting
    • A vote has to be connected to an identity in the system. Either integrating with Blockstack IDs or uPort IDs on Ethereum is critical in order to make the transaction politically accountable.
    • Votes are always-on and real-time, attached to an address that's connected to a proposal or idea in the system. As long as votes remain in that address they will be tallied accordingly.
  • Revoke
    • Any user has the right to revoke votes given to other delegates or proposal having sovereign control of them.
  • Organization / districts creation

[medied]

Thanks @virgile-dev. This is relevant to #16 which will be part of our next v0.1.1 milestone. We need to sync and talk about what goes in the next milestone, let's start in the sprint sync today.

[aecc]

@virgile-dev @medied while I agree with separating responsibilities in off-chain / on-chain categories, I think we are still quite far from it. We should aim at the moment for a 100% working product on-chain. Off-chain development adds other levels of complexity, for starters there is no standard SDKs or programming languages for off-chain solutions. We need to strongly familiarize ourselves with the technology before we can start building something off-chain.