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.
The rewards earned on this comment will go directly to the people( @tanzil2024 ) sharing the post on Twitter as long as they are registered with @poshtoken. Sign up at https://hiveposh.com.
Very innovative. Looking forward to this and accumulating SPK.
Voting apathy is a concern around the globe in every voting-based system ever created. The free market solution would be to add a sufficient incentive to it, but in this particular space it would just create a market for vote selling, wonder where we've seen that before :D
Maybe consider achievements like badges for participation in voting activities, that would create a history of participation, and Proof Of History is an essential part of the Proof of Existence as entities of the www as it is today.
With this kind of voting I think most people will be OK with something until they aren't and will see some votes that only hit one variable for all the way high or all the way low. I definitely would like to see some kind of the above mentioned items for the top 20 voting.
This was very informative and this is a great and a beautiful advanced network, Very inspiring.
If those 4 accounts act against the wishes of the stakeholder majority, they will be immediately voted out.
What bothers me most about the state machine you are proposing, which differs from a blockchain, is that it doesn't seem to have all the robust security of a blockchain. For sure, it uses less computer resources, because it doesn't have all the cryptographic chain that locks in each transaction and prevents attacks. With a state machine, who knows what attacks will be possible. It's a long road to create a foundational technology that does what a blockchain does - it has to be mathematically worked out, carefully reviewed by many eyes, battle-tested over years, before relying on that technology to handle large amounts of funds.
I deeply care about the SPK network and really look forward to it. The technology it is built on has paramount importance for the success of the whole project. Do we want to let our SPK network rely on a new and unproven L2 technology?
If the threshold was 17/20... nope, 16 couldn't vote out 4 ever.
I guess you don't know that this "state machine" has a consensus mechanism, is older than SushiSwap(with pieces older than HiveEngine), and has had over 100 operators. As a layer 2 it doesn't need to order transactions, but it still has other aspects of a blockchain. Forgetting all of the the solution must live on Hive because the DHF is paying us to build it to make hive a better place.
I mean that all the people who stake the governance token can vote out any rogue validators.
I didn't mean to devalue what you have created, sorry if it sounded like that. If it works with a sufficient level of robustness against the various kinds of attacks, and does what is needed for the SPK network, then that would be a terrific innovation you have created.
Agreed, and that's the general idea... have a few layers to the governance structure to mitigate the limitations of multi-signature accounts.
Congratulations @disregardfiat! Your post has been a top performer on the Hive blockchain and you have been rewarded with the following badge:
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPCheck out the last post from @hivebuzz:
@disregardfiat! The Hive.Pizza team manually upvoted your post.
Learn more at https://hive.pizza!