如果经常使用互联网,那么您可能总会遇到Reddit、Netflix、Instagram、Airbnb等主流网站宕机的情况。这些业务完全依赖于亚马逊网络服务(AWS)的基础设施,我们很难对它们这些年来的各种宕机视若无睹。即使上述网站准备了各种预防性措施(例如负载平衡)来应对突发情况,但是在托管服务商出故障时,这些措施也形同虚设。

为了提供AWS的性能,这些故障已经按照整体方案被合理地分隔开,影响被降至最小。但是,随着世界持续被软件所吞噬,即使微小的影响也越来越严重。我们可以想象一下,未来自动驾驶汽车的软件如果采用这个架构,是绝对不能出现故障的(即使只有一分钟)。正是这种未来的“非中介化”思维模式导致了区块链运动的兴起,区块链试图改善现有的局面。

虽然许多人对“正常运行时间超过亚马逊AWS”的想法嗤之以鼻,但是,在去中心化社区这并非异想天开。事实上,比特币刚刚做到了10年以来,出块不间断——很少有大型服务机构能做出这种产品。

但另一方面,区块链社区的人都知道如此长的在线时间是以可扩展性为代价的。对采用工作量证明来达成共识的区块链尤其如此。因此,我们也见到了在开发更有效共识算法的探索,以及(从某工作量证明区块链中获取价值,并用它来资助状态通道、等离子体plasma、弹性侧链等……)第二层解决方案的出现。虽然每种可扩展性解决方案在安全性、效率、资金锁定和数据可用性方面都各有利弊,但是我们相信SKALE是以太坊“执行层”最理想的去中心化可扩展性解决方案。

在本文中,我们详细介绍了如何通过将最好的可证明研究成果与世界一流的工程技术相结合来解决这些问题,来创建一种共识机制:在独立环境中它的运行速度超过20,000TPS;在完全连接的以太坊的环境中,TPS达上千,平均区块时间为1-2秒。

注意:如果您还没有读过我们的简要技术概述,建议您在阅读下文之前先阅读一遍,以对SKALE有个总体了解。

通讯

网络安全假设

该协议假定网络是异步的,并且确保信息最终都能传递,即所有虚拟化子节点都通过可靠的通信链路连接——链路可以无限慢,但最终都能将信息传达。

此异步模型与比特币及以太坊区块链相似,反映了现代网络的状态——暂时的网络分歧是正常的,但最终信息都能成功传递。最终的传递保证在实践中实现的方式为:在信息遭受到指数式退回的情况下,发送信息的虚拟子节点会进行多次尝试,向接收虚拟子节点传递信息,直至该传递成功为止。

待办交易队列

每个虚拟子节点维持着待办交易队列。第一个接收到入列交易的虚拟子节点会尝试通过其指定的离开信息队列,向对等节点进行传播。为安排信息传递给特定的对等节点,信息会被放置于相应的离开队列里。每个离开队列会被一条独立的线程所维护,以支持信息的并行传递,因此特定的对等节点接收信息失败不会影响其他对等节点的信息接收。

共识

区块提案

在上一轮共识完成之后,每一个虚拟子节点的 TIP_ID 会递增 1,同时立刻触发它们创建一个区块提案。

为创建区块提案,虚拟子节点会:

  1. 检查其待办交易队列。
  2. 如果待办队列中的交易规格小于或等于 MAX_BLOCK_SIZE,那么虚拟子节点会取出队列中的所有交易来填入区块提案。
  3. 如果待办队列中的交易总规格超过 MAX_BLOCK_SIZE,那么虚拟子节点会按接收的先后顺序取出队列中的待办交易,以填入 MAX_BLOCK_SIZE 的区块提案。
  4. 根据 SHA-256 根节点从最小值到最大值排序的交易,虚拟子节点收集区块提案。
  5. 如果待办队列是空的,那么虚拟子节点会等待一段 BEACON_TIME 的时长,如果此后队列仍旧为空,则创建一个不包含有任何交易的区块提案。

请注意:虚拟子节点在提案时不会把交易移出待办队列,原因在于提案时无法保证该提案会被接受。

数据可用性

一旦某个虚拟子节点创建一个区块提案,它会采用下文所描述的数据可用性协议通知其他的虚拟子节点。数据可用性协议保证了信息能够传递至绝大多数的虚拟子节点。

此协议包含五个步骤,如下所述:

  1. 虚拟发送子节点 A 把由区块提案与交易哈希组成的提案 P 发送至它的对等节点。
  2. 一旦接收到提案 P,每个对等节点会通过匹配哈希值与待办队列的交易对其进行重建。对于待办队列中找不到的交易,对等节点会向虚拟发送子节点发出请求。然后,虚拟发送子节点 A 会把这些交易的主要部分发送至虚拟接收子节点,从而允许对等节点重建区块提案,并添加至其提案存储数据库PD。
  3. 对等节点把包含 P 的阈值签名碎片的收据回发至 A。
  4. 待向绝大多数虚拟子节点(包含 A 自己,总数量≥2/3)收集阈值签名碎片完成后,A 会创建一个绝大多数签名 S。此签名作为绝大多数虚拟子节点拥有 P 的收据。
  5. 最后 A 会把此绝大多数签名 S 广播至网络中的每一个虚拟子节点。

请注意:每个虚拟子节点都拥有 BLS 私钥碎片 PKS[I]。原始密钥碎片通过Joint-Feldman 分布式密钥生成(DKG)算法实现,弹性侧链创建与虚拟子节点轮换时皆采用此算法。

在未来的共识步骤中,所有子节点对提案 P 进行投票时,需有数据可用性收据,其投票必须包含绝大多数签名 S,否则诚实的虚拟子节点会忽视不包含绝大多数签名 S 的任意投票。此协议保证了数据可用性,意味着任何取得共识的提案 P 对任意诚实的虚拟节点皆为可用的。

可插拔二进制拜占庭协议

下文所描述的共识采用异步二进制拜占庭协议(ABBA)。目前我们使用来源于Mostefaoui et al 的 ABBA 协议的变体。任何其他 ABBA 协议 P都可使用,只要满足以下特点:

  • 网络模型:P 假设上述描述的异步网络信息传递模型。
  • 拜占庭节点:P 假设少于1/3的拜占庭节点。
  • 初始投票:P 假设每个节点初始投“是”(1)或“否”(0)。
  • 共识投票:P以共识投了“是”或“否”结束,如果共识投票为“是”,也就保证了至少有一个诚实节点投了“是”。

请注意:ABBA 协议通常会输出一个随机数字COMMON_COIN,作为操作的副产品。我们把此

COMMON_COIN 用作一种随机数源。

共识轮次

提案阶段结束后,每个收到提案P的绝大多数签名 S 的虚拟子节点 A立即会在一个共识轮次 R 中对ABBA进行投票。协议如下:

  1. 对于每一轮 R,虚拟子节点会执行 N 个 ABBA 实例。
  2. 每个 ABBA[i] 相当于虚拟子节点 I 在区块提案中的一次投票。
  3. 每个 ABBA[i] 以一次“是”或“否”结束共识投票。
  4. ABBA[i] 全部结束后,会有生成投票向量 v[i],它包括每次提案的“是”或“否”。
  5. 如果投“是”的仅有一票,相关的区块提案 P 则被提交至弹性侧链。
  6. 如果投“是”的有多票,则会用伪随机的数字 R从“是”的投票提案伪随机性选出P。选出的提案对 R 除以 N_WIN 剩下的部分进行索引,其中N_WIN为投“是”提案的总数。
  7. 随机数R是 ABBA 所有COMMON_COIN 的总和。
  8. 如果所有投票全是“否”,则向该区块链提交一个空的区块。所有投票都为“否”的可能性非常小,随着N 的增加而降低。

确定选出的区块

一旦共识在任意虚拟子节点 A 上成功选出区块 P,虚拟子节点将执行以下算法以确定提案,并提交至区块链。

  1. A 会检查其是否收到选出的提案 P。
  2. 如果A 仍未收到提案,它将向其对等的虚拟子节点提出申请,进行下载。
  3. A 将对 P 签署一个签名碎片 S,并将其发送至其他全部的虚拟子节点
  4. A 等待接收来自包括其自己的绝大多数虚拟子节点的签名碎片。
  5. A 一旦接收到绝大多数的签名碎片,就会把它们组合成一个阈值签名。
  6. SKALE 网络白皮书 10
  7. 最后,A 把 P 与 阈值签名 S 一同提交至区块链。

提交至弹性侧链的区块包含区块头和区块主体。区块主体是区块中所有交易的级联交易数组,而区块头是一个JSON 对象,它包含以下内容:

图片


重启和崩溃

在重启期间,重启节点会暂时处于不可用状态——对于对等节点而言,这相当于一个短暂的慢速网络连接。重启后,指定给该节点的信息将被发出——此协议支持在不破坏共识执行的条件下进行重启。

在硬崩溃(由于硬件故障或软件漏洞导致某个节点无法在线,该节点无法达成共识的状态)条件下,该节点的对等节点会持续尝试向其发送信息,直至离开信息队列溢出——这会导致它们抛掉较旧的信息。为了降低这种状况的影响,长于一小时的信息将从信息队列中丢掉。

某个节点处于硬故障时,在每一轮共识中它会被当作一个拜占庭节点——网络允许少于 1/3的节点同时出现硬故障。如果多于1/3节点出现硬故障,共识将暂停,可能会导致区块链失去活力。

如果在指定时间内没有提交新的区块,那么这种灾难性的故障就会被检测到。在这种情况下,故障恢复协议将使用以太坊主链进行协调。节点将停止共识操作,同步它们的区块链,就某个时间点重启共识。最后,在一段强制性的停止后,节点会在某个约定的时间点开始共识。

同步代理

运行在每个节点上独立的同步代理,它确保该节点的区块链与网络上的区块提案数据库已经进行同步。同步引擎持续对其他节点进行随机同步连接,当某个节点发现它们的 TIP_ID 小于它们对等节点时,就会下载遗漏的区块,验证接收区块的绝大多数阈值签名,然后将它们提交到它的区块链。

从硬故障中恢复在线的节点将立刻开启其同步进程,同时通过接受区块提案与依据共识机制进行投票,而参与新区块的共识,但此时它不能发起自己的区块提案。原因在于每个区块提案需要前一个区块的哈希值,而只有某个节点完成同步进程后,它自己才能发起一个具有特定 BLOCK_ID 的区块提案。

通过每个节点上的这个代理,重新同步区块链后,经历了硬故障的节点能够很容易重新参与到区块提案中。

了解更多

如果您对体验SKALE感兴趣,请记得加入SKALE的Discord社区,查看开发者文档

想更深入地了解SKALE的技术,请查看我们的技术概述共识概述

SKALE的愿景是让创建运行全状态智能合约的低成本、高性能侧链更简单快捷。我们旨在不牺牲安全性或去中心化的前提下,为开发者提供快速与功能的高效体验。您可以通过TelegramTwitterDiscord关注我们,注册这个表格获取最新的SKALE讯息。