ICS 3: Connection Semantics #32
Conversation
cwgoes
added
tao
cwgoes
changed the title
cwgoes
force-pushed
the
cwgoes/ics-3-connection-semantics
branch
from
e3fb4a5
to
50322ef
Compare
|
Further whiteboarding on ICS 3: |
cwgoes
changed the title
cwgoes
added
ready-for-review
|
Going to make the diagram fancier and refer to two chains, but the substance is here. |
| \node at (-0.5,1.5) [above=0.5mm, right=5mm] {\textsc{Connection State Machine}}; | ||
|
|
||
| \end{tikzpicture} | ||
| \end{document} |
There was a problem hiding this comment.
referencing the current resulting image: https://media.githubusercontent.com/media/cosmos/ics/1b5746682891904a4b982723f5cfff36c1501c30/spec/ics-3-bidirectional-connection-semantics/state.png
|
|
Problem: what to do if we start initializing a channel, then final connection handshake times out? Maybe we can just delete the channel, the channel handshake will not complete. Concerns about name collisions? We could enforce relations between the timeout heights. |
cwgoes
changed the title
|
|
| This ICS defines three subprotocols: opening handshake, header tracking, closing handshake. Datagrams defined herein are handled as external messages by the IBC relayer module defined in [ICS 26](../spec/ics-26-relayer-module). | ||
|
|
||
|  | ||
|
|
There was a problem hiding this comment.
Nice diagram :) Could you make the text on transitions a bit bigger? It doesn't read easy currently.
There was a problem hiding this comment.
Also, IMHO it would be clearer if you'd separate A and B FSMs. And separate the opening and closing subprotocols. In other words, have one diagram for connection establishment, showing FSM for A on the left, FSM for B on the right and the corresponding datagrams used in the communication between the two.
Same for closing connections.
There was a problem hiding this comment.
Thanks for the feedback, makes sense - will do.
There was a problem hiding this comment.
Altered the font sizing. I'm not sure separating the FSMs for A and B is the right direction, though - the goal of the protocol construction is to allow reasoning about the combined state of the IBC handlers on both chains at once, so it seems like we want to combine them...
There was a problem hiding this comment.
...I agree we want to look at chains' FSMs at once. But the current diagram seem to show some transitions upon events that are not valid one one side. Let me try to read it more carefully the way it is together with the code.
There was a problem hiding this comment.
I think we should list the events in the FSM (CONNINIT, CONNOPENTRY, etc) and describe what triggers them. Maybe add also a column in the table below?
There was a problem hiding this comment.
Added two columns in each table, for prior state and posterior state - is that what you meant?
| desiredCounterpartyIdentifier Identifier | ||
| clientIdentifier Identifier | ||
| counterpartyClientIdentifier Identifier | ||
| nextTimeoutHeight uint64 |
There was a problem hiding this comment.
Maybe add a few words in the definition section about timeout heights.
There was a problem hiding this comment.
I wonder if the explanation in #86 should actually become an ICS...
|
Merging as a draft, future comments are always welcome. |
Closes #3.
Specify datagrams & semantics for bidirectional connections.
Unidirectional connections (one-to-one, or one-to-many, or even many-to-one) are possible but will be specified separately.