Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Adjustments to delegate pay  (Read 488 times)

0 Members and 1 Guest are viewing this topic.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Adjustments to delegate pay
« on: April 10, 2015, 01:53:23 AM »

I really think we need improvements to the way we pay delegates and workers. Here is my latest suggestion to get a little closer to the ideal system by making minimal changes.

First, instead of each delegate candidate only having a single pay rate, they would have the following:
  • Percentage budget for worker distribution
  • Budget limit for self-pay
  • Salary

The percentage budget for worker distribution (PBWD) would be a percentage between 0 and 100% (just like the current delegate pay rate) and budget limit for self-pay (BLSP) would be a BTS amount. The actual budget for worker distribution (BWD) for an active delegate, which is in units of BTS, would be calculated by multiplying the delegate's PBWD and the per-delegate BTS allocated for that round (this is the per-block inflation limit as of that round plus any per-delegate fees allocated for distribution in that round). Another important quantity, budget for self-pay (BSP), is defined for each delegate as min(BWD, BLSP). The registration fee for a delegate is based on the BLSP value, not the PBWD value. After registering the delegate, the delegate can not increase the values for PBWD or BLSP, but they can change the Salary however they wish at any time. The PBWD and BLSP can be decreased at any time, however the change to these values do not go into effect until the end of the round.

The salary of a delegate would specify a particular BitAsset type (or alternatively BTS) and provide a quantity in that BitAsset. The idea behind the salary is that the blockchain will multiply the quantity with the latest price feed for the corresponding BitAsset to get an estimated salary per round in BTS units. If that number is larger than the BSP quantity, then the salary will be limited to the BSP quantity. The actual salary (SAL) in BTS units to transfer to the delegate is calculated at the beginning of the round using the latest price feeds at the beginning of the round. If there are no recent price feeds at the beginning of the round for the specified BitAsset, that delegate will simply not be paid in that round.

At the end of the round, the total salary (TOTAL_DELEGATE_SALARY) distributed to delegates that produced blocks is calculated (TOTAL_DELEGATE_SALARY = sum of the SAL for each delegate that produced a block in that round) and the sum of each active delegates' BWD (TOTAL_AVAILABLE_BUDGET) is also calculated. The difference TOTAL_AVAILABLE_BUDGET - TOTAL_DELEGATE_SALARY gives the remaining worker budget (WB). Then, the WB is distributed according to the "worker pay list" as of the end of that round.

The "worker pay list" is a list of the PAY item which is a tuple (BITASSET_QUANTITY, BITASSET_TYPE, ACCOUNT_ID) or the LIMIT item which only has one value BTS_LIMIT_QUANTITY. Similar to delegate pay, the BITASSET_QUANTITY and BITASSET_TYPE together define the pay amount and are converted into the appropriate amount of BTS using the latest price feeds at the time (this time being at the end of the round). So you can think of this process as mapping the list [A] to list [c] with a function f : a -> c which maps PAY (BITASSET_QUANTITY, BITASSET_TYPE, ACCOUNT_ID) to PAY' (BTS_QUANTITY, ACCOUNT_ID) and maps LIMIT (BTS_LIMIT_QUANTITY) to itself. Again, if there is no recent price feed for the specified BITASSET_TYPE of an item, then the BTS_QUANTITY of the mapped tuple of that item is simply set to zero. At the end of the round, the blockchain goes in order through this second list (the [c] list) and if the item is the PAY' type, it pays BTS_QUANTITY to the specified ACCOUNT_ID as long as there is enough value in the WB, which is updated (WB := WB - BTS_QUANTITY) as it goes through the list, and if the item is the LIMIT type it burns (WB - BTS_LIMIT_QUANTITY) amount of BTS (assuming that it is a positive number) and sets WB := min(WB, BTS_LIMIT_QUANTITY) before proceeding with the rest of the list. If it reaches an item in the list where the BTS_QUANTITY exceeds the updated WB at that point, it will simply send WB amount of BTS to the ACCOUNT_ID and stop processing the rest of the list.

The "worker pay list" allows the blockchain to prioritize who to pay when money is tight. A typical set up would be to have multiple rounds of worker pay in the list. For example, if there were 3 workers (A, B, C), one possible "worker pay list" might be the following:
  • LIMIT (3500)
  • PAY (3, BitUSD, A)
  • PAY (1, BitUSD, B)
  • PAY (6, BitCNY, C)
  • PAY (1, BitUSD, A)
  • PAY (1, BitUSD, B)
  • PAY (6, BitCNY, C)
  • PAY (1, BitUSD, B)
  • PAY (6, BitCNY, C)
  • PAY (1, BitUSD, B)
So with the above list, if there is enough money to pay the entire list, both A and B would receive 4 USD worth of BTS per round (approximately $125,000 per year) and C would receive 18 CNY worth of BTS per round (approximately $90,000 per year). But let's pretend that money got tight (the price of BTS went down for example) and the DAC would only afford to pay up and including the 6th item of the list fully, the 7th item only partially, and the rest couldn't be paid at all. Let's say approximately $7.25 worth of BTS was available in the worker budget for each round (and let's assume that amount worked out to less than 3500 BTS). In that case, A would get the full 4 USD worth of BTS per round, B would only get half their normal pay or 2 USD worth of BTS per round, and C would perhaps get approximately 7.5 CNY worth of BTS per round. Also the LIMIT could further limit how much each worker gets paid. If the price of BTS were to drop to $0.003/BTS and the WB was 4800 BTS at the very beginning of the list, then if the LIMIT item wasn't there there would be enough BTS in the budget to fully pay the three works (only 4000 BTS would be needed in WB). However, with the LIMIT item at the top of the list, the 10th item would only receive partial pay.

Finally, there needs to be a way to update the "worker pay list" (which is initially set to the empty list). Any active delegate can submit a proposal for a change to the "worker pay list" and they can cancel their submission at any time. If they submit a new proposal when they already have a pending submission, the old proposal will be cancelled and replaced by the new proposal. Each active delegate is also allowed to submit a vote for any delegate's proposal (by submitting their delegate ID) but the vote only counts if it is for a currently active delegate who currently has submitted a proposal. Again, they can cancel this vote at any time and submitting a new vote automatically cancels any previous vote. Also, if the delegate they are voting for cancels their proposal (or it is automatically cancelled by submitting a new proposal), all of the delegate votes voting for that proposal also automatically cancel. If enough active delegates (let's say >=76) vote for the same delegate proposal, that proposal will become ratified. When this happens, the proposed changes from the ratified proposal update the "worker pay list", then the proposal submission is automatically cancelled and all of the active delegate vote submissions are also cancelled.

These proposals consist of a sequence of operations. There are four types of operations: ADD_ITEM, MODIFY_ITEM, REMOVE_ITEM, and REMOVE_ALL. The REMOVE_ALL operation removes all of the items in the current "worker pay list". The ADD_ITEM, MODIFY_ITEM, and REMOVE_ITEM operations require a non-negative integer which specifies the zero-based index of an existing item (and the integer equal to the number of items in the list is also acceptable for the ADD_ITEM operation). REMOVE_ITEM simply removes the item specified by the index from the list (shifting all items coming after it up to close the gap). ADD_ITEM adds an item immediately before the item specified by the index to the list (shifting it and all items coming after it down to make room) or it just adds the item to index 0 if the list was empty. MODIFY_ITEM does not add or remove items but rather simply modifies the values for the item specified by the index. ADD_ITEM and MODIFY_ITEM operations obviously need an additional argument to define the new values of the item which can either be just a BTS_LIMIT_QUANTITY for a LIMIT item or the tuple (BITASSET_QUANTITY, BITASSET_TYPE, ACCOUNT_ID) for a PAY item.

So with the above setup, it would take a super majority of the delegates to make changes to worker pay and even then they could not inflate BTS in each round by more than TOTAL_AVAILABLE_BUDGET which is simply the sum of each active delegate's BWD (which cannot exceed the BWD they were elected with). Also, there is still the hard-coded dilution limits that guarantee that TOTAL_AVAILABLE_BUDGET <= 101 * (hard-coded per-block inflation limit). The idea is that the delegates will listen to the shareholders through future non-binding proposals and make the appropriate changes that the shareholders want. Until the appropriate tools for non-binding proposals are available in the client, the delegates should just do what they think is best for BitShares.

The delegates can still get paid individually even if a super majority is never able to agree to any "worker pay list" so there is no new added risk of delegates not getting paid with this system. The delegates get the convenience of specifying their pay in USD (or other BitAssets), even though they are still actually paid in BTS, which means they do not need to manually burn excess BTS to get paid their fair salary (the blockchain will automatically do it for them). The delegates just need to make sure that the BSP they are elected with is high enough to give them their desired USD salary even as BTS price changes. And if BTS price drops so low that they cannot get their desired USD salary due to BSP limit, they are simply forced to deal with the lower pay as they are now (or maybe they can get a new delegate voted in with a higher BSP).
« Last Edit: April 10, 2015, 03:57:31 AM by arhag »

Offline carpet ride

  • Hero Member
  • *****
  • Posts: 544
    • View Profile
Re: Adjustments to delegate pay
« Reply #1 on: April 10, 2015, 02:15:09 AM »
We gotta get you to Blacksburg...


Sent from my iPhone using Tapatalk
All opinions are my own. Anything said on this forum does not constitute an intent to create a legal obligation between myself and anyone else.
Check out my blog: http://CertainAssets.com
Buy the ticket, take the ride.

Offline robrigo

Re: Adjustments to delegate pay
« Reply #2 on: April 24, 2015, 02:06:22 PM »
We gotta get you to Blacksburg...


Sent from my iPhone using Tapatalk

 +5% arhag for core dev!  8)
« Last Edit: April 24, 2015, 02:32:22 PM by robrigo »

Offline ripplexiaoshan

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 2027
    • View Profile
  • BTS: xiaoshan
Re: Adjustments to delegate pay
« Reply #3 on: April 24, 2015, 02:23:52 PM »
DPOS system definitely needs to be improved. +5%
BTS ID:xiaoshan

Offline cass

  • Hero Member
  • *****
  • Posts: 4328
  • /(┬.┬)\
    • View Profile
Re: Adjustments to delegate pay
« Reply #4 on: April 24, 2015, 03:47:15 PM »
great idea, great thinking (as always :) ) !  +5%

█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

 

Google+