Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add verifiable upgrade type and validate basic functions #3451
Add verifiable upgrade type and validate basic functions #3451
Changes from 6 commits
995c1f1
f8f6ad4
808ec70
8dd0c44
64878ae
837e3c9
5f9ad67
04dd0af
d66fe9d
18dbffe
a3da022
9b71740
7215e84
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Personally I prefer just doing the check explicitly in here rather than adding another expected keeper interface method but happy to keep this as is if there's consensus on adding this instead.
My vote would be for doing the check directly here.
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.
The idea is that this could be used in many other places, it also covers the not found case. Quickly looking it looks like we have around 7 other duplicate checks.
My preference would be to re-use this helper
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.
I agree with @damiannolan. I think also the
CheckIsOpen
function should anyway return a boolean (unless we rename it toCheckExistsAndIsOpen
, since it is actually checking two things). In my opinion I would just do the explicit check here.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.
yeah there was a bit of bike-shedding over the name/scope of this function between us. Initially we had it as
IsOpen
with a single boolean return but that didn't make it as self contained as we'd like. Returning the error allowed it to basically also check for any required error conditions and return them, simplifying the validation, hence the rename toCheckIsOpen
.Cian did say this function might not fly with everyone though 😄
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.
I'm happy to just remove the function entirely and do the explicit checking where needed! 👍
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.
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.
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.
I guess we should add test cases for empty channel version, packet sent and the upgrade timeout.
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.
I think these should be tested in a separate test that tests validate basic. This PR is already quite large, are you happy if we create a follow up PR to add tests for ValidateBasic of
UpgradeFields
andUpgrade
?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.
leave this todo in? I remember we talked about it being sensible if its zero (i.e channel which has just opened) but maybe it makes sense to leave it around for another pair of eyes to check?
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.
Yes I think 0 should technically be a valid value (no packets sent yet), maybe @colin-axner / @AdityaSripal could confirm if we should let 0 be an accepted value here?
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.
Packet sequences start at 1. But iirc from yesterday this value can be determined within the state machine in
WriteChanUpgradeInit()
as opposed to expecting a user provided valueThere 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.
validate basic of the message should then check for
>= 1
right? Even if it is determined within the state machine it should still be validated here if possible I think.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.
Maybe we should remove this function? I think we should have
MsgUpgradeInit
andMsgUpgradeTry
use theUpgradeFields
andUpgradeTimeout
directly rather than wrapping withUpgrade
. I suggest this because it seems unnecessary to expose a field populated by the state machine to the relayer. This would render thisValidateBasic
unnecessary as the msg should do basic validation on the fields and timeout and then the state machine would construct the upgrade type with the fields, timeout and retrieved packet sequence send. I guess we could keep if for the situation where the entire counterparty upgrade type is provided in the TRY and ACK, in this situation the sequence should not equal 0.My vote is to modify the init/try field for self upgrade to use the fields/timeout directly in the msg type and add a if sequence != 0 check to be used to verify the fully formed counterparty upgrade
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.
sounds good to me
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.
Yeah I'm happy enough with that approach 👍
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.
Ah, just realising the message modification will cause a bigger diff with the OnChanInit keeper func which is being addressed in a follow up. @colin-axner are you happy if the message structure gets updated (and this validate basic removed) in a follow up?
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.
Absolutely!
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.