From e39fd7dab74a7feef43513a734396611b570cead Mon Sep 17 00:00:00 2001 From: Kevin Heavey Date: Sat, 25 Nov 2023 13:06:04 +0400 Subject: [PATCH] fix typos --- spec/core/ics-004-channel-and-packet-semantics/UPGRADES.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/spec/core/ics-004-channel-and-packet-semantics/UPGRADES.md b/spec/core/ics-004-channel-and-packet-semantics/UPGRADES.md index ed58122ac..1eb8bad1a 100644 --- a/spec/core/ics-004-channel-and-packet-semantics/UPGRADES.md +++ b/spec/core/ics-004-channel-and-packet-semantics/UPGRADES.md @@ -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. @@ -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 @@ -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