# KuChain —— 安全、有效的资产流动性平台 ## 摘要 KuChain 是一条金融资产交易公有链,帮助资产交易服务商打造安全有效流动性、专业交易者友好、具备去中心化的资产安全和中心化交易体验的交易服务。借助高性能和低运营成本的共识引擎,保障用户资产所有权,并为具体的流动性业务提供原生的结算。 ## 背景 数字资产的流动性需求,自比特币诞生后,就伴随着区块链行业的发展一直存在,点对点的电子现金系统,催生了人们使用和交易数字资产的需求。以太坊的智能合约,让全民发行 Token 成为了可能,数字资产的数量呈指数级增加,随之而来的是对更多资产交易流动性的需求。 如今数字资产市场经历了十年的发展,行业中的参与者,不论是DeFi、项目方、投资机构、专业交易者、还是交易所自身,对流动性的需求依然没有被很好的满足。 历年频发的交易所安全事件,因宕机,被盗等等导致用户资产蒙受损失,加上交易服务商因为交易过程不透明而引发的订单抢跑(front running)与虚假成交等问题,导致中心化流动性服务遭遇信任危机。 市场需要更加安全、有效的流动性服务,在保障用户资产所有权不受任何人或因素侵犯,交易过程透明、可信等前提下,为所有人提供公平参与金融创新活动机会的交易服务。 ### 为什么安全有效的流动性如此重要 流动性(Liquidity) 是指在一个交易市场中,作为交换商品(Base) 在对其计价币种(Quote)价格影响较小的情况下快速买入或卖出的能力,是用户的资产价值在商品与计价币种之间快速转移的能力。 **充足的流动性市场代表着所有人都具备公平参与资产定价的机会,提供一个稳定繁荣的交易市场,用户能够快捷的成交自己的订单,研究机构能获取更加有效的市场信息**。 充足的流动性需具备以下特点: - 极低的要价与询价差 - 足够的交易深度 - 充分的成交量 - 可接受的交易费率 - 极小的滑点损失 流动性对交易服务商非常重要,安全有效的流动性是行业所迫切需要的,我们希望通过一种链下高效撮合,链上结算的技术架构,来满足对安全有效流动性的需求,基于分布式账本技术来保证用户资产所有权,通过高效共识机制保证网络稳定安全,再利用链上与链下结合的结清算机制保证交易服务商服务透明。 KuCoin 团队一直在寻找能够提供安全有效流动性的解决方案,比特币作为安全稳定的点对点结算网络,并不能满足我们的多资产链上流转的需求,以太坊经过验证也已经足够安全,智能合约支持多资产,但整体性能和扩展性不足。Cosmos-SDK 具备高度定制化的架构方案,定义了一套 IBC 跨链标准,基于 Tendermint 的高效共识引擎,能够实现一套支持安全、有效流动性平台的定制需求。 最终我们选择了 Cosmos-SDK 作为构建一个符合去中心化流动性需求的安全有效的流动性平台的技术架构。 ## KuChain 综述 ### 定位 KuChain 是 KuCoin 团队为交易服务商定制的资产结清算公有链,基于 Cosmos-SDK 研发,其核心目标是服务于安全有效的流动性需求,为去中心化交易所和各类 Dapp 的内部交易提供所需的安全、高效、低成本结清算服务。 KuChain 对业务的原生支持,让基于 KuChain 构建的去中心化交易服务更加安全、透明、高效,使其既具备中心化交易所的效率和体验,又保持去中心化交易所安全透明的特性。 ### 我们如何做 作为一个安全有效的资产流动性平台,将围绕**安全保管**、**多元资产**、**业务适应性**三个方向构建能够支持高效流动性的基础设施。 ## 安全保管 区块链作为分布式账本,以密码学和点对点的网络为基础,通过共识算法,保证了账本的分散性与一致性。 安全包括如下原则: - 用密码学中非对称加密算法,保障用户资产的所有权归用户所有 - 区块链网络中所有对账本数据的写入操作都需要经过密码学验证且达成网络共识后得到确认 - 所有试图对达成共识的账本进行篡改或对区块链网络造成安全威胁的有意无意的行为都会被发现且实施惩罚 KuChain 希望通过构建一个无许可的分布式网络来保证网络和资产的安全,用**共识机制**确保网络的分散性和账本一致性,用**严格结清算**设计与实现保证在链层面的资产变动都会被记录且可追溯。 ### 共识机制 KuChain 的共识机制基于成熟的,被广泛使用的 Tendermint 共识引擎,更加高效且抗分叉,能带来更快的处理速度,更大的交易容量,更短的确认时间,更低的分叉风险以及更多的扩展方案,基于 IBC 协议,为 KuChain 接入同构跨链资产打下基础。 严格的分叉问责制保证了出块不可逆,提高了确认速度。而为了达到这个目的,其使用了高性能的,一致性的 PBFT-like 共识引擎。PBFT 的复杂度通常是 $O({n}^2)$,时间复杂度随节点数量增加而迅速增加,这要求控制验证节点的数目。对此引入了 Proof of Staking ,用以从参与的全部验证节点中选择出一小部分节点出块,从而达到了性能和去中心化的平衡。 #### 验证人 验证人是网络和共识的维护者,其排名会根据整体获得的资产抵押占比权重(后面统称票权)来决定其产块的概率和投票的权重,在网络中用户抵押较多的节点就拥有较多的票权和较多的区块打包收益,而抵押较少的节点拥有的票权和整体产块收益较少。 权重值被称为投票权重,一般通过 staking 的 KCS 数量计算。对于任意节点,如果投票权重是正值,这个节点就可以被称为验证节点。每一个新块的产生,都需要验证节点广播参与其中,负责区块的签名,投票,赞同从而使验证节点对这个块达成一致。 所有的验证节点都会尝试在任意一个时间内为某一个区块达成一致。第一轮由提议者进行提议,如果这一轮不能达成一致,那么就会重新选择这一轮的提议者,重新开始新的一轮投票: 1. 对某一个区块达成一致 2. 在空区块上达成一致 验证人在 KuChain 网络中行使其宝贵权利,对区块写入进行投票表决,通过打包区块获得验证人激励,持有 KCS 的用户也可以选择网络中的验证人进行质押投票,获得区块打包的收益。 #### 网络攻击成本 KuChain 的共识引擎采用了多数投票决议制(超过三分之二)和锁定机制的最优拜占庭容错来确保其安全性。 其能够保证: - 对网络怀有恶意的攻击者,需要拥有超过三分之一的票权,且提交超过两份以上的值。 - 如果有一组验证人成功破坏了安全性,或者曾试图这么做,会被协议识别并处罚。 KuChain 和所有采用 PoS 共识的网络一样,需要达到 67% 的抵押率才能维持一个安全的网络状态,为确保提供一个安全可信的分布式账本服务,也会对所有试图威胁网络安全的行为给与严厉的惩罚。 对于一个持有 1/3 票权的攻击者而言,参与抵押获取验证人激励的收益会大过攻击网络所获取的收益,所以在攻击者收益的角度去考虑,整个 KuChain 网络是绝对安全的。 #### 治理 良好的治理体系,是保证链对环境自适应的基础,面对未来不确定的外部风险和变化,我们需要通过社区决议的方式完成链的调整,使其更具适应性,持续产生业务价值。 KuChain 网络中的决议通过提案完成,验证人通过对提案投票,从而改变链中一部分系统参数(比如区块转账费用限制),提案也可以对可读性的章程进行修订投票,或决定链下共识的执行方案,协作更新或升级验证人节点程序,从而参与 KuChain 的治理。 链下共识需要核心开发者参与商议,来解决盗窃及漏洞等相关问题,并得出更快更明确的解决方案。 ### 严格结清算 结清算是指除了链上的资产转账之外,对 Dex 交易引起的资产变动而在链上完成的相关债务的清偿,由于链下撮合与链上结清算的特性是链下与链上共同维护一套可信账本,链下的撮合将会以链上账本为主按照最新的区块同步账务,那么为了保证交易中账务的一致性和整个账务的同步性,需要链在结清算层面做到足够安全高效,使得核心资产 KCS 以及其他发行商所发行的资产,可以在 KuChain 网络内安全、透明的交易、流通。 结清算的原则是为了满足 Dex 对账务的需求,确保高效安全的结清算,为安全、有效的流动性提供坚实的支撑。 - 严格记录 —— 将所有链上资产变动严格记录到区块内 - 资产隔离 —— 用户交易资产与可支配资产隔离 #### 严格记录 网络中所有引起资产的余额变更行为,都会明确的写入区块中,每一笔转账或变化都会以 Token Transfer Msg 的形式记录在 KuChain 区块内,链上资产的变化不依赖于内存或其他不稳定的中间状态,以此来保证链的资产状态能够快速回溯,并为验证可执行性提供更加无需信任的跨链环境,为跨链网络可信的安全池。 #### 资产隔离 对于 Dex 来说,稳定的账务对账状态是维持高流动性与撮合性能的基础,在每个新区块中的交易得到确认之前,链下的撮合引擎会维护一套临时的账务,这个状态需要链提供严格的结清算的机制以保证交易体验和 Dex 的安全。 考虑到链下的账本变化和更新领先于链上,且账务状态会因为高频的交易和撮合快速变动,链的层面需要保证用户资产在交易所的状态是相对固定的,即使发生了交易过程中的链上转账,也不会影响交易的资产结算,所以要保证能够将用户用于交易资产和可随时转移资产进行隔离。 如果没有此功能设计,链也能够在撮合引擎提交了撮合的结清算请求之后拒绝掉这笔账务有问题的交易,但这个结果需要等待一个区块的时间才能得到确认和返回,Dex 的链下撮合会非常被动,需要处理链下撮合失败的订单撤回或恢复,此漏洞也会被攻击者利用,发送大量失败的交易导致 Dex 撮合效率降低,破坏流动性。这样虽不会造成用户资产安全的问题,但会造成撮合引擎花费大量的计算资源在订单撤销和恢复上,影响整个交易服务的交易体验。 KuChain 设计了一套隔离的结清算的流程,来保证整个 Dex 的账务和链上账本能够在隔离的环境完成撮合结果的结清算。 ##### Dex 交易的结清算流程 首先 Dex 的服务商需要在链上注册一个 Dex 类型的专有公钥(这个账号需要付出一定的成本),这个公钥用来帮助链完成 Dex 撮合交易的签名与鉴权,那么用户在 Dex 中进行交易之前,需要将一部分需要交易的资产委托至 Dex 的公钥,这部分资产归用户所有,交易的整个过程依然需要用户的签名授权才能被链接受并处理,只是用户无法使用这部分资产进行转账或在其他交易所交易,这么做的目的是为了能够在 Dex 中保持账户状态稳定,而用户可以选择随时取消委托这笔资产,只是这个请求需要等待几个区块间隔执行。 这样链下的撮合引擎就能够有足够多的时间处理不稳定的账务状态,如果用户取消委托,那么撮合引擎需要将用户相关资产交易中现有的订单取消,同时等待几个区块确认之后拿到最新的账务,完成账务状态的同步一致。 Dex 在处理交易的过程中会将成功的撮合订单进行撮合。 订单的结构如下: - 用户名/地址 - 方向 - 币种 - 金额 - 数量 撮合的交易数据结构如下: - 询价订单 - 出价订单 - 交易所信息 - 交易所签名 - 交易所公钥 **用户授权并处理交易流程** ```mermaid sequenceDiagram participant U as User participant C as Chain server participant D as DEX U->>C: delegate C->>+ C: verify & handle authorization Note over C: 1 block later C ->>- D: send event D ->> U: delegate success & init account U ->>+ D: sign & place order D ->>+ D: verify & check balance Note over D: match orders D ->>- D: match success D ->> C: sign & submit trade data C->>+ C: verify & handle trx Note over C: 1 block later C ->> D: notify result & update balance D ->> U: push to user ``` 1. 用户委托,委托给链账户一笔资产 2. 链会校验用户请求的合法性,包括签名和资产余额检查 3. 得到区块确认之后,Dex 能够通过监听接收到链上事件 4. Dex 同步当前用户的链上余额,初始化本地账本数据,并开启对该账户链上变动的监听 5. 用户签名了一笔交易订单,将请求发给 Dex 撮合引擎处理 6. 撮合引擎会验证交易签名的有效性同时检查用户的委托余额 7. 随后订单进入 orderbook ,匹配成功之后,Dex 会构建交易体 8. Dex 将成交记录签名之后提交给链 9. 链接收到交易之后会先验证交易所的身份,然后处理撮合交易 10. 得到区块确认之后,链将发送成功的信息给交易所,此时交易所的周期同步账本获得到了最新的账户资产信息 11. 交易所为用户确认成交清算成功。 ##### 取消委托 取消委托的流程是用户希望从 Dex 的委托账户将本来用于交易的资产取回,这个流程同样需要考虑资产隔离。 **取消委托流程:** ```mermaid sequenceDiagram participant U as User participant C as Chain server participant D as DEX U ->> C: cancel delegate C ->> C: verify C ->>+ D: push notiy D ->>- U: prenvent & cancel order Note over C: wait n block C ->>+ U: cancel confirm, balance change ``` 1. 用户发起取消授权并签名提交给链 2. 链接收到取消委托的请求,先验证后执行取消委托申请 3. Dex 的订阅服务接收到用户的取消委托的事件 1. 停止接受该用户后续相关资产的订单 2. 取消现有的活跃订单 3. 等待账务同步 4. 链等待 n 个区块之后,取消授权生效,用户资产变动 通过网络共识保障用户资产所有权,用过严格结清算体系保障资产流转的透明与安全。 ## 多元资产 多元资产是链作为资产流动性平台的核心功能,KuChain 链上支持多资产,对于 KuChain 来说,所有资产都是平等的,在网络中能够互相交易且具备较强的定制性。 ### 用户定义资产 KuChain 为社区用户提供了发行资产的能力,任何人都可以注册为资产发行商,为特定业务场景创建和发行对应的资产。我们称之为 UDA(User Define Asset) 。 UDA 是通过发行商身份在链上定制化的资产,资产的持有者可以将其当做原生代币一样交易。创建资产之前需要用户在网络中注册发行商身份(Issuer),之后只需要设置一些参数如供应量,符号,展示名称等基本信息。 UDA 生成之后,发行方可以向网络中任何账户空投或出售。这个过程中,发行商既不需要会编写智能合约,也不需要关注任何技术实现细节,就能用很低的成本创建一套基于去中心化账本的数字资产。 当然对于 Dex 的需求来说,UDA 也提供了符合需求的定制和支持,比如: - 资产设置增发规则,可以在资产创建时打开,或是永久关闭 - 资产唯一标志由`发行商用户名.资产编码`来标志其唯一性 - 资产名称可以修改 - 支持资产的燃烧和销毁 - 支持用户将资产锁仓至某一区块高度 #### 资产案例 - Dex 平台币 平台币做为 KuChain 网络中核心的组成部分,不同的 Dex 平台或多或少都需要借助自身的平台币作为价值传递的载体,平台币现作为权益和货币的形式在 Dex 内部或 Dex 之间传递价值,包括不限于,会员身份、邀请激励、手续费抵扣、持仓返利、链上治理决策等等业务场景,Dex 平台币是 KuChain 作为流动性平台之上的核心业务承载。 - 奖励积分 奖励积分作为商户引流或奖励用户的工具,积分累积到一定程度之后可以在后续的消费中抵扣金额,在 KuChain 发行的积分,能够通过 Dex 进行转让交易,为商户带来更多的业务增量。 - 数字资产 这里我们把数字资产当做资产数字化的一种方式,发行者将现实中的资产例如,古董,字画,房产等实物有价资产在第三方机构抵押,抵押机构发行一定量的数字资产将资产所有权用代币分离,并且可以在网络中快速流转并交易,提高实物资产所有权的流动性,也满足了实物资产的抵押者的资金流动性需求。 - 众筹 发行商可以发行资产作为凭证,代表股权或预售卷来快速筹集产品或公司的启动资金,发行者可以直接从二级市场融资,提高融资效率,二级市场的投资者也能够早期参与初创公司的风险投资,持有 UDA 的用户也可以选择在产品上线或公司启动之后在 Dex 里卖掉手中的资产。 - 公司债券 许多公司或企业都有扩大生产规模的需求,那么发行 UDA 可以帮助企业或公司再融资,帮助其获得更多的资金,UDA 可以在 Dex 自由交易,相当于创建了一个债券市场,增加了投资者的投资品类。 ### KuChain Non-Fungible token 不论是 UDA 还是原生代币 KCS 都是同质化的代币资产,虽然在资产案例中 UDA 能够很好的承载与传递价值,但市场中仍然有对非同质化代币的需求,KuChain 网络中将会添加对 NFT 资产的支持,我们称之为 KNFT(KuChain Non-Fungible token),在同一类型的 KNFT 中,每一枚 KNFT 都具有唯一的属性,即便是名称一致但在网络中具备独一无二的标志。 用户可以通过注册发行商,然后付出一些 KCS 来完成 KNFT 的发行,使用 KuChain 网络的转账空投等能力,将 KNFT 分发给其他用户。 ## 业务适应性 作为一个安全有效的资产流动平台,KuChain 希望提供的是一种通用能力,虽然一条链只服务于一个 Dex 的做法在行业内属于标准做法,但我们相信市场中对流动性的需求是非常多元化的,不论是资产的多样性,还是业务的多样性,我们无法只通过一个 Dex 去满足所有对流动性的需求。同时也需要思考即便是在去中心化的交易场景中,依然会出现流动性或定价权垄断的问题。 对于一个自由市场而言,KuChain 希望流动性可以在网络中以各种形式被表现出来,不论是基于何种技术架构(纯链上或链上链下结合),还是基于何种业务形态(Orderbook 或 Automatic market maker)都有其合理的应用场景,那其流动性的需求就值得被满足。 不仅如此,现有可预见的流动性业务形态将驱动 KuChain 成为更好的流动性基础设施,同时也要为未来不可见的流动性需求提供可扩展的接口与功能模块。 在这里我们通过几个方向来促进 KuChain 作为安全有效的流动性平台所需要的演化能力。 ### 流动性共享协议 流动性共享协议是指,在 KuChain 网络中,不同流动性服务商之间,通过 Dex 之间以订单转发的方式完成的一种链上结清算协议。 我们假设一种交易场景,Dex A 的运营商使用链下链上结合的方式来提供流动性,其具备提供主流数字货币流动性的能力,很多专业交易者和做市商都会在 Dex A 的盘口提供流动性。如果现在有一个线下社区,他们社区中之前流转了一些社区货币(后面统称为 Cash token : CT)作为结清算的媒介,假设他需要一个线上市场去完成 CT 的支付和流通,那么社区运营者可能会考虑通过在 KuChain 网络中发行 CT 来满足点对点的流转,如果社区运营者希望将 CT 的流动性放大,那么他会倾向于在 KuChain 中借助交易服务来完成 CT 的市场搭建。 此时,他最为省时省力的方法就是申请 CT 出现在 Dex A 的市场里,但也有可能因为 Dex A 的运营商会考虑整体品牌的风险或社区运营者无法承担 Dex A 的上币费用,甚至社区的运营者希望能够自己主导交易所的控制权,那么社区运营者会选择自己搭建 Dex B 服务。 在此情景下,会有几个问题和需求出现: - Dex A 的较强的流动性应该被放大 - Dex B 单一资产和流动性无法满足其运营需求 - Dex A 需要一种无侵入的方式为其他人提供流动性 - Dex B 的专有流量需要消费 Dex A 的流动性 - Dex 之前需要有可以进行流动性共享的共赢协议 流动性共享协议的实现,包含几个部分 #### 订单转发的申请与授权 Dex 运营商在创建 Dex 服务之前,需要在 KuChain 中注册 Dex 身份,这个身份主要用于交易所在链上结清算和抵押保证金和流动性共享协议使用。 依然用之前的 Dex A 和 Dex B 来说,如果 B 想使用 A 的流动性,那么他需要和 A 签订流动性共享协议,这个协议可以看做是一个链上的合同,里面定义了如下的约定: - B 可以将订单转发给 A 的某个交易对,其中会以交易资产的类型体现 - A 接收 B 在某个交易资产对中的撮合交易 - A 做为流动性提供商,将获得转发订单 *n%* 手续费作为服务费用 - B 需要提供 *n* 个 KCS 作为转发订单有效的保证金 - 订单转发的协议的有效期限 这些协议在链上完成签订,当协议生效之后,B 就可以直接使用 A 在某个交易对资产的流动性,双方拥有各自的用户授权账户,但能够使用相同的交易深度。 #### 订单转发 订单转发可以看做是 B 将所有关于共享协议包含的资产交易订单转发给 A 来撮合处理的过程,例如 B 社区的用户需要交易 CT,那么他需要通过 OTC 市场买入 BTC 充值到 Dex B,而此时 Dex B 只有 CT/USDT 交易对,那么如果用户只有 BTC ,他无法直接在 B 交易所里完成 CT 的购买,Dex B 为了用户体验和流量留存的考虑,需要 Dex A 帮助他处理用户将 BTC 转换成 USDT 的需求。 订单转发流程如下: ```mermaid sequenceDiagram participant U as User participant C as Chain server participant A as DEX A participant B as DEX B U ->> C: delegate N BTC to Dex B C ->> C: verify and check balance Note over C: wait 1 block C ->> B: push notiy B ->> U: delegate BTC confirmed U ->> B: place BTC sell order B ->>+ B: verify and check balance B ->> A: transmit order BTC A ->> A: verify & check agreement A ->> A: verify & check user balance & order Note over A: matching orders A ->> C: match success & submit C ->>+ C: verify and check agreement C ->>- C: hancle settle & divide fees Note over C: wait 1 block C ->> A: push notify C ->> B: push notify B ->> U: trade confirmed ``` 1. 用户将 BTC 委托给 Dex B, 2. B 接收到委托后,确认了用户可用的 BTC 金额 3. 区块确认之后,B 可以监听到委托成功事件 4. Dex B 确认了用户的委托操作 5. 用户在 B 交易所构建了一笔交易并签名,请求将 BTC 转换为 USDT 6. B 验证并检查用户的余额 7. 通过验证之后,B 构建一笔交易将这笔订单转发给 A,并附带 B 的签名 8. A 接收到请求之后先验证 B 的身份,并检查协议 9. 确认共享有效后,同步用户在 B 交易所委托的 BTC 余额,并检查订单有效性 10. 通过验证之后,订单进入买卖盘,并撮合成功,Dex A 会构建一笔链上结算的交易请求 11. 链接收到请求之后,首先验证 A 和 B 的签名,并检查共享协议 12. 确认无误,扣减了交易手续费,发起交易双方用户的资产结算,并根据共享协议所定义的比例,结算 A 与 B 的手续费 13. Dex A 监听到结算消息 14. Dex B 监听到结算消息 15. Dex B 的用户获得所需的 USDT 资产,开始下一笔交易 订单转发是现阶段流动性协议的主要实现方式,KuChain 也会根据未来的交易场景提供更多流动性共享的方式。 ### 主-子链架构 流动性共享协议能够扩大 KuChain 中流动性的使用效率,链作为结算者,支持整个网络中需要流动性的双方进行共赢合作,那么当流动性共享的协议被成百上千个交易服务商使用时,整条链的压力将会达到一个无法估量的水平,KuChain 作为一套流动性平台,需要解决链层面的性能扩展能力。 但我们并不会通过简单的区块扩容、减少验证者节点或是升级验者配置的方式来达到整个网络的灵活性和适应性,KuChain 提出了一种方案来实现网络横向扩展的适应性,我们称之为子链架构。 ### 子链 不同于常见的分片(sharding) 或侧链(side chain)方案,KuChain 中子链是链原生的一部分,与主网同步节点状态,子链通过状态同步来与主链进行“挂钩”,以此证明其状态的有效性。 主链的区块中会预留给子链,用于保存子链区块数据的哈希(Hash),而子链将主链确认之后的区块数据通过嵌入或引用的方式同步至自身的数据库内。主链通过此 Hash 可以校验子链的状态是否合法,而子链也可以直接使用主链的账务。 这样做的好处是,我们不需要通过改变共识或提升验证人服务器性能的方式来提高 KuChain 网络的吞吐量,如果 Dex 的结算需求和性能达到了一个主链无法承载的 TPS 量级,那么 Dex 将会直接采用子链去部署自己的交易服务,子链可以定义自己的共识机制,定制子链自己的验证人节点或机器配置,缓解主链结算压力的同时,也能提高子链的交易性能。 未来子链会扮演更多的角色,承载更多的业务功能,例如去中心化存储、状态验证,大数据计算等等。 ### 跨链 流动性共享和子链架构能放大 KuChain 网络内部的流动性,跨链则放大了 KuChain 向外部输出流动性的能力。 当前不论是基于以太坊智能合约的 DeFi ,还是其他中心化交易服务,都面临着流动性不足的问题,KuChain 可以将内部的流动性服务通过跨链的方式输出给其他公链网络。KuChain 将会针对不同的链采用不同的跨链技术方案,满足网络内部对跨链资产的需求,同时也为外部的交易服务提供流动性支持。 #### 同构跨链 同构跨链是指需要通信的区块链系统,采用了与 KuChain 相同的网络与共识标准协议 Tendermint,可以通过跨链通信协议与 KuChain 传递数据: 依赖 Tendermint 及时最终性的特点,用于枢纽与分区之间消息传递,IBC 协议中设计了两个消息: - IBCBlockCommitTx:包含发送方所在区块链的最新的区块信息。 - IBCPacketTx:包含跨链交易本身的信息,及其在发送方链中被打包的区块信息。 在 KuChain 网络中,两个链建立连接之前需要进行彼此注册: 1、保存两条链的验证者集合以及 Merkle 证明的算法,这样接收链才能确保消息的正确性和来源的可靠性。 2、为对方链创建两个可靠队列,一个队列存放所有对方链的消息(outgoing),一个队列存放来自对方链的消息(incoming)。 我们将跨链划分为三个阶段: 1. 用户向原链提交跨链交易请求,发送链执行这笔交易,并将交易存入 outgoing 队列。 2. relayer 从原链中的 outgoing 消息队列取出跨链交易数据,提交到目标链。 3. 目标链执行交易,放入 incoming 消息队列。 #### 异构跨链 异构跨链是指针对于与 KuChain 共识机制和技术架构不同的区块链的跨链方案,与同构跨链不同,异构跨链需要解决两条链之间的信任和资产安全问题,目前针对拥有智能合约的链(如ETH、TRX、EOS)可以通过智能合约与跨链中继来完成双方资产的跨链,针对与没有智能合约的链(如 BTC、BCH、BSV)可以通多签账户与信托节点完成。 ##### 基于智能合约和中继器 针对具有智能合约的公链链,KuChain 会利用中继器实现两条链的交互。 中继器的核心思想是把两条链上的操作互相回放,资产的转出和转入通过智能合约完成,中继器则负责监听并同步链上操作。 以下以 ETH 如何转账到 KuChain 为例 1. 在以太坊上设置跨链合约,当合约被转入 ETH 的时,会在以太坊链上铸造出新的 KETH 代币 2. 中继器接收到该笔交易,把增发的 KETH 数量中继到 KuChain 对应的合约上 3. KuChain 上的合约铸造 KETH 等量的代币,发送到目标账户 反过来的流程如下 1. 用户把 KETH 发送到 KuChain 的跨链合约中,合约销毁 KETH 代币 2. 中继器接收到该笔交易,把销毁的 KETH 数量中继到以太坊对应的合约上 3. 合约销毁掉对应数量的 KETH,并解锁相应的 ETH 还给目标用户 在此方案中,KuChain 需要依赖中继链处理 ETH 状态回滚的问题,但此问题可以通过延长中继链的确认时间来降低风险。 ##### 基于多签账户与信托节点 针对没有智能合约的链,KuChain 需要通过信托节点来实现原链资产锁定和目标链的资产映射。 KuChain 会使用多名信托节点来生成在原链的多签地址,当用户将资产转移至此账户之后,资产将会被锁定,之后信托节点将作为中继器,提交请求给 KuChain 中对应的智能合约,铸造相应的资产。 此方案也可以用来处理以太坊等其他智能合约链的跨链,只是需要付出更多的成本,具体的执行步骤与中继器的跨链流程相同,只是需要引入信托节点依赖多签账户来完成原链的资产锁定。 ### 账户模型 KuChain 为了提高链的性能和适应性,采用了基于地址并支持用户名的账户体系,与 EOS 不同的是,用户名并不是所有账户模型的基础,除了资产发行商,Dex 的运营者,验证人等需要高识别和不同权限的操作账户需要用户名之外,其余的普通用户普通地址即可满足日常的使用需求。 为节省内存,KuChain 不会维护没有余额的地址,只有发生过区块转账的用户才会被网络维护,能够查询到信息。 基于地址和账户名的模型对 Dex 来说更易于未来的扩展,也可以支持未来基于用户域名或 DID 的网络基础设施。 ## 经济模型 KuChain 的原生通证为 KuChain Score,简称「KCS」,发行总量为 2 亿,是基于 KuChain 发行的的区块链数字资产,是治理权益、网络使用权益的集合。KuChain 通过 KCS 的抵押、流通、销毁等逻辑维护 KuChain 网络的安全与可持续发展。 经济模型是维持 KuChain 网络持续发展的核心,其参与者包括验证人、发行商、交易服务提供商,普通用户等等。 ### 验证人 PoS 网络的验证数量的增加会导致网络的吞吐量变慢,KuChain 能够支持较多的节点验证人参与到分布式网络中,并保证节点进入门槛低,且网络具有较快的交易确认时间。随着摩尔定律下的硬件成本减半逻辑,我们认为节点的性能会在每四年提高一倍,那么依然维持相同的节点加入门槛,每四年升级一次区块大小,完成网络吞吐量的升级和网络节点的扩容。 网络启动之后的第一个四年,KuChain 将会有 33 位产块验证节点,每四年增加 33 名,验证人数量达到 99 位之后不再增加。网络中的区块投票或提案投票都会遵循 2/3 的票权比例,作为链上决策依据,之后网络会根据整体的验证人和硬件成本情况通过共识决定是否继续增加验证人数量。 在 KuChain 启动后,区块大小为 1M ,如果在链运行的期间内没有扩容需求,则会在四年之后例行扩容至 2M 大小,再隔四年继续升级,确保节点在硬件成本不变的情况下,提升网络吞吐量和手续费收益。 #### 验证人的奖励 当 KuChain 网络中的资产抵押率在 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 社区和生态的发展为核心目标,基金会行使的职能包括且不限于,对 KuChain 社区成员进行教育引导,引入具有交付能力的研发团队,孵化有潜力的应用项目,实施链下激励等。 ### 发行商 发行商作为资产发行的主体需要通过在 KuChain 网络中注册发行商的身份,拥有发行商身份的用户才能够使用 KuChain 网络发行 UDA,而且 UDA 的发行需要消耗一定数量的 KCS 作为手续费,注册发行商和发行资产的手续费用会转到系统的预算账户内,供用户未来的治理和提案使用。 ### 交易服务商 交易服务商作为 Dex 的拥有者,也需要在 KuChain 网络中注册,拥有交易服务商身份的用户可以在链上创建 Dex ,其 Dex 账号能够接受 Dex 的用户委托,实现资产隔离。 创建 Dex 需要抵押一定量的 KCS,来作为保证金,一旦出现 Dex 作恶或没有严格按照「价格时间序列」执行用户的交易指令,则会通过罚没 Dex 的保证金来完成处罚。 在 KuChain 中,只有用户类型是 Dex 的账号才能够使用结清算的服务,所有关于撮合交易的写入操作都需要通过 Dex 的私钥进行签名,而 Dex 需要支付链上结算的手续费用,这部分手续费用以 KCS 计价。 ### 普通用户 普通用户可以无许可的使用 KuChain 的基础功能,包括转账,锁仓,委托 Dex、抵押等操作,除去基础操作会收取少量 KCS 作为手续费之外,无需其他费用。 ## 路线图 - 2020Q2 测试网上线 - 2020Q4 主网上线 - 2022 同构与异构跨链 - 2025 子链架构实现
×
Sign in
Email
Password
Forgot password
or
By clicking below, you agree to our
terms of service
.
Sign in via Facebook
Sign in via Twitter
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
Wallet (
)
Connect another wallet
New to HackMD?
Sign up