Pre-proposal: Improve Stake Decentralization

Research & Development
21

Thank you @Oliver for starting this discussion :pray: It feels hopeful to see the dialogue that it’s sparked here :fire:

While I’ve laid out many of my broader thoughts in the podcast, as well as in previous writing, here are a few specific responses to your thoughtful proposal. I thank you again for putting yourself out there by making concrete recommendations.

It’s much harder to propose ideas than it is to take shots at them after they’re proposed. This is especially on a topic like decentralization, as many would prefer to not talk about it at all, as @chris alludes to. I do feel strongly aligned with Chris’ response, particularly this framing -

And with that, here are my responses :point_down:

I think the Solana Beach implementation of this has been very effective, particularly the recent collapsing of validators “above the line”.

Their approach to put “the line” at 33% of total stake is one that I support. The number of validators/indexers that control of 33% of stake is arguably the “lowest” important decentralization metric and comes earlier than the 51% threshold.

This sounds like a fantastic idea. This option would truly give validators a chance to “walk the walk” when it comes to supporting decentralization. I’ve long been of the opinion that traditional high-growth business models work directly against the core concept of decentralization.

For example, if a large validator company has investors who expect return to be maximized, how can that company’s management NOT try to capture every token of delegation they can? If they did leave stake on that table, that wouldn’t maximize their return, would it?

So today, large validator companies will often use the “Well, there’s nothing we can do to prevent delegators from continuing to to delegate to us…” explanation to justify the pursuit of ever larger and more controlling stakes.

(As an aside, one validator was actually using promoted Tweets for a while that said, in no uncertain terms, “Stake to us, we’re the biggest!”)

As I mentioned in the podcast episode there are, indeed, steps that these larger validators can take to not continue accumulating. Whether or not the validator company chooses to do so is another story.

I feel that enabling “new delegation rejection” shines light through this thinly veiled reasoning. It would give validators a very strong tool to “walk the walk” by saying, “Hey, we have enough, there’s enough to go around for everyone.”

As a first step, I’d implement this as a binary “On/Off” choice, to keep things as simple as possible (recognizing this could very likely be a non-trivial protocol change).

I feel that something like this is necessary. I’ve haven’t had a chance to think through the details yet.

I would say that, after observing the behavior of large validators on many networks over the first few years of staking mainnets running, a stick is necessary. Voluntary carrots aren’t working.

What’s happening is that the large validator companies are accumulating capital and the associated power so quickly, in such large quantities, that the carrots are often dwarfed into nothingness.

And unfortunately, we haven’t seen large validators voluntarily say, “Hey, we’re big enough, time to spread the wealth around.” There have been exceptions that are few and far between.

In fact, we most often see them get bigger and bigger and commanding more powerful roles in the networks they support/control. Figment receiving the large Graph Grant to become a third core development team is the most recent example of this.

The stick is necessary from a delegator perspective too. We need to help delegators make more informed decisions, rather than simply follow each other down the path of least resistance. The stick in this case will help get their attention. It will cause them to choose carefully, rather than simply look at the top 3 Indexers by stake and stake to the one with the lowest fee that day.

2 Likes
22

I wanted to add another thought around the idea of a dynamic delegation multiple.

The goal of this thought exercise is to encourage Delegators to spread their delegation around. This proposal actually targets Indexers first and foremost, with Delegators being the 2nd order knock on effect. Realistically, the Delegator who will be savvy enough to know that an Indexer with stake X will have the ability to accept a larger multiple, when compared to an Indexer with stake Y, that sounds like a somewhat informed Delegator to me. At the very least, if they’ve understood that, I think it may be safe to assume that it’s easier to get the message across about the ideal of spreading delegation around is better for decentralization.

I think we’d be adding complexity for complexity’s sake, and taking the harder path to get towards the intended goal.

Not to mention that a quick look down the list of Indexers, I see 20 out of 158 that have at least a multiple of 10x between delegated versus self-stake.
And of those 20, 2 have more than 5MM self-stake, and 3 have between 5MM and 2.5MM self-stake.
So from a multiples standpoint, I think we actually are already seeing the lower-end Indexer sizes utilizing the higher multiple as it is.

23

It seems like many delegators are largely coming and asking the immediate question “which indexer do I chose” as seen in discord/reddit time and time again.

I like the concept of a reduced tax if the curators splits their stake evenly amongst multiple indexers. A simple UI message ‘Help keep stake decentralized by splitting your stake amongst multiple indexers. Your delegation tax decreases when doing so.’ would probably go a long way.

Regarding a delegation cap multiplier, what’s to stop a larger indexer from opening multiple accounts to avoid the top tier limitations? Rather than 1 account indexing 30 subs, having 6 that index 5 (with smaller total signal) seems like it would work around this system.

1 Like
24

Great idea. I hope he can help build the community

25

Firstly a big thank you to Oliver, Chris and @fattox for the work and efforts to promote this vitally important subject and thanks to those who have contributed to the subsequent discussion.

The ideas discussed and suggestions made have been great. To bring this to a conclusion will be a challenge but not as big a challenge as dealing with a protocol that becomes self-defeating as stake becomes more and more centralized. We have a complex protocol with a multitude of levers that change how it works in practice. To get this right may require us to think and behave differently.

The foundation may be to agree the protocol principles we think are important. As a starter for 10:
1. Decentralization is vital
2. Competition is healthy provided that it encourages the best performance
3. Tokenomics are for the benefit of the protocol to fund development and encourage appropriate behaviour
4. Measurement is critical (because you get what you measure)
5. The Graph community must continue to support each other as we navigate through difficult and challenging times
…………etc

To turn to practical suggestions:

• We should not demonise, punish or restrict successful indexers that although they may be large and profitable do respect The Graph principles (as sketched out above).
• We should do all we can to evenly spread stake among competent indexers and to encourage this, more stake should realistically go to the more competent.
• Rather than looking to re-distribute the 30% of the token-supply that is currently delegated we should focus on attracting more tokens to be staked and ensuring that it is appropriately distributed.

Therefore we have two problems and not one: we need to attract new stakers AND we need to ensure an even spread of stake. We need to work on both

To attract fresh delegations we need to recognise both the fundamental importance of and potential of The Graph protocol and the sheer complexity of operating it as an indexer, a curator, a fisherman etc. AND understand what future investors/delegators really want: I suggest they want to invest in a worthwhile venture and make a difference, they want a long-term winner that provides good returns.

So the question is: “Do we make it easy for them?” I’m not sure that we do. When you consider the variety of returns/cuts you can get, people will find this bewildering, particularly as it’s possible for a good indexer with a much higher cut to actually return more to their delegators than an indexer charging ostensibly very low fees but performing badly. APR calculations could be very helpful but we also need to be mindful that it is only with the recent move to enabling curation and 3rd party subgraph creation that good indexers have been able to start to shine and data taken earlier than this is potentially very misleading.

We can work on fixing this and/or we take a leaf out of Solana‘s book and promote staking pools. Pools which have the responsibility and the resources to discern and allocate stake; indeed their even stake distribution ought to be measured and encouraged.

In summary:
• Make decision-making as easy as possible via strong and jointly held principles
• Measure and promote good performance (Don’t demonise successful indexers)
• Attract new delegations
• Consider pools as a way of spreading stake

Further observations on some of the specific proposals that have been made will follow in a future post.

4 Likes
26

Another concept will likely help decentralization of stake as well as onboarding stake holders would be contacting some wallet providers. I reached out to the exodus team who is interested in enabling GRT delegation on their desktop wallet.

For 3rd party wallet integration, the decision process may be a bit cumbersome for token holders who haven’t really taken the time to understand the process. We could offer some type of UX item like a ‘1 click delegation’ which could improve stake participation for newer users.

We would need to refine this but as a concept we could select the ‘indexer of the month’ based on (query fees produced on the last 28 epochs / delegated stake * effective APR).

@cryptovestor @Oliver

2 Likes
27

As a delegator i find it very difficult to choose the a indexer.

To make that process easier I would like to posit the idea of an “1 click delegation” button that delegates my GRT to a so-called “indexer index fund”.

This indexer index fund would be composed of a multitude of reputable indexers, and in the same way a stock index fund allows you to spread your investment among stocks of multiple companies this system would allow me to spread my stake among multiple indexers.

Questions that come to mind when thinking about this:

  • Is this even possible?

  • How to define a reputable indexer?

  • What should the weighing method be?

2 Likes
28

I feel like it would be easier to implement a ‘let us help you find one of our top indexers’ rather than an indexing fund that potentially moves delegation around. This would require management of the fund which leads to the issue of ‘who decides where the fund gets allocated’.

The ‘1 click delegation’ should rotate through a list of the top X (10 for example) indexers based off of various factors, but should be a proportional valuation of the indexers delegation compared to the value they are bringing to the network (presumably query fees) over a period of time and likely consider the return rate for the delegator.

This method would assist with spreading stake around and would favor productivity compared to current delegation %.

1 Like
29

As promised please see our thoughts on specific proposals below:

Indexer decentralization threshold

We (LunaNova) are supportive of this. It readily highlights the risk of centralization caused by continuing to send further delegations to already “well-staked” indexers; it is simple and quick to implement.

Delegation rejection

This would certainly test the intent of those with larger stakes and as such we would not object to the implementation of such a system. However, as Josh-StreamingFast has indicated this will not necessarily be simple to implement and there are questions about whether it should be on-chain, case by case and what to do about lost gas cost. It would require code, audit, integration, and implementation.

Changing the multiple for delegation capacity

This could be a very effective mechanism.

Making a delegation cap “dynamic” is quite appealing but agreeing what self-stake should lead to what delegation cap will not be trivial. Making this a function of absolute amounts of GRT may be limiting unless it can be regularly reviewed and changed as necessary, which is quite an overhead.
It may be preferable to make it relative to the total amount of GRT being staked and possibly the size of other Indexers. This may be a little complicated to implement but that should not deter us if this solution has strong support and a good chance at improving decentralization.

Whatever route is pursued we would need to decide whether delegations over the cap are simply rejected or if we stick to the current approach of diluting rewards as an Indexer goes over capacity.

Decentralization delegation tax

This is particularly attractive because it clearly benefits stakers delegating to a smaller Indexer. A progressive scale should avoid large swings in delegation behaviour. Just as with the adjusting the delegation capacity, there will need to be consensus on appropriate levels of tax for different levels of self-stake. However it should be easier to implement than altering delegation capacity because we would not have the difficult issue of handling stake over a delegation cap. Any tax raised this way could be simply burnt – to the benefit of all token holders.

CAUTIONARY NOTE

Much of The Graph’s current design variables, such as the 28 day max allocation period which dictates how long delegates are expected to wait after unstaking, was influenced by the concerns over Ethereum gas fees (ironically at levels much lower than they are now!)

To ensure the protocol remains functional and effective as load increases on its services, then moving to either a robust Layer2 solution or even migrating to a more efficient Layer1 may be necessary. This will hopefully see significantly cheaper fees for Indexer allocation and potentially allow us to significantly reduce global variables such as the 28 day period stakers have to wait to redelegate. We must bear in mind that any changes to improve stake decentralization need to be able to work under both the current model and a more cost-efficient/frictionless future model. (We don’t believe any of the currently tabled proposal would face any real issues should we get to the point of enabling more frictionless redelegation but it is something we do need to bear in mind as additional solutions to tackle this issue get proposed).

2 Likes
30

Re. Indexer Decentralization Threshold

I think this is a great initiative and I have an idea that may compliment this. Curious to hear feedback, as I’m not sure if this has been brought forward as an idea yet.

Endorsed Indexers

  • Implement a way for indexers to endorse other indexers, whether large or small. One of the largest issue delegators have is choosing an indexer(s), these endorsements may help aid in their decision.

  • Here are some of my thoughts and ideas on how this list could work:

    • Allow indexers to provide a list of their top 1-5 alternative indexers to endorse.
    • This list can be updated and maintained by the indexer anytime if they feel the need to change which indexers they’re endorsing.
    • In the UI, when delegators are prompted to delegate to an indexer, they are also provided with the indexers endorsed list and verbiage to promote diversification.
    • If the indexer is within the upper or lower threshold (based on the indexer decentralization threshold), upon delegating, the UI at first hides the ability to delegate to this indexer. The endorsed list of indexers to choose from instead of the original indexer will be visible. There will be proper verbiage to attempt to move delegators into choosing another indexer, BUT if they still wish to delegate to the original indexer that option is at the bottom.
    • If at any time an endorsed indexer falls into the upper or lower threshold a warning is placed beside them on all endorsed lists.
    • If honest indexers fall into the lower threshold category they should follow the proper channels to get out of the lower threshold accordingly.
    • If the indexer will become over-delegated or is over-delegated the option to delegate is hidden at first and this list of endorsed indexers is displayed. Provide a over-delegation warning to delegators. If they still wish to delegate, after the warning is acknowledged, allow delegation.
    • If the indexer does not provide an endorsed list, prompt the delegators in the UI and encourage the delegator to reach out to the indexer to add endorsements.
    • In the UI provide a “Endorsed list last updated timestamp”
4 Likes
31

I think this is a much more eloquent proposal for what I referred to as “indexer overflow”. Well done!

32

In a round-about way, this sounds like it could end up a little like EOS, with the BP voting. I’m sure @Josh-StreamingFast has some thoughts on that. :grimacing:

1 Like
33
  1. Delegation rejection. It could be solved much easier, the majority of Delegators use UI. We have only a few UIs, so I think it shouldn’t be a problem, to make an agreement between them. To hide Delegation function at all for Indexers with % of delegated tokens higher than X or\and delegation ratio higher than Y. I believe it will redirect 90%+ of delegators to other Indexers. And it’s pretty easy to implement. And yes, I think it shouldn’t be an option, where Indexer decides by himself, or when delegator may press “Show me the button Delegate”.
  2. Changing the multiple for delegation capacity. We obviously need this, the main problem is “what numbers should we choose”. Because if we will set it too low, the current large Indexers will be on fire. And their Delegators also (majority of Delegators of the Network) will be forced to redelegate and lose 28 epochs rewards and 0.5% fee for redelegating. It will be nice to have it with #1, don’t nerf current delegators and Indexers rewards, but hide the Delegation button, in this case, if someone from Delegators will decide to fix their rewards, they will go to another Indexer if the previous one already “over delegated” (in the new meaning) or have “over_ratio”. But I think it’s hard to implement with these nuances.
  3. Decentralization delegation tax. Also good point, it will be good to remain 0.5% as a maximum fee and 0.1% for delegating to Indexers with a Delegated share less than X and ratio less than Y.
1 Like