mt logoMyToken
Market cap:
0%
FGI:
0%
Cryptocurrencies:--
Exchanges --
ETH Gas:--
EN
USD
APP
Ap Store QR Code

Scan Download

侧链与Layer2的互操作:详解StarkEx无信任跨链桥

Collect
Share

概要

 

- 在侧链和 L2 之间转移资金的需求日益增长

- 目前的方法:通过 L1(以太坊)转移,缓慢、昂贵但无需信任;或通过应用程序(或 LP)转移,需要信任,但快速、便宜

- 我们提出了一个无需信任、安全且便宜的跨链桥,它依赖于以太坊的安全,能在侧链和 StarkEx 之间转移资金

- 通过在 StarkEx 和多个侧链之间扩展跨链桥,我们创造了一个高效跨链桥连接侧链

 

简介

虽然以太坊仍然是 DeFi 的资本区块链,具有很高的关注量和安全性,并与多条链建立了跨链桥。但以太坊也越来越拥挤,交易成本高且波动大。这促使用户转向侧链(如Polygon、BSC、Solana)和 L2( Optimistic Rollups 或 ZK-Rollups)等平台。这些平台在成本、安全、性能和可用的应用程序方面各不相同,于是加剧了割裂现象。

 

因此,在不同平台之间转移资金的需求越来越高。

 

提供侧链之间无信任跨链的解决方案已经上线(比如 Hop 或 MovR)。然而,L2(特别是 rollups)和侧链之间的无信任互操作性还没有得到解决。

 

与 Optimistic Rollups 的互操作性设计本身有问题,因为较长的最终性时间增加运营资本要求,也就提高了转移成本。

 

那么 ZK-Rollups 呢?在 L1 和 ZK-Rollups 的无需信任存取款已经可以在实时系统中使用(例如 dYdX、DeversiFi、Loopring)。而且它们通过条件转移缩短最终性时间。

 

但 ZK-Rollups 目前与侧链兼容性不佳。出现这个问题有其技术因素:目前部署在 L1 上的 ZK-Rollup 需要证明特定计算命题的有效性(即便有支持图灵完备性的 Cairo 语言,目前也是如此)。这就造成与需要在 Rollup 内有一个“互操作智能合约”的方案不兼容。

 

我们的去中心化、无需许可的 ZK-Rollup StarkNet 将改变这种状况。但是我们的无需信任可扩展性引擎 StarkEx 在此时此刻可以做什么?我们将在下面演示 StarkEx 如何支持与侧链的互操作性。

 

StarkEx 自 2020 年 6 月开始在主网上运行,已完成数百万笔交易,总价值达数十亿美元。下文将介绍 StarkEx 系统和方案,展示如何支持便宜且快速地将资金转移到侧链上,为在 ZK-Rollup 和侧链上的运行的 dApp 之间更好的互操作性铺平道路。但首先,先来想想什么定义了一个好的互操作性系统。

 

互操作性最优解的特质

 

侧链与 L2 之间互操作性的好解决方案应该应用最小信任,并简化用户体验。准确来说:

 

1. 最小化信任:应要求用户以尽可能少信任实体

2. 快速最终性:资金应可以快速到位

3. 低成本:低成本的解决方案必须在各个平台上提供低交易价格和高资本跨链效率(因为流动性提供者承担的成本将被用户抵消)

 

L2 与侧链之间的互操作性

 

迄今为止,用户如果想要在侧链和 L2 直接转移资金,就必须在两个原生选项中做出选择:无需信任且成本高、速度慢的方案 (图一);成本低、速度快,但需要信任的方案 (图二)。


(图一:经 L1 实现侧链和 L2 之间的资产转移)

(图二:经 应用程序实现侧链和 L2 之间的资产转移)

由 StarkEx 支持的解决方案

 

图三展示了我们提议的方案,用 StarkEx 为 L2 和侧链之间提供互操作性,同时满足上述提到的三个特征。请注意,这个方案使用 StarkEx 作为通道,同样适用于侧链之间的互操作性。

StarkEx 的优势

一些用户可能不熟悉 StarkEx,下文简要介绍了其基本概念。读者可以在此处查看 StarkEx 完整文档。如果只想读懂本文提议的桥接方案,以下的背景已经足够:

 

StarkEx 无需信任

 

由于 StarkEx 依赖于 STARK 证明,如果没有证明该状态确实有效,则 L1 上不会发生状态更新。这意味着资金只能根据在 Cairo 实施的逻辑在 StarkEx 内部易手,该逻辑强制执行以下操作:

 

- 没有用户在相关转账请求上的有效签名,就不能从用户那里转移资金

- L1 上已提交的 StarkEx 状态反映了 L2 环境中发生的所有资产转移记录

- 同样的资产转移请求 StarkEx 不能执行两次

 

这样的结果是,运营节点(例如交易所)无法盗取用户的资产。强制交易、应急舱口和专门的升级机制完善了去信任这一版图,使 StarkEx 变得完全自托管。

 

StarkEx 速度快

 

一旦进入 StarkEx 交易队列,运营商可能会认为交易已结算。这意味着用户可以即时随后提交交易; 无需等待交易的链上实际结算后再提交!

 

StarkEx 成本低

 

在 StarkEx 上,即使是复杂的永续交易,其成本也低至 ZK Rollups 模式的 1100 gas,这是比 L1 执行相同逻辑便宜 200 倍。Validium 模式下的交易成本更加低。此外,StarkEx 资本效率高,一旦包含其执行的证明在链上发布,就会立即敲定交易 — 要在交易后几个小时。

 

从 StarkEx 提款至侧链


步骤 1:用户向应用程序发送链下请求,指定想要提取的资产数量和类型。应用程序验证用户在他们的 StarkEx Vault 中是否有足够的资金。

步骤 2:应用程序在侧链中的互操作合约中锁定指定的资产数量和类型,然后将这些资金与(未签名的)StarkEx 的转移请求相结合。该请求命令 StarkEx 将相关资产从用户的 Vault 转移到应用程序的 Vault 中。

步骤 3:用户签署图 4 步骤 2 中指定的转移请求用以激活侧链上的互操作合约。该交易立即解锁用户的资金以便在侧链上使用。

回滚流程:如果用户未能在设定时间范围内签名,则应用程序将从互操作性合约中收回资金。

步骤 4:该应用程序现在可以在 StarkEx 上执行转账请求并在那里接收用户的资金。

满足需求

1. 该方案无需信任:用户在向 StarkEx 上的运营节点提供资金之前先在侧链上获得资金(如果没有前者,后者就不可能发生)

StarkEx 强制要求,为了从用户哪里获取资金,应用程序必须知道他们的签名

提供签名可以解锁用户在侧链上的资金

2. 速度快:在两倍的侧链最终性时间后,用户可以使用资金。

3. 交易成本低:不涉及 L1 交易,应用程序可以在 StarkEx 上立即取款,几小时后在 L1 上取款。

从侧链存款至 StarkEx

步骤 1:用户将其资金锁定在互操作合约中的侧链账户中。这些资金与 StarkEx 上的特定转账请求参数关联,指定钱可以转到用户的 Vault。

步骤 2:运营节点在 StarkEx 内执行图 5 中步骤 1 的转账请求,将资金释放到用户的 StarkEx 金库。用户可以立即开始交易这些资金。

步骤 3:步骤 2 的转账与其他交易批量进行(图 5 步骤 3.1 )。StarkEx 向 L1 证明这些交易已经发生(步骤 3.2),链上状态也相应更新(步骤 3.3)。

步骤 4:以太坊上的一个专用合约将新的 L1 状态传输给侧链上的互操作合约。这个状态,即 StarkEx 上所有交易的 Merkle 根,证实了用户按照要求在 StarkEx 上收到了资金。

步骤 5:应用程序打开 Merkle 树承诺,向侧链证明用户确实在图 5 步骤 2 中收到了StarkEx上的资金,为应用程序解锁互操作性合约中的资金。

回滚流程:如果应用程序未能在有限的时间内完成步骤 5,用户可以从互操作性合约中取回侧链上的资金。

满足需求

1、本方案是无需信任:用户先在 StarkEx 上收到资金,然后应用程序才能在侧链上认领资金。StarkEx 的逻辑和证明强制要求,如果没有前者,后者就不可能发生。

要想在侧链上接收资金,运营节点必须通过 StarkEx 向用户展示相关转账记录。

StarkEx 强制要求,只有在用户收到资金之后才能获得该转账记录。

2、速度快:交易一旦在侧链上确认,应用程序就可以立即将 StarkEx 上的资金交给用户。

3、 交易成本低:侧链或者 StarkEx 上的交易成本较低,虽然步骤四中 L1 交易的成本较高,但这个费用由多个存款请求共同分担。

此外,此应用程序在几小时之后就可以在侧链上获取资金。

未来还有什么?

StarkEx 的用户很快就能用到上面介绍的去信任的互操作方案。

 

至于 StarkNet,我们无需许可的去中心化 ZK-Rollup:StarkNet Planets Alpha 1 已经上线 Ropsten 测试网 —— 我们计划支持与其他生态系统 (如侧链) 的互操作性(译者注:本文发表于 2021 年 8 月,关于 StarkNet 可参考最新更新)。由于 StarkNet 证明了任何任意逻辑,它可以支持与此处描述类似的机制,或者部署现有的互操作性解决方案。

 

无论如何,StarkNet 促进了高度的互操作性,并将成为众多寻求扩展到以太坊之外的 DeFi 应用程序的互操作性的中心。

 

希望这篇文章对大家有一定的帮助

 

Disclaimer: The copyright of this article belongs to the original author and does not represent MyToken(www.mytokencap.com)Opinions and positions; please contact us if you have questions about content