随机数和分布式互联网:推行

时间:2021-07-20 22:32       来源: www.mengmengshop.com

出处:区块网

介绍

与很多密码定义一样,“公开可验证的随机信标”协议只不过一种趋近理想的策略。但理想的策略并不适用于真实的互联网:应该就轮中的唯一“位”、轮的数目与需要迅速且一直出货的互联网消息达成协议。但对于真实的互联网却不是如此。现代区块链的自概念PVRB解决方法开发涉及很多技术问题,因此没办法控制随机数生成和加密算法的强度。

区块链本身是PVRB的通信媒介,其中消息=买卖。目前,大家可以忘记互联网问题、消息未出货问题与中间软件问题——所有这部分风险都由分散式互联网来处置。PVRB不可以回滚或破坏已发送的买卖 ,而且参与者不可以拒绝参与协议,除非他们成功地攻击了互联网共识。因为安全级别是可以同意的,所以PVRB需要与区块链的主链一样,抵抗参与者之间的共谋。有迹象表明,PVRB应该成为共识的一部分;假如互联网赞同主链,它也应该赞同正确的产生随机数。不然,PVRB只不过一个由智能合约支持的独立协议。这两种办法各有利弊,在两者之间做出选择是相当困难的。

达成PVRB的两种办法

大家将更详细地描述两个选项:基于区块链独立智能合约的独立版本,与嵌入协议的共识集成版本。对于每种状况,我将参考时尚的区块链:以太币ereum、柚子币,与那些具备类似存储和处置智能合约办法的区块链。

独立合约

这里PVRB是一个智能合约,它同意来自随机生产者的买卖,处置它们,组合结果,并最后生成任何合约用户都可以接收的一些值。此值可能不会直接存储在合约中,但具备数据表示形式,因此允许确定产生随机性的惟一值。在该策略中,RP是区块链用户,其他人都可以参与生成过程。

独立合约选项看着很好,由于:

· 可移植性
· 易于达成和测试
· 便捷的经济策略
· 适用于区块链中工作

它也有缺点:

· 对消耗的计算资源的严格限制:买卖复杂性、容量、互联网速度和区块链存储
· 存在内部合约机指令的限制
· 消息传递的速度不可以超越区块链中包含的买卖的速度

假如大家想在现有些互联网中运行PVRB,而该互联网不包含复杂的加密技术,也无需很多的交互,那样这个选项是适合的。

共识一体化选择

这里PVRB嵌入到区块链节点代码中,或者与区块链节点消息传递并行工作。协议结果直接写入产生的块中,而协议消息在节点之间通过p2p互联网发送。因为协议的数值结果需要用块来撰写,因此互联网需要对它们达成一致。这意味着PVRB消息和买卖需要由节点进行验证,并包含在块中。这自动将大家引向一个显而易见的解决方法——假如互联网在一个块及其买卖上达成协议,那样PVRB应该是共识的一部分,而不是一个独立的协议。不然,该块在协商共识方面是有效的,但因为没遵循PVRB协议,因此不可以同意该块。因此,假如选择“共识整理”选项,PVRB将成为共识的要紧组成部分。

在互联网共识级别上讨论PVRB达成时,无论怎么样都不可以防止终结性问题。终结性是确定性共识中用的一种机制,它修复了一个“最后确定”的块,即便在并行分叉的状况下,这个块也不会被丢弃。假如你发布一条更复杂的链,它将取代任何其他更容易的链,而不需要管链的“年龄”和长度。比如,在柚子币中,有所谓的最后不可逆块被觉得是最后确定的。它们平均每432个块出现一次+ 12*15)。而比上一个库更老的分支将被容易地丢弃。该机制保证买卖包含在区块链中,并且从来不会回滚。开发一个协议来确保最后结果作为一个一致的外接程序是有意义的,由于它可以与块生产和发布异步工作。

当BP持有这部分区块,并在互联网看到一笔很好的买卖后发布它们时,对于那些可能成为“双倍支出”攻击受害者的用户来讲,最后结果至关要紧。PVRB有更严格的终结性需要,由于分叉架构意味着攻击者可以筹备几个随机数选项并发布最有益的一个。因此,限制可能的攻击时间是一个非常不错的解决方法。

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

共识一致选项看着很好:

· 与块生产有关的可能的异步达成——块像平常一样生成,但PVRB协议可以并行工作,并为每一个块生成随机数
· 可以达成即便是复杂的密码学,没智能合约的限制
· 可以比区块链中包含的买卖更快地组织消息传递,比如,协议的一部分可以在没互联网交互的节点之间工作

它也有缺点:

· 测试和开发中的困难—你将不能不模拟错误互联网、丢失的节点和互联网硬分叉
· 达成错误需要一个互联网硬分叉

这两种达成PVRB的办法都是可以同意的,但现代区块链中的智能合约在计算资源方面仍然很有限,这使得普通的密码学几乎不可能达成。但这样的情况一年比一年好。大家可以以ETH中zksnark的预编译系统合约为例。

提供透明靠谱的协议消息传递通道并非不收费的。任何分散协议都需要考虑到可能发生的西比尔( Sybil)攻击,任何行动都可以通过多个帐户进行协调。在开发过程中,请记住攻击者可以从任意数目的协议参与者中创建共谋。

PVRB和块变量

我并没说谎说 还没人在区块链中推行一个好的、强大的 PVRB, 并在赌博应用中进行了测试。ETH和 柚子币 中的这部分赌博应用申请来自何方?我和你一样惊讶: 在完全确定的环境中, 如何会有这么多 "强" 随机数呢?

我最喜欢的在区块链中获得随机数的办法是从块中获得一些“不可预测”的信息,并在其基础上生成一个随机数。你还可以选择块中的任何其他“不可预测”值,比如,块哈希值、很多买卖、互联网复杂性和其他未知值。你甚至可以在白皮书中写道,你的策略是“后量子安全的”。

唉,即便是后量子安全的哈希值也不够。诀窍在于PVRB的需要,我将引用上一篇文章:

1. 结果应该具备可证明的均匀分布,即基于强密码学。
2. 控制任何一点结果都是不可能的。
3. 不参与协议或用攻击消息重载互联网来破坏生成协议是不可能的。
4. 上面所述的所有都应抵制少量的不诚实的协议参与者串通一气。

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

在块生成软件中实行如此的攻击并不复杂。在验证和包含一个块中的买卖时,会有一个迅速检查通道,以查询会不会有收益,并可能选择一个买卖参数来增加获胜概率。与此同时,发现一个聪明的BP来实行如此的操作几乎是不可能的,由于每次他都可以用新的地址,并在不引起怀疑的状况下一点一点地获胜。

因此,基于块数据的办法不适用于通用PVRB达成。在一个简短的版本中,限制了赌注大小、玩家数目或KYC注册,这部分策略只适用于小型游戏。

PVRB和commit-reveal

好吧, 至少大家有哈希值, 一个 "几乎不可预测" 的块哈希值。假如大家设法解决领先矿工的问题, 大家可能会得到更有价值的东西。让大家将用户添加到此策略中, 并允许他们影响随机性结果: 任何技术支持职员都会告诉你, IT 系统中最随机的问题是用户操作:)

在这种策略中,用户仅需发送随机数,然后通过哈希他们的一同商品计算结果。在这样的情况下,最后一个玩家可以选择我们的随机数来控制结果。这就是为何最好用大家都知道的commit-reveal模式。第一,参与者发送他们的随机数的哈希值,然后提交原始随机数。一旦采集了所有必要的提交,“reveal”阶段就开始了,也就是说,参与者只能发送之首要条件交的哈希值随机数。目前大家将添加块参数—最好用以后的块参数,由于随机数只出目前下一个块中。目前任何玩家都可以影响结果的随机性,并可以“击败”一个恶意的BP,用它自己不可预测的随机性来阻止它……你还可以通过为“提交”请求一些买卖成本来提升协议安全性。

这是一个非常不错的尝试。唉,这还不够。目前,不只矿工可以影响结果,协议的任何参与者也可以。

至少大家有机会惩罚那些提交了却而没显示的人,这个策略稍后会有用。除此之外,它的容易性也是一个要紧的优势,由于更要紧的协议需要更多的计算。

PVRB和确定性签名

确定性签名是使RP生成伪随机数的另一种好办法,它不会干扰伪随机数。比如,RSA签名就是其中之一,而ECS则不是。假如RP有一对密钥,并且他用我们的私钥对一些值进行签名,RSA允许生成一个惟一的签名,而ECS允许生成任意数目的有效签名。在创建ECS签名时,签名者可以随意选择一个随机数,从而有机会从多个签名中选择一个。RSA是 “一个输入值”+“一个密钥对”=“一个签名”。要预测另一个RP的签名是不可能的,因此具备确定性签名的PVRB可以通过组合多个已签名相同值的参与者的RSA签名来构建,比如前面的随机数。这种策略节省了很多资源,由于签名既是正确协议行为的确认,也是随机性的出处。

然而,确定性签名并非万能的,而且该策略仍然容易遭到“最后一个参与者”问题的影响。最后一个参与者仍然可以决定是不是发布签名,从而控制结果。除此之外,RSA密钥可以非常长,这对于区块链买卖来讲是一个尤为重要的参数。显然,没容易的办法来解决这个问题。

PVRB和秘密共享策略

有一些加密策略允许互联网协商一个惟一的PVRB值,同时维持对某些参与者的任何恶意行为的抵抗。其中一个有用的协议是Shamir的秘密共享。它将一些秘密划分为几个部分,并将这部分部分分发给N个参与者。这个秘密的分布方法是,从N到M个部分足够恢复它,这部分可以是任意M个部分。容易地说,有一个未知函数的图,参与者在图上交换点,得到M个点后,整个函数就可以恢复。

wiki提供了一个非常不错的讲解;你还可以在这个演示页面上以实时模式试用该协议。

假如FSSS 策略可以以其单纯的形式应用,PVRB将是无懈可击的。在其最容易的形式中,协议可能是如此的:

· 每一个参与者生成一个随机数,并将其份额分配给别的人
· 每一个参与者都揭示了其他参与者的秘密
· 假如一个参与者采集了更多的m点,他的数字可以计算出来。无论“显示”的参与者集是什么,这个数字都是惟一的
· 所需的PVRB是显示的随机数的组合

因此,考虑到有必要数目的靠谱RP遵循规则,该协议根据严格的密码学需要工作,并维持对“最后一个参与者”问题的抵抗力。

这可能是一个理想的选择。比如,本文描述了基于Fiat-Shamir秘密共享的PVRB策略。正如我前面提到的,假如你试图将其应用到区块链的单纯形式中,技术限制将不可防止地出现。下面是柚子币 智能合约中协议测试达成的一个示例,其中非常重要的部分是检查参与者已发布的共享:代码。非常明显,证明验证需要多次标量乘法,而且数字很大。同时,大家应该记住,在区块链中,当区块生产者处置事买卖时,会调用verify函数。通常来讲,任何参与者都要比较容易地验证协议的正确性,这就是为何对“verify”函数的速度需要很严格是什么原因。大家的策略没成功,由于验证没满足买卖时间限制。

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

PVRB和阈值签名

秘密共享策略打开了在“阈值”保护伞下统一的一类协议。他们允许处置“最后的参与者”的问题:假如攻击者不透露秘密的一部分,另一个诚实的参与者会相反。反过来,这使大家可以就唯一的意义达成一致,即便一些参与者正在破坏协议。

结合确定性签名和阈值策略,大家得到了一个非常便利和有前途的PVRB策略-确定性阈值签名。

上一篇文章讨论了BLS的公共签名和私有签名与密钥,目前可以用容易的数学操作组合它们——这对开发职员来讲非常便利。组合仍然是有效的密匙和签名,这使得将多个签名聚合为一个密匙和多个公钥聚合为一个密匙变得比较容易。它们的决定论允许获得具备相同输入数据的相同结果。因为这种特质,BLS签名组合成为有效的密钥,这使得M个诚实的参与者大概生成唯一的确定性、公共可验证性和不可预测的签名,直到M个参与者披露为止。

在BLS阈值签名策略中,每一个参与者都用BLS签名,并将其份额发送给区块链。BLS签名的密码特质满足随机性水平需要,由于阈值部分预防“最后的参与者”,而密钥的独特兼容性允许用很多有趣的算法。

因此,假如你正在为你的区块链在2021年春夏构建PVRB,你非常可能会遇见BLS阈值签名策略;一些项目已经在用它。比如,DFinity是一个达成该策略的基准测试工具, Keep.network是一个为协议提供服务的智能合约示例。

达成PVRB

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

我将列出你在选择高质量PVRB时需要考虑的原因:

1. 它应该是强加密的,即严格不可偏置的,不可以给其他人控制。对于某些策略,状况并不是这样,因此最好向密码撰写者寻址。
2. “最后一个参与者”问题。当控制一个或多个RP的攻击者可以在两种可能的结果中进行选择时,PVRB需要可以抵抗攻击。
3. 协议破坏。当控制一个或多个RP的攻击者决定是不是生成随机数时,你的PVRB需要可以抵抗攻击,并且可以影响随机信标的生成。
4. 消息数目。你的RP应该向区块链发送最少数目的消息,并尽量防止同步操作,譬如“发送信息,等待特定参与者的响应”。你不应该期望p2p互联网中的迅速响应,特别是来自地理分布的互联网。
5. 计算的复杂性。任何PVRB阶段的链上验证都要比较容易,由于它是由所有完整的互联网顾客机实行的。在智能合约实行的状况下,速度需要是很严格的。
6. 可访问性和灵活性。你的PVRB应该对可能的互联网问题具备弹性。
7. 可信设置和初始密钥分发。假如PVRB涉及主协议设置,则可能会致使某些问题。这里举一个例子:假如参与者需要在开始协议之前告诉他们他们的密钥,这也是一个问题,由于参与者的列表可能会改变。
8. 进步问题。所需语言的库的可用性、它们的安全性和性能、公共可访问性、复杂的测试等等。

比如,阈值BLS签名有一个显著的瓶颈——在开始之前,参与者需要共享密钥并组织阈值组。这意味着大家将不能不在一个分散式互联网中跳过至少一轮,并且,因为随机数对于实时模式下的游戏来讲是必不可少的,因此存在着非常高的协议破坏风险,而阈值策略的优点将变得毫无用处。这个问题比之前的问题要容易,但大家仍然需要开发一个单独的阈值组程序,它需要通过对不遵守协议的参与者的存款和资金提取来得到经济上的保护。合约代码由虚拟机WebAs百度竞价推广bly或EVM实行。密码函数尚未在当地达成,并且比一般密码库慢不少倍。很多协议根本不满足密钥长度需要:比如,RSA的1024位和2048位。这是标准BTC和ETH买卖签名大小的4-8倍。

还应该用不一样的编程语言达成,这种语言并不多,特别是对于新协议而言。为了将PVRB集成到共识中,大家应该用平台语言撰写代码,即查找用于geth的Go代码、Parity的Rust代码和用于柚子币的c++代码。JavaScript代码更难找到,而且因为JavaScript和密码学关系并不密切,所以选择WebAs百度竞价推广bly。它看着将成为下一个要紧的网络标准。

结论

我期望在上一篇文章中,我成功地说服了你,区块链中的随机数生成对于分散式互联网的很多方面都是至关要紧的。今天我已经表明,这项任务是极其艰巨的,但也有一些非常不错的解决方法。说实话,协议体系结构只有在进行了涉及从设置到问题模拟每个方面的大规模测试之后才会被觉得是最后的。你不太可能在白皮书或文章中找到现成的解决方法。大家也不可以建议该干什么。至少在近期的几年是这样的情况。

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

现在,还没经过验证的PVRB可以被长期用;然而,很多可能的解决方法证明了还是有出路的,最后会有算法来解决这个问题。大家将乐于推荐结果,并感谢其他团队提供的文章和代码,使开发职员不会犯同样的错误。

所以,假如你遇见一个开发分散式随机数生成器的开发职员,必须要督促他谨慎,假如有必要,还要提供心理上的帮忙:)

« 上一篇:分布式互联网的信赖难点——拜占庭将军问题
» 下一篇:没有了

相关推荐