​
什么是 ICS？

链间标准（ICS）是一类设计文档，用于描述对 Cosmos 生态系统有用的特定协议、标准或功能。 一份 ICS 应列出该标准期望具备的性质，解释设计原理，并提供简明但完整的技术规范。主要 ICS 作者 负责推动提案通过标准化流程，向社区征集意见与支持，并与相关利益方沟通，以确保达成（社会层面的）共识。 链间标准化流程应当是提出生态范围协议、变更和功能的主要机制；在达成共识后，ICS 文档也应继续保留，作为设计决策的记录以及供未来实现者参考的信息资料库。 链间标准不应用于提出针对某一特定区块链的变更 （例如 Cosmos Hub），也不应用于规定具体实现细节（例如特定编程语言的数据结构）， 或就现有 Cosmos 区块链上的治理提案进行辩论（尽管 Cosmos 生态中的个别区块链 可能会使用其治理流程来批准或拒绝链间标准）。

​
组成部分

一份 ICS 由头部、概述、规范、历史记录和版权声明组成。所有顶级章节都是必需的。 引用应以内联链接形式给出；如有必要，也可在章节底部整理成表格。

​
头部

ICS 头部包含与该 ICS 相关的元数据。

​
必填字段

ics: # - ICS 编号（按顺序分配） title - ICS 标题（简短明确即可） stage - 当前 ICS 所处阶段，可用阶段列表见 PROCESS.md。 关于 ICS 接收阶段的说明，请参见 README.md。 category - ICS 类别，以下之一：
  • meta - 关于 ICS 流程本身的标准。
  • IBC/TAO - 关于链间通信系统核心传输、认证与排序层协议的标准。
  • IBC/APP - 关于链间通信系统应用层协议的标准。
kind - ICS 类型，以下之一：
  • meta - 关于 ICS 流程本身的标准。
  • interface - 关于最小接口集合以及承载链间通信协议实现的状态机必须满足的性质的标准。
  • instantiation - 关于具体实现细节的标准，说明该标准如何通过伪代码或软件组件落地实现。
author - ICS 作者及联系方式（优先顺序为：电子邮件、GitHub 用户名、Twitter 用户名、其他较可能获得回应的联系方式）。 第一位作者是该 ICS 的主要“负责人”，负责推动其通过标准化流程。 后续作者的排序应按贡献大小排列。 created - ICS 首次创建日期（YYYY-MM-DD） modified - ICS 最近修改日期（YYYY-MM-DD）

​
可选字段

requires - 本标准所要求或依赖的其他 ICS 标准，以编号引用。 required-by - 要求或依赖本标准的其他 ICS 标准，以编号引用。 replaces - 如适用，被本标准替代或取代的另一份 ICS 标准。 replaced-by - 如适用，替代或取代本标准的另一份 ICS 标准。 version compatibility - 与该 ICS 标准兼容的实现版本列表。

​
概述

在头部之后，ICS 应包含一段简要概述（约 200 字），对规范给出高层说明并解释其设计理由。

​
规范

规范章节是一份 ICS 的主体部分，应在适当情况下包含协议文档、设计原理、 必要引用以及技术细节。

​
子组成部分

规范可根据具体 ICS 的需要，包含以下任意一个或多个子部分。已包含的子部分应按此处规定的顺序排列。
  • 动机 - 说明所提议功能存在的理由，或对现有功能提出变更的理由。
  • 定义 - 列出本 ICS 中使用的新术语或为理解本 ICS 所必需的概念。凡未在顶层 docs 文件夹中定义的术语，都必须在此定义。
  • 期望性质 - 列出所规定协议或功能应具备的性质或特征，以及当这些性质被破坏时期望出现的影响或故障。
  • 技术规范 - 所提议协议的全部技术细节，包括适当情况下的语法、语义、子协议、数据结构、算法和伪代码。 技术规范应足够详细，以确保彼此互不了解的独立正确实现仍能保持兼容。
  • 向后兼容性 - 讨论与此前功能或协议版本的兼容性（或不兼容性）。
  • 向前兼容性 - 讨论与未来可能或预期的功能或协议版本的兼容性（或不兼容性）。
  • 示例实现 - 具体的实现示例，或对预期实现的说明，作为实现者的主要参考。
  • 其他实现 - 候选或已定稿实现的列表（外部引用，不以内联方式给出）。

​
历史

ICS 应包含历史章节，列出启发来源文档以及重要变更的纯文本日志。 历史章节示例见下文。

​
版权

ICS 应包含版权章节，通过 Apache 2.0 放弃相关权利。

​
格式

​
通用

ICS 规范必须使用 GitHub 风格的 Markdown 编写。 如需 GitHub 风格 Markdown 速查表，请参见这里。如需本地 Markdown 渲染器，请参见这里。

​
语言

ICS 规范应使用简明英语编写，避免生僻术语和不必要的行话。关于简明英语的优秀示例，请参见简明英语维基百科。 规范中的关键词 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY” 和 “OPTIONAL” 应按 RFC 2119 中所述方式解释。

​
伪代码

规范中的伪代码应与具体编程语言无关，并采用简单的命令式标准格式，包含行号、变量、简单条件块、for 循环，以及在必要时用于进一步说明功能（例如调度超时）的英文片段。应避免使用 LaTeX 图片，因为它们难以在 diff 中进行审阅。 结构体的伪代码应使用简洁的 Typescript，以接口形式编写。 示例伪代码结构体： 
interface Connection {
  state: ConnectionState
  version: Version
  counterpartyIdentifier: Identifier
  consensusState: ConsensusState
}
算法的伪代码应使用简洁的 Typescript，以函数形式编写。 示例伪代码算法： 
function startRound(round) {
  round_p = round
  step_p = PROPOSE
  if (proposer(h_p, round_p) === p) {
    if (validValue_p !== nil)
      proposal = validValue_p
    else
      proposal = getValue()
    broadcast( {PROPOSAL, h_p, round_p, proposal, validRound} )
  } else
    schedule(onTimeoutPropose(h_p, round_p), timeoutPropose(round_p))
}

​
历史

本规范在很大程度上受到了以太坊的 EIP 1 的启发并据此衍生而来，而后者 又进一步源自比特币的 BIP 流程和 Python 的 PEP 流程。先前文档的作者不对本 ICS 规范或 ICS 流程中的任何不足负责。请将所有评论直接发送给 ICS 仓库维护者。 2019 年 3 月 4 日 - 初稿完成并作为 PR 提交 2019 年 3 月 7 日 - 草案合并 2019 年 4 月 11 日 - 更新伪代码格式，新增 definitions 子章节 2019 年 8 月 17 日 - 澄清类别定义

​
版权

此处所有内容均基于 Apache 2.0 许可。

​
What is an ICS?

An interchain standard (ICS) is a design document describing a particular protocol, standard, or feature expected to be of use to the Cosmos ecosystem. An ICS should list the desired properties of the standard, explain the design rationale, and provide a concise but comprehensive technical specification. The primary ICS author is responsible for pushing the proposal through the standardisation process, soliciting input and support from the community, and communicating with relevant stakeholders to ensure (social) consensus. The interchain standardisation process should be the primary vehicle for proposing ecosystem-wide protocols, changes, and features, and ICS documents should persist after consensus as a record of design decisions and an information repository for future implementers. Interchain standards should not be used for proposing changes to a particular blockchain (such as the Cosmos Hub), specifying implementation particulars (such as language-specific data structures), or debating governance proposals on existing Cosmos blockchains (although it is possible that individual blockchains in the Cosmos ecosystem may utilise their governance processes to approve or reject interchain standards).

​
Components

An ICS consists of a header, synopsis, specification, history log, and copyright notice. All top-level sections are required. References should be included inline as links, or tabulated at the bottom of the section if necessary. An ICS header contains metadata relevant to the ICS.

​
Required fields

ics: # - ICS number (assigned sequentially) title - ICS title (keep it short & sweet) stage - Current ICS stage, see PROCESS.md for the list of possible stages. See README.md for a description of the ICS acceptance stages. category - ICS category, one of the following:
  • meta - A standard about the ICS process.
  • IBC/TAO - A standard about an inter-blockchain communication system core transport, authentication, and ordering layer protocol.
  • IBC/APP - A standard about an inter-blockchain communication system application layer protocol.
kind - ICS kind, one of the following:
  • meta - A standard about the ICS process.
  • interface - A standard about the minimal set of interfaces that must be provided and properties that must be fulfilled by a state machine hosting an implementation of the inter-blockchain communication protocol.
  • instantiation - A standard about concrete implementation details that explains how the standard is realized in pseudocode or software components.
author - ICS author(s) & contact information (in order of preference: email, GitHub handle, Twitter handle, other contact methods likely to elicit response). The first author is the primary “owner” of the ICS and is responsible for advancing it through the standardisation process. Subsequent author ordering should be in order of contribution amount. created - Date ICS was first created (YYYY-MM-DD) modified - Date ICS was last modified (YYYY-MM-DD)

​
Optional fields

requires - Other ICS standards, referenced by number, which are required or depended upon by this standard. required-by - Other ICS standards, referenced by number, which require or depend upon this standard. replaces - Another ICS standard replaced or supplanted by this standard, if applicable. replaced-by - Another ICS standard which replaces or supplants this standard, if applicable. version compatibility - List of versions of implementations compatible with the ICS standard.

​
Synopsis

Following the header, an ICS should include a brief (~200 word) synopsis providing a high-level description of and rationale for the specification.

​
Specification

The specification section is the main component of an ICS, and should contain protocol documentation, design rationale, required references, and technical details where appropriate.

​
Sub-components

The specification may have any or all of the following sub-components, as appropriate to the particular ICS. Included sub-components should be listed in the order specified here.
  • Motivation - A rationale for the existence of the proposed feature, or the proposed changes to an existing feature.
  • Definitions - A list of new terms or concepts utilised in this ICS or required to understand this ICS. Any terms not defined in the top-level “docs” folder must be defined here.
  • Desired Properties - A list of the desired properties or characteristics of the protocol or feature specified, and expected effects or failures when the properties are violated.
  • Technical Specification - All technical details of the proposed protocol including syntax, semantics, sub-protocols, data structures, algorithms, and pseudocode as appropriate. The technical specification should be detailed enough such that separate correct implementations of the specification without knowledge of each other are compatible.
  • Backwards Compatibility - A discussion of compatibility (or lack thereof) with previous feature or protocol versions.
  • Forwards Compatibility - A discussion of compatibility (or lack thereof) with future possible or expected features or protocol versions.
  • Example Implementations - Concrete example implementations or descriptions of expected implementations to serve as the primary reference for implementers.
  • Other Implementations - A list of candidate or finalised implementations (external references, not inline).

​
History

An ICS should include a history section, listing any inspiring documents and a plaintext log of significant changes. See an example history section below. An ICS should include a copyright section waiving rights via Apache 2.0.

​
Formatting

​
General

ICS specifications must be written in GitHub-flavoured Markdown. For a GitHub-flavoured Markdown cheat sheet, see here. For a local Markdown renderer, see here.

​
Language

ICS specifications should be written in Simple English, avoiding obscure terminology and unnecessary jargon. For excellent examples of Simple English, please see the Simple English Wikipedia. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in specifications are to be interpreted as described in RFC 2119.

​
Pseudocode

Pseudocode in specifications should be language-agnostic and formatted in a simple imperative standard, with line numbers, variables, simple conditional blocks, for loops, and English fragments where necessary to explain further functionality such as scheduling timeouts. LaTeX images should be avoided because they are difficult to review in diff form. Pseudocode for structs should be written in simple Typescript, as interfaces. Example pseudocode struct: 
interface Connection {
  state: ConnectionState
  version: Version
  counterpartyIdentifier: Identifier
  consensusState: ConsensusState
}
Pseudocode for algorithms should be written in simple Typescript, as functions. Example pseudocode algorithm: 
function startRound(round) {
  round_p = round
  step_p = PROPOSE
  if (proposer(h_p, round_p) === p) {
    if (validValue_p !== nil)
      proposal = validValue_p
    else
      proposal = getValue()
    broadcast( {PROPOSAL, h_p, round_p, proposal, validRound} )
  } else
    schedule(onTimeoutPropose(h_p, round_p), timeoutPropose(round_p))
}

​
History

This specification was significantly inspired by and derived from Ethereum’s EIP 1, which was in turn derived from Bitcoin’s BIP process and Python’s PEP process. Antecedent authors are not responsible for any shortcomings of this ICS spec or the ICS process. Please direct all comments to the ICS repository maintainers. Mar 4, 2019 - Initial draft finished and submitted as a PR Mar 7, 2019 - Draft merged Apr 11, 2019 - Updates to pseudocode formatting, add definitions subsection Aug 17, 2019 - Clarifications to categories All content herein is licensed under Apache 2.0.