(D)PoS-Hybrid Voting System

#1

LIP:
Title: (D)PoS-Hybrid Voting system.
Author: cc001 <cc001.bct at gmail.com <mailto:cc001.bct at gmail.com>>, 5an1ty
<5an1tycryptodev at gmail.com <mailto:5an1tycryptodev at gmail.com>>
Type: Standards Track
Module: DPoS
Created: 2019-03-05
Updated: 2019-03-05

Abstract

This LIP proposes a change of the voting system to a kind of a hybrid
between POS and DPOS systems. The major changes are:

  • Everybody who locks a minimal deposit and registers a delegate will be
    able to forge more or less often. There is no limit of the top 101 anymore.
  • The staked deposit of the delegates can be slashed (penalized) if the
    delegate misses multiple blocks in a row, double-forges, or misbehaves
    in other ways.
  • Every round 101 delegates are chosen from the pool of eligible
    delegates to forge blocks. The probability to be chosen depends on the
    staked amount of the delegate, the received voting weight and the
    delegates productivity. Compared to the current system where the top 101
    delegates forge all blocks, in the new system all delegates can forge,
    but depending on their weight, they forge more or less often, maybe only
    once every 100th round.
  • Delegate accounts can’t vote. They basically automatically vote for
    themselves.
  • Voters stake specific amounts to specific delegates. If the specific
    delegate misbehaves, this voting stake can also be slashed.
  • Voters are now also part of the consensus and get parts of the forging
    rewards.
  • Slashed amounts (from delegates and from voters) are burned.

Credits for this proposal also go to delegate 5an1ty.

Copyright

This LIP is licensed under the GNU General Public License, version
3
.

Motivation

In the current voting system in Lisk, every account holder can vote for
up to 101 delegates and the vote weight of the account is the balance of
the account, also referred to as the stake of the account holder. The
current voting system is based on approval
voting
and the idea is
that the delegates approved by the highest proportion of stake are the
most suitable to secure the Lisk network. In practice, this system
suffers from several shortcomings, which also have been addressed by
members of the Lisk community. There is a high incentive for voters to
vote for the current top 101 delegates because of the received rewards.
This creates a very high barrier for anybody to become an active
delegate (called “the 101 cliff”) which hinders a healthy competition
for active delegate slots.

The proposed new voting system has following properties and effects:
It is much more decentralized because everybody who wants to (and is
willing to risk their stake) is able to forge, even if he does not
receive any vote at all. Of course, delegates who receive many votes can
forge more often than delegates who receive less votes. This is a
significant change to the current system, where delegates depend on the
will of the voters to be able to forge. Additionally, voters are also
part of the consensus system by staking their balances to the delegates,
for which they receive a part of the block rewards.

A delegate must keep a minimum amount in his delegate account to be able
to forge. I would suggest this MinStakeNeeded = 100*BlockReward.
Currently this would be 300 LSK, after the next block reduction it would
be 200 LSK. If the balance in the delegates account falls below this
limit, the delegate is automatically excluded from forging.

Voters stake for specific delegates and their staked amount will also be
slashed by 1% (exact numbers to be defined) if “their” delegate
misbehaves. This incentivizes voters to vote for “good” delegates,
because voters lose money if they vote for misbehaving or low-productive
delegates.

Delegates put their balance at stake and parts of it can be slashed if
the delegate misbehaves. I would propose something like this:

  • Missing 50 blocks in a row, will remove 10% of the staked amount in a
    delegates account.
  • Double forging will also remove 10% of the stake.
    This slashing mechanism incentivizes delegates to not misbehave because
    it costs them a significant amount of money and they risk to stop
    forging. It also removes misbehaving delegates automatically from
    forging if their account balance falls below MinStakeNeeded.

Every round, 101 delegates are chosen from the pool of eligible
delegates. An eligible delegate is one that has at least MinStakeNeeded
in his delegate account. The probability of being chosen for the current
forging round depends on the staked amount of the delegate, the received
voting weight and the productivity of the delegate and how many other
eligible delegates exist and what their forging probability is. Exact
numbers to be definined, I would propose something like this:
CurrentApproval = X*StakedAmount + (1-X)*ReceivedVotingWeight
FinalForgingWeight = CurrentApproval * Productivity.
ProbabilityToBeChosenFor101 =
FinalForgingWeight/SumOfAllForgingWeightsOfAllEligibleDelegates.
X needs to be defined, I would propose for X something between 0.7 and
0.9. This means that voting weight is lower rated than the own stake.
The reason for this is that it reduces to incentive to bribe delegates
because a delegate can forge even if he receives no weight at all and
the received weight doesn’t count so much. On the other side, this
mechanism allows also delegates who don’t own a lot of own stake to
forge significantly often, by receiving a lot of votes because they
offer high quality and productivity.
Productivity might also be modified a little bit, to have a bigger
influence between delegates. Almost all current delegates have a
productivity higher than 99%, this means that it doesn’t make a lot of
difference between delegates. A way could be to scale it to something
between 90 and 100.
Because the productivity directly influences the probability to forge
and therefore the income of the delegate, the delegate has high
incentive to reach high productivity. Additionally, voters have
incentive to vote for delegates with high productivity, because they get
parts of the block rewards, forged by the delegate they put their stake on.

Voters stake (or vote) with a specific amount of their LSK holdings for
specific delegates. This means, a delegate with 5000 LSK can decide:
1000 to delegate1, 1000 to delegate2, 500 to delegate3, and 100 to 25
other delegates of his choice.
Voters can stake as many delegates as they want. Of course in total only
their complete account balance can be staked.
The stake voters put on delegates can also be slashed. It will be
slashed at the same situations where also the staked delegate get
slashed (missing multiple blocks, double forging), but only with 1%
(exact numbers to be defined) of the staked amount. This means, if a
voter stakes 1000 LSK for a delegate (with 100000 LSK staked in his
account) who misses 50 blocks in a row, the delegate will lose 10000 LSK
(10%) of his stake, and the voter will lose 10 LSK. This incentivizes
voters to not vote for delegates who only promise high rewards, but vote
for delegates who offer good quality and don’t get slashed. Because the
delegates productivity directly influences the income of the delegate
and his voters, delegates and voter have incentive to offer or vote for
high productivity.

Because voters are part of the consensus protocol, they are
automatically rewarded for voting. They receive a part of the forging
rewards of the delegates they are staking. I would suggest that they
receive something between 10-30%. Delegates might offer additional
rewards on top of that for their voters, but I think this will be very
limited, because voting weight does not have so much influence in the
forging probability like it is the case with the current system.

My suggestion is that slashed amounts are burned. Other ideas are
welcome. Burning these amounts would also reduce the supply and help the
price on exchanges.

Here are a few examples how delegates with different stakes, voting
weights and productivity would be able to forge. Lets assume X = 0.8

  1. the rich guy put all his 500000 LSK at stake to forge with it.
    Because he does not care about the community, he gets only 10000 LSK
    votings. His productivity is 0.95. This means, he has a
    FinalForgingWeight of (0.8500000 + 0.210000)*0.95 = 381900. If he
    misses 50 blocks in a row, 50000 LSK will be removed from his account
    and the FinalForgingWeight will be lower next round.
  2. The poor developer has not much money. He can only afford 1000 LSK to
    put in his delegate account. But he has t top productivity of 99.5% and
    the community loves him and votes him with 2000000 LSK. This gives:
    (0.81000 + 0.22000000)*0.995 = 398796. If he misses 50 blocks in a
    row, he loses only 100 LSK (10% of his stake), but all his voters lose
    also 20000 LSK together (1%, exact number to be defined), which makes
    them pretty unhappy. A few unvote him and he will have a lower weight
    next round.
  3. The medium rich guy, sharing additional rewards has 100000 LSK in his
    account, and because he promises an additional 10% rewards to his voters
    he gets 1000000 in voting weight, even if his productivity with 90% is
    pretty low. His weight is: (0.8100000 + 0.21000000)*0.9 = 252000
  4. The poor unserious dude who has only the minimum of 300 LSK in his
    account, no votes at all, and a productivity of 80% because he does not
    care at all, has a weight of (0.8300+0.20)*0.8 = 192.

The total weight of all three delegates together is 1032888. This gives
following probabilites for the delegates to be chosen for the next round:
Rich guy: 36.97%
Poor developer: 38.61%
Medium rich sharer: 24.4%
Poor unserious dude: 0.019%

This means, all of them can forge more or less often, depending on their
weight, even the “poor unserious dude”, but he has such a low
probability that he will forge only once every XYZth round.

Rationale

It is important to acknowledge that one perfect voting system for
Delegated Proof of Stake does not exist. Nevertheless, the proposed
change of the voting system is a great improvement of the current state
and an important step in evolving the Lisk Delegated Proof of Stake
system. In this section, we give our reasoning for favoring the proposed
voting system

Desired Properties

At first, we want to list the main desired properties of a voting system
for Lisk:

  • Decentralization: The proposed system is very decentralized
    because everybody who wants to forge is allowed to do so and nobody can
    prevent it. That is a big difference to the current system, where a
    delegate depends on the will of the voters. Of course, delegates who are
    not willing to risk some big stakes and who does not get a lot of votes,
    will forge only very rarely. Making voters part of the consensus further
    increases the decentralization.
  • Incentive to offer good delegate service and productivity:
    Because delegates put their LSK at risk, they have a very high incentive
    to not misbehave. Additionally, the productivity influences the received
    rewards of the delegates which further incentives them to not miss blocks.
  • Incentive to vote for “good” delegates:
    Because voters can lose parts of their balance/stake if the delegate who
    they vote for either gets penalized or forges less often because he has
    a low productivity, the voters have high incentive to vote for “good”
    delegates, and not for those who simply offer high rewards without
    providing top service.
  • High participation:
    Fees to change votes/stakes will be drastically reduced with the new
    dynamic fee system. This will encourage voters to change their stake
    frequently, depending on the quality of the delegates. Voters will get a
    significant amount of rewards, if they vote for the right delegates.
    They also could lose some of their LSK if they vote for misbehaving or
    low-productivity delegates.
  • Simplicity:
    A nice and easy to use UI/UX is needed to make the staking pretty easy
    for users. I would propose something like this: a voter defines how much
    of his balance he wants to stake, for example 50%. Then he decides for
    which delegates he want to stake and with what weight. Example:
    3delegate1, 2delegate2 and 1*delegates3 to 10. If he has 5000 LSK in
    his account, the system would then automatically put 577 on delegate1,
    385 on delegate2 and 192 on delegates3-10.

Backwards Compatibility:

Even if the proposed system sounds quite different to the current one,
not so much changes are needed. I try to elaborate on what would have to
be changed/adapted/added:

  • Remove the hard forging probability ‘1 if rank <= 101, 0 otherwise’,
    and replace it with a floating point probability, depending on the
    staked amount, the received voting weight and the productivity.
  • Every round 101 delegates are chosen (depending on the
    FinalForgingWeight) to forge during this round.
  • Delegate accounts can’t vote. They basically vote themselves
    automatically.
  • Delegates can only forge if their balance is => MinStakeNeeded
  • The balance of the delegate accounts can be slashed by the protocol,
    similar to how forging rewards are added, penalties can be deducted.
  • Voters “vote” with a specific portion of their account for specific
    delegates. They can vote for as many delegates as they want. To make
    that process as easy as possible, some nice UI/UX must be implemented.
  • The amount voters put on stake can be slashed if “their” delegate
    misbehaves.
  • Voters get a percentage of the forging rewards.
  • Slashed amounts are burnt.

Future Improvements

Following additional improvements could be implementent in a future upgrade:
? Delegates need to lock the funds for at least a month, and can not
unlock them before that time frame is over. This incentivizes them even
more to offer good services, and they can’t just stop forging and
selling all their stake at anytime. They need to commit to forge for a
specific amount of time. I would propose that funds can only be unlocked
every 2600th round (~1 month) after starting the stake.
? The weight in a delegate account could be limited to like maybe 200000
LSK, even if there is more in it. This could lower the influence of
whales and big accounts. Of course they could split their amount into
multiple delegates but this needs some additional work, multiple nodes
need to be managed, and for the additional account also votes must be
received.

3 Likes
#2

Dear cc001 and 5an1ty,

thank you very much for sharing this proposal. It contains many interesting ideas and I agree that it would make the DPoS system more open and decentralized as many more people could potentially forge.

A lot of details are not clearly specified however:

- Specification of locking a deposit for delegates, e.g., transaction to lock and unlock deposits, time until money can be accessed again. If deposits are not locked, delegates could simply transfer the money to some other account before they would get punished.

- Specification of new vote transactions, e.g., transaction for adding and removing votes and time until money can be accessed again. Otherwise, it is unclear to me what happens in the following example: an account with a balance of 1000 LSK votes with 300 LSK for a delegate A and 400 LSK for a delegate B, but then transfers 500 LSK somewhere else.

- Specification of misbehavior of delegates and how slashing is achieved, e.g., in the case of double-forging.

- Specification how 101 delegates are selected, e.g., what source of randomness is used that cannot be easily biased.

- Specification of how the productivity is measured.

I am further skeptical about the following aspects of the proposal:

- Simplicity is one of the key objectives of Lisk. Not every user may need to understand all details of the protocol, but every user should be able to easily understand the voting system to participate. Moreover, the implementation of the proposal would require a lot of complexity, many new transaction types, many additional parameters to be chosen.

- Punishing missed blocks or low productivity as suggested can introduce new problems. For instance, two or more delegates forging after a delegate D can intentionally make delegate D miss its slots if they simply do not build on the block by delegate D, but create a separate chain. Thus, delegates could conspire to cause competing delegates to be punished. Moreover, denial-of-service attacks are incentivized. The other problem is that this opens the possibility of long range attacks (also called history attacks), as a group of delegates can secretly forge an alternative chain where other delegates eventually lose all their stake or their forging weight decreases drastically as they never forge.

- It is unclear that it is possible to choose a good value for x. I fear that the system would lead to one of two extremes:

Staking is too risky for delegates (10 % punishment instead of only 1 % for voters) compared to increased weight (staked amount is counted x times, but vote weight only (1-x) times). So all delegates only stake the minimum, vote for themselves and campaign for votes.

Staking is much better (in you proposal staking gives 5 times the weight of votes). Most delegates stake money together with potential voters/supporters (e.g., using multisig) and voting becomes rather meaningless as it only changes little.

- One of the main advantages of DPoS is that there is only certain number of elected delegates being able to forge blocks which allows for more efficiency and better productivity. In the proposed hybrid PoS-DPoS there would be a very large potential number of delegates. It is unclear to me how this would be much different from PoS (with simulating staking pools with voting). What would be the advantages of this hybrid system over PoS?

Cheers,
Jan

···

On 3/5/19 4:51 PM, cc001 wrote:

LIP: <LIP number>
Title: (D)PoS-Hybrid Voting system.
Author: cc001 <cc001.bct@gmail.com <mailto:cc001.bct@gmail.com>>, 5an1ty <5an1tycryptodev@gmail.com <mailto:5an1tycryptodev@gmail.com>>
Type: Standards Track
Module: DPoS
Created: 2019-03-05
Updated: 2019-03-05

## Abstract
This LIP proposes a change of the voting system to a kind of a hybrid between POS and DPOS systems. The major changes are:
* Everybody who locks a minimal deposit and registers a delegate will be able to forge more or less often. There is no limit of the top 101 anymore.
* The staked deposit of the delegates can be slashed (penalized) if the delegate misses multiple blocks in a row, double-forges, or misbehaves in other ways.
* Every round 101 delegates are chosen from the pool of eligible delegates to forge blocks. The probability to be chosen depends on the staked amount of the delegate, the received voting weight and the delegates productivity. Compared to the current system where the top 101 delegates forge all blocks, in the new system all delegates can forge, but depending on their weight, they forge more or less often, maybe only once every 100th round.
* Delegate accounts can't vote. They basically automatically vote for themselves.
* Voters stake specific amounts to specific delegates. If the specific delegate misbehaves, this voting stake can also be slashed.
* Voters are now also part of the consensus and get parts of the forging rewards.
* Slashed amounts (from delegates and from voters) are burned.

Credits for this proposal also go to delegate 5an1ty.

## Copyright
This LIP is licensed under the [GNU General Public License, version 3](http://www.gnu.org/licenses/gpl-3.0.html "GNU General Public License, version 3").

## Motivation
In the current voting system in Lisk, every account holder can vote for up to 101 delegates and the vote weight of the account is the balance of the account, also referred to as the stake of the account holder. The current voting system is based on [approval voting](https://en.wikipedia.org/wiki/Approval_voting) and the idea is that the delegates approved by the highest proportion of stake are the most suitable to secure the Lisk network. In practice, this system suffers from several shortcomings, which also have been addressed by members of the Lisk community. There is a high incentive for voters to vote for the current top 101 delegates because of the received rewards. This creates a very high barrier for anybody to become an active delegate (called "the 101 cliff") which hinders a healthy competition for active delegate slots.

The proposed new voting system has following properties and effects:
It is much more decentralized because everybody who wants to (and is willing to risk their stake) is able to forge, even if he does not receive any vote at all. Of course, delegates who receive many votes can forge more often than delegates who receive less votes. This is a significant change to the current system, where delegates depend on the will of the voters to be able to forge. Additionally, voters are also part of the consensus system by staking their balances to the delegates, for which they receive a part of the block rewards.

A delegate must keep a minimum amount in his delegate account to be able to forge. I would suggest this `MinStakeNeeded = 100*BlockReward`. Currently this would be 300 LSK, after the next block reduction it would be 200 LSK. If the balance in the delegates account falls below this limit, the delegate is automatically excluded from forging.

Voters stake for specific delegates and their staked amount will also be slashed by 1% (exact numbers to be defined) if "their" delegate misbehaves. This incentivizes voters to vote for "good" delegates, because voters lose money if they vote for misbehaving or low-productive delegates.

Delegates put their balance at stake and parts of it can be slashed if the delegate misbehaves. I would propose something like this:
* Missing 50 blocks in a row, will remove 10% of the staked amount in a delegates account.
* Double forging will also remove 10% of the stake.
This slashing mechanism incentivizes delegates to not misbehave because it costs them a significant amount of money and they risk to stop forging. It also removes misbehaving delegates automatically from forging if their account balance falls below MinStakeNeeded.

Every round, 101 delegates are chosen from the pool of eligible delegates. An eligible delegate is one that has at least MinStakeNeeded in his delegate account. The probability of being chosen for the current forging round depends on the staked amount of the delegate, the received voting weight and the productivity of the delegate and how many other eligible delegates exist and what their forging probability is. Exact numbers to be definined, I would propose something like this:
CurrentApproval = X*StakedAmount + (1-X)*ReceivedVotingWeight
FinalForgingWeight = CurrentApproval * Productivity.
ProbabilityToBeChosenFor101 = FinalForgingWeight/SumOfAllForgingWeightsOfAllEligibleDelegates.
X needs to be defined, I would propose for X something between 0.7 and 0.9. This means that voting weight is lower rated than the own stake. The reason for this is that it reduces to incentive to bribe delegates because a delegate can forge even if he receives no weight at all and the received weight doesn't count so much. On the other side, this mechanism allows also delegates who don't own a lot of own stake to forge significantly often, by receiving a lot of votes because they offer high quality and productivity.
`Productivity` might also be modified a little bit, to have a bigger influence between delegates. Almost all current delegates have a productivity higher than 99%, this means that it doesn't make a lot of difference between delegates. A way could be to scale it to something between 90 and 100.
Because the productivity directly influences the probability to forge and therefore the income of the delegate, the delegate has high incentive to reach high productivity. Additionally, voters have incentive to vote for delegates with high productivity, because they get parts of the block rewards, forged by the delegate they put their stake on.

Voters stake (or vote) with a specific amount of their LSK holdings for specific delegates. This means, a delegate with 5000 LSK can decide: 1000 to delegate1, 1000 to delegate2, 500 to delegate3, and 100 to 25 other delegates of his choice.
Voters can stake as many delegates as they want. Of course in total only their complete account balance can be staked.
The stake voters put on delegates can also be slashed. It will be slashed at the same situations where also the staked delegate get slashed (missing multiple blocks, double forging), but only with 1% (exact numbers to be defined) of the staked amount. This means, if a voter stakes 1000 LSK for a delegate (with 100000 LSK staked in his account) who misses 50 blocks in a row, the delegate will lose 10000 LSK (10%) of his stake, and the voter will lose 10 LSK. This incentivizes voters to not vote for delegates who only promise high rewards, but vote for delegates who offer good quality and don't get slashed. Because the delegates productivity directly influences the income of the delegate and his voters, delegates and voter have incentive to offer or vote for high productivity.

Because voters are part of the consensus protocol, they are automatically rewarded for voting. They receive a part of the forging rewards of the delegates they are staking. I would suggest that they receive something between 10-30%. Delegates might offer additional rewards on top of that for their voters, but I think this will be very limited, because voting weight does not have so much influence in the forging probability like it is the case with the current system.

My suggestion is that slashed amounts are burned. Other ideas are welcome. Burning these amounts would also reduce the supply and help the price on exchanges.

Here are a few examples how delegates with different stakes, voting weights and productivity would be able to forge. Lets assume X = 0.8
1. the rich guy put all his 500000 LSK at stake to forge with it. Because he does not care about the community, he gets only 10000 LSK votings. His productivity is 0.95. This means, he has a FinalForgingWeight of (0.8*500000 + 0.2*10000)*0.95 = 381900. If he misses 50 blocks in a row, 50000 LSK will be removed from his account and the FinalForgingWeight will be lower next round.
2. The poor developer has not much money. He can only afford 1000 LSK to put in his delegate account. But he has t top productivity of 99.5% and the community loves him and votes him with 2000000 LSK. This gives:
(0.8*1000 + 0.2*2000000)*0.995 = 398796. If he misses 50 blocks in a row, he loses only 100 LSK (10% of his stake), but all his voters lose also 20000 LSK together (1%, exact number to be defined), which makes them pretty unhappy. A few unvote him and he will have a lower weight next round.
3. The medium rich guy, sharing additional rewards has 100000 LSK in his account, and because he promises an additional 10% rewards to his voters he gets 1000000 in voting weight, even if his productivity with 90% is pretty low. His weight is: (0.8*100000 + 0.2*1000000)*0.9 = 252000
4. The poor unserious dude who has only the minimum of 300 LSK in his account, no votes at all, and a productivity of 80% because he does not care at all, has a weight of (0.8*300+0.2*0)*0.8 = 192.

The total weight of all three delegates together is 1032888. This gives following probabilites for the delegates to be chosen for the next round:
Rich guy: 36.97%
Poor developer: 38.61%
Medium rich sharer: 24.4%
Poor unserious dude: 0.019%

This means, all of them can forge more or less often, depending on their weight, even the "poor unserious dude", but he has such a low probability that he will forge only once every XYZth round.

## Rationale
It is important to acknowledge that one perfect voting system for Delegated Proof of Stake does not exist. Nevertheless, the proposed change of the voting system is a great improvement of the current state and an important step in evolving the Lisk Delegated Proof of Stake system. In this section, we give our reasoning for favoring the proposed voting system

### Desired Properties
At first, we want to list the main desired properties of a voting system for Lisk:
- **Decentralization**: The proposed system is very decentralized because everybody who wants to forge is allowed to do so and nobody can prevent it. That is a big difference to the current system, where a delegate depends on the will of the voters. Of course, delegates who are not willing to risk some big stakes and who does not get a lot of votes, will forge only very rarely. Making voters part of the consensus further increases the decentralization.
- **Incentive to offer good delegate service and productivity**:
Because delegates put their LSK at risk, they have a very high incentive to not misbehave. Additionally, the productivity influences the received rewards of the delegates which further incentives them to not miss blocks.
- **Incentive to vote for "good" delegates**:
Because voters can lose parts of their balance/stake if the delegate who they vote for either gets penalized or forges less often because he has a low productivity, the voters have high incentive to vote for "good" delegates, and not for those who simply offer high rewards without providing top service.
- **High participation**:
Fees to change votes/stakes will be drastically reduced with the new dynamic fee system. This will encourage voters to change their stake frequently, depending on the quality of the delegates. Voters will get a significant amount of rewards, if they vote for the right delegates. They also could lose some of their LSK if they vote for misbehaving or low-productivity delegates.
- **Simplicity**:
A nice and easy to use UI/UX is needed to make the staking pretty easy for users. I would propose something like this: a voter defines how much of his balance he wants to stake, for example 50%. Then he decides for which delegates he want to stake and with what weight. Example: 3*delegate1, 2*delegate2 and 1*delegates3 to 10. If he has 5000 LSK in his account, the system would then automatically put 577 on delegate1, 385 on delegate2 and 192 on delegates3-10.

## Backwards Compatibility:
Even if the proposed system sounds quite different to the current one, not so much changes are needed. I try to elaborate on what would have to be changed/adapted/added:
* Remove the hard forging probability '1 if rank <= 101, 0 otherwise', and replace it with a floating point probability, depending on the staked amount, the received voting weight and the productivity.
* Every round 101 delegates are chosen (depending on the FinalForgingWeight) to forge during this round.
* Delegate accounts can't vote. They basically vote themselves automatically.
* Delegates can only forge if their balance is => MinStakeNeeded
* The balance of the delegate accounts can be slashed by the protocol, similar to how forging rewards are added, penalties can be deducted.
* Voters "vote" with a specific portion of their account for specific delegates. They can vote for as many delegates as they want. To make that process as easy as possible, some nice UI/UX must be implemented.
* The amount voters put on stake can be slashed if "their" delegate misbehaves.
* Voters get a percentage of the forging rewards.
* Slashed amounts are burnt.

## Future Improvements
Following additional improvements could be implementent in a future upgrade:
• Delegates need to lock the funds for at least a month, and can not unlock them before that time frame is over. This incentivizes them even more to offer good services, and they can't just stop forging and selling all their stake at anytime. They need to commit to forge for a specific amount of time. I would propose that funds can only be unlocked every 2600th round (~1 month) after starting the stake.
• The weight in a delegate account could be limited to like maybe 200000 LSK, even if there is more in it. This could lower the influence of whales and big accounts. Of course they could split their amount into multiple delegates but this needs some additional work, multiple nodes need to be managed, and for the additional account also votes must be received.

--
Jan Hackfeld
Cryptographer, Lightcurve

1 Like
#3

Dear Jan

See additional comments below:

Dear cc001 and 5an1ty,

thank you very much for sharing this proposal. It contains many interesting ideas and I agree that it would make the DPoS system more open and decentralized as many more people could potentially forge.

A lot of details are not clearly specified however:

yeah, well, it is more from an economical and game theory point of view. We don't think we are skilled enough to specify all the Lisk Core internals in detail. But I heard about a company called "lightcurve". Those guys are pretty skilled, I'm sure they could specify those things in detail. :wink:

See my comments about your points below:

- Specification of locking a deposit for delegates, e.g., transaction to lock and unlock deposits, time until money can be accessed again. If deposits are not locked, delegates could simply transfer the money to some other account before they would get punished.

Yes, this indeed is needed.

- Specification of new vote transactions, e.g., transaction for adding and removing votes and time until money can be accessed again. Otherwise, it is unclear to me what happens in the following example: an account with a balance of 1000 LSK votes with 300 LSK for a delegate A and 400 LSK for a delegate B, but then transfers 500 LSK somewhere else.

Yes you are right. The simplest solution for this is defining the stakes/votes in percentage of the account balance and not in absolute values, then it doesn't matter how much LSK is in the account. Example: 30% for delegate A, 40% for delegate B, 30% not-staked. All this could be done in one "staking-transaction". Old "staking-transactions" are invalidated/overwritten by new staking-transactions.

- Specification of misbehavior of delegates and how slashing is achieved, e.g., in the case of double-forging.

well, as written above, I don't know how this could or should be implemented in Lisk Core. You are more capable to define those things.

- Specification how 101 delegates are selected, e.g., what source of randomness is used that cannot be easily biased.

well, as written above, I don't know how this could or should be implemented in Lisk Core. You are more capable to define those things.

What source of randomness did you use now to generate the random order in the list? Once you have that source of randomness, I think it's pretty easy to generate the same list of 101 delegates on all notes. You generate a list of all delegates, duplicate every delegate as often as needed, depending on the final score of every delegate (calculated as described from own weight, votings and productivity), order the list and then choose 101 from it, using your randomness.

- Specification of how the productivity is measured.

that is the productivity that exists already now. (see https://explorer.lisk.io/delegateMonitor).
I just proposed to not use it directly as it is, because almost everybody would get 0.99 and above and the difference between delegates would be negligible. You could map the values from 0.95 to 1.0 to the percentage scale to make the impact of it more important.
Example 0.95 -> 0, 0.975 -> 0.5, 1.0 -> 1
-> productivityfactor = 20 * productivity - 19

a current productivity of 99.9 would give 0.98. 99.0 would give 0.8. and so on. Just an example.

I am further skeptical about the following aspects of the proposal:

- Simplicity is one of the key objectives of Lisk. Not every user may need to understand all details of the protocol, but every user should be able to easily understand the voting system to participate. Moreover, the implementation of the proposal would require a lot of complexity, many new transaction types, many additional parameters to be chosen.

I think with a nice UI/UX this would be absolutely no problem. Tell them they can vote for so many delegates they want, and give everyone a percentage of your account. See https://youtu.be/VBwno7NiFQo?t=107 (also at time 4:20) for an example of something similar (from usage point of view).
And of course with "Simplicity" I mean from the user point of view. Of course it may need some complexity in the background, but that doesn't matter if it is "hidden" well from the user.
Honestly, I don't think we can improve our DPOS system by simply changing some parameters. It will need quite some changes if we want to improve it. Otherwise it could have been done already months/years ago, right?

- Punishing missed blocks or low productivity as suggested can introduce new problems. For instance, two or more delegates forging after a delegate D can intentionally make delegate D miss its slots if they simply do not build on the block by delegate D, but create a separate chain. Thus, delegates could conspire to cause competing delegates to be punished. Moreover, denial-of-service attacks are incentivized. The other problem is that this opens the possibility of long range attacks (also called history attacks), as a group of delegates can secretly forge an alternative chain where other delegates eventually lose all their stake or their forging weight decreases drastically as they never forge.

First of all, it's the job of a delegate to protect against DDOS (as good as possible). This means the delegate needs the skill and/or the money to set up such a protection. And DDOS could be done already now, it's nothing new.
For the other attack scenarios, I don't know exactly what is possible and what not. Maybe such malicious behavior could also be detected and lead to slashing of the malicious attackers.
But yes, such scenarios might need some additional thoughts.

- It is unclear that it is possible to choose a good value for x. I fear that the system would lead to one of two extremes:

Well, X is defined in the code. It won't lead to anything, it is fix. It will need some simulations/calculations/thoughts to find a good balance. But the nice thing is, even if it is balanced, both extreme positions are possible, which is the reason that a lot of different kinds of delegates will be able to forge (rich guy, poor dev, see my examples...)

Staking is too risky for delegates (10 punishment instead of only 1 for voters) compared to increased weight (staked amount is counted x times, but vote weight only (1-x) times). So all delegates only stake the minimum, vote for themselves and campaign for votes.

Staking is only risky for delegates who either misbehave (eg double forging) or offer poor service/monitoring (missing a lot of blocks in a row without fixing the node). "Good" delegates will never get slashed anything.

Staking is much better (in you proposal staking gives 5 times the weight of votes). Most delegates stake money together with potential voters/supporters (e.g., using multisig) and voting becomes rather meaningless as it only changes little.

That's quite complicate and needs so effort. If X is chosen well, I think it's not worth it.

- One of the main advantages of DPoS is that there is only certain number of elected delegates being able to forge blocks which allows for more efficiency and better productivity. In the proposed hybrid PoS-DPoS there would be a very large potential number of delegates. It is unclear to me how this would be much different from PoS (with simulating staking pools with voting). What would be the advantages of this hybrid system over PoS?

There is a large potential number of delegates, but because every round 101 delegates are chosen in the beginning of the round, not much changes compared to now will be needed, and I don't think it's less efficient.
The differences are:
* 101 are chosen every round. this is how Lisk works and it is quite efficient.
* Voters can participate without having to be delegate.

* Votes will influence the forgers, which is not the case in pure POS

* It will lead to "good" delegates forging more often. Which is not the case in POS, where only the rich guys forge often.

Greetings

···

On 13.03.19 18:40, Jan Hackfeld wrote:

Cheers,
Jan

On 3/5/19 4:51 PM, cc001 wrote:

LIP: <LIP number>
Title: (D)PoS-Hybrid Voting system.
Author: cc001 <cc001.bct@gmail.com <mailto:cc001.bct@gmail.com>>, 5an1ty <5an1tycryptodev@gmail.com <mailto:5an1tycryptodev@gmail.com>>
Type: Standards Track
Module: DPoS
Created: 2019-03-05
Updated: 2019-03-05

## Abstract
This LIP proposes a change of the voting system to a kind of a hybrid between POS and DPOS systems. The major changes are:
* Everybody who locks a minimal deposit and registers a delegate will be able to forge more or less often. There is no limit of the top 101 anymore.
* The staked deposit of the delegates can be slashed (penalized) if the delegate misses multiple blocks in a row, double-forges, or misbehaves in other ways.
* Every round 101 delegates are chosen from the pool of eligible delegates to forge blocks. The probability to be chosen depends on the staked amount of the delegate, the received voting weight and the delegates productivity. Compared to the current system where the top 101 delegates forge all blocks, in the new system all delegates can forge, but depending on their weight, they forge more or less often, maybe only once every 100th round.
* Delegate accounts can't vote. They basically automatically vote for themselves.
* Voters stake specific amounts to specific delegates. If the specific delegate misbehaves, this voting stake can also be slashed.
* Voters are now also part of the consensus and get parts of the forging rewards.
* Slashed amounts (from delegates and from voters) are burned.

Credits for this proposal also go to delegate 5an1ty.

## Copyright
This LIP is licensed under the [GNU General Public License, version 3](http://www.gnu.org/licenses/gpl-3.0.html "GNU General Public License, version 3").

## Motivation
In the current voting system in Lisk, every account holder can vote for up to 101 delegates and the vote weight of the account is the balance of the account, also referred to as the stake of the account holder. The current voting system is based on [approval voting](https://en.wikipedia.org/wiki/Approval_voting) and the idea is that the delegates approved by the highest proportion of stake are the most suitable to secure the Lisk network. In practice, this system suffers from several shortcomings, which also have been addressed by members of the Lisk community. There is a high incentive for voters to vote for the current top 101 delegates because of the received rewards. This creates a very high barrier for anybody to become an active delegate (called "the 101 cliff") which hinders a healthy competition for active delegate slots.

The proposed new voting system has following properties and effects:
It is much more decentralized because everybody who wants to (and is willing to risk their stake) is able to forge, even if he does not receive any vote at all. Of course, delegates who receive many votes can forge more often than delegates who receive less votes. This is a significant change to the current system, where delegates depend on the will of the voters to be able to forge. Additionally, voters are also part of the consensus system by staking their balances to the delegates, for which they receive a part of the block rewards.

A delegate must keep a minimum amount in his delegate account to be able to forge. I would suggest this `MinStakeNeeded = 100*BlockReward`. Currently this would be 300 LSK, after the next block reduction it would be 200 LSK. If the balance in the delegates account falls below this limit, the delegate is automatically excluded from forging.

Voters stake for specific delegates and their staked amount will also be slashed by 1% (exact numbers to be defined) if "their" delegate misbehaves. This incentivizes voters to vote for "good" delegates, because voters lose money if they vote for misbehaving or low-productive delegates.

Delegates put their balance at stake and parts of it can be slashed if the delegate misbehaves. I would propose something like this:
* Missing 50 blocks in a row, will remove 10% of the staked amount in a delegates account.
* Double forging will also remove 10% of the stake.
This slashing mechanism incentivizes delegates to not misbehave because it costs them a significant amount of money and they risk to stop forging. It also removes misbehaving delegates automatically from forging if their account balance falls below MinStakeNeeded.

Every round, 101 delegates are chosen from the pool of eligible delegates. An eligible delegate is one that has at least MinStakeNeeded in his delegate account. The probability of being chosen for the current forging round depends on the staked amount of the delegate, the received voting weight and the productivity of the delegate and how many other eligible delegates exist and what their forging probability is. Exact numbers to be definined, I would propose something like this:
CurrentApproval = X*StakedAmount + (1-X)*ReceivedVotingWeight
FinalForgingWeight = CurrentApproval * Productivity.
ProbabilityToBeChosenFor101 = FinalForgingWeight/SumOfAllForgingWeightsOfAllEligibleDelegates.
X needs to be defined, I would propose for X something between 0.7 and 0.9. This means that voting weight is lower rated than the own stake. The reason for this is that it reduces to incentive to bribe delegates because a delegate can forge even if he receives no weight at all and the received weight doesn't count so much. On the other side, this mechanism allows also delegates who don't own a lot of own stake to forge significantly often, by receiving a lot of votes because they offer high quality and productivity.
`Productivity` might also be modified a little bit, to have a bigger influence between delegates. Almost all current delegates have a productivity higher than 99%, this means that it doesn't make a lot of difference between delegates. A way could be to scale it to something between 90 and 100.
Because the productivity directly influences the probability to forge and therefore the income of the delegate, the delegate has high incentive to reach high productivity. Additionally, voters have incentive to vote for delegates with high productivity, because they get parts of the block rewards, forged by the delegate they put their stake on.

Voters stake (or vote) with a specific amount of their LSK holdings for specific delegates. This means, a delegate with 5000 LSK can decide: 1000 to delegate1, 1000 to delegate2, 500 to delegate3, and 100 to 25 other delegates of his choice.
Voters can stake as many delegates as they want. Of course in total only their complete account balance can be staked.
The stake voters put on delegates can also be slashed. It will be slashed at the same situations where also the staked delegate get slashed (missing multiple blocks, double forging), but only with 1% (exact numbers to be defined) of the staked amount. This means, if a voter stakes 1000 LSK for a delegate (with 100000 LSK staked in his account) who misses 50 blocks in a row, the delegate will lose 10000 LSK (10%) of his stake, and the voter will lose 10 LSK. This incentivizes voters to not vote for delegates who only promise high rewards, but vote for delegates who offer good quality and don't get slashed. Because the delegates productivity directly influences the income of the delegate and his voters, delegates and voter have incentive to offer or vote for high productivity.

Because voters are part of the consensus protocol, they are automatically rewarded for voting. They receive a part of the forging rewards of the delegates they are staking. I would suggest that they receive something between 10-30%. Delegates might offer additional rewards on top of that for their voters, but I think this will be very limited, because voting weight does not have so much influence in the forging probability like it is the case with the current system.

My suggestion is that slashed amounts are burned. Other ideas are welcome. Burning these amounts would also reduce the supply and help the price on exchanges.

Here are a few examples how delegates with different stakes, voting weights and productivity would be able to forge. Lets assume X = 0.8
1. the rich guy put all his 500000 LSK at stake to forge with it. Because he does not care about the community, he gets only 10000 LSK votings. His productivity is 0.95. This means, he has a FinalForgingWeight of (0.8*500000 + 0.2*10000)*0.95 = 381900. If he misses 50 blocks in a row, 50000 LSK will be removed from his account and the FinalForgingWeight will be lower next round.
2. The poor developer has not much money. He can only afford 1000 LSK to put in his delegate account. But he has t top productivity of 99.5% and the community loves him and votes him with 2000000 LSK. This gives:
(0.8*1000 + 0.2*2000000)*0.995 = 398796. If he misses 50 blocks in a row, he loses only 100 LSK (10% of his stake), but all his voters lose also 20000 LSK together (1%, exact number to be defined), which makes them pretty unhappy. A few unvote him and he will have a lower weight next round.
3. The medium rich guy, sharing additional rewards has 100000 LSK in his account, and because he promises an additional 10% rewards to his voters he gets 1000000 in voting weight, even if his productivity with 90% is pretty low. His weight is: (0.8*100000 + 0.2*1000000)*0.9 = 252000
4. The poor unserious dude who has only the minimum of 300 LSK in his account, no votes at all, and a productivity of 80% because he does not care at all, has a weight of (0.8*300+0.2*0)*0.8 = 192.

The total weight of all three delegates together is 1032888. This gives following probabilites for the delegates to be chosen for the next round:
Rich guy: 36.97%
Poor developer: 38.61%
Medium rich sharer: 24.4%
Poor unserious dude: 0.019%

This means, all of them can forge more or less often, depending on their weight, even the "poor unserious dude", but he has such a low probability that he will forge only once every XYZth round.

## Rationale
It is important to acknowledge that one perfect voting system for Delegated Proof of Stake does not exist. Nevertheless, the proposed change of the voting system is a great improvement of the current state and an important step in evolving the Lisk Delegated Proof of Stake system. In this section, we give our reasoning for favoring the proposed voting system

### Desired Properties
At first, we want to list the main desired properties of a voting system for Lisk:
- **Decentralization**: The proposed system is very decentralized because everybody who wants to forge is allowed to do so and nobody can prevent it. That is a big difference to the current system, where a delegate depends on the will of the voters. Of course, delegates who are not willing to risk some big stakes and who does not get a lot of votes, will forge only very rarely. Making voters part of the consensus further increases the decentralization.
- **Incentive to offer good delegate service and productivity**:
Because delegates put their LSK at risk, they have a very high incentive to not misbehave. Additionally, the productivity influences the received rewards of the delegates which further incentives them to not miss blocks.
- **Incentive to vote for "good" delegates**:
Because voters can lose parts of their balance/stake if the delegate who they vote for either gets penalized or forges less often because he has a low productivity, the voters have high incentive to vote for "good" delegates, and not for those who simply offer high rewards without providing top service.
- **High participation**:
Fees to change votes/stakes will be drastically reduced with the new dynamic fee system. This will encourage voters to change their stake frequently, depending on the quality of the delegates. Voters will get a significant amount of rewards, if they vote for the right delegates. They also could lose some of their LSK if they vote for misbehaving or low-productivity delegates.
- **Simplicity**:
A nice and easy to use UI/UX is needed to make the staking pretty easy for users. I would propose something like this: a voter defines how much of his balance he wants to stake, for example 50%. Then he decides for which delegates he want to stake and with what weight. Example: 3*delegate1, 2*delegate2 and 1*delegates3 to 10. If he has 5000 LSK in his account, the system would then automatically put 577 on delegate1, 385 on delegate2 and 192 on delegates3-10.

## Backwards Compatibility:
Even if the proposed system sounds quite different to the current one, not so much changes are needed. I try to elaborate on what would have to be changed/adapted/added:
* Remove the hard forging probability '1 if rank <= 101, 0 otherwise', and replace it with a floating point probability, depending on the staked amount, the received voting weight and the productivity.
* Every round 101 delegates are chosen (depending on the FinalForgingWeight) to forge during this round.
* Delegate accounts can't vote. They basically vote themselves automatically.
* Delegates can only forge if their balance is => MinStakeNeeded
* The balance of the delegate accounts can be slashed by the protocol, similar to how forging rewards are added, penalties can be deducted.
* Voters "vote" with a specific portion of their account for specific delegates. They can vote for as many delegates as they want. To make that process as easy as possible, some nice UI/UX must be implemented.
* The amount voters put on stake can be slashed if "their" delegate misbehaves.
* Voters get a percentage of the forging rewards.
* Slashed amounts are burnt.

## Future Improvements
Following additional improvements could be implementent in a future upgrade:
• Delegates need to lock the funds for at least a month, and can not unlock them before that time frame is over. This incentivizes them even more to offer good services, and they can't just stop forging and selling all their stake at anytime. They need to commit to forge for a specific amount of time. I would propose that funds can only be unlocked every 2600th round (~1 month) after starting the stake.
• The weight in a delegate account could be limited to like maybe 200000 LSK, even if there is more in it. This could lower the influence of whales and big accounts. Of course they could split their amount into multiple delegates but this needs some additional work, multiple nodes need to be managed, and for the additional account also votes must be received.

1 Like
#5

Punishing missed blocks or low productivity as suggested can introduce new problems. For instance, two or more delegates forging after a delegate D can intentionally make delegate D miss its slots if they simply do not build on the block by delegate D, but create a separate chain. Thus, delegates could conspire to cause competing delegates to be punished.

This is a great point @janhack and this is definitely something to worry about.

The network would see the fork however and could make a decision based on what it sees.

  • Delegate D builds on top of a block by Delegate C
  • Delegate E also builds on top of a block by Delegate C

If you as a node see the block by Delegate D as well as Delegate E you know Delegate E is the offender here.

So Delegate E that was trying to sabotage Delegate D should be punished.

The slashing should not be based on productivity but also on actions that sabotage the network.
Even if Delegate E didn’t have bad intentions but due to bad connectivity didn’t see the block by Delegate D, this is still Delegate E’s fault, unless > 50% saw the same as Delegate E of course.

Because everyone can be a delegate and everyone that wants to participates in consensus can do so it means we have a vast network of truthful participants.

FYI: Only 101 delegates will be randomly selected based on total weight to be active per round, so scaling is intact.

#6

Dear cc001,

Thanks for your reply! I tried to further address your new comments below:

Please understand that we cannot work out all the details of your proposal, which has all the complexity of a proof-of-stake blockchain, as there are a lot of other roadmap objectives we are working on and also I am not convinced that it would go in the right direction.

I think percentages would be a solution. Note that we additionally may also need to lock deposits for voting accounts as they could otherwise transfer their balance shortly before a delegate would be slashed.

For generating the delegate list we use the hash of the height as a source of randomness (see LIP-0003 for details). This value cannot be biased, but is known in advance. That is why it is not suited for selecting delegates in a proof-of-stake like fashion as proposed above. For instance, I could register a certain public key/address as delegate and attribute a certain balance and vote weight to it because I know it will be selected in a certain round in the near future.

If we select delegates taking this value into account we need a precise definition that is the same for everyone and only depends on blockchain data. Otherwise, the network could easily split.

Cheers,
Jan

#7

Dear @5an1ty,

I don’t think missed block slots can be punished as you suggest above. The reason is that the observations, when a block is received, can be totally different for different nodes. But then it is unclear how the network can agree whether to punish delegate E in the example above or not.

For instance, Delegate D may broadcast its block to only half of the delegates and by controlling a sufficient number of nodes may prevent it from reaching delegate E and the other half of the delegates in time. Then to one half of the delegates it seems like E maliciously ignored the block by delegate D and to the other half it appears like D missed its slot. There is no way to verify which of the observations is the correct one.

In general, it is only possible to punish delegates based on information included in the blockchain as there is not necessarily consensus about information not part of the blockchain (e.g.,
arrival times of blocks).

I understand that only 101 delegates of a potentially very large number of delegates are selected. In terms of scalability of a BFT consensus protocol, the total number of nodes/validators/delegates (not only the small set of delegates of a round) lead to more overhead and lower time to finality. See also Vlad Zamfir’s tradeoff triangle.

Cheers,
Jan