Stratum 是连接 ASIC 与矿池之间的通信层。它负责传递任务通知、难度调整以及份额（share）提交，但它并不会改变 ASIC 计算 SHA-256 输入的方式。当运营者比较 Stratum V1 与 Stratum V2 时,真正相关的问题在于连接方式、安全性,以及由谁来控制区块模板（block template）的构建——而不是关于原始算力表现的问题。本文将 Stratum V2 规范所定义的内容,与各个矿池（包括 ViaBTC）实际部署的内容区分开来。
Stratum 传递的内容
在常规的矿池挖矿会话中,矿池服务器会向 ASIC 发送一个任务（job）：一个区块头模板、一个目标难度,以及构建 coinbase 交易的指令。ASIC 会寻找满足所分配份额目标的 nonce,并将有效份额提交回矿池,矿池再依据其采用的方法（PPS+、PPLNS 或其他已公开说明的模式）将这些份额计入矿工的收益。
Stratum 并不决定收益分配方式、矿池手续费或结算时间——这些是叠加在协议之上的矿池策略。Stratum 所管辖的是连接的格式、任务如何被传递、身份验证如何进行,以及在更先进的部署中,提交份额的一方是否同时控制哪些交易会被纳入区块模板。
V1 与 V2 的比较
Stratum V1 通常是基于 JSON、以行分隔的协议,运行在普通的 TCP 套接字之上。它最初并未定义内置的传输加密；传输加密与服务器身份验证取决于具体实现或网络部署所提供的额外保护措施。
Stratum V2 是一种二进制协议,具有固定的消息分帧格式,并以开放规范的形式发布。对于 ASIC 运营者而言,主要的区别在于：
| 方面 | Stratum V1 | Stratum V2 |
|---|---|---|
| 消息格式 | 通常为行分隔的 JSON | 具有固定分帧格式的二进制消息 |
| 传输保护 | 原始设计中没有内置传输加密；额外的保护措施取决于具体部署 | 对远程上游连接采用经过身份验证的加密；本地链路可能有不同的处理方式 |
| 交易选择 | 通常由矿池构建区块模板 | 基础挖矿协议（Basic Mining Protocol）仍可使用矿池下发的任务；若要由矿工选择模板,则需要可选的任务声明（Job Declaration）基础设施以及矿池支持 |
| 设备兼容性 | 需要兼容 V1 的固件以及相应的端点 | 需要兼容的原生固件,或者需要一个 V1 转 V2 的转换代理连接到兼容的 V2 端点 |
有两点差异值得进一步探讨：
- 传输安全性。 Stratum V2 规范对远程上游连接采用经过身份验证的加密,这意味着挖矿设备（或代理）与远程矿池端点之间的流量会被加密,并且在建立连接的过程中会对服务器进行身份验证。根据该规范,本地设备到本地代理之间的链路可以采用不同的处理方式（Stratum V2 协议安全性）。
- 挖矿功能与模板功能的分离。 V2 规范定义了不同的角色与子协议：挖矿协议（Mining Protocol，负责任务下发与份额提交,功能上与 V1 类似）,以及可选的任务声明协议（Job Declaration Protocol，用于协调由矿工选择的模板）。这两者在架构上是相互独立的,矿池可以只支持挖矿协议而不支持任务声明协议（Stratum V2 协议概览）。
仅仅切换协议本身并不能保证更高的芯片级算力(hashrate),也不能保证更好的能效表现（以 J/TH 衡量）。这些硬件特性取决于 ASIC 本身及其运行设置。任务下发与连接行为应当单独评估：协议及其实现方式的差异,可能会影响挖矿任务到达设备、以及份额到达矿池的有效性,但不会改变芯片本身的底层算力能力（Stratum V2 挖矿协议）。
安全性与任务选择
已发表的关于 Stratum V1 的研究表明,在未附加传输保护措施的部署环境中,未加密的 Stratum 流量可能暴露出有助于推断矿工算力(hashrate)的信息,并可能受到具备网络位置优势的攻击者的干扰（Recabarren 和 Carbunar,《Hardening Stratum, the Bitcoin Pool Mining Protocol》，2017 年）（arxiv.org/abs/1703.06545）。这描述的是原始 V1 设计在缺乏补充保护措施情况下的一种结构性局限——这并不意味着当前生产环境中每一条 V1 连接都是未受保护的,因为具体实现与端点可能会自行增加传输层安全保护。
Stratum V2 的经过身份验证的加密保护了消息内容与完整性,而服务器身份验证则有助于客户端验证上游服务器的身份。这些保护措施降低了消息内容被窃听以及消息被篡改的风险暴露。但不应将其解读为能够防范一切流量分析的保证：上述被引用的研究同样探讨了通过数据包时间戳推断收益的方式,因此,仅仅对消息内容进行加密,并不能证明所有基于元数据的推断都能被阻止。
另一个经常与上述内容混淆、但实际上截然不同的话题是任务（或交易）选择。在标准的矿池挖矿模式下,矿池服务器负责构建区块模板,ASIC 只需针对该模板寻找有效的 nonce。Stratum V2 的任务声明协议定义了一条可选路径：在该路径中,由挖矿运营方——而非 ASIC 本身——从模板提供方（Template Provider）获取候选模板,并使用任务声明客户端（Job Declarator Client）与支持该功能的矿池协调自定义任务（Stratum V2 任务声明协议）。
当前规范描述了两种模式。在 Full-Template（完整模板）模式下，客户端会声明模板的交易 ID，矿池可以请求缺失的交易数据。在 Coinbase-only（仅 Coinbase）模式下，交易集不会通过该流程向矿池披露，且不使用 DeclareMiningJob 消息。这两种模式都描述了"乐观挖矿"：工作任务可以在矿池确认之前就发送给设备，份额会被缓存，等待该确认。运营方应检查其所选实现如何处理确认和缓存份额。
对于运营方而言，仅在 ASIC 上启用 Stratum V2 本身并不能获得交易选择能力。Job Declaration（任务声明）需要在挖矿运营方一侧配备额外的基础设施，并且需要矿池支持该特定子协议，而不仅仅是基础的 V2 Mining Protocol（挖矿协议）。考虑使用 Job Declaration 的运营方应预期需要运行或协调一个比特币节点及兼容的模板构建软件，这是在其已管理的 ASIC 或代理配置之外的额外要求。
设备与代理兼容性
针对 V1 端点配置的 ASIC 不会自动获得 V2 能力。原生 V2 支持取决于设备固件是否实现了该二进制协议及其加密握手。在固件不直接支持 V2 的情况下，兼容的 V1-to-V2 转换代理（translation proxy） 可以将 V1 ASIC 连接桥接到兼容的 V2 矿池端点，从而避免对每台设备都进行固件更改。除非一个通用的 V2 代理实现了该转换功能，否则它本身是不够的。在此配置下，ASIC 到代理之间的链路仍为 V1，而代理到矿池之间的链路使用 V2；上游链路上的 V2 加密并不会自动保护本地的 V1 链路（SRI 转换代理示例）。
对于评估迁移方案的运营方，有几个实际的兼容性要点适用：
- 确认当前固件是否公开了 V2 连接选项，或者是否需要兼容的 V1-to-V2 转换代理。
- 在迁移期间若 V1 回退可用，先在一小部分矿机上进行测试，再转换整个矿场，可降低出现全矿场范围连接问题的风险。
- 监控应区分本地设备读数与矿池报告的份额及矿工状态，因为协议变更可能独立于底层算力表现而影响连接稳定性。
- Job Declaration 基础设施（节点、Template Provider、Job Declarator Client）是与基础 V2 连接性相独立的部署决策，并有其自身的维护要求。
目前，ViaBTC 已公开的 BTC 挖矿配置使用标准的 stratum+tcp 端点（例如 stratum+tcp://btc.viabtc.io:3333 和 stratum+tcp://btc.viabtc.io:443），采用常规的 userID.workerID 矿工格式，并建议使用多个端口以确保连接的连续性（ViaBTC BTC 挖矿指南）。该文档描述的是当前已发布的连接方式；不应将其解读为关于 Stratum V2 或 Job Declaration 可用性（无论是确认可用还是其他情况）的说明，运营方应直接查阅 ViaBTC 当前的官方文档，以获取最新支持的连接选项。
应向矿池提出的问题
由于"支持 Stratum V2"这一说法可能描述出实质上不同的能力，评估矿池的运营方应提出具体问题，而不是仅凭字面标签就接受：
- 矿池支持的是用于标准矿池下发任务的 V2 Mining Protocol，还是 Job Declaration Protocol，抑或两者都支持？
- 如果支持 Job Declaration，它运行在矿池仍能获取交易数据以进行验证的模式下，还是矿池无法直接看到交易内容的模式下？
- 是否有已发布的设置文档，涵盖 V2 连接所需的固件要求、支持的代理、端口及身份验证？
- 在迁移期间 V1 是否仍可作为后备方案保留？矿池如何处理同时运行两种协议版本的混合矿场？
- 与协议版本无关，矿池采用何种支付方式、手续费、结算时间及提现条款？无论矿工是通过 V1 还是 V2 连接，这些条款的记录方式是否一致？
将协议能力与支付条款作为独立的评估标准来看待，可避免一个常见错误，即假设矿池在传输层上的改进也会改善其经济效益——这两者是矿池选择中相互独立的方面。
常见问题
切换到 Stratum V2 会提高我的 ASIC 的算力吗？
单靠这一项不会。Stratum V2 改变的是挖矿通信方式，而非 ASIC 的芯片设计。仅切换协议并不能保证芯片级算力更高，或更优的 J/TH（焦耳每太哈希）能效。应将任务下发、连接稳定性与矿池接受的份额，与设备本地算力分开评估。
如今使用矿池是否必须依赖 Stratum V2？
不是。所需协议取决于你所使用的端点。兼容 V1 的矿机可以使用兼容的 V1 端点；请针对你具体的固件和矿池连接，确认所支持的协议及设置要求。
启用 Stratum V2 是否能让我自行选择交易？
单靠这一项不行。基础的 Stratum V2 Mining Protocol 支持仍然依赖矿池下发任务。交易选择需要独立的、可选的 Job Declaration Protocol，这需要在挖矿运营方一侧配备额外的基础设施，并需要矿池对该功能提供明确支持。
我能否在同一个矿池账户下同时运行 Stratum V2 ASIC 和 V1 ASIC？
这取决于具体矿池的实现方式。运营方在迁移部分设备之前，应向矿池确认是否支持混合协议矿场。
Stratum V1 使用起来不安全吗？
独立安全研究发现,未加密的 V1 实现存在结构性弱点,例如网络位置观察者可获取与算力相关的数据。这是该基础设计的已知局限,但并不能证明每一个生产环境中部署的 V1 都完全没有任何防护,因为各矿池或网络环境可能会自行添加传输层安全防护措施。
参考资料
- Stratum V2 协议概述
- Stratum V2 挖矿协议
- Stratum V2 协议安全性
- Stratum V2 任务声明协议
- Recabarren, R., 与 Carbunar, B.(2017 年)。强化 Stratum——比特币矿池挖矿协议。arXiv:1703.06545。
- ViaBTC 支持中心。BTC 挖矿。
- Stratum V2。搭载 Job Negotiator 的全新 SRI 更新——允许矿工自行选择交易。2023 年 4 月 14 日。