ICS 28 CCV draft w/ init and validator set update #640

mpoke · 2022-01-18T13:06:28Z

The partial specification of Cross-Chain Validation.

To facilitate the review process, we split the CCV spec in multiple PRs. All these PRs will be merge into the marius/ccv branch. Once the CCV spec is complete (all the features are included), we can create a PR to merge it to the main branch.

Features included:

the Initialization subprotocol, that enables the creation of a unique, order channel;
the Validator Set Update subprotocol, that enables the provider chain to inform the consumer chain of updates in the validator set.

Features not included (to be added to other PRs):

the staking hooks that enable the timely completion of unbonding operations (e.g., undelegations) on the provider chain (i.e., waiting for the operations to mature on the consumer chain);
the evidence / slashing subprotocol that enables the provider chain to punish validators for misbehaviors on the consumer chain;
the distribution subprotocol that enables the validators to receive rewards for validating on the consumer chain.

sergio-mena · 2022-01-24T10:05:09Z

After going through the current draft, these are my comments. Please reach out to me if something is not clear

First of all, after reading the whole spec, my main concern is that the whole system's liveness is as robust as the weakest chain. IMO, we should, at least, define a "kill_chain" method, similar to create chain that can be triggered via governance. This would be crucial in the event a chain's logic turns out to be unsound... so that the Validators can ever unbond their tokens.

Here are some more detailed comments:

"Header" section is missing. Take a look at ICS#1 and add the missing mandatory sections.
Questions on "Overview and Basic Concepts"
- I understand CCV helps securing chains whose tokens don't have a big market cap. But, what would keep the motivation for CCV after those chains become successful?
- So a consumer chain MUST (?) be created by the provider chain. This means it cannot pre-exist... reason?
- The terms "full node" and "validator" seem to be used interchangeably. They are not the same in Tendermint.
- Client creation. "InitGenesis method of the consumer CCV module". How are we sure such a method exists? MUST the consumer chain be implemented with the Cosmos SDK (alternative: App using ABCI directly)
- The text mentions child chain. Definition?
- So unbonding is now governed by the slowest consumer chain... what if a consumer chain gets stuck? Is this scalable?
Questions on "System Model and Properties"
- "Valid Blockchain". What does this mean?: "protocols are executed correctly". Who executes them correctly? All processes? No byzantine processes allowed?
- Correct relayer seems to not accept packet timeouts. What if one happens? Can we recover from that?
- "Desired properties" talks about tokens, but doesn't specify from which chain they are. I reckon it's always provider chain tokens, but it would help to clarify it in the text
- "Unbonding Invariant" doesn't declare "cc". Shouldn't it also be part of the forall?
- "Validator Update To VSC Validity" doesn't mention slashing, should it?
- "Validator Update To VSC Liveness" you could actually relax it to "a consumer chain" without loss of generality
- "Register Maturity" properties. No mention of aggregated VSCs. So it's not clear how these properties apply to them. An aggregated VSC may not exactly match any sent VSC
Questions on "Technical Specification"
- Interaction with staking module. Don't we need to modify it? ... so that it doesn't enforce the local unbonding period?
- Provider CCV module initialized at genesis. So how do we add support to existing chains?

Finally, some minor/editorial comment are added inline

sergio-mena

Some minor/editorial comments that complement my other comments added in the PR's conversation

spec/app/ics-028-cross-chain-validation/README.md

spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md

spec/app/ics-028-cross-chain-validation/system_model_and_properties.md

spec/app/ics-028-cross-chain-validation/technical_specification.md

…cepts.md Co-authored-by: Sergio Mena <[email protected]>

…rties.md Co-authored-by: Sergio Mena <[email protected]>

…n.md Co-authored-by: Sergio Mena <[email protected]>

Co-authored-by: Sergio Mena <[email protected]>

mpoke · 2022-01-25T13:44:11Z

@sergio-mena Thanks for the feedback. I replied to all comments inline.

After going through the current draft, these are my comments. Please reach out to me if something is not clear

First of all, after reading the whole spec, my main concern is that the whole system's liveness is as robust as the weakest chain. IMO, we should, at least, define a "kill_chain" method, similar to create chain that can be triggered via governance. This would be crucial in the event a chain's logic turns out to be unsound... so that the Validators can ever unbond their tokens.

This is probably a good idea. @AdityaSripal, @jtremback was this ever discussed? Basically, a turn-off button on the provider chain :)

Here are some more detailed comments:

"Header" section is missing. Take a look at ICS#1 and add the missing mandatory sections.

To be added before the complete draft is merge to the main branch.

Questions on "Overview and Basic Concepts"

I understand CCV helps securing chains whose tokens don't have a big market cap. But, what would keep the motivation for CCV after those chains become successful?

The motivation of CCV is a complex, ongoing discussion. For V1, Hub Minimalism may be the best motivation. Future versions may enable higher security.

So a consumer chain MUST (?) be created by the provider chain. This means it cannot pre-exist... reason?

It can pre-exist, but not as a consumer chain. To become a consumer chain, a hard-fork is required. The operators of validators of the provider chain will start full-nodes of the consumer chain starting from a Genesis state; this state can be exported by a pre-existing chain.

The terms "full node" and "validator" seem to be used interchangeably. They are not the same in Tendermint.

Fixed.

Client creation. "InitGenesis method of the consumer CCV module". How are we sure such a method exists? MUST the consumer chain be implemented with the Cosmos SDK (alternative: App using ABCI directly)

Currently, the spec assumes that the app is implemented using Cosmos SDK. It's not really a requirement, e.g., instead of InitGenesis, it can be any function that is called when receiving a InitChain message from the consensus engine. In the Technical Specification, that's the actual precondition of InitGenesis.

However, we should probably remove any dependencies to Cosmos SDK, e.g., replace "CCV is a Cosmos SDK module" with "CCV is a module of an ABCI application". @josef-widder Do you agree?

The text mentions child chain. Definition?

Consumer. Fixed.

So unbonding is now governed by the slowest consumer chain... what if a consumer chain gets stuck? Is this scalable?

If the consumer gets stuck, the unbonding cannot complete. Not sure I understand the second question. What do you mean by scalable?

Questions on "System Model and Properties"

"Valid Blockchain". What does this mean?: "protocols are executed correctly". Who executes them correctly? All processes? No byzantine processes allowed?

I agreee. "Valid Blockchain" is overloaded and ambiguous. @josef-widder we should probably be more exact in what does CCV expect here, right?

Correct relayer seems to not accept packet timeouts. What if one happens? Can we recover from that?

This is marked w/ a ToDo in the Technical Spec. In the case of a timeout, probably all the unbonding operations will complete. However, the spec is written under the assumption that timeouts cannot happen. There is a discussion on this under the definition of the "Correct Relayer" assumption.

"Desired properties" talks about tokens, but doesn't specify from which chain they are. I reckon it's always provider chain tokens, but it would help to clarify it in the text

Actually, it is specified, e.g., "tokens bonded by validator val on the provider chain".

"Unbonding Invariant" doesn't declare "cc". Shouldn't it also be part of the forall?

Actually, it does. It doesn't declare "val". Fixed.

"Validator Update To VSC Validity" doesn't mention slashing, should it?

No. Slashing is a feature not yet specified. But why should Validator Update To VSC Validity mention slashing?

"Validator Update To VSC Liveness" you could actually relax it to "a consumer chain" without loss of generality

Not really. I want it to include also Provide VSC uniformity, i.e., If the provider chain provides a VSC to a consumer chain, then it MUST eventually provide that VSC to all consumer chains.

"Register Maturity" properties. No mention of aggregated VSCs. So it's not clear how these properties apply to them. An aggregated VSC may not exactly match any sent VSC

The consumer chain MAY aggregate multiple VSCs before applying them to the validator set. However, ACKs are sent back for every VSCPacket (i.e., for every VSC). The "Register Maturity" properties are concern only with providing VSCs by the consumer chain and registering VSC maturity notifications on the provider chain. They don't have anything to do with aggregated VSCs.

Questions on "Technical Specification"

Interaction with staking module. Don't we need to modify it? ... so that it doesn't enforce the local unbonding period?

The completion of unbonding operations is specified in the next iteration (#646)

Provider CCV module initialized at genesis. So how do we add support to existing chains?

Hard forks.

josef-widder · 2022-01-25T14:10:35Z

"Valid Blockchain" means basically that the security model holds. In the case of Tendermint: <1/3 faulty validators. The properties, we actually need

no forks. This ensures that a chain A header seen by B actually corresponds to a block of A
valid transitions on A, that is, chain A executed the state machine properly. This ensures that a packet appears to be sent on chain A only if sendPacket has been called.

Together this ensures that

if a packet from A is received by B it actually has been sent by A.
If chain B received a validator set change, this change actually was correctly computed on A
if an ACK packet was received on chain A, the ACK was correctly computed on B, that is, the unbonding period passed

From another viewpoint, if the provider chain does arbitrary state transitions (or if there is a fork that is installed on the consumer's light client), we cannot guarantee a lot on the consumer chain.

Yes, it makes sense to make this clear in the specification.

mpoke · 2022-01-25T15:00:55Z

"Valid Blockchain" means basically that the security model holds. In the case of Tendermint: <1/3 faulty validators. The properties, we actually need

no forks. This ensures that a chain A header seen by B actually corresponds to a block of A

valid transitions on A, that is, chain A executed the state machine properly.

I would also add progress here, i.e., we assume both chains make progress.

In general, the "Valid Blockchain" assumption entails that

the underlying consensus engine satisfies both safety and liveness (i.e., no forks and eventually add new blocks);
the execution of the state machine follows the described protocol (e.g., when receiving the first VSCPacket, the consumer chain sets the CCV channel to VALIDATING).

@josef-widder do you see any other requirements that are included into the "Valid Blockchain" assumption? I agree that this assumption is necessary to ensure all the properties of IBC packets.

I do though abuse a bit the "Valid Blockchain" assumption in the argument of correctness. Probably I should point directly to the functions in the Technical Specification that describe the functionality provided by CCV.

josef-widder · 2022-01-25T15:09:51Z

@josef-widder do you see any other requirements that are included into the "Valid Blockchain" assumption? I agree that this assumption is necessary to ensure all the properties of IBC packets.

I think that is basically it. I agree that liveness also should be in the picture. But perhaps it makes sense to separate safety and liveness? In my mind "valid" was only concerned with the safety part. (As the "validity" property in typical consensus definitions).

I do though abuse a bit the "Valid Blockchain" assumption in the argument of correctness. Probably I should point directly to the functions in the Technical Specification that describe the functionality provided by CCV.

At least it would be good to understand which property depend on which assumptions. If this is clear, we don't need to go into too much detail in the correctness arguments.

… and sys inv

sergio-mena · 2022-01-25T17:13:06Z

@sergio-mena Thanks for the feedback. I replied to all comments inline.

@mpoke My pleasure. I just included here comments where I have something to reply.

So unbonding is now governed by the slowest consumer chain... what if a consumer chain gets stuck? Is this scalable?

If the consumer gets stuck, the unbonding cannot complete. Not sure I understand the second question. What do you mean by scalable?

Forget about the word "scalable" here. It was a poor choice on my side (I was meaning, scalable as the number of consumer chains grows). Basically, my question here is already fully addressed here and in the general comment.

"Validator Update To VSC Validity" doesn't mention slashing, should it?

No. Slashing is a feature not yet specified. But why should Validator Update To VSC Validity mention slashing?

The property itself is good. My comment was rather relating to the text between parentheses "i.e., resulted from a change in the amount of bonded tokens on the provider chain". Maybe a way to address my comment could be to change "i.e." by "e.g." there

"Validator Update To VSC Liveness" you could actually relax it to "a consumer chain" without loss of generality

Not really. I want it to include also Provide VSC uniformity, i.e., If the provider chain provides a VSC to a consumer chain, then it MUST eventually provide that VSC to all consumer chains.

Fair enough. When I work with properties for specs, I try to make each of them as simple as possible, assuming their actual usefulness comes when considered together, hence my comment. But I'm lacking context here to clearly see what's best.

mpoke · 2022-01-25T17:36:00Z

Added the following changes in commit ab41f91

Extra assumptions needed from the staking module.
Correctness argument of properties concerning the staking module interface.
Correctness argument of system invariants.

mpoke · 2022-01-25T17:49:39Z

"Validator Update To VSC Validity" doesn't mention slashing, should it?

No. Slashing is a feature not yet specified. But why should Validator Update To VSC Validity mention slashing?

The property itself is good. My comment was rather relating to the text between parentheses "i.e., resulted from a change in the amount of bonded tokens on the provider chain". Maybe a way to address my comment could be to change "i.e." by "e.g." there

@sergio-mena But slashing is "a change in the amount of bonded tokens". It's a forced change, not user initiated, but a change nonetheless.

spec/app/ics-028-cross-chain-validation/system_model_and_properties.md

sergio-mena · 2022-01-26T08:33:17Z

"Validator Update To VSC Validity" doesn't mention slashing, should it?

No. Slashing is a feature not yet specified. But why should Validator Update To VSC Validity mention slashing?

The property itself is good. My comment was rather relating to the text between parentheses "i.e., resulted from a change in the amount of bonded tokens on the provider chain". Maybe a way to address my comment could be to change "i.e." by "e.g." there

@sergio-mena But slashing is "a change in the amount of bonded tokens". It's a forced change, not user initiated, but a change nonetheless.

That's true. Maybe less obvious when you read it, but yes the sentence is correct

AdityaSripal

Partial review. Will continue going through it in the next couple of days

spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md

AdityaSripal · 2022-01-26T17:54:25Z

spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md

+  - *OnChanOpenInit*: On receiving the *FIRST* `ChanOpenInit` message, the consumer CCV module sets the status of its end of the CCV channel to `INITIALIZING`.
+  - *OnChanOpenTry*: On receiving the *FIRST* `ChanOpenTry` message, the provider CCV module sets the status of its end of the CCV channel to `INITIALIZING`.
+  - *OnChanOpenConfirm*: On receiving the *FIRST* `ChanOpenConfirm` message, the provider CCV module sets the status of its end of the CCV channel to `VALIDATING`.
+- **Channel completion**: Once the provider chain sets the status of the CCV channel to `VALIDATING`, it provides a VSC (i.e., validator set change) to the consumer chain (see [next section](#validator-set-update)). On receiving the *FIRST* `VSCPacket`, the consumer CCV module sets the status of its end of the CCV channel to `VALIDATING`. 


We should discuss if this is necessary. It was written this way so that we have a single unique channel, even if provider chain code is incorrect for some reason. But this is an odd defensive maneuver especially since elsewhere we assume provider ccv module is correct.

We can simplify by just setting VALIDATING on confirm of the consumer chain

You mean on ChanOpenAck on the consumer chain, right?

I kind of took this design for granted since it was already there when I joined the project. But yeah, I guess that since on ChanOpenAck the consumer sets the channel to OPEN, it can also set it as VALIDATING. This would actually enable the consumer to send Distribution / Evidence packets before the first VSC packet is received from the provider, which means rewarding or slashing the initial validator set. Plus, it avoids the corner case when the validator set never changes.

@josef-widder Do you see any issue with this change?

I talked with Josef about this and we agreed to have a chat with Jovan to figure out if we could actually drop the VALIDATING state completely.

My suggestion would be:

validators cannot unbond during the initialization protocol (no ACKs);

as a result, the initial validator set on the consumer chain is trust worthy and the consumer chain can already accept TXs;

a consumer chain is registered on the provider as soon as the governance proposal passes (the channel doesn't have to be initialized);

for every valset update, send a VSC packet to all registered consumer chains w/ an open channel; if the channel is not open yet, queue the VSC packets to send them later (once the channel is initialized);

for unbonding, any initiated unbonding operations must wait for ACKs from all registered channels (see PR ICS28: CCV draft w/ complete unbonding #646)

@AdityaSripal Do you see any reason to keep the VALIDATING / INITIALIZING states?

spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md

mpoke · 2022-01-26T18:30:19Z

The changes in 0d9edad remove dependencies of the CCV spec to Cosmos SDK.

@josef-widder Do you agree that CCV is actually a module in an ABCI application that depends on functionalities provided by a Staking module (that implements PoS) and a Governance module (that allows for proposals to be voted upon)?

…marius/ccv-init-and-vsc

AdityaSripal

Finished a first run-through of the spec. Great work!

spec/app/ics-028-cross-chain-validation/system_model_and_properties.md

spec/app/ics-028-cross-chain-validation/technical_specification.md

…rties.md Co-authored-by: Aditya <[email protected]>

…marius/ccv-init-and-vsc

* ICS 28 CCV draft w/ init and validator set update (#640) * Create README.md * Add files with CCV spec * fix links to ICS 4 * fix links to ICS 7 * add ICS 28 to main README.md * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/system_model_and_properties.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/technical_specification.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/README.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/README.md Co-authored-by: Sergio Mena <[email protected]> * minor, remove confusing phrasing * child -> consumer; parent -> provider * clarify which staking module * extend staking assumptions, remove redundant inv, prove staking props and sys inv * break long lines * break long lines * remove dependecies to Cosmos SDK * changes in the security model * specify multiple consumer chains * channel init overview * split Valid Blockchain assumption * minor changes after discussion w/ Josef * make the split of Valid Blockchain consistent * Update spec/app/ics-028-cross-chain-validation/system_model_and_properties.md Co-authored-by: Aditya <[email protected]> * Update spec/app/ics-028-cross-chain-validation/system_model_and_properties.md Co-authored-by: Aditya <[email protected]> * resolve conversations Co-authored-by: Sergio Mena <[email protected]> Co-authored-by: Aditya <[email protected]> * merge CODEOWNERS from master * ICS28: CCV draft w/ complete unbonding (#646) * Create README.md * Add files with CCV spec * fix links to ICS 4 * fix links to ICS 7 * add ICS 28 to main README.md * adding tech spec for unbonding delegations * add context on unbonding operations * add unbonding operation diagram * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/system_model_and_properties.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/technical_specification.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/README.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/README.md Co-authored-by: Sergio Mena <[email protected]> * minor, remove confusing phrasing * child -> consumer; parent -> provider * clarify which staking module * extend staking assumptions, remove redundant inv, prove staking props and sys inv * modify staking hooks spec to cover other unbonding ops * provider Staking module * break long lines * break long lines * remove dependecies to Cosmos SDK * changes in the security model * specify multiple consumer chains * channel init overview * address issues #27 and #33 from cosmos/interchain-security repo * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Josef Widder <[email protected]> Co-authored-by: Sergio Mena <[email protected]> Co-authored-by: Josef Widder <[email protected]> * ICS28: Extend consumer InitGenesis (#659) * Create README.md * Add files with CCV spec * fix links to ICS 4 * fix links to ICS 7 * add ICS 28 to main README.md * adding tech spec for unbonding delegations * add context on unbonding operations * add unbonding operation diagram * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/system_model_and_properties.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/technical_specification.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/README.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/README.md Co-authored-by: Sergio Mena <[email protected]> * minor, remove confusing phrasing * child -> consumer; parent -> provider * clarify which staking module * extend staking assumptions, remove redundant inv, prove staking props and sys inv * modify staking hooks spec to cover other unbonding ops * provider Staking module * break long lines * break long lines * remove dependecies to Cosmos SDK * changes in the security model * specify multiple consumer chains * channel init overview * address issues #27 and #33 from cosmos/interchain-security repo * extend consumer InitGenesis * describe mechanism to disseminate genesis state * remove ExportGenesis and restarted chains * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Josef Widder <[email protected]> * validate channel IDs on provider genesis Co-authored-by: Sergio Mena <[email protected]> Co-authored-by: Josef Widder <[email protected]> * ICS28: Consumer Initiated Slashing (aka Evidence) (#663) * Create README.md * Add files with CCV spec * fix links to ICS 4 * fix links to ICS 7 * add ICS 28 to main README.md * adding tech spec for unbonding delegations * add context on unbonding operations * add unbonding operation diagram * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/system_model_and_properties.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/technical_specification.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/README.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/README.md Co-authored-by: Sergio Mena <[email protected]> * minor, remove confusing phrasing * child -> consumer; parent -> provider * clarify which staking module * extend staking assumptions, remove redundant inv, prove staking props and sys inv * modify staking hooks spec to cover other unbonding ops * provider Staking module * break long lines * break long lines * remove dependecies to Cosmos SDK * changes in the security model * specify multiple consumer chains * channel init overview * address issues #27 and #33 from cosmos/interchain-security repo * extend consumer InitGenesis * describe mechanism to disseminate genesis state * describe mapping heights provider <> consumer * remove ExportGenesis and restarted chains * add overview of consumer initiated slashing * add slashing invariant * add assumptions needed by evidence * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Josef Widder <[email protected]> * draft CCV props for slashing * replace time w/ height; add HtoVSC and VSCtoH * replace time with height in invariants and properties * validate channel IDs on provider genesis * prove Slashing Invariant * enable mapping from consumer to provider heights * technical spec for slashing * minor changes * fix links to tendermint spec * clarify Staking vs Slashing modules * replace VSC acks w/ VSCMaturedPackets * fix some TODOs * fix properties * HtoVSC and VSCtoH from () to [] * fix infraction height and add intuition diagram * keep ValidatorSet in consumer CCV module state * add outstanding downtime flag and decouple from validatorSet * fix issues pointed by Simon * dealing with downtime slashing atomicity * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Aditya <[email protected]> * addressing Aditya's comments * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Josef Widder <[email protected]> * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Josef Widder <[email protected]> * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Josef Widder <[email protected]> * Update spec/app/ics-028-cross-chain-validation/technical_specification.md Co-authored-by: Josef Widder <[email protected]> * Update spec/app/ics-028-cross-chain-validation/technical_specification.md Co-authored-by: Josef Widder <[email protected]> * addressing Josef's comments * link TODOs with issues * Update spec/app/ics-028-cross-chain-validation/system_model_and_properties.md Co-authored-by: Aditya <[email protected]> * Update spec/app/ics-028-cross-chain-validation/system_model_and_properties.md Co-authored-by: Aditya <[email protected]> * apply suggestions from code review * cleanup outdated note on restarted consumer chains Co-authored-by: Sergio Mena <[email protected]> Co-authored-by: Josef Widder <[email protected]> Co-authored-by: Aditya <[email protected]> * ICS28: Remove CCV channel state (#678) * Create README.md * Add files with CCV spec * fix links to ICS 4 * fix links to ICS 7 * add ICS 28 to main README.md * adding tech spec for unbonding delegations * add context on unbonding operations * add unbonding operation diagram * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/system_model_and_properties.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/technical_specification.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/README.md Co-authored-by: Sergio Mena <[email protected]> * Update spec/app/ics-028-cross-chain-validation/README.md Co-authored-by: Sergio Mena <[email protected]> * minor, remove confusing phrasing * child -> consumer; parent -> provider * clarify which staking module * extend staking assumptions, remove redundant inv, prove staking props and sys inv * modify staking hooks spec to cover other unbonding ops * provider Staking module * break long lines * break long lines * remove dependecies to Cosmos SDK * changes in the security model * specify multiple consumer chains * channel init overview * address issues #27 and #33 from cosmos/interchain-security repo * extend consumer InitGenesis * describe mechanism to disseminate genesis state * describe mapping heights provider <> consumer * remove ExportGenesis and restarted chains * add overview of consumer initiated slashing * add slashing invariant * add assumptions needed by evidence * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Josef Widder <[email protected]> * draft CCV props for slashing * replace time w/ height; add HtoVSC and VSCtoH * replace time with height in invariants and properties * validate channel IDs on provider genesis * prove Slashing Invariant * enable mapping from consumer to provider heights * technical spec for slashing * minor changes * fix links to tendermint spec * clarify Staking vs Slashing modules * replace VSC acks w/ VSCMaturedPackets * fix some TODOs * fix properties * HtoVSC and VSCtoH from () to [] * fix infraction height and add intuition diagram * keep ValidatorSet in consumer CCV module state * remove CCV channel status * add outstanding downtime flag and decouple from validatorSet * adressing Josef's comment * fix issues pointed by Simon * dealing with downtime slashing atomicity * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Aditya <[email protected]> * addressing Aditya's comments * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Josef Widder <[email protected]> * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Josef Widder <[email protected]> * Update spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md Co-authored-by: Josef Widder <[email protected]> * Update spec/app/ics-028-cross-chain-validation/technical_specification.md Co-authored-by: Josef Widder <[email protected]> * Update spec/app/ics-028-cross-chain-validation/technical_specification.md Co-authored-by: Josef Widder <[email protected]> * addressing Josef's comments * link TODOs with issues * Update spec/app/ics-028-cross-chain-validation/system_model_and_properties.md Co-authored-by: Aditya <[email protected]> * Update spec/app/ics-028-cross-chain-validation/system_model_and_properties.md Co-authored-by: Aditya <[email protected]> * apply suggestions from code review * cleanup outdated note on restarted consumer chains Co-authored-by: Sergio Mena <[email protected]> Co-authored-by: Josef Widder <[email protected]> Co-authored-by: Aditya <[email protected]> * Update technical_specification.md Fix typo: VSCtoH replaced with HtoVSC in SendSlashRequest * ICS28: Replace "Initiator" w/ "Caller" and “Trigger Event” (#696) * update init methods and ics26 methods * updating ValSet Update methods * updating Consumer Initiated Slashing methods * ICS28: Handle pending proposals to spawn consumer chains (#697) * handle pending proposals * ICS28: Remove genesisHash from specification (#699) * remove genesis hash * remove details of genesis state dissemination * ICS28: CCV Reward Distribution subprotocol (#704) * add overview of reward distribution * add CCVHandshakeMetadata and update channel handshake methods signatures * initiate opening handshake for transfer channel * add DistributeRewards() method * address review comments * add distribution invariant * replace system invariants with system properties Co-authored-by: Josef Widder <[email protected]> * ICS28: Set initH in onChanOpenConfirm (#705) * set initH in onChanOpenConfirm * replace initH with initialHeights * ICS28: Enable the removal of a consumer chain from the provider (#707) * stopping a consumer chain * deal with timeouts on the consumer side * fix typo * add note on how to shut down the consumer * add note on safety implication of lockUnbondingOnTimeout * ICS28: Remove BeforeUnbondingOpCompleted (#711) * remove BeforeUnbondingOpCompleted hook * cleanup method names * ICS28: Update SlashPacketData (#728) * update SlashPacket * ICS28: Remove dependency on Tendermint and ABCI (#730) * remove mention of V2 * remove ABCI dependency from overview; also small fixes * remove dependencies from system model and README * remove dependencies from tech spec * call UnbondMaturePackets() earlier (#747) * fix edge case enabled by aggregation (#746) * Use `h < hp'` instead of `h <= hp'` in Bond-Based Consumer Voting Power (#749) * replace slashRequests w/ downtimeSlashRequests (#745) * ics28 update sendPacket (#756) * ICS28: Restructure technical spec (#760) * split technical spec into two files * restructure methods and subprotocols * add links to readme.md * fix typo - initH replaced w/ initialHeights * ICS28: Unbonding ops are put on hold even w/o consumer chains (#763) * PutUnbondingOnHold only if consumer chains exist * Use currentTimestamp() >= p.stopTime in StopConsumerChainProposalHandler (#769) Tackle #768 * adding consumerUnbondingPeriod (#771) * fix sendFungibleTokens signature * add authors * ICS28: Removing the only consumer chain (#770) * remove unbonding op with no consumer chains * add postcondition * add conditions for CreateConsumerClient and StopConsumerChain (#775) * update created date * ICS28: Account for slashing in Bond-Based Consumer Voting Power property (#793) * extend Bond-Based Consumer Voting Power w/ slashing * fix Bond-Based Consumer Voting Power formula * expand note for clarity * add pUnbonding * Update spec/app/ics-028-cross-chain-validation/system_model_and_properties.md Co-authored-by: Josef Widder <[email protected]> * clarify mathematical writeup of property * Update spec/app/ics-028-cross-chain-validation/system_model_and_properties.md Co-authored-by: Josef Widder <[email protected]> * Update spec/app/ics-028-cross-chain-validation/system_model_and_properties.md Co-authored-by: Josef Widder <[email protected]> * Update spec/app/ics-028-cross-chain-validation/system_model_and_properties.md Co-authored-by: Josef Widder <[email protected]> * make changes to sumUnbonding / sumSlash consistent * add history Co-authored-by: Josef Widder <[email protected]> Co-authored-by: Sergio Mena <[email protected]> Co-authored-by: Aditya <[email protected]> Co-authored-by: Josef Widder <[email protected]> Co-authored-by: Daniel T <[email protected]>

mpoke added 5 commits January 17, 2022 22:08

Create README.md

604b3ae

Add files with CCV spec

a9b6dad

fix links to ICS 4

312d108

fix links to ICS 7

4f2b2f8

add ICS 28 to main README.md

0f826ac

mpoke self-assigned this Jan 18, 2022

mpoke requested review from AdityaSripal, cezarad and cwgoes as code owners January 18, 2022 13:06

sergio-mena suggested changes Jan 24, 2022

View reviewed changes

mpoke and others added 7 commits January 25, 2022 12:06

Update spec/app/ics-028-cross-chain-validation/overview_and_basic_con…

6085697

…cepts.md Co-authored-by: Sergio Mena <[email protected]>

Update spec/app/ics-028-cross-chain-validation/overview_and_basic_con…

d2b7377

…cepts.md Co-authored-by: Sergio Mena <[email protected]>

Update spec/app/ics-028-cross-chain-validation/system_model_and_prope…

b132122

…rties.md Co-authored-by: Sergio Mena <[email protected]>

Update spec/app/ics-028-cross-chain-validation/technical_specificatio…

e470c84

…n.md Co-authored-by: Sergio Mena <[email protected]>

Update spec/app/ics-028-cross-chain-validation/README.md

28e7131

Co-authored-by: Sergio Mena <[email protected]>

Update spec/app/ics-028-cross-chain-validation/README.md

4bdcd8b

Co-authored-by: Sergio Mena <[email protected]>

minor, remove confusing phrasing

dee8d30

mpoke added 3 commits January 25, 2022 17:07

child -> consumer; parent -> provider

db69640

clarify which staking module

35cdcd8

extend staking assumptions, remove redundant inv, prove staking props…

ab41f91

… and sys inv

mpoke added 2 commits January 25, 2022 19:09

break long lines

9ef5aef

break long lines

bdf3c48

mpoke commented Jan 25, 2022

View reviewed changes

spec/app/ics-028-cross-chain-validation/system_model_and_properties.md Outdated Show resolved Hide resolved

AdityaSripal reviewed Jan 26, 2022

View reviewed changes

remove dependecies to Cosmos SDK

0d9edad

mpoke added 3 commits January 27, 2022 11:12

changes in the security model

08ceb8a

specify multiple consumer chains

5c7da62

channel init overview

9d25746

mpoke removed the request for review from cezarad January 28, 2022 12:45

mpoke added 4 commits January 28, 2022 13:55

split Valid Blockchain assumption

fd4f1bc

minor changes after discussion w/ Josef

7718fd3

Merge branch 'marius/ccv-init-and-vsc' of github.com:cosmos/ibc into …

92344a7

…marius/ccv-init-and-vsc

make the split of Valid Blockchain consistent

67ec931

AdityaSripal reviewed Jan 28, 2022

View reviewed changes

mpoke and others added 4 commits January 29, 2022 19:13

Update spec/app/ics-028-cross-chain-validation/system_model_and_prope…

6ae3577

…rties.md Co-authored-by: Aditya <[email protected]>

Update spec/app/ics-028-cross-chain-validation/system_model_and_prope…

d2a0dba

…rties.md Co-authored-by: Aditya <[email protected]>

resolve conversations

9b2b98c

Merge branch 'marius/ccv-init-and-vsc' of github.com:cosmos/ibc into …

f851913

…marius/ccv-init-and-vsc

mpoke merged commit 79becaf into marius/ccv Feb 10, 2022

mpoke deleted the marius/ccv-init-and-vsc branch February 10, 2022 10:54

mpoke restored the marius/ccv-init-and-vsc branch February 10, 2022 11:02

mpoke deleted the marius/ccv-init-and-vsc branch February 14, 2022 10:14

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ICS 28 CCV draft w/ init and validator set update #640

ICS 28 CCV draft w/ init and validator set update #640

mpoke commented Jan 18, 2022

sergio-mena commented Jan 24, 2022

sergio-mena left a comment

mpoke commented Jan 25, 2022 •

edited

Loading

josef-widder commented Jan 25, 2022 •

edited

Loading

mpoke commented Jan 25, 2022

josef-widder commented Jan 25, 2022

sergio-mena commented Jan 25, 2022

mpoke commented Jan 25, 2022

mpoke commented Jan 25, 2022

sergio-mena commented Jan 26, 2022

AdityaSripal left a comment

AdityaSripal Jan 26, 2022

mpoke Jan 27, 2022

mpoke Jan 28, 2022

mpoke commented Jan 26, 2022

AdityaSripal left a comment

ICS 28 CCV draft w/ init and validator set update #640

ICS 28 CCV draft w/ init and validator set update #640

Conversation

mpoke commented Jan 18, 2022

sergio-mena commented Jan 24, 2022

sergio-mena left a comment

Choose a reason for hiding this comment

mpoke commented Jan 25, 2022 • edited Loading

josef-widder commented Jan 25, 2022 • edited Loading

mpoke commented Jan 25, 2022

josef-widder commented Jan 25, 2022

sergio-mena commented Jan 25, 2022

mpoke commented Jan 25, 2022

mpoke commented Jan 25, 2022

sergio-mena commented Jan 26, 2022

AdityaSripal left a comment

Choose a reason for hiding this comment

AdityaSripal Jan 26, 2022

Choose a reason for hiding this comment

mpoke Jan 27, 2022

Choose a reason for hiding this comment

mpoke Jan 28, 2022

Choose a reason for hiding this comment

mpoke commented Jan 26, 2022

AdityaSripal left a comment

Choose a reason for hiding this comment

mpoke commented Jan 25, 2022 •

edited

Loading

josef-widder commented Jan 25, 2022 •

edited

Loading