Overview of the Decentralized Mining Pool Protocol Stratum V2

A Comprehensive Look into the Decentralized Mining Pool Protocol Stratum V2

Author: Stratu

The Stratum V2 protocol suite consists of four protocols (a mining protocol as the main body and three sub-protocols) that specify five roles and their communication standards for participants in Bitcoin mining, using three types of communication channels. This article introduces the roles and channels defined by Stratum V2 and summarizes the implementation of each sub-protocol. For technical details, please refer to the complete documentation on GitHub.

Roles

We have defined five roles for the main participants in the Stratum V2 protocol suite, and the relationships between these participants can be classified as upstream and downstream.

Miner (or mining device)

The actual mining device that calculates hash values. “Miner” can refer to a variety of hash rate producers, from large-scale corporate mining farms to mobile mining operations that stealthily collect natural gas on-site at shale oil drilling platforms. When describing miners, it’s most useful to describe the scale of their communication with upstream mining pools: a mining farm with a 10PH hash rate, partnering with a hydroelectric power plant, communicates as a unit with the mining pool, even though it distributes work to many mining devices within it. This can also be considered a “miner,” just different from a “miner” running a single S19 in a street garage. As described below, miners “offer” their hash rate to a particular mining pool. From the perspective of Stratum V2, miners are the most downstream role.

• 1KX Comparing 8 major decentralized social protocols from various aspects such as identity, data, storage, etc.
• RWA Tokenization Beyond Speculation
• LianGuaintera Capital Partner How DePIN is Introducing Decentralized Hardware to the New Data Economy

Mining Pool

The mining pool is a communication node responsible for coordinating hash rate and distributing mining rewards. They create work (jobs) for terminal devices, verify blocks and scores (shares), and propagate discovered blocks to the Bitcoin network. Mining pools do not hold or control hash rate. Terminals compatible with the Stratum protocol can switch between mining pools in minutes. Therefore, mining pools compete based on latency, ease of use, debt reliability, and related networking services, all of which can be significantly improved by Stratum V2. Mining pools can establish any type of communication channel (see below) with downstream roles (proxies or mining devices).

Proxy

Proxies are intermediaries between miners and mining pools, aggregating connections and translating mining communications (Sv1->Sv2 or Sv2->Sv1). Proxies may provide additional functionality, including monitoring services or work declaration optimization. Both miners and mining pools can run proxies, and they may run proxies for different reasons and in different scenarios.

Mining Proxy

The Sv2 mining proxy is an intermediary between mining devices and Sv2 mining pools. It receives mining requests from multiple devices, aggregates them, and forwards them to Sv2 mining pools. It can establish a multicast/extension channel with upstream (Sv2 mining pools) and a standard channel with downstream (Sv2 mining devices).

Translation Proxy

The translation proxy is responsible for the communication between the Sv1 mining equipment and an Sv2 mining pool or mining proxy. It allows Sv1 devices to interact with the mining infrastructure based on Sv2, bridging the gap between the older Sv1 protocol and Sv2. It can also open up new possibilities with the upstream (Sv2 mining pool or mining proxy). For example, a mining pool may run a translation proxy as an initial connection service to receive connections from both Sv1 and Sv2, and then establish a direct standard channel with Sv2 miners, using the proxy to translate communication with Sv1 miners.

Job Declaration (JD)

The job declarer is a role that can belong to either the mining pool or the miners, but can also be operated by any third party. They connect to a template supplier to receive and validate customized block templates. They are required for the implementation of the so-called “job declaration protocol.” They further distribute work to a mining proxy (or proxies) through a work distribution protocol.

Job Declaration Server (JDS)

The job declaration server (JDS) is the JD on the mining pool side, responsible for distributing mining work tokens required by job declaration clients to create customized jobs. It is also responsible for propagating the blocks to the mining pool when a miner discovers a valid block (using the job declaration protocol).

Job Declaration Client (JDC)

The job declaration client (JDC) is the JD on the miner side, responsible for fetching block templates from the template supplier it connects to and creating new mining work. It declares customized work to the JDS to start mining. The JDC is also responsible for initiating a backup mining pool mechanism, automatically switching to a backup pool when the declared work is rejected by the JDS. After exhausting all backups, it can switch to solo mining until new secure mining pools appear on the market.

Template Supplier (TP)

The template supplier (TP) can be deployed on the mining pool side or independent of the miner side, but can also be operated by any third party. When the TP is deployed on the miner side, it can extract transactions from a local Bitcoin node. This allows the miner to create customized block templates and declare them to the mining pool through the job declaration protocol.

Subprotocols

Mining Protocol

Also known as the “main 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 in the communication between mining devices, proxies, and mining pool services. If a miner/pool does not support transaction selection and job declaration, this is the only protocol that needs to be implemented.

Channels

The protocol defines three types of channels:

• Standard Channel: Does not modify the Merkle path/coinbase transaction and aims to simplify communication between each other and with upstream nodes as much as possible.

• Extended Channel: Provides extension control over the search space, enabling advanced use cases (e.g., bi-directional translation of v1 and V2 messages, difficulty aggregation, customized search space partitioning, etc.).

• Group Channel: A simple collection of standard channels conducted within a single connection, enabling access through a common channel.

Work Declaration Protocol

The Work Declaration Protocol is used by miners (generally a mining farm) to declare a customized block template to the mining pool. The result of this declaration can be reused across all terminal mining connections in the mining pool, reducing computational intensity. In other words, a single declaration can be applied to many devices in the mining farm, or even multiple mining farms, resulting in higher efficiency. This protocol is independent and allows the mining pool to interrupt these connections on separate infrastructures without affecting mining protocol connections. It is an independent and optional infrastructure within the entire protocol suite and can be provided to mining farms by third parties. This is also the most prominent feature of the entire protocol suite as it can promote decentralization of transaction selection power.

Template Distribution Protocol

The Template Distribution Protocol is used to assist in extracting information from Bitcoin Core that can be used to construct the next block. Its design goal is to replace gitblocktemplate (BIP 22 and 23), providing greater efficiency and ease of implementation for those integrating with other aspects of Stratum V2.

Work Distribution Protocol

Used to deliver newly declared work to relevant nodes, whether they are proxies or actual mining devices. This protocol complements the Work Declaration Protocol. When miners do not self-build and declare their own work (i.e., self-selected mining transactions), the work will be directly distributed to proxies and terminal devices by the mining pool, just like the original stratum protocol. However, the specifics of this protocol will be specified in future documentation, as it is often unnecessary when the work declarer becomes part of a larger mining protocol agent.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!