万字详解 Babylon 如何让 Cosmos 生态受益于比特币的安全性
注:原文作者是来自斯坦福 Tse Lab 的 David Tse、Ertem Nusret Tas 以及 Kamilla Nazirkhanova,由 DeFi 之道翻译编辑。
Babylon 是一个新的 Layer 1 区块链,它的愿景是利用比特币 PoW 的安全性来增强其他 PoS 区块链的安全性(重点是 Cosmos zone)。在第一部分中,我们将简单介绍一下该项目,然后在文章的其他部分,我们将深入研究它的原理以及各种用例。
Babylon 背后的团队是谁?
Babylon 的团队由来自斯坦福 Tse Lab 的共识协议研究人员以及来自世界各地经验丰富的 Layer 1 区块链开发人员组成。值得一提的是,Tse Lab 团队成员还与以太坊基金会合作提高权益证明(PoS)以太坊信标链的安全性,他们确定了一些关键攻击,并设计了 goldfish 协议来实现 PoS 以太坊的目标。今年一月份,Babylon 获得了由 IDG 领投的 620 万美元种子轮融资。
译者注:Babylon 主要尝试解决的是 Cosmos 等 PoS 区块链的长程攻击问题,而短程攻击可通过 Cosmos 的链间安全性(ICS)解决方案解决,两者可以是互补的。
一、比特币作为信任的来源
比特币是世界上最安全的区块链,它由比特币矿工网络的巨大算力保护。目前,这种安全性主要用于支持一种加密货币:BTC。而 Babylon 项目的愿景是利用比特币网络作为信任来源,使更广泛生态系统中的其他区块链受益。这种信任来源的价值可以进一步细分为两个方面:
比特币基于工作量证明(PoW),而目前绝大多数的区块链都基于权益证明(PoS)。PoS 链与 PoW 链相比具有一定的安全限制,而利用比特币网络设计合理的架构可能会消除这些限制。事实上,PoS 和 PoW 优势可以互补,一个设计合理的架构可以两全其美。
区块链的安全性在很大程度上取决于支持它的资源的价值。在 PoW 链中,它是算力的成本。而在 PoS 链中,成本则是质押的加密货币价值。从这个角度来看,不同安全级别的区块链种类繁多。在比特币矿工网络巨大的算力支持下,比特币处于区块链安全频谱的一个极端,而较小的区块链(例如特定应用的 Cosmos zone),则位于区块链安全频谱的另一端。利用比特币设计合理的架构,可以在不损害其自主性的情况下增强这些 PoS 链的安全性。
1、1 比特币作为可靠的时间戳服务
在中本聪的白皮书中,比特币区块链引入了一种由工作量证明提供支持的时间戳服务器。它为事件提供了不可逆的时间顺序。在其原生应用中,事件是在比特币账本上执行各种交易。在目前增强其他区块链安全性的应用中,比特币也可用于对其他区块链中发生的事件添加时间戳。每个此类事件都会触发发送给矿工的交易,矿工随后将其插入比特币账本,从而为事件添加时间戳。比特币上的这些时间戳可用于解决区块链的各种安全问题。在父链上为子链中的事件加时间戳的一般概念称为 checkpointing,而为事件加时间戳的交易称为检查点(checkpoints)。
1、2 Babylon 架构
图1:Babylon 架构
Babylon 的架构如上图所示。它由三个部分组成,然后具有两级检查点:
比特币,作为时间戳服务层;
Babylon 链(一个 Cosmos zone),作为中间层;
作为安全消费者的 PoS 区块链(例如其它 Cosmos zone);
一个重要的设计考虑是,比特币能够承载的数据能力是非常有限的。在这种情况下,Babylon 链具有多种功能:
它聚合了很多 PoS 消费链的检查点流(checkpoint stream),因此只需要将一个检查点流插入比特币网络中,即可同时为所有消费者 PoS 链中的事件加上时间戳。
它在比特币网络中的检查点可以使用密码学技术(例如聚合签名)变得紧凑。
它通过 IBC 协议从消费者 PoS 链接收检查点。
它检查 PoS 消费者链的检查点的数据可用性,以便攻击者无法为不可用的数据加时间戳。
1、3 用例
快速的质押解锁:权益证明(PoS)链需要社会共识来阻止长程攻击(long range attacks),这带来了长时间的质押解锁期。例如,在 Cosmos hub 的例子中,这需要 21 天的时间。而比特币的安全性取代了社会共识,从而将 PoS 质押的解锁期缩短至 1 天之内。
引导新链:比特币安全性可用于引导代币估值较低的新链。
保护重要交易:比特币安全性可用于保护重要交易,而普通交易可以快速完成。
提高审查抗性:被审查的交易可以使用 Babylon 作为备份进入账本。
二、为什么 PoS 链的质押解锁这么慢?
Cosmos zone 等采用权益证明(PoS)共识机制的区块链允许快速确认交易,但它们的质押解锁却非常缓慢,这显然对用户体验以及区块链的流动性会产生影响。那为什么会这样?
2、1 权益证明(PoS)链和质押解锁期
权益证明 (PoS) 区块链因其能源效率而受到了广泛关注。为了保护系统,PoS 链要求区块链的验证者在提议或对区块进行投票之前质押代币。这使 PoS 协议能够追究违反协议的人的责任,并罚没他们质押的代币来作为惩罚。除了区块奖励之外,这为诚实参与提供了另一种激励。
除了能源效率之外,PoS 链的一个重要优势是快速确定性:交易被快速确认,大约几秒钟。但随之而来的问题是,质押解锁会非常缓慢,多数 PoS 链的质押解锁需要数周的时间,如下表所示。
表 1:Cosmos zone、PoS 以太坊、Avalanche、Algorand 以及 Cardano 等不同 PoS 区块链的质押解锁期。
很多 PoS 协议需要很长的质押解锁期,然后退出的验证者才能收回其质押的资金。在解锁期间,验证者不能参与 PoS 协议,也不会产生任何区块奖励或权益利息。他们也无法移动质押的资金并将其用于其他目的。长时间的质押解锁,不仅会降低用户体验并造成财务摩擦,而且还会降低 PoS 系统中代币的流动性。有趣的是,工作量证明(PoW)链却完全相反:交易确认缓慢,但算力可以随意离开网络。
2、2 流动质押(Liquid Staking)方案可以帮忙吗?
流动质押(Liquid Staking)解决方案旨在缓解权益被锁定在 PoS 链中的问题。为了进行流动质押,用户需要将他们的资金存到托管机构,然后托管机构代表用户质押这些资金。作为回报,用户会收到代表质押权益的对应 token,然后他们可以在市场上自由交易这种 token。例如,通过在流动质押合约中质押 ETH,用户可以获得一个“stEth”,它可以作为借贷和流动性挖矿的抵押品。
尽管流动质押方案在 DeFi 中创造了新的机会,但它也有自己的缺点:
由于网络问题或负责保管质押权益的验证者的对抗性行动,这可能会造成罚没的情况。然而,这种超出流动代币所有者控制范围的事件可能会降低发生概率,在最糟糕的情况下,会完全破坏代币的价值。
如果通过智能合约处理流动质押,则可能存在导致质押资金被盗的漏洞。
上述风险可能反映在实际质押权益与相应代币之间的价差上。例如,Lido 提供的 stEth 代币与 ETH 之间最近有了 8% 的价差。
将存入大型流动质押服务的权益集中起来会损害 PoS 链的去中心化,并降低用户对其资金的主权。例如,最大的流动质押池 Lido 目前拥有以太坊信标链中所有质押 ETH 的 32.1% 的市场份额,该值略低于足以让对手双花或停止区块链的 33% 质押比例。这种质押卡特尔化对以太坊意味着的风险,这仍然是社区担忧的根源。
2、3 为什么 PoS 链质押解锁期那么长?
流动质押解决方案的风险凸显了缩短质押解锁期的重要性,而不是为流动性问题找到解决办法。为了实现这个目标,我们必须首先了解质押解锁期的目的是什么,以及为什么它会这么长。因此,我们首先要了解长程攻击(long range attacks),这也是 Cosmos zone 等 PoS 链采用长时间质押解锁期的原因。
对权益证明链的长程攻击
图2:规范链。旧的验证者显示为深绿色,新的验证者显示为蓝色。在提取他们的质押权益后,旧的深绿色验证者将被新的蓝色验证者取代。
图3:对规范链的长程攻击。在提取他们的质押权益后,旧的深绿色验证者(例如区块链的创始人)遭遇对手攻击,然后攻击者创建了一条冲突链,其从过去的一个区块处分叉规范链。在冲突链上,他们启动了一组新的紫色验证者,这些验证者处于攻击者的控制之下。对于稍后观察系统的客户端来说,这两条链看起来同样有效。
Cosmos zone 的安全性依赖于它们是否有能力追究协议违反者的责任,并罚没他们的质押权益作为惩罚。例如,如果验证者对两个冲突区块进行签名并最终确定,从而在客户端之间造成混淆,则可以通过将冲突的签名作为证据来将其识别为协议违反者,并随后对其罚没。然而,一旦验证者解除质押,即从链中提取他们的权益,他们就不再因违反协议而受到惩罚。因此,攻击者可以激励这些旧验证者进行长程攻击(参见图 2 和图 3)。长程攻击的一个突出例子是下面描述的创始人攻击。
在攻击开始之前,区块链的创始人(即初始验证者),提取他们的权益。然后,使用他们的旧密钥,他们构建了一条与现有规范链冲突的新区块链。冲突链从过去的一个区块处分叉规范链,其中创始人(即旧验证者)构成了验证者集的大部分(参见图 3)。在冲突链上,这些创始人再次退出,并将他们的投票权转移给具有不同密钥的新验证者,而这些验证者实际上是由攻击者(也可能就是创始人自己!)控制。这使攻击者能够在假设的创始人退出后继续在冲突链上进行构建。
长程攻击对区块链的安全构成了严重威胁,因为它们会混淆后来的客户端,使其采用与早期客户端采用的规范链不同的链。不幸的是,这些攻击是 PoS 所固有的,因而存在 nothing-at-stake(无利害关系)问题。当可以多次使用相同的权益来产生多个冲突的区块时,就会出现这个问题,就像长程攻击的情况一样。相比之下,比特币等工作量证明(PoW)链不易受到 nothing-at-stake(无利害关系)或长程攻击,因为攻击者无法使用“相同”的计算来构建多个单独的区块。
减轻长程攻击:社会共识?
为了防止长程攻击,很多 PoS 链要求新加入的客户端和验证者在可信源的帮助下识别规范链上的检查点区块。例如,引导 Cosmos 轻客户端的建议来源包括受信任的网站、包含检查点区块列表的 Discord 通道或用于下载客户端代码的受信任对等节点。收到检查点区块后,客户端可以安全地忽略旧验证者构建的冲突链(参见图 4)。
图 4: 新加入的客户端向其对等节点询问规范链上的弱主观性检查点(带有绿色复选标记的区块)。通过观察检查点,客户端可以区分冲突的攻击链(底部)和规范链(顶部)。
客户端对外部可信来源的依赖称为社会共识,以强调识别规范、正确链过程的主观性。事实上,不同的对等节点可能很容易对规范链产生分歧,因为链的“正确性”没有基本事实,而比特币则总是选择计算量最大的链作为“正确”链。
尽管社会共识是减轻长程攻击的第一步,但它也有其自身的问题:
社会共识没有具体说明如何识别受信任的对等方。由于这些对等方对于不同的验证者可能不同,因此通常很难量化对它们的信任。
对于网站等公共信任源,社会共识会将单点故障暴露给潜在的攻击者。例如列出检查点的网站被黑了怎么办?
社会共识引入了围绕透明度的问题,并可能导致围绕区块链生态系统的强大参与者的区块链决策中心化。
质押解锁如何适应这一切?
在社会共识方法的缺点中,最大的问题就是会引入令人沮丧的延迟:所有受信任的对等节点可能需要数天或数周才能就检查点达成一致。这是由于协议过程的主观和社会方面。例如,对等方可能通过 Telegram 进行通信(参见图 4),其中链上的协商将花费比共识协议的确认延迟更长的时间。这就是为什么图 4 中规范链上的最后一个检查点比链的顶端要老得多。
如果旧验证者可以在社会共识仍在进行时提取权益并创建冲突链,则应作为可信来源的对等方可能无法就检查点达成一致。这就是为什么包括 Cosmos zone 在内的很多 PoS 链会采用一个很长的质押解锁期。较长的质押解锁期意味着旧的验证者必须等到社会共识终止,并在规范链上检查一个区块,然后才能收回他们的质押资金。这反过来又可以防止恶意验证者混淆客户端,因为客户端会立即将冲突的恶意链(图 4 中的底部链)识别为没有检查点的链。旧的验证者当然可以选择在收回他们的质押权益之前建立一个冲突链,但在这种情况下,由于双重签名,他们的权益可能会被罚没,并且在实践中极不可能发生这种攻击。
2、4 小结
设置长时间的质押解锁期会降低用户体验以及 PoS 系统的流动性。尽管缓解长程攻击需要一段时间的质押解锁期,但如果社会共识可以更快地做出决策,那么时间就可以大大缩短。因此,在下一节中,我们将研究是否可以通过用更快的信任来源来取代社会共识,以实现更短的质押解锁期。
三、使用 Babylon 实现更快的 PoS 链质押解锁
3、1 使用比特币作为检查点的来源
幸运的是,通过使用比特币(世界上最安全的区块链)作为关于提款请求的确定性协议,我们可以加快和自动化社会共识的过程。为此,PoS 区块上的弱主观性检查点会被比特币上这些区块的实际检查点所取代(图 5)。这些检查点的顺序决定了规范的 PoS 链。一旦 PoS 区块的检查点在比特币中变得足够深(例如,k=6 区块深度),该检查点就无法被回滚,这意味着任何攻击链的检查点都会稍后出现在比特币上,并且随后可以被忽略。因此,要批准提款请求,包含请求的 PoS 区块的检查点出现早于比特币上的冲突检查点就足够了,并且确保 K 值要足够大。由于这需要数小时而不是数周,因此使用比特币作为检查点,可以将质押解锁延迟从数周减少到数小时(技术细节参见原论文)。
图 5:顶部(蓝色)PoS 链是规范的 PoS 链。带提款请求的顶部(蓝色)链上的 PoS 区块在比特币上具有一个较早的检查点。一旦这个检查点变得足够深,提款就会被批准。此时,如果提款验证者进行长程攻击,则底部(紫色)长程攻击链的检查点必然晚于顶部(蓝色)规范链的检查点,因为比特币上的 k 深度检查点无法被回滚。冲突的检查点可以被识别为来自攻击链,随后可以被忽略。
3、2 我们可以直接向比特币发送检查点吗?
让我们考虑一个 Cosmos zone(它是一个 PoS 区块链)向比特币发送检查点,以减轻长程攻击并减少其提款延迟。检查点可以通过使用比特币的 OP_RETURN
操作码来实现,该操作码允许在不可花费的比特币交易中发布 80 字节的任意数据。每个检查点必须至少包含要检查的 PoS 区块的哈希(32 个字节)以及最终确定该区块的签名(每个 32 字节)。在这里,哈希用于识别被检查点的 PoS 区块。需要签名来防止对手发送任意哈希并假装其正在比特币上检查 Cosmos 区块(我们将在下面看到为什么这是一个问题)。
由于每个 Cosmos 区块都可能包含一个提款请求,因此该 Cosmos zone 可能必须为每个新的 Cosmos 区块发送一个新的检查点。通常 Cosmos zone 每 10 秒就有一个新区块,但比特币大约每 10 分钟才有一个新区块,这意味着每个比特币区块至少要检查 60 个 Cosmos zone 区块的数据。然后,即使该 Cosmos zone 由单个验证者运行,这意味着在每个新的比特币区块上至少要检查 3840 字节的总大小,每个区块至少需要 48 笔 OP_RETURN
交易,仅仅用于检查单个 Cosmos zone! 在这一点上,我们甚至没有考虑由多个验证者运行的 Cosmos zone,或者为多条 PoS 链提供检查点服务。
总的来说,由于三个主要原因,直接在比特币上检查 Cosmos zone 可能是不可行的:
有必要检查每个包含提款请求的 PoS 区块,这可能是 Cosmos zone 中的所有区块。
有必要在每个检查点发布足够多的签名,以防止弱对手(不控制很多验证者)发送任意哈希并假装它正在检查比特币上的 Cosmos 区块。不幸的是,Cosmos zone 所使用的 Tendermint 签名是不可聚合的,并且占用了大量空间。
可能有很多 Cosmos zone 或其他 PoS 链发送检查点。在这种情况下,比特币有限的区块空间意味着检查点解决方案会面临基本的可扩展性问题。
为了减少检查点的占用空间,并开发可同时支持多个 Cosmos zone 的可扩展检查点解决方案,我们需要聚合检查点以适应每个比特币区块提供的有限空间。此外,我们需要使这些检查点尽可能紧凑。
而这就是 Babylon 要做的事。
3、3 Babylon 的架构
Babylon 是一个 PoS Cosmos zone 区块链,它接收来自多条 PoS 链的检查点流作为交易数据,并代表它们将单个检查点流发布到比特币。通过使用 Babylon 验证者的聚合签名来最小化检查点大小,并且这些检查点的频率通过允许 Babylon 验证者在很多区块时间的每个 epoch 仅更改一次来控制。
例如,完整的 Babylon 架构由三条区块链组成:消费者 PoS 链(例如其他 Cosmos zone)、Babylon 以及比特币(图 6)。
图 6
为了尽量减少对 Babylon 的信任以准确检查 PoS 区块,各个 PoS 链的验证者(为了清楚起见,我们只提一条链)下载 Babylon 区块,并观察其 PoS 检查点是否包含在比特币检查的 Babylon 区块中。这使 PoS 链能够检测到差异,例如,如果 Babylon 验证者创建了一个由比特币检查的不可用区块,并对不可用区块中包含的 PoS 检查点撒谎(图 10)。协议的主要组成部分描述如下:
1)Checkpointing: 只有 Babylon epoch 的最后一个区块被比特币检查。检查点由区块的哈希以及单个聚合 BLS 签名组成,该签名对应于已签署区块以进行最终确定的 2/3 验证者集的签名。Babylon 检查点也包含 epoch 编号。
PoS 区块可通过 Babylon 检查点分配比特币区块的时间戳。例如,图 6 中的前两个 PoS 区块由 Babylon 区块设置检查点,而 Babylon 区块又由时间戳为 t_3
的比特币区块设置检查点。因此,这些 PoS 区块被分配了比特币时间戳 t_3
。
2)规范 PoS 链:当 PoS 链上出现分叉时,第一个区块具有较早比特币时间戳的链就被视作规范 PoS 链(图 7)。如果两个分叉具有相同的时间戳,则平局被打破,有利于具有 Babylon 上较早检查点的 PoS 区块。
图 7: 使用 Babylon 从 PoS 链中提取质押权益。提款的 k 深度规则防止提款验证者进行成功的长程安全攻击。
3)提款规则:要提款,验证者向 PoS 链发送提款请求(图 7)。包含提款请求的 PoS 区块由 Babylon 检查,然后再由比特币检查,并分配时间戳 t_1
。一旦时间戳为 t_1
的比特币区块深度变为 k,就在 PoS 链上授予提款。此时,如果已提取质押权益的验证者进行长程攻击,则攻击链(图 7 中的底部链)上的区块只能被分配一个晚于 t_1
的比特币时间戳。这是因为,一旦时间戳为 t_1 的比特币区块变为 k 深度,它就无法回滚。然后,观察比特币上这些检查点的顺序,PoS 客户端可以区分出规范链和攻击链,随后可以将攻击链忽略掉。
图 8:一种短程安全攻击,导致在圈内对冲突的 PoS 区块进行双重签名的对抗性 PoS 验证者的权益被罚没。
4) 罚没规则:如果验证者在检测到攻击时没有撤回其质押,则可以对具有双重签名冲突 PoS 区块的验证者进行罚没(图 8)。恶意的 PoS 验证者知道,如果他们等到提款请求被批准后再进行长程安全攻击,他们将无法迷惑客户端,客户端可以查看比特币来识别规范链(图 7)。因此,他们可能会在为规范 PoS 链(图 8 中的顶部链)上的区块分配比特币时间戳(例如 t_2
)时分叉 PoS 链。然后,这些 PoS 验证者与恶意 Babylon 验证者以及比特币矿工合作,将 Babylon 和比特币分叉,并将时间戳 t_2
的比特币区块替换为另一个时间戳 t_3
的区块。在后来的 PoS 客户端看来,这将规范 PoS 链从顶部链更改为底部链。虽然这是一次成功的安全攻击,但它会导致恶意 PoS 验证者的权益被罚没,因为他们有双重签名的冲突区块(图 8 中以红色圈出),但尚未提取其质押权益。
图 9:Babylon 上不可用 PoS 检查点的停止规则。
5) 不可用 PoS 检查点的停止规则:PoS 验证者在观察到 Babylon 上不可用的 PoS 检查点时必须暂停他们的 PoS 链。在这里,一个不可用的 PoS 检查点是由 2/3 的 PoS 验证者签名的哈希,其假定对应于无法观察到的 PoS 区块。如果 PoS 验证者在观察到不可用的检查点时没有停止 PoS 链,那么攻击者可以揭示以前不可用的攻击链(图 9 中以深绿显示),并在后来的客户端视图中更改规范链。这是因为稍后显示的阴影链的检查点出现在 Babylon 的早期。
上面的暂停规则揭示了我们要求作为检查点发送的 PoS 区块哈希由 PoS 验证者集签名的原因。如果这些检查点没有签名,那么任何攻击者都可以发送任意哈希,并声称它是 Babylon 上不可用的 PoS 区块检查点的哈希。然后,PoS 验证者将不得不暂停检查点。请注意,创建不可用的 PoS 链是困难的:它需要破坏至少 2/3 的 PoS 验证者,以便它们用签名完成 PoS 区块,但不向诚实的验证者提供数据。然而,在上面假设的攻击中,恶意对手在没有攻击任何一个验证者的情况下,就停止了 PoS 链。为了防止此类攻击,我们要求 PoS 检查点由 2/3 的 PoS 验证者验证。因此,只有当 2/3 的 PoS 验证者确实被攻击者控制时,Babylon 才会有不可用的 PoS 检查点。由于破坏 PoS 验证者的成本,这种攻击极不可能发生,并且不会影响其他 PoS 链或 Babylon 本身。
图 10:比特币上不可用 Babylon 检查点的暂停规则。
6)不可用 Babylon 检查点的暂停规则:PoS 和 Babylon 验证者必须在观察到比特币上不可用的 Babylon 检查点时暂停区块链。在这里,不可用的 Babylon 检查点是具有 2/3 Babylon 验证者的聚合 BLS 签名的哈希,据推测它对应于无法观察到的一个 Babylon 区块。如果 Babylon 验证者没有停止 Babylon 区块链,那么攻击者可以揭示一条以前不可用的 Babylon 链(在图 9 中以深蓝显示),从而在后期客户端的视图中更改规范的 Babylin 链。类似地,如果 PoS 验证者没有停止 PoS 链,那么攻击者可以揭示以前不可用的 PoS 攻击链(图 10 中以深绿显示)以及以前不可用的 Babylon 链,从而在后期客户端的视图中规范 PoS 链。这是因为后来揭示的深色 Babylon 链在比特币上具有较早的时间戳,并且包含后来揭示的 PoS 攻击链的检查点。
就像不可用 PoS 检查点的暂停规则一样,上述规则揭示了为什么我们要求作为检查点发送的 Babylon 区块哈希必须附有一个聚合 BLS 签名,以证明 2/3 的 Babylon 验证者的签名。如果 Babylon 检查点没有签名,那么任意对手都可以发送任意哈希,并声称它是比特币上不可用 Babylon 区块检查点的哈希。然后,PoS 验证者和 Babylon 验证者将不得不等待一个在其原像中没有任何不可用 Babylon 或 PoS 链的检查点!创建不可用的 Babylon 链需要破坏至少 2/3 的 Babylon 验证者。然而,在上述假设的攻击中,攻击者停止了系统中的所有链,甚至没有破坏单个 Babylon 或 PoS 验证者。为防止此类攻击,我们要求 Babylon 检查点通过聚合签名进行证明;因此只有当确实有 2/3 的验证者被损坏时,才会有不可用的 Babylon 检查点。由于破坏 Babylon 验证者的成本,这种数据可用性攻击极不可能发生。不幸的是,一旦发生这种情况,它就会通过迫使它们停止来影响所有 PoS 链。
3、4 小结
通过使 PoS 链能够使用比特币作为时间戳服务(类似于社会共识的作用),Babylon 将 PoS 链的质押解锁时间从几周缩短到几个小时。由于比特币区块内空间不足,无法直接在比特币上对 PoS 区块进行检查,Babylon 作为单独的 PoS 链聚合 PoS 链所发送的检查点,并代表它们发布到比特币。Babylon 架构通过其针对未绑定验证者的 K 深度提取规则防止长程攻击,并保证在发生短程安全攻击的情况下罚没攻击者的质押权益。
四、通过 Babylon 提高审查抗性
4、1 审查抗性
Cosmos zone 等 PoS 区块链通常要求持有超过 2/3 的质押权益的验证者诚实地遵循协议,以便在链中包含新交易。当持有超过 1/3 质押权益的验证者变得恶意时,他们可以任意阻止区块的最终确定,从而选择性地审查交易。例如,恶意验证者可以进行勒索攻击,他们通过向时间敏感的交易用户索取贿赂(类似于 Validium 赎金攻击)。
不幸的是,1/3 审查攻击并不是 Cosmos zone 设计的缺点,而是 PoS 协议的基本限制,它能够罚没行为不端的验证者(例如,签署了冲突区块的验证者)。这个可罚没保证阻止攻击者创建冲突链,然而,这导致审查抗性从比特币的 1/2 下降到 Cosmos zone 的 1/3。
4、2 Babylon 如何提升 PoS 链的审查抗性
Babylon 可以帮助具有可罚没保证的 PoS 链(例如 Cosmos zone)实现 1/2 的审查抗性。为了实现这一目标,Babylon 将 PoS 链连接到比特币,使它们能够以 rollup 的模式运行,其中比特币被用作 PoS 交易的排序服务。在 rollup 模式下,PoS 验证者只负责验证 PoS 区块内数据的可用性,而区块的规范顺序由它们在 Babylon 上的检查点的顺序决定。规范的 Babylon 链依次使用比特币上 Babylon 区块的检查点构建,因而比特币是 PoS 区块排序的最终权威。
进入 Rollup 模式
图 11:Babylon 的审查投诉
如果 PoS 链的一个用户认为某笔交易 tx 被 PoS 链审查,可以通过向 Babylon 发送审查投诉来提示该链进入 rollup 模式(图 11)。审查投诉是一笔 Babylon 交易,其中包含审查交易 tx 的哈希。
图 12:审查投诉的检查点在比特币的深度变为 K,此时,验证者停止执行 PoS 协议。
在观察到关于 Babylon 的审查投诉后,PoS 验证者会等到投诉的检查点在比特币中达到 k 深度。此时,如果一名验证者尚未看到 tx 在 PoS 链中最终确定,它将停止提出新的 PoS 区块或签署新的提案(图 12)。相反,它会向 Babylon 发送一个用于查看 PoS 链的检查点(图 13)。
图 13: 审查投诉的检查点在比特币的深度变为了 2 k。验证者和用户进入 rollup 模式。
一旦审查投诉的检查点在比特币的深度达到了 2 k,如果比特币上的所有检查点都没有证明 PoS 区块在其前缀中包含 tx,则验证者(和用户)进入 rollup 模式(图 13)。
在 rollup 模式期间
图 14: 在 rollup 模式下,验证者创建捆绑包(bundle)并签署他们视图中可用的捆绑包。具有足够多签名的捆绑包(bundle)在 Babylon 上通过发布它们的哈希以及相关签名进行检查。
在 rollup 模式中,任何验证者都可以提出一个 PoS 交易捆绑包(图 14)。在收到一个 bundle 时,进入 rollup 模式的每个验证者都会对 bundle 的哈希进行签名,如果其事务在验证者视图中可用。从拥有超过 1/2 质押权益的验证者那里收集签名的捆绑哈希被发布到 Babylon。这些哈希和相关联的签名称为捆绑检查点(bundle checkpoint)。如果捆绑检查点附有持有超过 1/2 质押权益的验证者的签名,则捆绑检查点有效。
捆绑包签名需要防止对手向比特币发布任意哈希,并假装它们是不可用 PoS 交易的检查点。回想一下,当观察到不可用的检查点时,验证者会停止输出新的 PoS 区块,以防止数据可用性攻击。因此,在没有签名的情况下,攻击者可以发布类似于不可用检查点的任意哈希,并阻止 PoS 链。有了签名,攻击者必须按比例破坏一半以上的验证者,以获得由这些验证者签名的不可用检查点。
为了在 rollup 模式下构建 PoS 链,链的用户首先识别时间戳在比特币审查投诉检查点 2 k 区块内的 PoS 检查点。他们随后确定了这些检查点证明的最长 PoS 链。最后,他们按照检查点出现在 Babylon 上的顺序,将带有有效检查点的 bundle 捆绑包附加到该链的顶端。
退出 Rollup 模式
验证者在观察到建立在比特币审查投诉检查点上的 T>2 k 区块后退出 Rollup 模式。这里,T 是一个协议参数,表示 Rollup 模式的持续时间。在观察这些 T 区块后,PoS 链的验证者和用户都将添加到他们的链视图中的最后一个捆绑包视为新的创世区块,该区块用作 PoS 协议的锚点重启或引导。
4、3 抗审查的限制
通过 rollup 模式,只要有足够的诚实验证者签署捆绑哈希,PoS 链就可以减轻审查攻击。这意味着审查抗性为 1/2,与比特币的抗性百分比相当。不幸的是,即使在比特币的帮助下,也不可能设计出一个审查抗性超过 1/2 的协议,除非所有 PoS 区块数据都发布到比特币,然而这是不可行的(参见论文的定理 4)。鉴于这种不可能的结果,Babylon 的设计实现了针对 Cosmos zone 的审查攻击的最佳抗性。
五、共享安全性
Cosmos zones 等 PoS 链可以使用具有缓慢确定性规则的 Babylon 来实现比特币级别的交易安全。为了通过慢速确定性规则确认交易,PoS 链的客户端等到包含该交易的 PoS 区块的时间戳在比特币上变为 k 深度。通过这种方式,客户端可以保护高价值交易的安全性,防止双花攻击。使用比特币保护高价值交易的可能性,使得 Cosmos zone 即使在代币估值较低的情况下也能支持高价值交易,从而促进新 zone 用于 NFT 转移等高价值用例。通过聚合多个 Cosmos zone 的比特币时间戳,Babylon 使这些 zone 能够同时享受慢确定性规则提供的比特币级别的安全性。
5、1 比特币慢确定性带来的安全性
图 15:时间戳变为 k 深度 的 PoS 区块用绿色复选标记表示。这些区块通过慢确定性规则确认。任何与这些区块冲突的 PoS 链都将被识别为攻击链并被拒绝,因为它的时间戳将出现在通过慢确定性规则确认的 PoS 区块的时间戳之后。
在上文中,我们已经看到 Babylon 如何通过在比特币上为 PoS 链的质押解锁请求加时间戳来帮助缩短解锁时间。一旦为解锁请求加时间戳的比特币区块被确认,即在比特币最长链中的深度变为 k,攻击者就无法通过分叉比特币来覆盖携带质押解锁请求的 PoS 区块的时间戳。因此,PoS 链一旦在比特币上得到确认,就可以授予解锁请求,而不会使其遭受攻击。
将上述观察推广到所有 PoS 区块以及交易,我们就可以得到一种更强的 PoS 交易确定性概念:如果客户端等到 PoS 区块的时间戳在比特币上的深度变为 k,则该时间戳不能被任何冲突区块取代(除非比特币本身失去安全性)。这一概念使客户端能够在此类区块内获得比特币级别的交易安全,但代价是更长的延迟,因此被称为慢确定性。这种延迟来自于对 PoS 交易加时间戳的比特币区块的确认延迟(k 深度的时间)。
5、2 慢确定性的用例
1、保护重要交易
Cosmos zone 的客户端可选择使用慢确定性来为关键的高价值交易实现比特币级别的安全性。考虑购买一辆昂贵的汽车。如果商家在发货前等到付款被比特币上的 k 深度区块打上时间戳,这可以避免买家的任何双花风险。这是因为这种攻击不仅要求买方分叉底层 Tendermint 链(有被罚没的风险),而且还要分叉比特币本身,以移除包含支付交易的 Tendermint 区块的时间戳。
2、引导新的区块链
缓慢确定性的一个重要用例,是支持具有低代币估值的新 Cosmos zone 进行高价值交易(例如 NFT 转移)。在上面的双花示例中,恶意买家可能会毫不犹豫地贿赂验证者以分叉该 Cosmos zone,由于代币估值较低时,罚没的财务影响会很小,这导致了自举困境:由于安全攻击风险,区块链的低初始估值阻碍了用户进行高价值交易,这反过来又因交易量低而阻碍了代币价值的任何增长。而有了 Babylon 以及缓慢确定性,进行双花交易的攻击者还需要支付攻击比特币的费用,而这需要购买大量的算力。因此,通过阻止恶意者进行双花攻击,缓慢确定性可通过确保链上的高价值资产来打破引导困境,进而推高代币的价值。
5、3 为 Cosmos 生态分享比特币的安全性
通过缓慢的最终确定性,Cosmos zone 可以为重要交易提供比特币级别的安全性。然而,如果这些链选择直接向比特币发送时间戳,则带宽要求会非常高。在这种情况下,通过代表多个 Cosmos zone 聚集和发送检查点,Babylon 可以使整个 Cosmos 生态能够受益于比特币提供的安全性。
原文链接:
1、https://babylonchain.io/blogs/f/babylon-bitcoin-security-for-all
2、https://babylonchain.io/blogs/f/why-is-stake-unbonding-so-slow
3、https://babylonchain.io/blogs/f/babylon-for-fast-stake-unbonding
4、https://babylonchain.io/blogs/f/censorship-resistance-via-babylon
5、https://babylonchain.io/blogs/f/shared-security