萍乡新闻

usdt不用实名(www.caibao.it):Vitalik:Rollup 不完全指南

来源:萍乡城事网 发布时间:2021-01-21 浏览次数:

Rollup 最近在 Ethereum 社区风靡一时,有望在未来成为 Ethereum 的主要扩容解决方案。但这项手艺到底是什么样的呢?它可以给我们带来什么转变?我们若何使用这项手艺?这篇文章将试图回覆其中的一些要害问题

靠山:什么是 Layer1 和 Layer2 扩容?

现在主要有两种区块链扩容方式。

首先,你可以直接提高区块链买卖吞吐量,但这类手艺主要挑战为「当区块容量越大时,区块链将更难以验证,而且很可能逐渐变得更中央化」。为了制止这样的风险,开发者可以提高客户端软件的效率(译者注:好比 Turbo Geth),或者使用 Sharding 手艺让构建和验证事情涣散到许多节点上,现在 Ethereum 准备借助 Eth2 升级引入 Sharding 手艺。

其次,你也可以改变使用区块链的方式。用户不必将所有买卖放在区块链上,而是可以通过 Layer2 协议在链下执行大部门买卖。即链上的智能合约只需执行两个义务:处置存取款和验证链下买卖的有用性。由此减轻链上肩负,提高买卖处置效率。

State channels vs plasma vs rollups

现在主要有三种 Layer2 扩容方案:State channels、Plasma 和 Rollups,这三种各有优劣。

译者注:译文中省略 State channels 和 Plasma 科普内容,主要讲述 Rollups 部门。

术语说明

Rollups

参考:Optimistic rollups 和 ZK rollups。

Plasma 和 State Channels 是「完全」的 Layer2 方案,由于它们试图将数据和盘算都转移至链下。然而,由于存在「数据可用性的博弈问题」,意味着这两种方案不可能平安地知足所有应用场景。

Plasma 和 State Channels 通过依赖所属权的 owner(译者注:由于提交敲诈性证实需要证实资产所属权,这也是为什么 Plasma 接纳 UTXO 方案,以是无法解决像 Uniswap 资产所属权场景的问题。谢谢 Chih Cheng Liang 指点)来解决该问题,但这使它们无法完全通用化。

另一方面,Rollups 是一种「夹杂」的 Layer2 方案。Rollups 将盘算(以及状态存储)转移至链下,但同时将每笔买卖的部门数据保留在链上。

为了提高效率,他们使用了不少 fancy 的压缩技巧,尽可能地使用「盘算」取代「数据」。其效果是系统的扩容仍然受限于底层区块链的数据带宽,但效率是可观的:Ethereum ERC20 代币转账成本约为 45,000 gas,而 Rollup 中的 ERC20 代币转账仅使用 16 字节的链上空间,成本低于 300 gas。

事实上,数据上链是要害(注重:将数据放在 IPFS 上是行不通的,由于 IPFS 不提供任何给定数据是否可用的共识,以是数据必须放到区块链上)。将数据放在链上并获得共识,若是任何人愿意,他们可以在内陆处置 rollup 中的所有操作,从而允许他们监测敲诈买卖,请求提款,或亲自天生 transaction batches。

由于没有数据可用性问题,以是恶意或离线运营者所造成的损失会更少(好比他们不能造成 1 周的延迟),从而为谁有权公布 batches 打开了更大的设计空间,并简化 rollups 系统。最主要的是,没有数据可用性问题也意味着不再需要将资产映射到 owners。

这是 Ethereum 社区对 rollups 比以往的 Layer2 扩容方案更兴奋的要害缘故原由:Rollups 是完全通用的,我们甚至可以在 rollup 内运行一个 EVM,使得现有的 Ethereum 应用不必编写过多新的代码就可以迁徙到 rollups 上。

那么 Rollup 到底是若何事情的呢?

链上会有一个智能合约维护着 state root:rollup 状态的 Merkle root(即 rollup 内部的账户余额、合约代码等信息的 Merkle 化)。

任何人都可以公布一笔 batch 买卖,这是一个高度压缩的买卖聚集,包罗旧的 state root 和新的 state root。合约会检查 batch 中的旧 state root 是否匹配当前的 state root,若是匹配,则将 state root 更新到新的 state root。

为了支持存款和提款,我们增加了买卖的能力,其输入或输出是「外部」的 rollup 状态。若是一个 batch 来自外部的输入,那么提交该 batch 的买卖也需要将这些资产转移到 rollup 合约中。若是一个 batch 有对外的输出,那么在处置该 batch 时,智能合约将会执行「提现」操作。

这一切就这么简朴! 除了一个主要的细节:若何知道 batch 中的 post-state roots 是准确的呢? 若是有人可以用随便 post-state root 提交一个 batch 而没有任何责罚,他们就可以直接将 rollup 内的所有资产转给自己。这个问题有两种截然差别的解决思绪,从而衍生出两种「口味」的 rollup 方案。

Optimistic rollups VS ZK rollups

以下是这两种「口味」的 rollups 方案形貌:

  1. ZK rollups,接纳有用性证实:每一个 batch 都包罗一个称为 ZK-SNARK 的密码学证实(例如接纳 PLONK 协议),它可以证实 post-state root 是执行该 batch 的准确效果。无论盘算量有多大,合约都可以迅速地在链上验证证实。

但两种「口味」的 rollup 之间有着庞大的权衡:

方案权衡

总的来说,我的看法是:

短期内,Optimistic rollups 很可能在通用的 EVM 盘算中胜出,而 ZK rollups 则可能在简朴的支付、买卖和其他特定应用场景中胜出,但最终从中历久来看,随着 ZK-SNARK 手艺的改善,ZK rollups 将在所有场景中胜出。

敲诈性证实剖析

Optimistic rollup 的平安性主要取决于:若是有人将一个无效 batch 公布到 rollup 合约中,那么保持跟踪链上信息并发现敲诈的任何人都可以公布敲诈性证实,向合约证实该 batch 无效并回滚。

如图所示,声称某 batch 无效的敲诈性证实将会包罗这些绿色数据:该 batch 自己(对照存储在链上的哈希值核对)和 Merkle tree 的部门内容,从而证实该 batch 读取或修改特定账户。

而该树中的黄色节点可以从绿色的节点重修,以是不必提供。这些数据足以执行该 batch 并盘算 post-state root(注:类似 stateless clients 验证单个区块的方式)。若是盘算出的 post-state root 和该 batch 中提供的 post-state root 不一样,那么说明该 batch 具有敲诈性。

若是一个 batch 存在错误,但之前所有的 batches 都是准确的,那么就可以建立一个敲诈性证实以示意该 batch 是错误的。

请注重对旧的 batches 声称无效的处置:若是存在多笔无效 batches 提交到 rollup 中,那么最好只管证实最早无效的 batch。固然,若是一个 batch 是准确的,那么永远不可能建立一个敲诈性证实以示意其无效。

Rollups 是若何压缩数据的?

一笔简朴的 Ethereum 买卖(好比发送 ETH)通常消耗约 110 字节。然而,在 Rollup 上发送 ETH 仅仅消耗约 12 字节。

字节消耗对比

为了到达这样的压缩效果,一方面是接纳了更简朴高级编码,而现在 Ethereum 的 RLP 在每个值的长度上都虚耗了 1 字节。另一方面,另有一些巧妙的压缩技巧:

  • Nonce:该参数的目的是为了防止「重放」。若是账户的当前 nonce 是 5,那么该账户的下一笔买卖必须使用 nonce 5,但一旦买卖被处置,那么该账户中的 nonce 就会被递增到 6,这样接纳 nonce 5 的买卖就不会被执行。在 rollup 中,我们可以完全省略 nonce,由于我们只是从 pre-state 中恢复 nonce。同时由于署名会接纳最新的 nonce 举行检查,若是有人试图使用旧的 nonce 重放买卖,那么署名将无法通过验证。

  • Gasprice:我们可以允许用户使用牢固局限的 gasprices 举行支付,例如 2 的 16 次幂(译者注:主要为了节约字节)。或者,我们也可以在每笔 batch 中收取牢固用度,甚至可以将 gas 支付完全移到 rollup 协议之外,让买卖者通过特定渠道向 batch 建立者支付用度。

    ,

    ALLBET官网娱乐平台开户

    欢迎进入ALLBET官网娱乐平台开户:www.aLLbetgame.us,欧博官网是欧博集团的官方网站。欧博官网开放Allbet注册、Allbe代理、Allbet电脑客户端、Allbet手机版下载等业务。

    ,
  • Gas:我们同样也可以将 gas 设置为 2 的多次幂。另外,我们也可以在 batch 层面设置 gas 限制。

  • To:我们可以使用「索引」来取代 20 字节的地址(例如:一个地址是「树」中的第 4,527 个地址,我们就可以用索引 4,527 来示意它,同时我们也会在状态中添加一个子树来存储索引到地址的映射)。

  • Value:我们可以用科学计数法存储 value。在大多数情形下,转账仅需 1 ~ 3 有用位。

  • Signature:我们可以使用 BLS 聚合署名,它允许许多署名聚合成一个约 32 - 96 字节的署名(取决于协议)。然后,这个署名可以一次性对整个新闻集和发送者举行 batch 检查。表中的 ~ 0.5 示意一个区块中可验证的聚合署名的数目是有限制的,由于它需要在一次敲诈证实中验证署名。

ZK rollups 特有的一个主要压缩技巧:若是买卖的一部门仅用于验证,并与盘算状态更新无关,那么这部门可以省略。这在 Optimistic rollup 中是做不到的,由于该数据仍然需要包罗在链上,以防未来敲诈性证实检查所需,而在 ZK rollup 中,证实数据准确性的 SNARK 已经提供了任何验证所需的数据。

一个主要的例子是隐私珍爱 rollups:在 Optimistic rollup 中,每笔买卖中 ~ 500 字节用于隐私的 ZK-SNARK 需要上链,而在 ZK rollup 中,笼罩整个 batch 的 ZK-SNARK 已经足以解释「内部」的所有 ZK-SNARKs 是有用的。

这些压缩技巧是 rollup 扩容的要害,若是没有这些技巧,rollup 或许只能在基础链的扩容上有约莫 10 倍的提升(在一些特定的盘算量大的应用中,简朴的 rollup 也已经很壮大),但有了这些压缩技巧,险些所有应用的扩容系数都可以跨越 100 倍。

谁可以提交 batch?

关于哪些人可以在 Optimistic rollup 或 ZK rollup 中提交 batch 的问题存在许多派别。一般来说,人人都以为提交 batch 的用户必须先交纳一大笔押金,若是该用户提交敲诈性的 batch(例如接纳一个无效的 state root),那么这笔押金的一部门将被烧掉,另一部门作为奖励给到提交敲诈性证实的用户。但除此之外,还存在许多可能性:

  • Total anarchy:任何人都可以在任何时候提交 batch。这是最简朴的方式,但它有一些严重的瑕玷,好比存在这样的问题:多个参与者同时天生并试图提交 batch,而其中仅有一个 batch 可以乐成被收录。这将导致大量的虚耗,好比没有意义的天生 batch 证实或者提交 batch 到链上。

  • 中央化的 Sequencer:通过 Sequencer 这样的角色提交 batch(除了提现操作:首先由用户自己提交提现请求,若是 Sequencer 在下一个 batch 中没有处置该提现买卖,那么用户可以亲自提交一个 batch 处置提现)。这是最「高效」的,但它依赖于一个中央化的角色。

  • Sequencer 拍卖:通过拍卖(好比天天)来决议谁有权力成为第二天的 Sequencer。这种方案的优点是可以筹集资金,而这些资金可以通过 rollup 的 DAO 来分配(参考:MEV 拍卖)。

  • 从 PoS 聚集中随机选择:任何人都可以将 ETH(或者 rollup 协议的代币)存入 rollup 合约中,每一个 batch 的 sequencer 都市从其中一个存款人中随机选择,被选中的概率与存款金额成正比。这种方案的主要瑕玷是大量资产被锁定,导致资金效率低。

  • DPoS 投票:Sequencer 通过拍卖选中,但若是他们显示不佳,那么代币持有者可以投票将其踢出,并举行新的拍卖来替换他们。

改善提交 batch 和 state root 的方式

现在一些正在开发的 rollup 方案接纳的是 “split batch” 模式,即提交 Layer2 batch 的动作和提交一个 state root 的动作离开执行,这会有一些要害优势:

  1. 你可以允许许多 sequencers 并行公布 batch,以提高抗审查能力,而不用忧郁一些 batch 会由于其他 batch 已经被打包而无效。

  2. 若是一个 state root 存在敲诈,你不需要回滚所有 batch,仅恢复该 state root 即可,并守候有人为该 batch 提供新的 state root。这样可以更好地保障买卖发送者的买卖不会被回滚。

总的来说,这是一个相当庞大的手艺组合,它们试图在涉及效率、简朴性、抗审查和其他目的的庞大权衡中获得平衡。但现在谈哪种组合最有用还为时过早,而时间会证实一切。

Rollups 将会带来多大的扩容?

现在 Ethereum 的 gas limit 是 1,250 万,买卖中每个字节的数据需要消耗 16 gas。那么若是一个区块仅包罗一个 batch(我们假设使用 ZK rollup,将会消耗 50 万 gas 用于验证证实),那么该 batch 会有(1,200 万 / 16)= 75 万字节。如上图所示,每一位用户转账 ETH 仅消耗 12 字节,那么也就是说,该 batch 最多可以包罗 62,500 笔买卖。

在平均区块时间为 13 秒的情形下,这相当于到达约 4,807 TPS(对比 Ethereum 现在 ETH 转账的 1,250万 / 21,000 / 13 约为 45 TPS)。

部门用例扩容提升规模

那么扩容上限可以这么盘算:

(L1 gas cost) / (bytes in rollup * 16) * 12million / 12.5million

现在值得注重的是这些数字照样过于乐观,缘故原由有几个:

首先,最主要的是一个区块险些永远不会仅包罗一个 batch,由于将可能会存在多个 rollup 方案同时运作。第二,存款和提款将连续存在。第三,短期内使用量会很低,以是牢固成本成为主要消耗。但纵然将这些因素思量在内,预计扩容规模也会跨越 100 倍。

现在,若是我们想要跨越 ~ 1,000 - 4,000 TPS,该怎么办呢?这就是 ETH 数据分片的意义所在,sharding 建议每 12 秒开拓一个 16MB 的空间,这个空间可以被任何数据填满,系统保证对这些数据的可用性杀青共识,而这些数据空间可以被 rollup 使用。

这个约 1,398 kB/s 的数据量比当前 Ethereum 60 kB/s 提高了 23 倍,从长远来看,数据容量有望进一步增进。因此,使用 Eth2 分片数据的 rollup 可以处置高达约 100k TPS,未来甚至会更多。

Rollup 另有哪些尚未解决的挑战?

虽然现在 Rollup 的基本观点已经被人人所熟知,我们也很确认它们从根本上是可行的、平安的,以及已有多个 rollup 方案被部署到主网上,但 rollup 的设计仍然存在许多地方没有被很好地探索,将 Ethereum 生态系统的大部门内容完全迁徙到 rollup 上以行使其扩容能力也存在不少挑战:

  • User and ecosystem onboarding - 使用 rollups 的应用不多,用户对 rollups 也不熟悉,现在很少有钱包最先整合 rollups,而商家和慈善机构还不接受它们用于支付。

  • Cross-rollup transactions - 有用地将资产和数据 (例如 oracle 输出) 从一个 rollup 转移到另一个 rollup 中,而不会发生经由 Layer1 的用度。

  • Auditing incentives - 若何最大限度地提高至少一个老实节点会真正周全验证一个 Optimistic rollup 的概率,以便失足时他们会公布敲诈性证实。对于小规模的 rollup(几百个 TPS 以下)来说,这不是一个主要的问题,可以简朴地借助利他主义,但对于更大规模的 rollup 来说,需要更严谨地推理这个问题。

  • Exploring the design space in between plasma and rollups - 是否存在一些方式可以将状态更新的相关数据放在链上,而不是所有的数据。

  • Maximizing security of pre-confirmations - 许多 rollup 为了更快的用户体验,提供了一个「预确认」的观点,即 sequencer 立刻给予一个答应,买卖将被包罗在下一个 batch 中,若是他们食言,sequencer 的押金将被销毁。但这种方案的经济平安性是有限的,由于可能同时向许多用户做出答应,这种机制能否获得改善?

  • Improving speed of response to absent sequencers - 若是一个 rollup 的 sequencer 突然下线,那么快速和经济地从这种情形中恢复过来将是异常有价值的:要么快速且经济地大规模退出到另一个 rollup,要么替换 sequencer。

  • Efficient ZK-VM - 天生通用 EVM 代码的 ZK-SNARK 证实(或者将现有的智能合约编译适配到其他 VM)可以被准确执行,并且有一个明确效果。

结论

Rollups 是一种壮大的 Layer2 扩容范式,预计将成为 Ethereum 短期和中期(甚至历久)扩容的基石。我们已经看到了 Ethereum 社区对此感应大大的兴奋,由于这与之前的 Layer2 扩容方案差别,它们可以支持通用的 EVM 代码,允许现有的智能合约轻松迁徙。

这是通过一个要害的妥协来实现的:放弃将数据和盘算完全放在链下,而是将每笔买卖的少量数据留在链上。

Rollups 方案有许多种,在设计空间上会有许多选择:可以接纳敲诈性证实的 Optimistic rollup,或者接纳有用性证实的 ZK rollup(又名 ZK-SNARKs)。Sequencer(可以将买卖 batch 公布到链上的用户)可以是一个中央化的角色,也可以是一个去中央化的角色,或者是介于两者之间的其他选择。

总的来说,Rollup 仍然是一项早期阶段的手艺,一切仍在迅速发展,特别是 Loopring,ZKSync 和 DeversiFi 已经运作了几个月。

期待在未来的几年内,Rollup 领域会泛起更多令人兴奋的事情功效。

发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 验证码:点击我更换图片