Solana 工程周报：性能优化与生态更新

liumuhui 4小时前阅读数 1 #区块链

这是一份关于过去一周 Solana 工程最新动态的每周通讯。如果你希望持续了解 Solana 技术动态，请关注 Solana Changelog（@solana_devs 和 @readylayerone）。

版本发布

值得关注的 feature gate 激活

将 slot 时间从 250ms 缩短至 200ms — Testnet
将 BPF Stake Program 升级至 v5.1.0 — Testnet
将 slot 时间从 300ms 缩短至 250ms — Devnet
将 slot 时间从 400ms 缩短至 350ms — Mainnet

新版本

Agave v4.3.0-beta.0、v4.2.1
Firedancer Mainnet v0.1106.40201
Solana Kit v7.1.1
Token 2022 Program JS SDK v0.15.0
Program Metadata Program JS SDK v0.8.1
Token ACL Gate Program v0.3.0

生态系统动态

社区验证者讨论

2026年8月13日

SIMDs

新增了一项提案，防止 nonce 交易使用自己的 nonce 账户地址作为 program ID。

这意味着： 所有交易指令都必须指定一个 program ID。这防止了一种自引用情况，即存储在 nonce 账户中的 nonce 交易里的某条指令，将这个 nonce 账户自身的地址指定为 program ID。
提出了一项提案，从 runtime 的 stakes 缓存中移除不活跃的 stake。

这意味着： 实际上，存储不活跃的 stake 对处理交易没有用处，而且会存储比必要情况下更多的数据、消耗更多资源。不过，移除它们会对账户 stake 的 lattice hashing（数字签名）产生影响，而后者用于共识。此变更确保移除它们不会对共识产生负面影响。

验证者客户端（Agave、Firedancer、Mithril）

Agave 正在基于其 Accounts DB 实现，努力使 runtime 上的账户加载更加可定制。

这意味着： 这一变更创造了一项新能力，允许基于验证者服务调用所指定的特定条件，在 runtime 上加载账户数据（这需要时间，而优化这一点可以提升性能）。当你想根据诸如账户所有者是谁、账户有多少租金等因素来管理负载时，这会很有帮助。
Agave 正在探索使用专用 worker 线程替代 rayon 实现的 shred 签名验证。

这意味着： 之所以避免使用 rayon crate，是因为其线程池实现无法提供根据负载调整计算资源所需的灵活性。这一探索使得 shred 签名验证可能变得更精简、性能更高。
Agave 正在努力防止 slot rolling。

这意味着： Slot rolling 指的是在一个 slot 中未被处理的交易在另一个 slot 中被处理。这使得执行每 slot CU 限制所需的成本跟踪变得困难。此变更让区块调度步骤针对特定 slot 执行，而不是在达到限制后将交易顺延到下一个 slot。
Agave 正在考虑重构其 Gossip 实现。

这意味着： Solana 的 Gossip 实现允许验证者通过链下方式相互通信，交换诸如其 stake、网络地址等信息。从历史上看，由于多种原因，该服务一直是性能瓶颈；而这个草稿变更探索了更易读、性能更高的 Gossip 会是什么样子。一个值得注意的变化是，它不再使用多个线程来运行该服务，而是使用单个事件循环和 worker 线程。
鉴于上周对程序缓存的变更，Agave 正在继续推进在使程序缓存失效时要求提供程序的部署 slot。

这意味着： 这允许在将程序缓冲区加载到程序缓存时进行更细粒度的控制。runtime 最终可以基于这个新 API 从父 slot（或其他任何 slot）提取程序。这使得程序变更等操作更加直接，也让缓存行为更可预测。
Agave 的 TPU 将在运行签名验证之前，在入口阶段对交易进行 sanitize。

这意味着： 为了确认用户签署了交易，验证者需要验证这些签名确实是由其签名者创建的。不幸的是，这是一项相当昂贵的计算。此变更简化了流程：先根据简单参数（指令数量限制、账户锁定限制等）检查无效交易，从而更容易拒绝一笔交易。
Mithril 很快将允许自己对其他验证者的修复请求保持开放。

这意味着： 验证者并不总能从区块传播阶段收到的 shred 中重新组装出区块，这意味着它无法验证，也就意味着它无法投票。为了解决这个问题，它们会通过 Repair 向其他验证者发出所谓的修复请求（repair request），以获取缺失的 shred。Mithril 将允许自己向那些没有完整区块 shred 集合的其他验证者发送 shred。

Solana 语言客户端（Web3.js、Solana Kit、Kit 插件、Solana SDK、Codama、Solana Go）

对 V1 交易的支持正在以下语言客户端中进行：Web3.js、Solana Kit（之前已有进展）和 Solana Go。

这意味着： V1 交易是将在未来几周发布的新交易模式格式。所有语言和平台客户端都应能够支持它，否则用户可能会遇到错误。

Solana 程序库（SPL）和 Core BPF

Ed25519 Programmatic Signer Program 为其执行器程序添加了一个实现。

这意味着： Programmatic signer 实现是一个用于探索 durable nonce 替代方案的仓库。它已经有一个 signer 程序，用于验证签名并将 PDA 提升为签名者；还有一个 nonce 程序，用于创建和修改包含交易的 nonce 账户，并确保该账户只能被使用一次。这个新程序会推进 nonce，从而允许该操作被执行。

其他有趣的内容

@Axis_pizza —— 一位新的验证者，分享技术笔记和开源贡献
@Solplay_jonas 制作了一个有趣的小型会议罚款支付应用
关于 SGP-0002 的讨论仍在继续。来自 @mert 和 @brianlong 的分析如下
@triton_one 实现了更快、资源占用更少的索引

@triton_one：

Old Faithful：紧凑索引现在是默认选项

给所有基于 Solana 历史数据进行构建的人一个快速提醒。

我们已经开始在 Old Faithful 项目上发布一种新的索引格式——紧凑索引。它们更小、更快、……
@beeman_nl 讲述 Solana 移动应用如何与钱包应用交互

@beeman_nl：

有没有想过 @solanamobile 应用是如何与钱包通信的？

观看这个视频，了解 Mobile Wallet Adapter 的内部工作原理——以及 Wallet UI 如何将整个集成封装为一次 connect 调用。

章节：
- 00:00 预览：与钱包连接并签名
- 00:24 什么是 Mobile Wallet Adapter？
- 00:31 为什么需要 MWA
- 01:10 MWA 修复了什么
- 01:28 MWA 的内部工作原理
- 01:56 处理多个钱包
- 02:14 清除默认钱包
- 02:31 代码：Wallet UI
- 02:53 结尾
@NotDeGhost 正式介绍 Anchor v2

@NotDeGhost：

Anchor v2.0.0-rc.1 来了

程序体积比 v1 缩小了 90% 以上，速度快了 3-6 倍。我们还对安全性极其重视，默认内置 fuzzing，并且仅针对 RC 就进行了两次独立审计。