--- title: "我们如何为 Solana 设计可扩展性架构" description: "我们从零重建 Solana 平台时如何应对可扩展性问题，以及如何为接下来的发展做好准备。" --- # 我们如何为 Solana 设计可扩展性架构 [Solana](https://www.alchemy.com/solana) 与其他区块链都不一样。它的架构从第一天起就为把吞吐量推向硬件极限而设计——并行执行、内嵌计时机制、无需 mempool 的交易转发——这些机制共同作用，实现了每秒数千笔交易、亚秒级最终确认。而随着 Firedancer 已在主网上线、Alpenglow 也已在路上，这个上限即将大幅提升。 要构建跟得上这种节奏的基础设施，光靠快速的节点是不够的。这需要在技术栈的每一层设计时都假定：明天的负载会远超今天。 这正是我们从零重建 Solana 平台时对可扩展性的思考方式——也是我们为接下来的发展所做的布局。 ## Solana 的可扩展性模型从根本上有所不同 许多区块链基础设施都是围绕 Ethereum 的执行模型设计的：顺序交易处理、全局状态树、相对有限的数据输出。Solana 打破了这些假设。 Sealevel 是 Solana 的并行运行时，它要求每笔交易预先声明其读写集，从而使互不重叠的交易能够在多个 CPU 核心上同时执行。Proof of History 将一个加密时钟直接嵌入账本，消除了其他链上拖慢共识的协调开销。而 Gulf Stream 会将交易直接推送给下一个区块生产者，而不是让它们滞留在 mempool 中，从而进一步降低确认延迟。 结果是这个网络以极高的速度产生海量数据——峰值速度下每年超过 4 PB。要为这些数据提供服务，基础设施不能只是套用不同 RPC schema 的 Ethereum 方案，而必须围绕 Solana 特有的数据模式、访问特征和规模来架构。 正是这种认知塑造了我们所做的每一个决策。 ## 围绕 Solana 的数据特征进行架构设计 Solana 的数据特征带来了一系列特定的基础设施挑战。区块体积大、密度高。历史查询跨越的范围极大。开发者既需要随机的单点查找（按签名获取单笔交易），也需要大规模的顺序扫描（遍历某地址的完整签名历史）。而且这一切都需要在全球范围内以低延迟完成。 我们在[另一篇工程博客](https://www.alchemy.com/blog/how-alchemy-built-the-fastest-archival-methods-on-solana)中详细介绍了归档架构的技术细节——HBase 迁移、三重验证的数据摄取、自愈流水线，以及让我们在 `getTransaction` 上达到每区域 100,000+ RPS 的具体优化。而本文要讲的是这些决策背后的设计原则。 核心原则是：**把需要独立扩展的关注点分离开来。**传统的 Solana 基础设施将数据摄取、存储和服务捆绑在单一的、庞大的验证者节点中。这种耦合意味着你无法轻松扩展读取能力，无法在不停机数小时的情况下重启服务，也无法在不触及整个技术栈的情况下优化存储布局。 我们将系统拆解为独立的服务——能在数秒内启动的轻量级 RPC 服务器、对各实例处理哪些数据类型有精细控制的专用数据摄取器，以及专为 Solana 访问模式设计的存储层。每一层都按其自身的节奏扩展。当流量激增时，我们可以在数秒内针对同一存储层启动额外的 RPC 实例。当需要上线新区域时，存储层可以独立于服务层进行复制。 ## 可靠性是可扩展性的前提 基础设施领域有一个常见模式：团队为速度做优化，撞上扩展性的瓶颈，然后才发现这堵墙其实是可靠性问题。连接中断、数据不完整、负载下的静默故障，这些本质上都是伪装成扩展性问题的可靠性问题。 我们从一开始就是按这个思路设计的。我们的多区域架构包含 3 到 5 层的自主故障切换——如果某个节点、某个机架，或整个区域出现故障，流量会自动重新路由。 在数据完整性方面，每条记录都会被写入两次、以程序化方式验证，并持续扫描以检查完整性。一旦出现差异，我们的自愈流水线会自动重新摄取并修复缺口——每个区块最多会交叉核对 30 到 50 个相关地址。整个修复过程是自动化的，持续运行。这不是那种带告警的静态监控面板。 Solana 上的数据完整性，是一个比大多数人意识到的更难解决的问题。数据的体量和速度意味着即便是很小的缺口也会迅速累积——这也是开发团队中普遍存在的痛点，许多团队都反映过其基础设施提供商出现数据缺失或不一致的情况。这类问题往往在开发者的应用因交易未被索引、或签名历史不完整而出问题之前，都不会显现出来。我们把正确性当作不可妥协的底线，而不是尽力而为的目标。 最终结果是 99.99% 的正常运行时间，这背后是我们 8 年多以来运营的同一套严谨标准，支撑过 Polymarket 大选之夜、World 主网上线等场景。在这个层级上，可靠性不是一项功能——它是让其余可扩展性故事得以成立的前提。 ## 为 Solana 下一阶段的吞吐量做设计 Solana 目前的吞吐量以每秒数千笔交易来衡量。而协议的路线图指向的是数量级的提升，没有为这一走势做好架构准备的基础设施，终将成为瓶颈。 Firedancer 是 Jump Crypto 用 C 语言编写的独立验证者客户端，已于 2025 年末在主网上线。在实验室条件下，它已展示出每秒超过 100 万笔交易的处理能力。其模块化的 tile 架构、内核旁路网络以及并行签名验证，代表了对验证者软件如何使用硬件的一次根本性重新思考。截至 2025 年末，Solana 上大约 21% 的质押由 Firedancer 运行，且这一比例还在加速增长。 与 Firedancer 同步推进的还有 Alpenglow 协议升级，其目标是重写 Solana 的共识机制，将区块最终确认时间缩短到约 150 毫秒。而像 SIMD-0370 这样的提案，则会彻底取消区块级别的计算上限，让区块规模根据硬件实际处理能力来扩展，而不是受制于人为设定的软件限制。 此外，由 [Light Protocol](https://www.alchemy.com/dapps/light-protocol) 开发的 [ZK](https://www.alchemy.com/blog/zero-knowledge-rollups) Compression，将允许使用零知识证明把多个账户状态压缩到单个链上账户中。这解决了 Solana 日益增长的状态存储挑战，并开启了全新的应用设计模式。 我们的基础设施在设计时就考虑到了这些升级。分解式架构意味着我们可以随着吞吐量需求的增长独立扩展每一层。多区域部署提供了在更高流量下处理全球流量所需的地理分布能力。这让我们相对于其他 [Solana RPC](https://www.alchemy.com/dapps/list-of/rpc-node-providers-on-solana) 提供商拥有 2 倍吞吐量优势，而这只是起点，而非上限。 ## 可扩展的基础设施为构建者解锁了什么 可扩展性直接决定了开发者能构建什么。过去八年里，我们一直支持构建者从第一次 API 调用开始，经历此后的每一个关键转折点。像 Circle、Robinhood 和 OpenSea 这样的团队，都在 Alchemy 上从早期原型成长为服务数亿用户的产品。 - 毫秒级的归档查询意味着钱包可以即时渲染完整的交易历史。 - 以最新数据优先的查询方式，消除了为了呈现用户最新动态而需要扫描多年旧数据的必要。 - `getTokenLargestAccounts` 返回 1,000 条结果而非 20 条，让分析平台能对代币分布获得明显更丰富的视图。 - 原生的无 gas 交易，消除了扼杀转化率的上手摩擦。 - 100% 的质押写入确保交易落在真正的区块生产者上，提升确认的可靠性。 这些能力之所以存在，是因为我们把可扩展性当作第一性原理来对待。 ## 前路 Solana 在快速演进。网络容量会不断提升，而构建在其上的应用在规模化之后也会提出更高要求。 我们的承诺是持续走在这条曲线之前：投入更低的延迟、更高的吞吐量、更深入的数据访问能力，以及能够解锁尚不可行用例的新能力。基础设施永远不应该成为构建者在产品上不得不妥协的原因。 我们所描述的一切，今天就已可用。 - 从 [alchemy.com/solana](https://www.alchemy.com/solana) 开始 - 如需定制化基准测试、专项定价或其他需求，请[联系我们](https://www.alchemy.com/contact-sales)。 ## 常见问题 ### Solana 的可扩展性与其他区块链有何不同？ Solana 通过 Sealevel 运行时实现并行交易执行，通过 Proof of History 实现内嵌计时，并通过 Gulf Stream 绕过 mempool，从而实现每秒数千笔交易、亚秒级最终确认，并在峰值速度下每年产生超过 4 PB 的数据。 ### Alchemy 的分解式架构如何提升 Solana 上的可扩展性？ Alchemy 将数据摄取、存储和服务拆分为独立的服务，各自按自身节奏扩展，使 RPC 服务器能在数秒内启动、流量可以在不停机的情况下扩展、新区域可以在不触及整个技术栈的情况下部署。 ### Firedancer 是什么，它如何影响 Solana 的吞吐量？ Firedancer 是 Jump Crypto 用 C 语言编写的独立验证者客户端，已于 2025 年末在主网上线，通过模块化架构、内核旁路网络和并行签名验证，在实验室条件下展示出每秒超过 100 万笔交易的处理能力。 ### Alchemy 如何在 Solana 这种规模下保证数据完整性？ 每条记录都会被写入两次、以程序化方式验证，并持续扫描以检查完整性，自愈流水线会通过每个区块最多交叉核对 30 到 50 个相关地址，自动重新摄取并修复任何缺口。 ### ZK Compression 是什么，为什么对 Solana 很重要？ ZK Compression 由 Light Protocol 开发，允许使用零知识证明把多个账户状态压缩到单个链上账户中，解决了 Solana 日益增长的状态存储挑战，并支持新的应用设计模式。 ### Alchemy 如何在 Solana 上实现更快的归档查询？ 我们使用基于 HBase、针对 Solana 访问模式优化的存储层，结合以最新数据优先的查询方式和多区域架构，在 `getTransaction` 等方法上实现每区域超过 100,000 RPS 的毫秒级归档查询。 ### Alchemy 的 Solana 基础设施在规模化时如何保持可靠？ 多区域架构配合 3 到 5 层自主故障切换、自动化的自愈流水线以及持续的数据验证，共同实现了 99.99% 的正常运行时间，确保在节点、机架或整个区域出现故障时流量能自动重新路由。 ### Alchemy 可扩展的基础设施为开发者提供了哪些功能？ 毫秒级归档查询、以最新数据优先的查询方式、`getTokenLargestAccounts` 返回 1,000 条结果而非 20 条、原生无 gas 交易，以及用于提升确认可靠性的 100% 质押写入。