Solana 链技术上的别扭之处
内容提要
Solana以高吞吐、低费用著称，但设计更像由高配机器复制的实时数据库：由可预测leader排序交易，并行执行需预先申报账户读写集，程序无状态、可热升级，节点需256GB内存与数Gbit/s网络，历史查询依赖商业RPC与索引器。它将复杂度从链慢转移到硬件、调度与中心化基础设施，虽仍是区块链，却偏离了普通人可独立验证的原始约束。
延伸解读
性能提升的代价：复杂度转移
Solana 的高吞吐和低费用并非凭空而来，而是将传统区块链的“链慢、交易贵”问题转移到了验证者硬件、网络拓扑、leader 调度、账户模型、程序权限、交易构造、RPC 服务和链下索引等多个环节。这意味着，虽然终端用户体验接近互联网应用，但背后的系统复杂度和运维成本显著增加，普通用户难以独立验证整个网络。
并行执行的前提：显式声明账户读写集
Solana 的并行执行依赖于交易预先声明将读取和写入的账户。调度器仅在不冲突时并行处理，这要求开发者提前设计状态分片。因此，并非所有业务都能自动并行，热点账户仍会导致串行和调度错误。这种设计将数据库分片问题转移给了合约开发者，增加了开发复杂度。
可升级性带来的信任转移
Solana 的程序默认可升级，只要保留升级权限，代码即可被热更新。这与“代码即法律”的不可篡改理念相悖，将信任从公开代码转移到了升级权限的持有者。用户可能与可随时更改的后端服务交互，而非不可变合约。虽然这便于快速迭代，但也引入了中心化风险。
去中心化的现实约束：硬件与基础设施门槛
Solana 验证者需要 256 GB 内存、多核 CPU 和数 Gbit/s 网络，RPC 节点建议 512 GB 内存。这种高配置要求使得全节点更像数据中心，验证权容易集中在专业运营商手中。此外，历史查询依赖商业 RPC 和索引器，普通团队难以低成本独立获取链上数据，去中心化在实践层面受到限制。
Q&A
Solana 的 Proof of History 到底是什么？它和 PoW、PoS 有什么区别？
PoH 是一串只能顺序计算、但可以并行验证的哈希序列，用来证明事件的先后顺序和时间流逝，需要与 PoS 等共识算法配合使用。真正处理分叉选择和验证者投票的是 Tower BFT 一类的 PoS 共识逻辑，PoH 主要负责提供一把全网可验证的密码学时钟。
Solana 的并行执行 Sealevel 是怎么工作的？为什么需要预先声明账户读写集？
Sealevel 要求每笔交易必须预先列出将要读取和写入的账户，并标注 signer 和 writable。调度器看到两笔交易的可写账户不冲突，才敢并行执行。这很像高性能数据库的并发控制，把并行性的代价转嫁给了 SDK、前端和应用开发者。
Solana 的程序为什么是无状态的？PDA 又是什么？
Solana 的 Program 是存放 sBPF 字节码的可执行账户，本身无状态；所有可变状态都放在另外的数据账户中，并由 instruction 显式传入。PDA 没有私钥，程序通过种子和 bump 推导地址，并在运行时获得对它的签名能力，用于地址推导和账户所有权管理。
Solana 的交易格式有哪些限制？为什么需要 Address Lookup Table？
Solana 的 legacy 与 v0 交易长期受 1,232 字节上限约束，旧格式最多锁定 64 个账户，每个 Ed25519 签名占 64 字节，recent blockhash 有效期为 150 个 slot。开发者需要使用 Address Lookup Table 把 32 字节公钥压缩成查表索引，并尽量减少 signer、拆分大操作。
Solana 的程序可以升级吗？这对信任模型有什么影响？
Solana 的 loader-v3 程序只要保留 upgrade authority 就可以被升级；只有主动撤销升级权限，程序才会永久不可变。升级时新字节码先写入 buffer account，再替换 ProgramData account 中的内容。这使信任边界从公开代码转移到了 upgrade authority，用户以为在与不可变合约交互，实际可能只是在调用一个可由少数密钥随时热更新的后端服务。
运行 Solana 验证者需要什么硬件和网络条件？
Agave 官方建议验证者至少 12 核 24 线程、256 GB 内存、分别用于 accounts 与 ledger 的高耐久 NVMe；质押节点至少需要 2 Gbit/s 对称网络，推荐 10 Gbit/s。RPC 节点建议 512 GB 内存。文档还明确表示，不建议在 Docker 中运行主网验证者，云环境也需要显著更高的运维能力。
Solana 的低手续费是否意味着没有稀缺资源竞争？MEV 在 Solana 上如何表现？
低基础费不等于没有稀缺资源。在 Solana 中，稀缺资源包括当前 leader 的入口带宽、区块计算预算、热点账户的可写锁、交易包空间和低延迟转发能力。竞争从全局 gas price 变成对 leader 入口、账户锁和转发速度的争夺。结果不是 MEV 消失，而是 MEV 的技术门槛更高、基础设施更集中、普通开发者更难看见完整订单流。
Solana 的历史数据查询为什么依赖商业 RPC 和索引器？
高吞吐意味着海量 slot、交易、账户变更和日志。应用如果需要历史事件、地址行为、代币持仓、程序日志或实时监听，通常必须依赖专业 RPC、Geyser 数据流、Yellowstone gRPC、自建数据库或第三方索引服务。Solana 程序没有像传统数据库那样自动提供业务索引，程序日志也不是可靠、永久、可随意查询的事件数据库。开发者最终仍要把链上数据抽取到 PostgreSQL、ClickHouse、Kafka 或专用索引系统里。
Solana 过去发生过哪些重大事故？恢复方式说明了什么？
2023 年 2 月，异常大的区块与第三方 block-forwarding 服务共同触发重复数据传播，Turbine 的去重逻辑被压垮，网络进入 vote-only mode，最终由验证者人工重启并降级到稳定版本。2024 年 2 月，程序缓存 LoadedPrograms 的实现缺陷导致主网停止 finalization，工程团队发布 v1.17.20，验证者共同选定恢复 slot、准备 snapshot 并重启集群，事故持续约五小时。恢复方式通常是发布统一修复版本、协调验证者、选择共同认可的 slot、从 snapshot 重启，这更像一个由核心开发团队和专业运维商共同维护的全球集群。
Solana 的多客户端进展如何？它能解决根本问题吗？
原实现由 Anza 分叉并维护为 Agave，Firedancer 等独立客户端也在推进。不同团队、不同代码库可以降低单一实现 Bug 让全网同时失败的风险。但多客户端会提高韧性，却不会取消 Solana 路线的根本约束：新的客户端仍然必须跟上同一条高吞吐链，兼容同一套账户锁、交易格式、PoH、Turbine 和状态增长。它降低的是实现集中风险，不是系统复杂度本身。
