-
Notifications
You must be signed in to change notification settings - Fork 420
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
Put the path choices in clients instead of spec-wide #293
Conversation
|
Note that this also makes the canonical encoding client-type-specific, which I think is desirable. |
Merging since we concurred in the meeting & I want to avoid conflicts. Glad to walk anyone through. |
height: uint64, | ||
proof: CommitmentProof, | ||
connectionIdentifier: Identifier, | ||
connectionEnd: ConnectionEnd) { |
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.
why are here 2 connection ends?
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 second connectionEnd
is the part actually being verified.
The first is the local connection.
proof: CommitmentProof, | ||
connectionIdentifier: Identifier, | ||
connectionEnd: ConnectionEnd) { | ||
client = queryClient(connection.clientIdentifier) |
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.
should be client state
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.
Why? The idea is that the client exposes this function.
connectionIdentifier: Identifier, | ||
connectionEnd: ConnectionEnd) { | ||
client = queryClient(connection.clientIdentifier) | ||
return client.verifyConnectionState(connection, height, connection.counterpartyPrefix, proof, connectionIdentifier, connectionEnd) |
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.
should be
client.verifyConnectionState(clientState, height, connection.counterpartyPrefix, proof, connection.Identifier, connection)
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.
See above comment.
connection: ConnectionEnd, | ||
height: uint64, | ||
proof: CommitmentProof, | ||
connectionIdentifier: Identifier, |
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.
is this required?
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, we need to know the identifier to verify under.
path: Path, | ||
value: Value): bool { | ||
clientIdentifier: Identifier, | ||
consensusState: ConsensusState) { | ||
client = queryClient(connection.clientIdentifier) |
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.
ditto, should be client state
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.
See above comment.
client = queryClient(connection.clientIdentifier) | ||
client.verifyMembership(height, proof, applyPrefix(connection.counterpartyPrefix, path), value) | ||
return client.verifyClientConsensusState(connection, height, connection.counterpartyPrefix, proof, clientIdentifier, consensusState) |
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.
return client.verifyClientConsensusState(clientState, height, connection.counterpartyPrefix, proof, clientState.Identifier, consensusState)
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.
See above comment.
portIdentifier: Identifier, | ||
channelIdentifier: Identifier, | ||
channelEnd: ChannelEnd) { | ||
path = applyPrefix(prefix, "ports/{portIdentifier}/channels/{channelIdentifier}") |
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.
question: why do we want to expose the paths hardcoded on the client? do we expect ICS02 to be customized? Why not pass the path param directly instead of the prefix?
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.
These are example implementations, not necessarily required.
They will vary per client type. See #286
Closes #288