Merge PR cosmos#34: ICS 4: Channel & Packet Semantics

ChorusOne · Jun 8, 2019 · b8e9826 · b8e9826
1 parent a770489
commit b8e9826
Show file tree

Hide file tree

Showing 18 changed files with 978 additions and 17 deletions.
diff --git a/Makefile b/Makefile
@@ -1,4 +1,4 @@
-SUBDIRS := spec/ics-3-connection-semantics
+SUBDIRS := spec/ics-3-connection-semantics spec/ics-4-channel-and-packet-semantics
 TOPTARGETS := all clean
 
 $(TOPTARGETS): $(SUBDIRS)
@@ -8,6 +8,8 @@ $(SUBDIRS):
 setup_dependencies:
 	pip install matplotlib networkx
 
+check: check_links check_dependencies check_syntax check_sections
+
 check_links:
 	python ./scripts/check_links.py
 
@@ -20,4 +22,4 @@ check_syntax:
 check_sections:
 	python ./scripts/check_sections.py
 
-.PHONY: $(TOPTARGETS) $(SUBDIRS) setup_dependencies check_links check_dependencies check_syntax check_sections
+.PHONY: $(TOPTARGETS) $(SUBDIRS) setup_dependencies check check_links check_dependencies check_syntax check_sections
diff --git a/README.md b/README.md
@@ -40,6 +40,7 @@ All standards in the "draft" stage are listed here in order of their ICS numbers
 | --------------------------------------------------- | ---------------------------------- | ----- |
 | [2](spec/ics-2-consensus-verification)              | Consensus Verification             | Draft |
 | [3](spec/ics-3-connection-semantics)                | Connection Semantics               | Draft |
+| [4](spec/ics-4-channel-and-packet-semantics)        | Channel & Packet Semantics         | Draft |
 | [18](spec/ics-18-relayer-algorithms)                | Relayer Algorithms                 | Draft |
 | [23](spec/ics-23-vector-commitments)                | Vector Commitments                 | Draft |
 | [24](spec/ics-24-host-requirements)                 | Host Requirements                  | Draft |

diff --git a/deps.png b/deps.png
diff --git a/scripts/check_links.py b/scripts/check_links.py
@@ -2,7 +2,7 @@
 
 import re, os, sys
 
-link_regex = re.compile('\[(.*)\]\(../ics([^\)]*)\)')
+link_regex = re.compile('\[ICS ([0-9]+)\]\(([^\)]*)\)')
 title_regex = re.compile('ICS ([0-9]+)([ .:])')
 
 specs = [f.path for f in os.scandir('./spec') if f.is_dir()]
@@ -13,7 +13,7 @@
 for fn in files:
     print('Checking links in {}'.format(fn))
     data = open(fn).read()
-    links = ['ics' + l[1] for l in link_regex.findall(data)]
+    links = [l[1][3:] for l in link_regex.findall(data)]
     for link in links:
         found = link in specs_cut
         if not found:

diff --git a/scripts/check_sections.py b/scripts/check_sections.py
@@ -7,7 +7,7 @@
 sub_sub_section_regex = re.compile('[^#]### (.*)')
 
 specs = [f.path for f in os.scandir('./spec') if f.is_dir()]
-files = [f.path for spec in specs for f in os.scandir(spec) if f.is_file() and f.path == 'README.md' and 'ics-1-ics-standard' not in f.path]
+files = [f.path for spec in specs for f in os.scandir(spec) if f.is_file() and f.path[-9:] == 'README.md' and 'ics-1-ics-standard' not in f.path]
 
 expected_sub_sections = ['Synopsis', 'Technical Specification', 'Backwards Compatibility', 'Forwards Compatibility', 'Example Implementation', 'Other Implementations', 'History', 'Copyright']
 expected_sub_sub_sections = ['Motivation', 'Definitions', 'Desired Properties']

diff --git a/spec/ics-2-consensus-verification/README.md b/spec/ics-2-consensus-verification/README.md
@@ -382,7 +382,19 @@ Not applicable.
 In a future version, this ICS will define a new function `unfreezeClient` that can be called 
 when the application logic resolves an equivocation event.
 
+## Example Implementation
+
+Coming soon.
+
+## Other Implementations
+
+Coming soon.
+
 ## History
 
-March 5th 2019: Initial draft finished and submitted as a PR.
+March 5th 2019: Initial draft finished and submitted as a PR
 May 29 2019: Various revisions, notably multiple commitment-roots
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
diff --git a/spec/ics-23-vector-commitments/README.md b/spec/ics-23-vector-commitments/README.md
@@ -2,6 +2,7 @@
 ics: 23
 title: Vector Commitments
 stage: draft
+required-by: 2, 3, 4
 category: ibc-core
 author: Christopher Goes <[email protected]>
 created: 2019-04-16

diff --git a/spec/ics-24-host-requirements/README.md b/spec/ics-24-host-requirements/README.md
@@ -4,7 +4,7 @@ title: Host State Machine Requirements
 stage: draft
 category: ibc-core
 requires: 2
-required-by: 2, 3, 18
+required-by: 2, 3, 4, 18
 author: Christopher Goes <[email protected]>
 created: 2019-04-16
 modified: 2019-05-11

diff --git a/spec/ics-3-connection-semantics/README.md b/spec/ics-3-connection-semantics/README.md
@@ -4,6 +4,7 @@ title: Connection Semantics
 stage: draft
 category: ibc-core
 requires: 2, 23, 24
+required-by: 4
 author: Christopher Goes <[email protected]>, Juwoon Yun <[email protected]>
 created: 2019-03-07
 modified: 2019-05-17
@@ -15,15 +16,15 @@ This standards document describes the abstraction of an IBC *connection*: two st
 
 ### Motivation
 
-The core IBC protocol provides *authorization* and *ordering* semantics for packets: guarantees, respectively, that packets have been committed on the sending blockchain (and according state transitions executed, such as escrowing tokens), and that they have been committed exactly once in a particular order and can be delivered exactly once in that same order. The *connection* abstraction specified in this standard, in conjunction with the *client* abstraction specified in [ICS 2](../spec-ics-2-consensus-verification), defines the *authorization* semantics of IBC. Ordering semantics are described in [ICS 4](../spec/ics-4-channel-packet-semantics)).
+The core IBC protocol provides *authorization* and *ordering* semantics for packets: guarantees, respectively, that packets have been committed on the sending blockchain (and according state transitions executed, such as escrowing tokens), and that they have been committed exactly once in a particular order and can be delivered exactly once in that same order. The *connection* abstraction specified in this standard, in conjunction with the *client* abstraction specified in [ICS 2](../ics-2-consensus-verification), defines the *authorization* semantics of IBC. Ordering semantics are described in [ICS 4](../ics-4-channel-and-packet-semantics)).
 
 ### Definitions
 
-`ConsensusState`, `Header`, and `updateConsensusState` are as defined in [ICS 2](../spec/ics-2-consensus-verification).
+`ConsensusState`, `Header`, and `updateConsensusState` are as defined in [ICS 2](../ics-2-consensus-verification).
 
-`CommitmentProof`, `verifyMembership`, and `verifyNonMembership` are as defined in [ICS 23](../spec/ics-23-vector-commitments).
+`CommitmentProof`, `verifyMembership`, and `verifyNonMembership` are as defined in [ICS 23](../ics-23-vector-commitments).
 
-`Identifier` and other host state machine requirements are as defined in [ICS 24](../spec/ics-24-host-requirements). The identifier is not necessarily intended to be a human-readable name (and likely should not be, to discourage squatting or racing for identifiers).
+`Identifier` and other host state machine requirements are as defined in [ICS 24](../ics-24-host-requirements). The identifier is not necessarily intended to be a human-readable name (and likely should not be, to discourage squatting or racing for identifiers).
 
 The opening handshake protocol allows each chain to verify the identifier used to reference the connection on the other chain, enabling modules on each chain to reason about the reference on the other chain.
 
@@ -87,7 +88,7 @@ interface Connection {
 
 ### Subprotocols
 
-This ICS defines two subprotocols: opening handshake and closing handshake. Header tracking and closing-by-equivocation are defined in [ICS 2](../spec/ics-2-consensus-verification). Datagrams defined herein are handled as external messages by the IBC relayer module defined in ICS 26.
+This ICS defines two subprotocols: opening handshake and closing handshake. Header tracking and closing-by-equivocation are defined in [ICS 2](../ics-2-consensus-verification). Datagrams defined herein are handled as external messages by the IBC relayer module defined in ICS 26.
 
 ![State Machine Diagram](state.png)
 
@@ -274,7 +275,7 @@ function connOpenTimeout(identifier: Identifier, proofTimeout: CommitmentProof,
 
 #### Header Tracking
 
-Headers are tracked at the client level. See [ICS 2](../spec/ics-2-consensus-verification).
+Headers are tracked at the client level. See [ICS 2](../ics-2-consensus-verification).
 
 #### Closing Handshake
 
@@ -406,7 +407,7 @@ function connCloseTimeout(identifier: Identifier, proofTimeout: CommitmentProof,
 
 #### Freezing by Equivocation
 
-The equivocation detection subprotocol is defined in [ICS 2](../spec/ics-2-consensus-verification). If a client is frozen by equivocation, all associated connections are immediately frozen as well.
+The equivocation detection subprotocol is defined in [ICS 2](../ics-2-consensus-verification). If a client is frozen by equivocation, all associated connections are immediately frozen as well.
 
 Implementing chains may want to allow applications to register handlers to take action upon discovery of an equivocation. Further discussion is deferred to ICS 12.
 

diff --git a/spec/ics-3-connection-semantics/state.png b/spec/ics-3-connection-semantics/state.png
diff --git a/spec/ics-4-channel-and-packet-semantics/Makefile b/spec/ics-4-channel-and-packet-semantics/Makefile
@@ -0,0 +1,15 @@
+all: $(addsuffix .png, $(basename $(wildcard *.tex))) cleanup
+
+%.png : %.tex
+	pdflatex "\input{$<}"
+	convert -resize 50% -chop 26x0 -density 400 $(basename $<).pdf -quality 100 $@
+
+cleanup:
+	rm -f *.log
+	rm -f *.aux
+	rm -f *.pdf
+
+clean:
+	rm -f *.png
+
+.PHONY: all clean cleanup