HORIZEN侧链白皮书

侧链：链与链之间的脱钩共识

Alberto Garoffolo 和 Robert Viglione

Horizen区块链基金会

2018年10月

摘要

我们设计了一种新颖的侧链结构，既可以与Horizen区块链兼容，又能安全和分布式地进行跨链传输，而无需主链节点跟踪并验证侧链上的交易。 所提出的方案也同样可以用于其他的区块链项目。 我们表明，在某些合理的假设下，我们的跨链转账机制是安全的。

1.简介

在2008年比特币诞生后加密货币逐步涌现[13]，并且获得了各个领域的专家重点关注。 比特币是第一个成功基于点对点网络的分布式支付系统。 比特币的关键特征 - 去中心化 - 据称是一项颠覆性创新，有助于建立更加健全，公平和透明的金融体系。

作为完全开源的比特币，其他的区块链系统也利用了相同的分布式的原理，在这基础上还增加许多额外的进步，如智能合约[6]，私密支付[21,12]，分布式治理[5]等。 Horizen [8,19]就是这种系统的一个例子。 在保留基本区块链功能的同时，它引入了各种新功能，如私密支付，分布式治理，强大的节点网络（安全节点）等。

由于Horizen基于ZCash源代码，ZCash又基于比特币，因此它保留了原始比特币协议中存在的所有缺点，如有限的吞吐量，高延迟，低扩展性等[1]。 更重要的是，这种分布式的系统很死板，不善于做出改变，因为没有单一的实体来决定更新。 即使是更改微小的协议也需要社区之间协商，过程繁琐，这使得增加新功能变得非常困难。

这些问题迫使研究人员寻找可能改善这些限制的解决方案。 A. Back等人提出了一种最具吸引力的方法，被称为侧链。 在2014年[2]。 侧链方法能够改进现有的区块链系统，而无需实际更改系统本身。 基本思想简单但功能强大：构建一个具有所需功能的并行链，并提供在这些链之间传递价值或硬币的方法（见图1.1）。

图1.1侧链的基本构架：允许用户在主链和侧链之间转账以及获取所需的功能

例如，像比特币这种本身不支持智能合约的区块链系统可以通过利用侧链方法[15]来扩展这种功能。 实际上，可以部署具有不同特征和属性且无数量限制的侧链，而主区块链保持不变。

侧链设计中最关键和最有争议的部分是硬币转移机制（双向挂钩或简单的2WP）。 现有的侧链架构为具有不同属性和特质的区块链提供了解决方案。

在本文中，我们设计了一种新颖的侧链结构，既可以与Horizen区块链兼容，又能安全和分布式地进行跨链传输，而无需主链节点跟踪并验证侧链上的交易。 Horizen的侧链结构需要修改主链核心共识协议以实现跨链传输，但一旦实施，它将允许以可靠的方式部署多个侧链。

本文的结构如下：第1.1节概述了该领域的现有发展。 第2节详细讲述了有关Horizen侧链的必要性及其构造基本要求的。 第3节提供了拟议侧链结构的深入技术细节。

1.1相关工作

侧链的概念最初是由A.Back等人提出的。 在2014年[2]。 本文引入了双向挂钩的一般概念，并描述了两种操作模式 - 同步和异步 - 以实现挂钩链之间的相互作用。 同步模式表明主链和侧链彼此了解并且可以直接验证传输事务，而异步模式依赖于验证器来处理传输事务。

驱动链的一般概念在[17,11]中被提出。 它旨在比特币网络之上部署侧链。 虽然通过从主链提供SPV证明（如[2]中的同步模式）来处理正向传输（从主链到侧链），但是反向传输依赖于验证器。 驱动链提案中的验证人是在主链上的矿工，他需要跟踪侧链和处理转账。

A. Kiayias和D. Zindros在他们的演讲[9]中提出通过利用智能合约实现基于工作量证明（POW）的侧链协议。 另一种依赖智能合约的无表侧链结构称为Plasma，由J. Poon和V. Buterin在[14]中提出。 相反，我们的构架并不依赖于智能合约技术来提供双向挂钩。

还有许多其他的项目都在尝试构建跨链转移机制，包括Liquid project [4]，Polkadot [20]，Interledger [18]，Cosmos [3]等等。 他们提出了各种解决方案来实现与我们的构造不同的双向挂钩，主要针对私有链和联盟链。

2.预备活动

Horizen区块链系统具有广阔的路线图，其中包含各种新功能，例如用于分布式资源治理的财务系统[22]，用于安全和超级节点的分布式支付网络等。其中一些功能需要对核心客户端进行重大修改。如果直接在现有代码库中实现，可能会有严重的缺点：

1.整体应用程序的不断增长，放大了整体架构，并使新功能的引入变得复杂。

2.对现有的C ++代码库更改非常复杂。

3.将新功能集成到核心客户端会带来安全隐患。

4.需要硬/软分叉来改变共识协议。但是由于社区会有各种争论导致无法经常进行。

5.核心共识协议的吞吐量/延迟性受到限制。

6.引入新功能的灵活性有限（例如，很难用现有的共识协议替换基于DAG的协议以实现“瞬时交易”）。

出于这些原因，我们决定选择侧链方法来整合新功能。它是最具吸引力的方法之一，因为它允许至少克服以下问题：

1.侧链实现与主链完全分离，因此不需要对核心客户端进行修改（除了只执行一次对侧链初始支持）。侧链可以适用于任何适合使用“分布式帐本”的技术，而且主链不需要知道它。

2.在侧链功能有错误的情况下运行，可能的安全隐患也仅限制在侧链内，并且主链将冻结侧链所抵押的代币。

3.只需要核心共识协议的一个硬分叉（启用侧链）。然后可以无缝地部署任何新的侧链而无需更改主网。

此外，侧链方法通常会有更大的灵活性。在侧链上面可以可靠地开发各种新功能（例如，简单或智能合约，瞬时支付等）。

2.1 Horizon侧链的要求

考虑到上述限制，我们可以概述Horizen侧链架构的主要要求：

主链不用追踪并知道侧链。不应要求主链节点跟踪侧链。只有跨链传输是由主链负责和验证的，但为了验证它们，它应该足以仅跟随主链。

统一的跨链转移。所有侧链应采用主链已知的相同统一跨链（CCT）协议。即使CCT协议的参与者对于不同的侧链也是不同的，该过程应该由主链共识协议指定。统一部署多条侧链，而无需分别为每个侧链修改主链的共识协议。

灵活选择侧链共识协议。任何侧链共识协议可能与主链使用的协议不同。通常，主链不应该依赖关于侧链共有协议或其结构的任何假设。关于跨链转移的共识应该与特定的侧链共识协议分离。

平行侧链。 Horizen侧链架构不应限制同时部署的侧链数量。所有部署的侧链应完全独立地并行工作。对于不同的侧链，交叉链转移也应完全独立。

容错。主链应该对任何侧链故障（包括恶意行为）具有容错能力。风险应仅限于侧链平衡。即使在完全侧链腐败的情况下，也不可能从侧链中取出比以前更多的硬币。

核心微调。 Horizen核心所需的修改不应做过多修改。

开发侧链的SDK会提供测链开发的模版，模版包括最基本的共识协议。SDK会提供方便主要测链组件替换的界面。

3.侧链构架

本节为侧链结构的详细信息。 我们首先定义侧链的抽象模型，然后指定所拟定结构组成部分的细节。

3.1概述

分析现有的构建侧链的尝试[2,17,11,9]，我们例出侧链的两个主要组成部分：

1.跨链传输协议 - CCT（双向挂钩）。

2.侧链共识协议 - SCP。

定义这两个组件对于确定精确的侧链结构至关重要。 根据实现，它们可以合并到主链中或完全独立于主链。

在我们侧链的构造中，我们将这些组件分离。 CCT协议由主链逻辑统一和修复，因此所有侧链将使用相同的CCT协议。 SCP协议通常与CCT和主链逻辑完全分离，因此侧链开发人员可以根据需要和偏好自由选择SCP协议。

尽管SCP协议可能因不同的侧链而异，但我们会提供结构以供参考。

跨链传输协议。 CCT协议定义了双向挂钩的结构，因此它由两个子协议组成。 第一个定义了正向传输过程，另一个定义了 - 反向传输过程。 正向传送将硬币从主链（MC）传送到侧链（SC）。 反后传输将硬币从(侧链)SC传回（主链）MC。

在我们侧链的构造中，正向转移将在主链中启动，用特殊主链交易来实现并燃烧硬币，只要用户在提供侧链中的元数据，便可在侧链中获取相应数量的硬币。由于传输是在主链上启动的，并且不需要来自侧链的任何其他信息，因此主链和侧链都可以轻松验证。在这种情况下，正向转移的结构相对简单。

进行反向传输需要更复杂的过程。它们在侧链中启动，然后传播到主链，同时在SC上刻录相应数量的硬币并在主链上重新创建它们。由于主链不遵循侧链，因此无法直接验证此类反向传输的有效性。为了保持主链有验证反向传输的能力，我们使用一组称为验证者的特殊参与者来管理此类传输的认证。验证者在主链中注册，并抵押特定数量的硬币。它们的主要目的是跟踪侧链，收集所有反向交易到证书，签署证书并将它们传播到主链。由于主链已知验证者列表，因此可以轻松验证证书。

侧链共识协议。 尽管SCP可以用不同的方式实施，但我们将提供参考结构。 它基于Ouroboros [10]协议中提出的方案，并进行了修改，以便于与主链结合。 它还提出了一种不同于Ouroboros中提出的随机生成算法。

在以下部分中，我们提供了上述协议的详细说明。 我们将从SCP描述开始，然后在上面构建CCT协议。

3.2侧链共识协议

对于侧链共识协议，我们采用了Ouroboros的修改版本，该协议基于POS [10]。 其核心是将时间划分为具有预定数量的时隙（代）。在一个时隙开始之前，有一个时隙领导者“选择程序”，旨在选择为下一个时隙选出一个领导者；这个领导者，他有权在此时间段内生成一个块。（图3.1）。 该协议在同步环境中操作，其中每个时隙花费特定的时间量（以20秒为例）。

代：是指特定位置处的k个连续时隙的序列Epi =（）,其中k是时期的预定义长度，i是代的序列号。

时隙：是指特定的时间段，在此期间，每个时隙都有一个相应的时隙引导器，旨在选出一个时隙领导者，并授权他去产出新的区块。  时隙领导者可以跳跃性地生成块，并且在这种情况下，后面的块将引用最新生成的块。

图3.1一个时隙的一般方案。 请注意，即使每个时隙有一个指定的领导人，领导人也可以跳过1个生成块，在这种情况下，时隙保持为空。

时隙领导者。一个时隙Slij的领导者，由“选择程序”随机选出，选出的领导者被授权生产出对应的Slij区块。

时隙领导者选择程序。时隙领导者选择程序（，随机数）是一个选择过程，该过程根据押注复原后的和一些随机值rand对应地选择出所有“代”的领导者。在的时隙开始之前，押注分配要被复原。仅在押注分配原复后才会显示随机数。

在我们的构造中，我们修改了协议以引入侧链与主链绑定。这意味着侧链块可以包含对主链块的参考，使得主链区块的历史存储在侧链中。通过参考，主链区块的哈希数据，或者在主链区块包含该侧链的相关交易数据的情况下，整个块头与侧链及其(默克)Merkle路径一致。

侧链区块产出者的职责是在侧链产出区块的时候，要与主链保持一致性和有序性。侧链块可以包含对主链块Bi的引用，当且仅当（1）块Bi是有效的主链区块，以及（2）对所有先前的主链块的参照，k∈{η，η+ 1 ，...，i - 1}已经包含在侧链区块中（包括当前区域，因为它可能包含多个参照），其中η是起源参照（图3.2）。

请注意，区块产生者不一定包含主链参照，但我们假设诚实区块产出者会这样做以支持主链和侧链之间的硬币转账。 也可以为包含参照的块产生者提供激励机制。 例如，发起正向/反向的用户可以从每笔交易中支付少量费用。 激励机制超出了当前研究的范围，因为我们仅提供侧链共识协议的示例。

图3.2丢失的侧链区块（SC）通过参照主链区块（MC）来弥补的例子。

将侧链与主链绑定有两个主要原因：

1.MC和SC之间的完全同步。当侧链块参考主链块时，它明确地认同来自块和来自所有先前块的所有交易数据。 这意味着如果主链包含与此侧链相关的任何交易（例如，主链MC→侧链SC硬币转移），则此类交易可以立即转移到侧链。

2.不保证主链的最终确定性。 基于如下考虑，我们假设主链是Horizen区块链，它使用修改后的中本聪共识加区块延迟惩罚机制。 众所周知，Nakamoto共识并未提供块链的最终确定性[16]。 这意味着总是存在一定概率，将一些子链将被还原并被具有更多工作量用其它链替换。 这种行为通常由主链处理，但对于侧链可能是灾难性的，因为已经在侧链中确认的从MC→SC交易可以在主链中被还原。 绑定消除了这种情况，因为在MC中的有分叉的情况下，还将恢复参照MC中分叉块的相同的侧链分叉块。

3.完全参照。 完全参照意味着侧链块包含主链块的完整链。 即使某些区块产生者错过了新生成区块的机会，但下一位区块产生者将弥补前一位错过的主区块数据（参见图3.3）。

图3.3丢失的侧链区块（SC）通过参照主链区块（MC）来弥补的例子

在有跨链交易的情况下，参照本身是相应主链区块（MC块）或完整的区块哈希。 通过这种方式，可以对主链块进行精简验证，从而能在侧链中引入附加功能，例如跨链交易的精简验证。 例如，当在主链块中发生的交易时，侧链时隙领导者创建相应的侧链块，其中他在的区块头旁边产生一笔的交易，以及相应的Merkle路径。 在这种情况下，此类交易可以由任何侧链节点验证，而无需与主链核实。

完整同步。 通过完整同步，我们暗示了一个规则，即侧链时隙领导者必须在生成的侧链块中参照主链块中出现的所有与该侧链相关的交易（图3.4）。

通过这种方式，主链的跨链交易可以立即同步到侧链。 如果时隙领导者违反规则并且不同步来自主链的交易，这样的块将则被视为无效区块并分叉成无效孤块，侧链继续由有连续性的区块继承。

在同步区块时，将给存储在主链参照块中的根提供其Merkle路径。

随机性。 Ouroboros股权证明共识协议的关键组成部分是真正随机，对来源无偏见的随机性。 只有在保证随机的公平公正性的同时才能保证安全性。 在最初的Ouroboros协议中，随机性是通过基于可验证可共享秘密协议（特殊抛硬币）获得的。 该协议由时隙领导者运行。

在我们的侧链构架中，我们用工作量证明的主链，并在此解决方案中产生随机性。 详细的协议及其安全性将在后面的章节中讲述。

图3.4主链和侧链之间的txs同步示例图

安全性。证明区块链共识协议安全性的标准程序，需要满足分布式总账本要具有两个基本属性：活跃性和持久性[7]。 活跃性确保诚实方广播的交易最终将被纳入在账本中，并且持久性确保一旦一个诚实节点确认交易，它也将被所有其他诚实节点确认（这样它将成为最终节点具有不可更变性）。这些属性通常在某些假设下得到证实，例如假设协议参与者中的诚实者占多数。我们推荐感兴趣的读者可以参考最初的Ouroboros论文[10]，以获得详尽定义的假设列表。

由于提出的共识协议还包含与主链区块的绑定，因此它假设在所参照的主链中大多数哈希算力是诚实者。在这些假设情况下，我们提议的协议与最初的Ouroboros和Nakamoto共识协议具有同样安全性。

我们想强调的是，不同的侧链可能采用不同的共识协议，或用更适合特定的用例（例如瞬时硬币交易）。侧链的共识协议（包括本节中描述的协议）不是本研究的主要焦点，它还需要进一步严格的安全分析。

3.3跨链转账协议

本节描述了跨链转账协议，它是侧链结构中最关键的部分。 CCT协议基本上由两部分组成：

1.正向传输协议。 从主链到侧链的转移。

2.反向传输协议。 从侧链到主链的转移。

我们还在单独的部分中区分了认证协议。 从逻辑上讲，认证协议是反向传输协议的一部分，因为它旨在验证从侧链到主链的传输，但为了对其安全性架构分析得更清晰，我们单独描述它。

3.3.1正向传输协议

正向传输的设计很简单，与许多现有的侧链架构基本相同[2,17,11]。

通常，它以如下方式进行：主链MC到侧链SC传输（图3.5）由一对交易表明：一个在主链MC上（发送TX），另一个在侧链SC上（接收TX）。 发送TX的目的是锁定/燃烧MC上的硬币。 接收TX的目的是在侧链上解锁/创建相应数量的硬币。 接收TX仅在发送TX确认后的情况下有效（基本上发送TX是锁定硬币的证明）。

图3.5从主链（MC）到侧链（SC）的正向交易（TX）

由于这种转账机制便于修改，方便更好发挥所侧链共识协议的优势（第3.2节）。 它不是依赖于用户在侧链中创建接收TX，而是直接由侧链区块产生者自动追踪主链区块发送过来TX。

在下文中，我们假设侧链共识协议是基于3.2节中描述的协议，我们来更正式地定义正向传输。

（发送交易）的定义。 发送交易是一种特殊结构的交易，它发动硬币从原始区块链A（主链）到目标区块链B（侧链）的转移。 发送TX的基本结构定义如下：

Sending TX = {ledgerid, txid, (sendAcc, receiveAcc), amount, sig}

各项含义如下：

ledgerid：是以前部署的交易所针对的侧链的唯一标识符;

txid：是唯一的转账标识符;

sendAcc：是原始区块链A上的地址，其地址余额（sendAcc）要≥发送数量，

receiveAcc:是目的地区块链B上的地址;

amount：是转移的硬币数量;

sig：是与发送方对应的签名。

发送TX在其所属的原始区块链A上燃烧硬币数量，以及在其地址余额减少相应数量的币。

在我们的案例中不需要接收特殊交易，因为相关的交易数据在区块产出者发送TX的时候已全部被传送至侧链（参见图3.6）。 为了保证在侧链块中执行发送事务的简单验证的可能性（无需跟踪主链），还包含发送交易时的完整Merkle路径。 由于Merkle根存在于主链块头中（也存在于SC区块中），因此侧链可以容易地验证发送过来数据。

在侧链区块含有主链区块后，创建相应数量的硬币并且在接收方地址对应地增加硬币余额。

图3.6主链（MC）到侧链（SC）的正向交易（TX）的同步以及侧链中的区块结构

请注意，提供的交易结构并非详尽无遗。 它仅定义那些应包含在交易中的常规信息。 具体格式可以根据区块链系统的交易模型而变化。 例如，Horizen系统使用比特币交易模型，可以通过引入特殊操作代码（如OP_SENDSIDECHAIN）或引入全新类型的交易来实现发送TX。 开发者自行决定最合适的路径。

安全性。 为了分析所述方案的安全性，我们将引入一种称为正向传输安全的属性，除非相应数量的硬币已经与主链中的发送TX一起燃烧。否则该在属性的侧链上不能创建硬币。

很容易看出，如果使用具有紧密绑定的共识协议（如第3.2节所述），则正向传输协议完全符合安全属性。 如果在主链中回滚所发送的TX，则侧链区块也相应地变为无效区块并且还被还原。 此外，只有发送TX的创建者可以指定接收者地址。 要伪造交易，则需要同时伪造发送方地址的签名，所以这是无法伪造的。

3.3.2反向传输协议

反向传输协议是现存所有侧链结构中最复杂的部分。 正是这个组件使得Horizen的侧链不同于现存其他类型的侧构结构。 复杂性源于主链对特定侧链一无所知的假设，因此主链不能直接验证来自侧链中已经启动的交易数据。

实现反向传输有许多的办法。 例如，A.Back等。 在他们的构架[2]依靠授权实体的联邦来验证转移，驱动链方法[17,11]涉及主链矿工投票（并因此验证）反向传输的正确性。

在我们的构架中，我们依赖于反向传输的批量验证（在某种意义上与[11]中相同），但验证过程与现有结构不同。 我们引入了称为验证者的独立实体，而不是依赖于矿工（区块产生者），他们负责验证反后传输的正确性。 验证者在操作期间通过低押股份的方式进行注册。

本节的其余部分是有关如何组织、验证和传输到主链的反向传输的详细信息。 第3.3.3节为验证人选择协议的详细信息。

MC区块链（以及相应的SC）的整个生命周期分为提现代（不要与侧链SC的共识代混淆 - 它们是不同的）有确定数量的块epoch_len（例如，epoch_len = 720）。 让我们定义一个块属于特定代，ep_id为，其中j∈0.. epoch_len。 在侧链中，j提现代（以及任何其他子阶段）要参照主链MC区块的定义，以便代ep_id从引用侧链SC区块的开始，并以指示区块的结束。

图3.7提现代示意图（a）

为了更加简单精确地为您讲述本文档的其余部分。我们假设MC和SC以及每个SC块的生成速率相同,并且都参照同一个MC块。 我们将用 表示主链块链，用表示法对应主链区块的相应侧链区块（图3.8）。

图3.8提现代示意图（b）

代的主要目标是提供一种有效的机制，该机制能将经验证后的数据从侧链发送到主链。 由于主链本身无法验证侧链数据的真实性和有效性，因此称为验证者的特殊实体有权对传输的数据进行验证。 在现有的基础设施上，对每个信息分别进行认证，其效率过于低下，因此采用批量认证法，这意味着数据首先在代内累积，再集合到一个称为跨链证书的结构中，由验证者进行验证和签名，再将交易信息传送到主链。 一个这样的签署周期需要一个提现代。

跨链证书的定义。 跨链证书（CCCert）是一个通用容器，用于从侧链将数据传输到主链。 它的规则由主链定义，并由三个主要部分组成：反向传输列表，验证者提现列表和欺诈报告列表。 要被主链接受，CCCert应由授权认验证者群体中的大多数人签署。 更具体地说，CCCert包含以下信息：

1.侧链标识符;

2.代序数;

3.代的证书编号;

4.反向传输清单;

5.验证者提现清单;

6.欺诈报告清单.

图3.9跨链证书的基础结构

验证者们在主链中注册，因此签名集合由主链进行验证。 第3.3.3节将提供有关验证者集体注册和选择的详细信息。 注意，每个提取代可以生成多达k个跨链证书，其中k取决于认证者的数量。

在继续进行基本的反向传输流程之前，我们将定义反向传输和反向传输清单的概念，这也是CCCert的一部分。

反向传输的定义：反向传输（BT）是一种抽象结构，它指定了从侧链向主链转移（硬币）单笔交易的细节。 结构由主链规则定义。 通常，它必须至少要有，1.指定一定数量的转移硬币，2.有关接收者的信息：BT（金额，接收者）。

更具体地，反向传输包含主链中的硬币接收人的信息。 例如，在Horizen区块链系统的情况下，它可以包含输出脚本，该脚本定义了Horizen主链中所转移硬币的所有权。

指定代的反向传输来自侧链。 发起一笔反向交易的最常见情况是由侧链用户创建的提现交易交希望将其硬币转移到主链上。 但是，它不仅限于用户的提现。 还比如，它可以是来自财务库的付款，也可以是任何在侧链规则定义下，其他类型的支付。

反向传输清单。 反向传输清单（BTList）是一个由主链规则定义的结构，包含一组向后传输的总数金额≤MAX_CERT_AMOUNT最大证书总额，其中MAX_CERT_AMOUNT最大证书总额是指单个CCCert的最大允许转移限额。 这些清单是由有序的反向传输集合下确定性的定义。

每个提现代包括两个阶段：准备阶段和签署阶段。 在准备阶段，用户可以提交在该时期处理的提现请求。 如果用户在准备阶段之后提交提现请求，则仅在以下时期理提款请求。 基本的提现流程如图3.10所示。

图3.10：基本提现流程

在块之后立即开始对i代的反传输的验证。此时，当前反向传输的集合被处理妥当，也同时构造了跨链证书清单，并为每个CCCert分配了应该对其进行签名的验证者。在代期间的所有反向传输的清单被收集并按时间顺序排序。 然后根据算法将所有反向传输交易都被打包为反向传输清单。

---

算法1.将反向传输打包到清单中

---

1：从列表中获得第一个为反向交易，直到数额>MAX_CERT_AMOUNT或直到后向传输清单用完为止。

2：从列表获得下一个为反向交易，直到数额> MAX_CERT_AMOUNT或直到反向传输列表用完为止。

3：重复该过程，直到后向传输清单用完为止。

---

要限制反向交易的数量以便不让主链MC区块受影响，因此我们引入最低转账金额。

数额≥MIN_TRANSFER_AMOUNT最低转账金额

以这种方式，每个证书的最大转账次数为：

最大转账次数=最大转账额最小转账额

简单来说所有后向传输都按时间顺序分组为，这样每个的总量不会超过证书转账额的（MAX_CERT_AMOUNT）阈值。 然后将包含在相应的中。

特定提款代中的证书数量取决于反向转账的数量和验证者的数量。 如果可以在单个证书中处理所有反向转账，则只能在代中创建一个证书。 但是最多􏰀只能发出􏰀证书，其中n 指代中有效验证者的数量，N是验证者的总量。

请注意，特定的提现代可能没有足够的CCCert来处理所有的BTLists。 在这种情况下，未处理的反向传输将被传输到以下一个提现代。

所有交易都以确定的方式完成，无需任何额外的链上交易，这样每个验证者都准确地知道他应该什么签名，后来验证者都知道如何去构建证书以及谁应该去签名。 在签署阶段，验证者将他们的签名提交给侧链。 在一个代成之后，所有签名都被聚合，再将聚合签名的证书发送到主链。

最大证书额MAX_CERT_AMOUNT值等于，其中N是签名者的数量和deposit Ci是指验证者的存款金额。 简单来说，每张证书的最大提款限额是有资格签署此证书的验证人的总存款金额的一半。 由于所有验证者存款相同（将在后面的章节中讨论）并且验证者组的大小也是恒定的，因此最大证书限额MAX_CERT_AMOUNT对于在侧链中发布的所有跨链证书将是一个恒定值。

上述规则还意味着每个代的最大提款限额等于验证者抵押总额的一半。

3.3.3 验证者

要成为验证者，主链MC押金保管人需要在主链上创建一个特殊的交易CertifierReg（），它将无限期地锁定他的存款，直到另一笔交易CertifierWithdraw（，sig(pubkey))被创建。验证者在注册后便有权为特定的侧链签名。 pubKey用于签署跨链证书和处理CertifierWithdraw提现事务。

验证者需要在i代开始之前创建并注册。才符合i代的验证资格。

验证组。 对于在epoch epid中确定一组合格证明者=，根据算法2，在中随机抽选出N个验证人组成验证组，其中i∈{0，...,􏰄-1}，合格的验证者由∈ RG\PC组成，其中RG是所有已注册验证组，PC是参与先前k时段验证组。（k指争议期时长）。

---

算法2.验证组构架

---

1.对于每个∈计算他的个人中彩= H（rand || epid ||），其中H（·）是强加密的哈希函数。

2.按升序对所有彩票进行排序。

3.取票（i·N，i·N + 1，...，i·N + N -1）并将持票者纳入验证者组中。

鉴于以上规则，g = 验证组可以确定性地为特定代定义随机值。 可以看出，一个验证者在同一代不仅不能被分配给的不同群体，并且在参与后的争议期也不具备相应资格。

要确定特定CCCert的验证组，遵循一个简单的规则：具有指标i的CCCert应由具有相同指标的验证组签名。 因此证书和证明者组之间存在一对一的映射：→。 遵循这些规则，很容易确定应该签署什么以及由谁签署。 验证者在每个提现代只能从属于一验证组，不能从属多个。

反向传输过程的各个阶段总结在图3.11中：

图3.11认证过程的各个阶段

可以看出，在准备阶段结束后，签名过程开始并且一直持续到代的结束。 在签署时期，每个选举产生的验证者应该创建和提交相应CCCert的签名。 签名应严格地在代结束之前提交。 在代结束后，每个CCCert的签名（应该在至少s =􏰀􏰁+ 1个签名，其中N是验证组的规模）应该收到单个多重签名中，并与相应的CCCert一起提交到主链。

随机性。对于验证者的选择程序，需要保证选择的随机性。为了提供可靠的随机源，我们假设使用简单而有效的机制来进行，利用主链工作量证明POW算法。特定代的随机性等于在准备阶段代的主链块的最小证明哈希值。在这种情况下，可以保证随机性是完全公正的，做恶者要操控随机性，将需要拥有大量的哈希算力来改变随机性，准备阶段。做恶者的开销与挖掘的成本大致相同。就此而言，我们认为，在大多数验证人都是诚实的假设下，这种攻击是不可行的，在经济上也无利可图。

正式分析将在未来进行单独研究。

请注意，在随机数被产生之前，对符合格验证人进行复原是至关重要的。一旦验证人的公钥被复原，要操纵选择程序的唯一方法就是操纵随机数本身，正如我们前面提到的，这么做不可行，也无利可图。

激励机制。 在验证组中，把提现总额的k％（例如k = 1）做为奖励，平均分配给被选中的验证人。 只有签名者才能获得奖励。 在提交给主链后，在下一个代开始时，SC块中的区块产出者将奖励打包。

验证人的奖金余额将由侧链SC管理（主链MC不知道验证者奖励机制）。

图3.12显示了所有的反向传输列表。 对于每次反向转账，都要收取一定费用，该费用将在以后重新分配给证书签名的验证者。

图3.12：包含5个反向传输的清单示例。 指定转账金额，并减去验证者的奖励

因此，自然而然地，认证者的奖励费是由交易发起者支付。 奖励支付：在下一个代开始进行，同一侧链块与其中来自同一主链CCCert的区块同步完成后便支付奖励。如图3.13所示。

图3.13：奖励验证者

所有认证者的奖励金额是平等的。 如果他们中的一些人错过了签名机会，他们的奖励将被烧毁。 只有在首次给主链提供“有效跨链证书”的情况下才会支付奖励。

聚合签名。 提交给主链的跨链证书附有：以验证者个人的签名构建的聚合签名。 可以不同方案进行签名，例如， 在最简单的形式中，它可以只是个人签名的串联。也可以使用更高级的方案，例如， BLS阈值签名。 选择合适的方案是值得去做更深的研究。

撤销验证人。 要撤销验证者的权限并解锁存款，验证人需要创建一个特殊的交易CertifierWithdraw（reg_，sig）。 在争议期结束后，且在该验证人没有欺诈性报告的情况下，其存款将被解锁。（欺诈报告和争议在第3.3.4章节中讨论）。

如果在签名阶段之前提交了CertifierWithdraw（reg_，sig）转账，则验证者的争议期从当下的代开始。 如果在签名阶段开始后提交，那么验证人在此代仍然符合条件，并且撤销程序将在下一个提现代进行。

3.3.4提现的保护措施

保护措施是一项特殊功能，用于防止在多数验证人都腐败的情况下，能将资产从侧链安全撤回到主链。保障功能的本质是保持侧链的平衡，并限制侧链的提取金额大于以前转移从主链转出的金额。

实施保护措施很简单：对于每个部署的侧链，主链保持一个特殊的平衡变量。每个正向交易通过转移的硬币数量的方式增加余额。每个提现证书都会通过提取相应地金额而减少余额。跨链证书的提取数量不得超过存储在侧链中所剩余的硬币数量。

这样一个简单的功能可以防止侧链对主链产生的任何损坏性影响。它保证只有转移到侧链的硬币可以从侧链撤回到主链。即使在验证者完全腐败的情况下，做恶者也无法凭空在主链上制造硬币。

3.3.5争议机制

为了进一步保护系统，引入了一种特殊的争议机制，以防止签署恶意的跨链证书。 我们将此类证书称为欺诈性证书。

欺诈性证书是在主链中已被确认但与先前在侧链中签名的证书不对应的证书。由于主链MC不遵循侧链的规则，并且无法直接验证证书的一致性和有效性，因此使用特殊争议算法来定义特定跨链证书是否具有欺诈性。

争议程序如下：以下k个连续跨链证书（从下面的撤销时期开始）可以包括欺诈性证书的欺诈报告。如果在争议期间CCCert中至少包含一份此类报告，则认定该证书是欺诈性的，并且该证书的所有签名者都会受到惩罚并销毁其抵押的存款。 k是一个安全参数，可以在创建侧链时进行调整。

如果由他签名的一些证书被认为是欺诈性的，验证人无法取回他的押金。

如果特定代可能包含多个跨链证书，则所有这些证书都要参与欺诈检测。

基本欺诈报告流程可以使用算法3的模型（另请参见图3.14）：

由于欺诈检测是来自侧链进行，并且是一个完全确定性过程，如果来自k个先前撤销代的证书是欺诈性的，则诚实方需要包括欺诈报告。否则，它本身也有了成欺诈性，应该通过下个诚实证书对它进行处罚。

---

算法3 欺诈报告流程

---

1：跨链证书由验证组在侧链SC中正确签名。

2：欺诈性证书是私人创建的，然后由验证组签名然后发送给主链MC。

3：欺诈性证书被打包到主链MC中的区块中。 它在主链中是有效的，因为它包含有效的聚合签名。 但主链不验证侧链证书的连续性。

4：欺诈性证书在侧链的区块中同步。

5：代i + 1的验证者将与进行比较，检测出差异,提交欺诈证书,并将其纳入中。

6：创建跨链证书，里面包含了的欺诈报告。

7：跨链证书由验证组在SC签名。

8：跨链证书被打包到主链MC的区块中。

9:  主链MC拒绝为所有为签过名的验证者提现。

图3.14：欺诈性证书和欺诈报告流程示例图

3.3.6 安全性

在都是理性行为假设下，能够证明：验证人的欺诈行为不会影响反向传输协议的安全性。 我们假定有一个串通好的欺诈验证组，他们共同签署了一个恶意证书，将硬币撤回到他们自己的地址而不是由侧链中的提现请求指定的地址。 惩罚系统使得这种攻击无利可图，因为作弊验证者将同时失去他们所抵押的存款。 由于每张证书的提款金额有限，并且做恶者需要至少有一半的验证人参与作弊，因此很容易看到更多的硬币将被没收而不是被做恶者骗取。

还可以证明，在假设大多数注册验证人都诚实者的情况下，对作弊验证者的惩罚实际上也是不可避免的。

对上述安全属性的严格数学分析，将在另一篇论文中发表。

3.4 Bootstrapping侧链

可以同时部署和运行多个侧链。 为了简化和标准化侧链部署过程，需要将侧链创建的特殊交易接入主链中。 这种交易使得主链有知道有侧链被创建、设置侧链的id及设置其它参数。

创建的交易结构如下：

CreateSidechainTx = {ledgerid,start_block,epoch_len, prep_len,cert_depo, cert_group_size, cert_f ee, min_transf er_amount, dispute_len}

其对应的含义如下：

ledgerid是尚未注册的侧链的唯一标身份;

start_block是主链上的第一个提现代区块的开始;

epoch_len是块中提现代的长度;

prep_len是提现代准备阶段的长度;

cert_depo是成为验证人需锁定存款的金额;

cert_group_size是验证单个跨链账本的验证组大小；

cert_fee是指将支付给验证人佣金费用的百分比;

min_transfer_amount是单次反向传输允许的最小传输量;

dispute_len是跨链账本证书的数量,这些证书可以报告特定的欺诈行为（在发生的代之后，从下一个提现代开始）。

多个参数供特定不同类型的侧链选择，提供了灵活性。 所提供参数可以有有不同的组合，可以在如：速度、效率和安全性之间选择一个折衷方案。

使用此协议，任何人都可以在Horizen上创建侧链。 侧链创建者自己承担布署费用（以燃烧代币的形式）。

一旦创建了侧链，就会确定性地定义提现代，并且可以处理正向/反向传输。 请注意，即使某些提现代没有跨链证书（由于没有验证者或其他原因），它不会影响主链进程，在未来也可能与侧链发生正常交互。 即使侧链因一些原因被暂停，在规定的时间表内，仍可以提现。

4.结论

在本文中，我们提出了基于股权证明POS原则的侧链结构。 我们的主要贡献是构建新的反向传输协议，该协议既不依赖于中心化的认证联盟，也不依赖于矿工/区块产生者。 相反，它依赖于系统中一组名为“验证者certifiers”的新角色。 我们还提供了可用于侧链的共识协议的描述，让其构架恰当结合。 我们的构架需要改变主链共识协议以用来整合对侧链的基本支持。 集成后，可以部署多条侧链。 主链需要仅跟踪特定侧链的验证者及其余额而无需跟踪侧链。 通常，所提出的构架为侧链支持提供了去中心化的开源协议。 它既可以集成到工作量证明POW的区块链，也能集成到股权证明POS的区块链中。

---

欢迎加入ZEN社区：

微信群：gyshiyi

知识星球：https://t.zsxq.com/7uNJaiI

电报群（VPN）：https://t.me/joinchat/F_PCzUZpS76NkG-E_Yz4hg

---

参考文献

[1]  On Scaling Decentralized Blockchains. In: Clark J., Meiklejohn S., Ryan P., Wallach D., Brenner M., Rohloff K. (eds). Financial Cryptography and Data Security. Vol. 9604. Lec- ture Notes in Computer Science, Springer, July 2016.

[2]  A. Back et al. Enabling blockchain innovations with pegged sidechains. https://blockstream. com/sidechains.pdf. 2014.

[3]  Cosmos network: https://cosmos.network/docs/. 2018.

[4]  J. Dilley et al. Strong federations: An interoperable blockchain solution to centralized third

party risks. https://blockstream.com/strong-federations.pdf. 2016.

[5]  E. Duffield and D. Diaz. Dash: A Payments-Focused Cryptocurrency. https : / / github .

com/dashpay/dash/wiki/Whitepaper. 2018.

[6]  Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform.

https://github.com/ethereum/wiki/wiki/White-Paper. 2018.

[7]  Juan Garay, Aggelos Kiayias, and Nikos Leonardos. The Bitcoin Backbone Protocol: Anal- ysis and Applications. Cryptology ePrint Archive, Report 2014/765. https://eprint. iacr.org/2014/765. 2014.

[8]  Horizen: https://horizen.global/. 2018.

[9]  A. Kiayias and D. Zindros. A Sidechain Protocol for Proof-of-Work Blockchains. Presenta- tion at Crypto.Sec. https://docs.google.com/presentation/d/1u_UhfDBV31DCFmnU- kcyUd47eZGNfrDJVQVQNlI4iwE/edit#slide=id.p. 25 July, 2018.

[10]  Aggelos Kiayias et al. Ouroboros: A provably secure proof-of-stake blockchain protocol. Ad- vances in Cryptology - CRYPTO 2017 - 37th Annual International Cryptology Conference. Part I, volume 10401 of LNCS, Springer. 2017.

[11]  S. Lerner. Drivechains, sidechains and hybrid 2-way peg designs. https://bravenewcoin. com / assets / Whitepapers / Drivechains - Sidechains - and - Hybrid - 2 - way - peg - Designs-R9.pdf. 2016.

[12]  Monero: https://monero.org. 2018.

[13]  Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. https://bitcoin.org/bitcoin.pdf. 2008.

[14]  J. Poon and V. Buterin. Plasma: Scalable Autonomous Smart Contracts. http://plasma.io/.

[15]  Rootstock: smart contracts on Bitcoin network. https://www.rsk.co/. 2018.

[16]  Nicholas Stifter et al. Agreement with Satoshi – On the Formalization of Nakamoto Consen- sus. Cryptology ePrint Archive, Report 2018/400. https://eprint.iacr.org/2018/400. 2018.

[17]  P. Sztorc. Drivechain - the simple two way peg, November 2015. http://www.truthcoin. info/blog/drivechain/.. 2015.

[18]  S. Thomas and E. Schwartz. A protocol for interledger payments. https://interledger. org/interledger.pdf. 2018.

[19]  Robert Viglione, Rolf Versluis, and Jane Lippencott. Zen White Paper. https://horizen. global/assets/files/Zen-White-Paper.pdf. 2018.

[20]  Gavin Wood. Polkadot: Vision for a heterogeneous multi-chain framework. https : / / polkadot.network/Polkadot-lightpaper.pdf. 2016.

[21]  ZCash: https://z.cash/. 2018.

[22]  Bingsheng Zhang, Roman Oliynykov, and Hamed Balogun. A Treasury System for Cryp- tocurrencies: Enabling Better Collaborative Intelligence. Cryptology ePrint Archive, Report 2018/435. https://eprint.iacr.org/2018/435. 2018.

Horizen侧链英文版白皮书：

https://www.horizen.global/assets/files/Horizen-Sidechains-Decoupled-Consensus-Between-Chains.pdf