You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The provider chain should be able to remove a consumer chain, i.e., clean up the state and enable the completion of unbonding operations that were waiting for that consumer chain.
IMO this removal should be triggered by only two events,
either a governance proposal (on the provider) to stop providing security to a consumer chain
or the channel timeouts, which we assume it doesn’t, but we still need to do something when this assumption fails.
In my understanding, anyone (that knows the port and the channel ID) can send a ChannelCloseInit to the provider CCV module to close a CCV channel, right? The only way to implement some kind of access control is in OnChanCloseInit, right? I’m not sure though how to implement such access control, i.e., who can close a channel? Thus, I’d leave the logic inside OnChanCloseInit to abort any attempt to close the channel.
Instead, I suggest creating a handler of a new governance proposal (e.g., StopConsumerChainProposal) where we add all the cleanup logic. The same logic we add also in the OnTimeoutPacket handler on the provider.
What happens if the consumer chain’s channel end timeouts? This means that channel end moves to CLOSED. How will the provider find out about this? ACKs are no longer send back to the provider. Eventually the VSCPackets sent by the provider will timeout (since nobody will receive them). However, this requires for the timeout period to expire, which is very large to avoid timeouts :)
The text was updated successfully, but these errors were encountered:
The provider chain should be able to remove a consumer chain, i.e., clean up the state and enable the completion of unbonding operations that were waiting for that consumer chain.
IMO this removal should be triggered by only two events,
In my understanding, anyone (that knows the port and the channel ID) can send a
ChannelCloseInit
to the provider CCV module to close a CCV channel, right? The only way to implement some kind of access control is inOnChanCloseInit
, right? I’m not sure though how to implement such access control, i.e., who can close a channel? Thus, I’d leave the logic insideOnChanCloseInit
to abort any attempt to close the channel.Instead, I suggest creating a handler of a new governance proposal (e.g.,
StopConsumerChainProposal
) where we add all the cleanup logic. The same logic we add also in theOnTimeoutPacket
handler on the provider.What happens if the consumer chain’s channel end timeouts? This means that channel end moves to CLOSED. How will the provider find out about this? ACKs are no longer send back to the provider. Eventually the VSCPackets sent by the provider will timeout (since nobody will receive them). However, this requires for the timeout period to expire, which is very large to avoid timeouts :)
The text was updated successfully, but these errors were encountered: