Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Patch design doc format #456

Merged
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 8 additions & 9 deletions docs/key-assignment/design.md
Original file line number Diff line number Diff line change
@@ -48,23 +48,23 @@ in the implementation of the wider system.

## Sub protocol interactions

## Assigning a consumer consensus key
### Assigning a consumer consensus key

Once a validator is created on the provider chain it is possible for the validator to assign a consensus key for a particular consumer chain by submitting a transaction to the provider chain. The assigned key is stored, and all future validator set updates which are sent to the consumer chain are mapped through the assigned keys.

## Channel initialisation
### Channel initialisation

TODO: describe


## Validator set update
### Validator set update

When validator set updates are emitted by the staking module and sent by the VSU sub protocol, the updates are mapped through key assignments. Each provider consensus key referenced in an update is mapped to its assigned key. If no key is assigned, the default behavior is that a provider key is mapped to itself. Thus the VSU packets contain validator updates which, on delivery to the consumer, can immediately be passed to Tendermint (after aggregation). The update mapping algorithm takes care to produce a valid set of updates even when the assigned key is changed and the validator joins/leaves the active set.

When a VSUMaturity packet is delivered to the provider chain the KeyAssignment internal data
structure is pruned by passing the matured VSCID as argument. The pruning step removes any keys which
have not been used for consensus by the consumer chain since the consumer received the VSU with vscid VSCID.

## Consumer initiated slashing
### Consumer initiated slashing

When a double signing or downtime slash action occurs on the consumer chain the slash packet is sent as normal to the provider chain. On delivery to the provider chain, the consensus address referenced in the slash packet is mapped back to the address of the validator to be slashed on the provider. This is possible even in the presence of changes to the assigned key of a validator, as previously used keys are stored for some (sufficient) time.

@@ -73,16 +73,15 @@ A correct consumer chain will not send a double sign slash request for a consens

In other words: correct consumer chains shall not send double sign slashes for validators which they have already unbonded. This assumption is supported by setting appropriate parameters in the evidence module (see [relevant code](https://github.com/cosmos/cosmos-sdk/blob/61effe82603006a7192cb311787ca8fc776a4461/x/evidence/keeper/infraction.go#L54)).

## Reward distribution
### Reward distribution

There is no interaction with the rewards distribution sub protocol.

## Cleanup
### Consumer removal

When a consumer chain is removed on the provider chain all the associated key assignment data is deleted. When a validator is destroyed (not merely unbonded) on the provider, its associated key assignment data is deleted.


### System integration points
## System integration points

There are some integration points with the system