linter

spec/core/ics-003-connection-semantics/client-validation-removal.md

@@ -2,7 +2,7 @@
 
 The IBC protocol is no longer requiring that chains verify that the underlying counterparty client of a connection is a valid client of their consensus protocol. In order to understand the motivation for these changes, this document will describe why the validation existed in the first place, what challenges they introduced, and what the consequences are of removing them.
 
-### Client Validation Motivation
+## Client Validation Motivation
 
 Client validation was initially included in the connection handshake handlers in order to ensure that both chains were talking to the correct counterparty, i.e. the connection was correctly configured such that both chains are talking to each other. This ensures that when a channel is built on top of that connection, and a packet is sent over that channel; only a single chain is capable of receiving the packet.
 
@@ -12,15 +12,15 @@ The IBC connection handshake used this fact to ensure that the connection handsh
 
 Without this check, it is possible in very unlucky circumstances to have two chains that are validly connected to each other and also have misconfigured third-party chains that believe they are connected to a chain that is not connected back to them. For an example of this situation, see the attached [diagram](./client-validation-removal.png). In this case, the validly connected chains will have communication between them that follows IBC's correctness and integrity properties. However, the chains that are misconfigured may misinterpret messages send to other chains as messages intended for them. In this case, the only connection ends that are affected are the misconfigured connection ends that do not correlate to a valid connection end on the intended counterparty. In order for this situation to arise, there would need to not only be relayer error, but also a coincidence in identifiers and handshake message timing. Thus, this is an unlikely situation to arise in practice and the only effect is invalid message processing on misconfigured connections and channel ends.
 
-### Client Validation Problems
+## Client Validation Problems
 
 While it is beneficial that misconfigured connection attempts are blocked from completing, the client validation in the connection handshake introduced a lot of problems for the upgradability and flexibility of the protocol.
 
 - Not all chains have the ability to introspect their own consensus, specifically their own consensus history which is required to validate a counterparty's previous consensus state.
 - Explicit verification of a counterparty clientstate and consensus state makes adding new implementions of the same consensus difficult since the validation of any new client implementations must be supported on the counterparty you want to use it with. Thus, the structure of `ClientState` and `ConsensusState` is very difficult to change without interchain coordination.
 - Similarly, the proofs rely on ICS24 paths for the `ClientState` and `ConsensusState`. Thus, changing the key paths to a more efficient representation is very difficult without interchain coordination.
 
-### Social Consensus
+## Social Consensus
 
 As mentioned above, the client validation in the connection handshake prevents the creation of OPEN misconfigured connections and channels. However, it does not prevent the creation of OPEN connections and channels that are opened to malicious chains. The way IBC handles these situations is to rely on social consensus. This can be in the form of explicit social consensus, i.e. governance approved clients, connections and channels; or implicit social consensus where IBC messages are permissionless but there exists an out-of-band consensus on which connection-id is the canonical connection that all users will use to communicate to an external chain. This out-of-band consensus can be reflected in chain registries and front ends that are reflected to end users to prevent them from unintentionally using the wrong channel.