Validators and KYC

[jaekwon]

We expect much from our validators. Not only to provide security, but also to make good governance choices as delegates (even if we support more flexible delegation systems where one can delegate to non-validators, we still need to delegate our trust of running validators securely to validators as a matter orthogonal to most others.).

What should the founding documents say about KYC and validators? The genesis validators can be KYCd by anyone, that is easy enough. But in general, what should be the policy for AtomOne?

Theoretically, it seems that stakers should be KYC'ing their own validators. If they don't know who the founders are, or executives are, for example, then how do they know enough to stake to them responsibly? Maybe somehow they do, but maybe you still want to make sure that the validator you delegate to isn't running their validator in a sanctioned country. But other stakers could live under different rules. Ultimately the policy that the hub adopts is by nature a self-sovereign one, but it can choose to align with any axis that it wants, and its voluntary choice of alignment should be considered before everything else, as well as the chances that it may be allowed to change alignment, and that it may not be able to stick to any one thing because of various external circumstances.

We can require that validators self-select and self-declare their jurisdiction policy choice by blockchain-based identifier, and these choices should determine what regulations the chain must abide by but only to be changed once +2/3 of the voting power agree to enact a new one first by chain then by governance. The stakers need to agree to the change to. But to change anything otherwise would be insecure. And until we have a secure system that works across hubs and zones, it is safest first to start with the permissionless base, and to support experiments of control, and also to support experiments of guaranteed freedoms.

[WaqarMMirza]

Wouldn't it be subjective to implement jurisdiction policy, and how can we ensure that the validator is declaring the jurisdiction rightly and not being opportunistic? This can also lead to a biased treatment of validators by the delegators overseeing the technological expertise of the validators.

[moul]

I agree, and I also think KYC for validators is important to limit Sybil attacks.

[Kikitof]

What do you think about integrating third-party identity verification services to confirm the jurisdiction of validators on AtomOne? Coupled with decentralized governance, this would enable token holders to participate in decisions, ensuring an objective approach while preserving decentralization and confidentiality.

[giunatale]

We can require that validators self-select and self-declare their jurisdiction policy choice by blockchain-based identifier, and these choices should determine what regulations the chain must abide by but only to be changed once +2/3 of the voting power agree to enact a new one first by chain then by governance.

Validators have their reputation at stake. If we agree by constitution that the information provided by a validator when it's created is required to be accurate (and updated to be accurate at all times) they incur in the social damage of getting caught red handed if they lie. And we could even possibly design procedures in the constitution to punish these infractions. We just have to put pressure on them to disclose more than what they do for example today on the Cosmos Hub.
Then stakers can use this info and the constitution to make their choices I guess.

I don't think we want to have anything more complex than this though, at this stage

But to change anything otherwise would be insecure. And until we have a secure system that works across hubs and zones, it is safest first to start with the permissionless base, and to support experiments of control, and also to support experiments of guaranteed freedoms.

Completely agree

[jaekwon]

Wouldn't it be subjective to implement jurisdiction policy, and how can we ensure that the validator is declaring the jurisdiction rightly and not being opportunistic? This can also lead to a biased treatment of validators by the delegators overseeing the technological expertise of the validators.

By future retroactive punishment for lying.

This can also lead to a biased treatment of validators by the delegators overseeing the technological expertise of the validators.

This allows the stakers to choose what Gaia becomes. It can also allow the stakers to help decentralize the validators by geography, if it aims to be a globally decentralized hub, which it should.

[jaekwon]

third-party identity verification services to confirm the jurisdiction of validators on AtomOne

I think it might be the case that we all need to verify each other for genesis in order to ensure that we are each not in the OFAC list for example. This isn't something that can be "offloaded" to a third party by design, so a third party cannot help here. That's my understanding, but we will have to consult experts here.

[serejandmyself]

This is a super tricky subject. I think a simple hierarchy of values must somehow be outlined (for a normal digital society, read - blockchain).

I.E. Freedom, Privacy, Responsibility, etc. It's a question where would verifying economical entities falls. Under which value. I don't know. Yet, it certainly seems that its not verifiability (which would in a digital sense make a great value to hold on to), because its not required for consensus (we are talking an open blockchain).

Does this mean that economical values shouldn't be subjected to procedure? I dont think so (in any case its the network's decision always). I mean in general terms.

A bit on and off-topic. We are building a new validator centric multichain explorer, which is set to become a dashboard with user verified info via web3 tx signing. It's not going to be ready tomorrow or the next month. What I'm trying to say here is that maybe economical verification should be somewhere on the application layer (analogy with the 3 layers of blockchain networks) and should be separated to, as you say - whatever the consensus at the moment decides on.

Anyway. Many words here. But the point is trying to say that maybe this should be left to a more application layer of everything and not be included in the highlighted way it is now in the pre genesis README, which is not only application layer, but a consensus layer. Maybe tools such as what we are building will allow that application layer to have a more private and a more customizable KYC application/s in the future.