Don't forget we start tomorrow UTC (GMT) Monday, November 7, 2016 at 19:00:00
ARK is built to utilize a consensus mechanism known as Delegated Proof of Stake (DPoS). While DPoS has been around for quite some time, it has not received the same level of exposure as Proof of Work (PoW) and Proof of Stake (PoS), so we would like to take this opportunity to go over how the delegate system works, some changes we have made to the voting weight calculation, as well as some additional developments that we would like to highlight that show where our thought process is at in regards to delegation and forging.
DPoS made it’s debut back around 2014 in the Bitshares network. It was created by a group of developers led by Daniel Larimer (you may know him as the co-founder of Steemit - @dantheman ). Since the launch of the Bitshares network, there have been several offshoots of the original DPoS consensus model, predominantly Crypti-DPoS, which was later adopted by Lisk and is the same model that will be at the core of the ARK network.
When thinking about DPoS as a consensus model, it has several major differences when compared to traditional PoW and PoS models. Think of DPoS as a representative democracy wherein individual users utilize their stakes in order to nominate delegates to serve on their behalf. These delegates are then responsible for validating transactions and securing the ARK network. In this representative based system, the delegates are awarded transaction fees and in some instances, such as ARK, inflationary tokens in order to cover operating costs and secure their vested interest in the productivity and safety of the network. Should they perform their duties poorly, or use their authority in a manner not representing the will of the voters, votes may be rescinded and assigned to a new representative, thus ensuring the security of the network.
For the ARK DPoS model, we have made several changes to the core mechanics. One change is the number of users able to be elected to the active delegation. In Crypti-DPoS and in the original Bitshares network, that number of active delegates is 101. In order to maximize efficiency in the network and to continue to offer cutting edge block times and throughput, we will begin with testing a selection of 51 delegates. This lower level of delegates, coupled with our routing system and several other core improvements to the way the network communicates, have allowed our team to achieve a stable network at a block time of 8 seconds in testing, and eventually achieve blocks as fast as 5 seconds with additional optimizations. While these numbers are still being vetted, we may initially launch with 10 second block times to ensure stability, with a major goal of the project being significantly reduced block times moving forward.
One area where we saw room for improvement over the Crypti-DPoS model was in the way in which voting weight was tallied. In Crypti-DPoS and Lisk, voting works in the following manner:
- User Alex has 100 tokens.
- Alex can vote for 101 Delegates with a weight of 100 tokens assigned to each vote.
- 100 Tokens is a small amount so Alex has very little influence.
- User Kevin has 20 Million tokens and nominates himself to all 101 delegate slots.
- Kevin is a bad whale.
In the above scenario, the security of the network is only as strong as the ability of a single member to outweigh the current voting weight of the top delegates. If the highest delegate voting weight is 8%, then a user would only need to obtain 8.01% voting weight in order to displace the entire delegation. Traditionally, the argument against this has been that obtaining this amount of voting weight would be largely expensive and that a user having just spent a large sum of money on amassing tokens would not want to devalue those tokens by attacking or compromising the network.
From our perspective, we want to minimize that possibility as much as possible while putting more influence back in the hands of the users. That is why we have completely re-written the way in which votes are tallied within our version of DPoS. The following is an example of how voting works in ARK DPoS:
- User Alex has 100 tokens.
- Alex can vote for 1 delegate with a weight of 100 tokens assigned to that delegate.
- Alex can also choose to vote for 2 delegates, but each delegate would then only receive 50% of his voting weight.
- As Alex continues to vote for additional delegates, he reduces the weight he contributes to each of the delegates proportional to the number of votes cast.
- User Kevin has 20 million tokens. Kevin can nominate his delegate fairly easily. He may even be able to vote in 2 of his own delegates, but rightfully so, he purchased 20 Million tokens. What he can’t do is be guaranteed to nominate more than 8 delegates before his weight is too diluted to maintain his position.
- Kevin is a contained whale.
This is a much more reasonable manner in which to count votes and maintain the security of the network. By altering the voting mechanism and weight calculations, we have substantially increased the cost of a hostile takeover and reduced the window for an attack to occur.
One additional benefit of the new voting scheme is that it allows even smaller accounts to have influence in the voting system. As every single token casts only 1 vote, every token counts when it comes to being an active delegate. This creates the perfect environment for profit-sharing pools to form. The members of the ARK Crew not only wholly support this idea, but would like to take it one step further.
The ARK Crew will be releasing an official and fully supported open-source profit-sharing script that any potential delegate may download and run as part of their proposal for their delegate votes. The parameters for profit-sharing will be negotiable and will play a large part in whether or not a specific user receives votes from the community. Users will be able to determine a % of overhead to go to the pool owner with the rest being distributed to those granting votes to the delegate pool. There will be several different options for how the pool may calculate each individual user’s voting contribution over time and we will provide more details as we get closer to releasing the script.
Our profit-sharing pool system will feature a web interface and administration module and will be available the same day as our main-net launch. We will provide a beta version for testing purposes prior to the launch and hope you will help us test for any bugs when the time comes.
There are a plethora of other options for obtaining votes for your delegate. An exciting new type of crowdfund is to run a delegate with the intention of funding development of projects having their own bridged chains and tokens, with voters receiving an equity stake in those projects in return for their votes. Another way to attract votes is to offer community services on bridged chains for applications which are otherwise unprofitable, but people need. There are numerous services on the internet which people are used to receiving for free, but severely compromise privacy. These can be replaced with secure, private, and free services operated solely in the interest of the users, funded by Ark delegates.
The ARK Token Exchange Campaign (TEC) will begin on November 7th, 2016 at 19:00 GMT, and it looks to have already garnered substantial interest. Don’t miss out on your chance to join the movement and help shape the future. We feel our DPoS system features significant upgrades that make for a more equitable and secure network and we need people like you to step up and form the delegation. Remember that every ARK votes and every vote counts.
Thank you for your support and interest in ARK and stay tuned for more details about our network and TEC launch in the coming day!
Website: https://ark.io
Token Exchange Site: https://tec.ark.io
Starting Dates:
New York (USA — New York) Monday, November 7, 2016 at 2:00:00 PM EST UTC-5 hours
San Jose (USA — California) Monday, November 7, 2016 at 11:00:00 AM PST UTC-8 hours
Corresponding UTC (GMT) Monday, November 7, 2016 at 19:00:00
The algorithm you propose was heavily debated in the early days prior to BitShares 1.0 launching. I was originally supportive of the algorithm you laid out, but use Agent86 on bitsharestalk.org convinced me that approval voting was vastly supperior from a security perspective.
Under your model someone with 8% can guarantee they get one person in. Under DPOS it is highly unlikely that someone with 8% could get into the top on their own. In Steem the top witnesses have between 19% and 23% approval. That is more than any individual account except the steemit account which isn't voting.
If you adopt the 1 share 1 vote approach then the top 19 witnesses would each have only about 1% approval. With 51 slots they would each have less than 0.5%. It gets worse because the popular ones will end up with 2-3% while the less popular ones will end up with 0.1%.
In this environment, someone with 8% of the stake can come along and vote for 16 people with 0.5%. To make it apples-to-apples, someone with 20% of the stake would end up controlling over 51% of the active witnesses because they would each get 1% or more approval which would be more than the vast majority would ever get.
Good luck with your system. I am always happy to see new uses of DPOS. I am just sad to see backward steps that fail to incorporate the lessons learned.
Hey Dan ( @dantheman ).
Thanks for the response. We highly value your opinion! Our team has had extensive discussion about exactly what you describe, and the efficacy of both models, along with extensive experience with using the existing DPoS voting in practice, as well as how it can be gamed. We are inclined to think you were not wrong in your initial support for a voting system similar to our model. We would love to discuss it in more detail. We see this approach as a move sideways into testing a counter hypothesis, and would love feedback much like the above as we move forward into testing.
We are currently less than 24 hours from the start of our Token Exchange Campaign, so a more in depth response will have to come later, but we would love to reach out if you have a method that we could use to get in touch, or if you want to get in touch with us, you can contact our MD via ManagingDirector@ark.io .
Thanks again for taking the time to respond, we know you are a very busy man!
Regards,
The Ark Team
upvoted! I'll check this out tomorrow!
interesting. well explained.
thank you
Always great to hear about project experiencing DPoS. Seems that DPoS Consensus algorithm is best suited to build consumer products/services.
Wish the Ark team best success
This post has been linked to from another place on Steem.
Learn more about and upvote to support linkback bot v0.5. Flag this comment if you don't want the bot to continue posting linkbacks for your posts.
Built by @ontofractal