区块链的自定义解决方案PVRB的优缺点介绍

介绍

与许多密码概念一样，“公开可验证的随机信标”协议（简称PVRB）只是一种趋近理想的方案。但理想的方案并不适用于真实的网络：应该就轮中的唯一“位”、轮的数量以及必须快速且始终交付的网络消息达成共识。但对于真实的网络却不是这样。现代区块链的自定义PVRB解决方案开发涉及许多技术问题，因此无法控制随机数生成和加密算法的强度。

区块链本身是PVRB的通信媒介，其中消息=交易。现在，我们可以忘记网络问题、消息未交付问题以及中间软件问题——所有这些风险都由分散式网络来处理。PVRB不能回滚或破坏已发送的交易 ，而且参与者不能拒绝参与协议，除非他们成功地攻击了网络共识。由于安全级别是可以接受的，所以PVRB必须与区块链的主链一样，抵抗参与者之间的共谋。有迹象表明，PVRB应该成为共识的一部分;如果网络同意主链，它也应该同意正确的产生随机数。否则，PVRB只是一个由智能合约支持的独立协议。这两种方法各有利弊，在两者之间做出选择是相当困难的。

实现PVRB的两种方法

我们将更详细地描述两个选项：基于区块链独立智能合约的独立版本，以及嵌入协议的共识集成版本。对于每种情况，我将参考流行的区块链：Ethereum、EOS，以及那些具有类似存储和处理智能合约方法的区块链。

独立合约

这里PVRB是一个智能合约，它接受来自随机生产者（以下简称RP）的交易，处理它们，组合结果，并最终生成任何合约用户都可以接收的一些值。此值可能不会直接存储在合约中，但具有数据表示形式，因此允许确定产生随机性的惟一值。在该方案中，RP是区块链用户，任何人都可以参与生成过程。

独立合约选项看起来不错，因为：

· 可移植性（合约可以在区块链之间“拖动”）

· 易于实现和测试（编写和测试合约很方便）

· 方便的经济方案（使用特定于PVRB的逻辑很容易创建自己的代币）

· 适用于区块链中工作

它也有缺点：

· 对消耗的计算资源的严格限制：交易复杂性、容量、网络速度和区块链存储（换句话说，是传统的cpu/mem/io/存储）

· 存在内部合约机指令的限制（并非所有指令都可用，很难连接外部库）

· 消息传递的速度不能超过区块链中包含的交易的速度

如果我们想在现有的网络中运行PVRB，而该网络不包含复杂的加密技术，也不需要大量的交互，那么这个选项是合适的。

共识一体化选择

这里PVRB嵌入到区块链节点代码中，或者与区块链节点消息传递并行工作。协议结果直接写入产生的块中，而协议消息在节点之间通过p2p网络发送。由于协议的数值结果需要用块来编写，因此网络必须对它们达成一致。这意味着PVRB消息和交易必须由节点进行验证，并包含在块中（以便网络中的任何成员都可以验证是否符合PVRB协议）。这自动将我们引向一个显而易见的解决方案——如果网络在一个块及其交易上达成共识，那么PVRB应该是共识的一部分，而不是一个独立的协议。否则，该块在协商共识方面是有效的，但是由于没有遵循PVRB协议，因此不能接受该块。因此，如果选择“共识整合”选项，PVRB将成为共识的重要组成部分。

在网络共识级别上讨论PVRB实现时，无论如何都不能避免终结性问题。终结性是确定性共识中使用的一种机制，它修复了一个“最终确定”的块（以及指向它的链），即使在并行分叉的情况下，这个块也不会被丢弃。如果你发布一条更复杂的链，它将取代任何其他更简单的链，而不用管链的“年龄”和长度。例如，在EOS中，有所谓的最后不可逆块被认为是最终确定的。它们平均每432个块出现一次（12*21（预投票）+ 12*15（预提交））。而比上一个库更老的分支将被简单地丢弃。该机制保证交易包含在区块链中，并且永远不会回滚。开发一个协议来确保最终结果作为一个一致的外接程序是有意义的，因为它能够与块生产和发布异步工作。

当BP持有这些区块，并在网络看到一笔不错的交易后发布它们时，对于那些可能成为“双倍支出”攻击受害者的用户来说，最终结果至关重要。PVRB有更严格的终结性要求，因为分叉构造意味着攻击者可以准备几个随机数选项并发布最有益的一个。因此，限制可能的攻击时间是一个很好的解决方案。

因此，最好的选择是将PVRB和终结性结合在一个协议中—那么最终确定的块将等于最终确定的随机数—这正是我们的目标。从现在开始，玩家将在N秒内得到一个保证的随机数，并确保不可能将其回滚或重放。

共识一致选项看起来不错：

· 与块生产相关的可能的异步实现——块像往常一样生成，但是PVRB协议可以并行工作，并为每个块生成随机数

· 能够实现即使是复杂的密码学，没有智能合约的限制

· 能够比区块链中包含的交易更快地组织消息传递，例如，协议的一部分可以在没有网络交互的节点之间工作

它也有缺点：

· 测试和开发中的困难—您将不得不模拟错误网络、丢失的节点和网络硬分叉

· 实现错误需要一个网络硬分叉

这两种实现PVRB的方法都是可以接受的，但是现代区块链中的智能合约在计算资源方面仍然非常有限，这使得一般的密码学几乎不可能实现。但是这种情况一年比一年好。我们可以以以太坊中zksnark的预编译系统合约为例。

提供透明可靠的协议消息传递通道并不是免费的。任何分散协议都必须考虑到可能发生的西比尔（ Sybil）攻击，任何行动都可以通过多个帐户进行协调。在开发过程中，请记住攻击者能够从任意数量的协议参与者中创建共谋。

PVRB和块变量

我并没有撒谎说 （到2019年春季） 还没有人在区块链中实施一个好的、强大的 PVRB， 并在赌博应用中进行了测试。以太坊和 EOS 中的这些赌博应用申请来自何方？我和你一样惊讶： 在完全确定的环境中， 怎么会有这么多 “强” 随机数呢？

我最喜欢的在区块链中获取随机数的方法是从块中获取一些“不可预测”的信息，并在其基础上生成一个随机数。您还可以选择块中的任何其他“不可预测”值，例如，块哈希值、大量交易、网络复杂性和其他未知值。您甚至可以在白皮书中写道，您的方案是“后量子安全的”（因为存在防量子哈希值函数：）。

唉，即使是后量子安全的哈希值也不够。秘诀在于PVRB的要求，我将引用上一篇文章：

1. 结果应该具有可证明的均匀分布，即基于强密码学。

2. 控制任何一点结果都是不可能的。

3. 不参与协议或用攻击消息重载网络来破坏生成协议是不可能的。

4. 上面所述的一切都应抵制一定数量的不诚实的协议参与者（例如1/3的参与者）串通一气。

在这种情况下，只需满足第一个需求。通过哈希不可预测的块值，我们将得到一个均匀分布和正确的随机数。BP至少能够决定是否“验证一个块”，并从两个随机变量中进行选择的问题。BP可以作弊，保留一个块来看看接下来会发生什么，然后决定是否发布它。因此，以“偶数-奇数”或“红/黑”轮盘赌为例，他只能在获利的情况下发布一个区块。使用未来块的参数也没有什么意义。在这种情况下，他们说“通过哈希当前数据和一个高度为N+42的未来块获得随机性，其中N是当前块高度”。这稍微加强了该方案，但是BP仍然可以选择是否持有或发布区块。

在块生成软件中执行这样的攻击并不复杂。在验证和包含一个块中的交易时，会有一个快速检查通道，以查看是否会有收益，并可能选择一个交易参数来增加获胜概率。与此同时，发现一个聪明的BP来执行这样的操作几乎是不可能的，因为每次他都可以使用新的地址，并在不引起怀疑的情况下一点一点地获胜。

因此，基于块数据的方法不适用于通用PVRB实现。在一个简短的版本中，限制了赌注大小、玩家数量或KYC注册（为了禁止玩家使用多个地址），这些方案只适用于小型游戏。

PVRB和commit-reveal

好吧， 至少我们有哈希值， 一个 “几乎不可预测” 的块哈希值。如果我们设法解决领先矿工的问题， 我们可能会得到更有价值的东西。让我们将用户添加到此方案中， 并允许他们影响随机性结果： 任何技术支持员工都会告诉您， IT 系统中最随机的问题是用户操作：）

在这种方案中，用户只需发送随机数，然后通过哈希他们的共同产品计算结果。在这种情况下，最后一个玩家可以选择自己的随机数来控制结果。这就是为什么最好使用众所周知的commit-reveal模式。首先，参与者发送他们的随机数的哈希值，然后提交原始随机数。一旦收集了所有必要的提交，“reveal”阶段就开始了，也就是说，参与者只能发送之前提交的哈希值随机数。现在我们将添加块参数—最好使用将来的块参数，因为随机数只出现在下一个块中。现在任何玩家都可以影响结果的随机性，并能够“击败”一个恶意的BP，用它自己不可预测的随机性来阻止它……您还可以通过为“提交”请求一些交易费用来提高协议安全性。

这是一个很好的尝试（类似的方案也在不同的DApps中使用）。唉，这还不够。现在，不仅矿工可以影响结果，协议的任何参与者也可以。

至少我们有机会惩罚那些提交了却而没有显示的人，这个方案稍后会有用。此外，它的简单性也是一个重要的优势，因为更重要的协议需要更多的计算。

PVRB和确定性签名

确定性签名是使RP生成伪随机数的另一种好方法，它不会影响伪随机数。例如，RSA签名就是其中之一，而ECS（椭圆曲线签名）则不是。如果RP有一对密钥（RSA和ECS），并且他使用自己的私钥对一些值进行签名，RSA允许生成一个惟一的签名，而ECS允许生成任意数量的有效签名。在创建ECS签名时，签名者可以随意选择一个随机数，从而有机会从多个签名中选择一个。RSA是 “一个输入值”+“一个密钥对”=“一个签名”。要预测另一个RP的签名是不可能的，因此具有确定性签名的PVRB可以通过组合多个已签名相同值的参与者的RSA签名来构建，例如前面的随机数。这种方案节省了大量资源，因为签名既是正确协议行为的确认，也是随机性的来源。

然而，确定性签名并不是万能的，而且该方案仍然容易受到“最后一个参与者”问题的影响。最后一个参与者仍然可以决定是否发布签名，从而控制结果。此外，RSA密钥可以很长（1024和2048位），这对于区块链交易来说是一个非常重要的参数。显然，没有简单的方法来解决这个问题。

PVRB和秘密共享方案

有一些加密方案允许网络协商一个惟一的PVRB值，同时保持对某些参与者的任何恶意行为的抵抗。其中一个有用的协议是Shamir的秘密共享。它将一些秘密（例如，一个秘密密钥）划分为几个部分，并将这些部分分发给N个参与者。这个秘密的分布方式是，从N到M个部分足够恢复它，这些可以是任意M个部分。简单地说，有一个未知函数的图，参与者在图上交换点，得到M个点后，整个函数就可以恢复（线性函数需要2个点，二次函数需要3个点，等等）。

wiki提供了一个很好的解释;您还可以在这个演示页面上以实时模式试用该协议。

如果FSSS （Fiat-Shamir秘密共享）方案能够以其单纯的形式应用，PVRB将是无懈可击的。在其最简单的形式中，协议可能是这样的：

· 每个参与者生成一个随机数，并将其份额分配给其他人

· 每个参与者都揭示了其他参与者的秘密

· 如果一个参与者收集了更多的m点，他的数字可以计算出来。无论“显示”的参与者集是什么，这个数字都是惟一的

· 所需的PVRB是显示的随机数的组合

因此，考虑到有必要数量的可靠RP遵循规则，该协议按照严格的密码学要求工作，并保持对“最后一个参与者”问题的抵抗力。

这可能是一个理想的选择。例如，本文描述了基于Fiat-Shamir秘密共享的PVRB方案。正如我前面提到的，如果您试图将其应用到区块链的单纯形式中，技术限制将不可避免地出现。下面是EOS 智能合约中协议测试实现的一个示例，其中最重要的部分是检查参与者已发布的共享：代码。很明显，证明验证需要多次标量乘法，而且数字非常大。同时，我们应该记住，在区块链中，当区块生产者处理事交易时，会调用verify函数。一般来说，任何参与者都应该很容易地验证协议的正确性，这就是为什么对“verify（）”函数的速度要求非常严格的原因。我们的方案没有成功，因为验证没有满足交易时间限制（0.5秒）。

验证效率是区块链中任何高级密码方案最重要的要求之一。证明和消息创建可以脱离链，由高性能计算机完成，但是不能忽略验证——这是PVRB的另一个重要要求。

PVRB和阈值签名

秘密共享方案打开了在“阈值”保护伞下统一的一类协议。他们允许处理“最后的参与者”的问题：如果攻击者不透露秘密的一部分，另一个诚实的参与者会相反。反过来，这使我们能够就唯一的意义达成一致，即使一些参与者正在破坏协议。

结合确定性签名和阈值方案，我们得到了一个非常方便和有前途的PVRB方案-确定性阈值签名。

上一篇文章讨论了BLS的公共签名和私有签名以及密钥，现在可以使用简单的数学操作组合它们——这对开发人员来说非常方便。组合仍然是有效的密匙和签名，这使得将多个签名聚合为一个密匙和多个公钥聚合为一个密匙变得很容易。它们的决定论允许获得具有相同输入数据的相同结果。由于这种特性，BLS签名组合成为有效的密钥，这使得M个诚实的参与者（从N个总数到M个总数）有可能生成唯一的确定性、公共可验证性和不可预测的签名，直到M个参与者披露为止。

在BLS阈值签名方案中，每个参与者都使用BLS（例如前面的随机数）签名，并将其份额发送给区块链。BLS签名的密码特性满足随机性质量要求，因为阈值部分防止“最后的参与者”，而密钥的独特兼容性允许使用许多有趣的算法（例如，有效聚合协议消息的算法）。

因此，如果您正在为您的区块链在2019年春夏构建PVRB，您很可能会遇到BLS阈值签名方案;一些项目已经在使用它。例如，DFinity是一个实现该方案的基准测试工具， Keep.network是一个为协议提供服务的智能合约示例。

实现PVRB

遗憾的是，目前还没有真正的强密码PVRB区块链协议，这证明了它在真实的DApps中的安全性和稳定性。尽管现有协议是现成的，但是将它们应用于现有解决方案并不容易。PVRB对于集中式系统毫无用处，而分散式系统的计算资源非常有限：CPU、内存、存储、I/O。开发PVRB涉及到不同协议的组合，以便它能够匹配至少一个真正可行的区块链。

我将列出您在选择高品质PVRB时必须考虑的因素：

1. 它应该是强加密的，即严格不可偏置的，不能给任何人控制。对于某些方案，情况并非如此，因此最好向密码编写者寻址。

2. “最后一个参与者”问题。当控制一个或多个RP的攻击者可以在两种可能的结果中进行选择时，PVRB必须能够抵抗攻击。

3. 协议破坏。当控制一个或多个RP的攻击者决定是否生成随机数时，您的PVRB必须能够抵抗攻击，并且能够影响随机信标的生成。

4. 消息数量。您的RP应该向区块链发送最少数量的消息，并尽可能避免同步操作，比如“发送信息，等待特定参与者的响应”。您不应该期望p2p网络中的快速响应，尤其是来自地理分布的网络。

5. 计算的复杂性。任何PVRB阶段的链上验证都应该很容易，因为它是由所有完整的网络客户机执行的。在智能合约执行的情况下，速度要求是非常严格的。

6. 可访问性和灵活性。您的PVRB应该对可能的网络故障具有弹性（例如，当它在一段时间内不可用，并且部分RPs停止工作时）。

7. 可信设置和初始密钥分发。如果PVRB涉及主协议设置，则可能会导致某些问题。这里举一个例子：如果参与者必须在开始协议之前告诉对方他们的密钥，这也是一个问题，因为参与者的列表可能会改变。

8. 发展问题。所需语言的库的可用性、它们的安全性和性能、公共可访问性、复杂的测试等等。

例如，阈值BLS签名有一个显著的瓶颈——在开始之前，参与者必须共享密钥并组织阈值组。这意味着我们将不得不在一个分散式网络中跳过至少一轮，并且，由于随机数对于实时模式下的游戏来说是必不可少的，因此存在着很高的协议破坏风险，而阈值方案的优点将变得毫无用处。这个问题比之前的问题要简单，但是我们仍然需要开发一个单独的阈值组程序，它必须通过对不遵守协议的参与者的存款和资金提取（削减）来得到经济上的保护。合约代码由虚拟机WebAssembly或EVM执行。密码函数尚未在本地实现，并且比普通密码库慢很多倍。许多协议根本不满足密钥长度要求：例如，RSA的1024位和2048位。这是标准比特币和以太坊交易签名大小的4-8倍。

还应该使用不同的编程语言实现，这种语言并不多，尤其是对于新协议而言。为了将PVRB集成到共识中，我们应该用平台语言编写代码，即查找用于geth的Go代码、Parity的Rust代码和用于EOS的c++代码。JavaScript代码更难找到，而且由于JavaScript和密码学关系并不密切，所以选择WebAssembly。它看起来将成为下一个重要的互联网标准。

结论

我希望在上一篇文章中，我成功地说服了您，区块链中的随机数生成对于分散式网络的许多方面都是至关重要的。今天我已经表明，这项任务是极其艰巨的，但也有一些很好的解决办法。说实话，协议体系结构只有在进行了涉及从设置到故障模拟各个方面的大规模测试之后才会被认为是最终的。你不太可能在白皮书或文章中找到现成的解决方案。我们也不能建议该做什么。至少在最近的几年是这种情况。

到目前为止，在Haya区块链中开发我们的PVRB时，我们已经选择了阈值BLS签名，并计划在共识级别上实现PVRB，因为智能合约不允许体面的安全验证。我们可以同时使用两种方案：首先，一个昂贵的秘密共享来创建一个长期的种子值，它将作为具有确定性阈值BLS签名的高频随机数生成的基础。我们还可以把自己限制在其中一个计划之内。不可能预先说协议是什么样子的，然而，一个负面的结果也是一个结果，每一次解决问题的新尝试对参与研究的每个人来说都是另一个步骤。为了满足业务需求，我们正在处理一个特定的实际问题——为游戏应用程序提供一个可靠的熵源，因此我们还必须关注区块链，特别是终结性问题和网络治理问题。

目前，还没有经过验证的PVRB可以被长期使用;然而，许多可能的解决方案证明了还是有出路的，最终会有算法来解决这个问题。我们将乐于分享结果，并感谢其他团队提供的文章和代码，使开发人员不会犯同样的错误。