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.

Sign up for GitHub

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

fix typos in ics-004-channel-and-packet-semantics/UPGRADES.md #1042

Merged
merged 1 commit into from
Nov 27, 2023
Merged

fix typos in ics-004-channel-and-packet-semantics/UPGRADES.md #1042

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
6 changes: 3 additions & 3 deletions spec/core/ics-004-channel-and-packet-semantics/UPGRADES.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,7 @@ enum ChannelState {

- In `ChanUpgradeInit`, the initializing chain that is proposing the upgrade should store the channel upgrade.
- The counterparty chain executing `ChanUpgradeTry` that accepts the upgrade should store the channel upgrade, set the channel state from `OPEN` to `FLUSHING`, and start the flushing timer by storing an upgrade timeout.
- Once the initiating chain verifies the counterparty is in `FLUSHING`, it must also move to `FLUSHING` unless all in-flight packets are already flushed on both ends, in which case it must move directly to `FLUSHCOMPLETE`. The initator will also store the counterparty timeout to ensure it does not move to `FLUSHCOMPLETE` after the counterparty timeout has passed.
- Once the initiating chain verifies the counterparty is in `FLUSHING`, it must also move to `FLUSHING` unless all in-flight packets are already flushed on both ends, in which case it must move directly to `FLUSHCOMPLETE`. The initiator will also store the counterparty timeout to ensure it does not move to `FLUSHCOMPLETE` after the counterparty timeout has passed.
- The counterparty chain must prove that the initiator is also in `FLUSHING` or completed flushing in `FLUSHCOMPLETE`. The counterparty will store the initiator timeout to ensure it does not move to `FLUSHCOMPLETE` after the initiator timeout has passed.

`FLUSHING` is a "blocking" state in that they will prevent the upgrade handshake from proceeding until the in-flight packets on both channel ends are flushed. Once both sides have moved to `FLUSHCOMPLETE`, a relayer can prove this on both ends with `ChanUpgradeOpen` to open the channel on both sides with the new parameters.
Expand Down Expand Up @@ -354,7 +354,7 @@ function restoreChannel(
channel = provableStore.get(channelPath(portIdentifier, channelIdentifier))
errorReceipt = ErrorReceipt{
channel.upgradeSequence,
"upgrade handshake is aborted", // constant string changable by implementation
"upgrade handshake is aborted", // constant string changeable by implementation
}
provableStore.set(channelUpgradeErrorPath(portIdentifier, channelIdentifier), errorReceipt)
channel.state = OPEN
Expand Down Expand Up @@ -560,7 +560,7 @@ function chanUpgradeTry(
if counterpartyUpgradeSequence < channel.upgradeSequence {
errorReceipt = ErrorReceipt{
channel.upgradeSequence - 1,
"sequence out of sync", // constant string changable by implementation
"sequence out of sync", // constant string changeable by implementation
}
provableStore.set(channelUpgradeErrorPath(portIdentifier, channelIdentifier), errorReceipt)
return
Expand Down