У владельца одного ASIC всё сравнительно просто: он видит свои устройства, свой хэшрейт и свои начисления. У дата-центра другая задача. На одной площадке могут работать десятки или сотни ASIC разных владельцев, и статистику нужно организовать так, чтобы каждый клиент видел только своё оборудование, инженер быстро находил проблемный воркер, а оператор мог восстановить данные за нужный период.
Поэтому для дата-центра майнинг-пул — не только stratum-адрес и комиссия. Пул становится одним из источников операционных данных: через него можно разделять клиентские мощности, контролировать воркеры и хэшрейт на стороне пула, разграничивать доступ к статистике, выгружать данные и формировать регулярные отчёты для владельцев оборудования.
Для площадки с клиентскими ASIC особенно важны пять вещей: раздельная статистика клиентов, контроль воркеров и хэшрейта, разграничение прав доступа, возможность выгрузки или интеграции данных и сохранение истории за нужный отчётный период.
Geometria Pool — майнинг-пул для ASIC-майнинга BTC, LTC и DOGE. На продуктовой странице собраны условия подключения, личный кабинет и основные правила работы пула.
Если задача — подключить клиентские или собственные ASIC к пулу, начните с условий Geometria Pool.
Чем требования дата-центра к пулу отличаются от требований одного майнера
Владелец одного или нескольких собственных ASIC обычно оценивает пул по понятным параметрам: поддерживается ли нужная монета, какова комиссия, какой действует порог выплаты, стабильно ли подключение и удобно ли смотреть статистику.
У дата-центра появляется дополнительная задача — разделить данные между владельцами оборудования. Недостаточно видеть общий хэшрейт всех устройств. Нужно понимать, как работает техника каждого клиента, кто имеет доступ к конкретной статистике и можно ли быстро восстановить историю за вчера, месяц или квартал.
| Критерий | Владелец 1–2 ASIC | Дата-центр / ASIC-хостинг |
|---|---|---|
| Структура оборудования | Несколько собственных воркеров | Отдельные группы устройств разных клиентов |
| Статистика | Один владелец видит всё своё оборудование | Данные разделяются между владельцами |
| Доступ | Один основной пользователь | Администратор, инженер, клиент, бухгалтерия |
| Хэшрейт | Контроль собственных ASIC | Сверка по клиентам, группам и отдельным воркерам |
| История | Личная сверка | Основа регулярных клиентских отчётов |
| Экспорт | Не всегда нужен | Важен при большом числе клиентов |
| API | Обычно необязателен | Полезен при автоматизации мониторинга и отчётности |
| Цена ошибки | Затрагивает одного владельца | Может затронуть сразу несколько клиентов |
Если статистика всех ASIC смешана в одном аккаунте, любой вопрос клиента — например, почему снизился хэшрейт или почему начисления за период отличаются от ожидаемых — превращается в ручную сверку.
Поэтому структуру аккаунтов, клиентских групп и воркеров лучше продумать до подключения большого парка оборудования, а не перестраивать уже работающую систему.
Как разделить клиентские мощности: субаккаунты, группы и воркеры
Для площадки с несколькими клиентами практичная модель — выделять каждому владельцу оборудования отдельный субаккаунт (subaccount) или другой изолированный раздел статистики. Внутри него находятся воркеры конкретного клиента.
Это не требование закона и не формальный отраслевой стандарт. Но подобную модель используют крупные международные пулы именно для управления несколькими группами оборудования.
Foundry позволяет создавать субаккаунты для отдельных групп ASIC, назначать им собственные воркеры и отдельно управлять правами доступа. В официальной документации Foundry также предусмотрена выгрузка данных о хэшрейте и вознаграждениях для операционной работы, бухгалтерии и сверки данных.
Braiins описывает субаккаунты как инструмент для раздельного учёта хэшрейта и вознаграждений по разным площадкам, клиентам или подразделениям. ViaBTC также позволяет вести отдельные субаккаунты с собственной статистикой хэшрейта и начислений.
Для дата-центра важен не сам термин «субаккаунт», а принцип: данные одного владельца оборудования не должны смешиваться с данными другого.
Как организовать имена воркеров
Имена воркеров лучше унифицировать для всей площадки. По названию инженер должен быстро понимать, какому клиенту принадлежит устройство, где оно находится и какой ASIC нужно проверить.
Например: client01.site01.s21-007
Это только пример, а не обязательный формат. Хорошая схема именования должна быть стабильной, понятной сотрудникам и пригодной для масштабирования. Стоит использовать уникальный идентификатор устройства, при необходимости код площадки и обезличенный код клиента. Не следует включать в название лишние персональные или коммерчески чувствительные сведения.
«По опыту работы с клиентскими площадками значительная часть споров о статистике возникает не из-за самого пула, а из-за структуры аккаунтов и воркеров. Если заранее разделить клиентов и договориться о единой схеме именования устройств, оператору значительно проще отвечать на вопросы по хэшрейту, простоям и начислениям».
Какие метрики пула нужны оператору площадки
Внутренняя система мониторинга дата-центра и статистика майнинг-пула показывают разные стороны работы ASIC. Дата-центр контролирует питание, сеть, температуру оборудования и инженерные события. Пул показывает, какую вычислительную работу он получает от подключённых ASIC.
Хэшрейт на стороне пула и локальный хэшрейт
Пул оценивает вычислительную мощность по shares — результатам вычислительной работы, которые ASIC отправляет на сервер пула.
Local hashrate, или локальный хэшрейт, рассчитывается самим ASIC либо системой управления оборудованием.
Pool-side hashrate, или хэшрейт на стороне пула, — расчётная оценка вычислительной мощности, которую пул получает на основе сложности принятых shares за определённый период. Поэтому локальный показатель и хэшрейт на стороне пула не обязаны совпадать в каждый момент времени.
Небольшое расхождение само по себе не означает потерю вычислительной работы. Если заметное отклонение сохраняется на сопоставимых временных интервалах, стоит проверить shares, соединение, настройки ASIC, прошивку и состояние оборудования.
Accepted, rejected и stale shares
Accepted share — результат вычислительной работы, который пул принял в соответствии с условиями текущего задания.
Rejected share — share, которую пул отклонил при проверке. Причиной могут быть недостаточная сложность результата, некорректные параметры, дублирование или другие причины, определяемые правилами конкретного пула. Если доля rejected shares растёт, первопричину уже ищут в соединении, настройках, прошивке и состоянии ASIC.
Stale share — результат, который поступил слишком поздно: пул уже перешёл к новому заданию, поэтому предыдущая работа устарела.
Если отклонение появляется только на одном воркере, сначала имеет смысл проверять конкретный ASIC. Если проблема одновременно появляется у нескольких групп устройств, сначала стоит проверить общий канал связи и работу пула.
При большом ASIC-парке даже небольшая систематическая доля rejected или stale shares становится заметной в абсолютном объёме непринятой или опоздавшей работы и может отражаться на итоговых начислениях.
Подробнее сетевые причины и влияние задержки разобраны в материале «Пинг до пула и stale shares: как задержка влияет на работу ASIC».
Роли доступа: что должен видеть клиент, инженер и бухгалтерия
Разделить ASIC по клиентам недостаточно. Нужно ещё определить, кто какие данные может видеть и изменять. Полный доступ к основному аккаунту не нужен каждому сотруднику дата-центра и тем более каждому владельцу оборудования.
| Роль | Какие данные нужны |
|---|---|
| Администратор площадки | Общая структура, клиенты, права доступа, настройки и операции |
| Инженер | Воркеры, хэшрейт, shares, offline-периоды и техническая статистика |
| Клиент | Только собственные ASIC, хэшрейт, активность, начисления и выплаты |
| Бухгалтерия | Периоды, начисления, выплаты, суммы и экспорт данных |
| Внешний специалист | Согласованный набор данных только для просмотра |
У крупных пулов подобное разграничение уже реализовано на практике. Foundry разделяет роли Owner, Accountant и Technician на уровне субаккаунтов. Viewer Links дают доступ только для просмотра хэшрейта и воркеров выбранного субаккаунта. Для финансовых данных используется отдельный механизм — Financial API Key, который может предоставлять read-only доступ к хэшрейту и BTC earnings.
Braiins поддерживает полный доступ, read-only и ограниченный read-only режимы, а также watcher links. ANTPOOL использует похожую модель под названием Observer.
Для дата-центра смысл такой архитектуры простой: клиент может самостоятельно проверить работу своего оборудования, но не получает доступа к данным других владельцев и не может изменить критические настройки аккаунта.
Название функции у разных пулов отличается, поэтому при выборе сервиса важнее проверять не термин Viewer или Watcher, а фактические права пользователя.
Когда дата-центру нужны API и экспорт данных
API может быть полезен крупной площадке, но сам по себе не является обязательным признаком хорошего пула.
Если клиентов немного и отчёт готовится раз в месяц, часто достаточно личного кабинета и выгрузки данных. API становится полезен, когда клиентов много и данные нужно собирать автоматически — например, для DCIM, CRM, биллинга или собственного клиентского кабинета.
| Сценарий | Личный кабинет | Экспорт | API |
|---|---|---|---|
| Несколько клиентов | Подходит | Подходит | Обычно не нужен |
| Ежемесячный отчёт | Подходит | Удобен | Необязателен |
| Собственный клиентский кабинет | Ограниченно | Ограниченно | Желателен |
| Автоматическая сверка | Неудобно | Частично | Подходит |
| Большое число клиентов | Неудобно | Частично | Подходит |
| Автоматические уведомления | Ограниченно | Не решает задачу | Возможны, если API отдаёт нужные данные и площадка настраивает собственную логику мониторинга |
У крупных пулов API действительно используется для B2B-задач. Foundry предоставляет отдельные механизмы доступа к данным субаккаунтов, Braiins позволяет работать через API с группами субаккаунтов, ANTPOOL предоставляет программный доступ к статистике аккаунтов и воркеров.
Но оператору стоит проверять не само наличие слова API в документации, а конкретный набор возможностей: можно ли получать данные отдельно по клиенту, доступны ли воркеры и история хэшрейта, есть ли данные о начислениях и выплатах, насколько глубока история и можно ли разграничить права API-ключей.
Как построить клиентский отчёт по данным пула и площадки
Клиентский отчёт не должен зависеть только от майнинг-пула или только от внутреннего мониторинга дата-центра. Эти системы отвечают на разные вопросы.
Пул показывает вычислительную сторону работы: активность воркеров, хэшрейт на стороне пула, принятые shares, начисления и выплаты.
Дата-центр показывает физическую сторону: работал ли ASIC, было ли питание, возникал ли перегрев, проводились ли инженерные работы, пропадало ли сетевое соединение и почему устройство простаивало.
| Раздел отчёта | Источник | Что показать |
|---|---|---|
| Период отчёта | Общий параметр | Начало и конец отчётного периода |
| Оборудование | Учёт площадки | ASIC клиента и соответствующие воркеры |
| Хэшрейт | Пул | Средний хэшрейт на стороне пула |
| Активность | Пул | Воркеры и периоды offline |
| Shares | Пул | Accepted / rejected / stale, если показатель доступен |
| Начисления | Пул | Данные за период, если выделяются по клиенту |
| Выплаты | Пул | Даты, суммы и статусы, если структура аккаунтов позволяет получить их отдельно |
| Простои | Площадка | Период и причина |
| Работы | Площадка | Инженерные действия с оборудованием |
| Комментарий | Площадка | Объяснение существенных отклонений |
Хороший клиентский отчёт отвечает на два вопроса: работало ли оборудование и как эта работа отразилась на стороне пула.
Пул может показать, что воркер перестал передавать работу, но сам по себе не всегда знает физическую причину: отключение питания, ремонт, перегрев, сеть или изменение настроек ASIC. И наоборот, система дата-центра может видеть исправное питание и доступный ASIC, но только статистика пула покажет, какую вычислительную работу сервис фактически получил от оборудования.
Регулярная форма отчёта снижает количество ручных разборов: клиент заранее знает, какие показатели получит, а оператор не собирает новый набор данных под каждый отдельный запрос.
Как данные пула использовать для внутренней сверки и подготовки отчётности
Для российской площадки важно не смешивать майнинг-пул, участника майнинг-пула и оператора майнинговой инфраструктуры.
С 1 сентября 2026 года действует Федеральный закон № 282-ФЗ, который определяет майнинг-пул как объединение мощностей нескольких технических и программно-аппаратных средств разных владельцев — участников майнинг-пула, при котором полученная цифровая валюта распределяется между участниками.
Закон отдельно определяет лицо, организующее деятельность майнинг-пула, и оператора майнинговой инфраструктуры. Это разные правовые роли. Статус оператора майнинговой инфраструктуры сам по себе не является регистрацией майнинг-пула.
Лицом, организующим деятельность майнинг-пула, может быть юридическое лицо, личным законом которого является российское право, либо индивидуальный предприниматель при соблюдении установленных законом требований. Это требование относится именно к организатору пула. Участниками майнинг-пула в предусмотренных законом случаях могут быть и физические лица — граждане РФ без статуса ИП.
Обязанность лица, осуществляющего майнинг
Лицо, осуществляющее майнинг, в том числе участник майнинг-пула, предоставляет ФНС установленные сведения о полученной цифровой валюте и адресе-идентификаторе, включая адрес-идентификатор майнинг-пула.
Срок — не позднее 20-го числа месяца, следующего за месяцем получения цифровой валюты.
Обязанность оператора майнинговой инфраструктуры
У оператора майнинговой инфраструктуры собственная обязанность по статье 86.5 НК РФ. Он предоставляет ФНС установленные сведения о лицах, которым оказывает услуги инфраструктуры.
Срок — не позднее 25-го числа месяца, следующего за истёкшим кварталом.
Использование майнинг-пула не заменяет самостоятельную обязанность лица, осуществляющего майнинг, предоставлять сведения в ФНС. Отдельные обязанности оператора майнинговой инфраструктуры также исполняются самим оператором.
Историю начислений, выплат и другую статистику пула разумно использовать как один из операционных источников данных для внутренней сверки и подготовки учёта. Но данные личного кабинета не следует считать единственным юридически достаточным подтверждением всей деятельности: состав документов зависит от статуса участника, операций и применяемого порядка учёта.
Подробно требования к майнерам и реестрам ФНС разобраны в материале «Легализация майнинга в России», а налоговые последствия операций — в статье «Операции с криптовалютой в России: налоги и закон в 2026 году».
Как протестировать пул перед переводом клиентских мощностей
Для одного ASIC смена пула обычно сводится к изменению настроек и последующей проверке хэшрейта. Для площадки с десятками или сотнями клиентских устройств одновременный перенос всего парка создаёт лишний риск.
Практичнее сначала выделить отдельную тестовую группу.
«Для B2B-площадки я рекомендую не переводить весь парк на новый пул одним переключением. Тестовая группа за 7–14 дней позволяет увидеть не только хэшрейт, но и качество статистики, поведение при переподключениях, удобство отчётности и работу поддержки. Это не нормативный срок — задача теста в том, чтобы принять решение по собственным данным площадки».
Период 7–14 дней подходит прежде всего для технической и операционной оценки пула. Делать по нему окончательный вывод о сравнительной доходности некорректно, если у сервисов различаются модели выплат, в разные периоды меняется сложность сети или отличается результат нахождения блоков пулом.
Geometria Pool для B2B-подключения
Geometria Pool — майнинг-пул для ASIC-майнинга BTC, LTC и DOGE. Пул отвечает за подключение вычислительной мощности, работу с воркерами, статистику, начисления и выплаты по правилам сервиса.
Для фермы или крупного ASIC-парка можно обсудить структуру воркеров, подключение нескольких устройств, порядок переноса мощности и B2B-сценарий работы. Техническая поддержка Geometria Pool работает на русском языке.
Физическое размещение оборудования относится к отдельному направлению. Если задача включает питание, охлаждение, интернет, обслуживание и размещение ASIC на площадке, условия рассматриваются отдельно на странице дата-центра Geometria.
Расскажите о количестве ASIC и текущей структуре подключения — команда Geometria Pool поможет определить маршрут подключения или поэтапного переноса мощности.
Частые вопросы о майнинг-пуле для дата-центра
Какой майнинг-пул нужен дата-центру?
Дата-центру нужен пул, в котором можно раздельно учитывать клиентские ASIC, видеть статистику до воркера, ограничивать права доступа и восстанавливать историю за нужный период. Экспорт и API становятся важнее по мере роста числа клиентов и автоматизации отчётности.
Нужно ли создавать отдельный субаккаунт для каждого клиента?
Это не требование закона и не универсальный формальный стандарт. Но отдельный субаккаунт или другой изолированный раздел статистики на каждого клиента — практичная модель для площадки с несколькими владельцами: данные по воркерам, хэшрейту и операциям не смешиваются.
Чем хэшрейт на стороне пула отличается от локального хэшрейта?
Локальный хэшрейт рассчитывается самим ASIC или системой управления оборудованием. Хэшрейт на стороне пула оценивается по принятым shares за определённый период. Поэтому показатели могут отличаться. Устойчивое заметное расхождение на сопоставимых интервалах — повод проверить shares, соединение, настройки и состояние оборудования.
Нужен ли дата-центру API майнинг-пула?
Не всегда. При небольшом числе клиентов обычно достаточно кабинета и выгрузки данных. API становится полезнее, когда площадка автоматизирует клиентские отчёты, интегрирует статистику в DCIM, CRM или собственный кабинет и обслуживает большое количество устройств и владельцев.
Как дать клиенту доступ к статистике без права менять настройки?
Если выбранный пул поддерживает Viewer, Watcher, Observer или другой режим только для просмотра, клиенту можно предоставить доступ к его статистике без административных прав. Важно проверить, какие именно данные доступны пользователю и может ли он изменять настройки аккаунта или выплат.
Достаточно ли истории майнинг-пула для налоговой отчётности?
Нет. История пула может использоваться как один из источников данных для внутренней сверки и подготовки учёта, но она не заменяет обязанностей налогоплательщика и необходимого комплекта документов.
Кто предоставляет сведения в ФНС — майнер или оператор майнинговой инфраструктуры?
Каждый исполняет собственную обязанность. Лицо, осуществляющее майнинг, включая участника майнинг-пула, предоставляет установленные сведения о полученной цифровой валюте и адресе-идентификаторе. Оператор майнинговой инфраструктуры отдельно предоставляет сведения по статье 86.5 НК РФ о лицах, которым оказывает услуги инфраструктуры.
Как безопаснее перевести большой парк ASIC на новый пул?
Сначала лучше выделить тестовую группу, сохранить исходные показатели, проверить новый пул на сопоставимых ASIC и оценить хэшрейт, shares, стабильность подключения, историю данных и работу поддержки. После этого оборудование переводят поэтапно.
Вывод
Для дата-центра майнинг-пул оценивается не только по комиссии. Ключевой вопрос — можно ли с его помощью раздельно контролировать клиентские мощности и восстановить понятную картину работы оборудования каждого владельца.
Практичная структура выглядит так: клиент → отдельная группа или субаккаунт → воркеры → хэшрейт и shares → разграниченный доступ → история → клиентский отчёт.
Для B2B-площадки новый пул разумно сначала проверить на части мощности: оценить качество статистики, стабильность подключения, работу с клиентскими данными и возможность восстановить историю за нужный период. Только после этого переводить основной парк.
Нужно подключить ASIC или обсудить перенос клиентских мощностей?
