Polkadot 系列（三）——如何实现共享安全性

关注
发布于: 2020 年 12 月 23 日
导读本文是Polkadot系列文第三篇。
说到Polkadot，估计大家听到它的最大的优点就是它给平行链提供的共享安全性，共享安全性保障了不因区块链网络分片而降低安全性。那么共享安全性到底是如何实现的呢？
本文主要从Polkadot为平行链提供的的有效性和可用性两个保障帮你深度理解共享安全性。
回顾首先还是先来回顾一下前文提及过的Polkadot四种角色：
﻿
验证人（Validators）
它是中继链全节点，中继链会在验证人池中通过随机分组把验证人指定给不同的平行链。验证人会接受来自收集人打包的区块并进行有效性验证，然后结合共识算法对收集人提交的区块进行确认。
﻿
收集人（Collators）
它是平行链的全节点，负责收集和执行平行链的交易并产生候选区块，将区块和证明提交给验证人，并通过收集交易获得手续费。收集人类似于PoW共识区块链当中的矿工。
﻿
提名人（Nominators）
Polkadot中数字货币DOT的持有人，它会选择自己所信任的验证人进行DOT质押，然后分享验证人的收益。
﻿
钓鱼人（Fishermen）
它也是平行链全节点，监控验证人的非法行为，若验证人作恶（如批准了无效的平行链区块），钓鱼者可以向其他验证人举报并获得相应报。
﻿
有效性验证有效性验证指的是区块链系统对账本状态变更的合法性校验，实现全网的共识。
一条普通的区块链，比如以太坊，每出一个区块，区块会广播到全网的以太坊节点，这些节点会对区块中的交易进行验证和执行，确保最后生成的状态根等信息和区块头中的信息一致。在Polkadot中，对平行链的区块共识需要进行以下三个级别的有效性验证：
﻿
第一级有效性验证由平行链的验证人实现，可以防止收集人作恶。
每隔一段时间（具体间隔时间由BABE共识算法确定），中继链会通过随机分组把验证人池中的验证人指定给不同的平行链，每个平行链会分配到多个验证人。
平行链区块上的收集人收集交易，产生区块B以后，将区块B、有效性证明和一些相关数据发送给当前平行链的验证人。这些平行链的验证人收到区块和数据后，验证区块，如果区块无效，忽略该块；如果区块有效，则将收到的内容分成多个部分，构造一棵默克尔树，然后将每一份内容、默克尔证明以及区块信息组合，进行签名并分发给其他验证人验证。
﻿
第二级有效性验证由钓鱼人保证，可以防止平行链验证人作恶以及平行链验证人和收集人联合作恶。
钓鱼人一般都是平行链的全节点。它首先需要在中继链上放置押金，然后持续从收集人节点收集区块，并验证有效性。如果区块中包含了无效交易，钓鱼人将提交报告。如果事实证明它的判断是正确的，它将获得丰厚的奖励，但如果它判断错误，它将失去自己的押金。
﻿
第三级有效性检查是非平行链验证人执行的。
这些验证人选择过程是非公开的，且验证人数量由钓鱼人给出的无效报告和收集人给出的不可用报告的数量确定。如果检测到无效的平行链区块，则为其签名的验证人将会受到惩罚，它的押金将会部分或全部扣除。
上面三个级别的有效性验证中，钓鱼人的有效性验证比较好理解，因为它本身就是平行链的全节点，拥有平行链的所有状态数据，只需将收到的区块交易重新执行一遍，便可以得到新的状态数据和状态根来验证区块的有效性。
可是验证人是中继链的全节点，它如何做到能够验证平行链的区块呢，难道它维护所有平行链的状态数据？这显然是不可能的。
﻿
下面就重点介绍一下
Polkadot验证人到底是如何验证平行链的区块的
﻿
平行链接入Polkadot时，需要向中继链注册一段web assembly代码，叫做STVF（State Transition Verification Function），验证人将用STVF对平行链有效性进行验证。
假设某个平行链PC上个已经确认的区块是B0，当前待出的区块是B1，上个区块经由中继链确认后，在中继链上区块R0B上记录了B0的相关信息，如该平行链执行完B0以后的状态根R0。之后平行链收集人C打包了区块B1，得到该区块的向其他平行链的跨链消息M，并生成有效性证明π以及一些元数据(PC.id, H(B0), H(R0B), Rin, Rout, . . .)。这里的Rin是区块B1执行之前的平行链的状态根，Rout是执行以后的状态根，H(B0)表示平行链区块B0的哈希，H(R0B)表示中继链区块R0B的哈希。
生成有效性证明的过程实质就是执行区块中的交易，将执行过程中读写的状态数据记录下来，并结合区块执行前后的两个状态根生成证明。
﻿
如果使用*xz表示组成默克尔根x中的叶子z的SPV证明，那么区块B有效性证明数据就可以如下表示：
πB = U {*Rinx | B reads x } ∪ {*Routx | B writes x }
﻿
举个例子，假设平行链提交的区块B中包含两笔交易：
1.    A给B转账50
2.    C给D转账10
执行过程中需要读写A、B、C、D四个账户的状态。假设区块执行之前该平行链中这四个账户的余额都是100，那么有效性证明包含的便是下面两张图中标有颜色的这些数据，其中黄色部分是哈希值。
﻿
﻿
﻿
可以看到，不管平行链本身的状态数据有多少，由于区块的有效性证明数据都是由该区块的交易涉及的状态读写集的SPV组成，因此它的大小是有限的。
﻿
之后收集人C将区块B1、交易的有效性证明π、该平行链的出队列中的消息集合M以及元数据一起发给其中一个验证人，验证人再将这些信息分发给这条平行链的其他验证人。每个验证人加载该平行链的STVF对收到的平行链区块进行有效性验证。
﻿
STVF的核心也是执行平行链区块中的交易，过程中需要读取证明数据中的读集合，同时会产生写集合，并最后生成的写集合和证明数据中的内容进行比对；此外还可以通过收到的元数据中的信息进行一些其他的验证，如根据H(R0B)查找到该区块中保存的B0的状态根R0，将R0和收到的Rin进行比较。若这些信息都符合，则该区块通过验证。
﻿
最初收到平行链区块的那个验证人将生成一个Candidate Receipt，里面会记录该平行链区块B1相关的信息，如平行链PC的id、收集人C的id、区块B1的哈希、区块B1执行前后的状态根等，签名并广播给中继链所有节点（可以认为这是中继链的交易）。当这个Candidate Receipt最终被中继链出块确认以后，平行链PC的区块B也被最终确认了。
﻿
这种有效性验证方法可以保证平行链单个区块的状态转换是有效。如果平行链从第一个区块开始，都由中继链进行有效性验证并确认区块，那么可以保证平行链整条链的有效性。
﻿
可用性保障可用性保障指的是区块链系统在部分节点作恶的情况下，依然可以对业务系统提供可用服务保障。
﻿
在Polkadot中，假设这么一种场景：平行链收集人打包了区块B并提交给了验证人，验证人收到了该区块，通过了有效性验证，并且区块最终被中继链确认了。
﻿
但是该收集人节点作恶，没有把区块广播给平行链的其他节点，那么该平行链的其他节点无法得到该区块，无法更新本地的状态数据，该平行链也就无法出块了。
﻿
为了防止这种情况发生，通过验证以后，验证人会将平行链区块PC和有效性证明通过纠删码技术分成n个片段（n的数量是全网验证人的数量），并将这些片段广播给全网的所有验证人，每个验证人获得一个片段并会保存一段时间。
﻿
之后只需要得到n/3的片段，便可以恢复出原始数据。这种情况下，即使收集人节点作恶，平行链其他节点依然可以从中继链的验证人中获得上个区块的纠删码片段并恢复出区块。
总结通过上面对Polkadot有效性和可用性的介绍可以看到，中继链提供了种种措施来保障平行链的安全：随机分配的平行链验证人进行区块的验证、钓鱼人的监督、非平行链验证人的再次验证、中继链对平行链区块数据的备份……。
﻿
这种设计方式在保障整个区块链系统横向扩容分片的过程中不会降低某单一分片的安全性。对平行链来说，它享受了中继链提供的安全性，仅需安心关注自己的区块链业务即可，极大便利了区块链业务的开发，降低了单一平行链对安全的额外投入。
﻿
参考文献：
﻿
[1]     Availability and Validity,
https://research.web3.foundation/en/latest/polkadot/Availability_and_Validity.html
[2]    The Path of a Parachain Block，
https://polkadot.network/the-path-of-a-parachain-block/
[3]   J. Burdges, A. Cevallos, P. Czaban, R. Habermeier, S. Hosseini, F. Lama, H. K. Alper, X. Luo, F. Shirazi, A. Stewart, and G. Wood. Overview of polkadot and its design considerations. arXiv preprint arXiv:2005.13456, 2020.
﻿
本文作者
周蓉，江哲 
来自趣链科技数据网格实验室BitXHub团队，主要负责区块链账本互操作技术相关研究工作。
﻿