zoukankan      html  css  js  c++  java
  • 区块链:Casper 机制的历史起源:第二篇

    本章描述了我们在2014年秋季所做的有关博弈理论和经济安全模型。它描述了“贿赂型攻击者模型”如何将我们的研究直接导向对远程攻击问题的激进解决办法。

    第二章:贿赂型攻击者、经济安全和远程攻击问题。

    早在Vitalik和我我们见面之前,我们分别对激励机制进行了论证,所以 “使得激励机制合理化”对于权益证明是至关重要的。我们从来就不愿意将“有一半的持币者是可靠的”这个命题作为经济安全的假设。(因为它很重要,所以这样假设就显得很大胆。)另外,我们知道我们需要在验证节点(译者注:缴纳保证金存款的节点才能成为验证节点。bonded nodes)激励和协议安全保障之间达到某种“激励相容”。

    我们总是把协议看做一种博弈,如果协议的激励机制鼓励坏的行为,就很容易导致“坏的结果”。我们认为这是一个潜在的安全性问题。保证金存款机制给了我们一个明确的方式来惩罚这种不良行为; 惩罚条件是基础的程序,它来决定是否没收保证金。

    通过长期的观察,我们发现,当比特币价格更高的时候,它的安全性就更高;反之当它价格更低的时候,它的安全性就更低。我们现在还发现,保证金存款给那些持有它的slasher(剑手)提供了比那些只获得区块奖励的剑手还要更高的经济效率。从这里我们清楚地看到经济安全(economic security)的存在,并且将它奉为一个高度优先考虑的事项。

    贿赂型攻击者

    我不能确定Vitalik对博弈论的到底了解多少(但是很明显,他知道的肯定比我知道的多)。在刚开始叙述这个故事的时候,我自己了解的博弈论知识甚至是微乎其微的--比在故事结束时的我知道的还少。但是好在知道如何去判断和计算纳什均衡。如果各位读者还没有学习过任何关于纳什均衡的知识的话,那么下一段便是为你们精心准备的。

    一个纳什均衡是一个策略组合(参与者的策略选择)和相应的收益(损失以太币或者获得以太币),达到纳什均衡时,参与者个体没有激励偏离此均衡。“有动机去做出偏离规则的行为”意味着“如果这些参与者以某种方法去改变他们正在做的行动,那么他们就会得到更多的$ETH”。如果你们记得这条,并且每当你们听到“纳什均衡”的时候能够想到“个人的策略改变是毫无意义的”,那么你就懂得了纳什均衡。

    在2014年夏末的某天,当Vitalik通过Skype电话问我一个有关经济安全性的问题时,我在我立刻对他进行回应,并在回应中第一次提到了“贿赂型攻击者模型”(我可以收买他们(验证者节点)让他们去这么做)。我并不知道我这个想法是从哪儿来的。 之后大概过了一两周,Vitalik再一次问了我类似的相关问题,从而促使我向更深的方向去思考。

    通过收买、贿赂博弈参与者,我们能够改变博弈的收益(payoffs),并且还能通过这个行为改变这场博弈的纳什均衡。下面便是相关的图解:

    贿赂式攻击将经“囚徒困境”的纳什均衡从(图的左上)改变到(右下)。如果受贿赂式攻击的博弈开始了,那么在这个例子中的贿赂型攻击者需要投入6个单位的成本(右下)。

    贿赂型攻击者模型是我们有关经济安全的第一个有用的模型。

    在我们想到贿赂式攻击模型以前,我们把经济攻击(economic attacks)想做恶意收购,协议外的卖家收购代币或者挖矿算力。一系列的外来资本将不得不进入系统,攻击区块链。在贿赂式攻击模型出现后,问题将变成“收买现有节点以达到预期结果的成本是什么?”

    我们希望对我们的尚未定义的权益证明协议进行贿赂攻击需要支付一大笔钱,以补偿损失的保证金。

    撇开关于“合理性”的讨论不说,这是我们学着论证经济安全性的第一步。引入贿赂式攻击是简单而又有趣的。我们只需要计算需要付出多少代价就能让博弈参与者去做那些攻击者想要的事情。如果一个攻击者想要逆转区块,实现双花,他必须支付与保证金存款同级别的贿赂资金,对此我们非常确信。我们知道我们可以识别出“双花签名”。所以我们非常确定,在面临贿赂式攻击者时,相对于工作量证明,它能够给予权益证明以可量化的经济安全的优势。

    远程攻击的贿赂经济学

    Vitalik和我将贿赂型攻击者引入了我们有关权益证明的研究之中。我们发现没有保证金存款的权益证明(PoS)协议会很脆弱地被一些小小的贿赂给击败。你简单地给那些持币验证者一些贿赂,让他们将他们的币转移到一个新的地址,并且提供给原来地址(现在余额为零)的私钥给你。(我不确定谁第一个想到的这一个想法。)我们使用贿赂型攻击模型验证所有其它我们已知的权益证明协议,它们都不能解决贿赂型攻击,所以我们把它们都排除了。我个人很中意。(那时我们并没有听说过Jae Kwon的Tendermint,Dominic William的现已结业的Pebble,以及Nick Williamson的Credits)

    贿赂式攻击同时也给以保证金存款为基础的权益证明带来了挑战:在一笔保证金存款退回给验证者的个人地址以后,执行贿赂攻击的对手就能用最低的价格买到验证者地址的私钥。

    这种攻击和远程攻击是如出一辙的。它获取老的私钥来控制区块链。这就意味着攻击者能够随意地创建“假的历史记录”。但是这种事情只有在所有的保证金都在同一时间到期的情况下才能发生。

    在为我们的权益证明协议设置激励机制之前,我们需要先解决长程攻击的问题。如果我们没有解决长程攻击问题,那么客户端想要获取可靠的信息来知道谁真正地拥有保证金存款,将是不可能的。

    我们确实知道开发者的检查点可以被用来解决长程攻击问题。但是我们认为这一方法明显过于集中化了。

    在我研究转向权益证明之后的几周,当时我待在伦敦郊外Stephan Tual的房子时,我发现其实有一条自然规则能够为客户端论证安全保障金。只有当验证节点缴纳保证金存款的时候,它签署的承诺才有意义。也就是说,当这笔保证金被取出之后,这些节点的签名将不再有意义。也就是说,我为什么要在你取出保证金之后继续信任你?

    贿赂式攻击模型需要上述条件。因为当保证金被取出之后,贿赂型攻击者几乎不需要付出代价就能破坏有关承诺。

    这意味着一个客户端将持有一系列的验证节点,并且如果这些区块没有通过这些节点被签署,它们将会停止这些区块。忽视从那些当前没有保证金存款的节点发出的共识信息,能够解决或规避长程攻击问题。我们不是基于从创世块(Genesis Block)到现在的历史来验证现在的状态,而是基于一个谁当前持有保证金的列表以验证现在的状态。

    这与工作量证明(PoW)是全然不同的。

    在工作量证明(PoW)中,如果一个区块是与创世块链接的,并且这个块哈希满足了链的难度要求,那么这一区块便是有效的。但是在这个以保证金存款为基础的模型中,如果一个区块是被当前存有保证金的验证节点创建的,那么这个区块便是有效的。这也就意味着我们将需要当前的信息以验证区块链。虽然这种主体性已经让相当多人担忧,但是对于基于保证金存款的权益证明(PoS)来说,却是必要的,因为它能解决贿赂型攻击问题。

    这种认识使我非常清醒地看到,工作量证明安全模型和权益证明安全模型从根本上是不兼容的。于是我放弃了所有PoW/PoS混合方法。此外,在现在看来,尝试通过创世块来确定基于权益证明的区块链是否合法,这一行为看上去显然是错误的。

    然而,除了改变有关的确认模型之外,我们确实也需要提供一种方法,用于管理这些验证节点的列表。我们不得不使用来自于验证节点的签名去管理验证节点列表的更改,我们不得不在验证节点对这些更改达成共识后开展上述行动。否则,客户端将有不同的验证节点列表,而且它们因此也不能对以太坊的状态达成一致意见。

    保证金存款时间需要变得更长,这样客户端就能有时间去了解并识别新进入的一组验证节点。只要客户端保持足够的在线时间,它们就能保持持续地更新。我认为我们将通过使用推特(Twitter),分享验证点列表,或者是节点列表的哈希,以便于那些新的和休眠中的客户端在它们的使用者输入哈希到用户界面后,能保持同步化。

    如果你有一个错误的验证节点列表,那么你就会受到“中间人攻击”(man-in-the-middle attack)。但事情并不是真的那么糟糕。有关的讨论曾经是(现在也是!)你只需要能够去信任一次外部资源的相关信息,而在那一次之后,你就将有能力自己更新你的列表了,如果你的客户端能保持定期在线,避免提取保证金存款的“长程”。

    我知道这可能需要些时间来习惯,但是我们只能信赖新的保证金存款。Vitalik刚开始对这个讨论还是有些不安的,甚至试着坚持以创世块来完成鉴定。不过最终,我们都被在权益证明协议中的这种主观性的必然存在所说服,深信不疑。Vitalik独自提出了他的弱主观性评分规则,在我看来,这个规则能替换我的观点。我的观点是,让所有的验证节点每N个区块签名一次,以更新验证节点列表。

    解决完无利害关系(nothing-at-stake)和长程攻击(long-range attack)问题后,我们准备开始选择我们的惩罚条件(slashing conditions)。

    在下一章节,我们将记录我们第一次通过详细说明惩罚条件来定义一个共识协议所学到的东西。我也将和各位读者们展示,在我和一些同领域的杰出的人们探讨我们的研究时,所学到的东西。我之前谈到的博弈论和经济模型的故事将会在第四篇的时候呈现出来。


    原文链接: https://medium.com/@Vlad_Zamfir/the-history-of-casper-chapter-2-8e09b9d3b780 
    作者: Vlad Zamfir

  • 相关阅读:
    UIWebvView 解决onClick 延迟相应问题
    MySQL 5.6.x 配置数据库主从复制
    SDWebImage 常用方法
    OSX/iOS 播放系统声音
    UIView 设置阴影(属性说明)
    Response的Content-Type一览
    Linux查看端口占用情况并释放端口占用
    Windows安装配置Anaconda2/PyCharm
    bui框架nav导航图标一览
    服务器验证码乱码问题记录(字体库添加)
  • 原文地址:https://www.cnblogs.com/hzcya1995/p/13313200.html
Copyright © 2011-2022 走看看