-
Notifications
You must be signed in to change notification settings - Fork 636
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
feat: handler for ChanUpgradeTry
#3628
Changes from 113 commits
995c1f1
f8f6ad4
808ec70
8dd0c44
64878ae
51bb7a7
f203df9
837e3c9
5f9ad67
7bdf33c
13812eb
2f7d0fc
0b60a32
17c6379
28779f5
08af922
458b171
93db50e
b83849a
f29e2f8
134b5a2
5caa776
9fee155
09ddf84
8a710ff
ef0f3d9
8f36c16
0b36176
dfd9be3
f7eb3dd
c631e06
b8b5ca4
0e8092b
c7c7884
4c23aa5
59b86f1
8f0bfe9
72c7169
7be4d3d
2bc2901
6d8ae60
89f804d
1b813d2
a9a7f44
3f2e815
11e8ec2
5ae5eb4
b464f7f
ff64798
0bb2ec4
09de100
885112b
b64f04e
99c737e
2330bcf
5d539c3
8b50c87
3302d90
1eb0984
4f25273
af728d6
e80d0cd
7c0f0eb
dd0d947
68f0a41
b160d73
8a9e799
70630cc
6ef341d
c78f6c7
07759d9
804f6d0
3d99205
40ec564
45459d8
ac5b2d4
8eb28c2
ed6132f
05db79b
0ecc96f
134c459
9b42618
5d8c43d
d7fb83f
0e1250d
d3749df
f549077
649415b
4ba442b
70ae42a
df5319d
7ccc3e2
07c18e2
010ab73
3dda5e8
0ab93c4
eff04ae
6d5edfd
1ad8f8d
54ff9f7
e6de4e5
98846e0
3b2d33b
0bca504
2573e6b
164f03f
fc0fcca
22b1037
2b8cbb3
2943a8f
fba6fac
65df60b
e7fe924
e15bb28
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -9,6 +9,7 @@ import ( | |
"github.com/cosmos/cosmos-sdk/telemetry" | ||
sdk "github.com/cosmos/cosmos-sdk/types" | ||
|
||
"github.com/cosmos/ibc-go/v7/internal/collections" | ||
clienttypes "github.com/cosmos/ibc-go/v7/modules/core/02-client/types" | ||
connectiontypes "github.com/cosmos/ibc-go/v7/modules/core/03-connection/types" | ||
"github.com/cosmos/ibc-go/v7/modules/core/04-channel/types" | ||
|
@@ -67,21 +68,69 @@ func (k Keeper) WriteUpgradeInitChannel(ctx sdk.Context, portID, channelID strin | |
emitChannelUpgradeInitEvent(ctx, portID, channelID, currentChannel, upgrade) | ||
} | ||
|
||
// upgradeTry | ||
// ChanUpgradeTry is called by a module to accept the first step of a channel upgrade handshake initiated by | ||
// a module on another chain. If this function is successful, the proposed upgrade will be returned. If the upgrade fails, the upgrade sequence will still be incremented but an error will be returned. | ||
func (k Keeper) ChanUpgradeTry( | ||
ctx sdk.Context, | ||
portID, | ||
channelID string, | ||
proposedConnectionHops []string, | ||
upgradeTimeout types.Timeout, | ||
proposedUpgradeTimeout types.Timeout, | ||
counterpartyProposedUpgrade types.Upgrade, | ||
counterpartyUpgradeSequence uint64, | ||
proofCounterpartyChannel, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. for the actual proofs I find the name There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i spoke to @colin-axner about this, i think the issue is that this is the convention we currently use all over the rest of the codebase. i'm happy to open up an issue though to rename these params! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yea, happy to decide better naming, but nice to do it in one sweep through the codebase |
||
proofCounterpartyUpgrade []byte, | ||
proofHeight clienttypes.Height, | ||
) (types.Upgrade, error) { | ||
// TODO | ||
return types.Upgrade{}, nil | ||
channel, found := k.GetChannel(ctx, portID, channelID) | ||
if !found { | ||
return types.Upgrade{}, errorsmod.Wrapf(types.ErrChannelNotFound, "port ID (%s) channel ID (%s)", portID, channelID) | ||
} | ||
|
||
// the channel state must be in OPEN or INITUPGRADE if we are in a crossing hellos situation | ||
if !collections.Contains(channel.State, []types.State{types.OPEN, types.INITUPGRADE}) { | ||
return types.Upgrade{}, errorsmod.Wrapf(types.ErrInvalidChannelState, "expected one of [%s, %s], got %s", types.OPEN, types.INITUPGRADE, channel.State) | ||
} | ||
|
||
connectionEnd, err := k.GetConnection(ctx, channel.ConnectionHops[0]) | ||
if err != nil { | ||
return types.Upgrade{}, errorsmod.Wrap(err, "failed to retrieve connection using the channel connection hops") | ||
} | ||
|
||
// make sure connection is OPEN | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: I feel like this comment doesn't really add much value, I prefer to avoid inline comments which are self explanatory, this part of the code is self documenting and pretty obvious whats happening |
||
if connectionEnd.GetState() != int32(connectiontypes.OPEN) { | ||
return types.Upgrade{}, errorsmod.Wrapf( | ||
connectiontypes.ErrInvalidConnectionState, | ||
"connection state is not OPEN (got %s)", connectiontypes.State(connectionEnd.GetState()).String(), | ||
) | ||
} | ||
|
||
// check if packet is timed out on the receiving chain | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ditto re. this comment - this is also incorrect as it mentions packet but I understand this piece of timeout code will change later with the new |
||
if hasPassed, err := counterpartyProposedUpgrade.Timeout.HasPassed(ctx); hasPassed { | ||
// abort here and let counterparty timeout the upgrade | ||
return types.Upgrade{}, errorsmod.Wrap(err, "upgrade timeout has passed") | ||
} | ||
|
||
// assert that the proposed connection hops are compatible with the counterparty connection hops | ||
// the proposed connections hops must have a counterparty which matches the counterparty connection hops | ||
colin-axner marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
// construct counterpartyChannel from existing information and provided counterpartyUpgradeSequence | ||
|
||
// create upgrade fields from counterparty proposed upgrade and own verified connection hops | ||
|
||
// if OPEN, then initialize handshake with upgradeFields | ||
// this should validate the upgrade fields, set the upgrade path and set the final correct sequence. | ||
|
||
// otherwise, if the channel state is already in INITUPGRADE (crossing hellos case), | ||
// assert that the upgrade fields are the same as the upgrade already in progress | ||
|
||
// } else if channel.State == types.INITUPGRADE { | ||
|
||
// if the counterparty sequence is not equal to our own at this point, either the counterparty chain is out-of-sync or the message is out-of-sync | ||
// we write an error receipt with our own sequence so that the counterparty can update their sequence as well. | ||
// We must then increment our sequence so both sides start the next upgrade with a fresh sequence. | ||
var proposedUpgrade types.Upgrade | ||
return proposedUpgrade, nil | ||
} | ||
|
||
// WriteUpgradeTryChannel writes a channel which has successfully passed the UpgradeTry handshake step. | ||
|
@@ -255,13 +304,14 @@ func extractUpgradeFields(channel types.Channel) types.UpgradeFields { | |
|
||
// constructProposedUpgrade returns the proposed upgrade from the provided arguments. | ||
func (k Keeper) constructProposedUpgrade(ctx sdk.Context, portID, channelID string, fields types.UpgradeFields, upgradeTimeout types.Timeout) (types.Upgrade, error) { | ||
seq, found := k.GetNextSequenceSend(ctx, portID, channelID) | ||
nextSequenceSend, found := k.GetNextSequenceSend(ctx, portID, channelID) | ||
if !found { | ||
return types.Upgrade{}, types.ErrSequenceSendNotFound | ||
} | ||
|
||
return types.Upgrade{ | ||
Fields: fields, | ||
Timeout: upgradeTimeout, | ||
LatestSequenceSend: seq - 1, | ||
LatestSequenceSend: nextSequenceSend - 1, | ||
}, nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AdityaSripal is it intentional that the TRY step must use the same version as the counterparty? I don't see a mention in the spec for this reasoning. There's no check in
startFlushUpgradeHandshake
for this (potentially because we automatically use the counterparty upgrade version, but there is a check for the ordering being the same (despite the fact we also use the counterparty upgrade ordering), so there's an inconsistency in construction