danielle
Pivian
Nitya
7
Jul '17
Foreword
This write up is based on the concepts proposed by Presstab* and Cryptosi** on the pivx forums. After reading these ideas I was intrigued but also a bit worried because they seem to lack info on how this would be implemented and what the expected result of such an implementation would be.
Down below I present one of the possible ways to combine both proposals and the existing network into a simple and functional system that keeps the door open to some of the other desires and idea’s floating around in the community.
If you are not familiar with the original proposals I recommend you read them since the write up below tries to implement them without explaining the ideas behind them and alters some of the aspects related to them. Links below:
I’m staking funds for and working on the ‘Pivit Point of Sale’ project.
Extending the use of Masternode keys on to Voting and Staking Nodes as described below would be beneficial to some of the concepts used in the ‘Point of Sale’ and a ‘Custom Wallet’; both are WIP and on my to-do lists. (beneficial but not necessary)
Intro
The decision to allow more people to participate in the governance system has passed but was left open ended.* The primary question is who gets to vote?
“One Person; One Vote” seems the logical solution and philosophically it makes sense. However, on a practical level, it requires that the network defines and identify what “One Person” is. As it turns out this is a complex problem to solve in a network that aims to be decentralized and puts a high values privacy and anonymity.
So who gets to vote? Everyone that holds coins? Everyone that participates in the network? Again the network has to define and identify this. As it turns out it already does this; the block rewards are paid out to people that hold coins and actively participate in the network.
The question to ask, is it feasible to build a fair and functional governance system around those rewards? Down below I break down some numbers to explore one of the many ways this could play out; when doing so my main goal is to balance things out as much as possible to avoid any surprises as the coin supply grows.
When dealing with governance you are dealing power dynamics, within the theory on these dynamics four main groups play a role:
Identity Key
Masternodes already use this concept, they have keys not related to funds that allow the controlling wallet to manage multiple nodes. As it stands these keys identify a specific node on the network; in governance, these keys are used to cast votes.
Voting Weights
Every identity (node) on the network that obtains a valid voting weight has the right to vote; the weight of a vote depends on a number of weights the identity accumulated in a specific voting cycle.
Nodes
Within the tiered network, there are three node types that perform specific services to the network.
Voternode
The Owls and Wolfs of the network; requires a medium investment and they support the network by actively organizing the governance and proposal.
Masternodes
The whales in the network; requires the highest investment and passively support the network by securing private and instant transactions.
The network Swarm; requires minimal investment and passively secure the network by participating in the proof of stake system.
Block generation and the proof of stake system remain as they are but with a new node type added to the network the seesaw algorithm and related values need to be adjusted. As a recap the seesaw algorithm aims to balance out the number of coins locked away in Masternodes by adjusting the values of block rewards; as a result, it also tries to limit the maximum amount of Masternodes the network supports.
With that in mind it is time to start running some numbers; while the table below might seem random, it is setup to balance things out as much as possible. It assumes the supply is 54 million coins, current supply rounded up as it is set to grow as time passes.
| | Total (%) | Total (piv) | Locked | Nodes |
|---------|-----------|-------------|--------|--------|
| Voter | 20.00% | 10.800.000 | 2500 | 4.320 |
| Master | 40.00% | 21.600.000 | 10000 | 2.160 |
| Staking | 40.00% | 21.600.000 | *500* | 43.200 |
Block Rewards
The next bits of data required by the seesaw algorithm are the block rewards, the base line is listed below while the algorithm adjusts them to tweak to incentive pivx holders to keep the node counts around the desired amounts.
The values below are balanced based on the number of coins required to run a specific node and the expected rewards those nodes get per cycle (blocks); the other factor to keep in mind is the time and cost required to operate a node.
Reward Split - Equal based on value
| | Split (%) | Per Block | Blocks | Per Cycle |
|---------|-----------|-----------|--------|-----------|
| Voter | 20.00% | 0.900000 | 10 | 9.000000 |
| Master | 40.00% | 1.800000 | 20 | 36.000000 |
| Staking | 40.00% | 1.800000 | 1 | 1.800000 |
Reward Split - Adjusted for cost, time & incentive
| | Split (%) | Per Block | Blocks | Per Cycle |
|---------|-----------|-----------|--------|-----------|
| Voter | 22.50% | 1.012500 | 10 | 10.125000 |
| Master | 42.50% | 1.912500 | 20 | 38.250000 |
| Staking | 35.00% | 1.575000 | 1 | 1.575000 |
Note: The current system gives a very small edge to Masternodes, while the numbers above increase that edge to account for coins that are not actively staking. The values required to get a balance might require some tweaking.
Voting Weights
As with the rewards, it is possible to compute the expected voting weights per node and tier. For simplicity, the numbers below assume the one block rewards equals one voting weight, further down some examples are added that explain why this might be too simple.
Something to keep in mind is that a node only has one vote no matter how many weights he gains and that the weight of that vote gets adjusted by the weight amount.
| | Total (%) | Nodes | Weights | Share | Vote Count | Vote Share |
|---------|-----------|--------|---------|-------|------------|------------|
| Voter | 20.00% | 4.320 | 10.0 | 5.0 | 43200 | 21600 |
| Master | 40.00% | 2.160 | 20.0 | 20.0 | 43200 | 43200 |
| Staking | 40.00% | 43.200 | 1.0 | 1.0 | 43200 | 43200 |
Note: The vote count is fixed by the proof of stake system that generates one block every minute and the governance cycles that are finalized every 43200 blocks. As the coin supply grows the accumulated weight per node and per cycle will go down.
The input required per tier is far from equal; Voternodes are only required to lock 1/4 of the coins required by a Masternode but gets 1/2 of the weights; on the other side they require 5x of the coin needed by a Stakingnode to get 1 weight but the Voternode gets 10x weights in return.
As with the block rewards, it is required to offset the weights granted to Voternodes in relation to the coins required to maintain a node. The ‘share’ column shows the weights they should get based on the coins required; as it turns out this exactly half of the weights they receive.
The result is that there are 21600 weights remaining in this tier and 21600 unassigned weights; to restore the unassigned weights the delegation system comes in to play. Both Masternodes and Stakingnodes are able to delegate their votes to a Voternode by doing so they also pledge support to that node and in return for that support, the Voternode gets assigned some of the unassigned weights in its tier.
An equal split of 21.600 votes based on delegated weights:
Final Thoughts
The main benefit of using the rewards to control who gets to vote is the minimal amount of impact it has on the code base. The biggest change is the introduction of Voternodes; something that is already proposed and can borrow most of its code from Masternodes.
The biggest down side is the random sampling of the swarm, with just 43.200 weights per cycle to be spread out in what is supposed to be the largest group within the network it can only be looked at as a randomized sample. The most logical solution would be a decentralized and trust-less staking pool build into the network but that is a whole other ‘can of worms’ that could be handled at a later date.
Voting System
This write-up aims to explore the usability of block rewards as voting weights; the descriptions below are not intended to fully define the voting process instead, they just highlight some of the options that become available when implementing Voternode with ‘Voting Weights’ and ‘Identity Keys’.
The Voternode gains a key role in the network and becomes more than just an extra node that is used to lock coins and vote. It does not matter how you implement the idea around Voternodes you end up implementing a political class; a group that will attract those looking for changes that benefits their world view. When doing so it is important to add systems that holds the members of that group accountable and that it is possible to take away the benefits granted to them by the network.
Voting Tiers
When implemented as above it seems a balanced three tiered system is possible, that said I’m still not convinced it is wise to split them into three separate voting groups that all require a majority. Things beneficial to the network and Masternodes might be voted down by Stakingnodes and visa versa, the argument could be made that every proposal has to benefit ‘all’ but I’m not convinced that this is always feasible. Again this is just opinion, but all or nothing feels unbalanced to me; that and taking over one group is all that is needed to cripple the system.
Because of the role, Voternodes get assigned to them it seems logical to take some of the load from Masternodes and Stakingnodes by using the Voternodes as a filter. In that case, a proposal would require support from one or more Voternodes before it enters the network and then it would have to be passed by the majority of Voternodes before it is passed on to Masternodes and Stakingnodes for them to cast a vote.
The main goal of this would be to reduce voter apathy by reducing the work required of the two groups that contain people less interested the governance; on the other side, it requires people submitting a proposal to interact with the more active group that needs to keep its reputation up.
Voting Privacy
By tokenizing the voting weights it becomes possible to implement privacy in the voting systems. At the end of the month, libzerocoin is utilized to create a pool of tokens that are spent when the owner of the tokens casts his votes on the proposals available in that month.
Understanding the current system, a vote is created by signing a message with a private key, this means the person voting can prove he voted in a specific way and when the key is compromised it becomes possible to see how the owner of a key voted in the past.
The main issue with this is that voters can prove they voted in a specific way, this turns the vote into a commodity that can be sold and can result in corruption. A lesser issue, on failure to protect the voting key public pressure and fear of retaliation, could prevent people from voting against their peers even when they believe the proposal to be flawed.
Note: This has the down side that votes can no longer be changed and that the end user needs to vote on all proposals in a single network broadcast.
Voting Delegates
For delegation support on to Voternodes by both Masternodes and Stakingnodes could be used in reverse; meaning that when a supporter of a Voternode does not manually submit it’s vote his vote will follow that of the Voternode they support. When doing so it might be wise to implement strong and weak votes (-2, -1, 0, +1, +2) to balance things out again; where a delegated vote in the Masternodes or Stakingnodes group becomes a weak vote and nodes that do explicitly vote do so with a strong vote.
Closing
While this system is not perfect it forms a solid base to build on and requires minimal change to the core of the network. ‘The identity keys’ could be linked to other identifying info when this becomes desirable and ‘Voting Weights’ could be earned in different ways. Nothing here is set in stone … but a foundation is created.
history: https://gist.github.com/Nitya-Sattva/4d06e55d6b924661bb978af2022b4272
7
Jul '17
Foreword
This write up is based on the concepts proposed by Presstab* and Cryptosi** on the pivx forums. After reading these ideas I was intrigued but also a bit worried because they seem to lack info on how this would be implemented and what the expected result of such an implementation would be.
Down below I present one of the possible ways to combine both proposals and the existing network into a simple and functional system that keeps the door open to some of the other desires and idea’s floating around in the community.
If you are not familiar with the original proposals I recommend you read them since the write up below tries to implement them without explaining the ideas behind them and alters some of the aspects related to them. Links below:
- Presstab - http://archive.is/Ddt8K 3 - An Equal Weighted Three-Tier System
- Cryptosi - http://archive.is/BzmZl - Three-Tier Voting System Amendment
- Eric Stanek - http://archive.is/KhFEN - CDG: Multiple Governance Categories
I’m staking funds for and working on the ‘Pivit Point of Sale’ project.
Extending the use of Masternode keys on to Voting and Staking Nodes as described below would be beneficial to some of the concepts used in the ‘Point of Sale’ and a ‘Custom Wallet’; both are WIP and on my to-do lists. (beneficial but not necessary)
Intro
The decision to allow more people to participate in the governance system has passed but was left open ended.* The primary question is who gets to vote?
“One Person; One Vote” seems the logical solution and philosophically it makes sense. However, on a practical level, it requires that the network defines and identify what “One Person” is. As it turns out this is a complex problem to solve in a network that aims to be decentralized and puts a high values privacy and anonymity.
So who gets to vote? Everyone that holds coins? Everyone that participates in the network? Again the network has to define and identify this. As it turns out it already does this; the block rewards are paid out to people that hold coins and actively participate in the network.
The question to ask, is it feasible to build a fair and functional governance system around those rewards? Down below I break down some numbers to explore one of the many ways this could play out; when doing so my main goal is to balance things out as much as possible to avoid any surprises as the coin supply grows.
- Eric Stanek - http://archive.is/yPsUy -
Community Designed Governance - MNO Approval
When dealing with governance you are dealing power dynamics, within the theory on these dynamics four main groups play a role:
- The Owls: wise, protecting the foundation.
- The Whales: big movers, hidden below the waters.
- The Wolves: on the prowl, looking for changes that may benefit them.
- The Swarms: flowing around the environment, consuming what ever they can.
Masternodes already use this concept, they have keys not related to funds that allow the controlling wallet to manage multiple nodes. As it stands these keys identify a specific node on the network; in governance, these keys are used to cast votes.
Voting Weights
Every identity (node) on the network that obtains a valid voting weight has the right to vote; the weight of a vote depends on a number of weights the identity accumulated in a specific voting cycle.
Nodes
Within the tiered network, there are three node types that perform specific services to the network.
Voternode
The Owls and Wolfs of the network; requires a medium investment and they support the network by actively organizing the governance and proposal.
- Runs as a full chain node and handles governance related functionality required by the network, requires a fixed public addresses. (medium cost)
- For a Voternode the identity and reputation related to that identity is key, to utilize the full potential of the node the owner has to gather support from either the Masternodes or the Stakingnodes.
- Without support a Voternode has no extra voting right and earns no more than a Masternode.
Masternodes
The whales in the network; requires the highest investment and passively support the network by securing private and instant transactions.
- Runs as a full chain node and handles transaction related functionality required by the network, requires a fixed public addresses. (high cost)
- Voting Weights can be used to support Voternode and optionally the node can delegate the voting power of his weights to a Voternode.
The network Swarm; requires minimal investment and passively secure the network by participating in the proof of stake system.
- Runs as a full chain node, participates in proof of stake. (low cost)
- Voting Weights can be used to support Voternode and optionally the node can delegate the voting power of his weights to a Voternode.
Block generation and the proof of stake system remain as they are but with a new node type added to the network the seesaw algorithm and related values need to be adjusted. As a recap the seesaw algorithm aims to balance out the number of coins locked away in Masternodes by adjusting the values of block rewards; as a result, it also tries to limit the maximum amount of Masternodes the network supports.
With that in mind it is time to start running some numbers; while the table below might seem random, it is setup to balance things out as much as possible. It assumes the supply is 54 million coins, current supply rounded up as it is set to grow as time passes.
| | Total (%) | Total (piv) | Locked | Nodes |
|---------|-----------|-------------|--------|--------|
| Voter | 20.00% | 10.800.000 | 2500 | 4.320 |
| Master | 40.00% | 21.600.000 | 10000 | 2.160 |
| Staking | 40.00% | 21.600.000 | *500* | 43.200 |
- The seesaw algorithm gets adjusted to target a 20/40/40 split.
- The resulting node count is 2.160 Masternodes and 4.320 Voternodes.
Block Rewards
The next bits of data required by the seesaw algorithm are the block rewards, the base line is listed below while the algorithm adjusts them to tweak to incentive pivx holders to keep the node counts around the desired amounts.
The values below are balanced based on the number of coins required to run a specific node and the expected rewards those nodes get per cycle (blocks); the other factor to keep in mind is the time and cost required to operate a node.
Reward Split - Equal based on value
| | Split (%) | Per Block | Blocks | Per Cycle |
|---------|-----------|-----------|--------|-----------|
| Voter | 20.00% | 0.900000 | 10 | 9.000000 |
| Master | 40.00% | 1.800000 | 20 | 36.000000 |
| Staking | 40.00% | 1.800000 | 1 | 1.800000 |
Reward Split - Adjusted for cost, time & incentive
| | Split (%) | Per Block | Blocks | Per Cycle |
|---------|-----------|-----------|--------|-----------|
| Voter | 22.50% | 1.012500 | 10 | 10.125000 |
| Master | 42.50% | 1.912500 | 20 | 38.250000 |
| Staking | 35.00% | 1.575000 | 1 | 1.575000 |
Note: The current system gives a very small edge to Masternodes, while the numbers above increase that edge to account for coins that are not actively staking. The values required to get a balance might require some tweaking.
Voting Weights
As with the rewards, it is possible to compute the expected voting weights per node and tier. For simplicity, the numbers below assume the one block rewards equals one voting weight, further down some examples are added that explain why this might be too simple.
Something to keep in mind is that a node only has one vote no matter how many weights he gains and that the weight of that vote gets adjusted by the weight amount.
| | Total (%) | Nodes | Weights | Share | Vote Count | Vote Share |
|---------|-----------|--------|---------|-------|------------|------------|
| Voter | 20.00% | 4.320 | 10.0 | 5.0 | 43200 | 21600 |
| Master | 40.00% | 2.160 | 20.0 | 20.0 | 43200 | 43200 |
| Staking | 40.00% | 43.200 | 1.0 | 1.0 | 43200 | 43200 |
Note: The vote count is fixed by the proof of stake system that generates one block every minute and the governance cycles that are finalized every 43200 blocks. As the coin supply grows the accumulated weight per node and per cycle will go down.
The input required per tier is far from equal; Voternodes are only required to lock 1/4 of the coins required by a Masternode but gets 1/2 of the weights; on the other side they require 5x of the coin needed by a Stakingnode to get 1 weight but the Voternode gets 10x weights in return.
As with the block rewards, it is required to offset the weights granted to Voternodes in relation to the coins required to maintain a node. The ‘share’ column shows the weights they should get based on the coins required; as it turns out this exactly half of the weights they receive.
The result is that there are 21600 weights remaining in this tier and 21600 unassigned weights; to restore the unassigned weights the delegation system comes in to play. Both Masternodes and Stakingnodes are able to delegate their votes to a Voternode by doing so they also pledge support to that node and in return for that support, the Voternode gets assigned some of the unassigned weights in its tier.
An equal split of 21.600 votes based on delegated weights:
- 4 weights from Masternodes adds 1 support weight ; 43.200 / 4 = 10800
- 4 weights from Stakingnodes adds 1 support weight ; 43.200 / 4 = 10800
Final Thoughts
The main benefit of using the rewards to control who gets to vote is the minimal amount of impact it has on the code base. The biggest change is the introduction of Voternodes; something that is already proposed and can borrow most of its code from Masternodes.
The biggest down side is the random sampling of the swarm, with just 43.200 weights per cycle to be spread out in what is supposed to be the largest group within the network it can only be looked at as a randomized sample. The most logical solution would be a decentralized and trust-less staking pool build into the network but that is a whole other ‘can of worms’ that could be handled at a later date.
Voting System
This write-up aims to explore the usability of block rewards as voting weights; the descriptions below are not intended to fully define the voting process instead, they just highlight some of the options that become available when implementing Voternode with ‘Voting Weights’ and ‘Identity Keys’.
The Voternode gains a key role in the network and becomes more than just an extra node that is used to lock coins and vote. It does not matter how you implement the idea around Voternodes you end up implementing a political class; a group that will attract those looking for changes that benefits their world view. When doing so it is important to add systems that holds the members of that group accountable and that it is possible to take away the benefits granted to them by the network.
Voting Tiers
When implemented as above it seems a balanced three tiered system is possible, that said I’m still not convinced it is wise to split them into three separate voting groups that all require a majority. Things beneficial to the network and Masternodes might be voted down by Stakingnodes and visa versa, the argument could be made that every proposal has to benefit ‘all’ but I’m not convinced that this is always feasible. Again this is just opinion, but all or nothing feels unbalanced to me; that and taking over one group is all that is needed to cripple the system.
Because of the role, Voternodes get assigned to them it seems logical to take some of the load from Masternodes and Stakingnodes by using the Voternodes as a filter. In that case, a proposal would require support from one or more Voternodes before it enters the network and then it would have to be passed by the majority of Voternodes before it is passed on to Masternodes and Stakingnodes for them to cast a vote.
The main goal of this would be to reduce voter apathy by reducing the work required of the two groups that contain people less interested the governance; on the other side, it requires people submitting a proposal to interact with the more active group that needs to keep its reputation up.
Voting Privacy
By tokenizing the voting weights it becomes possible to implement privacy in the voting systems. At the end of the month, libzerocoin is utilized to create a pool of tokens that are spent when the owner of the tokens casts his votes on the proposals available in that month.
Understanding the current system, a vote is created by signing a message with a private key, this means the person voting can prove he voted in a specific way and when the key is compromised it becomes possible to see how the owner of a key voted in the past.
The main issue with this is that voters can prove they voted in a specific way, this turns the vote into a commodity that can be sold and can result in corruption. A lesser issue, on failure to protect the voting key public pressure and fear of retaliation, could prevent people from voting against their peers even when they believe the proposal to be flawed.
Note: This has the down side that votes can no longer be changed and that the end user needs to vote on all proposals in a single network broadcast.
Voting Delegates
For delegation support on to Voternodes by both Masternodes and Stakingnodes could be used in reverse; meaning that when a supporter of a Voternode does not manually submit it’s vote his vote will follow that of the Voternode they support. When doing so it might be wise to implement strong and weak votes (-2, -1, 0, +1, +2) to balance things out again; where a delegated vote in the Masternodes or Stakingnodes group becomes a weak vote and nodes that do explicitly vote do so with a strong vote.
Closing
While this system is not perfect it forms a solid base to build on and requires minimal change to the core of the network. ‘The identity keys’ could be linked to other identifying info when this becomes desirable and ‘Voting Weights’ could be earned in different ways. Nothing here is set in stone … but a foundation is created.
history: https://gist.github.com/Nitya-Sattva/4d06e55d6b924661bb978af2022b4272