- 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:
- Distribute Foundation delegations across validators (more info to follow)
- All token holders staking their tokens as soon as possible, as their stake will take potentially take several months to fully warm up
- Unstake and remove Bootstrap Validators
- Enable inflation
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
- Bugs Identified / SOL earned
- 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