EIP-7864 提议对以太坊状态使用二叉树，与 EIP-3102 相比，它提出了一个单一的平衡树，并借鉴了 EIP-6800 的一些思想，例如账户数据、存储槽和代码块的打包。该提议讨论了稀疏树与非稀疏树，以及用于默克尔化的哈希函数的选择，当前草案提议使用非稀疏默克尔树，并在主干级别压缩分支，使用 BLAKE3 哈希函数。
EIP-7864 的讨论主题
这个 EIP 是对以太坊状态的二叉树提案的重新尝试。与 EIP-3102 相比，它提出了一个单一的 平衡 树，并借鉴了类似于 EIP-6800 的其他想法，这些想法与 Verkle 无关（例如，账户数据、存储槽和代码块的打包）。
基于哈希的状态树由于以下原因重新引起了人们的兴趣：
- 潜在的 PQ 问题
- 证明系统快速发展，并越来越接近通过 SNARK/STARK 实现可行的状态证明。
关于二叉树设计，有两个主要的开放性问题：
- 稀疏 vs 非稀疏
- 使用哪种哈希函数进行默克尔化
关于第 1 点，规范的理想设计是稀疏默克尔树，因为它很简单。这里有一份 文档总结了之前的研究，以应对其缺点。
关于第 2 点，这取决于不断发展的证明器的性能以及所考虑选项的潜在安全问题。
目前的草案提案决定：
- 关于第 1 点，使用非稀疏默克尔树，仅在主干级别（主干 在 EIP 中定义）压缩分支。这旨在避免复杂的扩展节点规则，同时尝试减少用于默克尔化的哈希运算量。后者是必需的，因为目前我们在商品硬件的证明性能方面非常紧张。
- 关于第 2 点，使用 BLAKE3，这是一个真正的（~乐观的）候选者。目前的草案这样做是因为它可以帮助 EL 客户端尝试实现，而无需太多摩擦。如果 Poseidon2 被 证明是安全的，则可以通过描述
32-byte→[Field] 编码轻松调整 EIP，而不会对设计的其余部分产生太大影响。使用 Poseidon2 还可以重新开启关于“稀疏树”的讨论，因为其证明性能非常高。
以上都不是最终决定，但目前的提案为进一步讨论、研究、PoC 或分析其在主网中的外观提供了坚实的基础。这里有一个针对此 EIP 的 Python 实现 here。
我们欢迎社区中的任何人（例如，核心开发人员、应用程序开发人员、L2）提供反馈并进行协作！
其他说明：
- 我们尚未在其他潜在的“原理”部分中全力以赴，例如预期的 Merkle 证明大小、在 Python 规范中实现它们以及其他潜在的部分。目前的主要目标是增强对整体情况的信心，我们将在稍后对此进行扩展。
- EL 客户端可能对 一个有用的技巧 感兴趣，该技巧用于处理关于内部节点开销的 arity-N 树（请注意，该文档解释了 SMT 的这一点，但同样的想法适用于任何 arity-N 树）。
- Gas 重新建模是 EIP-4762。它可能需要不断调整，但总体方法将是相同的。
The proposed state-conversion strategy ( [EIP-7748](https://eips.ethereum.org/EIPS/eip-7748)) for moving from MPT to VKT/Binary is the same since it is agnostic to the target tree.
从 MPT 迁移到 VKT/二叉树的拟议状态转换策略（EIP-7748）是相同的，因为它与目标树无关。
如前所述，今天的主要障碍是找到一种安全的密码哈希函数，该函数具有一个证明系统，该系统在 推荐硬件（即电路内性能）中具有足够的证明吞吐量。
尽管电路外性能不是主要的决策因素，但我将很快分享在具有推荐硬件的机器上运行的不同哈希替代方案的一些基准测试。此信息将是了解树更新和（非 snark）证明创建性能的第一步。
有关电路内性能基准测试，请参阅 以下文档。
