Author: Stratu
The Stratum V2 protocol suite consists of 4 protocols (the main mining protocol and 3 sub-protocols), specifies 5 roles and their communication standards for the subjects participating in Bitcoin mining, and uses 3 types of communication channels. This article introduces the roles and channels defined by Stratum V2, and summarizes the implementation of each sub-protocol. As for Technical Oak, please refer to the complete documentation on GitHub .
Role
We have defined 5 roles for the subjects in the Stratum V2 protocol suite, and the relationships between these subjects can be classified as upstream and downstream.
Mining equipment (or, miners)
The actual mining rig used to calculate hashes. “Miners” can refer to a wide variety of hashrate producers: from large-scale corporate mines to mobile mining operations that surreptitiously harvest natural gas from shale oil rig sites. When describing a miner, it is most useful to describe the scale at which it communicates with an upstream mining pool: a 10PH mining farm, working with a hydropower station, communicates with the mining pool as a unit, although internally it also divides the work among many A mining device can also be considered a "miner", but it is different from the "miner" running an S19 in a street garage. As explained below, miners “give” their hashrate to a mining pool. From the perspective of Stratum V2, miners are the most downstream role.
Mining pool
A mining pool is a communication node responsible for coordinating the hash rate and distributing mining rewards. They create jobs for endpoint devices, verify blocks and shares, and propagate discovered blocks to the Bitcoin network. Mining pools do not maintain or control the hash rate. Terminal devices compatible with the Stratum protocol can switch mining pools within minutes. As a result, mining pools compete with each other based on latency, ease of use, debt repayment reliability, and related networking services, and Stratum V2 can significantly improve each of these. It can be considered that the mining pool is the most upstream role. Mining pools can open any type of communication channel with downstream actors (agents or mining equipment) (see below).
acting
The proxy is an intermediary between miners and mining pools, aggregating connections and translating mining communications (Sv1->Sv2 or Sv2->Sv1). Agents may provide additional functionality, including monitoring services or statement of work optimization. Both miners and mining pools can run agents, and they will run agents for different reasons based on different use cases.
Mining agent
Sv2 mining agents are the middlemen between mining equipment and Sv2 mining pools. It receives mining requests from multiple devices, aggregates them and forwards them to the Sv2 mining pool. It can open group/extension channels with the upstream (Sv2 mining pool), and can also open standard channels with the downstream (Sv2 mining equipment).
translation agency
The translation agent is responsible for communication between Sv1 mining equipment and an Sv2 mining pool or mining agent. It allows Sv1 devices to interact with Sv2-based mining infrastructure, bridging the gap between the older Sv1 protocol and Sv2. It can open expansion new eggs with the upstream (Sv2 mining pool or mining agent). For example, a mining pool might run a translation proxy as an initial connection service to receive connections from Sv1 and Sv2, then establish a direct standard channel with Sv2 miners and use this proxy to translate communications with Sv1 miners.
work declarer
A job declarator (JD) is a role that can belong to either a mining pool or a miner, but can also be run by any third party. They connect to a template provider, enabling them to receive and validate customized block templates. They are roles required in order to implement what is called a "statement of work agreement". They can further distribute work to a mining agent (or agents) through a work distribution protocol.
Statement of work server
The job declaration server (JDS) is the JD on the mining pool side and is responsible for allocating the mining work tokens required by the job declaration client to create customized jobs. It is also the entity responsible for propagating blocks for the pool when miners connected to the pool discover a valid block (using the Statement of Work protocol).
Statement of Work Client
The Job Declaration Client (JDC) is the miner's JD and is responsible for collecting block templates from the template provider it is connected to and creating new mining jobs. It declares the customized job to JDS to start mining. JDC is also responsible for activating the backup mining pool mechanism and automatically switching to the backup mining pool when the declared work is rejected by JDS. After exhausting its reserves, it can switch to solo mining (Solo Mining) until a new and safe mining pool appears on the market.
Template supplier
The template provider (TP) can be deployed on the mining pool side or not on the miner side, but can also be run by any third party. When TP is deployed on the miner side, it can extract transactions from local Bitcoin nodes. In this way, miners can create customized block templates and declare customized mining jobs to the mining pool through the work declaration protocol.
sub-protocol
Mining protocol
Also called "Master Protocol", it is the direct successor of Stratum V1. The main protocol is used for mining and is the only part of the entire protocol suite that needs to be implemented in all scenarios. It is used for communication between mining equipment, proxies, and mining pool services. If a miner/pool does not support transaction selection and mining work declarations, this is the only protocol that needs to be implemented.
channel
The protocol defines three types of channels:
Standard channel: Do not modify Merkle path/coinbase transactions, simplify communication with each other and with upstream nodes as much as possible.
Extended channel: gives extended control over the search space, enabling advanced application scenarios (for example, translating v1 and V2 messages back and forth, difficulty aggregation, customized search space segmentation, etc.).
Group channel: A simple collection of standard channels, carried out within a single connection, and thus accessible through a common channel.
statement of work agreement
The work declaration protocol is used by miners (generally a mining farm) to declare a customized block template to the mining pool. The results of such declarations can be reused across all terminal miner connections of the pool, thereby reducing computational intensity. In other words, a single statement can be applied to many devices across an entire mine, or even multiple mines, allowing for greater efficiency. This protocol is independent to allow mining pools to interrupt these connections on independent infrastructure without affecting the mining protocol connection. This protocol is an independent, optional infrastructure within the entire protocol and can be provided by a third party to the mining farm. This is also the most prominent feature of the entire protocol suite, as it can promote the decentralization of transaction selection power.
Template Distribution Agreement
The template distribution protocol is used to assist in extracting information from Bitcoin Core that can construct the next block. It is designed to replace gitblocktemplate (BIP 22 and 23), providing greater efficiency and ease of implementation for those integrating other aspects of Stratum V2.
work distribution agreement
Used to deliver newly declared work to interested nodes, which can be either agents or actual mining equipment. This agreement is in addition to the statement of work agreement. When miners do not self-build and declare their own jobs (i.e. self-selected mining transactions), jobs are distributed directly from the mining pool to agents and end devices, just like the original stratum protocol. However, this protocol will be left to future documentation, as, when a job declarer becomes part of a larger mining protocol proxy, a distribution protocol is generally unnecessary.
