据 @deanmlittle 所述，他质疑在消费级 NVMe 宣称 4KB 随机读超 200 万 IOPS 的情况下，为什么分层存储在 Solana 仍是实际问题，以及既然慢投票/出块已受惩罚，协议为何还要关心验证者的硬件取舍。 Solana 的 AccountsDB 分层存储将冷数据下沉到磁盘，但其设计明确指出更高的磁盘读取延迟会在银行阶段放大账户加载的瓶颈，尤其在混合读写、低队列深度且以领导者为中心的真实负载下，宣称的峰值 IOPS 并不能反映生产环境的有效吞吐（来源：Solana Labs 关于 AccountsDB 分层存储的 RFC，GitHub）。Solana 领导者每个时隙约 400 毫秒，需要完成账户读取、交易执行与区块传播，磁盘支撑的状态在 p99 延迟上升时会压缩出块时间窗口，即使 SSD 的平均 IOPS 很高也可能超时（来源：Solana 白皮书关于 PoH 与时隙）。计算单元对单笔与单区块有上限，因而当存储读取与账户锁成为瓶颈时，提高 CU 上限并不能绕开延迟问题（来源：Solana 文档，Compute Budget Program；Solana Runtime 文档，账户与锁）。 尽管慢投票与漏块会降低投票积分与奖励，但慢领导者仍会占用预定时隙并在惩罚生效前抬升分叉率与确认时间，因此协议需设定最低性能预期以维持整体活性与吞吐（来源：Solana 文档，Staking 与奖励；Solana 文档，领导者排班与共识概览）。Solana 基金会的硬件建议强调高性能 NVMe 与大内存以尽量将热状态留在内存、降低尾部延迟，这表明分层存储必须围绕领导者时序约束而非 SSD 标称 IOPS 进行工程权衡（来源：Solana 基金会/文档，验证者硬件建议）。对交易者而言，由于本地费率市场下拥堵会推高优先费并增加执行不确定性，存储层的性能取舍直接关联到 SOL 链上成本与吞吐表现（来源：Solana 文档，交易费用与优先费；Solana 文档，本地费率市场与拥堵机制）。