|
原文标题：《通告 | 一份新的无状态以太坊路线图》 自上一版无状态以太坊的全面 「路线图」 发布以来已经过去了一段时间，现在很多东西都发生了改变。似乎又到了需要「全都写下来」的时候了。 我们没有在做什么我们没有在解决无状态挖矿的问题。 我们没有在解决 DSA （动态状态访问）问题，也不准备出于执行的目的为事务附加见证数据（witness）。 关键路径很难确定我们的目标到底是什么。但是我认为，只要我们着眼于需求，自然会出现一个目标梯度。 通过区块见证实现无状态验证者我们 希望 / 需要 验证者无需保存完整的状态就能验证区块。一种提议是在协议中要求为区块附加区块见证，以便客户端使用区块见证数据来验证执行区块得到的状态根。 为此，我们需要： A：大大缩小见证（就当前的十六进制帕特里夏树而言，见证数据大小最高可达 100 MB） B：让验证者可以连同区块一起获得可靠的见证 我们使用 Verkle Trie 来解决需求 A ，将证明开支降至恒定大小（从理论上来说，根据当前 1250 万的 gas 上限来估算，证明大小的上限约为 800k，平均约为 200k）。另请参见 「 为以太坊状态应用 verkle trie 的提议 」。还值得一提的是，统一 verkle trie 需要修改 我们通过见证消息成为协议运行的一部分（很可能是将其作为区块头中的访问列表）来解决需求 B，以便收到该证明的人确认它是对应区块的正确证明。关于生成并通过 gossip 广播见证的责任归属尚未确定。 通过状态保质期（State Expiry）来抑制状态增长区块提议者（或矿工）依然需要生成区块。我们不建议解决无状态区块挖矿的问题，因为这会将我们的目标变成减轻日益增长的状态维护负担。 我们的目标是对总体状态规模施以经济限制。我们计划通过「状态保质期」来实现该目标。 大致上讲，所谓的状态保质期，就是让状态在一段时间（大约 12 个月）后「失去活性」。失活状态不再由协议管理。任何与失活状态的交互都需要附带一个证明，让失活状态重新恢复活性。该方案不会将任何复杂的「租赁」 机制引入 EVM，但它实际上还是强制实现了「状态租赁」。其结果就是为总体状态规模设置了严格的上限。 次关键路径通过「门户客户端」实现无状态客户端架构当前的 DevP2P 以太坊协议不能很好地支持无状态客户端。即使为支持无状态客户端而修改协议，这也并非易事。也就是说，仅依靠「关键路径」，我们就可以构建出适用于 Eth1+Eth2 合并基础设施的客户端，但是这些客户端对于大多数为了使用 JSON-RPC API 而使用客户端人来说没什么用。 (责任编辑：admin) |