Skip to content

Instantly share code, notes, and snippets.

@cc32d9
Last active December 12, 2021 05:25
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save cc32d9/a823d1ff8b49b2a0ab109cc46d814b75 to your computer and use it in GitHub Desktop.
Save cc32d9/a823d1ff8b49b2a0ab109cc46d814b75 to your computer and use it in GitHub Desktop.
Fuzzy's ideas on a new BP pay model

@SirFuzzalot presented an idea for a new PB pay model for an EOSIO network in https://t.me/EOSPros

Fuzzy, [12.05.19 04:56]
Here is my thought on fixing dpos away from pageantry though. 
Let me find the discussion (should prob post it on whaleshares first but oh well)

Fuzzy, [12.05.19 05:03]
Ok ill just type it here since i am no longer in the group i posted it in initially.

Fuzzy, [12.05.19 05:04]
Bps must stake N tokens to be in a pool of potential producers.

Fuzzy, [12.05.19 05:05]
A number of bps are pulled from this pool every round of block production

Fuzzy, [12.05.19 05:06]
Based on the amount they have staked at any given time, a randomized 
modifier (1-4?) is used to multiply this staked amount.

Fuzzy, [12.05.19 05:07]
But only for the purpose of establishing order of bps from highest 
to lowest...from which the top 21 will be chosen.

Fuzzy, [12.05.19 05:10]
A % of that final number is charged to produce a block. If block is 
produced and the bp candidate has not staked too high, the bp gets 
paid more than they paid to produce it

Fuzzy, [12.05.19 05:11]
If they staked too much block production costs more than its worth 
(incentivizing away from big greedballs taking too much control via one node)

Fuzzy, [12.05.19 05:12]
Alternatively if they staked enough to be profitable but miss the 
block...they lose the tokens paid for the right to produce the 
block...and receive no reward (ie net loss)

Fuzzy, [12.05.19 05:14]
Under this system bps in dpos become connected to a similar incentive 
structure to miners where they must balance risk vs reward.

Fuzzy, [12.05.19 05:15]
And must also produce blocks or lose money

Fuzzy, [12.05.19 05:15]
It also takes away from the pageantry and ass kissing incentive

Fuzzy, [12.05.19 05:15]
Because that incentive is toxic

Fuzzy, [12.05.19 05:16]
Its ok for private chains that want to build like traditional companies 
but not for ones built as a common space for the public

Fuzzy, [12.05.19 05:18]
Now ill screenshot this so i dont have to refind it and feel free to 
give your own thoughts.

Fuzzy, [12.05.19 05:18]
I believe the game theory behind this is pretty strongly aligned with 
what we would want though

Fuzzy, [12.05.19 05:20]
And of course if anyone is ever interested in working on such a thing 
let me know. Id love to participate with a chain that wants to do something 
like this and would gladly advise if they agree with me and would have me ☺️

Bai, [12.05.19 05:35]
[In reply to Fuzzy]
🙊😂😂

Fuzzy, [12.05.19 05:37]
[In reply to Bai]
I know...
What sucks is feeling like an asshole for saying it

Fuzzy, [12.05.19 05:37]
😅

Fuzzy, [12.05.19 05:38]
But i guess now is a good time to say this channel is called EOS 
blockpros for a reason.

Fuzzy, [12.05.19 05:38]
Exponential OS

Fuzzy, [12.05.19 05:38]
If all EOS chains did this

Fuzzy, [12.05.19 05:38]
Bp operations could potentially choose to stake in more than one

Fuzzy, [12.05.19 05:39]
And we could build voltron together in an ecosystem unlike any others in crypto

Eric - sw/eden, [12.05.19 05:43]
[In reply to Fuzzy]
Could you give an example here so I'm sure I understand the idea correct?

Fuzzy, [12.05.19 05:54]
[In reply to Eric - sw/eden]
Sure. 

Bob is a blockpro candidate. He has to stake a minimum amount to get there. 
For this situation lets just say that is 1000EOS. 

Wanting to have an edge on the competition, Bob decides to stake 2000. 

Round 1 of block production is about to start and the chain needs to 
establish the bps who will produce for this round. 

Bob gets a random multiplier to his stake (2)

Effectively now bobs number of "votes" is 4000. If this puts him in the 
top 21 for this round he will get to produce a block. 

But the cost to produce this block for this round is 1% of his staked 
tokens x the multiplier (40EOS).  

And the reward for producing the block is not effected by this multiplier. 
If the block reward is higher than 40EOS (+equipment costs) it is worth it.

If he misses the block...he is harming the chain. The chain should not have 
to pay for this given it was bobs job to produce the block. So he will lose 
the amount he had to post for producing the block.

Fuzzy, [12.05.19 05:56]
Now with this said...its obviously hypothetical.  Numbers would need to make
sense...but this is something that can be refined.

Fuzzy, [12.05.19 05:56]
The best way to game the system would be to provide many nodes...all up 
running efficiently to minimum standards and providing redundancy to the network.

Fuzzy, [12.05.19 05:57]
But that is also a risk

Fuzzy, [12.05.19 05:57]
Because with more nodes comes more overhead and more potential for costly messups.

Fuzzy, [12.05.19 05:58]
This is the basic gist of it though

Fuzzy, [12.05.19 05:59]
I think the block reward also should be defined dynamically by the profitability 
of the chain. Aka a % of how much the chain is making from users paying for its services

Fuzzy, [12.05.19 06:00]
But this is just the initial thought. I do believe though its a dang good start

cc32d9, [12.05.19 08:44]
I'll copy this to GitHub if you don't mind

Tal Muskal | LiquidApps.io, [12.05.19 08:53]
[In reply to Fuzzy]
Love the general approach. it would be interesting to simulate this method 
somehow to get a feel of the dynamics.

Eric - sw/eden, [12.05.19 08:53]
There are some technical points that needs to be made but that can be discussed 
later (probably we don't want elections every 3min except if someone missed 
blocks...); I think it's a very interesting approach and would also love to try it out.

Tal Muskal | LiquidApps.io, [12.05.19 08:59]
[In reply to Fuzzy]
"Bob gets a random multiplier to his stake (2)" - is not trivial though
@Commoneffort
Copy link

Potential attack: A whale can split the stake in hundreds of accounts and populate the pool. The same whale will get to produce the majority of blocks and decide the governance.

@ThomasFreedman
Copy link

Wow, very nice work and hypothesis Fuzzy, and I am shocked I've not heard any talk of it. If BitShares would have taken this concept seriously and refined where needed, perhaps we could have avoided the drama that has occurred since May.

As a BP on BitShares for almost 5 years, my take on this is it's definitely worthy of refining and implementing.

@Agorise
Copy link

Agorise commented Oct 8, 2019

More ideas that I have been scratching down as they come to me. Base pay and fees etc on percentages so that they are no longer controlled by humans, and the whale problem disappears completely:
https://docs.google.com/document/d/1PaB9-ccGRB-DB719UdJRXu1KR1Zd0Yr0OgbWrCRoR6U/edit

@jcalfee
Copy link

jcalfee commented Oct 8, 2019

A way to address the split stake attack: Use ring signatures to anonymize a web of trust (or verified user) network. Only BPs will need to go through this step so it would not burden the average user. Things should get easier if you solve the sock puppet problem up-front.

@Agorise
Copy link

Agorise commented Apr 15, 2020

"Bob gets a random multiplier to his stake"
This part may have been solved by Algorand:
https://medium.com/algorand/algorand-releases-first-open-source-code-of-verifiable-random-function-93c2960abd61

@faddat
Copy link

faddat commented Dec 12, 2021

@Agorise I agree that algorand's research and development work on randomized proposals is relevant here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment