Helius 产品和平台
自动扩展
Helius 的法币计划自动充值机制。当每月信用额度用尽时，自动扩展会购买额外信用，直至用户设定的上限，从而防止429 错误中断生产流量。加密计划没有自动扩展功能。相反，它们使用预付信用，需要手动购买。
查看自动扩展。
信贷
Helius 计费 API 和流媒体使用的单位。RPC 方法、DAS 调用和流媒体吞吐量各有特定的信贷成本。每个计划都包括一个每月的信贷配额，每个计费周期重置（未使用的信贷不结转）。 参见信贷以获取完整的成本表。DAS API
数字资产标准——一个开放规范，为 Solana 数字资产（NFTs、压缩 NFTs、可替代代币）提供统一接口。Helius 的 DAS API 实现以单一结构化响应返回丰富的元数据、所有权和定价，消除了对链上资产数据进行自定义解析的需求。 参见DAS API。专用节点
私人 Helius RPC 节点没有速率限制或信贷计量，以固定月费计费。适合需要无限吞吐量的狭窄用例；大多数应用程序最好由常规 Helius RPC 服务，因为其性能更优、故障转移能力强、功能覆盖全面。 请参阅专用节点。增强交易
Helius 的解析交易 API 可将原始 Solana 交易解码成人类可读的事件——代币转移、NFT 销售、交换、质押操作等——无需每个程序指令解析器。 请参阅增强交易。错误代码
Helius APIs 返回的标准 HTTP 状态代码，带有 Helius 特定上下文：400 Bad Request— 参数无效或请求格式错误（例如，地址格式无效，缺少必填字段，JSON 格式错误）401 Unauthorized— 缺少或无效的 API 密钥403 Forbidden— 访问被拒绝，通常是由于 IP 限制、未包含端点的订阅或 API 密钥权限不足404 Not Found— 请求资源没有可用数据（对于未知钱包的身份查找是正常的）429 Too Many Requests— 信用额度耗尽，超出速率限制或达到并发请求限制5xx— Helius 端问题；请使用指数退避重试
门卫
Helius 的边缘网关通过将请求路由到全球分布的代理舰队，提供显著低于标准 RPC 调用的延迟。通过将mainnet.helius-rpc.com 替换为 beta.helius-rpc.com 来访问。
有关架构背景，请参阅门卫和引入门卫博客文章。
LaserStream
Helius 的高性能 gRPC 流服务，用于 Solana 链上数据，具有历史重放、多区域故障切换，是 Helius 流产品中功能最丰富的集。官方 SDK 提供 JavaScript/TypeScript、Rust 和 Go。 LaserStream WebSocket 在同一基础设施上运行。 有关 SDK 基准的深入探讨，请参阅 LaserStream 和 LaserStream SDK 性能博客文章。LaserStream WebSocket
Helius 的持久 WebSocket 流服务。它在一个统一端点上提供标准的 Solana WebSocket 方法和 Helius 特定的扩展（transactionSubscribe 和增强的 accountSubscribe，具有更丰富的过滤功能）。LaserStream WebSocket 与 LaserStream gRPC 共享后端。
参见 LaserStream WebSocket。
预确认
Helius的最低延迟交易信号。在验证节点的调度程序承诺执行交易的那一刻流传递计划的交易——在它们被收集到条目和分段之前。早于分段交付和处理过的承诺流。通过preconfSubscribe WebSocket订阅传递。需要专业计划或更高；按照每条消息10个信用点计费。覆盖范围取决于哪些验证节点将其流转发给Helius，因此该馈送并不连续。
请参阅预确认和preconfSubscribe。
优先费用API
Helius的费用估算端点，根据实时链上费用市场返回推荐的优先费用值。无需猜测或在拥堵时过度支付，支持竞争性费用定价。 请参阅优先费用API。速率限制
在给定的Helius计划下允许的最大每秒请求数。速率限制根据计划层级和API系列（标准RPC、增强API、流）而不同。超出限制会返回429 Too Many Requests。
请参阅速率限制。
发送者
Helius的专门交易着陆服务，致力于低延迟交易者，结合了优先费用、Jito提示和抵押连接路由，以最大化着陆率。可在https://sender.helius-rpc.com/fast使用。
请参阅发送者。
分段交付
Helius的服务，通过UDP流传输原始Solana分段，在最终区块组装之前交付。Helius从一个分布式的跨区域验证节点网络中聚合分段，以最小化单个验证节点的地理延迟差异。适用于高频交易、套利和其他低延迟应用。原始分段可以在Helius Dashboard自助获取-每IP每月$1,000（专业计划每IP每月$800）。 有关分片如何工作的深入分析，请参阅分片传送和博客文章 赢得毫秒竞赛：分片、激光流和Solana的边缘。抵押连接
Helius付费计划的默认交易提交路径。抵押连接通过Solana协议级别的Stake-Weighted Quality of Service（SWQoS）将交易路由到即将到来的区块领导者，该服务根据验证者的抵押提供优先连接槽，并在拥塞期间减少数据包丢失。Helius的付费计划继承了这种着陆率优势，而无需调用者直接操作高抵押的验证者。 请参阅优化交易和博客文章 Stake-Weighted Quality of Service: Everything You Need to Know。钱包API
Helius的REST API可用于查询Solana钱包的余额、交易历史、转账、身份和资金来源——结构化的，按美元定价的响应，而不是原始RPC输出。除了地址之外，它还接受SNS.sol和ANS域名。
请参阅钱包API。
Solana基础
账户
在Solana上持久存储数据的容器，由32字节的公钥标识。所有链上状态——用户余额、程序代码、代币元数据——都存在于账户中，包括程序本身。每个账户都有一个所有者，这是一个允许修改其数据或提取lamports的程序，并且必须保持最低SOL余额（免租）以持续存在。 有关更深入的介绍，请参阅博客文章 Solana编程模型：Solana开发入门。植物
当前Solana的规范验证者客户端，由Anza维护——原Solana Labs客户端的重塑继承者。对特定植物版本的引用（例如v1.17.31 SWQoS最小抵押门槛）通常将行为固定在客户端的特定版本上。Jito-Solana是一个集成其区块引擎的植物分支；Firedancer是由Jump Crypto开发的独立C语言替代方案。 有关Agave实施的SVM模型，请参阅博客文章Solana Virtual Machine。空投
向某个地址授予SOL或SPL代币。在Devnet和Testnet上，空投通常指从水龙头获取的一小部分测试SOL，用于资助开发钱包；在Mainnet上，指向现有持有者的大量代币分发。Devnet空投可以通过Devnet faucet获取。关联代币账户 (ATA)
一个确定性派生的代币账户，用于持有特定钱包地址的特定SPL代币。每个钱包对于每种代币铸造最多只有一个ATA，使ATA成为查找用户代币余额的标准位置。它使用钱包地址和代币铸造作为种子派生。区块
一种包含一组交易和必要元数据的数据结构，其中包括区块的哈希和前一个区块的哈希，形成不可变的链。区块在插槽期间生成：插槽的指定领导者验证传入的交易，将其打包到一个区块中，并通过Turbine将区块广播到网络中。并非每个插槽都生成区块——如果领导者未能及时生成一个区块，该插槽将被跳过，网络继续前进。 一旦区块获得超级多数的权益加权验证者投票，就被认为是已确认的（参见承诺级别）。 有关更深入的研究，请参阅博客文章理解Solana的槽位、区块和纪元。承诺级别
对交易已包含在链上的置信度程度：processed— 当前领导者已看到但尚未投票；如果区块失去共识，仍可能被丢弃（约0.4秒）confirmed— 超过66%的权益加权验证者对区块投票；历史上，没有已确认的区块被驳回（约0.6秒）finalized— 区块获得超过66%的投票并在其上建立31个后续区块（即Tower BFT最大锁定），使其实际上不可逆转（约13秒）
confirmed 是推荐的默认设置。使用 processed 进行 UI 反馈，使用 finalized 进行高价值操作，如兑换存款或跨链桥接。在 finalized 获取的区块哈希比 confirmed 获取的更早过期，缩短了交易过期前的时间窗口。
请参阅博客文章 Solana 承诺等级是什么？ 以深入了解。
Compute Units (CU)
Solana 用于衡量交易执行的计算工作量，类似于 Ethereum 上的 gas。每笔交易指定一个计算单位限制和一个计算单位价格（每 CU 的优先费以 microlamports 为单位）；两者的乘积决定总优先费用。超过限制会导致交易失败。CPI (Cross-Program Invocation)
Solana 的一种机制，允许一个链上 程序 调用另一个程序，传递账户和指令数据——这种原语使 Solana 的可组合性成为可能。CPI 通过sol_invoke_signed 系统调用公开，该调用验证调用者是否具有被传递账户的适当权限；PDA 允许程序代表他们拥有的账户签名。
被调用程序在调用程序的剩余 计算预算 内操作：如果它耗尽预算或超过设定的限制，整个调用链将失败，包括原始交易。
请参阅博客文章 Solana 虚拟机 以深入了解。
Epoch
大约 432,000 个 Solana 插槽的集合——Solana 更新其验证器集、领导者计划、权益委托和奖励分配的高级组织间隔。目前每个 epoch 大约需要 2 天。 请参阅博客文章 理解 Solana 的插槽、区块和 Epoch 以深入了解。Firedancer
一个由 Jump Crypto 从零开始用 C 语言编写的第二个独立 Solana 验证器客户端。Firedancer 的目标有 (1) 通过独立的实现来记录和标准化 Solana 协议，(2) 改善客户端多样性（没有单个客户端控制超过 33% 的权益），以及 (3) 提高生态系统性能。其架构是模块化的：许多被称为“tiles”（QUIC tile、verify tile 等）的单一用途 Linux 进程通过共享内存进行通信，与 Agave 的单进程设计相对。 Frankendancer 是他们的混合中间体——将 Firedancer 的高性能 C 网络代码与 Agave 的 Rust 运行时和共识代码结合在一起。 请参阅博客文章 What is Firedancer? 以深入了解。指令
Solana 交易中的最小工作单位——单个程序调用，包含相关账户和数据。一个交易打包一个或多个指令，原子执行（要么全部成功，要么全部回退）。 请参阅博客文章 The Solana Programming Model: An Introduction to Developing on Solana 以深入了解。Lamport
SOL 的最小单位：1 SOL = 1,000,000,000 lamports (10⁻⁹ SOL)，以图灵奖获得者 Leslie Lamport 命名，他因在分布式系统中的基础性工作而获奖。原始 Solana RPC 方法以 lamports 返回余额和费用；Helius 的钱包 API自动处理转换。优先费以微 lamports 为单位，即 lamport 的百万分之一（10⁻¹⁵ SOL）。Leader / Leader Schedule
leader 是被分配在给定插槽期间提议新区块的验证器。leaders 由在每个纪元开始时计算的权益加权随机计划选出，因此任何验证器都可以独立推导出谁将在即将到来的 2-3 天时间窗口中领导每个插槽。每个 leader 被分配四个连续的插槽（每个插槽约 400 毫秒，总约 1.6 秒），为他们提供了一个短暂的连续区块生产窗口。 如果领导者未能在他们的时隙内生成区块，该时隙将被跳过——网络继续前进而不是等待缺失的区块。像 Sender 这样的交易发送服务会将签名交易路由到当前领导者和接下来的两个领导者，以最大化着陆概率。 请参阅博客文章 Solana 的共识：Tower BFT 和历史证明 以深入了解。Merkle 树
一种加密树结构，其中每个非叶节点是其子节点的哈希，因此单个根哈希提交整个数据集。验证数据属于树只需要沿叶到根的路径上的兄弟哈希（Merkle 证明），这无论树大小都是 O(log n) 数据。对于深度为 26 的树，该证明是 26 个兄弟哈希（约 832 字节），虽然小但仍然是每叶：这就是 压缩 NFT 所使用的证明形状。ZK Compression 用一个不随数据集增长的固定大小 有效性证明 替代它。 请参阅博客文章 加密工具 101：哈希函数和 Merkle 树解释。程序
一个包含已编译的 sBPF 字节码的可执行账户（即 Solana 上的智能合约）。程序是无状态的——它们读取和写入它们所拥有的数据账户，通过程序 ID（其 32 字节的地址）标识。Solana 配备了一组原生程序（系统、Stake、Vote 等）内置于运行时；其他一切都是用户部署的程序。 请参阅博客文章 Solana 编程模型：Solana 上开发的介绍 以深入了解。程序派生地址 (PDA)
一个从程序 ID 和一组种子派生的确定性地址。PDA 允许程序为它们控制的账户签名，这对有状态程序设计至关重要。PDA 有意在曲线之外，因此不存在私钥。历史证明 (PoH)
Solana 的同步原语——不是共识算法。PoH 提供了一种加密时间戳功能，使验证者可以在无需彼此通信的情况下就事件顺序达成一致。实现：一个连续的 SHA-256 哈希链，在每个验证者的单个 CPU 核心上连续运行，使用每次迭代的输出作为下一次迭代的输入。生成是顺序且单线程的；验证是可并行化的。 PoH 提供定义 区块 何时有效的“滴答声”。领导者必须在给定的 PoH 滴答范围内发布区块——不在范围内的区块被视为跳过。PoH 与 Tower BFT 并行运行，这是实际的共识机制。 参见博客文章 历史证明、股权证明和工作证明解释 获取更深入的了解。租金/免租金
每个 Solana 账户在链上持久存在需要持有的 SOL 余额，与账户的存储大小成比例。账户必须创建为免租金状态：导致账户低于最低限额的交易会失败。一旦免租金，账户将无限期持久存在而无需进一步支付。Sealevel
Solana 的并行交易执行引擎。与 EVM 等顺序虚拟机不同，Sealevel 能够在多个 CPU 核心上同时执行多笔交易。这是可能的，因为每个 Solana 交易在执行开始之前明确声明将读取和写入的 账户，因此调度程序可以在无需运行时分析的情况下识别非冲突批次。 调度规则很简单：涉及不同账户的交易并行运行；仅读取相同账户的交易也并行运行（读取不会冲突）；写入相同账户的交易按顺序运行以防止竞争条件。 请参阅博客文章Solana Virtual Machine以深入了解。Slot
Solana的基本时间单位，在此期间指定的领导验证者有机会产生一个区块。Slots目前目标是400毫秒，尽管实际持续时间可能因网络条件而异。如果领导者在其slot期间未能产生区块，则会跳过该slot——网络会继续下一个slot而不是等待，所以并非每个slot都会产生区块。 请参阅博客文章Understanding Slots, Blocks, and Epochs on Solana以深入了解。SVM (Solana Virtual Machine)
Solana完整的交易执行堆栈——不是狭义的字节码解释器。SVM包含协调执行的Bank组件、Banking Stage调度程序、BPF加载器和sBPF虚拟机本身（一个具有11个通用寄存器和约100个操作码的基于寄存器的VM，为性能进行JIT编译）。这与明确指代单一字节码执行器的EVM有所不同。 Solana程序编译为sBPF，Solana对Linux eBPF的分支。任何具有LLVM前端的语言（C, C++, Rust, Zig）都可以以sBPF为目标。要求交易预先声明账户访问是解锁Sealevel并行执行和Solana本地化费用市场的关键。 请参阅博客文章Solana Virtual Machine以深入了解。Tower BFT
Solana 的共识机制。Tower BFT 是一种类似 pBFT 的算法，它利用 历史证明 的同步时钟，消除了在每个槽上进行同步共识轮次的需要。验证者构建一个“投票塔”——一个连续的投票堆栈，其中每个新投票将之前所有投票的锁定期翻倍，从而以指数方式提高切换分叉的代价。 确认阈值：一旦一个区块获得≥2/3的权益加权投票，它就被确认（违反最终性需要削减≥4.6%的总权益）。一个区块一旦获得投票并加上31个后续区块构建在其之上，即达到 Tower BFT 的最大锁定，它就被最终确定。请参阅承诺等级获取使用指南。 请参阅博客文章Solana 的共识：Tower BFT 和历史证明以深入了解。Turbine
Solana 的区块传播协议。领导者将每个区块拆分为 MTU 大小的shred和 Reed-Solomon 纠删码恢复分片——FEC 速率（通常为 32:32）允许网络即使在大约 33% 的数据包丢失的情况下也能重建区块。然后，领导者通过一个确定性的权益加权对等验证者树转发分片（每个 shred 组由(leader id, slot, shred index, shred type) 种子生成），而不是直接向每个验证者广播整个区块。树（DATA_PLANE_FANOUT = 200）使领导者的出站带宽大致保持不变，无论验证者数量如何，并让区块在 2-3 跳内到达网络，而不是 O(n)。
请参阅博客文章Turbine：Solana 的区块传播。
Validator
Solana 网络中的一个节点，通过在其分配的领导者槽期间生成区块和对其他验证者的区块进行投票来参与共识。验证者按其活跃权益的比例被选为领导者槽。交易机制
地址查找表 (ALT)
一个链上的 Solana 地址表，版本化交易可以使用 1 字节索引而不是完整 32 字节公钥来引用，从而让单个交易最多引用 256 个账户。ALTs 对于复杂的 DeFi 操作是必不可少的，否则会超过交易大小限制。区块哈希
识别最近区块的 32 字节哈希，包含在每个 Solana 交易中以证明新鲜性。区块哈希在约 150 个插槽（约 1 分钟）后过期；过期的区块哈希的交易将被拒绝。客户端在签署之前通过getLatestBlockhash 获取近期的区块哈希。
优先费
每计算单元支付给验证者的小费，以使交易比其他交易更具优先权，从而改善其包含时间。优先费用以每计算单元微 lamports (µLamports/CU) 设定。Helius 的 Priority Fee API 根据最近的链上费用市场提供实时估算。分片
Solana区块的最小单位。区块被拆分（即分割）成shreds，以便通过Turbine在验证器网络上进行并行传播。Shred级别的访问为交易者提供了超低延迟的链上信号，领先于区块组装——尽管预确认更早到达，在预定交易阶段。 查看 原始分片 (UDP) 和 分片传输概述。以权益加权的服务质量 (SWQoS)
一种 Solana 协议级别的机制，根据发送者的权益优先处理当前和即将成为领导者的交易。作为抵御女巫攻击措施，SWQoS 在 Solana 2022 年 4 月 30 日故障后引入，防止低权益或未抵押节点在拥塞期间垄断领导者带宽。 领导者公开两个连接池：约 500 个连接共享给所有未抵押节点，以及约 2000 个以权益加权的连接，按比例分配给抵押的验证者——持有总活跃权益 X% 的验证者最多可以向领导者发送 X% 的数据包。低于约 15,000 SOL 活跃权益的验证者（约占总网络权益的 1/25,000）被视为未抵押。最低抵押阈值在 Agave v1.17.31 中实行。 Helius的质押连接通过将客户交易路由到Solana最大的验证节点，继承了这种着陆率优势，因此调用方在不直接操作大量质押验证节点的情况下受益于SWQoS。 参见博客文章Stake-Weighted Quality of Service: Everything You Need to Know。版本化交易
一种更新的Solana交易格式，支持地址查找表，允许一个交易引用最多256个账户（相比于传统交易的约35个）。对于大多数现代DeFi集成，需要版本化交易。它们通过序列化交易开头的版本字节来标示。代币和资产
压缩账户
压缩账户是指其数据通过交易日志提交到账本中，仅将哈希指纹存储在验证节点状态中，而不是完整数据占用验证节点磁盘上的传统账户槽位。开发者可以像对待常规账户一样处理压缩账户；索引器（如Photon）解析交易日志以重建当前状态，在通过ZK压缩读取或修改账户时，Groth16零知识证明验证完整性。这种模型最适合小数据账户——较大的数据（超过约100字节）会使压缩变得不切实际。压缩NFT（cNFT）
Solana的NFT作为链上并发Merkle树中的一个叶子表示，而不是作为其自己的账户。该树存在于Solana账户中，其状态转换由账本确保；NFT的当前状态由索引器根据交易历史导出，并生成可验证的Merkle证明与树的链上根进行对比。因此，读取cNFT需要像DAS API这样的索引器——标准的Solana RPC无法直接返回cNFT数据。与标准NFT相比，这种模型可以将铸造成本降低高达99%。并发默克尔树
一种 Solana 特定的 Merkle 树 变体，旨在允许多个写入者在同一槽中更新树而不使彼此的证明无效。链上账户不仅存储当前的根，还存储最近有效根的变动日志缓冲区和树冠（缓存的上层节点子集），使验证者能够验证针对仍在缓冲窗口内的任何根生成的证明。树由三个参数定义：最大深度（将叶子数限制为 2^depth），缓冲区大小（变动日志深度——多少次写入可以发生在旧的正在进行的证明变得无效之前），以及树冠深度（在链上租金与较小的交易内证明之间进行权衡）。有效的 (depth, buffer) 对从 (3, 8) 到 (30, 2048) 不等；为实现实用的组合性，保持maxDepth − canopyDepth ≤ 10。
并发默克尔树由 SPL 账户压缩程序实现，是 压缩 NFTs 的基础，通过 Metaplex Bubblegum 铸造为叶子。
请参阅博客文章 Solana 压缩的所有知识。
Groth16
一种 zk-SNARK 证明系统，能够生成固定大小的零知识证明（在 BN254 曲线上为 128 字节，使用点压缩），无论语句复杂性如何，验证为 O(1)。ZK 压缩 使用 Groth16 生成有效性证明，以证明压缩账户属于已知状态的已知根——小证明大小是保持压缩账户交易成本低的原因。 请参阅博客文章 Solana 构建者：ZK 压缩。铸造账户
定义 SPL 代币属性的链上账户——供应，精度，以及铸造/冻结权限。铸造账户的地址是代币的标准标识符（在以太坊术语中为“合约地址”）。SPL Token
通过Solana程序库的（SPL）代币程序在Solana上发行的代币。可替代代币（USDC、BONK、JUP等）是SPL代币；标准（非压缩）NFT也是SPL代币，用供应量1和0小数位铸造。SPL代币大致相当于Ethereum上的ERC-20和ERC-721。Token-2022是一个较新的程序，通过可选功能（如转账费用和机密转账）扩展了此接口。状态树
ZK压缩用于存储压缩账户哈希的Merkle树。链上账户仅持有当前根和最小元数据；实际的压缩数据存储在交易日志中，并由像Photon这样的索引器重建。程序通过传递有效性证明来读取或修改压缩状态，该证明确保账户的声明内容散列为当前根下的叶子。 请参阅ZK压缩。代币账户
链上账户为特定所有者持有特定SPL代币的余额。钱包可以拥有任意代币账户，但惯例是使用关联代币账户（ATA）——由关联代币账户程序创建的每个（钱包、铸币）对的确定性衍生代币账户。Token-2022（代币扩展）
支持可选扩展（如转账费用、机密转账、计息代币、不可转让代币）的SPL代币程序的变体。Token-2022作为一个独立的链上程序运行，具有自己的程序ID，但设计为经典代币程序的兼容继任者，因此SDK通常可以同时处理两者。必须在Token-2022程序下创建铸币以使用扩展功能。 查看博客文章 What are Token Extensions?。有效性证明
一个恒定大小的 Groth16 零知识证明，证明压缩账户声明的内容在特定根的 状态树 中存在。ZK 压缩 程序在读取或修改压缩账户时需要有效性证明；该证明使程序能够验证链下状态，而无需验证者将数据存储在链上。Photon 通过其getValidityProof RPC 方法向调用者公开有效性证明。
有效性证明是区分 ZK 压缩和 压缩 NFT 的关键：cNFT 使用简单的 Merkle 证明（从叶到根的兄弟哈希列表，随着树深度增加），而 ZK 压缩的恒定大小 ZK 证明不会揭示路径或周围的树状态。
查看博客文章 Solana Builders: ZK Compression。
ZK 压缩
ZK 压缩是由 Helius 和 Light Protocol 开发的一种 Solana 原语，它通过将帐户数据提交到分类帐中的交易日志中，并在验证者状态中仅存储哈希指纹，大大降低了链上存储成本。通过从索引的交易数据生成的恒定大小 Groth16 零知识证明，保留了密码完整性。这一原语不同于使用并发 Merkle 树且不使用零知识证明的压缩 NFT。 有关详细信息，请参阅 ZK Compression 和博客文章 Solana Builders: ZK Compression。连接性和流媒体
Geyser
Solana 的插件系统用于将验证者状态变化 —— 账户、交易、槽位、区块 —— 实时流式传输给外部消费者。验证者将 Geyser 插件作为动态库加载；插件在验证者处理状态更新时接收更新，消除了轮询 RPC 以获取更改的需要。Yellowstone gRPC —— 主流 Geyser 插件 —— 通过 gRPC 公开这些更新。Helius 的 LaserStream 实现了 Yellowstone gRPC 接口，并增加了历史重播（最多约 216,000 槽位 / 约 24 小时）和多区域故障转移等功能。gRPC
gRPC 是一种通用的高性能二进制 RPC 协议（“gRPC Remote Procedure Call” 的递归缩写）。在 Solana 环境中，“gRPC”通常指的是 Yellowstone gRPC —— 一个基于 Solana Geyser 插件系统建立的流式接口，通过 gRPC 提供账户和交易更新。Helius 的 LaserStream 服务建立在基于 Yellowstone 的接口上，增加了历史重播、多区域故障转移和托管基础设施等功能。RPC
RPC 代表远程过程调用，这是一种将服务器方法调用为本地函数的通用模式。在 Solana 中，“RPC”最常指的是 RPC 节点——一个跟踪 Solana 状态的节点，但不参与共识，专注于通过 JSON-RPC 接口提供数据请求（即账户状态、交易历史、交易提交）。相比之下，验证者负责生成区块并对其进行投票。Helius 的 RPC 服务是一个全球分布的 RPC 节点群，针对生产工作负载进行了优化。 请参阅博客文章 Solana Nodes — A Primer on Solana RPCs, Validators, and RPC Providers 以深入了解。Webhook
Webhook 是由服务器发送到接收器 URL 的 HTTP POST 请求，当订阅事件发生时——这是“反向”HTTP，其中服务器初始化调用。Helius Webhooks 将 Solana 链上事件（转移、NFT 销售、自定义程序活动）推送到注册的端点，消除了轮询的需要。WebSocket (WSS)
WebSocket 是一个从 HTTP 升级的持久双向 TCP 连接，用于 Solana 数据的基于推送的流传输，而无需重复 HTTP 请求。WSS（WebSocket Secure）是通过 TLS 运行的相同协议，是用于生产 Solana 连接的变体。LaserStream WebSocket —— Helius 的 WebSocket 流产品，包括标准 Solana 方法和类似transactionSubscribe 的 Helius 扩展 —— 使用 WSS。
生态系统
Anchor
Anchor 是一个用于快速安全地构建 Solana 程序的 Rust 框架。它通过过程宏处理账户序列化、验证和指令分派等样板代码，使开发者可以专注于程序逻辑而不是底层细节。大多数 Solana 开发者使用 Anchor 而不是用原生 Rust 编写程序。 请参阅博客文章Anchor 入门指南：构建 Solana 程序的初学者指南进行深入了解。IDL
IDL 代表接口定义语言。IDL 是一个 JSON 模式，用于描述 Solana 程序的指令、账户和数据类型；客户端使用它来构建交易并解码程序数据，无需手动滚动指令布局。Anchor 自动生成 IDLs 并默认在链上发布，以便公众发现。Jito
一家 Solana 生态系统公司，运营着网络的主要区块引擎——一个 MEV（最大可提取价值）基础设施层，接受交易包（一起执行或完全不执行的原子交易组），并允许搜寻者支付小费给验证器以优先处理它们。 Jito-Solana 验证器客户端是 Agave 的一个分支，集成了区块引擎。包括需要至少 10,000 lamports 的最低小费，并且 Jito-Relayer 持有入站流量约 200 毫秒以支持链下包拍卖。 Helius 的 Sender 通过质押连接和 Jito 的区块引擎同时提交交易，并选择首先成功的路径。 请参阅博客文章Solana MEV：简介。Light Protocol
由 Solana 协议团队与 Helius 共同开发的 ZK Compression。Helius 构建了规范索引器 (Photon) 并运营公共 RPC；Light Protocol 构建索引器所依赖的链上程序和证明栈。 请参见 github.com/Lightprotocol/light-protocol。Photon
这是由Helius构建的开源ZK Compression索引器。压缩的账户数据存在于Solana交易日志中而不是账户状态中，因此验证者不会通过标准RPC暴露它——Photon解析Solana交易，重建压缩的账户状态，并通过一个JSON-RPC接口提供，该接口镜像Solana的本地RPC，并包含ZK-Compression特定的方法，如getCompressedAccount和getValidityProof。开发人员可以自行托管，网址为github.com/helius-labs/photon，或使用托管的Helius端点。
请参见 ZK Compression。