02-client-TAOv2 #1147
02-client-TAOv2 #1147
Conversation
sangier
requested review from
AdityaSripal,
angbrav,
colin-axner and
damiannolan
as code owners
|
|
||
| ```typescript | ||
| interface Counterparty { | ||
| channelId: Identifier |
There was a problem hiding this comment.
Shall we change all the channelID references to clientIDs?
There was a problem hiding this comment.
I think we should keep this in ICS4 actually, since it is only used for channel level packet processing. In IBC-go we have the channel ID and clientID separate to enable aliasing.
So in the spec I think we should have them separate to note it isn't a strict requirement to have the identifiers the same. In a note, we can say that implementations (like Solidity) can choose to keep them the same.
There was a problem hiding this comment.
Makes definitely sense to me!
There was a problem hiding this comment.
Great work @sangier ! I think the sections on counterparty are good, but we should have it housed in ICS4 spec
|
|
||
| ```typescript | ||
| interface Counterparty { | ||
| channelId: Identifier |
There was a problem hiding this comment.
I think we should keep this in ICS4 actually, since it is only used for channel level packet processing. In IBC-go we have the channel ID and clientID separate to enable aliasing.
So in the spec I think we should have them separate to note it isn't a strict requirement to have the identifiers the same. In a note, we can say that implementations (like Solidity) can choose to keep them the same.
| @@ -527,6 +527,41 @@ type verifyNonMembership = (ClientState, Height, CommitmentProof, Path) => boole | |||
|
|
|||
| IBC handlers MUST implement the functions defined below. | |||
|
|
|||
| #### Counterparty Idenfitifcation and Registration | |||
There was a problem hiding this comment.
Let's move this section to ICS4 as we said.
|
I'll be moving things in ics04 in the other ics04 PR i'm working on! |
Closes #1136