Testnet 4 Validator Initiative Discussion

adr-sk commented 3 weeks ago

Description

The upcoming Testnet 4 (test4) will include a validator set implementation in Gno (related efforts: https://github.com/gnolang/gno/issues/1823, https://github.com/gnolang/gno/issues/1824).

Upon launch, we will see an inflow of requests from teams and individuals to join the validator set.

Defining a clear set of criteria is critical to ensure that each validator is technically proficient and aligned with the Gno project.

The criteria should be followed by a transparent evaluation process that's fair and reasonable.

Furthermore, a specification of responsibilities and tasks as a Gno.land validator should be provided to assure that validators are well-aware of what's expected from them.

Tentative Criteria

Contribution (optional at the current stage to lower the barrier to entry)
- Core Stack: Regular submission of meaningful PRs or Issues to the /gnolang organization (based on complexity, scope, and time)
- Infrastructure & Tools: Providing helpful services such as wallets, explorers, or public APIs
- Community: Contribution to official community moderation, localization & translation, and meetup arrangements
Experience & Background
- Provable record of successfully running a validator node on other blockchains
- Bonus: An uptime of more than 95%
- Bonus: No record of slashing for downtime or double-signing
- Bonus: Genesis validator for top Cosmos chains
- A validator with a strong public presence & reputation
- Bonus: A social follower above xx.
- Geographical distribution
- Bonus: If the data center is located in a new area

What to Expect as a validator

Responsiveness to upgrades (required)
Maintaining a high uptime (required)
Active participation in other spontaneous challenges and tests (required)
Providing public RPC endpoints (optional)
Running the node in Seed Mode (optional)
Periodic snapshots (optional)
Monthly operation reports for validator experience improvement & optimization (optional)

Number of Validators

Initially 10 validators that gradually increases with stabilization and optimization tests.

Successful outcomes

A clear criteria for joining test4 as a validator.
A reasonable policy for changing the size of the validator set.
A transparent validator evaluation process.
A reliable set of quality validators, consisting of contributors that bring value to the Gno project.
A list of responsibilities and tasks that validators should expect.

michelleellen commented 2 weeks ago

Hi @adr-sk

This looks great. A few questions/comments:

Would we want to have an informal spotlight process for potential validators? They create their Hackerspace issue, document their contributions, node set up...etc. This could be the first step in presenting themselves as candidates to be included in the network. We discussed having a working group, so if we identify validators on GitHub we can invite them to join. The DevX team will also run a validator, so having them in the working group kick off would be good
What about validator organizations, we should clarify since the sum of the team member contributions will be the sum for the validator contributions (CosmosStation).
Will we evaluate their voting record? (Genesis validator for top Cosmos chains)
Will validators be ranked by their contributions rather than then operational performance?

I think we should anticipate 20 or 30 or so by September/October. It would also be good to have a contribution section specifically for validators, obviously realms and core code can count, but would be good to get a wish list.

I think we can add the validator spotlight too to the data visualizer that @alexiscolin will work on for notable contributions and GoR.

adr-sk commented 2 weeks ago

Would we want to have an informal spotlight process for potential validators? They create their Hackerspace issue, document their contributions, node set up...etc. This could be the first step in presenting themselves as candidates to be included in the network. We discussed having a working group, so if we identify validators on GitHub we can invite them to join. The DevX team will also run a validator, so having them in the working group kick off would be good

Yes, each validator should create an issue to document the full process (from applying to spinning up a node), their node specs, and the monthly reports mentioned in the proposal.

What about validator organizations, we should clarify since the sum of the team member contributions will be the sum for the validator contributions (CosmosStation).

This is a tricky one. In PoS chains, there are little to no incentives for an entity to split up their validator node into multiple ones within a single network since rewards are proportional to the tokens delegated (=extra infra costs with no additional returns). However, in PoC, rewards are split equally among all validator nodes within the set, so the more nodes an entity runs, the more rewards they will receive. Although this won't be an issue in Testnet, maybe it's worth starting a discussion ahead of Mainnet to decide if a single entity should ever be allowed to run multiple validator nodes. (probably out of scope for this issue though) (cc @zivkovicmilos )

Will we evaluate their voting record? (Genesis validator for top Cosmos chains)

Evaluating the voting records would be a great way to gauge their engagement and activeness. It might also make sense to throw in a requirement of not having voted Yes on Prop 69, as it goes against the philosophy of the Gno project.

Will validators be ranked by their contributions rather than then operational performance?

Could you please clarify if the rank here is referring to a queue of validators waiting to enter the set, or a leaderboard of active members already in the set?

In the latter's case, since validators in PoC won't have "ranks" as in PoS, I belive a simple Pass/Fail structure with "baseline" requirements might be more suitable, unless there are any "tiered rewards" based on their performance. (cc @zivkovicmilos)

I'd also like to hear more about what you think about the suggested criteria. What do you think about the evaluation process involving a quantitative scoring system similar to the ICF delegation policy? (i.e. whenever there's an opening, the candidate with the highest score gets invited)

gnolang / hackerspace