关于 Optimistic Rollup,你需要知道的一切(上)_比特币:以太坊币多少钱一个

以太坊生态的最大挑战之一是如何在资源有限的前提下实现低延迟和高吞吐量。

系统的去中心化程度取决于网络中最弱的节点验证系统规则的能力。可以在低资源硬件上运行的高性能协议被称为“可伸缩的”。

在本文中,我们将深入探究现代“Layer2方案”的原则,这些方案的安全模型,及其在解决以太坊可扩展性问题上采取的策略。

本文的预设读者是那些对密码学技术感兴趣的人。如果你想要深入了解以太坊前沿可扩展性技术,以及如何设计并构建这类系统,千万不要错过这篇文章。

在本文中,重要的关键词和概念都已加粗,因为这些都是你在了解密码学货币技术时经常遇到的术语。本文涉及的概念比较复杂。如果你在阅读中遇到困惑,请不要放弃,守得云开见月明。

区块链资源要求

在比特币和以太坊等去中心化网络中,运行节点的资源要求主要有三种:

带宽:下载并广播区块链相关数据的成本。

计算:在脚本或智能合约中运行计算的成本。

存储:出于索引目的存储事务数据的成本,以及为了继续处理新的事务块而存储“状态”的成本。

影响性能的因素有:

吞吐量:系统每秒可处理事务的数量

延迟:处理一笔事务所需的时间

比特币和以太坊等新兴密码学货币网络的理想特性是去中心化。那么问题来了,网络是如何实现去中心化的呢?

低信任:有了这个特性,任何人都能自主验证比特币的总供应量永远不会超过2100万个,及其持有的比特币不是伪造的。运行节点软件的人可以独立计算最新状态,并验证出块流程是否遵循所有规则。

低成本:如果节点软件的运行成本很高,人们就会选择依靠可信第三方来验证状态。成本高意味着信任要求也高,这是我们极力想要避免的。

另一个理想特性是可扩展性:吞吐量能够随运行节点的成本增加呈超线性增长。这个定义很棒,但是并未指明与“信任”惯性。因此,我们另外定义了“去中心化可扩展性”:在几乎不会提高系统信任假设的情况下实现可扩展性。

以太坊的运行时环境是EVM。在EVM中,事务在执行不同操作时需要承担的成本不同。事务的计算单位叫做“gas”。在以太坊系统中,每个区块的gas上限被设为1250万gas。平均每12.5秒可以挖出一个区块。由此可得,以太坊的延迟是12.5秒,吞吐量是每秒100万gas。

你可能会问一个问题:每秒100万gas能做什么?

每秒可完成大约47笔“简单转账”事务。所谓“简单转账”事务,就是指“A向B转了一笔ETH”这样最基础的事务。每笔事务需要2.1万gas。

每秒可完成大约16笔ERC20代币转账。这类事务相比ETH转账事务需要执行更多存储操作,因此每笔事务需要约6万gas。

每秒可完成大约10笔Uniswap资产交换操作。代币对事务的平均成本约为10.2万gas。

……选择你感兴趣的事务,用100万gas除以其gas消耗量。

请注意,随着事务的执行复杂度提高,系统的吞吐量急剧下降。还有很大的提升空间!

方案1:使用中间方

我们可以使用大家都信任的第三方来达成所有事务。这样一来,我们就可以得到很高的吞吐量,并将延迟降至亚秒级。简直太棒了!这样也不会改变任何系统参数,但是我们需要参与一个由第三方单方面设置的信任模型。第三方可能会对我们进行审查,甚至夺走我们的资产,这就不妙了。

方案2:扩大区块容量并提高出块频率

我们可以通过减少出块时间来降低时延,我们还可以通过提高区块gas上限来提高吞吐量。这一改变可能会导致节点运营成本提高,从而阻碍人们运行节点。

方案1会提高对信任的需求,方案2会增加成本。因此,二者都不是理想的可扩展性方案。

重新认识OptimisticRollup

接下来会涉及一些关于哈希函数和默克尔树的知识。

了解了这么多之后,我们来模拟一段苏格拉底式对话,看看能否找到一个既能提高以太坊的实际吞吐量,又不会增加用户和节点运营者负担的协议。

:我们想要提高以太坊的可扩展性,又不想改变其信任和成本假设。我们该怎么做?

:可以尝试降低现有操作的成本。不过,说起来容易做起来难,我们先来看一下以太坊的架构:

以太坊网络中的每个节点目前都存储并执行来自用户的每笔事务。事务是在EVM中执行的,并与EVM的状态进行交互。常见的智能合约优化技术主要聚焦于在最大程度上减少与状态交互的次数,但是它们起到的作用很有限。

:是否存在不与状态交互就能达成交互的方法,以此降低资源成本?

:在极端情况下,我们是否可以将所有执行都转移到链下,并将数据保存在链上?我们可以引入第三方,即,排序者,来做到这点。排序者负责在本地存储并执行用户提交的事务。为了保持系统的活性,排序者会定期将它们收到的事务的默克尔根以及状态根提交到以太坊上。这个思路是正确的,因为O(N)笔链下事务只需在以太坊上存储O(1)的状态数据。

:通过使用排序者执行链下计算,只将默克尔根发布到链上,我们就能增强以太坊的可扩展性了是吗?

:是的。

:也就是说,只要我们选择了排序者,就能大幅降低转账成本。那用户怎么存钱进去呢?

:你在以太坊区块链上把钱存进某个合约,就能加入这样的系统了。排序者会将相应的存款记在你的名下。用户只需要发送一笔事务称“我想要取出3ETH,我当前的账户余额大于3ETH,这是证明”,就可以取出资金。即使L1上没有该用户的实际状态,该用户也可以提供默克尔证明并引用排序者发布的状态根来证明自己在当前状态下拥有足够多的资金。

:我们已经确定用户需要提供默克尔证明才能取出资金。用户如何获得构建默克尔证明所需的数据?

:用户可以要求排序者来提供数据!

:如果总是联系不上排序者,该怎么办?

:这种情况可能是因为排序者作恶,或因技术问题掉线,这会导致性能退化。因此,我们必须要求排序者将完整的事务数据提交到链上,只用于存储,不用于执行。这里的目的是实现数据可得性。由于所有数据都永久存储在以太坊上,即使一个排序者倒下了,新的排序者也可以从以太坊上重新找回所有与Layer2相关的数据,重新构建最新的L2状态,并接替上一个排序者的工作。

:如果排序者在线却拒绝向我提供默克尔证明数据,我可以从以太坊上下载这些数据对吗?

:对的,你可以自己同步一个以太坊节点,也可以从众多节点托管服务提供商中选择一家。

:我还有个不明白的地方……如何将数据存储在以太坊上却不执行它?难道不是每笔事务都要经过EVM执行的吗?

:假设你提交了10笔A向B转ETH的事务。执行每笔事务需要执行以下操作:增加A的nonce,减少A的余额,并增加B的余额。这需要多次写入和读取世界状态。你可以将所有事务的编码发送至智能合约的

publish(bytes_transactions)public{}

函数。请注意,这个函数的函数体是空的!也就是说,如此发布的事务数据是不会被解释、执行或访问的。它只存储在区块链的历史日志中。

:我们能信任排序者吗?如果排序者发布非法的状态转换怎么办?

:无论排序者何时发布一批状态转换,都会有“争议期”。在“争议期”内,任何人都可以发布“欺诈证明”来证明其中某个状态转换是无效的。欺诈证明就是通过重放导致链上发生状态转换的事务,并将得到的状态根与排序者发布的状态根进行对比。如果两个状态根不同,则欺诈证明成功,状态转换被取消。跟在该无效状态转换后面的状态转换也会被取消。争议期一过,就无法再对事务提出争议,即,事务被敲定。

:等等!你之前明明说过,只要会增加成本,或引入新的信任假设,就是不可行的可扩展性方案。你这里提到的方案不是要假设时刻有人会报告欺诈吗?

:没错。我们假设有一组被称为“验证者”的实体负责监控欺诈行为。如果Layer1和Layer2之间出现状态不匹配的情况,验证者就会发布欺诈证明。我们还假设验证者能够在争议期内将其欺诈证明发布到以太坊区块链上。我们认为,验证者的存在是一个弱假设。想象一下,如果有数万名用户采用该方案,你只需要1个人来担任验证者的角色。听起来不是那么不切实际吧!另外,改变以太坊的信任模型,或增加运行以太坊节点的成本是一个强假设,会做出我们不想要的改变。这就是我们的中心化可扩展性定义中的“几乎不会改变底层系统的设想”的意思。

:我同意会有人担任验证者的角色,因为这个新的解决方案牵涉到很多人的利益。但是,具体怎样还得取决于实际成本。那么,运行验证者和排序者需要消耗多少资源?

:排序者和验证者必须运行一个以太坊全节点,以及一个L2全节点来生成L2状态。验证者运行创建欺诈证明的软件,排序者运行打包并发布用户事务的软件。

:就这些吗?

:没错!恭喜!你已经重新发现了OptimisticRollup,这个2019至2021年最有前景的可扩展性方案。我可没有在说大话,这是以太坊社区经过多年研究得出的成果。也就是你在这段简短的对话中听到的。

注:

:我们建议读者阅读Vitalik的雄文《区块链资源定价》。

:请注意,存储“状态”的成本比存储原始事务数据的更高。

:OptimisticRollup就是“optimisticcontract”和“onchaindataavailability”的合体。

原文链接:

https://research.paradigm.xyz/rollups

作者:GeorgiosKonstantopoulos

翻译&校对:

闵敏&

阿剑

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金宝趣谈

Polygon怎么购买贵金属?有哪些方法获利高?_:

     目前在众多理财产品中,要说收益效率哪个最高,那绝对是具备保证金制度的现货贵金属,其活跃的行情表现,不但能给投资者带来许多盈利机会,而且我们可借助杠杆放大收益,取得更佳的理财效果.

[0:0ms0-6:28ms