Stratum protocol описание

Обновлено: 07.07.2024

Protocol Overview

The actual mining machine computing the hashes.

An intermediary between Mining Devices and Pool Services that aggregates connections for efficiency and may optionally provide additional functionality, such as monitoring the health and performance of devices.

An upstream node to which shares (i.e. completed jobs) are being submitted. The most common hashrate consumers are pools.

A node which negotiates with a pool on behalf of one or more miners to determine which jobs they will work on. This node also communicates with a block template provider (e.g. bitcoind) and sends jobs to mining proxies to be distributed to miners.

Mining Protocol

This is the direct successor of stratum protocol v1. It’s the main protocol used for mining and the only part of the full protocol stack that needs to be implemented in all scenarios. It is used for communication between Mining Devices, Proxies, and Pool Services.

The protocol defines three types of communication channels:

Standard channels don’t manipulate the Merkle path / coinbase transaction, greatly simplifying the communication required between them and upstream nodes.

Extended channels are given extensive control over the search space so that they can implement advanced use cases (e.g. translation between v1 and v2, difficulty aggregation, custom search space splitting, etc.).

Group channels are simply collections of standard channels that are opened within a particular connection so that they are addressable through a common communication channel.

Job Negotiation Protocol

Used by a miner to negotiate a block template (which includes the transaction set) with a pool, making pooled mining more similar to solo mining and thus increasing decentralization. The negotiation results can be re-used for all mining connections to the pool (of which there can be hundreds of thousands), greatly reducing the computational intensity.

This protocol is a separate, optional piece of infrastructure from the Mining Protocol and can be provided as a 3rd party service for mining farms.

Template Distribution Protocol

Used to get information about the next block out of Bitcoin Core. This protocol was designed as a much more efficient and easy-to-implement API to replace getblocktemplate (BIPs 22 and 23).

More specifically, the Template Distribution Protocol is used to communicate with a part of Bitcoin Core called “bitcoind” which implements the Bitcoin protocol for Remote Procedure Call (RPC) use. In other words, bitcoind allows the Bitcoin protocol to be integrated with other software.

Job Distribution Protocol

Used to pass newly-negotiated work to interested nodes, which can either be proxies or actual mining devices. This protocol is complementary to the Job Negotiation protocol.

In the case that miners aren’t negotiating their own work (i.e. choosing their own transaction sets), jobs will be distributed directly from pools to proxies and end devices, similarly to in the original stratum protocol. Additionally, it’s possible that the Job Negotiation role will be part of a larger Mining Protocol proxy that also distributes jobs, making this sub-protocol unnecessary even when miners do choose their own transaction sets.

Upstream and downstream describes the direction that data is flowing. The furthest downstream component is a Mining Device, while the furthest upstream component is a Pool Service.

Protocol

Overview

Methods (client to server)

mining.authorize

The result from an authorize request is usually true (successful), or false. The password may be omitted if the server does not require passwords.

mining.capabilities (DRAFT)

NOTE: This is a draft extension proposal. It is not yet in use, and may change at any moment.

The client may send this to inform the server of its capabilities and options. The singleton parameter is an Object describing capabilities; by default, it is considered as , "set_difficulty":[]>, but as soon as this method is used these must be explicitly included if desired. The "suggested_target" key may supersede the mining.suggest_target method.

Note that most of the keys do not have any meaningful value at this time, and the values thereof should be ignored (ie, only their presence matters).

mining.extranonce.subscribe

Indicates to the server that the client supports the mining.set_extranonce method.

mining.get_transactions

Server should send back an array with a hexdump of each transaction in the block specified for the given job id.

mining.submit

Miners submit shares using the method "mining.submit". Client submissions contain:

Server response is result: true for accepted, false for rejected (or you may get an error with more details).

mining.subscribe

The optional second parameter specifies a mining.notify subscription id the client wishes to resume working with (possibly due to a dropped connection). If provided, a server MAY (at its option) issue the connection the same extranonce1. Note that the extranonce1 may be the same (allowing a resumed connection) even if the subscription id is changed!

The client receives a result:

The result contains three items:

Subscriptions. - An array of 2-item tuples, each with a subscription type and id.
ExtraNonce1. - Hex-encoded, per-connection unique string which will be used for creating generation transactions later.
ExtraNonce2_size. - The number of bytes that the miner users for its ExtraNonce2 counter.

mining.suggest_difficulty

Used to indicate a preference for share difficulty to the pool. Servers are not required to honour this request, even if they support the stratum method.

mining.suggest_target

Used to indicate a preference for share target to the pool, usually prior to mining.subscribe. Servers are not required to honour this request, even if they support the stratum method.

Methods (server to client)

client.get_version

The client should send a result String with its name and version.

client.reconnect

The client should disconnect, wait waittime seconds (if provided), then connect to the given host/port (which defaults to the current server). Note that for security purposes, clients may ignore such requests if the destination is not the same or similar.

client.show_message

The client should display the message to its user in some reasonable way.

mining.notify

Fields in order:

Job ID. This is included when miners submit a results so work can be matched with proper transactions.
Hash of previous block. Used to build the header.
Generation transaction (part 1). The miner inserts ExtraNonce1 and ExtraNonce2 after this section of the transaction data.
Generation transaction (part 2). The miner appends this after the first part of the transaction data and the two ExtraNonce values.
List of merkle branches. The generation transaction is hashed against the merkle branches to build the final merkle root.
Bitcoin block version. Used in the block header.
nBits. The encoded network difficulty. Used in the block header.
nTime. The current time. nTime rolling should be supported, but should not increase faster than actual time.
Clean Jobs. If true, miners should abort their current work and immediately use the new job. If false, they can still use the current job, but should move to the new one after exhausting the current nonce range.

mining.set_difficulty

The server can adjust the difficulty required for miner shares with the "mining.set_difficulty" method. The miner should begin enforcing the new difficulty on the next job received. Some pools may force a new job out when set_difficulty is sent, using clean_jobs to force the miner to begin using the new difficulty immediately.

mining.set_extranonce

These values, when provided, replace the initial subscription values beginning with the next mining.notify job.

mining.set_goal (DRAFT)

NOTE: This is a draft extension proposal. It is not yet in use, and may change at any moment.

Informs the client that future jobs will be working on a specific named goal, with various parameters (currently only "malgo" is defined as the mining algorithm). Miners may assume goals with the same name are equivalent, but should recognise parameter changes in case a goal varies its parameters.

Features

Bandwidth consumption

Stratum V2 is optimized in two ways to reduce bandwidth consumption. First, because it’s completely binary instead of JSON-based like V1, the size of data transfers is minimized. Second, it eliminates many instances where data is being transferred unnecessarily (e.g. redundant messages), meaning that the total amount of data transfers is also minimized.

V2 typical share submission message is 32 bytes without encryption and 48 with it.

V1 typical share submission message is approximately 100 bytes

Technical Description

Having a binary rather than text-based protocol reduces bandwidth consumption considerably. Making messages human-readable in Stratum V1 resulted in some messages being approximately 2-3 times heavier than necessary, and those have now been reduced to a minimum size in V2.

Additionally, V1 includes some messages that are unnecessary altogether, such as mining.subscribe. By eliminating these instances, fewer messages need to be transmitted in total and bandwidth consumption is reduced even further.

Motivation & Impact

Reducing network traffic as well as client-side and server-side computational intensity translates to lower infrastructure costs for all participants. At the same time, a significant reduction in bandwidth consumption allows for hashing results to be transmitted more frequently, enabling more precise hashrate measurement and mining reward distribution as a result.

Server CPU load

With the introduction of standard and group channels for end devices, Stratum V2 enables efficient caching so that server CPUs don’t need to recompute the Merkle root for every share submission. This shifts more responsibility upstream from end mining devices to proxies that connect to pools via extended channels.

V2 70-80% reduction in CPU load on share submissions vs. V1

V1 Efficient caching is not possible. The Merkle root is recomputed for every submission.

Technical Description

Reduced server CPU load in Stratum V2 is a result of enabling end devices to do header-only mining. This means that the Merkle root is always provided by an upstream node and doesn’t need to be handled by end devices at all. In other words, end devices no longer have to perform any coinbase modifications. This makes computations simpler for miners, but it also has the added benefit of making work validation (i.e. CPU load) much lighter on the server side.

Motivation & Impact

As pool operators ourselves, one of our motivations for reducing server CPU load is probably rather obvious — it reduces our overhead costs. However, any pool can (and should) take advantage of this benefit, so the greater motivation in the big picture is simply to reduce the inefficiency of the entire network.

Job distribution latency

Pools can send jobs to workers ahead of time for future blocks, even before the prior block has been found. Then the pools can send the latest prevhash to the miners in a much smaller (i.e. faster) message, indicating that they should start working on the next block immediately.

V2 separates the messages, making it possible for the miners to start working on new (full) blocks more quickly after a previous block has been found.

V1 prevhash and future job are part of the same message, so pools send empty blocks.

Technical Description

Pools distribute jobs to miners by sending blocks containing some predefined data as well as some variable data that the miners handle. In Stratum V1, the predefined data includes the prevhash (i.e. hash of the most recently found valid block) and the Merkle root for the transaction set to be included in the current block. However, these two pieces of data aren’t seperabable, so there is a heavy (slow) data transfer necessary to distribute new jobs as soon as a new block (with a new prevhash) has been found and propagated. In Stratum V2, it’s possible to separate the prevhash from the rest of the predefined block data, which allows for the block data to be sent before a new prevhash is available. As a result, the new prevhash message can be sent on its own as soon as a valid block is found, and this transmission can occur much faster because the message doesn’t include heavier data. This enables miners to begin working on new jobs more quickly than they could with Stratum V1.

Motivation & Impact

Every millisecond that a miner has to wait to begin working on a new job is opportunity (i.e. money) lost. By separating the prevhash message from other job distribution messages in Stratum V2, those precious milliseconds can be saved.

Binary vs. non-binary

Stratum V2 is binary, which means messages are encoded so that machines can read and write them efficiently, but they aren’t suitable for humans to read or work with directly. As a consequence, the size of data transfers between miners, proxies, and pool operators is minimized.

V2 data transfers are not human-readable, but are significantly more efficient.

V1 sends human-readable (JSON) data, which helped with adoption and is easier to parse / debug, but is much less efficient.

Technical Description

The protocol has fixed message framing and is precisely defined, which means that there isn’t room for different interpretations of Stratum V2 like there was with V1. The specific message framing structure can be found in the ‘Framing’ section of the BIP.

Motivation & Impact

The original stratum protocol uses JSON, which has a very poor ratio between message payload size and actual information transmitted. Making Stratum V2 a binary protocol yields far better data efficiency, and the saved bandwidth can be used for more frequent submits to further reduce hashrate variance.

Man-in-the-middle attack prevention

To ensure the confidentiality and integrity of sensitive data, Stratum V2 uses a robust encryption scheme that prevents data from being deciphered by potentially malicious third parties. This protects miners from several attacks that are possible in V1, including hashrate hijacking in which a third party intercepts communication between a miner and pool and takes credit (i.e. steals payouts) for the work the miner has done.

Has mechanism(s) to prevent malicious parties from stealing hashrate and eavesdropping on mining data transfers?

Technical Description

Stratum V2 employs a type of encryption scheme called AEAD (authenticated encryption with associated data) to address the security aspects of all communication that occurs between clients and servers. This provides both confidentiality and integrity for the ciphertexts (i.e. encrypted data) being transferred, as well as providing integrity for associated data which is not encrypted.

Motivation & Impact

Stratum V1 is vulnerable to man-in-the-middle attacks of three varieties: eavesdropping on all communication between pools and miners, stealing metadata from ISP logs, and hashrate hijacking. These attacks can all be executed without being easily detected, making them all the more troublesome. Stratum V2 uses authenticated encryption with associated data (AEAD) so that possible adversaries will be unable to use share submission data to identify particular miners, thus maintaining the privacy of miners and protecting them against hashrate hijacking.

Empty block mining elimination

In Stratum V2, it is equally as efficient for pools to send full blocks for miners to begin working on as it is for them to send empty blocks (i.e. blocks that don’t contain any transactions). Since there is no extra delay caused by sending a full block, the incentive to send an empty block is eliminated.

No extra delay to send a full block vs. an empty block.

Slower to send a full block than an empty block.

Technical Description

Very similarly to the Job Distribution Latency section, the elimination of the incentive for empty block mining comes down to the separation of the prevhash message from other block header data. With Stratum V1, there is an incentive for pools to send empty blocks containing the new prevhash as soon as possible, as these messages will arrive faster than a message containing a full block. By separating these two messages in Stratum V2, it’s now possible for pools to send full blocks to miners before the new prevhash message. In other words, the miners can be prepared to start working on a new (full) block before the previous block has been found, and then all they need is the new prevhash message to begin working on that next block. Since this prevhash message is the same size (i.e. takes the same amount of time to arrive) regardless of whether or not the pool has sent an empty block or a full block, there is no longer an incentive to mine on empty blocks.

Motivation & Impact

As long as the incentive to mine on empty blocks exists, there is a nonzero chance that a miner will actually find a valid solution during this time and propose an empty block that’s accepted by the rest of the network. Given that there is no advantage to mining on an empty block vs. a full block with Stratum V2, empty block mining should effectively be eliminated.

This is the official documentation of lightweight bitcoin mining protocol.

If you’re looking for Stratum mining proxy, please visit mining proxy howto.
If you’re looking for mining software compatibility, please go to the compatibility section.

This page is both a technical documentation and advocacy of the new mining protocol which can be used for bitcoin mining. If you're a casual miner or just a regular bitcoin user, then you don't have to understand everything in this document.

The main reason why I designed this protocol and implemented opensource pool server is that the current getwork&LP mining protocol has many flaws and it can hardly be used in any large-scale setup. ASIC miners are probably coming at the end of the year 2012, so Bitcoin community definitely needs some solution, which will easily scale to tera-hashes per second per pool user.

1. Why to Change Something That Works?

Ntime Rolling: Not Enough Jobs For Fast Miners

Nowadays, for every received job from the server, a miner can modify only ntime and nonce. Nonce is a 32bit integer (4.2 billion of iterations). Ntime is a 32bit integer storing UNIX timestamp and should reflect current time, although optimized miners roll ntime slightly into the future, which gives more combinations to miners (nonce range * ntime range). However, a block created from massively modified ntime can be rejected by Bitcoin network.

Strictly following getwork specification, one getwork job is enough for 4.2GHash/s mining rig and (thanks to ntime rolling) this job is usable for one minute or until a new Bitcoin block arrives (depending on what happens first). So, for 42 GHash/s rig you’ll need 10 getwork requests at once, but usually a few more because of some pre-caching strategies implemented by miners to prevent idling on network latencies. And what about 1 THash/s ASIC miners coming soon? We simply need some solution where network load is not at all bounded to miners performance.

Long Polling: An Anti-Pattern

Getwork came as an easy solution for building standalone miners (do you remember when the official Bitcoin client was the only miner?), much before I built my first Bitcoin pool and when frequent polling of local bitcoin daemon wasn't an issue. When pools came into the game, people found out that they must decide between short polling intervals (=higher network load, lower stale ratio) and intervals, which don't overload network and servers, but lead to a much higher ratio of rejected shares. And long polling pattern was the answer. Long polling is a great way to achieve real-time updates using standard web technologies. But as I already mentioned in the text above, web technologies are not ideal for Bitcoin mining.

Another problem consists of packet storms, coming from clients trying to reconnect to the server after long polling broadcasts. Sometimes it's hard to distinguish valid long polling reconnections from DDoS attacks. All this makes pool architecture more complicated and harder to maintain, which is reflected in less reliable pool service and has a real impact on miners.

The solution for such issues is related to the previous point about driving load by the server and not by thousands of (sometimes) strangely implemented miners, who are aggressively trying to reach the server.

2. How Can We Fix All That?

Now we know what's wrong in the current situation, so let's design a new protocol and don't repeat bad decisions again:

Stratum Protocol

I originally designed Stratum protocol for lightweight Bitcoin client called Electrum. Later I found out that protocol requirements are quite similar to requirements for bitcoin mining, so I decided to reuse it as-is. Don't be confused by an esoteric protocol name, I tried to stick to standards as much as possible.

In a simplified manner, Stratum is a line-based protocol using plain TCP socket, with payload encoded as JSON-RPC messages. That's all. Client simply opens TCP socket and writes requests to the server in the form of JSON messages finished by the newline character \n. Every line received by the client is again a valid JSON-RPC fragment containing the response.

There are good reasons for such solution: it is very easy to implement and very easy to debug, because both sides are talking in human-readable format. The protocol is unlike many other solutions easily extensible without messing up the backwards compatibility. As a bonus, JSON is widely supported on all platforms and current miners already have JSON libraries included. So packing and unpacking of the message is really simple and convenient.

Extranonce Rolling: The New Dimension

This is probably the most innovative part of the new protocol. In contrary to current mining where only ntime and nonce can be iterated, Stratum mining protocol gives a power to miners to easily build unique coinbase transactions locally, so they'll be able to produce unique block headers locally. I recommend to iterate four bytes of extranonce, which gives the possibility to serve 18 EHash/s (Exa-hashes/s) mining rig from a single TCP connection. But it can be easily changed by the pool operator anytime.

Now it is going to be a bit technical, so let's explain it a bit. Block header (that string what is in getwork response and what miners are hashing) is composed from following parts:

Block version, nbits, hash of previous block in the blockchain and some padding bytes, which are constants.
Nonce and ntime, which miner can modify already.
Merkle root hash, which is created by hashing of bitcoin transactions included in the particular mining job.

To produce more unique block headers (and thus be able to generate more unique hashes), we have to modify something.

Every bitcoin block contains so-called coinbase transaction which specify the bitcoin address for sending block reward. Fortunately there's a chance to modify this transaction without breaking anything. By changing coinbase transaction, merkle root will change and we will have unique block header to hash. Currently this (creating unique coinbase) happens on pool servers. So let's move it to miners!

Other Decisions

JSON Versus Your-Preferred-Protocol

I considered many solutions for serializing and deserializing message payloads. I wrote some reasons for JSON above, but let's sumarize them again:

JSON payload is human readable, easy to implement and debug.
All bitcoin miners already have JSON libraries included. JSON has native support in almost every language.
In contrary of most binary protocol, JSON payload can be easily extended without breaking backward compatibility.
JSON-RPC already specifies three native message types which Stratum uses: request, response and notification. We don't need to reinvent a wheel.
JSON has definitely some data overhead, but Stratum mining messages typically fits into one TCP packet.

Why I throw away other serializers:

Custom text protocol is human readable and easy to debug, but not so easy to implement as it may look at first glance. We have to define a way how to pair request and response, because sequential processing of requests may be a bit tricky on some platforms (yes, now I'm referring Twisted framework which I used for pool implementation). We also have to define how to serialize various data types like lists or even mappings. JSON solve all this transparently for us.
Custom binary protocol is the most compact form which can saves a lot of bandwith, especially while dealing with binary data involved in bitcoin mining. However writing (de)serializers *properly* may be a bit tricky. I wanted the protocol which is easy to implement. Fiddling with byte order and binary headers is not what I was looking for.
Protocol buffers by Google is interesting concept which may fit the needs, except that only C++, Python and Java are supported.
Thrift is another binary protocol which I used some time ago, but it is defitely too heavy for our purposes.

Stratum Versus Getblocktemplate

Getblocktemplate introduced in bitcoind 0.7 is a very progressive solution for delegating block creation from full bitcoin client to standalone, specialized software. Stratum mining server uses getblocktemplate mechanism under the hood. There are still some reasons why Stratum is, in my opinion, a better solution for pooled mining:

There's really only one reason why Stratum is worse than getblocktemplate solution at this time: miners cannot choose Bitcoin transactions on their own. In my experience 99% of real miners don’t care about transaction selection anyway, they just want the highest possible block reward. At this point they share the same interest with pool operator, so there’s no real reason to complicate mining protocol just for those 1% who want to create custom blocks for the pool.

I already have some ideas for Stratum mining protocol extension, where miners will be able to suggest their own merkle branch (I call it internally “democratic mining”), which will solve such issues as centralized selection of transactions. For now I decided to focus on such a solution, which will fit to majority of miners and do some extensions later.

3. For Mining Software Developers

Stratum protocol is based on JSON-RPC 2.0. In this chapter I expect that you're familiar with this protocol and you understand terms like "request", "response" and "notification". Please read JSON-RPC specification for more details.

For high level image of the Stratum protocol concept, please read Stratum protocol specification on Google docs. This document needs some care, but give you the basic examples how to connect to Stratum server.

Exception Handling

Stratum defines simple exception handling. Example of rejected share looks like:

Where error field is defined as (error_code, human_readable_message, traceback). Traceback may contain additional information for debugging errors.

20 - Other/Unknown
21 - Job not found (=stale)
22 - Duplicate share
23 - Low difficulty share
24 - Unauthorized worker
25 - Not subscribed

Real-World Example

This chapter contains real log of miner-pool communication which solved testnet3 block

Miner Connects the Server

On the beginning of the session, client subscribes current connection for receiving mining jobs:

The result contains three items:

Subscriptions details - 2-tuple with name of subscribed notification and subscription ID. Teoretically it may be used for unsubscribing, but obviously miners won't use it.
Extranonce1 - Hex-encoded, per-connection unique string which will be used for coinbase serialization later. Keep it safe!
Extranonce2_size - Represents expected length of extranonce2 which will be generated by the miner.

Authorize Workers

Now let authorize some workers. You can authorize as many workers as you wish and at any time during the session. In this way, you can handle big basement of independent mining rigs just by one Stratum connection.

Server Start Sending Notifications With Mining Jobs

Server sends one job *almost* instantly after the subscription.

Small engineering note: There's a good reason why first job is not included directly in subscription response - miner will need to handle one response type in two different way; firstly as a subscription response and then as a standalone notification. Hook job processing just to JSON-RPC notification sounds a bit better to me.

Now we finally have some interesting stuff here! I'll descibe every field of the notification in the particular order:

job_id - ID of the job. Use this ID while submitting share generated from this job.
prevhash - Hash of previous block.
coinb1 - Initial part of coinbase transaction.
coinb2 - Final part of coinbase transaction.
merkle_branch - List of hashes, will be used for calculation of merkle root. This is not a list of all transactions, it only contains prepared hashes of steps of merkle tree algorithm. Please read some materials for understanding how merkle trees calculation works. Unfortunately this example don't have any step hashes included, my bad!
version - Bitcoin block version.
nbits - Encoded current network difficulty
ntime - Current ntime/
clean_jobs - When true, server indicates that submitting shares from previous jobs don't have a sense and such shares will be rejected. When this flag is set, miner should also drop all previous jobs, so job_ids can be eventually rotated.

How to Build Coinbase Transaction

Now miner received all data required to serialize coinbase transaction: Coinb1, Extranonce1, Extranonce2_size and Coinb2. Firstly we need to generate Extranonce2 (must be unique for given job_id!). Extranonce2_size tell us expected length of binary structure. Just be absolutely sure that your extranonce2 generator always produces extranonce2 with correct length! For example my pool implementation sets extranonce2_size=4, which mean this is valid Extranonce2 (in hex): 00000000.

To produce coinbase, we just concatenate Coinb1 + Extranonce1 + Extranonce2 + Coinb2 together. That's all!

For following calculations we have to produce double-sha256 hash of given coinbase. In following snippets I'm using Python, but I'm sure you'll understand the concept even if you're a rubyist! It is as simple as:

How to Build Merkle Root

Following Python snippet will generate merkle root for you. Use merkle_branch from broadcast and coinbase_hash_bin from previous snippet as an input:

How to Build Block Header?

Now we're almost done! We have to put all together to produce block header for hashing:

First zeroes are blank nonce, the rest is padding to uint512 and it is always the same.

Note that merkle_root must be in reversed byte order. If you're a miner developer, you already have util methods there for doing it. For some example in Python see Stratum mining proxy source codes.

Server Can Occasionally Ask Miner to Change Share Difficulty

Default share difficulty is 1

big-endian target for difficulty 1 is:

but server can ask you anytime during the session to change it:

This Means That Difficulty 2 Will Be Applied to Every Next Job Received From the Server.

How to Submit Share?

When miner find the job which meets requested difficulty, it can submit share to the server:

Values in particular order: worker_name (previously authorized!), job_id, extranonce2, ntime, nonce.

4. Downloads

- Source code of Stratum proxy on Github - Opensource bitcoin mining pool build on Stratum server framework in Python.

5. Compatible Miners

For all current getwork-compatible miners you can use Stratum mining proxy running locally on your mining computer. One mining proxy can handle (almost) unlimited number of connected workers, so running one proxy for all of your mining rigs is a way to go.

Miners with native support of Stratum protocol (no proxy needed!)

If you want support of Stratum protocol in your miner, just ask its developer and show him this page. Also don't hesitate to contact me and ask for implementation details.

Майнинг биткоина значительно изменился за последний десяток лет, но старейший майнинговый пул Slush Pool всегда оставался одним из самых популярных. Пражский пул выжил и окреп за время эволюции отрасли, а стоящая за ним компания Braiins стала ведущей силой в некоторых важных обновлениях.

Одним из ключевых обновлений последнего времени стал протокол совместного майнинга Stratum V2, заменяющий Stratum V1, сильно устаревший со времени создания в 2012 году:

Stratum V2 улучшает эффективность майнинга благодаря снижению объема частоты обмена данными. Это сокращает инфраструктурные издержки для майнеров и упрощает добычу криптовалют в удаленных локациях с медленным интернетом.

Новый протокол поддерживает шифрование, чтобы исключить атаки MitM («человек посередине»), искусственное завышение и кражу хэшрейта. Он также предлагает новую функцию децентрализации, вдохновленную BetterHash Мэтта Коралло (Matt Corallo), которая дает майнерам возможность выбирать задания для работы.

Criticism

Closed development

Displacing GBT

The next generation protocol for pooled mining by Pavel Moravec and Jan Čapek, in collaboration with Matt Corallo and other industry experts.

Stratum V2 is the next generation protocol for pooled mining. It focuses on making data transfers more efficient, reducing physical infrastructure requirements for mining operations, and increasing security. Additionally, Stratum V2 introduces three new sub-protocols that allow miners to select their own transaction sets through a negotiation process with pools, improving decentralization.

In the sections below, we’ll go through Stratum V2 feature-by-feature so that you can understand what’s changed from V1, why those changes matter, and how it all works on a technical level.

Note: Before you dive into the technical details, be sure that you understand the Terminology we’ll be using.

Принятие Stratum V2

После выпуска Braiins спецификации Stratum V2 она была положительно принята сообществом майнеров. Однако переход на новый протокол замедлился, так как нужно было решить множество мелких деталей и недочетов перед тем, как реализовывать его масштабную поддержку. Но уже в ближайшее время это изменится.

Компания Braiins, оператор Slush Pool, выпустила новый продукт с рабочей реализацией Stratum V2 и поддержкой автонастройки ASIC, востребованной пользователями. Речь идет о прошивке для ASIC-майнеров под названием Braiins OS, которая стала первой прошивкой с поддержкой AsicBoost в 2018 году и полностью открытым исходным кодом.

Недавно Braiins выпустила совершенно новую версию прошивки под названием Braiins OS+. Она основывается на исходном коде Braiins OS и поддерживает Stratum V2, но получила дополнительные проприетарные алгоритмы для автоматической настройки майнинговых ASIC. Они помогают майнерам увеличить прибыль со своего оборудования.

Software support

Tables showing miner/server support for Stratum mining protocol:

Читайте также:

Stratum protocol описание

Contents

Protocol Overview

Mining Protocol

The protocol defines three types of communication channels:

Job Negotiation Protocol

Template Distribution Protocol

Job Distribution Protocol

Protocol

Overview

Methods (client to server)

mining.authorize

mining.capabilities (DRAFT)

mining.extranonce.subscribe

mining.get_transactions

mining.submit

mining.subscribe

mining.suggest_difficulty

mining.suggest_target

Methods (server to client)

client.get_version

client.reconnect

client.show_message

mining.notify

mining.set_difficulty

mining.set_extranonce

mining.set_goal (DRAFT)

Features

Bandwidth consumption

Technical Description

Motivation & Impact

Server CPU load

Technical Description

Motivation & Impact

Job distribution latency

Technical Description

Motivation & Impact

Binary vs. non-binary

Technical Description

Motivation & Impact

Man-in-the-middle attack prevention

Technical Description

Motivation & Impact

Empty block mining elimination

Technical Description

Motivation & Impact

1. Why to Change Something That Works?

Ntime Rolling: Not Enough Jobs For Fast Miners

Long Polling: An Anti-Pattern

2. How Can We Fix All That?

Stratum Protocol

Extranonce Rolling: The New Dimension

Other Decisions

JSON Versus Your-Preferred-Protocol

Stratum Versus Getblocktemplate

3. For Mining Software Developers

Exception Handling

Real-World Example

Miner Connects the Server

Authorize Workers

Server Start Sending Notifications With Mining Jobs

How to Build Coinbase Transaction

How to Build Merkle Root

How to Build Block Header?

Server Can Occasionally Ask Miner to Change Share Difficulty

How to Submit Share?

4. Downloads

5. Compatible Miners

Criticism

Closed development

Displacing GBT

Популярность автоматической настройки

Принятие Stratum V2

Software support