CIP-001: WeCross improvement proposals discussion

[morebtcg]

WeCross improvement proposals

跨链是区块链行业的前沿课题，业界对跨链的定义和设计都有很多不同的理解。跨链的场景、跨链的网络架构、跨链的交互逻辑，都有大量的研究和讨论。基于这个现状，WeCross团队不局限于自己探索和解决所有跨链的问题，而是将已知或可能存在的场景和需求，以CIP（WeCross Improvement Proposals）的形式提出解决方案，邀请广大区块链从业者和用户共同参与方案的规划，一起讨论和完善方案的设计，由WeCross团队采纳，最终合作完成WeCross功能的实现。

浏览CIP：https://github.com/WeBankFinTech/WeCross/labels/CIP

CIP构成

CIP的描述应该简洁精炼，围绕着目标进行，包含以下要素：

• 功能简介：简述该CIP提出的背景、预期要解决的问题和使用的场景，发起CIP提案时，该章节为必填
• 模块架构：CIP涉及哪些全新模块和已有模块的修改、各模块之间的联系、逻辑架构图，如果该CIP提案涉及网络、互联逻辑还应提供系统架构图和网络架构图
• 功能列表：总体的功能列表，各模块的功能列表
• 接口设计：各模块功能接口的名称、入参、出参和逻辑概要描述
• 协议设计：如果该CIP提案涉及网络、互联逻辑，提供网络通信协议的流程和字段设计
• 数据结构：如果该CIP提案涉及数据落盘存储，提供数据存储的数据结构设计
• 时序图：主要模块功能的流程时序图
• 兼容性：与旧版本WeCross、已搭建的WeCross跨链网络的兼容性分析
• 安全分析：跨链数据、账户、资产和通信的安全性分析

CIP工作流

CIP遵循一套预设的工作流，所有CIP的进展会公示在Issue中，有独特的标签，CIP工作流包含以下阶段：

1. 提案阶段(Proposal)：发起人按照CIP模板，填写CIP的功能简介，提交Issue，由WeCross核心开发者审核
2. 方案阶段(Draft)：WeCross核心开发者认可该CIP提案后，为Issue赋予明确的标签。发起人需要在14天内将CIP提案模板中的所有章节补全，期间，发起人可以与核心开发者进行多轮共同沟通，共同完善方案
3. 投票阶段(Vote)：CIP的所有章节完成以后，WeCross团队审阅CIP方案，并发起讨论和投票，决定是否采纳该CIP
4. 采纳阶段(Accepted)：WeCross团队将此CIP纳入版本规划，发起者可以一起参与开发
5. 结束(Final)：CIP功能随WeCross版本发布后，将该CIP标识为结束状态
6. 拒绝(Reject)：CIP功能未通过投票或被放弃，该CIP标识为拒绝状态

一个正常采纳的CIP工作流为：提案 -> 方案 -> 投票 -> 采纳 -> 结束
一个被拒绝的CIP工作流为：提案 -> 方案 -> 投票 -> 拒绝

CIP激励

对于热心提交CIP、评论CIP并最终被采纳的用户，WeCross团队根据行为的不同，给予相应激励：

• 提交CIP并被采纳：
• 评论CIP并被采纳：

参考资料：EIP方案

EIP全称Ethereum Improvement Proposals，是以太坊标准的提案格式。

EIP1介绍了EIP的标准格式和分类(https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md)

EIP包含多种类型，包括：

• Core：核心提案，指对以太坊的核心功能，如EVM等模块的提案，例如EIP5，提出了对CALL和RETURN的gas计算方案。(https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5.md)
• Networking：网络提案，涉及P2P模块、网络协议和轻客户端协议等，例如EIP8提出了基本的RLP编解码协议、包头协议和握手协议等等。(https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8.md)
• Interface：接口提案，与API、RPC和ABI相关，如EIP6提出了将SUICIDE的语法改名为SELFDESTRUCT，还有ABI编解码协议。
• ERC：应用层面的提案，如智能合约、命名协议、dapp目录结构规范等，如知名的ERC20(links to the yellow paper and wiki ethereum/EIPs#2 )合约。

其它的诸如Meta EIP和Informational EIP则是相对没那么正式的EIP，用于一些讨论、建议等场景。

遵循EIP1的描述，一个正式的EIP包含以下内容：

• Preamble：RFC 822风格的内容概要，包括EIP编号、作者等信息
• Abstract：200字以内的EIP内容概要
• Specification：规格描述
• Backwards Compatibility：前向兼容性，该EIP与旧版本的兼容性
• Test Cases：测试用例
• Implementations：实现的详细描述，可以用代码描述
• Security Considerations：安全因素，包括账户安全、密码学安全等一些跟安全相关的考量
• Copyright Waiver：版权相关

EIP遵循如下流程和步骤：

1. Idea：简单描述EIP的想法，并提交一个草案PR到EIP项目
2. Draft：PR被合入以后，在期限内继续完善EIP的内容，期限通常是14天（可协商）
3. Last Call：期限到达前，EIP会在项目网页上展示，如果设计理念改变、或是有无法解决的争议，EIP会回到Draft状态，否则进入下一个状态（https://eips.ethereum.org/）
4. Accepted：EIP被接受，开始规划开发、是否要硬分叉等事项
5. Final：EIP实现后，该EIP转为Final状态

截至目前（2020-05-14），以太坊的所有EIP中，55个EIP是已实现（Final）状态，184个EIP是草案（Draft）状态，5个EIP是展示（Last Call）状态，1个EIP是接受（Accepted）状态，正在开发。从作者来看，大部分已实现（Final）状态的EIP，都是由以太坊的核心成员如Vitalik Buterin、Christian Reitwiessner、Alex Beregszaszi等人提出，草案（Draft）状态的EIP，来源比较多样。

[wheatli]

强烈支持，需要有一个CIP的模板文件，以及一个CIP管理目录