Key assignment system

Data structures:

Current validator set store:

This is a store of all the current powers of validators. I don't think this is possible to query from Cosmos SDK, so it needs to be built up from validator set updates.

TODO: think about the edge case that exists immediately after ICS is installed on a provider chain and this store has not been fully built up yet.

Key assignment message:

This is a message sent by a validator indicating that they would like to assign a key to be used on a consumer chain. This message contains the following data:

• Provider chain key
• Consumer chain key
• Signature of the provider chain key
• Signature of the consumer chain key

Key assignment mapping:

This store maps provider chain keys to consumer chain keys. It is updated when a key assignment message comes in.

Mapped validator set:

This is the result of applying the key assignment mapping to the current validator powers store. It has the current powers of the full validator set, but with whatever key they have assigned for the consumer chain.

Past mapped validator sets

This is a list of mapped validator sets from prior blocks. Each mapped validator power set must be kept long enough so that it can be referenced when a slash packet comes in. Storing all of these sets will take up a lot of space, but they can be compressed by storing only a delta at each block and rebuilding the full set from the deltas when a slash packet comes in. It is possible to prototype this without compression, and then add compression later.

Diffed validator set, aka VSCPacket:

By diffing the current mapped validator set with the most recent past mapped validator set, we can get a list of changes to the validator set. This is the data that is sent in the VSCPacket. This should be equivalent to the data that is sent in the VSCPacket in the ICS spec, modulo any mapping changes.

Procedure:

• When receiving a key assignment message from a validator, verify the signatures and update the key assignment mapping.

• On endblock:

  • When the validator set changes are received from the staking module, use them to update the current validator set store.
  • Apply the key assignment mapping to the current validator set store to get the mapped validator set.
  • Save the mapped validator set to the past mapped validator sets store.
  • Diff the mapped validator set with the most recent past mapped validator set to get the VSCPacket data.
  • Send the VSCPacket data to the consumer chain.

• When receiving a slash packet

  • Get the infraction height
  • Get the mapped validator set from the past mapped validator sets store at the infraction height
  • Use the mapped validator set to slash the correct validator

Diffing algorithm:

This algorithm diffs between validator sets. Each validator set is a map of keys->powers. The output of this algorithm is a validator set update, which is also a map of keys->powers.

• For each key in the old validator set:

  • If the key is not in the new validator set, write a validator set update entry with the key and power 0.
  • If the key is in the new validator set, but the power is different, write a validator set update entry with the key and the new power.

• For each key in the new validator set:

  • If the key is not in the old validator set, write a validator set update entry with the key and the new power.