以太坊状态规模管理诸提议(下)_币世界+以太坊爱好者

2021-02-16 16:58 栏目:行业动态 来源:网络整理 查看()

在不同的解决方案之间有重要的技术权衡,特别是如果我们想要保持当前设计的一些重要属性

从状态树中移除vs。为状态树安排一个“退休”部分

区分不同状态到期建议的另一个技术观点是“一个树流”和“两个树流”。也就是说,我们现在只有一个状态树,只是把一些状态标记为过期;还是直接把非活动状态从主状态树中移除,转移到另一个只包含过期状态的特殊树(或者其他数据)?

一条小溪

以太坊状态规模管理诸提议(下)_币世界+以太坊爱好者

-活动节点用白色标记,非活动节点用灰色标记-

请注意,即使是树上的中间节点也会被标记为活动或不活动(或者,在更现实的方案中,每个节点都会被标记为非活动日期,因此可以轻松检查其活动);标记可以在状态树中的每个节点(叶节点和中间节点)上完成。

两棵流动的树

以太坊状态规模管理诸提议(下)_币世界+以太坊爱好者

-白色树包含活动状态;灰色树存储停用状态-

树流的好处是,最起码它的工作模式看起来和当前状态树差不多,去激活和再激活的过程相对简单:再激活过程只需要刷新树中相关节点的“失效日期”参数,而去激活是自动的。但它的缺点是需要一个能以这种方式在节点中存储中间信息的树结构,不能很好地扩展到Verkle树。此外,它还需要一个额外的默克尔证明元素,不仅可以沉入叶节点,还可以停在中间节点(当它需要证明一部分状态已经过期时)。

双树流的优点是,当前的纯状态累加器可以支持这种方案,而无需为每个节点添加元数据。缺点是需要对整个协议做一些更深层次的改动,需要一个显式的流程去激活状态(所以到期不再是自动的)。此外,它并没有为复活冲突的困境提供内置的解决方案(参见下一节),因此需要在两种方法之间进行选择。

注意,在双树流中,用于存储去激活状态的数据结构不是树。其实完全可以有这样的设计:当一个状态对象需要复活时,只需要提供一个指向该对象被停用时的回执的默克尔树,然后附上一些密码证据证明该对象之前没有复活过(或者最近又过期了)。

复活冲突

接下来我们来看状态失效方案的一个关键问题:“复活冲突”。复活冲突的概念如下。假设由地址a生成一个账户;此帐户已过期;然后,地址A创建一个新的账户(例如,使用CREATE2操作码确保两次生成的账户地址相同);最后,地址A再次尝试复活原账号。这个时候会发生什么?

有几种可能的解决方案:

明确的“账户合并”流程:类似于“除两个账户累计ETH余额外,以旧账户状态为准”或“除累计ETH外,以新账户状态为准”的规定;甚至,特殊的合并过程可以由旧账户的合同代码指定

通过消除相同地址重复部署的功能,不会发生复活冲突:即调整CREATE2的功能,比如将当前时间包含在最终哈希成地址的数据原图中,这样即使以后使用相同的数据生成,也无法获得相同的地址。

在状态对象中添加一个“存根”,防止在同一个位置生成新的账户(上面提到的树流方法自动实现了这个功能)

当需要生成一个新账户时,必须附带一个该账户之前未过期的证书:某种意义上相当于存根方案,但这种方法是将存根放在一个单独的状态部分,所以任何想要创建合同账户的用户都必须跟踪这部分状态。

(请注意,如果我们使用插槽到期方案,上述任何解决方案都必须扩展到单个插槽级别,而不是帐户级别。)

主要关注的是:(1)会给应用增加很多复杂性,他们需要加入合并的逻辑;(2)这样做之后,除非在链中“注册”了一个地址,否则用户再也无法轻松获得一个可以与之交互并积累资产的地址(比如ERC20令牌)。未注册地址很重要:任何第一次接收ETH的用户都是在使用未注册地址。这种担心的根源(2)是未注册地址其实是有时间限制的。如果用户生成一个地址并收到资金,但忘记在下一年发送交易(即忘记“注册”),他的资金将被锁定。

请注意,EOA也不能幸免。虽然看起来有可能,因为EOA的合并过程比较简单(把旧的ETH余额加到新的就行,EIP 169为nonce)。然而,这里有两个问题。首先,账户抽象的目标是用契约取代EOA,但账户抽象契约的合并过程可能并不简单。其次,不仅是EOA本身,EOA参与的应用中的相关存储密钥(如ERC20令牌余额)也会受到到期和复活事件的影响,因此仍然需要复杂的合并逻辑。

因此,在我看来,破坏性最小的是某种形式的存根方案。但是存根方案中存在一个信息论问题,会导致一些奇怪的结果。为了防止在n个过期状态对象位置创建新的状态对象,覆盖这n个地址(和/或存储密钥)的集合必须是状态的一部分。如果这个集合是信息最小化的(即O(N);包含这些地址),那么这个集合的大小将是O(N),所以它的状态规模也是O(N);那么,活跃状态的规模就会和不活跃状态的规模成正比,所以其实我们并没有解决这个问题。

树木腐烂

解决这个问题的唯一办法就是覆盖那N多个账号的信息;实际上,我们将不得不使整个树不可访问(这再次是树流解决方案的本质:如果两个帐户过期,它们之间的所有空间也隐式过期)。

这里还有一个问题:这造成了一种“树腐”的形式。随着时间的推移,状态树的所有部分对于创建新帐户都是不可访问的,至少对于那些没有跟踪该区域过期状态的用户是如此。

而发霉的树木带来的二次问题,必须解决。例如,如果合同想要创建子合同,它必须能够在用户有或没有见证数据的状态区域中创建合同(可能需要用户提供“提示”)。发霉树木问题的解决方案可以在这里找到:一个持续开放的新区域,用于创建帐户。另一个想法是,每个用户选择状态的特定区域(例如,状态的1/256),跟踪区域的变化(包括过期状态),以便创建见证消息并仅在区域中创建帐户。

发霉树的另一个问题是,它们需要一个显式的数据结构来存储和检查范围。如果树中有可以放在节点中的数据,并且指出节点下的哪些部分已经过时(如树流解决方案所使用的),这是最好的,但是键值对存储很难做到这一点。

回头再看强无状态性

在状态失效方案中使用树形结构导致的许多问题可以追溯到这样一个事实,即我们需要就哪些状态是活动的,哪些是非活动的达成共识。这在双树流模式下更加明显。但是,即使在树流模式下,也需要显式标记状态树,以便最近通过使用快速同步下载状态的以太网节点可以确定尝试访问帐户而不提供见证消息的事务应该成功还是失败。我们能确保我们不需要弄清楚这种区别吗?

如果我们实现了完全无状态,那么我们就可以帮助事务发送者和阻止生产者可靠地获得生成见证消息所需的状态,这样岂不是解决了这个问题?那么,什么可以帮助事务发送者和阻止生产者这样做呢?

一种自然的方式是,网络中的所有节点只保存状态树的一部分,例如,过去一年访问过的部分。只需在客户端设置中添加一个自愿设置。如果我们想更可靠,我们可以通过引入托管证明方案,强制至少矿工(后面是PoS验证者)存储一些数据。

需要注意的一点是:如果共识层不能感知哪些状态是活动的,哪些状态是不活动的,那么访问最近状态和旧状态的气体成本是相同的。这导致两个结果:

访问最近状态的气体开销也需要进一步增加

包含见证消息的块大小上限可能非常大,如果一个块中充满了访问旧状态的事务(大约800字节* 12.5 m gas/2400 gas每次访问~=4.1 MB,假设EIP-2929已经实现并变成二叉树)

如果我们想避免这些缺点,我们需要跟踪哪些状态对象(包括未填充的地址空间区域)在共识中是活动的,这将使我们回到接近状态到期方案的属性。这再次表明,“无国籍状态与国家期满(国家租金)”是一个光谱,一个复杂的权衡空间,而不是一个非此即彼的选择。

上卷(中文翻译)是

Rollup 也需要,也可以,使用同样的解决方案

以太网重要的中期可扩展性解决方案。但是,汇总本身不再需要担心状态数据的大小;实际上,上卷系统的状态规模问题和以太链本身的状态规模问题是完全一样的。

幸运的是,如果我们能想出一个解决方案,至少EVM上卷(试图最大限度地复制以太网运行环境的上卷方案)可以使用相同的解决方案来解决其内部状态的规模问题。因此,状态大小管理方案是对可伸缩性方案的补充,如汇总和切片(s硬化和其他伸缩策略)。

(译者注:个人认为这里的“补充”一词存在严重误导。)

结论

状态规模是一个不断恶化的问题,状态规模的求解可以为大幅度提高区块Gas上限铺平道路。我们应该就某种形式的国家到期计划达成共识并实施它。然而,在不同的解决方案之间有重要的技术权衡,特别是如果我们想要保持当前设计的一些重要属性。

我们可能需要牺牲的一些属性包括:

用户可以在该地址离线生成帐户并接收资金,并且可以在该地址出现在链上之前的任何时间内保持属性沉默

地址保持20字节的长度(滚动状态扩展方案需要更多的地址空间,尽管出于防冲突的原因,可能需要快速更改地址的长度)

状态可以看作是“纯”键值对存储的一个属性,一个不需要在状态树的每个节点存储元数据的属性

现有应用程序需要不同程度的重写,以确保用户可以生成见证数据,而无需存储所有停用的状态。

用气量;或者创建新合同和写入新存储槽的难度

如果我们准备做出牺牲,一些项目很快就可以实施。另一方面,也许随着时间的推移,我们可以修复或更好地总结这些概念,减少问题,特别是使它们在技术上更容易实现(例如,允许使用“纯”键值对存储)。我们应该更深入地了解我们更愿意/不太愿意接受哪些牺牲,并继续积极研究改进建议。

原始链接:

https://hackmd . io/@ hwen w8 hnrimm2m 2g h56cw/state _ size _ management

作者:Vitalik Buterin

翻译:阿健

微信二维码
售前客服二维码

文章均源于网络收集编辑侵删

提示:仅接受技术开发咨询!

郑重申明:资讯文章为网络收集整理,官方公告以外的资讯内容与本站无关!
NFT开发,NFT交易所开发,DAPP开发 Keywords: NFT开发 NFT交易所开发 DAPP开发