基于SimpleChain Beta的跨链交互与持续稳态思考

1. 区块链扩展性迷局

比特币做为第一个区块链应用与运行到目前为止最被信任的公链，其扩展性问题却持续被做为焦点贯穿着整个链的发展周期。事实上，在2009年1月4日比特币出现的那一天到2010年10月1日之间，并无明确的区块上限，根据比特币区块链区块的数据结构最高可达到32M的容量。而在2010年10月1日的一个commit当中，中本聪第一次在代码中明确限定了1M的区块上限，就在10月3日，Jeff Garzik发布了将区块上限扩展到7M的补丁，成为了第一个硬分叉的尝试。固然，这个补丁并无用户使用，而彼时的平均区块数据量仅在几十k左右，中本聪也在当时说明为了保证比特币系统的安全和稳定，建议不要采用Jeff Garzik所发布的补丁。

 

随着比特币网络规模的持续扩张，链上交易变得更为活跃，区块内的数据量也逐渐增多，因而每秒7笔的交易处理速度成为瓶颈的趋势也愈加明显。

 

 

 

图表 1 比特币区块链历史大小（BitinfoCharts.com）

从2015年开始Jeff Garzik就曾再次经过BIP100提出移除1MB上限，回归最先的32MB，而此时比特币算力早已突破了1P的规模边界，利益相关方中比起通常的支付用户，更多的是矿工。然而对于矿工来讲，打包更多的交易意味着消耗更多的资源，也所以，一直以来比特币区块链区块的扩容从未真正达成共识，随之而来的是BCH、BSV等的分叉。而无限放大区块容量上限来解决交易处理速度的问题，显然只是权宜之计。

 

相似的问题，在以太坊上依然存在。虽然其区块大小并未像比特币那样以一个常数做为限制，但gaslimit做为上限的设置与矿工利益的平衡也一样对以太坊的交易处理速度造成了限制，使其秒处理速度在15笔左右。也所以在ICO盛行的2017年以及相似以太猫这样的游戏爆火的时候，整个以太坊网络都会陷入交易堆积成山的瘫痪状态。

 

在主链扩展难以破局的过程当中，一方面出现了将主链区块链数据验证和计算的责任仅交由一小组高性能节点来完成的解决方式，比特股、EoS等的DPoS机制即经过这种方式啦实现。这类解决方案经过模拟现实中的议会制选举高性能节点，而不免引发了利益集团与中心化趋势的疑议。除此以外，也有经过链下交易来解决这类问题的尝试，其中比特币的闪电网络和以太坊的雷电网络是较为典型的两个实例。

 

因为比特币UTXO的区块链模型和以太坊基于帐户余额模型的区别，在链下交易通道的具体协议设计上就有了闪电网络和雷电网络的差别。然而二者之间有着共通的基本逻辑，即经过在主链外开辟针对特定交易对象的交易通道。也就是说，特定交易对象之间经过共同锁定一笔保证金，来用于特定时间区间内的交易结算，只要双方或多方交易结果没有超出保证金的额度，或者没有超时，或者没有任何一方选择停止交易通道，双方或多方的交易就不须要向全网广播得到确认，也不须要向区块链主网支付任何手续费。这使得高频小额的交易再也不依赖于区块的大小或者区块的出块速度。

 

固然，为了实现尽量多的匹配高频交易的各类需求，闪电网络中会出现多个中转节点，用于匹配交易需求的各方。也是因为闪电网络中的交易过程要求收款环节经过签名回收，所以交易方须要实时在线，也而从这个逻辑来看，彷佛中心化的交易所最适合担任中转节点的角色。而这也让社区担心，是否最终会让高频小额交易变得日益中心化并在安全性上作出妥协。

 

固然，无论如何，闪电网络与雷电网络的设计已经将扩展性问题的解决引导向了主链以外的第二层，将不一样需求的网络和主链网络分层，成为了解决扩展性问题的一大趋势。

2. 主子链设计与分片概念

分片源于数据库设计中的概念，经过分类备份和冗余来增长总体数据库的处理效率和容错性。分布式数据库中经过创建不一样的分片机制知足业务系统的不一样要求。区块链中针对性能扩展所提出的第二层（Layer 2）解决方案也借用了这一律念，经过将不一样业务对区块链的不一样需求进行分类，并各自分布在不一样的子链当中，从而解决全链共识的性能瓶颈。

 

然而，区块链与分布式数据库中较大的区别在于，分布式数据库的增删改查以及计算来自于业务系统或者中心化的数据管理系统，分布式数据库各节点仅负责响应数据管理员（DBA）；而区块链的业务逻辑也来自于各节点即包含也业务逻辑、计算、也包含了至少帐本层面数据的管理，也就是每一个节点均可以是DBA，或者理解为根本没有DBA，所以在设计上则更为复杂。

 

因为分布式数据库的交易逻辑为中心化控制，所以其分片能够被看做是单纯的存储分片。区块链的分片则主要分为相对简单的交易分片：即仍然保持全网络节点在数据上的全同步，仅经过分片来让不一样节点运行不一样的运算逻辑；和更为困难的状态分片：即同时包含了对交易与存储的分区。狭义上来理解，最直观的状态分片其实就是各类分叉，不一样分叉链上各自处理的本身的交易、存储本身的帐本数据，验证历史区块有效性的时候能够选择一直回溯到分叉发生前的区块，经过快照来确认历史交易。但这种类型的分片因为没有后续跨片交互的机制设计，所以并无提高太多实际价值。

 

那么状态分片的跨片交易须要解决的就是如何去相互验证不一样分片内交易的有效性了。分片内部交易的有效性由分片内的节点经过共识机制确保，也所以在SimpleChain的设计当中，不一样的分片内也一样拥有着区块链的运行机制，所以跨片交易问题在SimpleChain当中就被理解为跨链交易的问题，而分片则被定义为子链。

3. 跨链交易的造成

因为跨子链交易来自于两个帐本数据不一致的区块链用户之间，所以经过构造一个不做为状态存储在帐本中的“对象”，能够实现相似于SPV（简单支付验证）的机制，即经过互相之间所同步的区块头来完成梅克尔证实，来验证这个构造出来的“对象”所传递信息的有效性。咱们能够把这个对象称为收据。

 

 

 

 

图表 2 基于收据的跨链交易确认（Ethereum wiki）

在上述图表中，表示的是一个从区块链X中的用户A向在区块链Y中的用户C发送100个单位的资产的过程。

（1） 这个过程首先经过生成一笔交易以及一个编号为154016的收据，并在区块链X的帐本中扣除A的100个单位资产来发起。

（2） 这个收据发送到区块链Y以后，经过梅克尔证实能够验证到收据所包含的信息是否正确，也就是第一笔交易是否已经在X区块链被确认，A是否已经被扣除了100个单位的资产。

（3） 得到确认后，用户C从区块链Y发送一笔包含了对收据154016的梅克尔证实的交易给到区块链X，能够把这笔交易看做回执，并增长C帐本中的100个单位资产。

（4） 区块链X收到这个回执，并将以前的收据进行销毁，同时区块链Y也在后续的区块中将收据154016进行销毁，跨链交易完成。固然区块链X与Y也能够保留回执，用于验证后续跨链交易的持续性。

 

为了确保上面这个机制的持续有效，咱们还须要考虑跨链交易中的终局性问题，或者叫作分叉选择机制。区块链Y所验证的区块链X交易必须来自于区块链X有效链的块中的交易，而不是来源于一个孤块或者孤链。Vlad Zamfir提出过一个合并块的设计，也就是两条链在须要发起跨链交易时，两个在不一样链上的块合并为同一个区块，各自的链都基于这个合并块去延长以后的块数据。但实际上合并块意味着两条链的帐本同步，所以咱们认为并不能解决两个分片或者两个链之间的相互独立性问题。可是跨链交易中，如何寻找正确的对方链的块去完成收据的梅克尔证实，是能够从Vlad的思路中找到答案的。

 

Vlad将两条须要实现跨链的链进行等级排序，分为“父链”和“子链”，“子链”须要在与“父链”高度相同，或高于“父链”高度所产生的区块与“父链”进行区块合并，或者在咱们的场景中是在“父链”上进行区块跨链验证。这样可以确保两个链在各自延长的过程当中，跨链部分数据可以持续保持一致。

 

 

 

图表 3 合并块机制（Vlad Zamfir）

可是，在上述的解决方案中存在须要两个区块链同步出块的前提，由于若是“父链”X的交易迟迟不能确认，或者没有延长，或者“子链”Y没有及时收到X的延长状况，亦或者“子链”与“父链”存在间断性同步，则“子链”Y的后续交易有效性也都会受到相应的影响。

 

 

 

图表 4 非同步跨链（跨片）交易在分叉时的状况（Alexander Skidanov）

从上图中能够看出，两个分片或者链各自存在分叉的状况下，若是分片1中的A-B以及分片2中的V’-X’-Y’-Z’各自被确认为主链，则跨链或跨片交易没有问题，亦或A’-B’-C’-D’和V-X成为了主链，则跨片交易就失效。但假设是另外两种状况，则存在了原子性故障，也就是在一个分片中交易有效而在另外一个分片中交易无效。因为两个分片或者链的异步性，致使在发起跨链交易时并不能肯定两个链内部各自的主链肯定状况，所以这种问题就会产生。因而分片或者子链之间的跨链交易就须要一个中间共识机制来进行协调。

 

在以太坊2.0的设计中，信标链被赋予了这个职能。信标链能够被认为是以太坊2.0设计中全部分片链的主链，这条主链经过Casper共识机制来选举并在每一轮中随机产生分片验证者，用于协调分片之间的交易正确性。可是在属于PoS的Casper共识机制中，因为没有了难度要求、nonce、块哈希这些本来在PoW中可以执行无状态SPV证实的工具，所以要验证分片链的有效性须要回溯到可信区块，再从新计算可信区块后的区块状态一致到当前区块，才能完成验证。致使了验证者增长了工做量。所以在SimpleChain当中，为了减小验证者的工做量，相似信标链的角色则经过PoW的主链来完成。

主链当中存在锚定矿工的角色，所谓锚定矿工承担三个功能角色，1. 负责在某子链发起跨链交易时验证该子链状态的有效性；2. 负责在主链中写入子链交易并广播得到确认；3. 将意在主链确认的跨链交易结果分别写入交易发起子链与交易接收子链的区块中。

 

锚定矿工在验证、广播、和传递跨链交易时，既做为子链矿工也做为主链矿工存在。然而在主链上的矿工数量会比子链中的矿工数量多，所以在子链中伪造交易传递到主链的成本将大大低于在主链伪造交易写入子链。所以须要一种更为合理的锚定矿工选举机制。

 

 

 

图表 5 子链中做恶矿工的几率将会高于主链（Alexander Skidanov）

锚定矿工不针对于某个子链长期存在，但须要长时间做为主链矿工存在。因为PoW的主链可以容许无状态SPV证实，所以咱们在SimpleChain中将锚定矿工的选举经过随机的形式来完成。

 

一次跨链交易验证的锚定矿工数量上限=Min[（全网矿工数/子链数量）*3,全网矿工数]

 

因为锚定矿工来自于PoW主链矿工，所以经过从小到大排列主链矿工所计算出的工做量证实计算结果，进行锚定矿工筛选。因为数值越小的工做量证实计算结果得到的几率越低，所以在锚定矿工预选列表中的排名越高，超出该次锚定矿工数量上限排名的矿工则在当前轮的交易验证中不参与签。锚定矿工选举过程的PoW排序与主链延长的PoW同步进行，即主链矿工不只将使用工做量证实计算结果得到主链SIPC奖励，还将得到锚定矿工奖励。锚定矿工奖励来自于子链跨链交易发起者所支付的SIPC矿工手续费。

 

在保证主子链的一致性问题上，咱们采用了n个确认的机制。当发起一笔跨链交易时，子链内的区块应首先得到n个块高的确认，才可以经过锚定矿工的验证并广播至主链上。通过主链n各块高的确认后，才分别将确认后的交易状态写入跨链交易所涉及的两个子链当中。

 

n的大小与跨链交易的金额、数据量成正比，也就是价值越高的交易所须要的在子链和主链中的确认数要求越高。目前设计中，主链确认数n沿袭了比特币的常数设定思路，因为主链平均出块时间12秒，所以主链的n值设定为15时其安全性将会接近于比特币6个确认的时间。而子链确认数则以主链15个确认的基础，基于跨链交易的金额、数据量进行动态调整。

 

4. 主子链结构持续稳态的经济设计

 

 

图表 6 SIPC模型 （Simplechain Foundation）

SimpleChain在白皮书1.0中提出了主链数字资源SIPC的微通胀机制，即随着子链的增长、子链活跃度的增长以及对跨链交易需求的增长，SIPC的区块奖励会在本来的衰减曲线基础上产生微调（上图中从绿色虚线变为黑色实线）。这种微调的结果就是当主链SIPC被做为一种资源，子链对其的需求量增长的时候，主链出块奖励将相应增长，以当前状态为例，主链出块奖励将可能从20SIPC增长到21SIPC。

 

这一设计的目的在于让子链与主链上的角色之间的关系更为稳固。子链对主链的需求在于经过主链协调跨链交易，一笔跨链交易的过程为：

 

（1） 子链用户发起跨链交易并支付手续费，手续费包含子链Token（T）与主链SIPC（S）；

（2） 子链矿工或验证节点完成共识验证并收取部分子链Token（t1）做为手续费；

（3） 被选举出来的跨链矿工收取剩余部分子链Token（t2）以及手续费中的所有主链SIPC（S）以及运营池中的部分SIPC（s2）做为手续费完成跨链锚定与广播；

（4） 通常主链矿工收取主链交易手续费SIPC（S’）打包跨链交易；

（5） 另外一条子链锚定矿工读取主链中的跨链交易，广播至目标子链中。

以上过程当中T=t1+t2，然而通常主链矿工收取的主链交易手续费S’=R+k，R为原始主链出块奖励，即当前的20SIPC，k则为微通胀调节奖励。

 

上面出现了运营池的概念，所谓运营池便是在子链初期建立时，建立节点经过抵押SIPC的形式向子链注入的启动资源，运营池中的SIPC将在跨链交易中做为部分奖励s，输出给锚定矿工。

 

假设一个资料的启动运营池容量是10SIPC，在跨链过程当中，每次会分出其中的0.1SIPC给到跨链矿工做为跨链矿工的部分奖励，一次交易事后运营池容量减小为9.9SIPC。此时，通常主链矿工收取到的交易手续费S’=20+0.01，这0.01就是微通胀调节奖励。

 

运营池能够由任何SimpleChain用户选择再次注入SIPC，也可由子链共识触发活跃度下限，更改跨链矿工奖励来使得跨链矿工得到的s2为负，即部分跨链手续费被存入子链运营池。此时，通常主链矿工收取的手续费中的微通胀调节奖励k将为0或转向负数。这种状况下代表子链走向衰退期，或子链与主链将逐渐经过减小互相激励而脱离关系。

 

5. 潜在风险与后期讨论

上述模型中可能存在的技术风险包括主链区块当中对于包含跨链交易的交易量上限问题，以及过多锚定矿工形成的主链负担太重的问题。

 

经济模型方面，存在“损人不利己”攻击的可能，即经过建立衰减子链，影响主链矿工与用户利益的状况。

 

6. References

[1]. BitInforCharts (2019) Bitcoin Block Size historical chart, Available from: https://bitinfocharts.com/comparison/bitcoin-size.html [Accessed on 02/04/2019]

 

[2]. Buterin. V(2015) On Slow and Fast Block Times, Available from: https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/ [Accessed on 04/04/2019]

 

[3]. Buterin. V(2019) Merge blocks and synchronous cross-shard state execution, Available from: https://ethresear.ch/t/merge-blocks-and-synchronous-cross-shard-state-execution/1240 [Accessed on 03/04/2019]

 

[4]. Buterin. V(2019) How can we facilitate cross-shard communication?, Available from: https://github.com/ethereum/wiki/wiki/Sharding-FAQ#what-is-the-train-and-hotel-problem [Accessed on 03/04/2019]

 

[5]. Prestwich. J(2019) What to expect when eths expecting, Chinese Version Translated by EthFans, Available from https://ethfans.org/posts/what-to-expect-when-eths-expecting [Accessed on 02/04/2019]

 

[6]. Skidanov. A(2019) The authoritative guide to blockchain sharding part 1, Chinese Version Translated by EthFans, Available from: https://ethfans.org/posts/the-authoritative-guide-to-blockchain-sharding-part-1 [Accessed on 02/04/2019]

 

[7]. Skidanov. A(2019) The authoritative guide to blockchain sharding part 2: Unsolved problems in blockchain sharding, Chinese Version Translated by EthFans,https://ethfans.org/posts/unsolved-problems-in-blockchain-sharding [Accessed on 02/04/2019]

 

[8]. Zamir. V(2018) Casper, Ethereum Community Conference on March 8-10,2018, Available from: https://www.youtube.com/watch?v=GNGbd_RbrzE[Accessed on 03/04/2019]