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.

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

Merged
merged 9 commits into from
Oct 28, 2019

Conversation

cwgoes
Copy link
Contributor

@cwgoes cwgoes commented Oct 23, 2019

Closes #288

@cwgoes
Copy link
Contributor Author

cwgoes commented Oct 25, 2019

  • Update example code in ICS 2
  • Update connection call proxy

@cwgoes cwgoes marked this pull request as ready for review October 25, 2019 13:09
@cwgoes
Copy link
Contributor Author

cwgoes commented Oct 25, 2019

Note that this also makes the canonical encoding client-type-specific, which I think is desirable.

@cwgoes
Copy link
Contributor Author

cwgoes commented Oct 28, 2019

Merging since we concurred in the meeting & I want to avoid conflicts. Glad to walk anyone through.

@cwgoes cwgoes merged commit 5e425da into master Oct 28, 2019
@cwgoes cwgoes deleted the cwgoes/path-choices-in-clients branch October 28, 2019 15:25
height: uint64,
proof: CommitmentProof,
connectionIdentifier: Identifier,
connectionEnd: ConnectionEnd) {

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?

Copy link
Contributor Author

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)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be client state

Copy link
Contributor Author

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)

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)

Copy link
Contributor Author

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,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this required?

Copy link
Contributor Author

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)

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

Copy link
Contributor Author

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)

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)

Copy link
Contributor Author

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}")
Copy link

@fedekunze fedekunze Nov 21, 2019

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?

Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Put the path choices in clients
2 participants