因为有些情况非常严重，我们希望可以很简单地从没收的押金里支付奖金。我们通常倾向于使用烧毁代币的方法进行重分配，而不是采用批量转账的方法。烧币可以从整体上增加代币的价值，也就可以补偿整个网络而不仅是涉及到的特定几方。这主要是作为安全防范机制，只有非常恶劣的行为才会到会非常大金额的惩罚。

很重要的一点是奖金必须足够高才能让网络觉得验证工作是值得做的，当然也不能比成本高太多，否则会招致那些足够有钱的、精心策划的国际级别的犯罪黑客攻击那些不幸的验证人，迫使他们做出非法行为。

规定的奖金也不能比恶意验证人的押金高太多，否则会不正当地激励非法行为：验证人为了奖金自己举报自己。解决方法是要么直接限制成为一个验证人的最小押金量，要么间接教育提名人：如果验证人押金太少，他们可能没有足够的动机来遵守规则。

6.3 平行链的注册

这个模块用于记录系统中的每个平行链。它是个相对简单的类似数据库的结构，管理着每条链的静态信息和动态信息。

静态信息包括链的索引(一个整数)和验证协议的标识。协议标识用于区分不同的平行链，只有这样，验证人才能运行正确的验证算法，然后提交合法的候选块。一个最初的概念验证版本会关注于如何把一个新的验证算法放在客户端中，这样每增加一个新种类的区块链，就需要一次硬分叉。然而在保证严格和高效的情况下，还是有可能不用通过硬分叉就能让验证人知晓新验证算法。一个可能的实现方法就是用一种确定的、本地编译的、平台无关的语言来描述平行链的验证算法，例如WebAssembly等。为了验证这种方法的可行性，我们还要做更多的调查，毕竟如果能够避免硬分叉还是会有很大优势的。

动态信息涉及交易路由系统，比如必须对平行链的的入口队列进行全局共识(在下一节讨论)。

必须通过全民公投才能注册新的平行链。这本来可以直接内部管理，但通过一个外部的全民公投合约会更好，因为这个合约还可以用于更多其他场景的治理。关于平行链投票注册系统的具体参数(例如法定人数、多数派的比例)会用形式化证明做成一个不常更新的“主宪法”系统，当然初始阶段也可能只是用传统的方法。具体的公式不在本文的讨论范围内，例如占2/3的多数派通过，并且全系统1/3的代币都参与了投票才算通过。

还有一些暂停和删除平行链的操作。我们希望永远不要暂停一个平行链，但这个设计是为了能应对平行链的一些紧急情况。最明显的情况是由于验证人运行了平行链的多种客户端实现，导致可能无法对某区块达成共识。我们也鼓励验证人使用多种客户端实现，以便能尽早检测到这类事情，防止押金被扣减。

因为暂停操作是个紧急措施，所以会采用验证人动态投票的方式，而不是通过全民公投。对于重启操作，可能直接通过验证人投票，也可能通过全民公投来完成。

删除操作平行链只能通过全民公投来进行，而且要提供一个宽松的平滑退出过渡期，能让它们成为一个独立的区块链或变成其他共识系统的一部分。这个期限可能是几个月，而且最好由平行链根据自身的需求来制定。

6.4 打包中继链区块

区块打包的过程本质上是共识的过程，也是把基本的数据变得有意义的过程。在一个PoW链里，打包有一个同义词叫挖矿。在本方案里，它涉及收集验证人对于区块有效性、可用性、一致性的签名，这些区块包括中继链区块和它所包含的全部平行链的区块。

底层的BFT共识算法也不是当前的工作范围。我们不描述它，而是使用一种原语描述一种由共识推动的状态机。最终我们希望能受到一些现有共识算法的启发：Tangaora(Raft的BFT变体)、Tendermint和HoneyBadgerBFT。共识算法需要并发地对多条平行链达成共识。假设一旦共识达成，我们就可以不可辩驳地记录哪些人参与了其中。我们也可以在协议内把不正当行为的人缩小到一个小组中，里面仅包含哪些恶意参与者，这样就可以在惩罚时可以降低附带伤害。

以签名声明形式存在的这些证明、中继链的状态树根和交易树根一起存储在中继链的块头里。

对于中继链区块和平行链区块的打包过程是在同一个共识生成机制中，两类块共同组成了中继链的内容：平行链并不是由他们的小组隔离地进行“提交”之后再被收集的。这虽然导致中继链的流程更加复杂，但也让我们可以在一个阶段里就完成整个系统的共识，能够将延迟最小化，并且能支持更加复杂的数据可用性，这在路由流程中将会很有用。

可以用一个简单的表格(二维的)来建模每个参与方的共识机。每个参与方都有一系列以签名形式存在的来源于其他参与方的信息，描述着每个平行链的候选块和中继链的候选块。这些信息有两部分数据：

可用性：对于出口队列里这个块的已提交交易，验证人是否有足够的信息才能在下一个块正确地验证平行链的候选块?他们可以投1(知道)或0(不确定)。当他们投了1，他们就承诺在后续的投票中也要这么投票。后面的投票和这个不对应会导致惩罚。

有效性：平行链的区块是否有效，是否包含了引用的所有的外部数据(比如交易)?这和验证人对平行链的投票相关。他们可以投1(有效)、-1(无效)或0(不确定)。只要他们投了非0，他们就承诺在后续的投票中也要这么投票。后面的投票和这个不对应会导致惩罚。

所有验证人都必须投票;在上面的规则限制下，还可以重新提交投票。共识流程可以像很多标准BFT共识算法那样来建模，每个平行链是并行的。除了有很小的概率把少数恶意参与者都被分配到了同一个平行链小组之外，共识算法在整体上还是能支撑网络，最坏的情况也不过只是出现一个或多个平行链因空块而死锁的情况(还有一个回合做出惩罚)

判断一个独立区块是否有效的基本规则(允许全部的验证人作为一个整体达成共识，然后这些平行链区块就成为中继链上具有一致性的数据引用)：

需要有至少三分之二的验证人投票“是”，并且没人投“否”。

需要超过三分之一的验证人对出口队列消息的可用性与否投票“是”。

对于有效性而言，如果至少有一个“是”且至少有一个“否”投票，一个特殊的条件就开启了，整个验证人就必须投票决定是否有恶意参与者，或者是否产生了意外的分叉。除了有效和无效之外，还支持投第三种票，等效于同时投了“是”和“否”，表示这个节点有相互冲突的意见。这可能是因为节点所有者运行的多种客户端实现而产生了分歧，也预示着平行链协议可能存在不清楚的地方。

当所有验证人的票都被记录过后，发现赢的那个意见少于一定数量的票(详细参数最多可能是一半，也许更少)，那就可以假设平行链发生了意外的硬分叉，这个平行链的共识就会被自动暂停。否则，我们假设就是有恶意行为发生，并惩罚那些给输的那个意见投了“是”票的验证人。

结论是只有足够的签名票数才能达成一致性，然后中继链的区块就打包完成了，开始打包下一个区块。

6.5 中继链区块打包的改进

打包区块的方法确保着系统的正常运行，因为每条平行链的关键信息都要由超过三分之一的验证人来保证可用性，所以它并不能很好地伸缩。这意味着随着更多平行链的增加，每个验证人的工作也会增加。

在开放的共识网络中，如何保证数据的可用性还是个有待解决的问题，然而还是有一些方法可以缓解验证人节点的性能瓶颈。一个简单的方案是：其实验证人们只是负责验证数据的可用性，那他们就没必要自己真正地存储、通信和复制数据。第二个方案是数据隔离，这个方案很可能和收集人如何组织数据相关，网络可以对收集人有一定的利息或收入激励，让他们保证提供给验证人的数据是可用的。

然而，这个方案也许可以带来一点伸缩性，但仍没有解决根本问题。因为添加更多平行链通常需要增加验证人，网络资源的消耗(主要是带宽)以链总数的平方的速度增长，长期来看这是不可持续的。

最终，我们可能会思考对于保证共识网络安全的根本限制，网络对带宽的需求增长速度是验证人数乘以消息总进入数。我们不能信任那些将数据分开在不同节点存储的共识网络，因为这会将数据和运算分离。

6.5.1 延迟性介绍

简化这个规则的方法是先了解即时性的概念。33%+1的验证人最终(eventually)需要对数据的有效性进行投票，而不是立刻(immediately)投票，我们可以更好地利用数据指数级传播的特性，来帮助应对数据通信的峰值。一个合理的等式(尽管未证明)：

(1) 延迟 = 验证人数 * 区块链数

在目前的模型下，系统的规模只有随着链的个数而伸缩，才能保证数据的分布式运算;因为每个链至少需要一个验证人，对于可用性投票的复杂度，我们把它降到了只和验证人个数呈线性关系。现在验证人数可以和链个数同样增长了，我们终结了：

(2) 延迟 = 数量2

这意味着随着系统增长，网络内带宽和延迟性的增长是可知的，但达到最终确定性所需的区块数目仍然是以平方增长。这个问题将会继续困扰我们，也可能迫使我们打造一个“非平层”(non-flat)的架构，也就是会有很多按层级结构排列的Polkadot链，通过一个树形的结构来路由消息。

6.5.2 公众参与

微意见(micro-complaints)系统是一种可以促进公众参与的方式。可以有一些类似于钓鱼人的外部参与方来监管验证人。他们的任务是找到提供了非可用数据的验证人。他们可以给其他的验证人提交一个微意见。这个方案需要用PoW或押金机制来防止女巫攻击，否则它会让整个系统失效。

6.5.3 可用性保证人

最终的一个方案是从验证人里提名出第二个小组作为可用性保证人(Availability Guarantors)。他们也需要和普通验证人那样交押金，而且有可能来源于同一个组(会在一个长周期里选择他们，至少也是一个会话)。和普通验证人不同的是，他们不需要在各条平行链间切换，而只需要形成一个单一的小组，监管所有重要跨链数据的可用性。

这个方案还有个优势是能缓解验证人数和链个数之间的等式关系。链个数可以最终增长(与原始链的验证人小组一起)，然而各参与方仍可以保持次线性增长或常量增长，尤其是那些参与数据可用性验证的人。

6.5.4 收集人设置

系统需要保证的一个重要方面是：合理地选择那些制造平行链区块的收集人。如果一条平行链由某个收集人控制了，那么外部数据是否可用就会变得不那么明显，这个人就可以比较简单地发动攻击。

为了尽可能地广泛分配收集人，我们可以用伪随机的方法来人工衡量平行链区块的权重。在第一个示例中，我们希望验证人倾向于选择权重更大的候选块，这是共识机制的一个重要部分。我们也必须激励验证人找到最大权重的候选块，验证人可以把他们的奖励按比例分配给这些候选块。

在共识系统里，为了确保收集人的区块被选中的机会是平等的，我们用一个连接所有收集人的随机数生成器来决定每个候选块的权重。例如用收集人的地址和一些密码学安全的伪随机数做异或(XOR)运算来决定最优的块(获胜票)。这给了每个收集人(更准确地说是每个收集人地址)随机公平地打败别人的机会。

验证人通过女巫攻击来生成一个最接近于获胜票的地址，为了阻止这种情况，我们会给收集人的地址加上一些惰性。一个很简单的方法是需要他们的地址有基本的余额，另一个更优雅的方式是综合考虑地址的余额来计算获胜的概率。这里还没有完成建模，我们很可能会让很少余额的人也可以成为收集人。

6.5.5 区块超重

如果一个验证人集合被攻击了，他们可能会生成一个虽然有效但要花费大量时间来执行的区块。这个问题来源于一些特定的难解数据题，比如大质数因式分解难题等，验证人小组可能需要非常长的时间才能解出答案，如果有人知道一些捷径，他们的候选块就有巨大的获胜优势。如果一个收集人知道那个信息，而其他人都在忙着计算老的块，那么他就有很大的优势让他的候选块获胜。我们称这种叫超重(overweight)块。

为了防止验证人提交这些大幅超出普通区块的超重块，我们需要添加一些警告：因为执行一个区块要花费的时间是相对的(根据它超重的程度)，所以最终可能的投票结果会有三种：第一种是这个区块绝对没有超重，超过2/3的验证人声明他们可以在一定时间内算完(例如出块时间的50%);另一种是这个区块绝对超重了，超过2/3的验证人声明他们无法在限定的时间内执行完这个区块;再一种就是意见分歧基本持平，这种情况下我们会做一些惩罚。

为了保证验证人能预测他们提交的区块是否超重，他们可能需要公布自己在每个块上的执行表现。经过一段时间后，他们就可以通过和其他节点的比较来评估自己处理器的性能。

6.5.6 收集人保险

还有一个问题留给了验证人：为了检查收集人区块的有效性，他们不能像PoW网络那样，而是必须自己计算里面的交易。恶意收集人可以填充非法或超重的区块给验证人，通过让他们受害(浪费他们的资源)来获取大量的潜在机会成本。