作者：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带宽利用率。快照不能任意增大。理想的解决方案是：
Chilly、Avocado、LSR。糟糕的名字通常是优秀软件设计的标志。Anza和Firedancer的工程师想出了以下方案。
帐户运行时的缓存由所有实例（instances）进行确定性管理。从更高层次看，这是访问状态的LRU缓存。在区块构建和调度期间，该实现（implementation）可以很容易检查帐户，不需要锁定或迭代LRU缓存。缓存是用一个非常简单的计数器机制实现。
这种设计的绝妙之处在于，它很自然地适合当前的调度程序。用户只需要担心他们的优先费。调度程序必须处理将所有低于LOAD_LIMIT和帐户写锁限制的tx放入背包问题。最高优先级的tx可以首先加载并使用LOAD_LIMIT。一旦达到这个限制，所有其他tx仍然可以放入一个区块中。因此，验证器可以最大化缓解txs的缓存局部性。
Avacado由两部分组成，状态压缩和索引压缩。首先用哈希替换帐户数据，然后将帐户索引迁移到Binary Trie / patricia Trie。新帐户必须提供证明，证明他们不在“trie”中。
大致设计如下：
估计75%的账户在超过6个月的时间里没有被访问，而且很可能永远不会被访问。压缩它们可以节省50%的快照大小。
这是一个更难解决的问题。仅通过状态压缩，验证器仍然拥有系统中所有可能的有效帐户。创建新帐户需要检查此数据库。验证器存储此数据库的成本很高，但用户创建新帐户的成本很低。要保证新私钥不会与现有帐户发生任何冲突。
Binary Trie mining
这个过程的关键之处在于，执行此操作的验证者将获得奖励，但并不是所有验证者都必须执行此操作。如果所有验证器都必须执行此操作，那么所有验证器都必须维护当前Binary Trie中的内容，这意味着整个状态必须是快照的一部分。想要维护整个状态的验证器应该提交一个交易，将索引中的N个帐户压缩到Trie中。
新帐户证明
要创建一个新帐户，用户必须证明该帐户在Trie中不存在。维护整个状态的验证器可以生成帐户不在Trie中的证明。这给用户带来了负担，他们必须始终与大型状态提供者连接以生成这些证明。
或者，用户可以证明他们的帐户是用最近的PoH哈希创建的。支持这一点的最简单的方法是：
鉴于Trie中的帐户必须首先进行状态压缩，这需要一个完整的epoch。Trie中的任何帐户都不可能使用最近的PoH哈希来生成地址。
其他可以支持的方法是PKI创建本身可以提供一个证明，证明私钥是用哈希（用户隐藏的秘密，最近的PoH哈希）创建的。
Lightweight Simple Rent，又称 Less Stupid Rent。如何为分配新帐户的成本定价，以及如何确保旧的废弃账户最终得到压缩，并减少系统的整体负载和新用户的价格？
需要恢复租金（Rent）制度。Rent是指当前状态下的账户应该支付X美元/字节/天的费用，就像AWS上的账户支付存储费用一样。
Rent Rate bonding curve
RentRate = K*(state_size)^N
无论当前状态大小如何，如果很小，费率应该很低，如果接近快照限制，费率应该非常高。
Allocation Minimum Bonding Price
账户必须至少存在一个epoch。分配需要将帐户带入Hot状态。热帐户应该在缓存期间存在。
New Account bond = Epoch Slots * RentRate * Account::size
新账户的余额中必须至少有这么多的lamports才能创建。
Hot Account Burn
lruturnverrate = 每个帐户在LRU缓存中平均占用的时间，最大值为1 epoch。这个值可以是一个常数，也可以在链下计算，并作为中位数权益加权常数报告给SVM。
压缩
当（current slot - account::creation_slot) * RentRate * account::size > account::lamports时，压缩帐户并烧毁所有lamports。
上述解决方案，应该会让State很便宜，因为随着时间的推移，未使用的帐户最终会达到lamports 0，并将被压缩。所以数据开销会减少，甚至索引开销也会减少，这将减少当前状态的大小。减少状态的大小将降低超二次分配的成本。
相关阅读：Solana最新研报：生态充满韧性，增长与挑战并存
| 正加财富网内容推荐 | ||
| OK交易所下载 | USDT钱包下载 | 比特币平台下载 |
| 新手交易教程 | 平台提币指南 | 挖矿方法讲解 |
