除了基本的调试和实现事情，我们依然尚有很多其它事情要做。Trinity 还没有实近况态的回填机制（即下载启动块之前的往事件、事务和数据）。今朝激活切换机制的独一要领是从头启动 Trinity，并且尚不清楚 Beam 同步要领所需的最低硬件设置（我们接待各人帮我们汇集相关数据）。

其他要领

简化之后的进程就像下面这张动图所显示的：

快速同步要领有多快？

真正的希望是我们综合了这两者：首先利用引导式快速同步来模仿无状态客户端，，然后逐渐过渡到完全同步模式。我们丢掉了无状态客户端的一个利益，即低硬盘开销，可是我们保存了快速执行最近一个块的利益。通过在当地生存状态输入和状态输出数据，我们减轻了关于无状态客户端的一个重要隐忧，即被大量见证数据 DOS 进攻的风险，Beam 同步要领执行的时间越长，被 DOS 进攻的风险越小。

本文作者利用了 CC4.0 版权协议来限制本文的版权。只需附上作者署名并维持同样的版权划定，即可自由利用本文版权。因此，本译本版权遵循同样的版权划定（担保作者署名，后续利用维持 CC4.0 协议）。

区块见证数据是按需确定的，这就意味着我们无法提前预知需要哪些状态数据（收到一个数据，才气确定下一个需要的数据是什么）。所以我们向对等节点请求数据时，一次只能请求一个状态数据。相反，快速同步一次最多可请求 384 个树节点，这使得 Beam 同步对对等节点的网络延迟更敏感。

跟着时间的推移，缺少的数据会越来越少。留意，假如某个状态从未被会见过，那么客户端将永远不会请求它（因此永远也不会得到这部门状态数据），因此我们在靠山运行另一个历程来填补这些空缺。通过该回填进程，Beam 同步最终会取得所有状态数据并生存在当地，然后节点就可以切换到完全同步状态。

剩下的事情

一个新的阿尔法版本的 Trinity 客户端上周发布，这个版本包罗一个可在高端硬件上运行的 Beam 同步要领原型。

快速同步要领在今朝的主网运行情况下面对一些挑战，因为同步需要下载很大都据，甚至高出 100GB 的数据，所以，大概在上图所示的第二步 “Get All State（得到所有的状态）” 就要卡住很长时间。

每当我想起今朝尚有几多人仍在利用 Infura（通过 Metamask、Gnosis-Safe 等）与链上应用措施交互时，我就感想有点难熬。Infura 的处事很棒，但假如大部门用户都不本身运行节点，显然也不太仇家。纵然长短常有本领且努力性很是高的开拓人员，也不能完全挣脱对 Infura 的依赖。从这点看来，我们仍未完成

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。