Author Topic: Improving DPOS  (Read 1877 times)

0 Members and 1 Guest are viewing this topic.

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
Quote
Don't ever force voting on people.  We already have certain problems. The way to fix voter apathy would make the default be "vote as delegates recommend" but never force voting on anyone.  It will totally kill faith in the project.
Isn't this (vote as delegates recommend) what I suggested?

Quote
The problem is that you are increasing the fee for what is largely an unknown outcome. This fee is already an issue. The higher the burden the more difficult it is to get talented people to work from the blockchain.  This compounds the problem.
I agree with this. It is a trade off.

Quote
I think these interests are functionally equivalent and you will still have the problem of finding large stake-holders who want to be delegates.
Right. This also is a trade off. More direct / material incentives vs. reducing the number of people that could do the job well.

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
Quote
A concern with slate voting (RDPOS): If I vote for 4 slates and all of these slates have delegate XY on their slate. Then XY turns out to be evil or unreliable and 3 of the 4 delegates I approved take XY of their slate then I still fully approve XY. Any solutions to that?

That's what the thumbs down / disapprove feature does, it doesn't vote for them even if he is recommended.

But that still requires intervention by the shareholder. If there is an unreliable or evil delegate or a non working 100% pay delegate that delegate could be kicked out fast if my vote follows what my trusted slates do but that would not work if even one slate keeps on approving the bad delegate. ..So I should have said first that my assumption was that it would be desirable to have a fast reaction time realized by updating my vote as my trusted slates change it.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
What about a mixed system: Delegates have to put up a tendermint like (http://tendermint.com/docs/tendermint.pdf) collateral which is destroyed when someone signs a block on more than one chain. Either the Top 100 security delegates would have to all put up the same collateral hard coded into the client or the amount of collateral could be a factor besides shareholder approval (effect could be capped for example at 500% above average collateral among the top 101 delegates).
That would probably only work at scale when the competition among delegates is higher.

The problem is that you are increasing the fee for what is largely an unknown outcome. This fee is already an issue. The higher the burden the more difficult it is to get talented people to work from the blockchain.  This compounds the problem.

The overall idea is to rely on different consensus mechanisms to increase the overall network resilience.

An idea I like better than the above because it suffers less from what Bytemaster criticizes in his blog about non delegated POS: Among the 101 delegates could be 10 that are not determined by shareholder approval but by stake size. Because it are 10 fixed positions that all get the same returns from their position the problem described in BM's post about the centralization of POS doesn't apply. The problem here would be instead that 10 stakeholders with considerable stake would have to be found that are also able to run a delegate. 
The advantage would be that every 100 seconds there was someone producing a block that had a direct material interest in the security of the network as compared to delegates who may "only" have an interest in keeping up their reputation and being reelected.
I think these interests are functionally equivalent and you will still have the problem of finding large stake-holders who want to be delegates.

Variation: Instead of stake being the determining factor for selecting the 10 positions height of collateral (tendermint idea) could be considered. Not sure how this would play out.
I asked a few questions on the tendermint forum (based on the concerns that lead to DPOS) http://forum.tendermint.com/t/questions-on-tendermint/42/2

Regarding voter apathy: Assuming voter apathy is the biggest challenge in DPOS wouldn't it be worth it to make "vote as delegates recommend"[1] the only option? Disadvantage: Reduction (not loss) of anyway incomplete privacy. Logic: Network security comes first and has to work, otherwise the whole system including advancements in privacy aren't worth anything. The gains of individuals (privacy) shouldn't harm everyone (security).

Don't ever force voting on people.  We already have certain problems. The way to fix voter apathy would make the default be "vote as delegates recommend" but never force voting on anyone.  It will totally kill faith in the project.


My comments in bold.  Don't take them as a belief that any of your ideas are bad, I'm just giving criticism off the top of my head.
I speak for myself and only myself.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Quote
A concern with slate voting (RDPOS): If I vote for 4 slates and all of these slates have delegate XY on their slate. Then XY turns out to be evil or unreliable and 3 of the 4 delegates I approved take XY of their slate then I still fully approve XY. Any solutions to that?

That's what the thumbs down / disapprove feature does, it doesn't vote for them even if he is recommended.
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
What about a mixed system: Delegates have to put up a tendermint like (http://tendermint.com/docs/tendermint.pdf) collateral which is destroyed when someone signs a block on more than one chain. Either the Top 100 security delegates would have to all put up the same collateral hard coded into the client or the amount of collateral could be a factor besides shareholder approval (effect could be capped for example at 500% above average collateral among the top 101 delegates).
That would probably only work at scale when the competition among delegates is higher.

The overall idea is to rely on different consensus mechanisms to increase the overall network resilience.

An idea I like better than the above because it suffers less from what Bytemaster criticizes in his blog about non delegated POS: Among the 101 delegates could be 10 that are not determined by shareholder approval but by stake size. Because it are 10 fixed positions that all get the same returns from their position the problem described in BM's post about the centralization of POS doesn't apply. The problem here would be instead that 10 stakeholders with considerable stake would have to be found that are also able to run a delegate. 
The advantage would be that every 100 seconds there was someone producing a block that had a direct material interest in the security of the network as compared to delegates who may "only" have an interest in keeping up their reputation and being reelected.

Variation: Instead of stake being the determining factor for selecting the 10 positions height of collateral (tendermint idea) could be considered. Not sure how this would play out.
I asked a few questions on the tendermint forum (based on the concerns that lead to DPOS) http://forum.tendermint.com/t/questions-on-tendermint/42/2

Regarding voter apathy: Assuming voter apathy is the biggest challenge in DPOS wouldn't it be worth it to make "vote as delegates recommend"[1] the only option? Disadvantage: Reduction (not loss) of anyway incomplete privacy. Logic: Network security comes first and has to work, otherwise the whole system including advancements in privacy aren't worth anything. The gains of individuals (privacy) shouldn't harm everyone (security).

Additional suggestion: If one of the 10 delegates changes their recommendations / slate then my vote should change too otherwise slates can not react fast and vote an evil / unreliable delegate out.
Alternative: Every week my client performs a transaction of my whole stake to myself so to confirm that I still vote as the slates I approved.

A concern with slate voting (RDPOS): If I vote for 4 slates and all of these slates have delegate XY on their slate. Then XY turns out to be evil or unreliable and 3 of the 4 delegates I approved take XY of their slate then I still fully approve XY. Any solutions to that?

[1] I assume "vote as delegates recommend" works like this: You vote say for 50 delegates. If 10 of them have a slate with other delegates they recommend, then you vote for these 10 plus all their recommended delegates. Plus you vote for the 40 delegates that do not have a slate. Maybe this: If more than 50% of the slates I approve actively disapprove (downvote button) delegate xy than my overall vote is negative for delegate xy is negative.
« Last Edit: January 08, 2015, 04:40:12 pm by delulo »