# KuChain 白皮书
## 背景
现代巨头扼杀了创新，去中心化正在挽救这一切。
基于区块链的分布式账本分散了货币发行和存储的权力。智能合约实现了可验证运算逻辑，分散了逻辑执行与验证的权力。 资产所有权被数字签名算法与遍布在全球各地的计算节点共同守护，资产确权与价值流转的过程被简化为机器算法。
机器构建的信任设施极大提高了金融效率，基础设施的变革让金融领域充满了变数，信任经济和开放金融时代已然进入爆发前夜。
未来成熟的开放金融市场将是一个百万亿级美金的市场。作为开放金融的第一代产物，以太坊生态中的DeFi应用获得了稳定的增长。基于DAO生态的合成稳定币、抵押借贷协议市场和代币原子交换协议等基于智能合约的功能服务也作为积木模块，被许多的金融产品使用。但应用的执行效率和DeFi服务的安全性正面临着许多挑战，链的性能也成为了制约应用发展的瓶颈。
专用的应用链则将具体的应用剥离，分散到不同的链载体，应用执行效率得到了保证，但是产品与产品之间相对割裂，需要依赖标准或协议完成服务与服务的组合。虽然全栈应用链可以通过跨链协议解决产品割裂的问题，但仍需要解决如启动融资，共识建立，配套开发工具，社区运营等实际问题，小团队无法快速启动业务，制约了应用链的普及和跨链生态的发展，开放金融基础设施的迭代和构建并非一帆风顺。
**为了加速信任经济和开放金融时代的到来，作为开放金融底层「信任流转操作系统」的KuChain应运而生，未来KuChain既满足公有设施的高性能可扩展，又能提供应用积木的可组合基础和低门槛进入的开发生态，同时支持广泛的异构区块链之间跨链通信的标准实现。**
### 作为开放金融基础设施的要求
当区块链成为开放金融的载体，一个金融应用一条链将成为常态，要满足金融应用的开发并让应用生态得以繁荣，区块链设施必须要满足以下条件
* 支撑亿级的用户数量
* 允许普通用户低成本进入, 同时维持相对稳定的使用费
* 安全与稳定
* 便于更新和拓展
* 高性能
* 性能容量上限可扩展
* 良好的原生跨链支持
* 去中心化治理机制
* 完善的开发配套支持
### 支撑亿级的用户数量
KuChain创新的设计了一套全新的资源模型, 使得用户账户的资源消耗可以更小, 同时减少了资源的无故浪费与投机行为, 使得KuChain在可以接受的成本下支撑亿级的用户数量。
### 允许普通用户无成本进入, 同时维持相对稳定的手续费
KuChain为每个账户设置保护性的基础资源，使得账户可以在付出少量的手续费就可以使用链的基本功能, 同时减少用户操作的复杂性. KuChain 使用手续费来作为资源的基本支付方式, 保证应用消耗的手续费相对稳定, 可以避免因为资源限制的波动影响应用的发展。
### 便于更新和拓展
KuChain 上基于合约实现的功能可以简单的通过更新合约的方式更新, 同时 KuChain 添加了基于链上配置触发更新的机制, 这样可以平滑的进行链基础代码的升级, 避免大量节点出现硬分叉的情况. KuChain 支持子链机制, 可以在使用子链结构拓展主网功能, 这样既支持拓展新功能, 也能保持主网兼容性, 使得 KuChain 即不会被 KuChain 发展限制, 也可以与 KuChain 技术发展同步。
### 性能容量上限可扩展
KuChain可以通过子链实现主链之外的计算链, 这样可以拓展主网性能容量上限, 通过基于子链来实现对于其他去中心化存储协议的激励层子链, KuChain上的应用可以使用海量的数据。
### 良好的原生跨链支持
跨链是目前区块链发展的重要方向之一, KuChain通过子链和静态账户机制可以很好的支持各种跨链协议, 这可以为KuChain带来更大的应用场景。
### 去中心化的治理机制
KuChain 不断探索更加去中心化的链治理机制, 基于 Layer 2 子链添加丰富的基础功能以支持更复杂的 DFS(去中心化金融服务)开发, 同时强化轻节点在链中的作用和功能, 在高性能环境下基于轻节点加强链的去中心化程度。
KuChain 的架构使得 KuChain 可以在其之外进行更多的实践, 打破 KuChain 带来的天花板. KuChain 将会不断探索更加去中心化的链治理机制, 在兼容 KuChain 的基础之上, 基于 Layer 2 子链添加丰富的基础功能以支持更复杂的 DFS 开发, 同时强化轻节点在链中的作用和功能, 在高性能环境下基于轻节点加强链的去中心化程度。
## KuChain 云图(Cloud Atlas)
我们深知宏伟蓝图更需要深耕细作，KuChain 社区将通过三个阶段逐步达成这一图景。
### 枢纽一 - 仙王 (Route 1 - Cepheus)
公链是资产载体，资产则是开放金融的价值媒介，我们希望 KuChain 能够满足日益增长的开放金融需求，KuChain 的第一阶段将向一条高性能低成本的金融公有链演进，专注于满足金融应用的商业化需求。
作为开放金融的基础设施，提供易用的交互接口与开发者友好的基础服务，让开发者构建去中心化金融应用的难度和成本降低。KuChain 将会支持与孵化金融公链的底层服务，例如 DEX 、资产交换协议，借贷，稳定币等等，这些服务作为开放金融的地基，支持更多金融应用的创新。
### 枢纽二 - 天龙 (Route 2 - Draco)
至此， KuChain 已经完成了一个繁荣的开放金融生态演进，KuChain 具备了成为开放金融区块链枢纽的能力，也能够将内部繁荣的金融生态共享给整个区块链行业。
KuChain 会基于跨链协议与其他区块链互联互通，为生态内的区块链提供金融和资产路由服务。同时也会探索在其他链的跨链实现，构建一条价值互通的多链生态。
### 枢纽三 - 凤凰 (Route 3 - Phoenix)
前两个阶段，KuChain 成为了一条支持多链互通的金融链，在此基础上，我们希望能够再次扩展 KuChain 在业务场景的适应性和灵活性，使用子链架构完成复杂业务或更具高性能要求的区块链业务。完成业务层和资产层的分离，成为更加通用的区块链解决方案。
子链架构将提供更加类似于传统互联网技术栈的开发体验，定义一种子链与主链互通的协议标准，探索更多区块链与业务场景结合的可能。
## 技术概述
如果将软件类比为生物，那么 KuChain 就是一个渐进式的，自我演化与迭代的有机生命体。
### 设计理念
我们希望 KuChain 具备犹如智慧生命体般的软件自适应性，面对未来纷繁多变的市场需求和技术演进，KuChain 在不重构具备共识代码的前提下，获得渐进式的演化和迭代能力，甚至能够产生应用与范式的突变，在未来不确定的软件环境中获得生物进化层面的领先优势。
达成这些结果的方式，一是渐进式的架构设计，二是从可扩展性和可适应性的层面考虑整体模块的组合与隔离，将状态迁移和改变足够抽象与解耦合，借助外部服务和可扩展的架构设计，让 KuChain 具备鲁棒性与适应性。
#### 高性能
高性能响应是 KuChain 的基础能力，通过引入基于二进制流的，更小更快的通信协议，能够将整个区块网络通信的数据读取解析性能提高，传输数据量缩小，验证人之前通信速率提升。
文件存储以自然界分形思想，使用可认证数据结构 —— IAVL+ 树形(自平衡的二叉搜索树)结构，提高查询写入性能的同时，支持版本化以及快照功能。
#### 节点多态
节点在 KuChain 网络中负责 KuChain 网络的交易验证、交易记账、区块打包等工作，还需在不同的业务范围内担任不同的角色。验证节点具备的插件能力和提供的额外服务决定验证人形态。对整个网络而言，KuChain 希望验证人不局限于单一职能，而是能够提供多种职能的多态体。
针对多变的链下业务和服务拓展方案，KuChain 使用插件来完成链和验证人的扩展需求， 插件方便插拔的加载与卸载方式，不影响链本身的执行， 验证节点可以通过配置插件按需求加载。例如区块浏览器插件，高性能索引数据库插件，NFT 资源存储与展示插件等等，他们可以拓展网络中验证节点的职能多样性，促进链形态的多态化。
验证人拥有多态身份且能够通过可插拔的方式自由切换业务能力，整个网络就具备了业务自适应性 —— 节点可以根据具体的业务需求选择支持哪些服务和扩展，因运算资源有限，使用量大的扩展将会被保留，使用量少的扩展会被逐渐淘汰。如果是服务于垂直领域的专业验证人节点，需要通过特有扩展完成自身对链的业务需求，例如交易所，钱包等同步节点，会为维护专有节点，进一步提高网络分散性。
为了更好的支持具备扩展性的运行时系统，在 KuChain 中会添加更多的链状态的拓展数据结构， 与原有的数据类型不同， 这些数据的存储和内存状态将会相对独立， 并且序列化结构中将会添加数据类型元信息， 以此增强这部分数据的兼容性和拓展性。
#### 计算迁移
KuChain 的高性能方案并不能突破单链本身的性能限制，当出现更加高性能的需求或更加激进的共识需求时，我们将使用子链架构完成计算迁移，此时网络出现业务逻辑与结算逻辑的分离态。
一些资源消耗量较大的服务和 DAPP 可以基于子链运行， 通过中继服务将计算结果或者核心状态同步到 KuChain 中， 这样后续可以添加存储、计算、DAPP、随机数等专用子链， 以此拓展 KuChain 的业务覆盖广度与深度。
使用二级链结构拓展主网功能， 即支持拓展新功能， 也能保持主网兼容性， 使得 KuChain 更具有演化适应性。主链和子链更接近于 Layer 1 于 Layer 2 的关系，在主子链架构体系中，主链将计算压力迁移至符合业务需求的子链中，主链只提供账务结清算功能。
当然，一对一的主子链通信机并不能满足整个网络的互通效率，KuChain 主链设计为多子链之间的互通枢纽，子链之间的数据和资产传递，会通过主链进行，自身的业务垂直能力将覆盖到各个子链中，子链之间的通信类似于更加精细化的专业分工，在 KuChain 网络内部完成数据资产通信的协议实现。
*详见子链架构*
#### 同/异构跨链
KuChain 内部网络通过主子链架构完成网状拓扑，同时也具备原生跨链能力，基于 Tendermint 共识和通信协议实现的区块链架构，将会具备与 KuChain 网络传输资产与数据的能力，我们称之为**同构跨链**，同时对于比特币网络和以太坊网络的资产跨链，我们称之为**异构跨链**。
KuChain 作为资产枢纽，网络中所有引起资产的余额变更行为，都会明确的写入区块中，每一笔转账或变化都会以 Token Transfer Msg 的形式记录在主链区块内，这样能够保证链的资产状态能够快速回溯并验证可执行性提供更加无需信任的跨链环境，为跨链网络可信的安全池。
最终每条链支持多种资产，一种资产可以路由到多条链中，加上子链架构的设计，整个 KuChain 网络在横向与纵向都将获得无限的延展空间。
*详见跨链与多链*
#### 多域
KuChain 尽可能的将不同的代码模块按照「域」隔离拆分，不同域处理自身专有业务逻辑同时，通过域间通信协议完成数据交互，链特定类型的服务都基于域完成。
##### 基础域
KuChain 基础域，涵盖 P2P 网络、共识算法和跨链通信协议三部分。
P2P 网络构建了一个防泛洪攻击的健壮网络基础，通过对模块域通信需求抽象与封装，将基础网络通信服务通过标准协议定义，提供其标准实现。
共识算法采用 BFT 拜占庭容错共识协议，在共识协议中，验证人节点有着不同数量 *投票权*，网络中的产块验证人可以通过投票来完成区块数据的写入。
采用了大多数投票 (67% 票权)的最优拜占庭容错来确保网络安全性。这些能够保证网络的破坏者具有较高的攻击成本(需要持有超过 33% 以上的票权)，共识协议能够识别出危害网络安全的行为，保证分布式账本数据的一致性。
##### 模块域
模块是 KuChain 业务逻辑的核心，其中涉及到链功能层面的模块，模块之间解耦与独立，为 KuChain 在各个阶段的功能演化提供基础。
###### Account
account 模块定义了 KuChain 的账户系统。用户需要指定用户名和地址进行区分，并且这个模块也指定了基本的交易和账户类型。
###### Asset
asset 模块定义了 KuChain 的资产管理系统。KuChain 支持多资产模型，用户一个账户下可以有多种不同的资产，都是通过这个模块进行管理。同时，asset 模块也提供了多种转账功能，包括账户之间的转账以及同一账户下不同资产的虚拟转账，比如委托或者冻结。
###### Distribution
distribution 模块定义了 KuChain 如何分配奖励给验证节点。详细的分配算法已经在这篇白皮书中有所涉及，这里不再累述。
###### Supply
supply 模块主要提供如下功能:
* 被动追踪链上代币的总供应量
* 提供和本币交互的范式
* 提供验证链上供应量的方式
###### Genaccount
genaccount 用来设置和创世账户相关的模块，创世账户主要包括系统账户以及初始冻结的账户，以及一些引导用的验证节点账户。
###### Genutil
genutil 提供一些和创世状态有关功能的模块，比如定义创世链的状态。
###### Params
params 提供全局可用参数的储存。
主要有两种类型，Keeper 和 Subspace。Subspace 是单独的空间，其中所有的 key 都有特殊的，配置过的前缀。而 Keeper 对所有存在的空间都有访问权。
Subspace 被单独的 keeper 所使用，这样可以存储私有变量，从而避免被其他 keeper 访问。Keeper 适合 government 这种模块，因为 government 需要对所有空间都有访问权。
###### Upgrade
upgrade 模块用于平滑地升级 KuChain 到一个新的版本。需要接受一个 BeginBlocker 的钩子，用以在某个特定的时间或者特定的块高度处理一次特殊的一次性逻辑。
需要注意，升级并不受 government 决定，而是需要协调各个验证节点。如果实现协调不好，那么升级是不安全的，会导致各个验证节点状态不一致，并且很难恢复。
###### Crisis
这个模块用以在链的不变量被破坏的时候挂起整条链。不变量通常在链的初始化阶段被设置。
###### Gov
用以 KuChain 的链上自治。所有对本币执行过抵押的用户都有投票的权利，票数由本币抵押量所决定，比例为一比一。这个模块提供如下功能或者特性：
* 提议：需要抵押一部分本币
* 投票：对符合条件的提议进行投票
* 赎回抵押：用以赎回提议时抵押的本币
###### Slashing
用来惩罚验证节点的非法行为，需要首先接受到证据。目前只有对双签的惩罚，双签是指，验证节点签名一个已经被签名过，执行过的旧块。当惩罚验证节点时，如果这个验证节点同时接受过其他用户的委托，那么这些委托用户也会受到惩罚。
###### Staking
抵押本币相关，用于支持 Proof-of-Stake 系统。这个系统中，通过抵押，用户可以把本币置换成为 Staking，从而换取成为验证节点的资格和投票的资格。
###### Evidence
用以支持提交和处理有关验证节点恶意行为比如双签，虚拟交易等的证据。
##### 插件域
为了实现更灵活的部署， 在设计 Plugin 架构时， KuChain 的很多功能，尤其是与外部交互的功能是基于插件的， 这方面的功能与链的逻辑无关， 主要负责与链外的交互。
KuChain 的很多 API 和服务基于 Plugin 实现， 一些 plugin， 如 DB plugin， 会强烈的与模块的实现相关， 为了减少这种耦合， 我们会基于通知消息来完成从模块向插件的交互
##### 通信域
KuChain 提供了大量 http 接口， 为支持应用开发层更加高效灵活可扩展， 我们需要 websocket 接口和基于消息队列的接口，满足大规模交易需求，或能够在峰值交易中开发者和用户无感知阻塞的方式处理。
借助链下消息引擎服务，KuChain 能够支撑高吞吐的交易峰值请求，帮助链在处理大量交易时提供一个缓冲，可以平滑整条链的访问压力。
通用消息订阅/推送接口协议为多客户端提供更加无缝的数据结果高效回传功能。不仅能在高峰值请求下非阻塞的处理交易，让大量交易与链上状态变更的有序执行。通用消息订阅/推送接口协议会将最新的链上执行结果有序返回给客户端，完成链上状态数据改变与传输闭环，不仅能够获得更加高效率的写入读取操作，也能够快速获得当前区块状态，提升整体的应用体验。
## 子链架构
KuChain 需要满足性能和功能上的水平可拓展性， 同时保证主网络适配性， 为此 KuChain 将会加入子链架构， 不同于常见跨链架构， 各个子链是链原生的一部分， 与主网保持一致的节点状态， 子链通过状态同步来与主链进行“挂钩”， 以此证明其状态的有效性。
相对于各个不同共识下的链通过跨链机制组成的多链架构， 子链架构不会影响整个链的去中心化程度和共识， 很好的平衡了链的拓展性和权益。
### 子链
区块链采用 Hash 绑定的方式维持一个单链结构， 对 KuChain 来说， 一个块高度上最终有且仅有一个区块， 所有产出的区块中， 事务 (transcation) 和行为 (action) 都是有序的， 虽然通过并发执行结果不相关联的事务 (transcation) 可以使得链的计算充分利用服务器的多核环境， 但是依然会将链的节点限制在单机上。
原始的 KuChain 链称为主链， 节点的选举和治理都在主链完成， 在主链之外， KuChain 可以添加独立的子链， 子链与主链的共识保持一致， 子链的区块同样需要主链节点的验证，由于子链的大部分状态和行为独立于主链，所以对于一个节点，子链节点可以独立于主链节点运行，形成自己网络，甚至共识体系，这使得 KuChain 可以通过添加物理机器来拓展主网运行的性能。
通过子链，架构 KuChain 也可以在拓展功能的同时保持原有链的兼容性， 一些独立特定的功能可以通过子链添加至 KuChain 网络中， 形成数个专用子链， 这样网络中可以添加更多的特性以支持复杂的DAPP。
### 主子状态验证
子链独立于主链， 为了共享主链安全池，需要同步主链状态，以便于主链需要能够确认子链的状态与主链保持一致。对于各个子链， 其需要与主链保持一致的状态称为主状态， 子链自身的状态为子状态，一个子链中的区块， 除了主链验证节点的确认之外， 还需确认其主状态， 这样就可以确认一个子链的区块是否有效，子链即能获得主链的安全背书，又能证明自身的网络安全性。
在 KuChain 中， 子链需要进行主子状态验证， 通过在区块中计入主状态变换行为的 Hash 结果以证明其一致性， 这样可以通过主链的状态快速验证子链区块。
### 元子链
元子链是只包括 KuChain 主链主状态的子链， 对于各个子链来说主状态是验证其有效性的最基本的信息， 但是主状态是基于 KuChain 主链获得的， 子链可以基于元子链的数据来进行主子状态验证， 这可以允许子链进行轻量级的验证同步过程。
### 哨兵链
KuChain 区块数据与状态数据都是通过全节点重放计算得出， KuChain 客户端可以实现轻节点验证， 但是在可信的基础上无法直接获取链状态。
现有的大部分区块链需要用户通过中心化的节点或者服务获取链的状态信息， 这些信息并没有方式可以被证明是可信， KuChain 引入哨兵子链， 可以将状态变换信息至于哨兵子链之上， 使得链外应用获取到可靠的链状态信息。
哨兵链可以使 KuChain 更便捷高效的融入各种跨链场景中，增加链的可用性。
### 运算链
KuChain 的子链同样可以部署 DAPP， 这与常见的 Layer 2 扩展子链的模式相同， KuChain 将会创建一些对等的运算子链用于用户部署特定的 DAPP 或复杂逻辑的合约， 以实现拓展主网运行的性能。
### 子链间通信
KuChain 子链可以直接获取主链的信息和状态， 这些信息可以以两种方式进入子链的区块:
- 引用式
- 嵌入式
对于引用形式， 子链的区块中只包含主链信息的索引及 Hash 信息， 要全面验证子链的区块需要同步主链的状态， 这种方式可以使子链更加轻量化， 适合配合主链的功能性子链使用。
对于嵌入形式， 子链的区块中将会包含主链全部有关信息， 全面验证子链不需依赖同步主链的状态， 这种方式虽然会增加子链的数据量， 但是子链可以更加独立于主链， 这种方式适合比较独立的计算性子链使用。
通过以上方式可以实现主链到子链的状态传递， 以实现主链对子链的单向可操作性， 另一方向， 子链也需要传递部分状态到主链， 由于子链仅是主链的补充， 同时为了保持兼容性， KuChain 主链需要保持独立性， 所以所有子链向主链的状态转移都需要以嵌入的方式进行。
子链与主链之间可以实现的互操作性， 子链与子链之间也可以实现同样的机制， 实现的具体形式可以根据子链的作用不同而做出不同的选择。
## 跨链与多链
当 KuChain 具备了内部的纵向扩展性之后，外部区块链的交互通过跨链通信协议(IBC)将会赋予 KuChain 横向扩展的能力。
从技术层面实现跨链需满足：
- 共识算法需要具备及时最终性，在出块之后，需要能够快速确认为不可逆。
- 交易确认需要高效独立的证明方法，基于 Merkle 证明能快速验证。
KuChain 针对不同的链采用不同的跨链技术方案，达到价值转移的目的。
### 同构跨链
同构跨链是指需要通信的区块链系统，采用了 KuChain 相同的网络与共识标准协议，可以通过跨链通信协议与 KuChain 传递数据：
依赖 Tendermint 及时最终性的特点，用于枢纽与分区之间消息传递，IBC 协议中设计了两个消息：
- IBCBlockCommitTx：包含发送方所在区块链的最新的区块信息。
- IBCPacketTx：包含跨链交易本身的信息，及其在发送方链中被打包的区块信息。
在 KuChain 网络中，两个链建立连接之前需要进行彼此注册：
1、保存两条链的验证者集合以及 Merkle 证明的算法，这样接收链才能确保消息的正确性和来源的可靠性。
2、为对方链创建两个可靠队列，一个队列存放所以对方链的消息(outgoing)，一个队列存放来自对方链的消息(incoming)。
我们将跨链划分为三个阶段：
1. 用户向发送链提交跨链交易请求，发送链执行这笔交易，并将交易存入 outgoing 队列。
2. relayer 从发送链中的 outgoing 消息队列取出跨链交易数据，提交到接收链。
3. 接收链执行交易，放入 incoming 消息队列。
KuChain 通过跨链通信协议完成与外部链的跨链互操作，协议通过数据包交换，在多个不同的分区网络中流转资产与数据，也是 KuChain 作为资产枢纽和信任流转系统的桥梁。
### 基于中继的跨链方案
目前，比较成熟的方案是利用中继器来进行两条链的交互。
中继器的核心思想是把两条链上的操作互相回放，当然这里的操作特指资产的转换。
以下以 ETH 如何转账到 KuChain 为例
1. 在以太坊上设置合约，当合约被转入 ETH 的时候，会增发相应的代币 kuETH
2. 中继器接收到该笔交易，把增发的 kuETH 数量中继到 KuChain 对应的合约上
3. KuChain 上的合约增发 kuETH 数量的代币，发送到目标账户
反过来的流程如下
1. 账户把 kuETH 发送到 KuChain 合约上，合约销毁相应代币
2. 中继器接收到该笔交易，把销毁的 kuETH 数量中继到以太坊对应的合约上
3. 合约销毁掉对应数量的 kuETH，把 ETH 发送到目标账户
在此方案中，KuChain 需要依赖中继链处理 ETH 状态回滚的问题，但此问题可以通过延长中继链的确认时间来降低风险。
对于没有合约支持的公链，比如 BTC，这个方案并不奏效。
### 比特币跨链
为了解决 BTC 的跨链问题，我们考虑依托于 BTC 闪电网络系统。
闪电网络主要通过引入智能合约的思想来完善链下的交易渠道。核心的概念主要有两个：RSMC（Recoverable Sequence Maturity Contract）和 HTLC（Hashed Timelock Contract）。前者解决了链下交易的确认问题，后者解决了支付通道的问题。
基于跨链的属性，我们先描述哈希时间锁定。
哈希时间锁定支持一定数量的 A 链资产和一定数量的 B 链资产进行原子交换。它通过同时使用哈希锁和时间锁，从而迫使资产的接收方在 deadline 内确定收款并产生一种收款证明给打款人，否则资产会归还给打款人。收款证明能够被付款人用来获取接收人区块链上的等量价值的数字资产或触发其他事件。
但是哈希时间锁定依然需要两条链上都支持合约，所以为此，在 BTC 上引入了可撤销的顺序成熟度合同即 RSMC。这个技术的本质是资金池。
首先假定交易双方之间存在一个“微支付通道”（资金池）。交易双方先预存一部分资金到“微支付通道”里，初始情况下双方的分配方案等于预存的金额。每次发生交易，需要对交易后产生资金分配结果共同进行确认，同时签字把旧版本的分配方案作废掉。任何一方需要提现时，可以将他手里双方签署过的交易结果写到区块链网络中，从而被确认。从这个过程中可以可以看到，只有在提现时候才需要通过区块链。
任何一个版本的方案都需要经过双方的签名认证才合法。任何一方在任何时候都可以提出提现，提现时需要提供一个双方都签名过的资金分配方案（意味着肯定是某次交易后的结果，被双方确认过，但未必是最新的结果）。在一定时间内，如果另外一方拿出证明表明这个方案其实之前被作废了（非最新的交易结果），则资金罚没给质疑方；否则按照提出方的结果进行分配。罚没机制可以确保了没人会故意拿一个旧的交易结果来提现。
另外，即使双方都确认了某次提现，首先提出提现一方的资金到账时间要晚于对方，这就鼓励大家尽量都在链外完成交易。通过 RSMC，可以实现大量中间交易发生在链外。
但是同样，闪电网络依然在早期，相关的清算节点并不成熟，所以 BTC 的跨链需要更长时间的探索。
跨链作为目前区块链的研究前沿，相应的方法和标准正还未完善，KuChain 也会考虑最新的方案来使得跨链方案更加便利和快捷。
## 智能合约虚拟机
智能合约越来越成为区块链重要组成部分之一。而 KuChain 未来不仅需要跨链支持并且还需要提供 DFS 支持，所以合约是需要 KuChain 思考并且实现的。
部署合约和执行合约本质上是链上的一条特殊的消息，这条消息会调用对应的合约代码，并且把代码交由合约虚拟机执行。
目前主流的合约虚拟机由两种，一种是 Ethereum 的 EVM 虚拟机，一种是新一代的 WASM 虚拟机。
相对来说 EVM 引擎采用率较高，但是从 EOS 开始，目前新一代区块链技术栈也会基于 WASM 的虚拟机实现。 但对于一条具备高度演化性的链来说，使用哪种虚拟机并不是固定的， 支持不同的虚拟机或脚本系统可以很大程度上简化 DAPP 开发的难度。为了更进一步降低开发的门槛，我们考虑定制虚拟机从而可以让现成的合约代码不经过修改或者少许修改就可以在 KuChain 上执行。设计上，KuChain 不仅会兼容 EVM 虚拟机，也会支持 WASM 的虚拟机方案 ，未来 KuChain 也会持续探索执行引擎解决方案。
不过相关的兼容性技术发展也并不成熟，要达到生产环境的可用性也要看未来的调研和探索，也不排除做一条独立的合约子链，通过中继进行跨链互通的方案。
---
## 应用
KuChain 的演化自适应性，是来自其广泛的应用生态，在设计之初，就考虑大规模商用领域的应用需求，包括纵向与横向的拓展架构满足不同形态的业务、插件化的设计支持多元化的数据支持、高吞吐量状态队列融合链上链下服务，足以构建更多高性能低成本的商业应用产品。
### 高性能可信交易协议
基于 KuChain 现有的技术架构，KuChain 具备制定并实现高性能可信交易协议的能力，当前市场中的交易全部上链 DEX 虽然足够安全，无法满足商业级别的量化交易需求，虽然也有基于零知识证明的链下撮合方案，但链上结算其依然受整个网络的吞吐量、链 TPS 的性能瓶颈限制明显。
我们认为，链上与链下结合的方式能够平衡 DEX 安全与高性能的解决方案， KuChain 为可信交易协议提供更加符合需求的原生支持，如链下消息引擎，插件域特有数据结构支持，高性能索引查询服务都为解决高性能可信交易协议提供支持。
在链下提供高性能的撮合引擎，通过维护临时账本，撮合服务可以达到几十万级别的 QPS 性能，能够满足量化交易者或机构交易者对资金安全和交易性能的需求。
#### 高性能撮合引擎
高性能撮合引擎是高性能可信交易协议的基础，通过高内聚服务，同一服务簇共享相同的内存空间，将服务簇中相关的撮合、计算操作所依赖的内存寻址操作成本降到最低，可构建低成本高性能的撮合服务。
撮合内服务功能内聚，相关链路最简化，提升性能
- Account —— 账务新增，动账变化
- Trade —— 记录委托中订单，撮合订单，取消订单
- Market —— 成交订单后，引擎内orderbook维护，推送数据变更
基于内存共享服务簇的性能基础，链下撮合不仅会维护高响应级别的账务变更服务，也会基于流式响应的消息服务引擎为订阅者推送实施变动的市场数据，包含 orderbook 变动信息、Level-1、Level-2、Level-3 等实施买卖盘数据，可满足不同频率级别的交易策略。
#### 高性能服务簇
撮合服务整体架构是基于内存和消息中间的。撮合外部服务实际上是一个个指令转换器，将用户请求转化为相关指令。
用户请求到用户最终结果流程：
1. 用户请求在外部服务转换为对应指令
2. 指令放入消息中间件
3. 撮合引擎收到消息，基于内存迅速处理，生成指令结果
4. 指令结果放入消息中间件
5. 指令结果被外部系统获取，更改指令结果，用户获得最终数据
**Account 账务**
账务服务主要负责用户资产预授权，解除资产预授权，查询账户明细等功能。用户发起非查询类请求，需要向撮合引擎发出指令，等待撮合引擎最终处理。查询类则直接在账务服务中处理。收到撮合指令处理结果后，更新账务信息。
**Trade 交易**
负责用户下单，撤单，查询交易明细等。用户发起非查询类请求，需要向撮合引擎发出指令，等待撮合引擎最终处理。查询类则直接在交易服务中处理。收到撮合指令处理结果后，更新交易信息。
**Market 市场**
提供 k 线图，市场近期成交记录，市场 Level-1， Level-2， Level-3数据。市场服务也是基于内存的，所以相关数据的处理能紧随市场变化。市场服务的数据源自于撮合引擎的成交指令结果。收到撮合指令处理结果后，构建或更新市场数据。
**Support 支撑**
支撑服务主要提供一些链上数据查询类工作，例如用户公钥，交易对，币种等相关信息。这些信息，大部分是与用户行为校验相关。建立链下支撑服务的优势是：避免大量的请求与链上进行交互，减少链上负载。2。减少校验链路长度，降低校验时长，提升用户体验。
**Engine 撮合引擎**
撮合引擎主要负责外部指令处理，基于内存计算，使得相关指令处理非常迅速。在指令结果处理后，存入消息中间件中。
对程序化交易者，高性能可信交易协议中，链下撮合引擎会提供交易所需的所有数据支持，在撮合引擎进行的交易策略执行和操作除非进入到撮合流程，否则不会收取任何任何手续费用，体验与中心化的撮合交易服务一致，高频交易做市商能够以非常低的成本参与到流动性提供活动中，增加交易市场的深度，无需担心链上 Gas 和交易策略费用消耗。
##### 资产预授权冻结
链下与链上各自维护同一套账本，高性能撮合引擎需按照周期同步链上账务状态变更，链下为辅链上为主的方式完成资产的结清算。
交易所在 KuChain 链上注册交易所账户身份，获得交易所专有私钥，用于处理 DEX 用户预授权的交易资产。这部分资产属于用户预授权给交易所，其依然拥有着资产的所有权和处置权，并非转移给 DEX 账户所有。
每一笔订单都需要用户所持有的私钥进行签名授权，确保整个流程没有身份冒用和资产双花问题，
基于此设计能够避免出现交易所“携款跑路”，用户资产无法找回的情况，也能够满足机构交易者的风控模型，用户资产的所有权，由区块链网络和分布式账本保障其所有权。
预授权冻结为解决链上链下对账间隙，用户资产在同一打包区块内变动造成的账务异常，最终导致撮合订单失败的问题。
用户通过私钥签名指定 DEX 的公钥预授权一部分资产，撮合引擎会接收用户发送的订单信息，并以价格时间序列完成订单薄的维护，当用户取消预授权，则撮合引擎会通过链下的 Demon 服务获得推送消息，此时链并不会立即执行用户的取消授权申请，而是会通过延迟区块状态，链下引擎会在此期间完成用户所述订单的汇总与撤单，在取消预授权执行之前完成链下与链上资产的结清算。
##### 交易重放与交易所作恶
链下撮合引擎面临的核心问题是撮合过程无法像链上交易一样公开透明，撮合引擎虽然无法获取到用户的资产和私钥，但会有利用用户签名的交易进行交易重放攻击，如果交易所重放了用户拥有的余额，能够骗过链上结算的账务变更，这就给交易所作恶的可能。
为解决这个问题，协议将会要求撮合引擎的运维者必须按照整个链下交易的真实数据完成订单数据的时间范围的快照，将所有链下发生过得挂单撤单操作进行快照留存，以某个时间周期为单位做订单的数据摘要，并提供查询检索服务。
同时撮合引擎需要将周期性的订单数据用 SHA256 的方法，将时所有用户操作和订单进行 Hash 摘要， 并通过链上接口保存至区块链中，这样用户一旦出现账务问题，就可以通过交易订单回溯，匹配哈希，查询出某个时间段的重放攻击记录。
通过周期订单的哈希摘要上链，能够限制撮合引擎使用用户签名的交易信息进行重放攻击，也提供了查询回溯服务，用户通过链上信息验证交易所的作恶行为。
一旦发现交易所出现的作恶行为，社区将会通过提案完成 DEX 创建抵押账户的惩罚，以弥补用户被重放攻击造成的损失。
第一阶段，KuChain 将提供高性能去中心化交易协议的原生支持，定义链下撮合标准，防止撮合引擎作恶，第二阶段子链架构完成后，将会把整个撮合账务和引擎迁移至子链架构实现，届时交易协议的性能会得到进一步的提升，还会完成 DEX 撮合引擎之间的深度共享和订单转发分佣的交易协议升级。
### 去中心化低成本存储协议
KuChain 的未来的子链架构，为链的扩展提供了新的思路。子链可以通过储存协议，支持更大的存储空间，从而能够支撑更加多元化的金融业务场景。
我们考虑把去中心化存储协议作为 Layer 2 层的存储扩展，Layer 2 层可以访问 Layer 1 层也就是主链(Beacon Chain)的数据，同时子链实现自己的共识和激励模型，最大程度地把主链业务和子链系统剥离。
去中心化存储协议会成为 KuChain 子链上存储服务的标准实现，其他 Dapp 或子链可以集成实现好的协议库或者自己实现协议来提供数据的大存储服务。
同时 KuChain 也考虑提供一条专门用于存储的子链，可以为其他子链提供标准化的服务。
**KuChain Layer 2 存储协议子链**
KuChain 的存储子链将会在 IPFS 协议基础之上引入链上激励与惩罚机制， 通过这条子链用户可以在链上使用大型状态信息， 以此支撑更加复杂的 DAPP 。
当前的 KuChain 中， 存储状态主要由两个途径完成：
- 基于区块数据
- 基于状态数据
前者无法与合约层去中心化的交互， 而后者的成本过高， 无法支持海量数据的存储。
存储子链将会允许 KuChain 支持可信的海量数据，并且作为一条子链，本身也需要引入专门的角色来完成对应的职能， 存储子链的验证节点的选出和其他子链保持一致，都需要主链批准。功能性的逻辑将会基于存储子链完成， 其中主要包括三个方面: 数据元信息管理， 存储有效性证明和存储经济系统。
- **存储子链中的角色** 存储子链中有三类角色: 矿工 (worker)， 数据所有者 (owner) 和验证者 (checker)。这三类角色基于存储数据功能的不同而互有重叠， 矿工实际存储数据， 其需要向链完成存储有效性证明， 以此被系统奖励和惩罚。数据所有者是数据的提供者， 其需要向系统提供数据的元信息并进行验证确认， 验证者可能是存储子链上的任何角色， 其根据实际的状态会对矿工发起存储有效性证明挑战， 以此确认有效性。
- **数据元信息** 为了验证存储海量数据， 需要在链上建立大量数据元信息及其索引信息， 这些数据存储于存储子链的RAM中， 不同于一般合约使用的多重索引数据结构， KuChain 将会优化数据元信息的存储， 使得存储子链可以支持大量的存储元数据。
- **存储有效性验证** 为了确认存储的有效性， 需要矿工和数据所有者完成存储有效性验证， 以此来证明在一定概率下其角色可以提供完整数据， 存储有效性验证可以由存储子链上的任何角色发起， 如果对应角色无法在一定时间内完成存储， 其将会受到对应的惩罚。
存储子链需要建立对应的激励惩罚机制，这部分由子链提交请求，主链实施，但是主链不需要了解存储子链的状态数据。
### 数字身份
数字身份作为金融应用的基础设施，为用户与金融应用开发者或服务商提供基础的去中心化身份体系，在 KuChain 设计之初，就考虑了如何在 KuChain 实现一个面向金融服务的数字身份协议。
为此添加了账户的支持，在地址的基础上，实现了一个基于账户名的账户体系， 这个账户体系并未和链的基本功能绑定，而是提供了预留的支持，为数字身份协议的实现提供基础。
数字身份协议，一方面支持用户的链上链下身份绑定，提供可控的数据隐私保护、存储、迁移服务，另一方面需要满足金融或商业服务的数据需求，集数据授权，分析，共享，交易于一体的去中心化数字身份系统。
#### 用户
KuChain 提供一套基于存储子链或整合其他去中心化存储服务的身份客户端，用户可以将自己的身份信息上传至去中心化的存储网络中，所有信息通过用户私钥授权管理。
协议协助用户将自身的身份信息进行多维度管理划分，用户通过对身份信息划分维度的授权操作进行管理，能够清晰的管理自己的信息授权，并控制授权的范围和维度，用户在应用中产生的个人信息数据也会由用户自身拥有。
同时基于区块链账本的账务结算体系，用户通过授权商户某些数据而获得有偿激励，能直接获得自身数据的定价权和数据使用的收益权。
同样，应用对用户数据的转售，也会由用户授权是否开启，如果开启，则用户能够获得转售数据的大部分收入。
#### 开发者
应用开发者的应用只能获得提供服务的必要用户信息，且这些信息在用户无授权的情况下，无法单方面获取。
而且在用户使用应用之前会明确的知道应用所需要的用户权限，从而决定是否需要授权身份信息，用户在应用中的使用数据也会通过授权的方式授予应用，应用对用户信息的转售操作会将大部分收益分配给拥有数据所有权的用户。
#### 数据公司
数据公司需要有偿的购买用户数据，通过提出需求和询价的方式来完成数据发现，数据采购会通过链上交易的方式结算给所有信息所有权的用户。这个过程无需第三方参与，且能获得实时的所需的数据信息。
### 去中心化保险
当 KuChain 中具备了高性能的 DEX 服务，用户身份协议，那么我们能够基于此构建去中心化保险业务，基于稳定可靠的预言机与数字身份服务，通过链上合约和一些 DFS 的组合，能够支撑链上保险业务和服务。
相较于传统保险业务理赔难、管理成本较高、风险难以识别的问题，去中心化保险服务通过不可篡改、强制自动执行的智能合约的信任机制来为传统保险业务赋能。
开发者通过使用 KuChain 去中心化保险协议构建一个去中心化保险应用，该应用允许任何人创建并发行保险产品。KuChain 将包含产品信息、保费等属性的保险产品写入智能合约，用以保证其他用户购买及理赔将通过智能合约进行约束。
#### 保险产品定价
使用链下计算和链上预言机喂价实现保险产品定价。首先链上预言机获取历史数据并将其发送至链下专有算法中，链下精算系统根据返回数据建立模型并计算保费，最后将结果发送至链上智能合约。
#### 分散风险
通过搭建风险共担池确保风险分散且能够以更低成本进行赔付。对于基于大数法则下小概率事件的保险产品来说，风险共担池既提高了产品交易流动性也保证风险赔付以一个极低的成本进行，从而降低了风险。
#### 保险赔付
链上预言机作为判定是否赔付的依据，它首先将数据传输至智能合约，智能合约再判定是否触发赔付，若是，则自动赔付。
### 去中心化信托
链上信托作为 KuChain 未来业务探索的方向，当网络中流转的资产逐渐增加，针对资产托管和继承的需求会产生，我们通过构想一种信托的使用场景来启发更多资产与智能合约结合的可能性。
#### 合约自动托管
信托基金将用户资产在智能合约中托管，可以单独托管或是多方通过数字签名管理，甚至考虑通过很多先进的私钥保管技术完成整个资产所有权的控制，降低用户使用信托协议的门槛。
待未来生物科技技术逐步发展并商用过后，将人类的生物指征（例如指纹，面部识别甚至 DNA 编码等）与数字签名结合，来管理私钥，完成受益人身份确权和资产转移。
#### 信托基金的增值
信托基金不仅需要做到安全便捷的托管和分配，还需要有保证稳定增长的能力，在智能合约中，我们希望合约具备资产增值的能力，当网络中的 DEX 和 DFS 足够成熟，那么智能合约可以将基金的一部分资金投入，获取稳定增值或分红，为 DFS 提供流动性的同时产生稳定的资产增值。
#### 基金分配与继承
因为信托基金的执行者是智能合约，那么其可以具备按时解锁一部分资金的给受益人的能力，作为受益人，按照信托基金的解锁周期申领解锁的资产，托管合约也可以设置在某个时期对解锁账户进行变更和资产转移，甚至可以在某个触发套件停止之后，进行合约中资产所有权的变更，完成资产的继承转移。
---
## 共识机制
KuChain 的共识机制基于成熟的，被广泛使用的 Tendermint 共识引擎，更加高效且抗分叉的共识机制是区块链操作系统的最优选择， Tendermint 能带来更快的处理速度，更大的交易容量，更短的确认时间，更低的分叉风险以及更多的解决方案，也能为之后计划中的跨链需求提供更完善更平滑的基础支撑。
其设计上是严格的分叉问责制，这保证了出块不可逆，提高了确认速度。而为了达到这个目的，其使用了高性能的，一致性的 PBFT-like 共识引擎。PBFT 的复杂度通常是 \Omicron({n}^2)，时间复杂度随节点数量增加而迅速增加，这要求控制验证节点的数目。对此引入了 proof-of-staking ，用以从参与的全部验证节点中选择出一小部分节点出块，从而达到了性能和去中心化的平衡。
KuChain 会根据整个金融应用生态的发展需求对其维护与扩展。
### 一种公平的基于时间权重的 PoS 投票治理机制
现有的 PoS 共识都是再以强调治理为核心，但在项目实际的运行过程中，大部分持有代币的网络用户都变成了沉默的大多数，甚至很多用户关注的核心不在于治理权益，而是 PoS 抵押收益。
KuChain 希望通过一种公平的机制，鼓励用户参与到治理中，并从治理的过程中获得收益，借助这种机制，激励关注治理而非收益的网络用户，同时将治理权益的定价权交给市场，KuChain 并不会给治理权定价。
#### TPoS
KuChain 早期社区成员，提出了一种公平的基于时间权重的 POS 投票治理机制 TPoS，将代币的治理权益通过时间权重的分发方式与网络原生代币权益分离，将会在 KuChain 未来通过社区讨论完善后实施。
##### 治理机制
着重描述投票人激励部分，系统将代币的投票权益剥离出来，生成新的投票代币。
系统代币分为两种
1. 原生代币 —— KCS 作为系统本身发行的代币，仅可用于转账和链上应用使用，不可投票
2. 投票代币 —— Vote 投票代币，可以用于投票
1. 投票代币只能通过抵押原生代币获得。
2. 投票代币投票后可以获得系统增发对投票人的激励原生代币(KCS)
3. 投票代币数量和原生创世代币(KCS)一致
4. 投票代币分为 1 个月，6 个月，12 个月和 24 个月，四个不同时间类型的投票代币锁定池，不同时间类型的投票代币数量为总投票代币数量 / 投票代币类型数，这里的例子为总投票代币数量 / 4，为每个时间类型的投票代币数量
3. 节点投票数仅同步自己节点下所有委托的投票代币 Vote 的数量，节点激励以投票代币数量为准。
##### 投票激励分配方式
系统针对投票人的激励，每次发行平均进入不同时间类型投票代币的激励池，比如如果有 4 个同步时间类型的投票代币，就把针对投票人激励增发的代币按照每个块平均分配给 4 个投票代币激励池。
投票代币获得方式：
- 不同时间类型的投票代币(Vote)通过使用系统代币(Coin)参与质押拍卖获得
- 拍卖方式
- 每个时间类型的代币单独质押拍卖
- 拍卖分 10 次每次平均数量拍卖，每次拍卖所得的投票代币(vote)分对应不同时间类型奖励池的 10%代币的收益权。这样不同批次拍卖的投票代币的抵押收益率会不一样，同样时间类型的投票代币(vote)越早参与的拍卖者持有投票代币(vote)的收益率会高。注：即时拍卖也可因为每一张投票代币对应的系统代币比率不同，那么抵押收益也会不同。
- 每次拍卖的投票代币(vote)会有不同的票面价值(对应的抵押原生代币数量不一样)
##### 节点惩罚与赎回
节点惩罚时直接销毁对应惩罚比例的投票代币(vote)，相对应的可兑换的原生代币也会一同被销毁。
用户如果选择赎回，则在投票代币(vote)到期后可以选择赎回对应投票代币(vote)质押数量的系统原生代币，投票代币返回给系统。
每个类型代币每积累一定数额之后即刻开始质押拍卖，拍卖期间这部分投票代币应得的收益平均分配给现有有效投票代币也可累计给当期拍卖人。
##### 交易
所有投票代币可以链上交易，交易后继承在拍卖时获得收益率，也就是 Vote 置换回 KCS 的比率会随着 vote 所有权的转移而转移。
### 验证人
验证人网络排名会根据整体的获得的资产抵押占比权重(后面统称「票权」)来决定其产快的概率和投票的权重，在网络中用户抵押自己较多的节点就拥有较多的票权和较多的产块收益， 而抵押较少的节点拥有的票权和整体产块收益较少。
权重值被称为投票权重，一般通过 staking 的 KCS 数量计算。而任意节点，如果投票权重是正值，这个节点就可以被称为验证节点。每一个新块的产生，都需要验证节点广播参与其中，负责区块的签名，投票，赞同从而使验证节点对这个块达成一致。
所有的验证节点都会尝试在任意一个时间内为某一个区块达成一致。第一轮由提议者进行提议，如果这一轮不能达成一致，那么就会重新选择这一轮的提议者，重新开始新的一轮投票：
1. 对某一个区块达成一致
2. 在空区块上达成一致
提议的顺序由事前确定的顺序决定，这个顺序很大程度上由投票权重所决定。
验证人将行使其宝贵权利，对区块写入进行投票表决，通过打包区块获得验证人激励，持币用户也可以选择网络中的验证人，进行质押投票，获得区块打包的收益。
### 提议人
KuChain 网络中的提议人是持有 KCS 并参与到验证人抵押的网络用户，我们称之为提议人，他可以通过使用自己持有的私钥签名一笔抵押交易，使自己手中的一部分数额的 KCS 从未抵押状态进入到抵押状态，也可以像链上发起交易，将委托的代币从抵押状态进入到未抵押状态，处于对网络安全的考虑，赎回操作需要有 14 天的解除抵押等待期。
如果提议人想要转投验证人节点，那么可以直接进行转投操作， 无需解除抵押状态，提议人可以发起领取分红的操作，抵押的收益将从奖励池转至提议人账户。
### 轻客户端
KuChain 能够支持客户端在没有全节点数据的情况下，低成本的验证交易，可以提供移动端的支持。比特币轻客户端必须同步运行区块头组成的链，并且找到工作量证明最多的那一条链，而 KuChain 轻客戸端只需和验证组的状态保持同步，通过验证最新区块中预先提交的 > 2/3 来确定当前链上的状态。
---
## 发行与激励
### KCS 代币
KuChain 的原生通证为 KuChain Score，简称「KCS」，发行总量为 2 亿，是基于 KuChain 发行的的区块链数字资产，是治理权益、网络使用权益的集合。
### 验证人的数量限制
网络启动之后的第一个四年，KuChain 将会有 33 为产块验证节点，每四年增加 33 名，之后维持在 99 名产块验证节点。网络中的区块投票或提案投票都会遵循 2/3 的票权比例，作为链上决策依据。
在 KuChain 启动后，为了降低验证人参与的门槛，区块大小的在 1M ，如果在链运行的期间内没有扩容需求，则会在四年之后例行扩容至 2M 大小，再隔四年继续升级，确保节点在硬件成本不变的情况下，提升网络吞吐量和手续费收益。
PoS 网络的验证数量的增加会导致网络的吞吐量变慢，KuChain 能够支持较多的节点验证人参与到分布式网络中， 并保证节点进入门槛第，且网络具有较快的交易确认时间。随着摩尔定律的硬件成本减半逻辑，我们认为节点的性能会在每四年提高一倍，那么依然维持相同的节点加入门槛，每四年升级一次区块大小，完成网络吞吐量的升级和网络节点的扩容。
创世验证人的最大数量将设置为 33 位， 这个数字将以 100% 每 4 年的速度增长 8 年， 最终达到 99 位，达到 99 位验证人之后，网络会根据整体的验证人和硬件成本情况通过共识决定是否继续增加验证人数量。
### 验证人的区块奖励
验证人的收益取决于以下因素：
- 验证人打包区块获得的共识比例，以 2/3 ~ 3/3 的节点投票结果为范围，决定验证人的收益
- 区块的收益中会有 20% 的基础收益分配给当前产块的节点
- 剩余的 80% 会扣掉节点自己设置的抵押手续费率分配给投票给节点的 KCS 提议者
- 提议者获得的收益按照其抵押在节点中的 KCS 占比分配
当网络中的资产抵押率在 1% ~ 67% 时，整个网络的抵押收益率为抵押总量的 13% ~ 5% ，当网络抵押率超过 67% 时，抵押收益率将维持在抵押总量的 5% 左右，整个收益按照每个区块计算并发放，验证人和提议人需要手动提取之前累计的 Staking 收益。
KuChain 中每当出一个区块的时候，会对上一个区块进行收益计算。
提议者 (proposer) 和验证者 (validator) 所有奖励都来自于处理交易而来的 gas fee 之和。
$Fee = \sum_{i=1}^{n}fee_i$
$Ratio_{base}=$系统设置的提议者的基本分成
$Ratio_{bonus}=$系统设置该提议者能额外分得的部分
${Multiplier}_{bonus}$ 定义为 $\frac{\sum_{i=1}^{n}\nu_{i=signed}}{\sum_{i=1}^{n}\nu_{i}}$，$\nu_{i}$ 表示上个区块的验证者的投票权重，$\nu_{i=signed}$ 表示对上个区块验证并签名的验证者的投票权重
而提议者能分得的比率为:
${Ratio}_{proposer} = {Ratio}_{base} + {Ratio}_{bonus} \times {Multiplier}_{bonus}$
由此，提议者的奖励为
${Reward}_{proposer} = {Fee} \times {Ratio}_{proposer}$
$Fee$ 的一部分会作为税奖励给区块打包者
${Ratio}_{tax}=$系统设置的税率
${Ratio}_{validators} = 1 - {Ratio}_{tax} - {Ratio}_{proposer}$
对单个 Validator，其收益计算如下
${Reward}_{validator}=Fee \times {Ratio}_{validators} \times {\frac{\nu_{i=k}}{\sum_{i=1}^{n}\nu_{i}}}$
### 对验证人的惩罚
KuChain 会通过网络协议完成作恶验证人的惩罚，对于任何有意或无意对网络造成危险的验证人节点， 会对其施加一定的惩罚。
有些惩罚会区块结束的间隔立即执行，比如双重签名，或违反 “预投票锁定” 。这种链上的不诚实行为会导致验证人失去其良好的声誉和影响力，其绑定的 KCS 以及在储备池中的比例份额 – 统称为 “权益” 会被扣减 5%(包含验证者和提议者)，并监禁 14 天，监禁期间无法验证区块并获得区块的验证人收益。
如果验证人在最近 1000 个区块漏签 500 个块以上时，会被监禁 10 分钟并扣减 0.01% 权益。
### 治理
#### 治理架构
KuChain 既不主张原教旨主义般单纯的链上治理，也不忽略链下社区用户的表决和意愿，我们希望使用链上与链下结合的方式，推动网络和社区的发展。
#### 链上提案
链上提案分为文本提案和参数变更提案两种类型：
文本提案需要链上决议，链下执行，接受社区监督并鼓励节点最终提议人的表决和意见。
参数提案则是需要验证人表决修改链上参数，全部过程在链上公开的进行。
##### 提案流程
- 用户抵押保证金 KCS 提交提案，达到最低保证金要求后进入投票期
- 如果提案未进入投票期，可以将保证金退回
- 投票时间为 14 天
- 验证人选择提案投票类型
- 同意
- 强烈同意
- 反对
- 强烈反对
- 弃权
- 提案根据验证人所拥有的委托票权比例来统计结果
- 参数变更提案通过后直接生效
- 文本提案社区自行处理
- 需要对系统升级的提案，需要开发团队进行开发之后，验证人配合进行代码升级
##### 投票治理规范
1. 验证人未能在投票时间及时对提案进行表决，将被系统自动踢出验证人序列一段时间，默认为一周
2. 提议人自动继承其委托的验证人的投票权，当提议人自行投票时，这一投票可以被覆盖掉。
3. 每个提案，投票者可以表决取走保证金(为避免过多的无意义提案)，如果超过半数的投票者表决取走保证金，则保证金将会转入基金会账户。
4. 超过 1/3 票权的提案表决为「强烈反对」或「强烈支持」的结果，就可以否决大多数验证者的决定，如果大多数验证者投票被否决，那么这部分验证者将失去一天的出块奖励作为惩罚，而否决大多数验证者的这一方面，还将额外失去 0.1% 的 KCS 作为惩罚。—— 这一规则适用于当前社区对提案出现较大分歧，且少数票权无法战胜多数票权的情况而设定，防止整个网络出现多数人「暴政」。
#### 链下治理
链下治理作为链上治理的辅助与补充，将以基金会为主导，通过促进社区成员的沟通与交流，推进整个 KuChain 社区和生态的发展为核心目标，基金会行使的职能包括且不限于，对 KuChain 社区成员进行教育引导，引入具有交付能力的研发团队，孵化有潜力的应用项目，实施链下激励等。
## 路线图
- 2020Q2 测试网上线
- 2020Q4 主网上线
- 2022 KuChain Cepheus
- 2025 KuChain Draco
- 2030 KuChain Phoenix
Sign in with Wallet
Connect another wallet