Vitalik Buterin       2021-07-15

来源 | r/ethereum

了解这些技术的相关文章：

AMA 部分

bluepintail 提问：

与进行中的升级 (1559、合并和分片) 相比，实现状态休眠机制 (state expiry) 的复杂度怎么样？

Vitalik 回答：

好问题！我会说从以太坊客户端开发者的角度来说，它的复杂性介于 1559 和合并之间。它更大的难度在于基础设施还没建起来，以及要与状态休眠机制长期配合的话需要重写合约 (状态休眠机制不会破坏任何现有的合约，可能除了一些非常病态的情况，但它确实使现有的合约随着时间变得越来越低效，因此它们可能需要在 5-10年内重写，以保持可运行)。

需要构建的一个主要基础设施是提供旧状态的见证数据 (witness)。如果有人有 1 年多没访问过的旧状态，然后他们想发起一个事务访问它的，如果不在它们手上，他们会需要从某处取出该旧状态。有三种可能性：

• 中心化服务器 (etherchain、etherscan......) 采用一个标准化的 API，它会返回旧状态的见证数据
• 用户必须自己找到存档节点，并对其进行 RPC 调用
• 去中心化又易于使用的方案是更难开发的：类似用门户网络 (Portal Network) 存储这些证明

另一项需要实现的是升级所有以太坊基础设施，以使用包含地址周期的新地址格式。

对于合约的主要挑战是，如果你想构建一个长期保持可用的合约系统，那么你将需要以这样的方式：对应新用户的新数据不需要保存在旧地址周期。 如果没有做任何事，那么如果一个 ERC20 代币在周期 0 被创建了，它现在应该是周期 10，然后发送一个 ERC20 代币到一个还未拥有该特定 ERC20 代币的地址，这将需要提供 8 个见证数据 (在时段20时，这会变成需要 18 个见证数据)。因此不是致命的，但会越来越烦人。为了避免这点，ERC20 代币需要采用一种在更新的 (newer) 地址周期上有子合约的结构，把更新创建地址上的余额存储在那些更新的地址周期上。我认为，现在是合约设计者开始认真考虑如何在“后状态休眠机制” 的世界里设计他们的合约了。

dhskiskdferh 提问：

你可以更详细阐述一下智能合约实现将如彻底支持这点吗？乍一看，我想知道如何把状态 (像余额和补贴）转移到一个新地址......我想是可以迁移状态的，尽管我会觉得这是非常贵的交易。

关于如何在未来编写合约以支持这点，请问你有什么洞见吗？谢谢

Vitalik 回答：

以下是一个更完整的"后状态休眠机制" ERC20 代币的概述。

假设 ERC20 合约在周期 C 创建，而它当前处于周期 N。它的每个周期 C, C+1, C+2 .... N 都有子合约。一个地址周期是 A的地址的代币余额会被存储在周期 max(C, A) 的子合约里。

这确保了即使 ERC20 合约失活了，如果你创建了一个新地址，你将不需要提供见证数据 (因为如果你的地址是在周期 N ，那么余额会被存储在周期 N 的子合约里，这不需要见证数据才能编辑，因为 N 是最新的时段)。

只有以下两种情况才需要见证数据：

1. 读取和编辑在最近两个时段都未被访问过的账户的余额
2. 当账户和 ERC20 合约都失活后，第一次设置账户的余额

如果我们真的想，我们可以通过扩展协议来消除第二种情况，使在地址周期 P 的地址 X 可以发送由在地址周期 Q 上的地址 hash(X, P, Q) 所有的代币；这会允许代币持有者使用地址 hash(X, P, Q) 来接收代币，这样 X 就可以发送它们了 (如果 Q 是最近两个时段之一，这就不需要见证数据了)。

另一个想法是只在可用的最近状态周期里存储代币余额 (这样只要发送者的状态是最近的，就永远不需要见证数据才能发送代币给其他人)，且只有在必要时才会用 transfer 函数从历史周期里取周期和汇总余额 (balance 函数也必须这样做；这样balance 函数的使用就不得不减少，且在需要使用时也会节省很多)。

以上内容的总结是：在为长期见证数据最小化做优化和简化代码间有一个光谱，我预计很多合约会更关注代码简化，并只使用最基本的长期见证数据最小化技巧。但我希望易于编码的最佳实践会随着时间推移得到开发和发展。

Kike328 提问：

与某地址直接相关的状态不能在每次与该地址本身有交互时都上传吗？我意思是，创建一些较短的周期，但每次与一个合约有交互时，就上传该合约的所有状态到该周期。我不是完全了解以太坊的状态运作细节，所以可能我说的并不实际和有点愚蠢，但这会解决我们合约开发者对写的合约不适用于未来的担心。

Vitalik 回答：

与某地址直接相关的状态不能在每次与该地址本身有交互时都上传吗？

不能，因为可能会有无限多这样的状态。M 个用户* N 枚代币=M*N 个潜在余额。

PurpleHamster 提问：

Also is state expiry the same as state rent? 状态休眠机制跟状态租金方案一样吗？

Vitalik 回答：

状态休眠机制和状态租金解决的是相似的问题，两个方案所属分类的界限是有点模糊的。现在的 state expiry 方案与 2015-18 年间的状态租金方案间的主要现实差异是：

• 状态休眠机制没有试图对一个接收了给定状态支付租金的某特定区块做审计。相反，它更粗略，按年来计算。这能减少复杂性。
• 不存在“支付租金”这一操作；相反，你只需在正常交易发送过程中访问它，就能延长它的活性时间。
• 如果你的状态失活了，激活它是很简单的；你只需提供一个见证数据
• 使状态失活也不需要有什么操作，这也能减少复杂性
• 有一个“地址周期”机制使得在无须提供见证数据的情况下更容易创建新合约，同时避免复活冲突（这种情况是某状态对象在某位置上失活了，有人发送了一个事务到这个位置以创建一个新的对象，这会与之前在这个位置上但“状态不再可用”的值冲突。）

robmacca 提问：

如果我担心这些数据会丢失，是否有可能为我所有的钱包交易/值 (不是整个网络) 创建见证数据？

Vitalik 回答:

如果你的数据在该状态周期没有被更新，你就必须每年上线一次，并创建一个见证数据，所以不是创建了见证数据以后什么都不用管了。我个人并不担心数据丢失；有很多行动者在存储历史数据，只要它们中的一个是可用的，你就可以对其发出 RPC 请求并获得见证数据。全部数据提供商 (我很确定数据提供商的数量超过 100) 都丢失了它们的数据这件事的概率比遇到 51% 要低得多。

CrustyRat 提问：

Mina 和它的实现对以太坊基金会和实现以太坊无状态这一目标有什么启示吗？

Vitalik 回答:

我们的密码学团队与 Mina 团队在很多场合聊过。我当然希望 Mina 先实现它的目标，因为它是一个更简单的系统，且可以从头开始，但整个状态转换函数完全使用 ZK-SNARK 加密也是以太坊的一个长期目标。尽管在我看来，这与无状态是两个不同的轨道。

BestLucarioFan 提问：

如果所有的存档节点都关闭了，我们只剩下普通节点的话，失活的状态会怎么样？如果你自己不真的存储失活状态的话，是否不可能为失活状态提供见证数据了？

还有，采用了状态休眠机制后，你预计运行以太坊客户端需要多少 GB？即使在很远的未来，这会保持不变吗？（不考虑 gas limit 提升的话）

最后，与 merkle-patricia trie 相比，解析维克尔树 (verkle trie) 的速度会慢多少倍？

Vitalik 回答：

全部存档节点都关闭这件事的可能性似乎是极小的。因为存档节点有好几百个，其中很多是由企业的高水平技术团队运行的。作为一个额外的保护层，我预计门户网络或类似的系统会要求每个普通用户存储一小部分历史状态，并以这种方式进行去中心化备份。

采用了状态休眠机制方案后，你预计运行要给以太坊客户端需要多少 GB？即使在很远的未来，这会保持不变吗？（不考虑 gas limit 提升的话）

根据当前的 gas limit 水平，我预计 50 GB 就可以了，尽管如果 gas limit 提升的话这个数字会增加。

BestLucarioFan 提问：

这很酷，如果只需要 50 GB的话，我想在我家的 PC 运行一个本地以太坊客户端。

这里存储量的减少是否会与轻客户端的引入向叠加？

Vitalik 回答：

在实现了合并、无状态和状态休眠机制后，你会有下列客户端选项可运行：

• 轻客户端：存储要求：50 kB。带宽要求：最低每天 50 kB、每个区块~1 kB。安全模型：同步委员会的诚实多数
• 无状态客户端：存储要求：< 1 MB。带宽要求：每个区块~500 kB。安全模型：完全安全
• 普通全节点：存储要求：50 GB。带宽要求：每个区块100 kB。安全模型：完全安全
• 存档节点：存储要求：1-3 TB。带宽要求：每个区块100 kB。安全模型：完全安全

UnrulySasquatch1 提问：

是打错了吗？为什么无状态客户端需要的带宽是存档节点的 5 倍？

Vitalik 回答：

全节点和存档节点下载的是相同的数据，以与区块链同步。无状态节点需要下载更多数据，因为需要下载见证数据以验证状态 (普通节点不需要是因为它们仅自己保存和维护状态)；这是拥有无状态客户端的折中。

AdvocatusDiabo 提问：

维克尔树好像非常有前景。另一方面，Eli Ben-Sasson 说我们可以生成与今天所需见证数据大小相同的零知识证明 (https://twitter.com/EliBenSasson/status/1405414149925048323)。以及在数年后，可能会有一个新的改良数据结构。我的问题是我们可以把它抽象了吗？是否有可能使底层数据结构不成为协议的一部分，而对于无状态来说，是否可能在没有一个数据结构的情况下也能请求到见证数据？我希望这个问题是有意义的。

Vitalik 回答：

从长远来看，STARKs 肯定是更好的技术，但当前的证明生成还不够快。使用对哈希了的二叉树进行STARK 加密的见证数据的最坏情况会是每个分支 6000 次访问 * 80 个哈希值 (假设最坏情况的深度)= 480000 个哈希值，一个更普遍情况的见证数据会是每个分支 1500 次访问 * 25个哈希值=37500个哈希值。即使是后者也需要非常重型的超并行化机器 (ultra-parallelized machinary)，才能在一秒钟内使用常规的哈希函数 (即 SHA256)生成一个证明。一旦优化了算法的哈希函数 (MiMC、Poseidon、Rescue 等系列) 被证明了是足够安全的，那么STARKs 会变得更可行。至于维克尔树，现在已经可以快速生成证明了。

Routine-Thing 提问：

对于矿工或验证者来说，实现无状态意味着什么？

Vitalik 回答：

这意味着你不需要大量的磁盘空间来做验证者以验证区块。现在，要做区块提议者还是需要有磁盘空间。也就是说，看起来越来越有可能区块提议在将来会变成专业化的作业，验证者不是一定要做区块提议工作；详见：https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725 （中文版）

asdafari 提问：

虽然该提议旨在解决中心化问题，这可能来自 PoS 系统里的 MEV，是保留 MEV 的长期方向吗？如果是，原因是什么？它通过抢跑或尾追交易或三明治夹击等从一般用户手中提取价值，使区块构建者/提议者获益，我认为这是大多数人都认为是不可取的。我有时觉得我在 Uniswap 上的交易已经出现可疑的高滑点了，但这也可能只是我的多疑。

Vitalik 回答：

我真的看不出现在消除 MEV 是可能的。现在有非常多种重要类型的 MEV (例如，交易所的价格套利)，我看不到能把它们消除的方法。我认同应该最大限度地阻止三明治夹击等类似的操作，尽管如此，我觉得更多的专业区块提议者是解决方案的一部分 (例如，大多数 Uniswap 攻击可以通过设置滑点=0 得到阻止，而要做到交易滑点为 0 且交易一致不会失败或浪费 gas，在 Uniswap 上排序成功你交易费支付需要有额外条件，也就是需要专门的交易打包逻辑...)

TShougo 提问：

这可能是个新手问题。修剪 (pruning) 和无状态有什么区别？修剪不是也为全节点减少状态大小吗？

Vitalik 回答：

修剪只意味着移除不再需要存储的旧数据。大多数的以太坊节点已经都是修剪节点了，这帮助我们成功渡过出现过的 gas limit 提升。无状态允许客户端完全不需要存储数据，状态休眠机制允许最近没有被访问过的状态数据也被修剪。

LightningShark 提问：

在使用像维克尔树这样的新概念时，你是如何管理风险的？你是否曾经担心过使用这个方法会有风险？

Vitalik 回答：

维克尔树依靠的是目前已经相当成熟的密码学，即如果它出问题了，Monero 也运行不下去了。

Liberosist 提问：

你预计 rollup 会实现状态休眠机制吗？会有什么不同？还是说像 regenesis 这样的方案在 rollup 里会更常见？

Vitalik 回答：

Regenesis 并不是状态休眠机制的真正竞争者；Regenesis 是同时实现状态休眠和历史数据休眠 (这就是以太坊现在在走的路) 的概念的品牌名。我肯定期望 rollup 也会网这个方向走，只是因为接近主线 EVM 是符合它们的利益的。

temple22 提问：

对合同设计增加的复杂性可能会给开发人员带来更高的准入门槛，你认为这可能是一个需要考虑的问题吗？

尽管我理解状态问题是必须要解决的。

Vitalik 回答：

这肯定会给开发人员增加一些复杂性，尽管目前的设计已经是多年思考与研究如何尽量减少这种情况的结果；这一直是阻止我们在 2018 年开启这个计划的主要原因。因此，我认为我们到了一个地步，是这个提议在给开发者增加复杂性与给客户端或用户大大减少复杂性之间取得一个合理平衡。其他以太坊功能 (例如账户抽象和更好的历史访问工具) 也会同时使开发者的工作更容易开展。

fipasi 提问：

状态休眠机制对维持网络运行是必须的吗？

Vitalik 回答：

理论上，如果我们觉得构建区块和运行一个普通节点需要更多存储是没问题的话，使用无状态就可以维持它运行。但这个路径有中心化风险。

lucadonnoh 提问：

对学习计算机科学的学生来说，有没有什么学习承诺、默克尔树、维克尔树这些东西的好资源？

Vitalik 回答：

可以从阅读我关于维克尔树的文章开始：https://vitalik.ca/general/2021/06/18/verkle.html

lectorlector 提问：

有没有可能用目前的以太坊默克尔树生成一个维克尔树结构，然后生成承诺和证明？这样就可以维持当前以太坊默克尔树的哈希函数了？

例如，生成一个维克尔树证明，它是目前以太坊默克尔树某个根上的一个叶子，

还是说在把原来的哈希函数用在 KZG 承诺和维克尔树上有某些限制，所以需要生成一个用一个不同哈希函数的、新的树结构？(就像在 zkSNARK 中使用 Keccak256 就太贵了，人们因为 SNARK 线路大小限制而使用Mimc或Poseidon等'snark friendly'哈希函数)

Vitalik 回答：

我们需要使用新的承诺的新的树结构，以生成维克尔树证明；证明大小的增加与维克尔树使用代数同态的承诺而不像 SHA256 那样的黑箱哈希值密切相关。

saddit42 提问：

你会担心实施无状态会对现有的和未来潜在的应用造成太大的破坏？你认为是否有破坏性较小的可行路径？

Vitalik 回答：

我不认为无状态会破坏任何应用！状态休眠机制确实会有 (看我上面的回答)，但即使如此，影响也不是那么糟糕 (现有的应用还会继续运作，只是会随着时间推移变得没那么高效)，且应用会有很长的时间来适应。

UkoeHB 提问：

维克尔树需要可信设置 (trusted setup) 吗？如果需要，我很惊讶这点没有在你的博客文章里提到，而尽在延伸阅读里找到。

Vitalik 回答：

如果你使用 Kate 承诺的话，需要 (但是是小型的，因此制作一个就可以有数千个参与者是非常容易的)。如果你使用 bulletproof 类型的承诺，就不用。

ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ethereum.cn，若需长期转载，请联系[email protected]进行授权。