Gate Ventures：详解Solana的技术架构，将要迎来第二春吗？

总结

Solana 是一个高性能的区块链平台，采用独特的技术架构实现高吞吐量和低延迟。其核心技术包括 Proof of History (POH)算法确保交易顺序和全局时钟，Leader Rotation Schedule 和 Tower BFT 共识机制提高区块出块速率。Turbine 机制通过 Reed-solomon 编码优化大区块传播。Solana Virtual Machine (SVM)和 Sealevel 并行执行引擎加快交易执行速度。这些都是 Solana 实现高性能的架构设计，但同时也带了一些问题，如网络宕机、交易失败、MEV 问题、状态增长过快和中心化问题，我们也在本文中着重阐述了这种机制带来的问题。

Solana 生态发展迅速，各项数据指标在上半年都迅猛发展，尤其在 DeFi、基础设施、GameFi/NFT、DePin/AI 和消费者应用领域。Solana 的高 TPS 和面向消费者应用的战略以及品牌效应较弱的生态环境为创业者和开发者提供了丰富的创业机会。在消费者应用方面，Solana 展示了其对于推动区块链技术在更广泛领域应用的愿景。通过支持如 Solana Mobile 和专为消费者应用程序构建 SDK，Solana 正致力于将区块链技术集成到日常应用中，从而提高用户的接受度和便利性。例如，Stepn 等应用程序通过结合区块链和移动技术，为用户提供了新颖的健身和社交体验。尽管目前许多消费者应用程序仍在探索最佳的商业模式和市场定位，但 Solana 提供的技术平台和生态系统支持，无疑为这些创新尝试提供了强有力的后盾。随着技术的进一步发展和市场的成熟，Solana 有望在消费者应用领域实现更多的突破和成功案例。

Solana 虽然在区块链行业中以其高吞吐量和低交易成本获得了显著的市场份额，但它也面临着来自其他新兴公链的激烈竞争。Base 作为 EVM 生态中的一个潜在对手，其链上活跃地址数正在迅速增长，同时，Solana 的 DeFi 领域总锁仓量（TVL）虽然创下了历史新高，但 Base 等竞争对手也在快速占领市场份额，Base 生态的融资额也首次在Q2季度超越 Solana。

尽管 Solana 在技术和市场接受度上取得了一定的成就，但它需要不断创新和改进，以应对来自 Base 等竞争对手的挑战。特别是在提高网络稳定性、降低交易失败率、解决 MEV 问题以及减缓状态增长速度等方面，Solana 需要持续优化其技术架构和网络协议，以保持其在区块链行业的领先地位。

技术架构

Solana 以其 POH 算法、Tower BFT 共识机制以及 Trubine 数据传输网络和 SVM 虚拟机带来的高 TPS 和快速 Finality 著称。我们将要简要介绍其各个组件是如何工作的，如何发挥其高性能的目标以进行架构设计的，以及在这种架构设计下带来的弊端和衍生而来的问题。

POH 算法

POH（Proof of History）是一个确定全局时间的技术，其并不是共识机制，而是一种确定交易顺序的算法。POH 技术是来源于最基础的密码学 SHA 256 技术。SHA 256 通常用于计算数据的完整性，给定一个输入 X，则有且只有唯一的输出 Y，因此对该 X 任何变动都会导致 Y 的完全不同。

POH 序列，图源 ： Solana 白皮书

POH 序列示意图，图 源： Solana 白皮书

在 Solana 的 POH 序列中，通过应用 sha 256 算法就能确保整个序列的完整性，也就确定了其中交易的完整性。举个例子，如果我们将交易打包成一个区块，生成对应的 sha 256 hash 值，那么这个区块内的交易就被确定，任何变动都会导致 hash 值的更改，之后这个区块 hash 作为将作为下一个 sha 256 函数的 X 的一部分，再添加下一个区块的 hash，那么上一个区块以及下一个区块就都被确定下来，任何变动都会导致新 Y 的不同。

这个就是其 Proof of History 技术的核心含义，上一个区块 hash，将作为下一个 sha 256 函数的一部分，类似于一个链条，最新的 Y，总是包含了历史的证明。

交易 Flow 架构图，图源 ： Solana 白皮书

在 Solana 的交易流架构图中，描述了 POH 机制下的交易流程，在一个称为 Leader Rotation Schedule 的轮换机制下，会在所有的链上验证者 Validator 中，产生一个 Leader 节点，该 Leader 节点收集交易并且进行排序执行，生成 POH 序列，之后会生成一个区块传播给其它节点。

Leader 选举机制，图 源： Helius

为了避免 Leader 节点处产生单点故障，因此引入了时间限制。在 Solana 中时间单位是以 epoch 进行划分，每个 epoch 包含 432 ， 000 个 slot（时隙），每个 slot 持续 400 ms，在每一个 slot 中，轮换系统会在每个 slot 内分配一个 Leader 节点，Leader 节点必须在给定的 slot 时间内发布区块（400 ms），否则，就会跳过这个 slot，重新选举下一个 slot 的 Leader 节点。

总的来说，Leader 节点采用 POH 机制能让历史的交易全部确定下来。Solana 的基本时间单位是 Slot，Leader 节点需要在一个 slot 内广播区块。用户将交易通过 RPC 节点给到 Leader，Leader 节点打包交易排序然后执行生成区块，区块传播给其它验证者，验证者需要通过一个机制来达成共识，对区块内的交易以及顺序达成共识，该共识使用的就是 Tower BFT 共识机制。

T ower BFT 共识机制

Tower BFT 协议，图源： Helius

Tower BFT 共识协议来自于 BFT 共识算法，是其的一种具体工程实现，该算法仍然与 POH 算法有关。在对区块进行投票的时候，如果验证者的投票本身就是一种交易，那么用户交易以及验证者交易所形成的区块哈希，也能够作为历史证明，哪个用户的交易细节以及验证者的投票细节都能被唯一确认。

投票图 示

在 Tower BFT 算法中规定，如果所有验证者对该区块进行投票，超过 2/3 的验证者投了 approve 票，那么这个区块就能被确定下。该机制的好处是，节省大量的内存，因为仅仅需要对哈希序列进行投票即可确认区块。但是在传统的共识机制中，一般采用的是区块泛洪，就是一个验证者接收到了区块然后就会发送给周围的验证者，这样就会造成网络的大量冗余，因为一个验证者接收到了不只一次相同的区块。

在 Solana 中，由于存在大量的验证者投票交易，并且由于 Leader 节点中心化带来的高效以及 400 ms 的 Slot 时间，这就导致了整体区块大小以及出块频率都特别高，大区块在传播时，也会给网络造成很大的压力，Solana 采用 Turbine 机制来解决大区块的传播问题。

Turbine

Turbine 区块传播机 制，图源： Helius

Leader 节点通过称为 Sharding 的过程将区块拆分为 shred 的子区块，其规格大小以 MTU（最大传输单元，无需将其分割成更小的单元即可从一个节点发送到下一个节点的最大数据量）为单位。然后通过使用 Reed-solomon 擦除码方案来保障数据的完整性以及可用性。

Reed-solomon 编码方案，图源： Helius

通过将区块分成四个 Data Shreds，然后为了防止数据传输过程中丢包和损坏，因此使用 Reed-solomon 编码将四个包编码成八个包，该套方案能容忍至多 50% 的丢包率。在实际的测试中，Solana 的丢包率大概为 15% ，因此这套方案能很好的兼容当前的 Solana 架构。

在底层的数据传输中，一般会考虑使用 UDP/ TCP 协议，由于 Solana 的对丢包率的容忍度较高，因此采用了 UDP 协议进行传输，其缺点在于丢包时不会重新传输，但是优点在于更快的传输速率。相反，TCP 协议会在丢包时重新多次传输，会极大的降低传输速率以及吞吐量，有了 Reed-solomon 以后，这套方案，能显著增加 Solana 的吞吐量，在真实环境中，吞吐量能够提高 9 倍。

分层传播示意图，图源 ： Helius

Turbine 将数据分片以后，使用多层传播机制来进行传播，Leader 节点会在每个 Slot 结束之前将区块交给任意一个区块验证者，然后该验证者会将区块分片成 Shreds，并且生成纠删码，该验证者之后会开启 Turbine 传播。首先要传播到根节点，然后该根节点会确定哪些验证者位于第几层。其过程如下所示：

1. 创建节点列表：根节点将所有的活跃验证者汇总到一个列表中，然后根据每个验证者在网络中的权益（也就是质押的 SOL 数量）进行排序，权重较高的则位于第一层，以此类推。

2. 节点分组：然后每个位于第一层的验证者也会创建术语自己的节点列表，以构建自己的第一层。

3. 层形成：从列表顶部将节点划分为层，通过确定深度和广度两个值，就能确定整颗树的大致形状，这个参数会影响 shreds 的传播速率。

权益占比较高的节点，在层级划分时，在更上一层，那么就能够提前获得完整的 shreds，此时就可以恢复完整区块，而后面层的节点，由于传输的损耗，其获得完整 shreds 的概率会降低，如果这些 shreds 不足以构建完整的碎片，会要求 Leader 直接重新传输。那么这时数据传输会向树内部进行，而第一层的节点早就构建好了完整的区块确认，约后面层次的验证者完成区块构建之后进行投票的时间就越久。

这套机制的思想类似于 Leader 节点的单节点机制。在区块传播过程中也存在一些优先的节点，这些节点首先获得 shreds 碎片组建完整区块以达成投票共识的过程。将冗余推向更深层次，能够显著加快 Finality 的进行，并且最大化吞吐量和效率。因为实际上前几层可能就代表了 2/3 的节点了那么后续节点的投票也就无关紧要了。

SVM

Solana 能够每秒处理数千笔交易，主要的原因在于其 POH 机制、Tower BFT 共识和 Turbine 数据传播机制。但是 SVM 作为状态转换的虚拟机，如果 Leader 节点在进行交易执行中，SVM 处理速度较慢，那么就会让整个系统的吞吐量降低，因此针对 SVM，Solana 提出了 Sealevel 并行执行引擎来加快执行交易的速度。

Sealevel 并行执行示意图，图 源： Xangle

在 SVM 中，指令由 4 个部分组成，包含程序 ID，程序指令以及读取/写入数据的账号列表。通过确定当前账户是处于读取还是写入状态以及要进行状态更改的操作是否有冲突，可以将账户的交易指令中对状态没有冲突的并行化允许，每条指令以 Program ID 来表示。而这也是为什么 Solana 的验证者的要求很高的原因之一，因为要求验证者的 GPU/CPU 能够支持 SIMD（单指令多数据）以及 AVX 高级矢量拓展能力。

生态发展

Solana 生态 Lands cape，图源：Gate Ventures

在当前的 Solana 生态发展的过程中，越来越偏向于实际的效用，比如 Blinks 以及 Actions 甚至 Solana Mobile 等，而官方支持的应用发展方向也更偏向于消费者应用程序，而不是对基础设施的无限内卷。在 Solana 当下性能足够的情况下，应用种类更为丰富。就以太坊来说，由于其 TPS 较低，因此以太坊生态仍然是以基础设施和扩容技术为主，在基础设施无法承载应用的情况下，也就无法去将构建消费者应用了，这也就造成了资金在基础设施投资过多，但是应用投资过少的不平衡状态。

DeFi

DeFi Landscape， 图源：Gate Ventures

在 Solana 上的 DeFi 协议中，有大量未发币的项目，包括 Kamino（第一 Lending）、Marginfi（Lending + Restaking）、SoLayer（Restaking）、Meteora 等，由于 Solana 的团结生态氛围，通常一个项目在发币的档期，其它项目都会尽量的避开，以吸引足够的市场目光。

DEX 市场份额， 图源： Dune

当前在整个 DEX 方面竞争激烈，其龙头也经历了多次迁移，从 Raydium，Orca 到现在 Jupiter 为主导地位。

DEX 交易的发起人，图源 ： Dune

值得注意的是，DEX 的交易其中大约 50% 都是由 MEV bot 发起的，主要是其低廉的费用和 Meme 交易活跃滋生了 MEV 的有利可图。而这也是导致用户高峰交易失败频发、宕机的主要原因之一。

Solana TVL，图源： Defillama

Solana 上的 DeFi 协议伴随着 SOL 价格的上涨，其 USD 名义 TVL 也赢来了爆发性的上涨。其 TVL 上涨的趋势仍然没有停止，新一波的上涨趋势形成。

总之，Solana 赛道虽然竞争激烈，但是仍然有变，与 Ethereum 上 Uniswap 占据用户的品牌心智不同，尽管是本应该极具粘性和网络效应的 DEX 也会面临被更替的风险。Solana 主链的交易被 MEV bot 充满，这对用户造成了很大的用户体验的问题仍然有待解决。在整体大方向上，Solana 的 TVL 仍然在非常迅猛的增长，其后续的 DeFi 生态发展仍然非常值得期待，并且这些应用的品牌心智对用户的占领并不强，是创业者选择链的潜在动力。

Infrastructure

基础设施 Landscape，图源：Ga te Ventures

在基础设施的构建上，主要的龙头是预言机 Pyth 以及跨链桥 Wormhole，也包括一些针对性的解决方案大众可能了解较少，比如：

1. Jito Labs：专注于构建 Solana 上的 MEV 解决方案，其 Jito Labs 客户端构建了 Bundle 和伪 emempool 来给予 researchers 进行 MEV。目前其市占率超过 50% 。除此之外，其 LSD 协议 Jito 的质押的 SOL 也接近 1200 万枚，并且仍然在高速增长。

2. Helius：Helius 作为 Solana 上的主动的贡献社区，对 Solana 有最全的研究以及通过研究进行代码贡献。

3. GenesysGo：其产品 ShdwDrive 是 Solana 中数据存储项目，其致力于能够商业化落地的项目支持，包括社交数据、网站托管等业务。目前仍然在测试网阶段。同时，其母公司 GenesysGo 也在为 Solana 社区构建各种 public goods 以及研究。

除此之外，Solana 仍有大量值得探索的项目等待中文社区挖掘。我们确实发现，这些基础设施在 Solana 的协议级别构建、生态发展、社区有着巨大的影响力，可能有无论是投资或者合作进一步挖掘其潜力的机会。

Gaming / NFT

Gaming / NFT Landscape，图源： Gate Ventures

Solana 上也有较为丰富的 GameFi 和 NFT 生态，其中 Mad Labs 在整个 Solana 生态中占据比较重要的位置，许多项目空投都会优先考虑 Mad Labs 持有者发放，过去这一龙头的位置是 DeGods。而 NFT 市场也经历了变迁，过去最多人使用的是 Magic Eden，现在转变为 Tensor。

DePin / AI

DePin Landscape，图源： Gate Ventures

DePin 数据概览，图 源： DePin Scan

目前在 Solana 的 DePin 市场上，Render 是有实际业务的当之无愧的龙头。伴随着 solana 以实际应用为中心的发展战略，其也在这轮复苏中，抓住了 Depin 的叙事之风。在上半年，大量新的 Depin 项目搭建在 Solana 之上，其中就包括 io.net、Nosana、Shadow 等。

Consumer

Consumer Landscape，图源：Ga te Ventures

无论是 Solana Mobile，还是 Solana Ecosystem 官网专门为消费者应用程序构建专栏，Actions 以及 Blinks 的发明，都说明了 Solana 对于区块链商业化落地和实用性的愿景。其 Mobile 收集的发布也是在将 Web 端的 dapp 放到移动端，这非常符合人性和互联网发展趋势。因此，应用在这种土壤上容易爆发，最典型的就是 Stepn。

纵览目前在运行的消费者应用程序，其实大部分仍然没有找到很好的突破口，所以仍然无法实现一个真正的应用落地到商业世界，这其中包括了产品创新单一、商业模式单一、对Web2营销乏力、Gas Fee 的需求、代币的入门门槛等多种因素。

但是消费者应用程序是区块链技术最终落地的场景，也决定了公链的天花板。因此 Solana 对于手机端消费者应用程序的探索是非常有必要的，我们对于这个方向的长期挖掘也是必要的。特别是当前以太坊生态中，基建远大于应用的情况下。最终，基建都是为应用服务。

Payments

Payment Landscap e，图源：Gate Ventures

Solana 上的钱包包括了 Phantom、Backpack、TipLink 等。与 DEX 一样，这里的品牌效应并不强，因此创业者有更多的机会，过去钱包龙头是 Phantom，现在转变为 Backpack，其是 Mad Labs 构建，值得一提的是 Mad Labs 现在也是 Solana 上的 NFT 龙头。

Solana 稳定币发行状况， 图源： Defillama

其目前与 Paypal、Visa 等合作进行链上的稳定币支付转账，这个业务场景本身非常有利于快速 Finality 以及低 Gas Fee 的 Solana 链。目前其链上稳定币处于缓慢增长的状态。

稳定币转账堆栈图 Y TD，图源： Artemis

Solana 在上半年具有引人瞩目的稳定币转账的市场份额。但是从 6 月份之后，其市场份额显著下滑。上半年 Solana 表现的绝对亮眼，但是其在下半年的开端转账数据有明显下滑的趋势。

竞争对手数据

链上活跃地址数， 图源： Artemis

在一众公链中，Base 被视为 EVM 生态潜在的 Solana 竞争对手。Base 的链上活跃地址数正在迅猛增加，而 Solana 在具备先发优势的情况下，也仍处于高速增长的阶段。NEAR 维持高位不变，但是 Aptos 以及 Sui 在公链的竞争中落后。

TVL 对比，图源： Artemis

Solana 在 Defi 领域的 TVL 也进展显著，其 TVL 已经创下历史新高，并且与其它公链相比也有一大段距离，但是值得注意的是 Base 也处于高速成长的阶段。

公链稳定币储备，图源：Allium

目前 Solana 的稳定币供应的市场份额一直萎靡不振，Ethereum 由于多链的出现，其市场份额自然缩小，Base 市场份额在悄然增加。

融资数据，图源：Mess ari

在资本市场融资方面，最近一个季度 Base 生态的融资频率大幅增加，并且超过了 Solana 生态。因此，通过各项链上数据的市场份额以及资本融资也能看出，关于市场上 Base 与 Solana 竞争是成立的，并且这种竞争压力伴随着 Base 的成熟，Solana 会面临更大，并且 Base 与 Solana 的愿景相似，都是希望以高 TPS 完成 Mass Adoption 的 Cryptio Native Consumer App 愿景。

面临的技术挑战

宕机

Solana 在历史上经历过多次宕机，我们分别梳理了其具体事件以及宕机原因：

• 2021 年 5 月 4 日

网络性能下降，导致大量交易无法成交

• 2021 年 9 月 3 日

网络不稳定，性能下降，持续时间约为 1 小时

• 2021 年 9 月 14 日

Grape Protocol 在 Raydium 平台上的 IDO 活动火热，许多用户通过编写的机器脚本发送大量交易，这些交易造成「内存溢出」，导致验证节点崩溃，最终整个网络无法出块，中断时间长达 17 小时。

• 2022 年 1 月 21 日

由于市场波动较大，网络充斥着大量套利机器人提交的交易，导致网络引发严重负载，中断时间长达 30 小时。

• 2022 年 5 月 1 日

由于一个 NFT 新项目铸造，大量机器人交易涌现导致主网节点失去共识，之后暂停出块长达 7 小时。

• 2022 年 6 月 1 日

由于交易中的 durable nonce 功能漏洞，导致网络重启，中断时间约 4.5 小时。

• 2022 年 10 月 1 日

由于节点配置错误导致网络宕机

• 2023 年 2 月 25 日

Solana 主网性能出现问题，最终迫使验证者节点自动进入“仅投票”的安全模式，无法处理用户交易。

• 2024 年 2 月 6 日

BPF（Berkley Packet Filter）加载器发生故障，宕机的时间为 4 小时 46 分钟

Solana 由于其网络架构如 Gulfstream Leader 选举机制以及 Leader 节点的单节点风险，导致了 Leader 节点的后续预测变得可行，进而当网络交易增多时，就会对单节点的 Leader 造成很大的内存压力，而 Leader 节点又需要给 Turbine 树中的节点随时准备重新传输区块，否则无法完成共识投票。当大量的 ddos 攻击出现时，单节点故障带来的系统宕机变得极为频繁.

总之，宕机主要是无法出块的问题，有可能是因为 Leader 机制带来的单节点故障，在区块组建处产生问题，也有可能是共识层无法对区块达成共识，导致无法出块的问题。整体而言，这与 Solana 的本身架构以及软件的测试流程有紧密相关。

交易失败

用户失败交易的比例， 图源： Dune

使用过 Solana 的用户应该知道，我们的交易很多时候都无法正常提交，过段时间以后，发现交易失败，这造成了极差的用户体验。如上图，根据统计，用户提交的交易中，其中有 35% 左右的交易是失败的，需要用户多次提交，而在链上有较大波动时，这一比例将更大。

其主要原因是网络层技术 QUIC，这是一项较新的技术。

网络协议层级—— 5 层结构， 图源： Research Gate

QUIC（Quickl UDP Internet Connections）是 Google 提出的，针对 HTTP 2.0 协议的传输层改进。该实验性协议是基于 UDP 传输层协议进行研发，也被称为 HTTP 3.0 。

HTTP/2 与 QUIC 图示 ，图源： EMQX

TCP 可靠性高于 UDP，但是 UDP 的速率高于 TCP，因为 TCP 会在包丢失的时候具备拥塞控制机制，重新传输丢失的包。UDP 速率高，可靠性低，Goggle 希望构建一个可靠性高且速率高的传输层协议 QUIC。QUIC 最核心的特性就是相互独立的逻辑流。它允许在单个连接上并行传输多个数据流，并且每个流可以独立地处理。相比之下，TCP 只支持单数据流，需要按照发送顺序接收和确认每个报文。

失败交易图示， 图源： bread

Solana 宕机的主要原因就是使用了该 QUIC 实验性应用层协议，由于 UDP 以及多路传输的快捷，并且希望保持完整数据的传输，因此其也会设计机制来对丢包情况进行多次重传。Leader 节点在接收多个交易时，是通过 QUIC 协议开启多个通路进行的，但是 Leader 节点毕竟是一台计算机，尤其能够处理的交易容量上线，因此在发生大量的交易涌入时，Leader 节点就会切段某些通路连接，这就会导致交易被 drop。如何选择将被切断的连接并没有一套既定的标准（比如切断所有费用低于 xxx 的连接），所有连接是否会被切断都是随机性的。因此这就导致了存在一定黑箱操作的空间，Leader 节点可能更倾向于有利可图的 MEV 交易，而放弃用户的低价值交易。

MEV

在 Solana 的出块机制中，由于 RPC 是直接与 Leader 进行交互，并且采用 FCFS 的原则，因此其不具备以太坊似的 Mmepool。由于 Mempool 的存在，以及以太坊的 permissionless 原则，相比之下，以太坊面临更严峻的 MEV 问题。

MEV 架构，图源： Helius

Jito Labs 客户端目前占据了 50% 的客户端市场份额，因此 Jito Labs 自己构建了一个伪 mempool，用户通过 RPC 进入一个伪 mempool 停留大约 200 ms。jito labs 提供了一个链下的包含保障，能够保证该 bundle 内的所有交易均包含进区块中。搜索者可以竞标夹层攻击待处理交易的机会，Searchers 通过竞标到利润最大化的 Bundle，然后 Block Engine 负责寻找出竞价最高的 Bundle 提交给运行 Jito Labs 客户端的 Leader。

这是造成 MEV 的根本，但是 MEV 有其正外部性以及需求，如果 Jito Labs 不去做伪 mempool，那么其它项目也会做，因此 Jito Labs 选择吃下这个市场，以改进 MEV 的机制，减轻负外部性。当然，这种对 MEV bot 的需求导致了用户处于最弱势，因为验证者将收取手续费，mev bot 将获得套利的利润的，但是用户遭受更高的滑点和可能失败的交易。

状态增长

Solana 的 POH 机制以及 Turbine 共识导致了其区块过大，这会产生状态增长的问题。目前，账本大小并没有一个确切的答案，而账本还在以实践环境下的每 450 ms 一个区块的速度增长，大约每年增长 4 PB（在 1 GBPS 的最大性能下运行）。目前 Solana 的历史修建发生在 2 个 epoch 之后，大约是 4 天的时间（总共 100-200 GB）。 而过去的数据存储在 Google Bigtable 数据库中 。

关于 Solana 的账本数据并不透明，并且官方对于追求大区块高 TPS 吞吐量而造成了极高的区块大小和潜在影响都没有太多披露，账本的存储也完全依赖于第三方，因为官方也发现 google 等中心化的数据库比 Genesys Go、Arweave 等性能更高，目前这些去中心化数据库仍然存在商业化落地的问题。这种极具增长的状态以及中心化的托管都是 Solana 被诟病的原因之一。

展望

Solana 也释出了其未来的路线图，包括：

1. 改善发行 Token 的协议，包括转账加密、Hook 以及元数据指针。

2. 客户端改进，包括轻量级客户端 Tinydancer、过渡型客户端 Frankendancer、最终客户端 Firedancer。

3. 生态系统的配套开发组件：Gmaeshift 专注于游戏的 SDK、armada markets 专注于 token 代币生命周期改善、SPE 专注于企业级 SVM 区块链、虚拟机改善等。

我们能够看到，Solana 的 POH 算法以及 Turbine 共识机制等都将区块链的三难困境中的性能作为优先级，其好处就是在目前的环境下有着最优秀的性能表现，带来了可探索的应用边界更广。并且伴随着 Solana 以消费者应用程序为战略目标，有很大的可能迸发出一些 Mass Adoption 的应用程序。同时，在 Solana 上的项目品牌效应较弱，因此对创业者也有更多的机会。

Solana 在生态发展上，主要优势在于 DePin/AI 以及 Meme，但是我们也能够看到其生态发展仍然没有达到预想中的发展，Consumer App 仍然无法商业化落地。在竞争对手方面也有 Base 这种后起之秀，Base 的融资额度与市场占有率在迅速提升。

Solana 也面临了一些技术上的问题，包括宕机、交易失败、MEV、状态增长过快以及中心化等诟病，但是 Solana 积极一面就是其并不专注于冗余的基础设施建设，更多是依靠现在的 TPS 容量构建面向消费者的应用程序，而其路线图也围绕此展开。伴随着越来越多的 Layer 2 的构建以及客户端的上线，SVM 生态系统的 TPS 将更上一个台阶。Solana 仍然是一片绿洲，有许多资本没有充分触达的生态项目，对于创业者也有很多机会值得探索。

关于 Gate Ventures

Gate Ventures 是 Gate.io 旗下的风险投资部门，专注于对去中心化基础设施、生态系统和应用程序的投资，这些技术将在 Web 3.0 时代重塑世界。 Gate Ventures 与全球行业领袖合作，赋能那些拥有创新思维和能力的团队和初创公司，重新定义社会和金融的交互模式。

官网： https://ventures.gate.io/
Twitter： https://x.com/gate_ventures
Medium： https://medium.com/gate_ventures