首页 / DeFi / 如何解决以太坊域间互操作性的不可能三角(以太坊生态系统中实现互操作性的困难)

如何解决以太坊域间互操作性的不可能三角(以太坊生态系统中实现互操作性的困难)

前不久,Connext发布了NXTP,这是用来在兼容性以太坊的领域之间实现完全不可信的传输和合同调用,也就是不同区块链和第二层/L2项目链接。

在本文中,我希望解释为什么在以太坊生态系统中很难实现互操作性,并解释为什么我们认为:NXTP代表了一个真正的生态系统长期解决方案。

对无需信任的互操作性的需求

多链式/L2以太坊已经成为现实,并将继续存在。协定和应用都已经改变了开发策略,转向了多个领域,用户现在必须解决每天在不同层间移动,或者转移到另一个L1系统/侧链上的难题。各个项目都在竞相为DeFi启用这种迁移功能,并催生了几十个新的连接和互操作协议。

毫不奇怪,这也带来了一些引人注目的黑客攻击和欺诈行为:

·跨境交易协议THORChain遭到攻击;

·PolyNetwork遭黑;

·纯欺诈行为。

除了这些例子外,每一个“桥梁”系统都自认为不需要信任、安全和去中心化,即使情况并非如此。因此,开发人员和用户目前面临的最大挑战是:“我怎么决定桥接机制在加密经济中是真正安全的?”

换言之,用户如何区分“桥梁”类型,从而决定在两链之间转移资金时,哪一位是用户?

“不信任”对密码经济的真正意义是什么?

从研究界来看,当我们谈到加密经济的安全性和不受信任的属性时,我们实际上提出了一个很明确的问题:谁要验证这个系统,要付出什么代价?

若要建立真正的非中心、不受审查的公共物品,我们必须考虑到:我们的系统可能遭到强大对手的攻击,如:主权国家、大公司、或是狂妄的邪恶天才。

假如你的威胁模型中没有包含(亚马逊创始人)贝索斯最后转向邪恶这一假设,那你就不会成功。

安全最大化意味着要在系统中将验证者(验证者、矿工等等)的数量和多样性最大化,这通常意味着竭尽全力建立一个完全由以太坊验证者组验证的系统,这是L2和以太坊扩展性方案背后的核心理念。

旁白:大多数人并不知道,但是扩展性研究就是互操作性的研究。我们已经了解,多年来,通过移入多个领域可以进行扩展,问题是如何在这些领域间实现不需要信任的通信。正因为如此,JohnAdler关于optimisticrollups的开创性论文的题目是“TrustlessTwo-WayBridgesWithSidechainsByHalting”。

在域之间添加新的验证程序会怎样呢?

把前面所学过的加密经济安全知识运用到“桥梁”上。

想一想场景:假设你有Arbitrum的资金,你就特别选择了这个域,因为它是rollup,这意味着(有理由假定)你的资金完全受到以太坊的底层验证者的保护。换言之,你的钱在加密经济上可能和区块链生态系统一样安全。

想像一下,你决定使用“桥梁”,把你的资金转用到Optimism的廉价和快速。Optimism也是不受信任的,所以你可以放心把钱放进去,因为你知道他们会分享和Arbitrum一样安全(以太坊安全)。

然而,您所使用的“桥接协议”使用了其自己的一套外部验证程序。尽管一开始看起来并不重要,但是你的资金现在已经不再是靠以太坊来保证安全了,而是通过“桥梁”验证程序来保证安全:

·如果这是一个资产锁定/铸造货币“桥梁”,创建包装资产,意味着“桥梁”验证器现在可以单方合谋盗取你所有的钱;

·如果这是一个使用流动性池的“桥梁”,那么“桥梁”验证器就能以类似的方式串通从流动性提供商(LP)中盗取所有的集合资金。

虽然很多人都为安全、不受信任的L2等了几年,但是你现在的情况跟使用受信任的侧链或者可信的L1体系结构一样。

重点在于,加密经济系统的安全性依赖于其最弱的环节,在使用不安全的「桥梁」时,你的链子或L2的安全都毫无意义。同样,就像L1和L2的安全一样,这些都归结为一个问题:由谁来验证系统?

互操作协性议分类

根据验证程序的类型,我们可以把所有的互操作性协议分成三类:

类型1:原生验证

本机验证协议是:对于通过链间传递的数据,协议完全由下层链本身的验证者验证。一个轻便客户机,可以在一个以太坊虚拟机(VM)的另一条链上运行,反之亦然。

例如CosmosIBC和NEARRainbowBridge。Rollup入口/出口也是一种特殊的形式!

优点:

·互通性的方式不需要最大的信任,因为“桥梁”的安全性直接由底层验证者承担;

·在域间实现完全通用的消息。

缺点:

·依赖域的底层信任和/或协商一致机制才能运行,所以必须针对每种域类型进行自定义构建。

以太坊生态系统具有高度异构:从zk/optimisticrollups到侧链,再到运行ETH-PoW、Nakamoto-PoW、Tendermint-PoS、Snowball-PoS、PoS、Snowball-PoS,PoA等多种共识机制。这两个领域都需要一种独特的策略来实现本地验证的互操作系统。

类型二:外部验证

一个外部验证协议就是使用一组外部验证器来中继数据。这种情况一般表现为安全多方计算(MPC)系统、对话网络、或者门限签名(这些实际上都是相同的东西)。

例如,THORChain,Anyswap,Biconomy,Synapse,PolyNetwork,EvoDeFi等等。

优点:

·允许在域间传递完全通用的消息;

·可以很容易地扩展到以太坊生态系统中的任何域。

缺点:

·用户或LP完全信任外部验证程序的资金/数据。这就是说,在加密经济中,这种模式的安全性基本上低于基础领域的水平(类似于前面提到的Arbitrum和Optimism)。

有些情况下,为了给用户增加安全,项目会使用附加质押(staking)或bonding机制。但从经济角度来说,这是无效的。若要让系统不受信任,使用者必须以抵押品支付可能的最高损失,而抵押资产必须由验证者自己提供。这样不但大大增加了对该体系的资金需求,而且首先违背了铸造资产和流动性池的初衷。

类型三:本地认证

局部验证协议是一种只对参与跨领域交互的各方进行交互验证的协议。局部验证协议把复杂的n方验证问题变成了一套更加简单的两方交互方式,其中一方只对自己的对手进行验证。这一模式在两个方面都存在经济利益冲突的情况下有效——即双方不能通过合谋从整个链条中获得资金。

例如,Connext、Hop、Celer等简单的原子交换系统。

优点:

·本地验证的系统是不需要信任的——其安全由底层链来支持,因为rollups具有某种合理的保证(例如,这个链的审查时间不得超过X天);

·他们还可以轻松地扩展到其他领域。

注:并非每一个本地验证系统都不可信。一些项目在某种程度上牺牲了不需要信任的利益,从而改进了用户体验,或者增加了其他功能。

举例来说,Hop增加了一种信任假设,即要求系统中的arbitrary-messaging-bridge(AMB),即在1天内为Bonder解锁Bonder的流动性,而不是在退出rollup后整整等7天。在没有AMB的给定域中,协议也需要一个依赖外部验证的“桥梁”。

缺点:

一个本地验证系统无法支持在链之间进行广义数据传递(generalizeddatapassing)。

上述含义有一点隐晦,可能涉及到许可:如果被调用的函数在逻辑上拥有某种形式的拥有者,本地验证的系统可以实现跨域合同调用。举例来说,一个Uniswap代币互换功能可以跨链调用,不需要信任,因为这个函数可以被任何拥有可交换代币的人调用。但是,这种方法不能在没有信任的情况下跨链锁定和生成NFT,因为目标链上的铸币式(mint)函数的逻辑拥有者应该是源链上的锁(lock)合约,而这在本地验证系统中没有体现出来。

互通性困难。

接下来,我们将讨论这篇文章的主题,以及应该促使用户和开发人员就“桥梁”选择作出决定的思维模式。

不能采用可扩展性的三角,在以太坊生态系统中也存在不可能的互操作三角。该互连协议可能只具有以下三个特征中的两个:

·不受信任:具有和底层域一样的安全性;

·可扩展性:任何领域都能支持;

·信息通用性:有能力处理任意跨域数据。

Connext和NXTP如何匹配呢?

在这三个互操作性属性中,我们找不到非常容易的方法。然而,我们已经认识到,和用太坊解决扩容性不可能三角问题一样,可以用来解决互操作性不可能三角化的问题。

用太坊L1对安全性和去中心化进行了优化,增加了可扩展性。其根本原因在于,这些属性对于区块链的生命周期和功能至关重要。然而,以太坊通过L2/碎片,即现有安全性和去中心化主干上的一层,从而增强可扩展性。

对于Connext,我们深信,拥有最长生命周期、最实用的互操作系统、最具可信度、最具可信度、最具可信度、最具可伸缩性。正因为如此,NXTP被设计为一种本地验证系统,其安全性与底层域相同,但也适用于任何域。

资料是否具有普遍性?类似于以太坊生态系统的可扩展性解决方案,我们通过在NXTP上插入原生验证的协议(作为我们互操作网络的L2!)以提高信息的普遍性。通过这种方式,用户和开发人员可以在任何领域获得一致的交互界面,并且能够“升级”他们的连接,当这些功能可用时,能够实现信息的通用化。

因此,我们称NXTP是互操作网络的基础协议。整个网络将包含一系列协议,包括NXTP,特定于一对域的通用跨链桥,以及将它们连接到无缝系统中的协议。

多谢JamesPrestwich,EliKrenzke,DmitriyBerenzon和更广泛的L2研究团体在过去几年里的对话,帮助产生了本文中的许多观点,并且纠正了我愚蠢的错误。

本文来自网络,不代表本地资讯门户立场,转载请注明出处:https://www.gamecheng.com/qukuilian/defi/2637.html

雯华作者

上一篇
下一篇

为您推荐

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

手机访问
手机扫一扫打开网站

手机扫一扫打开网站

返回顶部