权益证明,私钥攻击与无法伪造的奢侈

作者:Hugo Nguyen

来源:https://medium.com/@hugonguyen/proof-of-stake-the-wrong-engineering-mindset-15e641ab65a2

前篇中文译本

在我的上一篇文章中,我讨论了为何在最坏的情况下,PoS 不如 PoW 恢复能力强。

在本文中,我将扩展讨论上文提过的场景 3:私钥攻击。

私钥攻击可以分为两类: 私钥攻击 & 现有 私钥攻击。

1. 旧私钥攻击

为了解决这一问题,新版本的 PoS 开始使用动态验证者集或者检查点(Checkpoint)。背后的思想是要收回曾经的”权益持有者“参与未来验证过程的权利。

然而,即使使用了上述方法,我们也无法完全在 PoS 协议中消除这个问题。以下两类节点仍旧十分脆弱:

a)刚刚加入网络的新节点

b)长期不活跃的节点

由于这些节点要么无任何区块历史,要么由于长期下线缺失了许多区块历史,他们(上述节点)很难检测到一些“权益持有者”在自己不在线的期间已经出售了其所持有的代币。

某些 PoS 的支持者可能会很快指出,PoW 的新节点中也会出现类似的问题,因此这个问题是可以接受的。

不过该论断非常具有误导性。虽然 PoW 系统中的新用户的确需要信任 某人,才能下载正确版本的软件并跟上其他节点的节奏。该信任并不延伸到信任某人来选择哪条链是合法的。

第二,也是更重要的一点,只要 PoW 节点软件下载完成,对于节点操作者来说,脱机任意时间都是比较安全的。在引导步骤完成后,PoW 可以达到高度“无需许可性(Permission-less)”:节点可以随时加入或者离开。除了在发生硬分叉的时候,需要节点操作者重复引导步骤(这也是为什么我们需要谨慎地进行硬分叉,并在可能的情况下尽量避免)。

而对于 PoS 的操作者来说,即使有了正确版本的节点软件,仍需定期向可信任的第三方沟通,以确定自己还在合法链上。对与主网失联或是被骗上错误的链的担忧会持续存在,说不定比你的可信任第三方的存在还要持久。这将大大降低协议的安全性。

所有 PoS 协议都会遭遇这一根本问题。

2. 现有私钥攻击

第二类私钥攻击的对象是现有私钥。这意味着即使加入动态验证者集或是检查点都无法预防该攻击。(事实上,由于自动检查点把未决的链分裂永久化,反而会加剧该问题。)

以下简述该类攻击是如何发生的:一名获得了持有至少 1/3 代币供应量的私钥的攻击者[1] 能够轻易地在相同高度创建出两条具有相当合法性的链,对于网络中的其他参与者来说,两条链中的任一条都不会看起来更“正确”(这实际上就是一次链分裂)。这对于大多数 PoS 协议来说都是破坏性的,因为在 PoS 下如果无法达到大于 2/3 的参与者是诚实参与者,协议就会停止运作。那么我们将无法“确认”任何区块,这条基于 PoS 的链就会停止生长并最终死去。

(上述保证持续运作的性质被称为“活跃性(liveness)”。)

让我们具体来看几个PoS实现:

i)Tendermint

Tendermint 认同上述缺点,并承认在协议卡住的情况下,用户需要通过链下手段达成共识:

“验证者子集应该通过外部方法协作,以签署”重组提案(reorg-proposal)“来选择出一条链。

我们还是应该赞扬他们的诚实,不过我完全无法同意该”解决方案“能真正解决问题。增加人类用户的手动干涉意味着该协议更难扩展,也意味着更容易被贿赂。这离我们在设计重要的基础设施级别的软件时想要的强健程度差了十万八千里。正如我上一篇文章里说的,从根本上说,这是心态问题

ii)Casper

Casper 在攻击方控制超过 1/3 权益时也会卡死。

Casper 引入了一个很成问题的概念——“怠工惩罚(inactivity leak)”,节点只要离线就会受到惩罚,无论你是否故意恶意离线。这是一个非常 保守的规则 因为:a)这给了攻击者另一个攻击面,即攻击者可以发起 DDoS 攻击诚实验证者使其离线,进而使其亏损;b)这将使节点有潜在的理由(担心亏损)不抵押保证金(即 stake)。由于抵押保证金的参与度对 PoS 来说 极度 重要,该概念总体上会对整个网络的安全性造成负面影响。(下文会详述)

iii)DFINITY

在 DFINITY 项目中,每个区块需要“认证(notorized)”两次才能最终“确认”。持有超过 1/3 权益的攻击者也有能力不让区块成功“认证”,以冻结该协议。


关于 DFINITY,还有一些重点我要提一下。

DFINITY 建立了一个模仿 PoW 链中的“区块重量”特征的机制(由此解决链分裂问题),但没有 PoW 背后的能源支持。该机制通过一个叫“random beacon”的东西在每一轮中随机部署一个验证者“排行榜”,每个区块的“重量”等于创建该区块的验证者的排名。简单来说,DFINITY 对于”重量“的思考仅仅基于随机性(并且所有参与者对相同的随机性达成共识)。

先不考虑这个“random beacon”是否真的能安全地实现,并以去中心化的形式实现,直观上说,这并不是个好点子。

一个数字化区块并没有真正的重量,所有的区块都是由一堆 0 和 1 组成的。如果生产区块没有成本,那么造假或者重新生产也就不会有成本。使得 PoW 区块具有真正的重量的,是区块哈希与挖矿消耗的能量之间的直接且可证明的联系。(更多关于该话题的内容,请看我关于 PoW 的文章)(编者注:中译本见文末《剖析工作量证明》)

而 DFINITY 的区块重量则是主观的,因此可能被操控。当出现以下两种情况时,该“被相信”的重量会变得毫无意义:a)当节点无法就随机性达成共识,或者 b)当随机数源停止运作(例如:区块”认证“错误会导致 random beacon 停止运作)

总的来说,DFINITY 的安全性可能实际上比 Tendermint 和 Casper 要差。虽然“准入小组”是个好主意,但它只是全部活跃验证者的一个子集(k < N)。由于该子集是随机选取的,恶意节点很容易在某些子集中占多数(也许在其他子集里只占少数)。能够控制 1/3 验证者子集的攻击者可能在一个子集中有超过 1/3 的参与度。随后攻击者可以进一步进行身份“研磨(grinding)”,直到占有他想要的份额来提高攻击成功的概率。(他不需要控制所有的准入小组,只需要控制 部分 即可。)


权益参与度

在上述的分析中,我们假设的最坏情况是攻击者控制了 货币总供给量 的 1/3 或以上,这在事实上很难,但并非不可能。不过在现实中,攻击者需要控制的“权益”并不需要这么高,因为攻击者只需控制“活跃权益(active stake)”的 1/3 或以上即可。

所有的权益持有者都参与到权益抵押与验证过程中的可能性是非常低的。我们先来假设参与度为 50%,那么攻击者只需控制 1/6(而非 1/3)的代币总供给就能够制造冲突区块或检查点了。假设参与度为 25%,那么攻击者只需控制 1/12。这有着很大的警示作用,正如之前提到的,财富通常服从幂定律分布,几个最富有的权益持有者轻易就能控制代币总供给量的1/12。

权益抵押的低参与度很可能是 PoS 协议需要面对的最大威胁。


无法伪造的奢侈消耗:幕后英雄

让我们来回想一下,比特币成为一个突破性创新的背后到底有什么秘密?以下是三个关键因素:

  1. 随机性
  2. Unforgeable costliness” (即所谓“无法伪造的奢侈消耗”)
  3. 激励机制

第一和第二点都是 PoW 挖矿的方面,而第三点则嵌入了比特币的共识协议代码中。

第一点属于计算机科学与密码学的领域,第三点则属于经济学与博弈论的领域。

而唯独第二点,却很难说到底属于哪门学科。理解第二点并理解其重要性所需的思维模型可以说是多个学科的综合,如考古学、进化心理学、经济学甚至物理学。[2]

很可能是因为我们对第二点尚未充分研究,许多人忽视且大大低估了其重要性。 PoS 协议的设计者就经常犯这个错,在他们的设计中只考虑第一和第三点。

在 DFINITY 对随机性的执念中我们能看到这一点。DFINITY 的设计者认为随机性就是解决所有问题的关键。

而以太坊的 Casper 协议则是对激励机制有着执念,在这条路上走得越来越远,还创造了个毫无意义的术语——“加密经济学”。以太坊的设计者们以为只要巧妙地设计激励机制就能解决所有问题。

有句老话说:“如果你只有一个锤子,那么所有东西看起来都是钉子。”这句话还挺适合 PoS 协议设计领域的。

事实是,这个“无法伪造的奢侈消耗”很可能就是支撑起比特币最最最重要的组成部分。没有此种无法伪造的奢侈,比特币就既没有任何新东西,也不具备任何颠覆性。


总的来说,私钥攻击对 PoS 协议来说是个严肃的问题。在 PoW 中失去对大多数哈希率的控制不是什么好事,但这并不意味整个系统会完全崩塌。但在 PoS 中失去对“权益”的控制将使整个系统完全暴露且毫无防御能力。

(完)


注 1:这个1/3的比例取自已经有成熟研究的传统拜占庭容错系统,而PoS本身就是其中的一部分。传统拜占庭容错系统在大于等于1/3的节点是恶意节点时会失效。而”拜占庭容错”的概念则来自拜占庭将军问题,由 Lamport、Pease 与 Shostak 在1982年提出。

注2:请阅读 Nick Szabo 关于货币起源的论文中文译本),以便更好地理解第二点的重要性。


Hugo Nguyen2021-09-10
https://www.btcstudy.org/2021/09/10/proof-of-stake-private-keys-attacks-and-unforgeable-costliness-the-unsung-hero/

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇