区块链中文技术社区 - Solana-新手教程
type: channel
link: https://bcskill.com/index.php/category/Solana-新手教程/
items: Solana 检查交易confirmed状态时间过长
items: SVM 私有链 Websocket延迟优化
items: TokenPocket 如何添加Solana私有网络
items: Solana RPC 返回 VersionedTransaction too large
items: Solana调整出块时间为50ms，并且保持recent_blockhash（120秒）过期时间不变
items: Solana SPL 程序编译
items: RISC-V 与EVM集成的性能和可行性分析
items: Solana 节点服务器优化
items: Solana 硬件兼容性列表
items: 私有链化部署Squads Protocol

Solana 检查交易confirmed状态时间过长
type: item
date: 2026-01-05T16:35:00+08:00
description: 问题 业务中发送交易后，等待状态变为 confirmed 的时间较长，约 3 秒左右。 环境 基于 Solana Agave 部署 单 validator 私链 原因分析 confirmed 并不是交易立即执行的状态，而依赖 slot / vote / block commitment。 单 validator 下 confirmed 延迟原因 processed：leader 已执行交易（最快） confirmed：交易所在 block 被投票确认 finalized：达到 supermajority 单 validator 情况： 即便只有一个节点，也必须出 vote vote 是单独交易，通常在 下一个或后续 slot 才完成 slot 时间偏大或交易量低 → vote 延迟 → confirmed 累积到 1–3 秒 即使 slot = 50ms，在低 TPS 私链下，confirmed 仍可能慢，因为 vote 被节流或跨多个 slot 才出。 解决方案 1. 客户端改用 processed connection.confirmTransaction(sig, "processed") 或 sendAndConfirmTransaction( connection, tx, signers, { commitment: "processed" } ) processed 延迟：几十 ms confirmed 延迟：1–3 秒 单 validator 私链中，processed 基本安全，不会发生共识回滚。 2. 风险说明 唯一风险来自 节点崩溃/重启：block 未落盘 → 交易可能丢失 非共识风险，仅进程级别 3. 优化 confirmed 延迟 低 TPS 私链可通过增加压测交易： 每个 slot 保持交易 → vote 更快产生 → confirmed 延迟缩短 压测交易可使用无害空交易 发送 0 SOL 的转账 from/to 同一个账户 4. 综合方案（推荐） 目标：保证业务交易快速反馈，同时降低 confirmed 延迟 客户端 使用 commitment = processed 立即返回成功，提升用户体验 后台服务 异步监听交易 signature 等 confirmed / finalized 极端情况（几秒后未 confirmed） → 补偿或重发 压测优化（可选） 在私链 TPS 较低时，可增加持续模拟交易 每个 slot 都有交易 → vote 更快生成 → confirmed 时间缩短 可使用无害空交易，不影响业务逻辑 该方案兼顾速度、确认可靠性，并可通过压测交易进一步降低 confirmed 延迟

SVM 私有链 Websocket延迟优化
type: item
date: 2025-07-10T09:59:00+08:00
description: 背景 当交易上链后，需要websocket尽快订阅到新发起的交易信息，但已有逻辑有2s左右延迟 目前逻辑 { "jsonrpc": "2.0", "id": 1, "method": "blockSubscribe", "params": [ { }, { "commitment": "finalized" } ] } 当前测试环境为私有网络，且仅有一个Validator 优化延迟 优化链路 原有链路：监听服务 -> WAF -> RPC -> Validator 压缩链路 监听服务 -> RPC -> Validator 去除WAF防护过程造成的延迟 保留RPC对Validator压力防护 监听服务 -> Validator 在1的基础上去除RPC同步Validator区块的时间 在链路路径上，为最短路径，只适合核心私有服务，时间优先 阶段测试结果 结果：链路优化后，延迟优化效果不明显 排除：排除WAF设置或防护逻辑，以及RPC同步相关对websocket的影响 修改参数 修改blockSubscribe.commitment 参数 测试结果 测试参数 最大延迟 概率 备注 blockSubscribe (confirmed) < 1s 95% 满足实时需求 blockSubscribe (finalized) ~ 2s 均值 RPC节点需开启 --rpc-pubsub-enable-block-subscription 总结：当blockSubscribe.commitment 为confirmed时，满足实时性需求 下面继续做具体分析，以及安全性确认 整体分析 commitment Solana 分别引入了 processed、confirmed 和 finalized 三种 commitment Commitment 等级 状态说明 是否可能回滚 用途 processed 当前 leader 节点已执行交易（未确认） 可能被 fork 快速响应 confirmed 超过 1 个 superminority（2/3 vote）节点已投票确认 小概率回滚（如果 fork 被重组） 较安全且快速 finalized 已不可逆地写入链上（root slot） 永不回滚 最终状态 安全分析 confirmed 还可能丢弃？ Solana 是基于 Turbine + Tower BFT 共识 的区块链，允许 fork 存在，直到达成“supermajority lockout”： 举个例子： Leader A 在 slot 100 产出 block1，包含你的交易 tx1 多数 validator 已投票确认 → tx1 达到 confirmed 但 Leader B 在 slot 100 提出了 fork block2（没有 tx1） 网络切换了分叉，block2 成为主链，block1 被丢弃 最终你会看到 tx1 消失 这种情况虽然极少发生（除非网络分叉非常激烈），但确实有可能，尤其在以下情况下： 网络波动严重（多个 validator 未及时同步） 特别是在 devnet/testnet 上更常见 冲突交易竞争激烈（如套利机器人密集交易） 单一Validator 结论：如果整个网络只有一个 validator，交易一旦被执行（即 processed），就等同于 finalized，不会被回滚或丢弃 原因：Solana 的分叉和回滚机制依赖于 多个 validator 的投票（tower consensus），但如果你只有一个 validator 节点（如私链或测试环境）： 所有交易处理都只走 一个 chain path 没有投票机制（自己 vote 自己） 没有 fork、没有分歧 所有被处理的 block/slot 会直接成为 root → 立即 finalized 延迟分析 问题：在只有一个 Validator 的 Solana 网络中，为什么交易已经 confirmed，但还没有立即 finalized？不是说没有其他节点就没有分叉吗？ 原因：因为 finalized 状态取决于 root slot 的推进，而 root slot 的推进有“延迟”或“惰性机制”，即使只有一个 validator。 Solana 的 finalized 并不是单纯根据是否有分叉来判断，而是依赖一个特殊机制： Tower BFT + Root Slot 推进规则： 每个 validator 会有自己的 "lockout" 投票历史，形成“投票树” 当 validator 在连续的 slot 上投票到一定深度，就能推进 root slot 只有 root 之后的 slot 才会被标记为 finalized 即使只有一个 validator…

TokenPocket 如何添加Solana私有网络
type: item
date: 2025-06-30T09:36:00+08:00
description: 安装Chrome扩展 https://chromewebstore.google.com/detail/tokenpocket-web3-crypto-%E9%92%B1/mfgccjchihfkkindfppnaooecgfneiii?utm_source=ext_app_menu 打开资产展示 添加自定义网络 选择SVM 填入私有链对应的RPC，链ID 随意 （对于Solana链没有链ID，这里只是为了与EVM链类型共用布局） 例如 只做演示，BCSkill 技术社区未对外提供私有Solana链支持 添加新增网络 测试 然后回到资产展示，选择新添加的网络即可 注意 不要直接从 系统设置->节点列表->选择Solana->添加自定义节点 这里的添加只能添加Solana官方的节点，添加时会通过RPC 获取getGenesisHash，得到创世hash并与Solana 官方devnet testnet mainnet 进行比对，如果不一致则报错。 应该先添加完自定义网络后，再给自定义网络添加自定义节点

Solana RPC 返回 VersionedTransaction too large
type: item
date: 2025-06-27T11:42:23+08:00
description: Solana构建发起交易时，返回错误 (*jsonrpc.RPCError)(0xc00739b530)({ Code: (int) -32602, Message: (string) (len=122) "base64 encoded solana_sdk::transaction::versioned::VersionedTransaction too large: 1668 bytes (max: encoded/raw 1644/1232)", Data: (interface {}) <nil> }) 错误分析 交易的大小超过1232 字节限制 static_assertions::const_assert_eq!(PACKET_DATA_SIZE, 1232); /// Maximum over-the-wire size of a Transaction /// 1280 是 IPv6 最小 MTU /// 40 字节是 IPv6 报头的大小 /// 8 字节是分片报头的大小 pub const PACKET_DATA_SIZE: usize = 1280 - 40 - 8; PACKET_DATA_SIZE 硬编码，不可配置，为保障节点间数据传输的稳定和安全性 解决 拆分交易，将多个逻辑拆分到多笔交易 参考 https://github.com/solana-foundation/anchor/issues/2051

Solana调整出块时间为50ms，并且保持recent_blockhash（120秒）过期时间不变
type: item
date: 2025-05-29T09:35:00+08:00
description: 背景 比如想基于Solana运行一个Layer2网络或者应用链，需要尽可能的加快出块时间{从综合测试和其它类似项目综合分析，50ms是最快最稳定的}， 如果单一的降低出块时间，会导致 recent_blockhash过期时间变短，从而可能导致交易发送时容易报 “Blockhash not found” 下面我们将给出如何实现50ms的slot，并保持recent_blockhash过期时间（120s）不变的方案 代码修改 agave\sdk\program\src\clock.rs /// 每秒 tick 数：PoH 产生 tick 的速度（原为 160） pub const DEFAULT_TICKS_PER_SECOND: u64 = 1000; // 1000 ticks = 1秒 /// 每 slot 包含 tick 数（原为 64） pub const DEFAULT_TICKS_PER_SLOT: u64 = 50; // 50 ticks = 1 slot /// blockhash 最大有效时间（保持主网一致） pub const MAX_HASH_AGE_IN_SECONDS: u64 = 120; // blockhash 有效时间 120秒 Solana 会自动计算： pub const MAX_RECENT_BLOCKHASHES: usize = MAX_HASH_AGE_IN_SECONDS * DEFAULT_TICKS_PER_SECOND as usize / DEFAULT_TICKS_PER_SLOT as usize; // => 2400 MAX_RECENT_BLOCKHASHES 为什么要 调整为 2400 这是因为你想要 每个 slot 时间为 50ms，而官方默认是 400ms，两者时间差 8 倍。 解释为什么需要把 MAX_RECENT_BLOCKHASHES 调整到 2400 1. 官方默认参数回顾： 参数 数值 MAX_HASH_AGE_IN_SECONDS 120 s DEFAULT_TICKS_PER_SECOND 160 DEFAULT_TICKS_PER_SLOT 64 MAX_RECENT_BLOCKHASHES 300 计算： 意味着最近 120 秒内链上大约有 300 个 slot（因为每 slot 约 0.4 秒）。 2. 你想改成 50ms/slot 50ms = 0.05秒，等于官方 0.4秒的 18\frac{1}{8}81。 在 120 秒内，会有： 3. 为了保持 blockhash 有效时间不变 你必须保存最近 2400 个 blockhash（对应 2400 个 slot），才能覆盖 120 秒内所有 slot。 4. 计算验证 MAX_RECENT_BLOCKHASHES = MAX_HASH_AGE_IN_SECONDS * DEFAULT_TICKS_PER_SECOND / DEFAULT_TICKS_PER_SLOT 现在参数改成： MAX_HASH_AGE_IN_SECONDS = 120 DEFAULT_TICKS_PER_SECOND = 1000 （tick 速度提高了） DEFAULT_TICKS_PER_SLOT = 50 计算： 总结 每 slot 时间 slot 数（120秒内） 需保存最近 blockhash 数量 MAX_RECENT_BLOCKHASHES 400ms 300 300 50ms 2400 2400 所以，MAX_RECENT_BLOCKHASHES 调整为 2400 是为了匹配新的更快 slot 频率，保证 blockhash 在 120 秒内仍有效 solana-genesis 初始化 对于初始化时也需要对应的加入启动参数 --ticks-per-slot 50 测试脚本 #!/bin/bash RPC_URL="https://api.mainnet-beta.solana.com" # Step 1: 获取最新 blockhash echo "Fetching latest blockhash..." RESPONSE=$(curl -s -X POST $RPC_URL \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","id":1,"method":"getLatestBlockhash"}') BLOCKHASH=$(echo $RESPONSE | jq -r '.result.value.blockhash') echo " Got blockhash: $BLOCKHASH" echo " Starting…

Solana SPL 程序编译
type: item
date: 2025-04-25T17:54:21+08:00
description: 代码Clone git clone https://github.com/solana-program/token.git cd token git checkout program@v3.5.0 基础环境 # 安装nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/master/install.sh | bash source ~/.bashrc # 安装node nvm install 20 node -v # 安装pnpm npm install -g pnpm 安装依赖 pnpm install 编译 cd program/ cargo build-sbf 默认编译可能出现以下错误 [2025-04-25T09:39:35.004769959Z ERROR cargo_build_sbf] Failed to obtain package metadata: `cargo metadata` exited with an error: error: current package believes it's in a workspace when it's not: current: /mnt/d/github/token/program/Cargo.toml workspace: /mnt/d/github/token/Cargo.toml this may be fixable by adding `program` to the `workspace.members` array of the manifest located at: /mnt/d/github/token/Cargo.toml Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest. 解决 在 program 目录的 Cargo.toml 文件中添加空的 [workspace] 表 修改 program\Cargo.toml，在第一行增加 [workspace] // 增加此行 [package] name = "spl-token" version = "3.5.0" ... 执行成功后，程序编译出现在program\target\deploy\spl_token.so

RISC-V 与EVM集成的性能和可行性分析
type: item
date: 2025-04-21T15:03:41+08:00
description: 前置总结 技术目的：以太坊网络扩容面临的几个长期瓶颈，包括稳定的数据可用性采样、确保区块生产保持竞争力，以及零知识EVM证明。在智能合约中实施RISC-V架构将保持区块生产市场的竞争力，并提高执行层零知识功能的效率。转向RISC-V将使 Ethereum 与 Solana 和Sui等更新的区块链更具竞争力 技术可行性：从《RISC-V 与以太坊虚拟机集成的性能和可行性分析》分析和测试结果应该可行 难度和风险：需要执行层的重新设计，社区大概评估整体需要数年的时间，需要大量资源，并可能出现新的漏洞，并且开发人员和项目将如何通过旧的智能控制trac移植到新系统存在问题。当涉及向后兼容性时，这可能会引起很多麻烦。基本等同于个完整的新链 现状：目前消息来看，Vitalik只是计划考虑信标链运行RISC-V，相当于技术调研初期，对于以太坊目前现状，可以主要为了造势，稳币价。对于以太坊是否真正开始投入开发支持，可能等先观望下了 RISC-V 与以太坊虚拟机集成的性能和可行性分析 https://hackmd.io/@0xdeveloperuche/Hk18BWxkxl RISC-V与EVM相关项目： evm https://github.com/developeruche/riscv-evm-experiment/tree/main/crates/research-draft zkevm https://verified-zkevm.org/ https://argument.xyz/blog/riscv-good-bad/

Solana 节点服务器优化
type: item
date: 2025-04-18T14:52:59+08:00
description: 系统初始化配置 https://docs.solanalabs.com/operations/guides/validator-start#system-tuning sudo bash -c "cat >/etc/sysctl.d/21-agave-validator.conf <<EOF # Increase UDP buffer sizes net.core.rmem_default = 134217728 net.core.rmem_max = 134217728 net.core.wmem_default = 134217728 net.core.wmem_max = 134217728 # Increase memory mapped files limit vm.max_map_count = 1000000 # Increase number of allowed open file descriptors fs.nr_open = 1000000 EOF" sudo sysctl -p /etc/sysctl.d/21-agave-validator.conf sudo bash -c "cat >/etc/security/limits.d/90-solana-nofiles.conf <<EOF # Increase process file descriptor count limit * - nofile 1000000 EOF"

Solana 硬件兼容性列表
type: item
date: 2025-04-18T09:52:17+08:00
description: https://solanahcl.org/ https://github.com/solanahcl/solanahcl https://docs.anza.xyz/operations/requirements

私有链化部署Squads Protocol
type: item
date: 2025-04-10T21:17:50+08:00
description: 前期调研 目前v3已经停止升级，优先使用v4版本 Squads-Protocol 官方app.squads.so前端不开源，只开源了精简版本 squads-backup-kit squads-backup-kit 前端不支持创建，只支持管理已有多签账户地址 首次创建可以使用Squads CLI进行创建 v4程序地址：SQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCf squads-backup-kit GitHub：https://github.com/Squads-Protocol/public-v4-client 在线地址：https://backup.app.squads.so/ Squads CLI 使用 https://docs.squads.so/main/development/cli/installation https://docs.squads.so/main/development/cli/commands 创建keypair mkdir squads-multisig cd squads-multisig solana-keygen new -o ./keypair-multisig.json solana-keygen new -o ./keypair-1.json solana-keygen new -o ./keypair-2.json solana-keygen new -o ./keypair-3.json 生成测试账户地址 89CefQR7XpdSKsDAFMZVUu3ipqiW35BceuahoE8CiAxz 56uqkuNMGsozcYDuzKfkqUEPqDLQfXRncvoH73xHzHnt G3YLqbreJj1spvBMajv8qgPXVzZ1WaN34LDn7ChFdAPY Hj3KcgcuvcHRM9or6SbuLuTV8Xe5pDttKk3nQSXzP65d 分别给上面4个账户地址转1SOL,为后面演示 2/3多签测试做准备 创建多重签名 squads-multisig-cli multisig-create --rpc-url <RPC_URL> --program-id <PROGRAM_ID> --keypair <KEYPAIR_PATH> --config-authority <CONFIG_AUTHORITY> --members <MEMBER_1> <MEMBER_2> ... --threshold <THRESHOLD> multisig-create参数 --rpc-url ：（可选）Solana RPC 端点的 URL。如果未指定，则默认为主网。 --program-id ：（可选）多重签名程序的 ID。如未指定，则默认为标准 ID。 --keypair ：密钥对文件的路径。 --config-authority ：（可选）程序配置机构的地址。 --members <MEMBER_...>：成员公钥列表，以空格分隔。 --threshold ：执行多重签名交易所需的签名阈值数量。 测试创建 squads-multisig-cli multisig-create --rpc-url https://api.devnet.solana.com --program-id SQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCf --keypair ./keypair-multisig.json --members 56uqkuNMGsozcYDuzKfkqUEPqDLQfXRncvoH73xHzHnt,7 --members G3YLqbreJj1spvBMajv8qgPXVzZ1WaN34LDn7ChFdAPY,7 --members Hj3KcgcuvcHRM9or6SbuLuTV8Xe5pDttKk3nQSXzP65d,7 --threshold 2 threshold为2，则代表 2/3通过 权限是数字，映射到以下内容： 提议人 -1 投票人 -2 执行人 -4 上述所有的 -7 或者任何权限组合（即提议者和投票者3） 例如 --members FcBpwMquaMURbYwpRFUrBrYgFwJzfWiBEGfHLbik1Wsm,7 执行命令后返回 https://solscan.io/tx/XRFQkd2HN4mFoQvKa2FUdKYr2WkETZmxAYbCkM87VjxFDBgUWCEQYEixPcodpQtu1kv8cVgu1MP5pQpcU995U9A?cluster=devnet You're about to create a multisig, please r…