SPK Network - SPK Governance

SPK DPoS

It's day 2 of blog every day November. I've decided to power up all my posts so I can participate in PowerUpMonth as well. Anyway, on to the things that occupy both my days and dreams...

Around HIVE we often shout about the benefits of Delegated Proof of Stake (DPoS). The SPK Network is built on top of a DPoS chain and will retain as much of the spirit of this paradigm as these conditions allow. The most pressing limitation is we can't as easily force a super majority of participants to have a collectively desired outcome. For example, with 20 accounts controlling a multi-signature wallet, we don't have many options about how the signatures will be arranged. If we set the multi-sig threshold at 17 then it only takes 4 accounts to hold the funds hostage. Which means our multi-signature has to do one of two things. Either set account weights based on stake, or rely on a simple majority to come to a decision.

I prefer keeping the signature holders as even as possible in terms of reward shares and voting rights. Though I would be interested in seeing the competing paradigm play out.

Setting the variables of the overall chain will come down to holders of SPK who have powered up their tokens. In the Hive paradigm you vote for your witnesses, you get 30 votes for 20 spots, and you give up your ability to vote on the price feed, account creation fee, software version, etc... In the proposed SPK paradigm you will retain the ability to vote on every item of governance.

Adding a little balance to this system, the more interested you are in the service layer of SPK (storage, encoding, etc) the more you earn in SPK tokens and the more SPK tokens these service providers earn as well. Distributing the governance at a faster rate than interest only paradigms. Hive uses this style of metric as well in the 50 - 50% split for content moderation.

Design Considerations

One of the strengths of a state machine instead of a traditional block chain is it can have a smaller memory footprint. Utilizing the storage inherent in Hive the SPK network can allow voting that doesn't keep a record of actual votes for every account. Rapid replays and low costs are both preferable to storing a set of votes for every account the holds SPK Power.

In practice this is accomplished by 2 things. Every vote needs to have every parameter one wishes to change. As voting will always be "open" the dynamics of the system must allow for variables to move freely. When somebody votes their power amount will be subtracted from the total power amount. Say 10 out of 100. The current variables will then have a 90 to 10 bias when a new average is determined.

(10% * User_with_10%_stake_Variable_Vote) + (90% * Variable_currently) = Variable_new_value

To prevent one account from voting over and over to push variables toward a goal, the last vote time will be recorded. This will effectively allow only one full sized vote per voting period.

So if the same account votes in the very next block their effective power will be ~0 and the averages bias will be ~100.

This paradigm also has the added benefit of keeping variables in a more steady state condition which should encourage platform utilization.

One further consideration is allowing the cool-down period for several account to reset then making a full sized votes with more accounts. For this reason there is an additional decay parameter to normalize disinterested voters from having a bigger impact when they decide to vote again. For instance, if the cool-down period is 3 months. from 3 months to 6 months the vote power will decrease from 100% to 50%. This will also apply to stake that is newly powered up to prevent certain kinds of governance attacks we've seen in the past.

The Near Future

One thing that we worry about is voting apathy, the knowledge of the voters, over-weighted influence, etc... Basically all of the things that any voting paradigm suffers from. Hive has quite a robust system to equalize the top 20 which provides some answer to most of these concerns.

The SPK Network will have a set of "Validators" that need to manage content in it's contracts. These will be voted in to a consensus group. They will likely be some of the biggest accounts in the network, but will also likely have a large discrepancy in actual stake.

We will keep track of voting apathy by keeping a running sum of votes over the decay period, then distributing those votes (and in practice the stake held by the top 20) equally among those same accounts. So if we have 50% of stake interested in governance, the top 20 will each have a 2.5% vote weight(The other 50% divided by 20). This should cover, knowledge, equality, apathy, and some democracy/republic questions, as any voter who abstains will instantly be proxied evenly among those most knowledgeable.

Votable Variables

Here are the parameters the SPK votes are currently planned to control:

SPK Power Down Interval / Voting Decay

To maintain system security votes will not be allowed to happen more often from different accounts by powering down from one account and powering up to another. To protect from this vector the Power Down Interval is also the voting decay interval. Presently the power-down time is set to 800000 blocks, which is roughly 4 weeks. I personally would like to see this time increase to roughly 3-4 months. Making the voting cycle a quarterly concern much like traditional corporate bookkeeping cycles. Allowing trends to be analyzed over time and governance strategies to be put forth by members.

LARYNX Power Down Interval

As this number isn't tied to security a separate time can be used. Something long enough to discourage abuse to the service platform, and short enough to encourage people to power up Larynx and obtain services.

Number of Runners

Hive has a currently limit of 40 keys per account. This sets a hard limit of 79 runners under the current paradigm of giving partial authority to the runners that are most collateralized than simple median (80/2 + 1 > 40). It is currently set to 25 which provides up to 13 key holders. The larger this number is the more secure each wallet is, the irreversibly of blocks, The actual parameter is variable between 25 and 79, while votes are possible from 10 to 94 to allow a little acceleration toward the limit that will prevent 79 or 25 from being reached.

SPK Generation Rates

These are where SPK comes from. There are three different rates currently 0.1%, 0.015% and 0.01% for LARYNX powered up by a infrastructure provider; delegated to an infrastructure provider(both the delegatee and delegator enjoy this rate), and the lowest for somebody who has powered up their LARYNX but hasn't put it to purpose. These rates will have floating Limits.. 0 to the middle rate, 1 to 5 times the lowest rate, and 2 to 5 times the middle rate. These limits will keep the game theory of operating services balanced. I would also like to see a BROCA rebate for delegators to incentive both good services and lower prices, but these aspects will be outside of consensus. More information

DEX Parameters

These include the fee percent, slope, and max values discussed here

DAO Claim Percent

Also discussed here

Future Parameters

Once the Airdrop is over the Service Infrastructure Pools com into play. This is when the SPK network will start moving capital toward goals. This means a whole new set of parameters to control. What the SIP splits it's funds into, how the DAO is utilized, the inflation rate that will best balance capital inflows. etc.

Inviting Discussion

We're doing something new and we welcome any and all feedback to build a better system. Transparent development, funding, and discussion remains our highest priorities. Please comment below and tell us how we can improve, what you like and don't like, or anything else. Thanks for the support and reading this.