技术

Solana

高吞吐、低手续费的区块链,运行时与 EVM 完全不同。编程模型不同,取舍也不同。

最近审阅: 2026-05-24 审阅人Kevin Riedl wiki ↗

Solana 与 EVM 不兼容。智能合约(在 Solana 里叫「Program」)用 Rust 编写,部署为 BPF 字节码,由 Solana 运行时执行。这套架构为吞吐(每秒数千 TPS)和低费做了优化,代价是验证节点对硬件要求更高、以及一种不同的(有人说更中心化的)去中心化分布。

对于用户支付低于一美分手续费、确认达到亚秒级的消费级应用,Solana 很难被打败。对于与 EVM 生态深度组合的 DeFi,跨链过去的工程量并不小。哪条链合适,取决于哪种取舍对你的产品更重要。

绊倒 EVM 团队的那个坑,举个实际例子:Solana 的编程模型是基于账户的,而不是基于合约状态的。你要显式地把一笔交易触及的每个账户传进去、你要管理账户上的租金(rent)、你从一开始就要考虑并行执行。一支熟练于 Solidity 的团队会习惯性地低估这段爬坡、发布在顺路径下能跑的代码,然后撞上账户所有权和租金方面在 Ethereum 里没有对应物的边缘情况。为这个模型转换预留真实的时间;它不是一次语法翻译。

诚实的取舍,以及「挑那条又快又便宜的链」这个创始人错误:Solana 的验证节点硬件要求高于 Ethereum,所以验证者集更小,历史上也出现过网络宕机(最近少了些)。对消费级支付和高吞吐应用,那个取舍通常是没问题的,吞吐值这个价。对一个核心承诺是抗审查的系统,在假定 Solana 过关之前,仔细审视威胁模型。

生态成本是这个决定的另一半。住在 EVM 链上的那种深度、可组合的 DeFi 和工具链,在 Solana 上并非全都存在,而跨链桥接资产本身就是一项不平凡、对安全敏感的操作,不是一次免费的导入。如果你的产品需要插进现有的链上协议,那股拉向 EVM 的力是真实的,应当与 Solana 的原始性能去权衡。如果你的产品大体自成一体、且受吞吐约束(支付、消费级应用、游戏),性能取胜,更小的生态很少咬你。Wavect 在 web3 栈里 Solana 与 EVM 都做交付。我们没有链偏好;我们有用例偏好。

// FAQ

常见问题

验证节点对硬件要求更高,活跃验证节点数也更少,所以地理与所有权分布更集中。是好是坏看立场:要无许可抗审查,去中心化分布很重要;要消费级延迟与费用,集中度是已经付出的代价。两边都不假装这不是取舍。
账户模型不同:Solana 把代码与状态分离,合约(Program)无状态,数据放在用户拥有的 Account 里。这让并行执行成为可能(同链 TPS 高的根因),但也意味着 Solidity 思路不能直接搬过来。Account 设计错了,性能就掉回 EVM 水平。
消费级支付、游戏、社交、DePIN:用户每次交互成本必须低于一美分、确认必须亚秒级的场景。深度组合 DeFi 反过来更适合 EVM 生态,因为 TVL 与协议互通都在那边。链选错,产品天花板会被运行时压死。