Opt-in security rough design

[jtremback]

Protocol Change Proposal

This change will enable opt in security. With opt in security, validators will be able to decide which consumer chains they would like to validate on, and will only receive rewards for those that they are active on.

Proposal

There are a few main requirements to make opt-in security work:

• Consumer chains must receive VSCs with only the validators who have opted in. The chain will halt if e.g. only 10% of the power is running it, but it requires blocks to be signed by 66% of the power.
• Rewards must be distributed only to those validators who have opted in to a particular consumer chain (and their delegators).
• Validators should only be slashed by those consumer chains which they have opted into

There are some requirements that we can relax:

• We can allow consumer chains to pause unbondings for all validators, not just the ones who have opted in, if we set VscTimeoutPeriod such that consumers are removed before the exceed the provider chain's unbonding period. This means that the unbonding pausing system does not need to be modified from what exists for RS.

Code changes:

We need to store records of which validators have opted into which consumer chains.

We need to use these records to modify validator updates going out in QueueVscPackets. I think the algorithm required will be very similar to the key assignment algorithm. It may even make sense to integrate it into key assignment.

When downtime packets are received from a consumer, instead of jailing the validator on the Hub, they should just automatically opt that validator out of the consumer chain. They should not be allowed to opt back in for a time. This is like jailing.

When equivocation slashing packets are received from a consumer, we check that the validator they are for is actually opted in to that consumer.

We then need to design a new reward system. Currently, rewards are handled by the consumer chain just sending them directly to the fee pool address on the provider from which they are distributed by the distribution module to all validators and their delegators according to power.

Instead, rewards from a particular consumer need to go only to the validators that have opted in on that consumer, and their delegators. Determining which validators should get rewards is very simple using the records of who has opted in, but distributing them needs more thought. I would strongly prefer to use the existing distribution system because it is very efficient (no computation is needed until a delegator claims) and it would be good to keep claims working in the same way because people are used to it, and it has accounting implications.

It may not be easy to hook into the literal distribution module, and instead it might be more expedient to copy the code or the algorithm or something. Needs more thought.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned
• Is a spike necessary to map out how the issue should be approached?

[Spaydh]

Hi @jtremback, what is the proposed solution to the subset problem? And do you envision opt-in security to work alongside RS or replace it?

[mpoke]

Here is a rough design of Partial Set Security (the new name for Opt-in security).