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