Rollup 技术如何扩展 DeFi 生态?

 OKEX   2021-08-05 15:55   289 人阅读  0 条评论

Rollup 可以提升 DeFi 的性能,然而其可组合性会受到影响。

原文标题:《当 Defi 遇上 Rollup》(When DeFi meets Rollup)
撰文:Ryan Sean Adams
翻译:子铭
编辑:Edward

去年,以太坊平台出现了两个新的时髦的流行语。在应用层上,我们在以太坊上看到了这些 「DeFi」项目:它们利用智能合约提供类似传统金融的服务,同时具有去信任(或者至少是信任最小化)的属性。在扩展协议设计中,研究人员开始针对 Optimistic Rollup 发出自己的声音(这是一种 Layer 2 架构,且有些人相信它不仅仅只是过眼云烟)。

今年(2020 年),随着近期 DeFi 生态的继续发展以及 Rollups 不断冲击主网,一个自然而然的问题出现了:二者将如何相遇?

我们能不能用 Rollups 来扩大 DeFi 生态的规模?我们要面对哪些挑战?

概述

Optimistic Rollups 是一种 Layer 2 架构,目的在于减轻以太坊主链的负担。其基本思想是,主链不对 Rollup 侧链上的所有交易进行验证,而是简单地将其发布出去,并「乐观地(optimistic)」假设它们是有效的(除非明确提出质疑)。

采用 Rollups 的核心好处是它降低了用户的 Gas 成本,这对整个网络来说意味着每秒会发生更多的交易(至少几百 TPS)。它同样也意味着某些原本耗费 gas 较多的应用(如采用复杂密码学的隐私解决方案)则将变得可行。因此,虽然 Rollup 本身并不具备隐私保护的内在优势,但它是构建隐私保护技术的合适基础。同样的,Rollup 本身并不会降低交易延迟,但它提供了一个良好的环境,我们可以在此基础上建立一个可以提供几乎即时交易的渠道。

Optimistic Rollups 处理数据的方式可以让应用构造变得简单,尤其是相对于其他 Layer 2 协议而言更是如此。重要的是这为最终用户带来了与使用 Layer 1 协议几乎相同的用户体验。同样地对于开发者和协议设计者来说,他们所习惯的工具和思维模式仍然可以使用(尽管正如我们将看到的那样,要解决一些围绕着可组合性的挑战可能需要一些额外的工作)。

用户视角

从用户的角度来看,在 Rollup 上与 DeFi 应用或其他方式进行交互感觉几乎与在 Layer 1 上使用 DeFi 的感觉相同。它可以支持像 Metamask 和 Burner 这类比较流行的钱包,也可以支持区块浏览器来监控 Rollup 的活动。

使用 Rollup 实现 DApp 的基本生命周期如下:

首先,用户将一些资金(该「资金」可以是 ETH、ERC20s、ERC721s 等)存入 Rollup;这第一步与了许多第 1 层 DApp 用户第一步的用户体验相同,即用户在使用前必须先将资金转入合约。在这一点上,用户可以像平时一样在应用程序上发布交易;如果 Rollup 的设计是为了优先考虑抗审查,那么让自己的交易被纳入到 Rollup 上就不需要依赖更多的信任、声誉或商誉,也不会比发布 Layer 1 交易面对更多的潜在审查。

当用户想把资产带回至 Layer 1 时,他们会发布一个特殊的提现交易。在这一点上我们观察到了一个潜在的区别:回顾一下,Optimistic Rollup 的安全模式取决于各方发出质疑的能力;因此监控到并证实为欺诈行为的过程是需要一段时间的。这意味着一旦请求提现,用户必须先做等待然后才能在 Layer 1 上再次获得资金;这种机制所提供的经济安全性其实是区块所需的 stake 数量和上述等待期长度的函数(Ed Felten 认为 3 个小时其实就足够了)。

话虽如此,但我们希望看到的是的是用户不用经历这样一个等待期。比如第三方可以通过在 Layer 1 给你发送等值的资金并减去一些相关费用从而让你无需等待就能获得资金的所有权。因此只要我们有这样的流动性提供者,并且还能有把复杂的事情简单化的交互界面,即使是在 Layer 2 提现也会和 Layer 1 的用户体验相差不大。

T-word

好吧,但是 Optimistic Rollup 真的是去信任的吗?当然。

任何用户都可以在去信任的前提下选择使用 Rollup;如果他们不选择使用 Rollup 的话他们的安全保障依然是非常强大的。

为了消除任何信任隐患,任何人(用户或其他用户)都可以成为验证者,以让他们自己验证有没有人会在其中作弊(cheat),且如果他们想要作弊的话也会被及时制止。这相当于运行一些每隔一个争议期(dispute period)至少要「检查一次」的额外程序。而对于不运行验证器(validators)的用户来说,只有当所有的验证方都参与不法行为并相互勾结,才有可能发生诈骗交易(比如说盗取资金)。换句话说,只要有一个诚实的验证者在外面,不管是另一个用户、交易所、应用开发者、区块浏览器、钱包提供商,还是他们的地下室里的一个匿名少年;或者说,即使所有的当事人都是恶意的,但只要他们不串通好了,即不至于一致地集体撒谎,整个 Rollup 就不会涉及任何的不法行为。一旦欺诈行为被证实,不良行为人就会被扣除押金,其中一部分会给到欺诈验证者;这也就激励了这些有关诚实行为的验证(honesty validation),并让不良行为人为不法行为给其他验证者带来不便而付出代价。

开发者视角

接下来让我们转移到应用开发者的角度,我们非常高兴地发现在构建和部署 Rollup DApps 的过程中,很多开发者同样不会觉得陌生;开发者工具和库,如 truffle、web3 和 ethers.js,都可以在 Rollup 环境中重新应用于开发。此外,部署到 Rollup 上的合约仍然可以用 Solidity 编写,只有会有一些限制而已。

那么,在设计 Rollup 应用的时候,最大的区别就是有关可组合性(composability)的问题(这一点与 DeFi 应用特别相关)。

关于可组合性所面对的挑战

DeFi 应用的一个比较著名的(偶尔也会让人震惊的特点)就是它们之间能够相互协作进而直接和无权限限制地整合其他金融服务。这种看似激进的互通性实际上为以太坊合约在 Layer 1 提供了「免费」服务,当然其缺点就是其应用扩展(scaling)会遇到瓶颈。当我们将各项活动分割成独立的 Layer 2 环境时,不同的 Layer 2 链之间的互通性虽然不会丢失,但也会变得更加困难。

打个比方来说,如果说 Layer 1 的 App 是舍友,那么单独的 Rollup 上的 App 就是住在同一个小区但在不同房子里的朋友。也就是说,他们的生活区并没有那么拥挤,但现在沟通或制定计划不会与他们之前生活在一个共同空间里见面进行一样简单。

拿 PoolTogether 来说,PoolTogether 这是一个免损失博彩(no—loss lottery)的 DeFi 应用。PoolTogether 的合约管理着随机博彩的赢家选择和资金的分配;资金由 Compound (这是一个独立的(也是预先存在的)应用)产生的利息组成;而其资金形式(对于其所有池子中的一个池子而言)则是 Dai (由一个分离的合约发行)。这种互通性同三者在 Layer 1 所表现出的互通性没什么两样。

但是,如果这三个合约都在单独的 Rollup 上呢?

像 DAI 这样的资产从一个 Rollup 上迁移到另一个 Rollup 上并不是一件难事,甚至看起来和普通的 Layer 1 合约之间的资产迁移非常相似。然而购买 PoolTogether 的博彩需要先使用 PoolTogether 将资产存入 Compound,但如果 PoolTogether 和 Compound 是在不同的链上,那么只通过一次简单的交易是不可能的。PoolTogether Rollup 需要一个新的策略来访问和及时跟进有关 Compound Rollup 更新的消息。在其他一些情况下,我们可以想象到两个合约可能都希望有权力与另一个合约进行双向交互以及时获得这些更新安排;或许在其他情况下,我们可能只需要一方偶尔从另一方那里定期获得的「更新」的通知。

这里的 Rollup 通信工具集类似于 Layer 1 区块链之间的通信方法,比如很像在以太坊 2.0 这样的系统背景下的不同分片(shards)之间的通信安排。简而言之,我们有许多不同的方法来适用于不同的用处,每一种方法都有各自的技术复杂度和 / 或用户体验权衡,这取决于具体的需求。本文不会提到技术相关的细节,但用户体验的权衡往往会涉及比如要求用户等待更长时间来确认他们的交易和 / 或发布多个交易来完成他们所需的操作等类似的事情。

让我们再把刚刚那个类比更夸张地讲一下:难道已经居住在同一空间下的朋友们需要各自搬去不同的房子,然后彼此在窗外大喊大叫通信?或是通过一些处在中间位置或是共有房间通信?或是直接通过数字聊天(速度快,但需要更先进的电话技术)?

虽然可能性有很多,但简而言之 Rollup 的沟通永远不会像「面对面聊天」一样简单。

注意一下,跨 Rollup 通信(cross-Rollup communication)仍然十分简单。因为这肯定至少在一个方面比跨任意两种链的通信更加容易:它们有一个共同的参考框架,即以太坊 2.0 的 beacon 链和 Rollup 的底层 Layer 1。

我们可以想象一下这样的极端状况:我们把一大堆应用(比如说所有的 DeFi)放在一个巨大的 Rollup 上。此时跨 Rollup 互操作性的复杂性就消失了;Compound 和 PoolTogether 可以像在 Layer 1 一样自由地在 Layer 2 上交互。

但这个愿景唯一问题是它破坏了我们开始时所追求的可扩展性的收益。Layer 2 的可扩展性在很大程度上来自于分割(partitioning)和本地化工作(localizing work),否则就必须在全局范围内进行;单一的而繁忙的 Rollup 将会变得更难验证,并会使我们更加面对一开始想要避免的问题。换句话说,我们不希望搬出一个已经人满为患的房子而去挤占一个新的房子。

那么也许理想的实现就在一个折衷的位置上运行:那些从(或需要)相互之间的可组合性中受益的应用可以选择在一个共同的 Rollup 上运行,同时根据需要通过适当的方式与其他链进行通信。

应用程序可以根据其保持密切沟通联系的需要,将其聚集到某些 Rollup 区域中——这与人口聚集在某些地区和城市的方式相同

最终,Layer2 的一个关键价值主张我们可以借此实现去权限的实验;应用和用户可以根据他们预期需要的服务和交互选择进入本地环境,让他们获得新的功能同时支付更低的费用,并缓解网络拥堵现象。

就 Layer2 结构而言,Optimistic Rollups 是提供这些优势的最佳竞争者,同时它还能保留用户所期望的核心用户体验。随着扩展解决方案逐渐变得可用,以及我们正逐渐接近去中心化金融演进的下一个阶段。围绕着促进互操作性的问题是现阶段的重要考虑因素。

来源链接:bankless.substack.com

本文地址:https://www.xf112.com/post/159.html
版权声明:本文为原创文章,版权归 OKEX 所有,欢迎分享本文,转载请保留出处!

 发表评论


表情

还没有留言,还不快点抢沙发?