区块链跨链互操作技术 (下篇)

Chain Interoperability

翻译:CoinEx链开发团队/kui | 原作者:Vitalik Buterin | 原文PDF | 上篇

Theory and implementation

如前所述,很多不同的场景都需要互操作。从高层次应用的角度来看,这些场景范围很广,从金融到身份验证,到任何值得用区块链来实现的应用。然而,从计算机科学的角度来看,我们可以给互操作的类型进行更加简单的分类:我们将其定位为“原因-结果”图,分为三类:前向因果、后向因果、相互依赖,如下图所示:

有统计学背景的人能看出这张图表示的是相关性的三种可能的原因;但不包括巧合——这是有充分的理由的:互操作在一定程度上就是可靠的相关性。前向因果很简单:链A引发链B上的事件(或者表述为:链B可以读取链A)。反向因果是链B引发链A上的事件——它和前向因果很类似,但它还是值得被单独列为一项的(直观上,你可以把它看作是同你意料中因果关系的方向相反的因果关系)。相互依赖是指:两条链上的活动,都是由某个外部事件触发的。中继可以提供前向因果和后向因果,这取决于两条链的能力如何。见证人机制可以提供全部三种相关性。哈希锁,只能提供相互依赖,把哈希秘密的揭示作为“共同的原因”。这从另外一个角度解释了为什么哈希锁从根本上要比中继机制更弱。

如果我们手头只能实现部分的因果关系而没有其它的,我们会问这样一个问题,是否有一个办法把上述三种关系中的任意一种转换为另外一种?碰巧,的确有这么一个机制,但它需要依赖一个或多个被“反激励”的参与者,也就是说,这些参与者在链上有一大笔押金来保证自己不作恶(或者,在联盟链的场景下,经由一个同链绑定的法律合同的约束),同时,此方法的能力有限,也存在一些重要的使用警告。它的用法大致是这样的:当链A可以读取链B的时候,我们可以在链A上创建一个智能合约,合约中押一大笔钱,这笔钱保证说:当链A上发生了某种触发事件后,链B上一定会有对应的事件发生,否则就罚没这笔钱。此方法的一个用例是所谓的“定居点的双向楔入”:在Bitcoin链上有一个多签地址,此地址的拥有者们在ETH链上押了一大笔钱,这些拥有者们在ETH链上维护一个叫做e-BTC的IOU(I-own-you,我欠你)Token,当你在ETH链上把一个e-BTC打给他们,他们就必须在Bitcoin链上把一个BTC打给你。把BTC转成e-BTC的流程就简单多了,只需要使用BTCRelay。注意,此方法需要很高的ETH押金才能实现经济意义上的安全:如果ETH/BTC的汇率下降得特别厉害,押金就不足以阻止多签地址的拥有者们偷BTC了。

哈希锁也能在某种程度上被转换为直接的因果关系,但可能性更受限,开发起来更困难。我们来看一下如何让A链上所发生的事件跨链影响到B链。当A链上发生某事件X时,某人就必须在A链上揭示一个哈希的原相,否则会被扣掉一大笔押金,而这个原相在B链上会导致事件Y发生,这样,就相当于A链的事件X触发了B链的事件Y。然而,这种机制需要实现安排好这些事件和哈希原相的关系。一个更好的方法是把“哈希锁”改为“签名锁”:B链上的一个预言机宣布一些关于A链的事实,并且对这些事实签名,这些事实被B链上的智能合约视为跨链消息;于此同时,监督这个预言机的第三方,可以将这些事实和签名送回到A链上做验证,如果验证失败的话,此预言机的运营者会在A链上损失一大笔押金。不管怎么说,上面提到的这些方法还是太复杂了,以至于它们最多也只能被看作劣质的代用品,更优化的跨链互动机制,还是应该直接包含全部三种因果关系。

如果希望利用上述这些基础工具来满足尽可能多的用例,最好还是能有一个高层次的编程语言。在编程语言中,因果关系可以被表述为事件的创建和监听,相互依赖也可以用事件来表达,只不过这个事件不是链上的事件,而是链外一个哈希原相的揭示。对一个程序员而言,在写应用的时候,需要给A链和B链各自开发一个组件,在这两个组件里,都有像这么一行代码onPreimageReveal(0x172db5b4…),这样,程序员就确信,一旦原相被揭示,被这一事件所触发的代码就会运行。这些代码所编译得到的结果,不仅仅是智能合约的代码,而且也是一个Daemon(或者一个Daemon的插件)的代码,它会检查两条链上的状态,如果某事件在一条链上发生,Daemon就把它转帖到另外一条链上去。这个Daemon可以由任何人运行,而且不需要被信任,和智能合约相关的利益攸关方可以运行它,或者由链的开发者、用户等等也可以运行它(作为一种公共服务)。

Formal modeling and Security

对这些跨链的脚本进行形式化验证,需要先建立模型:假定A链上的时间戳的误差最大是δ1,B链上的时间戳的误差最大为δ2,跨链消息传递的延迟最大不超过δ3(这些误差值δ,需要考虑出块间隔,短时间内51%攻击的风险,短时间内链被审查的风险),然后就能分析出,比方说,一个onPreimageReveal事件在链A和链B上发生的时刻之差,最大为多少。这样,在这些假定之下,我们就能对跨链的“支付对交付”合约的原子性,给出一个形式化的证明了。

注意,在跨链的场景下,把上述延迟因素考虑在形式化模型中,是非常必要的。在单链的场景下,分析一个应用所执行的协议,就不是那么有必要了,除非你需要考虑抗审查的因素(如果A真的非常需要把交易X打包上链,他们可以在10分钟之内做到这一点)。这是因为,从一条链的内部看来,它是非常安全的,每一个操作都100%保证能按照计划完成。但是,在多链的场景下,链A和链B的安全模型是不同的,跨链的信息传递需要被建模,在链B内部验证链A的状态需要被建模。于是,复杂性由此产生了,而且这些复杂性在讨论到失效模型的时候,会变得更加有趣。

此外,特别是在涉及到公链的时候,我们不能不讨论经济。例如,51%攻击,垃圾交易攻击,等等。这些攻击总是可能的,但它们也都有成本,所以,一个更加完备的形式化模型,甚至需要用如下的形式表述结论:“这个算法,在这些参数之下,安全性不超过20万美金,如果涉及到的金额超过了20万美金,攻击将变得有利可图,您需要增大时间窗口”。

然而,涉及到经济的安全模型并不容易建立,一个原因是:攻击者可以同时影响到好几个应用。例如,如果想通过垃圾交易来实施审查(阻止某交易上链),那么一般难以奏效,特别是对于高价值的应用。因为发送者只需要把一个交易打包上链即可,而攻击者则需要填满每一个区块。而且,在公链中,发送者只需要支付一个很高的手续费即可激励矿工即可打包他的交易,而攻击者必须每小时都花成千上万美元来阻止别人发交易。然而,这样的攻击,同时对链上所有的应用都是有害的,所以,如果链本身经常处于快满的状态,或者操作对于时间非常敏感(例如状态通道的清算),那么垃圾交易攻击就可以成功地让足够多的这样的操作同时失败,这样就能覆盖攻击的成本了。51%攻击也是类似的,如果每个应用都被设计成在51%的攻击的场景下损失不超过5万美金,而总共有一千个这样的应用,那么,花500万美金来同时攻击这一千个应用,就是有利可图的。因此,对公链做风险建模的时候,做金融抵押和风险管理时所采用的模型会更加适合。

Governance and Failure Modes

上面的讨论,只有当两条链都在正常工作的时候,才是有意义的。然而,如果一条或者两条链失效了,或者在治理上遇到了突发状况呢?

下面是列举了可能的意外情况,包括正面的和负面的:
A quick listing of possible irregularities, both positive and negative, that may happen to a chain is as follows:

  1. 51%攻击导致交易回滚。
  2. 51%攻击导致了成功的审查(部分成功或者全部成功)。
  3. 51%攻击造成一条无效链被轻节点和中继节点承认,但没有被全节点承认。这条错误的链内包含错误的状态转换。
  4. 改变链功能的“软分叉“(如果是意料之外的软分叉,可以认为它等效于上述第2点)。
  5. “硬分叉”:所有或者几乎所有的用户同意切换到一个新的全节点客户端上,它包含了共识协议的修改或者不寻常的状态改变,而且社区的协作程度足够高,使得在这次分叉之后,链的名称、品牌、社区影响力全部由旧链转移到新链上了。
  6. 网络故障导致分区,使得链也分叉为两个,且持续了一段时间。
  7. 一条链的共识算法是以一致性为优先(而非可用性为优先),当很多节点都下线之后,就不会有新块出来,链“停下来”了(这和上面的第2点等效,但也几乎总是会导致上述第4点)

如果一个跨链应用所在的两条链中,有一条或者两条发生了上述的事件,此应用该如何来应对呢?如果不对这些失效进行处理,那么不同的情况将导致不同的后果,例如:

  • 交易回滚事件,会导致跨链的原子操作失去原子性,因为交易在A链上的部分被回滚了,但在B链上的部分没有。
  • 一个虚假的中继事件,会导致跨链的原子操作失去原子性,因为交易在A链上的部分并没有发生,但在B链上的部分发生了(虚假的中继事件导致其发生)。
  • 一个审查事件,有时候会造成跨链的原子操作失去原子性,因为它可以把一笔提款交易阻止足够长的时间,然后让攻击方提前把款提走。但是,是否能做到这一点还取决于应用本身的逻辑,这一问题不是在所有情况下都存在的。
  • 一条链的硬分叉,可能会导致跟踪它的中继合约失效。虽然这不是在所有情况下都会发生的,事实上,这和硬分叉以及中继逻辑的实现细节密切相关。
  • 网络分区是个复杂的情形,根据共识协议的不同,这可能会导致交易回滚或者“失败-停止”事件。PoW算法一般是前者,而传统的拜占庭容错算法一般是后者。以太坊Casper的PoS模型是混合的,允许在设计中继的时候,选择“确认的程度”,从而允许不同的应用在上述两种失效模型中做不同的选择。

一般而言,“一致性优先”的共识算法意味着更加安全的跨链操作。为什么呢?考虑上面的Fedcoin的例子,Fedcoin由它的家链来发行,同时有总额为M的Fedcoin,跨链跑到了链A上。假设链A受到了持续的交易回滚攻击,或者虚假中继攻击,这样,A链就能向家链发出任意数额的SEND消息——先发一个SEND消息,等这个消息被家链确认之后,把A链上的交易回滚掉,再重新发SEND消息,如此反复。家链上会因此从链A上发过来的M个Fedcoin,这些Fedcoin都归攻击者所有了,但到此为止——家链上记录了跑到链A上去的Fedcoin的总额,因此避免了损失无限制地扩大,当然,这M个Fedcoin的损失是无法避免了。注意,相反方向的攻击也是可行的:如果家链上受到了回滚攻击,那么攻击者就能把它的每一条子链都充满了任意数额的Fedcoin,这等于是把Fedcoin弄得一文不值了。

现在,假定链A要么受到了审查攻击,要么遇到了“失败-停止”(当链A是一致性优先而非可用性优先时,大概率会是后者)。链A的用户会被阻止,失去把他们的Fedcoin拿回家链的权力,但攻击者也无法偷取任何东西——所以,把链停下来(阻止新的交易发生)是相对危害更小的,而且也让攻击者没有收益。

另外一个重要的考虑因素是链所在的环境。如果家链是一条联盟链,那么就很容易通过应急措施(做一次补救性的分叉,冻结攻击者的资产)来减少损失,所以总的损失会相对而言少很多。但在公链的场景下,损失就取决于别的一些考量,包括资产到底要做到多高程度的“去许可(permissionless)”。然后,没有任何技术可以彻底让攻击者无利可图,因为他们可以在管理者发现并且阻止他们之前,就把偷来的资产换成其他的加密货币。

注意,从单链资产到跨链资产,在一般的假设下,只不过增加了一些异步延迟而已,但考虑到失效模型,它的确微妙地弱化了安全:回滚攻击成为了导致资产被盗的一个薄弱点。这有一些像状态通道对安全的弱化,只是在表述上有一些差异:审查攻击成为了导致资产被盗的一个薄弱点。在公链的场景下,尤其是这样。人们常说矿工不会合谋来进行51%攻击,是因为这样会导致链的价值下降,币价下跌,矿工收益下降。但在资产跨链的时候,矿工可能就会有理由来攻击一条侧链,进而抬升家链的价值。因此,侧链和家链上矿工之间的关系很尴尬。

Interoperability and Lifecycle Events

在联盟链上,有一类事件是非常有趣的:生命周期事件。其中包括:

  • 经济疆域的改变(例如英国脱欧)。
  • 贸易制裁的开始和终止(例如针对俄罗斯和伊朗的)。
  • 货币退出流通(例如1999年欧元的诞生)。
  • 货币分叉(例如伊拉克在1990年前所使用的瑞士第纳尔)。

这会导致一系列事件:

  • 一条链逐步停止使用,因为它的底层货币逐步退出流通了。
  • 一条链开始运作,为了适应一种新资产的诞生
  • 一条链分叉了,类似于ETH/ETC那样的分叉。(将一种资产分裂为两个,在主流金融中能找到的先例,只有由于公司分立(spinoff)而造成的分叉,就像Ebay和Paypal)
  • 某种类型的链间交互可能会由于制裁的原因被阻塞。还有可能遇到“事实上的软制裁”:由于法律上的改变,某种跨链操作在完成时会受到巨大的压力。

类似1999年那样欧元区诞生的场景,值得格外的关注,这是一个最好被避免掉的场景:新创的资产没有单一的家链,而是有很多条链都对总额的一部分拥有发行权。借助区块链技术,这一场景的复杂性应该是可以避免掉的。一种引入新币种(例如欧元)的方法是,旧的货币的家链仍然保留,但是它们都会变得从属于一条新的家链(即它们都会处于类似上面Fedcoin例子中的链A的地位),然后它们上面的账户的余额直接乘以汇率(对欧元的汇率)即可。

由于管理的原因,想要防止链间的互操作,是比较困难的。理由是,任何人都可以在一条链内创建另外一条链的验证器(用做中继)。哈希锁更加简单:甚至有可能把一个哈希锁伪装成一个在数学上非常复杂的金融衍生品。但是,还是有一些显而易见的措施可以采取:例如,A国的中央银行希望冻结B国对其货币的使用,它只需冻结和B国的任何链有联系的银行帐号即可。还有一些软性的措施,比如限制每人每年跨链的交易限制为X美元以内。基本上,对跨链的资产转移,可以施加几乎任意的限制。但是,阻止同一条链上的资产交换就更加挑战了,只能用启发式的模式识别技术,就像今天我们用来应对欺诈和洗钱的手段一样。

在所有这些情形下,我们都非常希望达成这样的目标:无论发生什么意料之外的事件,链上的应用都可以平滑地过渡,包括链上的合约。这是可能的,如果我们把如下这些结合起来:预先通知,使用尽可能“干净”的技术来实现改变,在链上的金融合约中使用适当的缓和、恢复技术。技术性的混乱分裂、冻结和其它黑天鹅事件,只能发生在罕见的紧急情况下,例如战争,或者低烈度的政治报复(一个例子是一个政府扰乱同一个地区的经济交往,当迅速扩大的经济衰退发生时),在这些紧急情况下,智能合约级别的损失控制和恢复技术很可能是缓解问题的唯一形式。

Mitigation and Recovery from Failure Modes

从实践中我们知道,只有在不切实际的幻想中,才存在着永远持续的、保持不变的协议,它从来不会经历攻击或治理方面的状况。需求改变,优先级改变,意外发生,协议的实现也经常包含Bug。如果真的像Bitcoin社区中的很多人说的那样,Bitcoin的协议规范就是Bitcoin Core的C++实现本身,那么,那个利用整数溢出来凭空造出930亿个BTC的攻击者,就应该合法地享有他的收益,而事实上,通过协调一个软分叉来回滚12小时的历史交易并且堵上这个整数溢出漏洞,这930亿个BTC被否定了。考虑到这些不可避免的现实,我们应该如何来管理风险?

一种可能的反应是,把链间互操作限制在具有相似治理策略和共识机制的两条链,或者,两条链至少要彼此信任对方的治理策略和共识机制。由于这个原因,一些人宁愿呆在私有链和联盟链的领地内,把“无法无天”的公链,视为传统金融的净水中混入的泥沙。但是呢,不同的联盟链的治理机制也可能彼此不同,甚至频繁地彼此攻击。经济制裁就是故意阻止(金融方面)的互动的先例,例如针对俄罗斯和伊朗的制裁。其条链的大多数节点可能位于一个国家的境内,该国的政府可能会征用这些节点,来攻击敌对国家,这可以看成是“赛博战争”的一种形式。因此,如果我们希望构造一个尽可能全球适用的模型,那么合理的起点是:每条链都只相信它自己,而其他链有可能发出任意的行为,也就说,所有其它链都是“无法无天”的。毕竟,把地缘政治说成是“无法无天”的,也不能算是全错。因此,我们必须应对链发生失败的所有可能性。

讲到这里,你可能会问,如果区块链可能会失败和停止,那么分析它们之间的互操作,又何异于分析中心化系统之间的互操作呢?区块链技术到底给我们的讨论中增加了什么样的从根本上是全新的考量呢?这种考量在传统的SWIFT和银行系统中并不存在的?一种说法是,被我们称之为“区块链技术”或“Crypto 2.0”的东西,实际上是一系列相关的技术和设计哲学,包括数字签名、哈希、Merkle树,P2P网络、“默认不信任”、“推,别去拉”及其引发的若干哲学选择,它们结合在一起,即使在受到51%攻击的上下文中,区块链环境都可以表现出独特的特性,来帮助我们设计出更加安全的系统。

从技术角度讲,我们可以从一个特性来开始讨论:对每一个交易及其引发的状态转换,区块链会留下一个基于哈希和数字签名的密码学“足迹”。即使在51%攻击发生的时候,旧的链仍然存在,并且在密码学意义上是不可更改的——不仅仅在加密货币经济学角度上或者社会学角度讲是不可更改的,从严格的数学意义上讲也是不可更改的。曾有攻击发生这一事实,是大家都能看到的,如果你是一个链的参与者(或中继者),你还能看到哪个分支是先出现的。如果隔了一段时间某链没有出块,大家也是都能看到的。

上述这一特性所导致的部分结果看起来是平淡无奇的,包括我们刚才已经讨论过的:恰恰是因为区块链对哈希和签名的重度使用,我们才能构造中继风格的互操作,以及哈希锁。这些技术在传统的中心化API中,能被实现的概率极低。然而,探查到失败模式的能力,甚至还更加有趣。例如,假定我们希望有一个事件:onChainReverted(chainID,k),在PoW的上下文中,当中继发现链发生回滚的时候(当某个时刻区块M是链的顶端,但之后链的顶端变成区块N了,N和M的k代祖先之前是共同的),它就自动触发这个事件。

另一个例子是onFailStop(chainID,s)事件,它在区块链连续s秒没有出新块的时候被触发。一个实现起来更加负载的例子是能够探查到审查攻击的预言机,通过它,任何人可以提交一个交易,这个预言机会返回yes,当且仅当此交易值得被包含入链,但是持续(比方说)30个区块都没有被打包进块。协议的硬分叉也可以导致onFork事件的出发,方法是志愿地给一个标记合约提交一个状态转换,此转换将触发onFork事件。对以上这些例子,一个更加中心化的解决方案是,一个多签的公证人预言机,它在探查到某链处于异常状态的时候,会签署相应的消息。

当一个应用收到一则这样的消息的时候,它应该怎么做呢?它所能做的事情有天然的限制;从原理上讲,无法停止一个攻击者让一条侧链反复回滚,如上文讨论的,此攻击者一定是能偷到这M个Fedcoin的,不论高层次的编程语言使用了什么黑科技也无济于事。但是,我们仍然有可能综合使用智能合约和回滚预言机来创建一个低信任的“区块链失效保险”。然而,对于其他情形(例如失败-停止),不可能获得更好的、人人都不需要承担风险的特性。

有一个简单的策略:为每一个合约指派一个“应急管理人”,当一个分叉预言机判断同此合约有互动的链中的某一条遇到了异常情况的时候,应急管理人有权手动地执行合约,尽其所能来保证合约的执行符合其最初的意图。这个管理人可以是一家银行,一家监管机构,或者一家NGO,甚至可以是上述三种实体的联盟。尽管不需要频繁地依赖这个管理人来工作,管理人的角色却是非常需要信任的,最好由广受信任的实体来担任这个角色。这个策略编码起来最简单,也容易被人们理解(包括理解为何在日常情形下,这并没有增加中心化),因此在短期内它是最可能被实现的策略。

另一个方法是尝试自动地处理某些场景。例如,如果某一条链遇到了一个失败-停止事件,Timeout设置就被延长,直到这条链恢复。规划中的硬分叉可以给onFork事件附带一些标记,用来指示侵入性的水平和类型,根据这些标记可以采用不同的措施来应对。在某些场合,“回退到后备”或许可以工作:如果链B上的合约要读取链A的信息来做身份认证,而链A不可用了,那么链B可以回退到其它的信息源,或者委派一个“备用的KYC管理人”。在另一些场景中,例如跨链的利息劵的兑付,可以简单地将某次兑付标记为“已失败”,然后在一段时间之后再重试。

综上,我们可以看到互操作给应用增加了一层新的复杂性。这种复杂性带来了强大的潜力,在很多场景下,相对于政府机关间的传输,合同和交易所,即使跨链智能合约有这些额外的复杂性,仍然更加简单,更加难以攻击。然而,它的确又带来了它自身独特的挑战和风险,同时我们需要理解这些风险,设法缓解它们。从长期来看,我们期待看到对链间互操作的研究围绕着跨链编程语言来进行,这样就可以分别在两个方向上取得进展:一、安全地实现跨链的基本原语;二、利用这些原语来开发实际的应用。但是,我们仍然在跨链研究的早期,还有很长的路要走。

The Road to Interoperability in Practice

Notaries Relays Hash-Locking
Interoperability types All All (if relay exists on both chains, otherwise single-way causality only) Cross-dependency only
Trust Model Majority of notaries honest Chains do not fail or get “51% attached” Chains do not fail or get “51% attached”
Usable for cross-chain exchange? Yes Yes Yes
Usable for cross-chain portability? Yes (but require universal long-term notary trust) Yes No
Useful for cross-chain oracles? Yes Yes Not directly
Useful for cross-chain asset encumbrance? Yes (but require long-term notary trust) Yes In many cases, but with difficulty
Ease of implementation Medium Hard Easy

同链间互联相关的用例,可能需要过很久很久的时间才会成熟,因为它们需要很多依赖条件:(1) 某条链A已足够成熟,足以支持其上的应用;(2) 某条链B已足够成熟,足以支持其上的应用;(3) 某应用或者某需求无法在单一的一条链上实现。(3)本身大概也必须等(1)和(2)两点满足,在两条链上都有足够成熟的应用的时候,这些应用才会产生互操作的需求。

因此,短期来看,链间互操作的用例将同公链的币币交易相关,或者同公链的加密货币衍生品相关。类似MakerDAO这样的项目或许会对加密货币衍生品这样的用例更感兴趣,因为它们有意地将它们的持币分散在很多链上的很多资产上。联盟链的用例需要花更久的时间,因为目前联盟链中只有Liquid有值得注意的使用量,即使那样,它的主要用例也完全依赖于公链上的加密货币。而在主流金融中使用联盟链仍然非常遥远。因此,短期内,公链上的加密货币金融系统大概率会成为链间互操作机制的试验台,假以时日,等待这些机制足够成熟之后,它们会被应用到其它用例上。

从长期来看,建立跨链应用,应该满足真实需求,同时,底层技术的研发可以从抽象角度出发。如果只是建立应用的目的仅仅是“把这些链接起来”,而没有一个清晰的、用例驱动的底层理由说明为啥把链连起来是有用的,那么很可能会浪费资源。同时,看起来公证人、中继和哈希锁是很棒的基础构造,在开始构建应用的时候,首先要考虑它们;接下来的步骤,很可能应该是继续开发这三样工具,将它们的能力在一些简单的用例中提供出来,包括“支付对支付”、“支付对交付”、资产转移和跨链预言机。如果技术被构建得足够通用,那么它们的应用在任何场合下都是最优化的,而且随着时间推移,会出现越来越多的应用。

1 Like