Mainnet Beta: Investor Delegation and Road to Inflation

Overview

  • The aim of this post is to discuss and establish consensus within the community on how the Solana Foundation should be measuring validator performance objectively and presenting this information publicly.
  • A separate Validator Information thread has also been created , where validators are suggested to present their information once the format of information that should be published has been agreed upon. Please have a look and provide any feedback in this thread.
  • Some additional information around other important considerations that arise with the activation of inflation on Mainnet Beta have been presented as well.

In the coming months the Solana Foundation’s goal is to enable inflation on Mainnet Beta.

To enable inflation the following needs to happen:

  1. Distribute Foundation delegations across validators (more info to follow)
  2. All token holders staking their tokens as soon as possible, as their stake will take potentially take several months to fully warm up
  3. Unstake and remove Bootstrap Validators
  4. Enable inflation

Considerations

The above has several important implications which would benefit from community feedback. Please share all feedback over the following week to support the Foundation’s proposal and timeline. This means all feedback and discussion is to be submitted before the 13th of June 8:00am PT.

1. How will token holders decide who to delegate to?

The Solana Foundation aims to provide token holders with raw, unbiased facts regarding performance in the form of a spreadsheet based on the following parameters (subject to change):

  • Participation across testnets since the inception of TdS / SLP / MB
  • Contributions
    • Bugs Identified / SOL earned
    • Tooling
    • Github Contributions
  • Honorable mentions

An example of how we plan to present this is shown here

Additional Validator information is proposed to be provided in a forum thread here 9 for now where It is encouraged that validators provide more information about themselves, their company and self-report validator performance metrics on the Solana networks. The Solana Foundation will also aim to be explicit in ensuring token holders are aware that performance metrics such as skipped slots at this stage of the project are important long term but are currently not quite a reliable metric. This is due to skipped slots likely being due to software bugs rather than poor validator operations.

2. Will token holders be able to change their delegations?

Yes, the Foundation will be developing tooling to ensure that it is low-friction for token holders to be able to confidently get started with staking as soon as possible knowing that they’ll have the option to easily switch who they’re delegating to as they see fit.

This includes working with the Coinbase Custody team to allow token holders to delegate to any validator through Coinbase. The goal is to support an environment where stakes do not get locked into a centralised custody provider.

3. Inflation without Slashing?

Slashing is a hard problem, and becomes harder when the goal of the network is to be the fastest possible implementation. The tradeoffs are especially apparent when optimizing for latency. For example, we would really like the validators to cast and propagate their votes before memory has been synced to disk, but this means that the risk of local state corruption is much higher.

Fundamentally our goal for slashing is to slash 100% in cases where the node is maliciously trying to violate safety rules, and 0 during routine operation. How we aim to achieve that is to first implement slashing proofs without any automatic slashing whatsoever.

Right now, for regular consensus, after a safety violation the network will halt. We can analyze the data and figure out who was responsible and propose that the stake should be slashed after restart. Similar approach will be done with 1 block conf. 1-block conf safety violation is easily observable, but under normal circumstances a 1-block conf safety violation may not halt the network. Once the violation has been observed, in the next epoch the validators will freeze the affected stake and on the next upgrade will decide if the violation requires slashing.

Long term, transactions should be able to recover a portion of the slashing collateral if the 1-block safety violation is proven. In that scenario each block is effectively insured by the network.

Other Relevant Threads

Please also refer to this thread on some existing discussions around some of these topics

5 Likes

Hello!

Here are my thoughts and personal opinions about the up-mentioned discussion points:

  1. I think it’s a good starting point. It combines both the contribution so far to Solana from the early days and it allows us also to present ourselves and share our strong points (experience, team, infrastructure, security, disaster recovery plans, etc.)

  2. The easier it will be for delegators to interact with the network, the more engagement we should see. People are having hard times on multiple chains due to the lack of user friendly tools. Let’s not forget that most of the token holders are used with intuitive tools and easy to use apps.

  3. For now it should work, but on the long run the slashing must be defined and implemented at the protocol level. It’s totally unacceptable to have one of the important aspects of the network taken care in a manual, subjective and centralised way .

  4. I sustain this initiative, count me in

Wish you all 100% uptimes :slight_smile:

George

2 Likes

Thanks for involving us here. My initial thoughts:

1 - This seems fair but the effect of this will likely be that delegators cluster around a small number of validators, making it harder for new validators to get traction, resulting in a more centralised network where the rich just get richer and more powerful. We won’t really want 90% of rewards going to 10% of the validators.

My solution to this would be to introduce some kind of mechanism so that the more SOL a single validator is staking (either their own, or via delegation), the less attractive staking more SOL would be.

Let’s say just for example that when staking over 20k SOL, adding to that stake results in diminishing rewards. So for a new delegator, they can delegate to a long time, popular and trusted validator for relatively small rewards, or take the risk on a newbie for larger rewards.

Happy to think this through more and specify properly if helpful.

2 - Makes sense

3 - Agree with syncnode on this. I don’t have any suggestions, but even though it’s a hard problem but we need to figure it out.

Cheers,
Luke

Discord: captainlk#9940

2 Likes

I think before enabling inflation on mainnet it should be properly tested on testnet to be sure no dangerous things happen to peoples money real time

1 Like

Could there be any legal ramifications with slashing being decided by validators rather than being automatically executed by the protocol? Could the slashed party dispute this off-chain?

3 Likes

Thanks for starting this conversation.

I guess most of the investors of Solana are institutional and hence staking tend to be centralized. We need to deal with this as early as possible. In some cases, the team and some largest investors may need to take counterintuitive actions.

While we believe meritocracy matters, some validators already have strong track records in this space. Solana may need to spend more effort in bringing up the smaller or newer validators to equalize the Matthew Effect. Otherwise this is not that hard to see 80% of delegation go to 20% of validators.

Solana foundation (and team) may also need to act as the “delegators of last resort” to strike a balance between performance and decentralization when the distribution of delegation is not decentralized enough (but this also means we need to define “enough decentralization”).

2 Likes

yea, i’m not sure. :thinking:

It will be good that we can intensively test the inflation function on TDS and make sure everything work as expected before enable it on mainnet.

1 Like

I think it is fair to have the Validators who are from the beginning with Solana shown on the list.
Others need to prove themselves first.

It would be nice though to have an amount of fairness for all validators.
So hopefully this will not grow to a “whales” will have all the stake game!

Maybe we could make it possible to have some balanced stake, where you can stake with more trustes validators a % for decent rewards and another % with higher risks (short time validator, needs to prove). It’s basically same like a mixed portfolio…

Let’s make this fun for both proofed and new validators.

Keep up the nice works and ve curious to see what this will bring!

1 Like

Hi folks,

Thank you for the thoughtful approach and giving the community an opportunity to provide feedback. This is great! I’m supportive of this effort.

A spreadsheet of overall validator performance is valuable, especially if how long the validator has been supporting Solana is highlighted. The validators with the most experience might have scores that are dinged because they’ve dealt with much more network instability than newer validators. How might you account for this?

Token holders won’t necessarily know about the network stability challenges. Could there be a way to reflect stability / missed slots starting from the most recent released version as a metric? Perhaps this metric is not measured from the most recently released version but from whatever point is deemed “stable.”

I agree with the assessment on inflation without slashing.

There’s also an opportunity here to commit to decentralizing the network over time. Could there be a proposed timeline or some other mechanism to specify when on-chain slashing will get turned on?

Additionally, it would be very helpful to understand how off-chain slashing decisions will be made and what a validator’s role will be in those decisions. After recent events on Steem, it seems like a wise move to define this process in advance to arm infrastructure providers, token holders, exchanges, and custodians with the info they need to do their part fairly and compliantly.

Thanks again for inviting feedback here!

Viktor

Hi Dominic,

Thank you for progressing this.

Ideally we should be objectively measuring validator performance and presenting it to delegators for guidance. At this early stage it is not easy to to do so, but it is important to try. It is equally important to highlight to delegators how their risks have been minimized at this early stage by not enabling slashing and how risks can be further reduced by spreading stake across multiple validators.

The proposed overview of validator statistics is valuable and should ideally be one single access point reached via the Solana website. We question whether investors are interested in what compensation validators have received so far. This lagging measure of capability may be better turned into some sort of a historical experience/capability index. We suggest that a number of “near-objective” measures could be presented and incorporated:

1. Participation by stage (as a graphic)
2. Periods delinquent longer than 12/24 hours whilst rest of cluster operational (indicative of a failure in monitoring)
3. Responsiveness to upgrades  (have all TdS, Mainnet beta upgrades been performed in a reasonable period of time?)
4. Contributions in technical areas, governance, bug filing etc (List)

We would also suggest defining an appropriate time-window for some of these. For example we may look to display performance for measures 2 and 3 over the last X days or so, where X might be 60 for example. This would mean that we would only be highlighting any failures in validator performance over the last 60 days. If a validator did “drop the ball” they would then only need to ensure that they performed consistently well for the next 60 days to return to a good status on the dashboard. We need to get the balance for X right. Too long a period and validators may be “punished” for an unnecessarily long time, however too short a period and it may not be sufficient to fully demonstrate longer term reliability.

The self presentation by validators will also be useful, where they can cover things like:

  • Team, experience, security and presumably also link to assets like their own website for example
  • Commission fees
  • Performance guarantees

Ultimately a good dashboard will be required which presents a combination of real-time and historical information

We agree with the suggestions by other contributors about testing properly on testnet before rolling out to mainnet.@Dominic is there sufficient time in the schedule to do this?

We like captainilk’s suggestion about exploring mechanisms to reduce accumulation of stake with a single validator. @Dominic, is this something that is practical to look at, at this stage?

@jk_stakefish raises a great question about potential legal risk if decisions are made via a committee of validators rather than hard-coded in to the protocol. @Dominic what’s the best way to get an answer to this question?

We think @terence’s idea of using the foundation tokens as “delegators of last resort” to balance stake distribution and avoid investor stake concentration on a few validators is very intriguing. @Dominic is this a viable strategy? Are there any restrictions on how the foundation can delegate its stake?

Mike B LunaNova

1 Like

Initial responses inline :point_down:

The spreadsheet appears difficult to digest and interpret. There are many metrics that need to be clearly and consistently defined and calculated. My sense is that delegators will be scared away by the current level of complexity, leading them to seek a simpler decision method, e.g. going to the biggest validator, lowest fee validator, etc.

Self-reporting performance metrics doesn’t sound like a great idea. It’s too subject to interpretation and manipulation. Also, validators may or may not have the tooling in place to report such metrics in a reliable and consistent way, particularly if they’ve been involved for a while.

I feel it’s also important to report on when validators began participating and also be given credit for subjective contributions. Maybe the “Honorable mentions” are meant to capture these subjective contributions? If so, I’d suggest changing the name to “Other contributions” to not downplay them against other contribution categories.

Also, Solana could facilitate delegator introductions to validators.

While token holders “could” delegate to anyone, is it likely they will delegate to anyone other than the Coinbase 0 Fee (assumed) validator? While some may, my sense is it won’t happen on a large scale. To counter this, Solana should fund a diversity of easy to use staking interfaces. See this Livepeer dashboard as an example.

I generally discourage bouncing between extremes, e.g. 0 to 100%. My feeling is the beneficial approach is to take a middle path. I’m in favor of only slashing due to malicious behavior. Proving this behavior is complex and should ultimately be a governance decision. It may take a series of steps to get there. Maybe the % increases based on # of incidences, e.g. get caught once, get slashed 25%, get caught again, get slashed 100%.

Rather than slashing for liveness, maybe delegates get auto-unbonded if a validator’s been down for say 24 hours. This forces them to to get there stake back in the game and re-evaluate their validator decision.

Regardless of the approach, the app developers also need to buy into it. They need to be comfortable with the security of the network, of which slashing is a critical component.

Chris / Chainflow

1 Like

Hello!

We took our time and shared some thoughts related to these points.

  1. We believe this is a good start for building a strong validator community and if the facts presented will be unbiased, it seems like a fair procedure. Early participation as well as active involvement show dedication of the validators to the project. For honorable mentions it would be interesting to also know the reason behind it like a special contribution or very good responsiveness and involvement.
    One thing that we could add to the trust of a validator is how much a validator is self-staking. This is though not easy as many probably wouldn’t want to share how much they self-stake with their own validator.
    We think a crucial step is how this information will be presented to the users. An excel spreadsheet might not provide best user experience and the risk is that people would just ignore it. Maybe a validator portal/dashboard would be a great tool to show this information.

  2. We are strong believers in user experience and we think this is a key component for mass adoption. The easier it gets for an average person to use something, the higher the adoption.
    One thing to be taken in consideration is if it wouldn’t make sense to decouple token locking from delegating itself. By this we mean, that a certain number of tokens X can be locked to secure the network but they could be moved from a validator to another without waiting for Y days to unlock them. How often these tokens should be allowed to be moved pro epoch is also important to analyze so that it won’t have a negative impact on the network.

  3. In terms of slashing, we believe intended malicious behavior should definitely be slashed. We think the challenge will appear when trying to be sure that the malicious behavior was really intended by the node and was not something accidental. Therefore if this cannot be totally isolated, we are not entirely sure about the 100% slash.
    What we think would be interesting to analyze in the future, is to check and see if it would be possible to have a protection at protocol level for double signing. This would allow validators to run active backups with the same keys, thus providing active redundant nodes for their validators without the risk of getting slashed for a double sign.
    As slashing is a large and complex topic, it might make sense that we open a discussion directly focused on this topic so that we gather input and ideas from all validators in terms of what should be slashed and what not and also what can be avoided/protected directly by protocol design.

Best,
Chainode Tech Team

1 Like
  • Summarized the feedbacks on Chinese Validator’s thoughts of [[Mainnet Beta: Investor Delegation and Road to Inflation]:
  1. Starting inflation is fine, but the absence of Slash could be a problem. The current scheme is widely available for off-line or double-signature capture online. It would be safest to finish developing Slash before starting Staking.
  2. As for the issue of delegation, need to know whether the Solana foundation has the right to operate in Stake of investors. If yes, we suggest that the foundation help the excellent nodes to connect with investors, so as to ensure that investors’ stake can be given to the excellent nodes.
  3. The overall contribution score is OK, and it seems that there is no way to distribute the delegation more fairly
1 Like

There is that fancy new “persistent memory” rolling out in a few months… but the general point in relation to slashing stands, hardware/software issues can cause a slash… not to mention operator errors (accidental equivocation comes to mind)… but having said all that, probably you just have to suck it and see. Can’t spend your life wondering.

That’s aka a sybil attack & it’s almost impossible to prevent at the token holder level. If we set a limit on how much you can stake to a validator, I just create multiple validators… but as you say, you can do it at the validator level, by capping or reducing rewards, as others are doing.

Right, that is exactly when double-signing (equivocation) happens. It’s beyond my pay grade, but can the protocol not somehow detect & ignore it?

1 Like