Proposal: Evaluator geographic/infrastructure diversity monitoring

[robertocarlous]

Context

The DIN whitepaper (Section 6, Threat Model) defines the network's resilience
in terms of stake-based collusion: the protocol tolerates up to but not
including 50% malicious participants (M < N/2), backed by median-scoring
to catch outlier Evaluator behavior. Sybil resistance is flagged as an open
question, to be solved "through decentralized identity verification,
verifiable credentials, or manual processes" (not yet decided per the paper).

Paper: https://arxiv.org/abs/2407.02461

The gap

What the current threat model doesn't address is infrastructure and
geographic concentration among Evaluators a risk that's independent of
both Sybil attacks (fake identities) and stake-based collusion. Even a set
of individually legitimate, honestly-staked Evaluators could end up
clustered behind the same cloud provider or jurisdiction, which is a
distinct failure mode most PoS networks track separately (commonly via
something like a Nakamoto Coefficient the minimum number of independent
entities needed to collude to disrupt the network).

Proposal

A lightweight, additive diversity-monitoring layer, not a change to the
existing staking/slashing mechanics:

1. Capture operator metadata at NFT-stake registration — approximate
   region, hosting provider/ASN, client version.
2. Publish a concentration dashboard tracking stake concentration,
   hosting-provider concentration, and geographic concentration among
   active Evaluators over time.
3. Weight the existing random Evaluator-assignment step (the ~1:10
   Evaluator:Participant ratio per subgroup) to favor diversity within the
   pool the randomness draws from, where the eligible pool allows it.

This is intentionally scoped as measurement and selection-weighting, not
new slashing conditions diversity concerns and malicious-behavior
penalties are different problems and probably shouldn't share an
enforcement mechanism this early.

Open questions

• Given identity verification is still open per the paper, should this
  build on whatever DID/verifiable-credential approach gets chosen, rather
  than standing up a parallel system?
• Worth measuring only during testnet first, or is there appetite to make
  this public pre-mainnet as a transparency signal?

cc @umeradl @abrahamnash