无缝衔接异构链资产互换的跨链平台

目录

1. 跨链 DeFi ...................................................................................................................... 3

2. Khipu 的目标 ............................................................................................................... 4

2.1 Khipu 的基础设施包含两个部分： ........................................................................ 4

2.2 关于 Khipu Swap Protocol 协议的必要性 ......................................................... 4

3. Khipu Swap 跨链技术实现.......................................................................................... 5

4. Khipu Token(Kip)的经济模型 .................................................................................... 6

5. 优化以太坊节点能力以支持跨链 ................................................................................... 7

5.1 以太坊单节点性能计算 .......................................................................................... 8

5.2 以太坊性能的极限优化 ......................................................................................... 11

5.2.1 智能合约并行 ............................................................................................ 12

5.2.2 储存优化 ................................................................................................... 14

6. 以太坊 2.0 的分片架构 ............................................................................................... 21

6.1 以太坊 2.0 的分片设计 ......................................................................................... 21

6.2 分布式分片架构 ................................................................................................... 22

6.2.1 状态的一致性 ............................................................................................. 23

6.2.2 每个分片的共识 ......................................................................................... 23

6.2.3 典型分布式系统的分片设计 ...................................................................... 24

7. 团队 ............................................................................................................................. 26

1. 跨链 DeFi

DeFi 是目前最为流行的 DAPP，但早在 BTS 时期 DeFi 这个概念已被认为是非

常有前景的一个赛道，当时由于技术的基础设施不成熟，早期 DeFi 的产品方向

过于模仿中心化的 Finance 产品，并没有将区块链的优势发挥出来，导致很长一

段时间 DeFi 并未找到杀手级的应用场景，直到 AMM 的出现。

Bacor 是最早流行的 AMM 协议，但当时 ordbook 的模式对 TPS 的要求比较

高，所以 EOS DEX 的去中心化交易所先火了起来。而现在由于非 orderbook 的

模式令链上撮合对 TPS 的要求大大减少，导致 DEX 的主战场从 EOS 转移到了

ETH 上，只是因为 ETH 生态的代币种类繁多，市值最高。然而 Defi 发展到现在

的最大瓶颈也正是以太坊本身生态的局限性，整个加密货币市场市值最大的货币

并未能参与进来。

比特币相对于以太坊系的区块链，是一个完全异构的平台。目前的跨链实现，都

需要一方从外部注入另一方的交易证明。

目前解决 BTC 跨链的方式是使用 WBTC 等锚定货币，但锚定币偏离了中心化的

初衷，从安全和信任的角度来看也不容易令用户接受，成交体验也变得更差。即

便是 ETH 本身也非 ERC20 的 token，也就是说以太坊要参与 Defi 还需要通过

WETH 的方式（0x 协议的 DEX 开始都使用这个方式）。想要 Defi 生态的进一步

发展，就必须要有真正的通过节点共识为支撑的跨链。

2. Khipu 的目标

2.1 Khipu 的基础设施包含两个部分：

优化后的以太坊节点及 solidity 编写的 BTC 及其他主链的全节点以支持跨

链。

在优化后的节点上支持非锚定币的跨链结算的协议 Khipu Swap Protocol

（KSP）

基于 Khipu 的各类 DeFi 应用则会交由社区开发者完成

2.2 关于 Khipu Swap Protocol 协议的必要性

与异构数字资产的互换，需要保证，两笔双向的交易要么同时完成，要么同时失

败。通常这类交易都要经过一个中间见证账户，如果在要求的时间内都完成成交，

则互换顺利完成；否则，将由中间见证账户回滚交易。

实现中间见证交易并不难。难的是对于异构的比如比特币，中间见证账户是无法

自己确认参与互换的比特币交易是否成功，即需要从外面注入比特币链上的成交

证明。

Khipu Swap，除了完成类似 IDEX、uniswap 的功能，还能实现跟比特币等异

构数字资产跨链交易。其原理是在扩展了以太坊的 Khipu 上面，完全用合约本

身（代码）来实现一个比特币节点。这样的 DEX 在跟比特币等跨链互换时就是

无需中介代理，自动按互换合约完成和可以完全信任的。

Khipu Swap 是直接在合约上实现了比特币节点，因此，比特币的成交记

录会由合约自己验证并保存在 Khipu 本身的状态中，可以在互换合约中直

接查询，无需外部注入。

3. Khipu Swap 跨链技术实现

Khipu Swap = 以太坊主链节点 + 扩展功能及合约 + 扩展功能及合约上实现

的 BTC。

“标准以太坊节点” 和 “标准比特币节点” 都将作为运行在 Khipu Swap

上的节点，成为 节点中的节点。 作为企业级的区块链平台，Khipu 对以太坊做

了适当的扩展，其中最重要的是其网络 IO 能力。

具备网络 IO 能力后，Khipu 就能通过编写合约、或者说直接在 EVM 虚拟机

上实现一套完整的比特币节点。如此一来，对比特币交易的验证是通过 Khipu

合约的运行来验证的，而比特币交易的数据也作为了 Khipu 的状态保存在可验

证的 storage 中。

因此，运行在 Khipu EVM 虚拟机上的比特币节点，就具备了以下独一无二的

特点：

它的交易本身是比特币共识的

它是基于 Khipu 合约，运行在 Khipu EVM 虚拟机上，也因此是 Khipu 共识

的

同时，Khipu Swap 本身也是以太坊兼容的。也是运行在 Khipu EVM 虚拟机

上的以太坊节点，也具备以下特点：

它的交易本身是以太坊共识的

它经由 khipu 验证，运行在 Khipu EVM 虚拟机上，也因此是 Khipu 共识的

那么，我们也就有了一个无缝衔接了以太坊和比特币的平台，无需从外部注入比

特币或者以太坊交易证明的 DEX 平台，实现了跨链操作。

4. Khipu Token(Kip)的经济模型

Khipu Swap Protocol 是一个支持原生跨链合约的客户端协议，它的第一个落

地应用是支持 BTC 通过 非 WBTC 的形式和 ERC20 资产进行跨链互通，包括但

不限于资产置换，质押等， 它的可靠性基于链本身的共识，并且跨链清算是保

证最终一致性的，也就是一旦合约未执行完清算，token 是会原路退回的。

KSP 内置的 token（Kip）的主要应用价值为非 ERC20 资产在赎回过程中，

Taker 需要支付手续费给提供 erc20 以外资产的 Maker（流动性提供者），同时

Maker 在获取大部分手续费的同时，也会获取一定量的 Kip。而 Khipu Swap 节

点也会获得差额手续费收益，用于对 Kip 的回购。

整个流程结构如图 1 所示：

5. 优化以太坊节点能力以支持跨链

由于以太坊的侧链和主链共享资源，侧链和跨链都会导致拥堵，所以为了实现更

好的跨链，以太坊单节点性能也需要做到极限的开发。

5.1 以太坊单节点性能计算

以太坊的单链性能主要由以下三个因素决定：

o 网络广播时延

o 共识达成时间

o 单节点执行和验证合约时间

在平均约 15 秒的出块时间中，以上三个因素的时间所占比例大约为多少呢？

根据多项研究，现有的互联网环境下，0.1M 大小的区块网络广播时延大约可以

取值为 1 到 3 秒。区块大小每增加一倍，时延相应增加 25%~50%。以太坊

目前区块大小为 33k 以内，在考虑到网络技术的进步，设定为 1 到 3 秒甚至

更短的时延是合理的，我们可以取 2 秒来做理论上的各种估算。

共识达成的时间可以通过动态增加或减少工作量证明难度系数来调整。但在

PoW 共识机制下，这个时间所占的比例也不能太低，否则 PoW 的可靠性和公

平性就会被网络传输时间和区块执行时间所削弱。

下图是以太坊主网在 2017 年 9 月到 2018 年 7 月的难度系数曲线。可以明

显看到在加密猫热期间，矿工用于执行区块的时间大幅增长，只能动态调整下调

难度系数来保证出块时间。

图 2. 以太坊难度系数曲线 - 2017 年 9 月到 2018 年 7 月

以太坊的每笔交易不是简单的账户资产的转移（增加或减少），而是可以通过智

能合约来处理复杂的逻辑。这些复杂的逻辑会调用不同的指令，或读取存储的状

态,或运行某种复杂的计算（比如 SHA）等。这些不同的指令需要消耗的计算资

源是不同的。

以太坊虚拟机很好地引入了 gas 度量，用来度量每种指令所消耗的资源。在典

型配置的节点上，理想的 gas 度量设计应该做到：每笔交易需要消耗的 gas 量

与其执行时间逼近线性关系，这样可以保证在可预测的时间内能够验证完毕。同

时调整每个区块的 gas 上限，就可以调整每个区块内所能消耗的计算资源总量

或者说交易数。

区块链通常使用最简单的一笔转账交易来对每秒交易数 TPS 做理论估算。以太

坊目前的区块 gas 上限是

800 万 gas，而一笔简单的转账，消耗的 gas 量是 2.1 万，因此，每个区块

内最大交易数为 800 / 2.1 = 381 笔。以 15 秒的出块时间计，每秒最大交易

数 TPS 为 381 / 15 = 25。

因此，在目前的以太坊架构上，要增加 TPS ，就需要提高区块的 gas 上限。这

涉及到网络中的大部分节点，尤其是挖矿节点，其用于区块验证的时间占到 15

秒出块时间的比例。如果这个时间太长，新出的块被网络其它节点验证后转发（广

播）的延误就越长，链上出现叔块的比例就越大，要达到区块的不可逆决定性所

需的代价就越高。因此，我们不妨先假定这个区块执行的时间占出块时间的比例

应该控制在五分之一以内，也就是 3 秒。根据以上假设，我们得到一张以太坊

单链可能达到的 TPS 上限（表 1）

表 1. 不同计算能力（mgas/s）及执行时间比例下以太坊的 TPS 上限

TPS= ( 100 × mgas ÷ 2.1 × duration ) ÷ 15

表 1 还列出了两种极端的情况：

一种是采用类 DPoS 共识机制后，共识达成的时间接近零，只需要留出网络

广播时间的场景。假设这时区块执行时间可以放宽到占出块时间的 80%（15

秒中的 12 秒 —— 留 3 秒给网络广播）。这种场景恰恰类似目前 EOS

的实现（蓝色）

一种是区块执行时间即是出块时间。这种场景实际上就是目前企业应用里完

全中心化的场景（绿色）

由此可见，以太坊要达到更高的 TPS，比如从现在的 25 提升到 100 这个量级，

单节点上每秒执 行 gas 的能力要达到 10 mgas 以上，而要达到 1,000 量级，

需要达到每秒 120 mgas。

那么，究竟以太坊在单节点上执行区块的极限在哪里？瓶颈又在哪里呢？接下里

就让 Khipu 回答上述问题。

5.2 以太坊性能的极限优化

前面提到，以太坊对于企业应用来说，当前的主要瓶颈是 TPS。TPS 的提升，

一个方案是分片，比如以目前的处理能力（TPS 理论值 25 左右），100 条分片

链就可能达到 2,500 TPS，代价是原来比如能有 5 万个节点背书一条链，现在

变成每条链只有 1/100 ，也即 500 个节点，TPS 上去了，但安全和可信度下

降。所以提升单链的 TPS （也即单节点的 TPS）总是最关键的，比如提升到

1,000 TPS，那么 10 条分片链就可能达到 10,000 TPS，这时每条链仍然保证

5,000 个节点背书。

可以预见，在三五年内，磁盘 IO 的性能，可以依靠 SSD 等技术得到提升；网

络带宽，也会不断提升；而 CPU 时钟频率的提升已经到了一个瓶颈，需要靠单

机的 CPU 核数来提升计算能力，但如果只能单线程串行执行交易，那么 CPU

这个瓶颈就无法突破。因此，并行执行交易的能力就尤为关键。

5.2.1 智能合约并行

区块内合约并行执行的难度在于我们并不预先知道合约彼此之间的依赖关系。以

太坊合约可能存在并发竞态（Race Condition）的地方有三处：

对同一地址的 Account 的存取

对同一地址的 Storage 的存取

对同一地址的 Evm Code 的存取

假如让用户在编写合约时识别和标明会发生竞态冲突的地址范围，从以上三种可

能出现的竞态来看，让用户识别和标明并保证不出错且无遗漏显然是不现实的。

竞态究竟是否会出现、在何处出现、在什么条件分叉下会出现，只有当确定性地

获得涉及的当前状态后才可能作出判断。这种判断，以目前的合约编程语言，也

几乎不可能通过对代码的静态分析来获得完全正确且无遗漏的结果。

但这并不意味这区块内合约的并行执行一定不可能做到。有意思的是这个问题以

太坊提出来好几年了，但并没有人真正去尝试一下。其实，目前这个问题更是个

工程问题而非理论或设计，但在工程实施过程中能摸索到设计中存在的问题，从

而接下来提出更好的设计。

Khipu 首先在这方面作出了较全面的尝试，并完成了工程实现。

Khipu 的实现方案是每条交易都从前一期区块的世界状态开始，分别并行执行，

在执行过程中记下所有理想经历路径上遇到的以上三种竞态。在并行阶段结束后，

转入合并阶段。合并阶段开始逐条合并并行的世界状态，每合并一条交易时，先

从记录下来的竞态条件中判断是否与前面已经合并的竞态条件有冲突，如果没有，

直接合并；如果有，则将这条交易以前面已经合并的世界状态为起点再执行一次。

最后合并的世界状态，将用区块的哈希做最后的校验，这是最后一道防线，如果

校验有误，则放弃前面的并行方案，将区块内的交易重新按串行执行。

Khipu 在这里引入了一个并行度指标，即某一区块内能够不需要再次执行就可以

直接合并结果的交易的比例。从 Khipu 实际测试的结果看，这个比例（并行度）

平均可达 80%。

总体而言，如果计算任务可以被完全的并行化，单链的可扩展性就会是无限的：

你总是可以往每一个节点里添加更多的 CPU 核心数量。若事实不是这样，则最

大的理论速率就受限于安达尔定理（Amdahl’s law）：你能给系统进行提速的

极限取决于那些不能进行并行化的部分的倒数。如果你可以进行 99% 的并行化，

那么你就可以提速到 100 倍；但如果你只能实现 95% 的并行化，那么你就只

能提速到 20 倍。

在以太坊的例子中,若有 80% 的并行化，则有 20% 是不能并行化的，那么 20%

的倒数即 5，所以可提速的极限是 5 倍。

特别地，对于区块生产者，因为可以布置在高性能机器上，如果其能主动识别交

易间并发竞态，并按照最好的策略安排这些交易，则可能大大提高并行度，从而

获得更高的提速。这也正是 EOSIO Dawn 3.0 后决定采用的方案：

Automatic Scope Detection 4

Under EOSIO Dawn 2.0, every transaction was required to declare which

data ranges it would access. This was error prone and verbose for

developers. Under Dawn 3.0, the block producers are responsible for

determining which data ranges are accessed and to decon ict them. This

makes all transactions smaller and moves the scheduling overhead to the

block producer rather than pushing it back on the user, developer, or full

nodes.

5.2.2 储存优化

以太坊在单节点性能上还存在一个严重的瓶颈，那就是单机在有上亿级 trie

node 时的存取效率。这个瓶颈也是以太坊在 2016 年遭受 DDos 攻击的目标。

攻 击 者 利 用 当 时 以 太 坊 与 读 取 存 储 相 关 的 一 些 指 令 的 gas 偏 低

（ EXTCODESIZE 、 EXTCODECOPY 、 BALANCE 、 SLOAD 、 CALL 、

DELEGATECALL,、CALLCODE、SELFDESTRUCT 等）而反复创建空帐号，导致

以太坊全网的节点频繁地做 disk IO 操作，性能急剧下降。后来虽然通过提高

相关指令的 gas 而使得攻击最终停止，但以太坊其时在 trie node 增加到数千

万到上亿后的读取瓶颈暴露无疑。

此后，虽然主要的以太坊实现，Geth 和 Parity 等都在 kv 存储引擎上做了大

量优化，但随着 trie node 数量的持续增加，在传统的机械硬盘上，几乎都已

经失去了运行全节点的能力。

以太坊一个区块目前大约需要执行的随机读为 4,000 次左右。我们可以估算一

下不同的硬盘 IOPS，不同的缓存命中率 CacheHitRate，在最理想的情况下（一

次冷数据读只需一次磁盘 IO）完成一个区块的数据读写需要的时间。

先设定几组硬盘的 IOPS 指标：

HDD 随机读的 IOPS 设为 100

SATA SSD 随机读的 IOPS 设为 1500

NVMe SSD 随机读的 IOPS 设为 15000

理想的情况下（一次冷数据读只需一次磁盘 IO）完成一个区块的数据读需要的

时间见下表。

表 2. 理想情况下一个区块的数据读需要的时间

4000 ×(1－CacheHitRate)÷IOPS

可见，目前以太坊的区块，HDD 的节点要跟上主网（15 秒的出块时间），需要

满足以下条件，否则理论上不可能：

极好的缓存算法，缓存命中率 70% 以上

极好的存储引擎，冷数据最多一次 disk IO

Geth、Parity 等几乎所有的以太坊实现，都使用 LevelDB 或者其后续优化版本

RocksDB 来存储包括 trie nodes 的 kv 数据。LevelDB、RocksDB 都是采用

LSM 算法实现的高效 kv 数据库，它可以将随机写转化为顺序写以很大程度上

提高写的性能，但这种算法却无法解决随机读的问题。尤其在机械硬盘上，随机

读完全无解，只能靠缓存，或者，相比增加内存来加大缓存，使用 SSD 硬盘成

本更低。另外， LSM 在存储大 value 的数据时，其写入能力跟 BTree 的存储

引擎相比开始变得不突出，还有一个问题时其写入速度很不平整，会周期性地因

压缩过程而抽风。

但对于以太坊而言，有一个很独特的问题，就是 trie nodes 数据，只要 value

变了，key 就跟着变，因为 key 不是别的，它正是 value 的 hash。因此，比

如即使是同一账户，它的 key 也是跟随 value 变化的。而针对 key 来缓存的

kv，只有在 value 保持相当长一段时间不变时才有意义，否则热数据基本无效。

这样的数据特性决定了很难构造出合适的缓存算法，或者说，一个最简单的

FIFO 缓存策略反倒可能是最有效的。

以太坊，以及很多区块链 kv 数据，key 都随 value 变。这种 kv 数据实际上

对直接从硬盘上随机读提出了很高的要求。即使加大内存缓存了相当一部分数据，

但如果从硬盘上随机读取冷数据的能力不能达到近似于 O(1)，那么随着数据量

单向递增，你将无法保证任何一笔交易的完成时间，或者说，只要一笔交易的数

百次查询中有那么几次非常慢，这笔交易的处理就会被极大地拖慢。

以太坊链上至少有三种数据类型：

Account nodes，storage nodes，Evm-code nodes 是以 Trie 的形式组

织的世界状态 world state (WS)。每一区块有一个世界状态的在该区块时

刻的快照。每一区块的只跟前一区块的 WS 有关。不同的区块的快照，有冗

余的 nodes（同一没变的），这些数据可以做 compaction，也即只保留前

面某时刻的快照及后续增量，而不影响后续区块的校验。

Block-header, block-body, receipts 。 这 三 项 加 上 1. 的

account/storage/code nodes，都是执行区块验证需要用到的数据，但这

三项跟区块时间是一一对应的，不会有重复冗余，不需要做 compaction，

而且这三项是区块执行和验证始终可能用到的。

Transactions 的 Location 。数量庞大（每个区块可以包含多达 300 个），

只用于查询。

特别地，对于第一类数据，计算和校验当前区块必须用到整个世界的状态（trie

nodes），也即从创世区块演变到当前，所有实体的当前状态，需要全部的这些

实体在 trie 中的位置和值。尽管计算当前区块只涉及其中的片段，但你无法预

知会涉及到哪些片段。也即，你必须存储所有的未删 trie nodes，才能完成当前

区块的计算和校验。这就带来一个实现上的难题（矛盾）：一方面，为了安全、

不可假冒、不能篡改，以太坊希望每一个全节点都参与验证；而另一方面这些全

节点必须拥有整个世界的当前状态。目前（在 800 多万号区块），这些 trie

nodes 的总数已经超过 3.5 亿，占据的磁盘空间 70G 以上。而计算一个区块，

大约会增加数千个新的树节点，同时有数千个树节点变成无用的，净增 90 个左

右。

另外，以太坊的状态数据是以事件流存储的。随着时间的流逝，状态以清掉或者

转变为另一个的形式不断被记录。一个有趣的地方是，假设希望以 “快照+后续

事件” 的方式来抵达任一时点的状态，你并不需要特别地去在某个时点执行一

下快照，因为该时点区块的 stateroot 会指引你串起该时点的状态快照。

如果不是 archive full node，对状态树的剪枝有两种方式，一是将最新树上找

不到的节点一个个删除（in place delete），一是沿着 stateRoot 将最新树上能

找到的节点重新追加到一个新表（append to a new table）。随着区块的不断

增加，两种方式的工作量会逐渐趋同，前者甚至会超过后者。因此，在经过适当

的区块后，追加到一个新表的方式应该是值得的。

那么，有没有一种设计能在保持 LevelDB/RocksDB 极强的写入能力的同时，

也能尽量做到接近 O(1) 的随机读呢？Khipu 在仔细分析了区块链数据的特点

后，专门开发了一个适合区块链 kv 数据的存储引擎 Kesque。

首先，区块链的 kv 对中，key 通常是 256bits 的 Hash，把一个如此大的 key

全部加载到内存无疑会占用巨大的空间。但 key 既然已经是 Hash，那么如果

我们只去 key 的后 4 个 bytes（相当于一种有效压缩）来代表 key，发生冲突

碰撞的概率应该会很低。实际测试的结果也表明，对于上亿规模的以太坊 kv 记

录，发生冲突碰撞的概率只有千分之几。也就是说，如果我们把 key 的后四位

bytes 以及该条记录在硬盘文件上的 offset（四位 bytes 代表）作为索引加载

到内存中，那么在 99.x% 的情况下，给定一个 key，最多只要一次磁盘 IO 就

可以加载到该条记录。

这个索引所占的内存空间大约为每条记录：4 bytes + 4 bytes = 8 bytes，每

1G 内存大约可以容纳 1.34 亿条记录。按照这个思路，Khipu 开发和实现了

Kesque 存储引擎，其设计要点为：

把 Kafka 的 log 文件作为 Hash 表的 KV entilies 的载体

设计一个 Int-int 的 map 保存没有冲突的 Key - Offset

设计一个 Int - Ints 的 map 保存于冲突的 Key - Offset

查找时现在 Int - Int map 找：

如果找到，则直接定位到了记录在 log 文件的 offset，一次磁盘 IO 便可取出

记录，复杂度为 O(1)。这是 99.x% 的情况。

如果没找到，则从 int -> ints map 中找到 n 个 offsets，对每个 offset 从硬

盘读取记录并比较完整的 key，相同的那条记录就是所要寻找的。这里 n 值在

大部分情况为 2,越大的概率越低，虽然不再是一次（两次或多点）磁盘 IO，但

复杂度仍然近似 O(1)

这个新设计的存储引擎，在处理上亿以太坊典型数据时，随机读的能力比

LevelDB 高出一个数量级。

6. 以太坊 2.0 的分片架构

为了实现更好的 DeFi 跨链，以太坊 2.0 提出了分片的概念设计。分片是企业

应用分布式扩展性的关键。以太坊的分片设计，是由多个平行世界组成的多链

组成，每条链对应一个单独的世界或者叫分片，分片上承载了不相重复的主要

数据，称为数据层 Data Layer。而分片之间的数据交换则由协调层

Coordination Layer 来协调。

6.1 以太坊 2.0 的分片设计

为了解决可扩展性问题，以太坊 2.0 的分片引入了链上状态分区（on-chain

state partition）的概念来获得更高的吞吐量。以太坊 2.0 将以太网络分为两层，

上层为现有的以太坊主链，基本保持不变；下层为分片链，主要用于分片运算。

可以简单地这么认为，分片中的交易都会被装入 “ 校对快 ”（collation）。 与

侧链类似，校对器（collator）只有一小部分会被记录到主链。

分片链上的交易处于自己独立的空间中，分片验证人（shard validator）只

需要验证他们所关注的分片

分片链通过 POS 机制依附于主链，以获得更高层次的共识（higher level

of consensus）

具体过程就是分片中包含多个节点，即分片验证人，他们可以通过 POS 机制在

分片中完成交易的验证，验证之后产生一个校对块，而这个校对块的一头部信息

被加入到主链上面，具体的交易并不保存在主链上面。

一方面，以太坊 2.0 通过引入独立分片，赋予了整个网络的并行处理能力，提

升了整个系统的吞吐量；另一方面，每个分片只保存一部分的历史状态数据，主

链不需要保存具体的交易信息，可以大大降低节点的存储压力。

6.2 分布式分片架构

图 3. 以太坊 2.0 分片概念设计

6.2.1 状态的一致性

来源：zhihu@alabs block chain research

6.2.2 每个分片的共识

概括来说，在 PoW 世界里，高昂的算力成本付出，让矿工自觉地向最长链收敛，

那么在去算力的世界（PoS）里，如何让产块者遵循统一的最长链选择策略？我

们需要制定规则，以太坊 2.0 采用 PoS + BFT 类共识，对相关的规则（casper）

达成最终共识，解决这些致命的问题，而 BFT 类共识有需要 N^2 的通信代价，

节点扩展性受到制约，这也是为什么分片（每个片区节点数有限）被选择作为以

太坊 2.0 的扩容方案。

6.2.3 典型分布式系统的分片设计

以太坊的分片设计是典型的分布式系统的分片方式，如果与流行到分布式系统

Akka 相比，我们可以看到，它的每条分链（平行世界）对应了 Akka 分片集群

里的分片节点，而协调层则是整个宇宙的一个单例，在以太坊体现为一条单链，

在 Akka 分片集群里则是一个集群的单例实例。

图 4. 典型分布式分片集群 - Akka 分布式分片集群的设计

Akka 已经有非常多成功的企业应用案例。与此相通的以太坊分片设计，使得

我们可以顺利地将企业应用也分布到分片链上。但是，我们需要将以太坊 2.0

设计中 Beacon Chain 存储的状态 Markle trie （比如 receipt）扩展到一般

的企业领域实体。

7. 团队

邓草原---Khipu 创始人兼团队领袖

1985-1990 清华大学工学硕士

2000-2001 TOM（中国）投资有限公司CTO

2011-2013 方正证券股份有限公司金融工程部首席专家

2013-2015 豌豆荚平台架构师

2016-2018 轻芒平台架构师

2005 年至今AIOTrade 开源股票软件（Scala/Akka），项目创建人

2008 年至今Sun/Oracle NetBeans IDE 之Scala、Erlang 语言开发平台，项

目创建人

2010-2013 分布式并行实时金融计算及投顾集群

2013 年分布式实时数据分析平台

2014 年开源分布式Websocket 及SocketIO 百万级长连接集群(Scala/Akka)

2015 年分布式实时内容服务平台(Scala/Akka)

2016 年高性能分布式并行网络爬虫(Scala/Akka)

2015 年至今Chana 开源分布式实时缓存及服务平台(Scala/Akka)

2017 年至今ChanaMQ 开源AMQP 分布式实时消息平台

2018 年至今Ethereum 客户端Khipu（Scala/Akka）

2018 年 NetBeans 全球开发大赛金奖 2008 年至今 NetBeans 梦之队成员