区块链：多链体系在提升性能的同时，怎么去保证单链被攻击性问题

一、BUMO Orbits

在现在的区块链项目中，节点的存储和处理交易的能力都是比较受限，比如比特币每秒3-7笔交易，以太坊每秒7-15笔交易等。我们都知道三角理论，所谓的区块链“不可能三角”，也称为“三元悖论”，通常指区块链系统无法同时兼顾去中心（Decentralization）、可扩展性（Scalability）、安全性（Security），至多只能三者取其二。是否有一种新的机制能够让少部分节点来验证每笔交易，足够多的节点来验证每笔交易系统必然安全，但又不能并行处理更多的交易，在这里我们引入了bumo多链orbits，obits采用的是主子链架构，主链上可以无限挂载多条子链，子链的区块头信息作为摘要写入到主链中，orbits架构可以线性的提升性能。

二、性能提升的情况下如何保证安全

出于对系统安全的保证导致了可扩展性受限 。当为了提高 TPS（每秒交易数）将交易分配到各个子链的同时，我们随之也减少了每笔交易的计算和验证的节点数。这种情况下对安全性是极大的挑战。多链体系下单链攻击问题尤为突出，怎样防止单链攻击等安全是目前的当务之急，有没有一种办法既能满足性能和扩展的同时也能保证子链的安全性呢？这些都是值得深思的问题，多链的其中一个重要机制就是，如何在链上生成随机数。验证节点被选中的几率，应该仅与验证者的保证金相关，且成比例。如果验证节点能够预测，或是任意选择他们想要参与的链，那么不诚实的验证节点既可以相互共谋，展开一个适应性攻击（adaptive attack）。如果采样不能以较高的随机性进行选择，那么攻击者很可能在多链中展开 1% 的单链攻击：如果有 100 条链，攻击者可以专注于攻击某一条链，他们只需要 1% 的验证节点就可以控制单链。

三、VRF

在多链的体系，这很容易，主链可以管理整个多链体系下的 “验证节点集合”在状态中被跟踪，并且可以直接从这个集合中简单地抽样。 协议内算法运行并为每条链选择45个验证节点，或者每个验证节点独立地运行一个算法，该算法使用一个共同的随机源（可证实地）确定它们在任何给定时间的链。 请注意，抽样任务是“强制性的”是非常重要的。 节点不能选择它们进入的链。 如果验证节点可以选择，那么攻击者可以用很小的验证节点集中他们的利益到一条上并攻击它，从而消除系统的安全性。

在这里bumo  引入了VRF算法，相比于bumo 1.0 DPOS+BFT共识相比，最主要的创新是将proposer和validator的选举随机化：

proposer：根据随机数从每组验证节点中选出proposer，从中挑选数值最大的节点出块

validator：按照持有token的比例，通过抽样的方式对验证节点进行混洗，然后决定验证节点属于那条链的验证节点

其实bumo VRF算法最核心的地方在于对验证节点进行抽样和混洗，以下将着重分析该算法。

在保证公平性的情况下保持结果的随机性

公平性：长期来看，节点被选中的概率应和它所持有的token数量有关系，但是也不能完全去看token数量，比如节点是否作恶、宕机、离线等都要考虑

随机性：单次选举结果随机且无法预测

目的是让普通用户也可以参与其中，DPOS的不足之处在于如果超级节点比较稳定，一般的用户很难能参与其中。VRF即可验证随机数：首先它是一个随机数，其次由于它包含生成者的私钥签名，验证者可以通过公钥确认该随机数的合法性。示意图如下：

最终的输出是2个：proof和随机数(Rand)。粉红色箭头是随机数生成流程，蓝色箭头是随机数验证流程。

重要的是要指出，即使随机数的产生是高度可利用的，这对协议来说也不是一个致命的缺陷。 相反，它只是意味着有一个中等偏高的中心化激励。 原因在于，由于随机性选取相当大的样本，因此很难将随机性偏差超过一定数量。

如上所述，最简单的方法就是通过二项分布。 如果希望避免大小为N的样本被超过33％攻击，并且攻击者具有全链权益的p％，则攻击者能够在一轮中获得大多数的概率是：

   下面是一个表格，说明N和P的各种值在实践中的概率：

	N=50	N=100	N=150	N=250
p = 0.33	0.0108	0.0004	1.83 * 10-5	3.98 * 10-8
p = 0.25	0.0001	6.63 * 10-8	4.11 * 10-11	1.81 * 10-17
p = 0.2	2.09 * 10-6	2.14 * 10-11	2.50 * 10-16	3.96 * 10-26

 

因此，对于N> = 150，任何给定的随机种子将导致有利于攻击者的样本的可能性确实非常小  。 这就意味着从随机性的安全角度来说，攻击者需要在选择随机值的顺序上有非常大的自由度，以彻底打破抽样过程。 大多数随机性的漏洞不允许攻击者简单地选择种子; 在最坏的情况下，他们给了攻击者许多机会从许多伪随机生成的选项中选出最有利的种子。目前bumo多链情况下每条子链的验证节点必须超过30个，而且我们的链的条数最少也在10条以上，再加上候选节点列表的节点300个，整体的验证节点差不多为600个，被攻击的程度是非常之低。

bumo VRF算法具体步骤:

bumo VRF总体的设计过程分成两个部分，第一部分是随机数的产生，第二步是验证节点混洗，示意图如下：

1. 随机数的产生过程

Qr是第 r块的种子，用于选举 Leader 和 Verifier，r%phase_size==0为验证节点洗牌的种子。的计算方式如下：

• 如果Br-1是合法区块，则Qr=H(BLS_Sign(Qr-1),Br_H)
• 如果Br-1=Be，即空区块，则Qr=H(Qr-1, Br_H)

验证节点的洗牌是一个阶段动态调节的过程，所以洗牌的随机种子与阶段phase出块有很大关系，从上图可以看出所有的随机种子都有主链产生并且签名采用的BLS阈值签名的方式（目的是让多个人能够签出同样的结果），最初的的源以B1区块哈希作为初始的来源。根据以上公式可以推出phase 1 第一阶段的洗牌种子为Q5。

1. 验证节点的混洗过程

第一步：首先将第一阶段洗牌种子Q5 hash 取前缀的3为字节作为种子然后上模32，得到步长rand_size

第二步:按照以下逻辑不断交换

for (i = 0; i < 32-(32%rand_size); i += rand_size)
{

     rand_chunk = hash_seed[i : i+int(rand_size)];
        for (j = 0; j < rand_size; j++)
            {
                value |= rand_chunk [j];
            }
    replace_index = value %(list_size -i)+i;
    exchange(I, replace_index);
}

第三步：不断重复第二步直到循环到list_size

第四步: 对所有混洗过的验证节点进行分组

 

四、轻节点执行

选择采样周期只会影怎样自适应响攻击者使得协议仍然安全防御他们; 例如，如果您认为适应性攻击（例如不诚实的验证节点发现他们是同一个样本的一部分并且共同勾结），可能在8小时内就发生勾结，则采样时间为4 小时不应该是16小时。

每个采样周期的主要挑战是重新改组会带来非常高的开销。 具体来说，验证链上的块需要知道该链的状态，因此每次验证节点被重新改组时，验证节点需要下载他们所在的新链的整个状态。这需要强大的状态大小控制策略（即经济上确保状态不会增长过大，无论是删除旧账户，限制创建新账户的比率还是两者的结合），以及相当长的重组时间。

目前，bumo客户端可以在1天内下载和同步整条链的全部数据，这显然不符合快速切换的需求。 在这个需求的场景下我们引入了轻量级节点演算，能够达到快速同步链的状态。

轻量级演算的目的是让节点在不存储全状态，只需要存储状态根的情况下也能执行和验证交易。比特币的轻节点客户端能够验证交易的有效性，并不能执行和演算交易。轻量级演算可以用于跨链过程中演算和验证其它链交易、可以用于多链中不同链验证节点随机洗牌后切换节点、可以用于快速同步其它链数据、可以用于主-子链结构中，子链节点作恶没法演算子链节点数据问题等。

轻量级演算实际上是构造在轻量级客户端之上，轻量级客户端只存储状态树根。轻量级客户端概念，假设状态转换可以用数学的方式进行表达，则表达形式为Bu_ST(S, B) -> S’，其中S、S’代表状态，B代表区块（或者是T，代表交易），那么Bu_ST就是状态转换函数。理论上，很多相似的协议，都能通过同种协议变形进行变更。

转换过程如下：

S->S的状态根，S包含32字节Merkle根哈希

B->（B，P），其中P代表‘证人’，即证明执行B可访问的所有数据的值的一组Merkle分支

Bu_ST->Bu_ST’，以状态根以及区块+证人（数据）做输入，然后在执行区块需要读取账户信息、存储密钥或其他状态数据时，使用证人做‘数据库’数据库（若证人不包含请求数据片段，则退出并提示错误），最后输出新状态根

也就是说全节点只存储状树根，打包区块与Merkle分支（‘证人’）是验证节点的事；然后由全节点下载并验证这些大（带证人数据的）区块。所以轻量级全节点与常规全节点是完全可以在同一个网络中和平共处的；设置个状态转换节点，为区块B附上验证其所需的证人数据，然后在另外轻量级节点网络协议中广播这个（B，P）；验证节点的Leader在该无状态网络上打包区块后，把附带的证人数据去掉，然后重新在常规网络上进行播。

以上都为理论上的描述，以下我们会以流程的方式对轻量级验证进行说明，轻量级演算节点只存储状态的root信息，观察客户端存储链的全状态信息。

1. 1. 轻量级演算节点想要执行交易tx，在链上对应的状态为D，轻量级演算节点并不知道D的状态，所以它会向观察者客户端请求D的状态以及会影响D变化的Merkel分支Witness: {R, A, C, D, B}
   2. 轻量级演算节点获取相关的数据
   3. 将D状态及Merkel分支等RW_Set广播给其它节点
   4. 不同节点收到交易及相关依赖后执行和验证交易

在图的右边看到了轻量级演算用于各种各样的场景，这个部分在开端就又阐述，此处滤过，以下为轻量级演算的时序图。