作者：toly，Solana 联合创始人

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

编译：Felix，PANews

每天大约有 100 万个新账户被添加到 Solana 中，现在的总状态已超 5 亿，而快照大小约为 70GB。随着硬件的改进，这些数字本身是完全可管理的，但是 SVM 运行时的目标是提供最便宜的硬件访问方式，为了实现这一点，必须在当前硬件限制内管理状态和内存。

截至 2024 年，最新的 PCI 带宽可以达到 0.5 Tbs 到 1 Tb 的吞吐量。或者每秒 64GB 到 128GB。虽然听起来很大，但如果一个 tx 读取 / 写入为 128MB, 128GBps 的 PCI 带宽会将链的 TPS 限制在 1000 左右。实际上，大多数 txs 访问的是最近加载并缓存到 RAM 中的内存。理想的设计应该是允许加载 1000 个具有 128MB 新状态的 txs，再加上 10k 或更多读取和写入现有缓存状态的 txs。

创建新帐户需要证明该帐户当前不存在。这通常是在每个验证器上自动完成，因为每个验证器都有当前所有有效帐户的完整索引。即使帐户数据不存储在本地，只存储数据的哈希，5 亿个帐户也将是 32 字节的密钥 + 32 字节的数据哈希或者每项 64 字节，即 32 GB。这已经足可以保证 RAM 和磁盘的分离。

在某些快照大小（Snapshot Size）下，如果部分网络出现硬件故障，冷启动新系统所需的时间足以延长最坏情况的重启时间。随着带宽和硬件的改进，情况每天都在变化，而 Solana 并没有接近这个限制，但该限制在任何时间点都存在。

内存和磁盘具有不同的性能特征和限制。如果 SVM 不区分，那么交易和限制就必须针对最坏的情况进行定价，进而限制了性能。在交易执行期间，所有帐户密钥至少必须可用，并且总帐户数量将影响 RAM 和磁盘 PCIi 带宽利用率。快照不能任意增大。理想的解决方案是：

允许将更多不需要 PCI 资源的 txs 打包到区块中

管理总索引大小和快照大小

Chilly、Avocado、LSR。糟糕的名字通常是优秀软件设计的标志。Anza 和 Firedancer 的工程师想出了以下方案。

帐户运行时的缓存由所有实例（instances）进行确定性管理。从更高层次看，这是访问状态的 LRU 缓存。在区块构建和调度期间，该实现（implementation）可以很容易检查帐户，不需要锁定或迭代 LRU 缓存。缓存是用一个非常简单的计数器机制实现。

总加载字节被跟踪为 Bank::loaded_bytes:u64

每个帐户在使用时都用当前运行总数 account::load_counter:u64 进行标记

加载帐户时，如果 Bank::loaded_bytes - Account::load_counter > CACHE_SIZE，则帐户被认为是冷帐户，其大小是根据每个区块的 LOAD_LIMIT 计算

新帐户 load_counter 为 0，因此所有新帐户都是冷帐户

Leader 的调度程序将 LOAD_LIMIT 作为一个水印，类似于写锁 CU 限制。

这种设计的绝妙之处在于，它很自然地适合当前的调度程序。用户只需要担心他们的优先费。调度程序必须处理将所有低于 LOAD_LIMIT 和帐户写锁限制的 tx 放入背包问题。最高优先级的 tx 可以首先加载并使用 LOAD_LIMIT。一旦达到这个限制，所有其他 tx 仍然可以放入一个区块中。因此，验证器可以最大化缓解 txs 的缓存局部性。

Avacado 由两部分组成，状态压缩和索引压缩。首先用哈希替换帐户数据，然后将帐户索引迁移到 Binary Trie / patricia Trie。新帐户必须提供证明，证明他们不在「trie」中。

大致设计如下：

在分配期间，每个帐户每字节绑定 X 个 lamports。

如果 X

压缩是一个多步骤的过程，运行在一个 epoch 上

帐户数据被替换为哈希值（data）

帐户密钥仍处于状态之中

引用压缩帐户的交易失败

解压需要上传类似于加载程序的数据

解压的成本应该与分配一个新帐户的成本相同

估计 75% 的账户在超过 6 个月的时间里没有被访问，而且很可能永远不会被访问。压缩它们可以节省 50% 的快照大小。

这是一个更难解决的问题。仅通过状态压缩，验证器仍然拥有系统中所有可能的有效帐户。创建新帐户需要检查此数据库。验证器存储此数据库的成本很高，但用户创建新帐户的成本很低。要保证新私钥不会与现有帐户发生任何冲突。

Binary Trie mining

Binary Trie 作为快照的一部分被跟踪

想要获得额外 sol 的验证者可以创建一个交易，从状态中删除压缩的帐户 kv 对，并将它们添加到 Binary Trie 中

用户可以在解压过程中将 kv 从 Trie 中移除，从而在不被允许的情况下反向执行此操作（这可能需要在解压时进行原子操作，以便在后台服务压缩帐户时更容易）。

对于验证器，无论它包含多少 kv 对，Trie 根的大小都是恒定的

使用 zkp，每个 tx 可以压缩约 30 个帐户

假设每个区块只有一个，那么压缩 5 亿个账户需要大约 80 天的时间

这个过程的关键之处在于，执行此操作的验证者将获得奖励，但并不是所有验证者都必须执行此操作。如果所有验证器都必须执行此操作，那么所有验证器都必须维护当前 Binary Trie 中的内容，这意味着整个状态必须是快照的一部分。想要维护整个状态的验证器应该提交一个交易，将索引中的 N 个帐户压缩到 Trie 中。

新帐户证明

要创建一个新帐户，用户必须证明该帐户在 Trie 中不存在。维护整个状态的验证器可以生成帐户不在 Trie 中的证明。这给用户带来了负担，他们必须始终与大型状态提供者连接以生成这些证明。

或者，用户可以证明他们的帐户是用最近的 PoH 哈希创建的。支持这一点的最简单的方法是：

生成新的 PKI

帐户地址是哈希（最近的 PoH 哈希，PKI::public_key）

鉴于 Trie 中的帐户必须首先进行状态压缩，这需要一个完整的 epoch。Trie 中的任何帐户都不可能使用最近的 PoH 哈希来生成地址。

其他可以支持的方法是 PKI 创建本身可以提供一个证明，证明私钥是用哈希（用户隐藏的秘密，最近的 PoH 哈希）创建的。