状态可得性 — GetNodeData DHT 方案
我们将这个方案称为GetNodeData方案,因为它与快速同步方案(fast sync)获取状态的方式差不多。
我的团队正在验证一个 [“状态可得性” 问题](https://notes.ethereum.org/5VVFi_8FRo2hSnTiLFB_6g)的解决方案是否可行。 ## 方案概述 我们的方向大致如下: * 网络是一个分布式哈希表(DHT,很可能构建在 discv5 上)。 * 账户和合约存数据存储在它们各自的 trie 节点中。 * 网络中的节点拥有所有区块头数据。 * 每个区块中新的 trie 数据都以证明的形式发送到网络中。 我们将这个方案称为`GetNodeData`方案,因为它与快速同步方案(fast sync)获取状态的方式差不多。 ## trie 节点 vs 叶节点 + 证明存储 我们选择将数据存储在各个 trie 节点中,因为这样比较简单。 另一种方法是仅存储叶子节点的值和附带的证明。这个方法比较复杂,因为证明需要不断更新。更新证明可以在本地完成,但是需要进行 EVM 计算并广播完整的区块见证消息。EVM 计算成本很高,而完整的区块见证消息很大。 通过将数据存储在各个 trie 节点中,网络节点只需存储这些 trie 数据,并验证新数据的默克尔证明即可。 ## 迄今为止的发现 ### **预期延迟** 基于 DiscV5 DHT 的经验,我们预期网络查询时间约为 100 毫秒。 ### **每笔交易的 Trie 节点** Nick Gheorghita 一直在研究常见交易类型所涉及的 trie 节点的数量。在样本数量较少的情况下,他得到的初步结果是: * 简单价值转移:~ 30 个 trie 节点 * ERC20 转账/批准:~ 50 个 trie 节点 如果延迟为 100 毫秒,则执行`eth_estimateGas`和`eth_call`需要的时间上限分别为 3 秒和 5 秒。我们还可以通过一些基础的优化(如同时查找交易的发送方和接收方)来降低延迟。 我们正在进行更深入的实验,来测量大型主网交易区块的延迟情况。 ### **垃圾回收和冷状态** Brian Cloutier 已经对冷状态访问模式进行了一些调查。 > [关于冷状态的定义,请参见这张术语表](https://github.com/ethereum/stateless-ethereum-specs/wiki/Glossary#cold-state)。 (冷状态:指的是在较长一段时间内无人接触(读取或修改)的那部分状态。) Brian 的发现是,大多数区块都会触及之前 100 万个区块都没有触及的状态(关于这一发现,Brian 可以给出详细论证)。 这就涉及到垃圾回收。 * 如果网络有足够的空间存储完整的归档状态,我们就不需要垃圾回收。 * 如果网络没有足够的空间来存储完整的归档状态,则该网络必须执行某个机制来防止冷状态丢失。 ## 待解决问题 ### **重复数据删除和垃圾收集** 存储 trie 相同的两个合约拥有同样的 trie 节点。 同样地,余额、nonce、代码和状态相同的两个账户的账户数据也存储在同样的叶节点上。如果我们使用节点哈希作为键来存储节点,必须通过引用计数(reference counting)来实现垃圾收集,否则就无法知道从一个 trie 中移除的节点有没有在另一个 trie 中使用。 一种解决方法是,将节点在 trie 中的位置及其节点哈希作为键。这样可以使用排除证明来删除节点,但是会因为需要存储重复数据而造成额外的成本。 一个待解决问题是,这会在多大程度上提高存储需求。 ### **归档 vs 垃圾收集** 我们需要想清楚如何实现垃圾回收,或者说,确认网络是否可以成为归档节点。 解决垃圾回收问题的方案: 1. 移除重复数据删除机制,并使用`(trie_path, node_hash)`作为键来查找数据。 2. 监控网络并主动重新添加冷状态。 3. 弄清楚垃圾回收的子集是否可以仅发生在账户 trie 中的中间 trie 节点上。 4. 确保网络能够像归档节点那样运行。 ### **数据入站** 我们需要将新创建的 trie 数据推送到网络中。网络中的节点预期会存储所有区块头的最新快照,从而将证明与最新状态根锚定。 待解决问题有: 1. 新的 trie 数据的完整区块证明有多大? 2. 区块证明中每个节点各自的证明有多大? * * * **原文链接:** [https://ethresear.ch/t/state-availability-getnodedata-dht-approach-dev-update/8657](https://ethresear.ch/t/state-availability-getnodedata-dht-approach-dev-update/8657) **作者:** Piper Merriam **翻译&校对:** 闵敏 & 阿剑 * * * 本文转自:https://ethfans.org/posts/state-availability-getnodedata-dht-approach-dev-update
我的团队正在验证一个 “状态可得性” 问题的解决方案是否可行。
方案概述
我们的方向大致如下:
- 网络是一个分布式哈希表(DHT,很可能构建在 discv5 上)。
- 账户和合约存数据存储在它们各自的 trie 节点中。
- 网络中的节点拥有所有区块头数据。
- 每个区块中新的 trie 数据都以证明的形式发送到网络中。
我们将这个方案称为GetNodeData
方案,因为它与快速同步方案(fast sync)获取状态的方式差不多。
trie 节点 vs 叶节点 + 证明存储
我们选择将数据存储在各个 trie 节点中,因为这样比较简单。
另一种方法是仅存储叶子节点的值和附带的证明。这个方法比较复杂,因为证明需要不断更新。更新证明可以在本地完成,但是需要进行 EVM 计算并广播完整的区块见证消息。EVM 计算成本很高,而完整的区块见证消息很大。
通过将数据存储在各个 trie 节点中,网络节点只需存储这些 trie 数据,并验证新数据的默克尔证明即可。
迄今为止的发现
预期延迟
基于 DiscV5 DHT 的经验,我们预期网络查询时间约为 100 毫秒。
每笔交易的 Trie 节点
Nick Gheorghita 一直在研究常见交易类型所涉及的 trie 节点的数量。在样本数量较少的情况下,他得到的初步结果是:
- 简单价值转移:~ 30 个 trie 节点
- ERC20 转账/批准:~ 50 个 trie 节点
如果延迟为 100 毫秒,则执行eth_estimateGas
和eth_call
需要的时间上限分别为 3 秒和 5 秒。我们还可以通过一些基础的优化(如同时查找交易的发送方和接收方)来降低延迟。
我们正在进行更深入的实验,来测量大型主网交易区块的延迟情况。
垃圾回收和冷状态
Brian Cloutier 已经对冷状态访问模式进行了一些调查。
关于冷状态的定义,请参见这张术语表。
(冷状态:指的是在较长一段时间内无人接触(读取或修改)的那部分状态。)
Brian 的发现是,大多数区块都会触及之前 100 万个区块都没有触及的状态(关于这一发现,Brian 可以给出详细论证)。
这就涉及到垃圾回收。
- 如果网络有足够的空间存储完整的归档状态,我们就不需要垃圾回收。
- 如果网络没有足够的空间来存储完整的归档状态,则该网络必须执行某个机制来防止冷状态丢失。 ## 待解决问题
重复数据删除和垃圾收集
存储 trie 相同的两个合约拥有同样的 trie 节点。
同样地,余额、nonce、代码和状态相同的两个账户的账户数据也存储在同样的叶节点上。如果我们使用节点哈希作为键来存储节点,必须通过引用计数(reference counting)来实现垃圾收集,否则就无法知道从一个 trie 中移除的节点有没有在另一个 trie 中使用。
一种解决方法是,将节点在 trie 中的位置及其节点哈希作为键。这样可以使用排除证明来删除节点,但是会因为需要存储重复数据而造成额外的成本。
一个待解决问题是,这会在多大程度上提高存储需求。
归档 vs 垃圾收集
我们需要想清楚如何实现垃圾回收,或者说,确认网络是否可以成为归档节点。
解决垃圾回收问题的方案:
- 移除重复数据删除机制,并使用
(trie_path, node_hash)
作为键来查找数据。 - 监控网络并主动重新添加冷状态。
- 弄清楚垃圾回收的子集是否可以仅发生在账户 trie 中的中间 trie 节点上。
- 确保网络能够像归档节点那样运行。
数据入站
我们需要将新创建的 trie 数据推送到网络中。网络中的节点预期会存储所有区块头的最新快照,从而将证明与最新状态根锚定。
待解决问题有:
- 新的 trie 数据的完整区块证明有多大?
- 区块证明中每个节点各自的证明有多大?
原文链接: https://ethresear.ch/t/state-availability-getnodedata-dht-approach-dev-update/8657 作者: Piper Merriam 翻译&校对: 闵敏 & 阿剑
本文转自:https://ethfans.org/posts/state-availability-getnodedata-dht-approach-dev-update
区块链技术网。
- 发表于 2021-03-08 15:22
- 阅读 ( 446 )
- 学分 ( 2 )
- 分类:以太坊
评论