Lucky for you I have been working on just such a paper... here is a preview of the motivation for this:
Under DPOS 1.0 the stakeholders would select 101 delegates by approval voting. These delegates would take turns producing blocks every 10 seconds. Each delegate would get to set their own pay rate as a percent of the maximum. Decisions about which fees to charge and hard-forks to adopt rested in the hands of delegates which acted individually.
This system worked reasonably well but over time some serious issues became apparent. Some of these issues include:
Requiring stakeholders to select 101 delegates may be too much leading to most stakeholders voting for less than 101 or not carefully vetting the delegates they chose.
Forcing all “employees” to run servers to get paid significantly complicated the hiring of people without those skills.
There was no way to come to a consensus on what the fee structure should be.
With a total budget of $50,000 per month of new issuance, each individual delegate had a maximum budget of $500 per month which is not enough to get someone’s full time attention. It was politically unpopular to give one individual multiple delegate positions for fear of centralization.
Delegates have too much control in a single position that opens them up to unnecessary legal liability.
DPOS 2.0 Overview
Under DPOS 2.0 the roles of delegates have been divided into 3 categories:
Witness - produces blocks and is paid a percentage of transaction fees.
Worker - is paid a fixed number of tokens per day to perform a task
Delegate - co-signer on a dynamic multi-sig account with permissions to change blockchain parameters.
Each of these roles is filled by approval voting. The number of Witnesses and Delegates is directly voted upon by the stakeholders. Each stakeholder must vote for at least as many Witnesses and Delegates as they believe the system should have. The number of witnesses/delegates is defined such that at least 50% of voting shareholders believe there is sufficient decentralization. The number of workers is determined by how many workers the available daily budget will cover when paid out to workers from most approved to least approved.
Delegates
The delegates have multi-sig control over a special account dubbed the “genesis account”. This multi-sig account can do anything any other account can do with a 2 week delay. If enough delegates are voted out within two weeks of jointly approving a transaction then the transaction will fail to go through.
The “genesis account” has the unique privilege of changing critical parameters such as: Block Interval, Block Size, Witness Pay Rate, Burn Rate, and even the review period for their own transactions.
Delegates are not paid positions and are therefore honorary and held by individuals who have a vested interest negotiating changes to the network parameters.
Legally the delegates have no direct power other than to propose changes for the stakeholders to reject. This means delegate positions are safe from regulation and power truly rests in the hands of the stakeholders.
Unlike DPOS 1.0 where each delegate operates independently, under DPOS 2.0 delegates are forced to reach consensus directly before any change can be proposed.
That certainly defined the roles and their functions, but many other questions remain unanswered. I look forward to your paper and the answers to the questions it will hopefully provide.
Are all delegates required to sign off on the multi-sig account to change anything?
My first impression is DPoS 2.0 sounds better and more formal / mature than DPoS 1.0 and I like it. I am somewhat skeptical about whether the delegate pool (will there be a limit on the number of delegates?) can reach unanimous decisions to satisfy the multi-sig, but the concept seems quite sound.
PS - a minor nit: I don't care for the "witness" label either. Producer, verifier, certify-er, or even "blockhead" seem better, but hey - it's a subjective call, and I can live with it if necessary.