章节有一种办法或许能加快初始实时过程（initial sync process，所指从创世纪块开始的区块链实时），就是用于区块亲眼数据（witness）预先建构出有内存树根（cache trie），来防止速度较快的状态采访。这样做到必须额外闲置硬盘空间和网络带宽，但或许可以大幅度加快实时过程。其中的原理是，一般来说，要继续执行一个区块，我们就必须默克尔树上的一些数据。虽然在某个块继续执行以前，默克尔树上早已有一些数据了，但这些数据有可能足以继续执行区块。所以，长时间来说，我们还要从状态数据库（state db）中萃取出有数据并添加默克尔树上，然后才能检验交易。这个过程可能会极快，因为 硬盘采访/数据库查找 的速度比较慢。根据这个问题叙述，我们可以区分出有三种有所不同的方案：1）长时间流程（也就是当前在以太坊节点中用于的方案）在区块 B 继续执行以前，我们有状态树根 T1；yabo网页登录 在必须继续执行 B 的时候，我们把 T1 中遗漏的数据加到到 T1 上，构成 T1'，T1''，等等。每次遇上 T1 上没的信息，我们就在数据库中查询（速度慢）。继续执行完了 B 之后，我们有了状态树根 T2，T2 不具备继续执行 B 所需的所有账户状态。维持 T2，以待先前用于。2）无状态流程在区块 B 继续执行以前，我们并没状态树根；不过，我们可以获得一个亲眼数据 W，来重组继续执行这个区块所需的状态树根。

我们继续执行 W，取得了状态树根 T2。在 T2 上继续执行区块 B，不必须查询数据库。区块继续执行完了之后就把 T2 毁掉。3）准无状态流程（semi-stateless folw）（即本实验要测试的方案）· 在区块 B 继续执行之前，我们有状态树根 T1，亲眼数据 W1、W2、……，不足以将 T1 并转成 T2· 依序在 T1 上继续执行 W1、W2、……，最后取得 T2，也不必须查询数据库。· 在 T2 上继续执行区块 B，也不必须查询数据库。· 拔着 T2 以待先前用于。在初始实时中用于准无状态流程可以取得无状态流程的大部分益处 †，又不必须传输那么多数据，因为我们器重了状态树根内存。† 在准无状态方案yabo网页登录 中，区块的并行执行不会受到更大的容许那么，为了测试准无状态方案的性能，我们必须测量两件事：· 这一方法必须额外闲置多少 硬盘/比特率？与几乎富状态的方法比起，它知道更佳吗？· 其初始实时速度不会慢多少？本文中我们不会集中于测试硬盘市场需求。创建实验· 状态树根（默克尔树根）的最大规模：100 万个 node。一旦节点数多达这个值，我们就驱赶 LRU 节点，以获释内存。用这种办法，我们就能掌控状态树根对内存的用于。· 部分亲眼数据不会存储在数据库中（我们用的是 boltdb）。每个条目的结构如下：key: [12]byte // 区块号 + 状态树上节点的仅次于数量value: []byte // 亲眼数据，按文档中的叙述不予序列化· 我们会在亲眼数据里存储合约代码（这是我们当前架构的严重不足）。数据按特例方法获得（必须一个实时好的 turbo-geth 节点）(in the turbo-geth repository)make state./build/bin/state stateless — chaindata ~/nvme1/mainnet/mainnet/geth/chaindata — statefile semi_stateless.statefile — snapshotInterval 1000000 — snapshotFrom 10000000 — statsfile new_witness.stats.compressed.2.csv app下载— witnessDbFile semi_stateless_witnesses.db — statelessResolver — triesize 1000000 实验结果存储从创世纪块开始实时 6, 169, 246 （619 万）区块，亲眼数据的数据库（bolt db）超过了 99GB。亲眼数据大小的分位数分析python quantile-analysis.py cache_1_000_000/semi_stateless_witnesses.db.stats.1.