RFC35: ckb2021 P2P protocol upgrade

rfcs/0035-ckb2021-p2p-protocol-upgrade/0035-ckb2021-p2p-protocol-upgrade.md

@@ -1 +1,98 @@
-In review, see <https://github.com/nervosnetwork/rfcs/pull/234>
+---
+Number: "0035"
+Category: P2P Protocol 
+Status: Draft
+Author: Chao Luo, Ian Yang
+Organization: Nervos Foundation
+Created: 2021-07-01
+---
+# P2P protocol upgrade
+
+## Abstract
+
+This RFC describes how the network protocol changes before and after the ckb hard fork, and how the network protocols smoothly upgrade along the hard fork.
+
+## Motivation
+
+The network protocol is the foundation of distributed applications. Before and after hard fork, there will be small changes in data format, but the network should not be disconnected or split because of this change. After hard fork, only clients that support hard fork are allowed to connect.
+
+This RFC describes in detail how the ckb node implements this functionality.
+
+## Specification
+
+We divide the entire hard fork process into three phases: before hard fork, the moment that hard fork activates, and after hard fork. The protocols are divided into two categories which have different upgrade strategies.
+
+- Upgrade the version of a specific protocol and ensure that both versions of the protocol are supported and can be enabled at the same time
+- Mount two protocols that are functionally identical but require runtime switching for smooth upgrades
+
+### For protocols whose functionality and implementation do not need to be modified
+
+Including protocols:
+
+- Identify
+- Ping
+- Feeler
+- DisconnectMessage
+- Time
+- Alert
+
+##### Before hard fork
+
+Change the version support list from `[1]` to `[1, 2]`, the client will support both versions of the protocol, the new client will enable version 2 and the old client will enable version 1
+
+##### Hard fork moment
+
+Disconnect all clients with the protocol version 1 on, and reject this version afterwards.
+
+##### After hard fork
+
+Remove the support for the protocol version 1 from the next version of client code, i.e. change the support list from `[1, 2]` to `[2]`, and clean up the compatibility code
+
+### Implement protocols that requires modification
+
+#### Discovery
+
+##### Before hard fork
+
+1. Change the version support list from `[1]` to `[1, 2]`.
+2. Remove redundant codec operations from the previous implementation
+
+##### Hard fork moment
+
+Disconnect all clients with the protocol version 1 on, and reject this version afterwards.
+
+##### After hard fork
+
+Remove the support for the protocol version 1 from the next version of client code, i.e. change the support list from `[1, 2]` to `[2]`, and clean up the compatibility code
+
+#### Sync
+
+##### Before hard fork Before
+
+1. Change the version support list from `[1]` to `[1, 2]`
+2. Remove the 16 group limit from the sync request list and keep the maximum number of syncs, new version changes the block sync request limit from 16 to 32
+
+##### Hard fork moment
+
+Disconnect all clients with the protocol version 1 on, and reject this version afterwards.
+
+##### After hard fork
+
+Remove the support for the protocol version 1 from the next version of client code, i.e. change the support list from `[1, 2]` to `[2]`, and clean up the compatibility code
+
+### For protocols whose behavior will conflict before and after fork
+
+#### Relay
+
+##### Before hard fork.
+
+Since relay protocols before and after fork may have inconsistent cycle of transaction validation due to inconsistent vm, such behavior cannot be identified by a simple upgrade, for such protocols, another solution will be adopted to smooth the transition, i.e., open both relay protocols, disable the new protocol relay tx related messages, and let the old protocol work normally
+
+##### Hard fork moment
+
+1. Disable relay tx related messages in version 1 protocol and switch to the new relay
+2. Allow opening the version 1 protocols
+
+##### After hard fork
+
+Remove the support for the old relay protocol in the next version of the client code, i.e. remove the support for the old relay protocol and clean up the compatibility code

rfcs/0035-ckb2021-p2p-protocol-upgrade/0035-ckb2021-p2p-protocol-upgrade.zh-CN.md

@@ -0,0 +1,101 @@
+---
+Number: "0035"
+Category: P2P Protocol 
+Status: Draft
+Author: Chao Luo, Ian Yang
+Organization: Nervos Foundation
+Created: 2021-07-01
+---
+
+# P2P 协议升级
+
+## Abstract
+
+这个 RFC 用于描述网络协议在 ckb hard fork 前后的变化，以及如何在 hard fork 过程中让网络协议平稳过度。
+
+## Motivation
+
+网络协议是分布式应用的基础，hard fork 前后，数据格式将会有小范围的变化，但网络不应该因为这个变化而导致断开或者分裂，我们应当尽可能平稳地过度这一特殊时期，同时要保证在 hard fork 之前，所有客户端可以连接，hard fork 之后，只允许连接支持 hard fork 的客户端。
+
+这个 RFC 详细描述了 ckb 节点如何实现上述功能。
+
+## Specification
+
+我们将整个 hard fork 的过程分为三个阶段：hard fork 之前，hard fork 时点，hard fork 之后。然后分为两大类手段来描述具体的改动细节，以及如何支持平稳过度。
+
+ckb 对网络协议有两种升级和扩展的方式：
+
+- 对特定协议升级版本，并保证同时支持两个版本协议可同时开启
+- 挂载两个功能一样但需要运行时切换的协议用于平滑升级
+
+### 对于功能和实现都不需要修改的协议
+
+包含协议：
+
+- Identify
+- Ping
+- Feeler
+- DisconnectMessage
+- Time
+- Alert
+
+##### hard fork 之前
+
+将版本支持列表从 `[1]` 修改为 `[1, 2]`，该客户端将同时支持两个版本的协议，新客户端将开启 2 版本，老客户端将开启 1 版本
+
+##### hard fork 时点
+
+将开启 1 版本协议的客户端全部断开连接，同时在之后拒绝此版本协议开启
+
+##### hard fork 之后
+
+在下一个版本客户端代码中移除 1 版本协议的支持，即支持列表从 `[1, 2]` 修改为 `[2]`，并清理兼容代码
+
+### 对实现需要微调的协议
+
+#### Discovery
+
+##### hard fork 之前：
+
+1. 将版本支持列表从 `[1]` 修改为 `[1, 2]`
+2. 移除之前实现时多余的编码解码操作
+
+##### hard fork 时点
+
+将开启 1 版本协议的客户端全部断开连接，同时在之后拒绝此版本协议开启
+
+##### hard fork 之后
+
+在下一个版本客户端代码中移除 1 版本协议的支持，即支持列表从 `[1, 2]` 修改为 `[2]`，并清理兼容代码
+
+#### Sync
+
+##### hard fork 之前：
+
+1. 将版本支持列表从 `[1]` 修改为 `[1, 2]`
+2. 移除同步时请求列表的 16 一组限制，保留最大同步数的限制，新版本将 block 同步请求上限从 16 改为 32
+
+##### hard fork 时点
+
+将开启 1 版本协议的客户端全部断开连接，同时在之后拒绝此版本协议开启
+
+##### hard fork 之后
+
+在下一个版本客户端代码中移除 1 版本协议的支持，即支持列表从 `[1, 2]` 修改为 `[2]`，并清理兼容代码
+
+### 对行为在 fork 前后会发生冲突的协议
+
+#### Relay
+
+##### hard fork 之前：
+
+由于 relay 协议在 fork 前后可能会因为 vm 不一致而导致交易验证的 cycle 不一致，这样的行为无法通过简单的升级来标识，对于这样的协议，将采取另一种方案进行平滑过度，即打开两个 relay 协议，禁用新协议 relay tx 相关消息，让老协议正常工作
+
+##### hard fork 时点
+
+1. 禁用 1 版本协议中的 relay tx 相关消息，切换为新 relay 工作
+2. 允许打开 1 版本协议
+
+##### hard fork 之后
+
+在下一个版本客户端代码中移除老版本 relay 协议的支持，即删除老版本 relay 协议的支持，并清理兼容代码