状态可得性：GetNodeData DHT 计划方案_数据来源

状态可得性：GetNodeData DHT 计划方案

我的团队已经认证一个 “状态可得性” 难题的解决方法是不是行得通。

大家的方位大概以下：

网络是一个分布式系统哈希表（DHT，很可能搭建在 discv5 上）。

帐户和合同存数据储存在他们分别的 trie 节点中。

网络中的节点有着全部区块头数据信息。

每一个区块中澳的 trie 数据信息都以证明的方式发送至网络中。

大家将这一计划方案称之为GetNodeData计划方案，因为它与迅速同歩计划方案（fast sync）获得状态的方法类似。

大家挑选将数据储存在每个 trie 节点中，由于那样非常简单。

另一种方式是仅储存叶片节点的值和附加的证明。这一方式非常复杂，由于证明必须不断创新。升级证明能够在当地进行，可是必须开展 EVM 测算并广播节目详细的区块印证信息。EVM 核算成本很高，而详细的区块印证信息非常大。

根据将数据储存在每个 trie 节点中，网络节点只需储存这种 trie 数据信息，并认证新数据的内塔尼亚胡证明就可以。

预估延迟时间

根据 DiscV5 DHT 的工作经验，大家预估网络查看時间约为 100 ms。

每单买卖的 Trie 节点

Nick Gheorghita 一直在科学研究普遍交易方式所涉及到的 trie 节点的总数。在样版总数较少的状况下，他获得的基本結果是：

简易使用价值迁移：～ 30 个 trie 节点

ERC20 转帐/准许：～ 50 个 trie 节点

假如延迟时间为 100 ms，则实行eth_estimateGas和eth_call必须的時间限制各自为 3 秒和 5 秒。大家还能够根据一些基本的提升（如另外搜索买卖的推送方和接受方）来减少延迟时间。

大家已经开展更深层次的试验，来精确测量大中型主网买卖区块的延迟时间状况。

垃圾回收和冷状态

Brian Cloutier 早已对冷状态浏览方式开展了一些调研。

有关冷状态的界定，请参照这张术语表。

（冷状态：指的是在很长一段时间内没有人触碰（载入或改动）的那一部分状态。）

Brian 的发觉是，大部分区块都是会碰触以前 100 万只区块也没有碰触的状态（有关这一发觉，Brian 能够得出详尽论述）。

这就牵涉到垃圾回收。

假如网络有充足的室内空间储存详细的存档状态，大家就不用垃圾回收。

假如网络沒有充足的室内空间来储存详细的存档状态，则该网络务必实行某一体制来避免冷状态遗失。

反复数据删除和废弃物搜集

储存 trie 同样的2个合同有着一样的 trie 节点。

一样地，账户余额、nonce、编码和状态同样的2个帐户的帐户数据信息也储存在一样的叶节点上。如果我们应用节点hach做为键来储存节点，务必根据引入记数（reference counting）来完成废弃物搜集，不然就没法了解从一个 trie 中清除的节点是否有在另一个 trie 中应用。

一种解决方案是，将节点在 trie 中的部位以及节点hach做为键。那样能够应用清除证明来删掉节点，可是会由于必须储存反复数据信息而导致附加的成本费。

一个待解决困难是，这会在多多方面上提升储存要求。

存档 vs 废弃物搜集

大家必须想清晰怎样完成垃圾回收，换句话说，确定网络是不是能够变成存档节点。

处理垃圾回收难题的计划方案：

清除反复数据删除体制，并应用(trie_path, node_hash)做为键来搜索数据信息。

监管网络并积极再次加上冷状态。

搞清楚垃圾回收的非空子集是不是能够仅产生在帐户 trie 中的正中间 trie 节点上。

保证 网络可以像存档节点那般运作。

数据信息入站

大家必须将新创建的 trie 数据信息消息推送到网络中。网络中的节点预估会储存全部区块头的全新快照更新，进而将证明与全新状态根导向。

待解决困难有：

新的 trie 数据信息的详细区块证明有多大？

区块证明中每一个节点分别的证明有多大？

全文连接:

https://ethresear.ch/t/state-availability-getnodedata-dht-approach-dev-update/8657

创作者:  Piper Merriam

汉语

标签：

区块链热门资讯