Сложность сети Bitcoin: что это, как рассчитывается и почему меняется

Сложность сети Bitcoin — это параметр протокола, который регулирует, насколько трудно майнерам найти хэш, удовлетворяющий текущей цели Proof-of-Work. Она нужна не для того, чтобы сделать майнинг «сложным вообще», а для более конкретной задачи: удерживать средний темп появления новых блоков около заданного ориентировочного интервала, даже когда суммарная вычислительная мощность сети заметно растёт или падает. Без такого механизма подключение новых ASIC постепенно ускоряло бы выпуск блоков, а массовое отключение оборудования, наоборот, могло бы надолго замедлить цепочку.

Для обычного пользователя слово difficulty часто выглядит как ещё один абстрактный показатель рядом с хешрейтом, комиссией и ценой BTC. На практике эти величины отвечают на разные вопросы. Хешрейт описывает вычислительную активность майнеров, сложность задаёт текущую строгость требования к допустимому хэшу блока, комиссия отражает конкуренцию транзакций за место в блоках, а цена формируется на рынках. Они влияют друг на друга через экономику участников, но не являются одной и той же метрикой.

Главная польза понимания сложности — способность читать состояние сети без ложных выводов. Рост difficulty не означает автоматически рост курса. Снижение difficulty не делает Bitcoin «сломавшимся». Высокая сложность не гарантирует, что ваша конкретная транзакция подтвердится через десять минут. И наоборот, временно более медленные блоки ещё не означают, что алгоритм пересчёта перестал работать: механизм оценивает не один блок, а целый период.

В этом руководстве мы разберём механику от базовых понятий до практических расчётов. Сначала отделим target от difficulty и хешрейта, затем пошагово пройдём пересчёт через 2016 блоков, посмотрим, почему рост мощности отражается в difficulty с задержкой, как пересчёт влияет на ожидаемый доход майнера и что видит обычный пользователь. В конце будет набор команд Bitcoin Core и проверочный чек-лист, позволяющий самостоятельно сверить значения без доверия к графику стороннего сервиса.

Ключевая идея: сложность Bitcoin — это автоматическая обратная связь между фактическим темпом нахождения блоков и целевым темпом сети. Она реагирует не на цену и не на число транзакций напрямую, а на то, насколько быстро майнеры прошли очередной расчётный период.

Что такое сложность сети Bitcoin простыми словами

От «найти хэш» к измеримому условию

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

Цель, или target, — это фактическая граница допустимого хэша. Чем меньше target, тем уже диапазон подходящих результатов и тем труднее случайной попытке оказаться успешной. Difficulty — удобное относительное представление этой строгости. Поэтому target и difficulty движутся в противоположных направлениях: когда target уменьшается, сложность растёт; когда target увеличивается, сложность падает.

Эта обратная связь важна для чтения графиков. Если вы видите, что difficulty выросла на несколько процентов, это означает, что после пересчёта сеть установила более строгий target. Но не следует представлять, будто каждый ASIC физически начал считать «более тяжёлые» хэши. Устройство продолжает выполнять тот же SHA-256-процесс; меняется вероятность того, что очередной полученный результат будет принят как доказательство для блока.

Почему один блок не обязан находиться ровно за десять минут

Интервал около десяти минут — долгосрочный ориентир, а не обещание для каждого блока. Proof-of-Work вероятностен. Иногда подходящий хэш находится почти сразу, иногда поиск занимает заметно дольше. Даже при идеально неизменных хешрейте и сложности последовательность реальных интервалов будет неровной. Поэтому измерять здоровье сети по одному «быстрому» или «медленному» блоку бессмысленно.

Полезнее мыслить сериями. Если мощность сети резко выросла, блоки в среднем начнут приходить быстрее, но текущая difficulty останется прежней до очередной границы пересчёта. Если мощность резко упала, блоки временно будут идти медленнее. Именно накопленный результат расчётного окна показывает протоколу, в какую сторону нужно изменить target на следующий период.

Difficulty — относительная величина, а не время

Число difficulty удобно сравнивать с базовым минимальным уровнем Proof-of-Work. Оно не выражается в секундах, ваттах, долларах или хэшах в секунду. Это коэффициент относительной трудности. Поэтому фраза «сложность равна столько-то хэшам» некорректна без дополнительных оговорок: для оценки количества попыток используют вероятностную модель, а для оценки времени обязательно нужен хешрейт.

Интуитивно можно представить, что при difficulty D среднее число попыток до успеха масштабируется примерно как D, а ожидаемая работа традиционно связывается с величиной порядка D × 2^32 хэшей. Но это ожидание, а не гарантированное количество. Майнер может найти блок значительно раньше или позже среднего. Для отдельного устройства или пула реальное время определяется ещё и его долей в общем хешрейте.

Зачем Bitcoin вообще нужен автоматический пересчёт сложности

Что было бы при постоянной сложности

Представим сеть с навсегда зафиксированным target. На старте определённая вычислительная мощность давала бы средний интервал около десяти минут. Затем производители выпускали бы более эффективные ASIC, число операторов росло бы, а суммарный хешрейт увеличивался. При неизменной цели подходящие хэши находились бы всё чаще. Блоки ускорялись бы, вместе с ними ускорялась бы эмиссия новых BTC и менялась бы экономическая модель сети.

Обратная ситуация не менее проблемна. Если значительная часть майнеров отключилась бы из-за скачка цены электричества, запрета деятельности, аварии или падения доходности, фиксированный target остался бы рассчитан на прежнюю мощность. Блоки могли бы идти существенно медленнее. Очередь транзакций росла бы, подтверждения задерживались бы, а восстановление зависело бы только от добровольного возвращения мощности.

Стабильный денежный график требует стабильного темпа блоков

Bitcoin связывает выпуск новых монет с блоками: субсидия начисляется тому, кто создаёт допустимый блок, а её размер меняется по высоте цепочки. Поэтому приблизительно устойчивый темп блоков важен не только для пользовательского ожидания подтверждений, но и для предсказуемости денежного графика. Механизм difficulty adjustment не делает календарь идеальным, однако не позволяет долгосрочному росту оборудования бесконтрольно ускорять эмиссию.

Этим сложность тесно связана с темой предложения Bitcoin, но не дублирует её. В статье о том, как устроен Bitcoin, его эмиссия и сеть, difficulty — лишь один элемент общей системы. Здесь же нас интересует именно регулятор темпа: его математическая логика, задержка реакции и практические последствия для майнера и пользователя.

Почему сеть не корректирует difficulty каждый блок

На первый взгляд мгновенная коррекция кажется логичнее: если предыдущий блок пришёл быстро, немного повысить difficulty; если медленно — снизить. Но отдельный интервал слишком шумный. Случайность Proof-of-Work дала бы постоянные резкие колебания, а временные метки отдельных блоков получили бы чрезмерное влияние на параметр консенсуса. Bitcoin использует более длинное окно, чтобы реагировать на устойчивое изменение мощности, а не на естественную статистическую случайность каждого блока.

Период в 2016 блоков даёт компромисс между устойчивостью и скоростью адаптации. При целевом интервале 600 секунд это соответствует 1 209 600 секундам, то есть двум неделям. Фактический календарный период может быть короче или длиннее, потому что блоки приходят неравномерно и хешрейт внутри окна меняется.

Как Bitcoin пересчитывает сложность через 2016 блоков

Шаг 1. Сеть проходит расчётный период

На mainnet одна и та же difficulty действует внутри расчётного интервала. Узлы знают границы периода по высоте цепочки. До следующей границы новый блок обычно наследует то же значение nBits, которое кодирует target. Это значит, что график difficulty выглядит ступенчатым: параметр не обязан плавно двигаться вслед за хешрейтом каждый час.

Когда приходит высота, на которой должен начаться новый период, узел берёт временные метки начала и конца предыдущего окна и вычисляет фактическую длительность. Логика использует результат целого периода, а не среднее арифметическое нескольких последних блоков. Поэтому резкий приток мощности в середине окна влияет на пересчёт только через то, насколько он изменил суммарное время прохождения 2016 блоков.

Шаг 2. Фактическое время сравнивается с двумя неделями

Целевой timespan для mainnet равен 14 суткам. Если предыдущие 2016 блоков были добыты быстрее, фактическое время оказывается меньше целевого; новый target должен уменьшиться, то есть стать строже. Если период занял больше времени, target увеличивается, а difficulty снижается. В коде пересчёт target выражается пропорцией: прежняя цель умножается на фактическую длительность и делится на целевую длительность.

Из-за обратной связи между target и difficulty проценты не всегда симметричны. Если период прошёл за 90% от целевого времени, новый target составит примерно 90% прежнего. Difficulty при этом станет примерно 1 / 0,9 = 1,111 от прежней, то есть вырастет примерно на 11,1%. Если же период растянулся до 120% от нормы, target станет 1,2 от прежнего, а difficulty снизится примерно до 83,3% прежней — падение около 16,7%.

Шаг 3. Срабатывает ограничение экстремального изменения

Протокол не позволяет фактическому timespan безгранично влиять на одну корректировку. Перед расчётом слишком короткий период приравнивается минимум к четверти целевого timespan, а слишком длинный — максимум к четырём целевым timespan. Это ограничивает разовую смену target и защищает механизм от экстремальных значений. На языке difficulty это означает, что за один retarget нельзя получить произвольный стократный скачок только из-за одного необычного окна.

Важно не превращать это ограничение в бытовое правило «сложность всегда меняется максимум на X процентов» без понимания обратной зависимости. Код ограничивает именно используемый timespan и вычисляемый target. При очень быстром периоде target может стать не меньше четверти прежнего, что соответствует росту difficulty максимум примерно в четыре раза за один пересчёт. При очень медленном периоде target может вырасти максимум в четыре раза, что соответствует снижению difficulty до четверти прежней, если не мешает общий powLimit.

Шаг 4. Новый target становится правилом следующего периода

После расчёта target кодируется в компактном поле nBits, и последующие блоки должны удовлетворять новому порогу. Все полноценные узлы проверяют это независимо. Майнер не может объявить удобную себе difficulty: блок с неверным Proof-of-Work будет отклонён участниками, которые применяют те же правила консенсуса.

Именно независимая проверка делает difficulty частью протокола, а не настройкой майнингового пула. Пул может задавать собственную share difficulty для внутреннего учёта работы участников, но она не заменяет network difficulty. Share с низкой внутренней целью полезна для измерения вклада майнера; только хэш, соответствующий настоящему сетевому target, способен стать валидным блоком.

Хешрейт и сложность: связанные, но не одинаковые показатели

Хешрейт описывает поток попыток, difficulty — правило успеха

Хешрейт сети — оценка того, сколько SHA-256-вычислений майнеры в совокупности способны выполнять за секунду. Difficulty не измеряет эту скорость напрямую. Она задаёт вероятность успеха одной попытки. Чтобы оценить, с какой скоростью при данном target должны появляться блоки, нужно совместить оба элемента: частоту попыток и вероятность того, что случайный хэш окажется ниже цели.

Это различие объясняет распространённую ситуацию: хешрейт уже резко вырос, а difficulty на графике ещё не изменилась. Никакого противоречия нет. Внутри текущего окна правило остаётся прежним, поэтому большее число попыток приводит к ускорению блоков. Только на границе 2016-блочного периода сеть преобразует накопившееся ускорение в более высокую difficulty. После этого при том же хешрейте средний темп снова стремится к ориентиру.

Почему хешрейт сети нельзя измерить как мощность одного ASIC

Для отдельного устройства производитель или оператор может измерять хешрейт непосредственно по числу вычислений. У всей сети нет центрального счётчика, куда каждый майнер обязан сообщать реальную мощность. Поэтому network hashrate оценивается косвенно по тому, сколько блоков было найдено за выбранный промежуток при известной difficulty. Это статистическая оценка, а не телеметрия каждого чипа.

Отсюда следует осторожность при сравнении сайтов. Разные окна оценки могут показывать слегка разные значения хешрейта в один момент. Короткое окно быстрее реагирует, но сильнее шумит из-за случайности блоков. Длинное сглаживает шум, но медленнее отражает резкий приток или отключение оборудования. Для решения о майнинге важнее понимать методику и тенденцию, чем спорить о нескольких процентах расхождения между двумя графиками.

Что происходит, если мощность выросла сразу после пересчёта

Допустим, новый период только начался, а через несколько часов сеть получила крупный объём дополнительных ASIC. Текущая difficulty останется фиксированной почти на весь период. Блоки начнут находиться быстрее, и до следующей границы может пройти меньше двух недель. Майнеры в этот промежуток фактически делят большее количество блоков в единицу календарного времени, но одновременно каждый конкретный оператор конкурирует с большим общим хешрейтом.

На следующем пересчёте target станет строже. После этого календарный темп блоков приблизится к норме, а количество BTC, ожидаемое на единицу хешрейта, снизится относительно периода до роста конкуренции. Поэтому покупатель оборудования, который берёт доходность из «удачного» ускоренного окна и переносит её на месяцы вперёд, может получить завышенную модель.

Что происходит при массовом отключении майнеров

Если большая доля мощности исчезает в середине периода, блоки замедляются. Difficulty пока рассчитана на прежнюю вычислительную среду, поэтому оставшимся майнерам статистически требуется больше календарного времени, чтобы набрать те же 2016 блоков. После retarget target становится мягче, и при неизменном оставшемся хешрейте средний темп ускоряется обратно.

Такая задержка — важное свойство Bitcoin. Сеть не «понимает» причину отключения: авария это, экономический стресс, миграция оборудования или изменение политики в регионе. Она видит только историю блоков и применяет предопределённое правило. Благодаря этому пересчёт не требует голосования о том, была ли причина уважительной и насколько следует помочь майнерам.

Как сложность влияет на экономику майнинга Bitcoin

Почему рост difficulty уменьшает ожидаемые BTC на единицу хешрейта

Если ваш ASIC сохраняет один и тот же хешрейт, а network difficulty увеличивается, вероятность того, что именно ваша вычислительная работа приведёт к сетевому блоку, становится ниже при прочих равных. Для участника пула это отражается в ожидаемом количестве BTC на единицу времени: доля мощности майнера относительно эффективной сложности сети становится менее выгодной. Сам аппарат не стал медленнее, но конкуренция сети была преобразована протоколом в более строгий target.

Поэтому расчёт майнинга должен включать сценарий изменения difficulty. Модель, основанная только на текущем хешрейте устройства, цене BTC и тарифе электричества, неполна. Даже если цена и тариф останутся неизменными, рост общей мощности и последующие retarget способны последовательно сокращать добычу в BTC. Именно поэтому рекламная «окупаемость за N месяцев» без сценария difficulty почти всегда слишком хрупкая.

Difficulty и цена Bitcoin связаны экономически, но не формулой

Протокол не подставляет рыночную цену BTC в формулу пересчёта. Если курс вырос сегодня, next work required не изменится только из-за котировки. Однако цена влияет на решения людей и компаний: более высокая выручка может сделать выгодным включение старых машин, ускорить ввод нового оборудования и расширение дата-центров. Если из-за этого хешрейт устойчиво растёт, уже через темп блоков эффект косвенно дойдёт до difficulty.

При падении цены возможна обратная цепочка: маржинальные устройства становятся убыточными, часть операторов отключается, хешрейт снижается, период растягивается, следующая difficulty уменьшается. Но это не автоматическая и не мгновенная реакция. У разных майнеров разные тарифы, эффективность, долговая нагрузка, стратегии продажи BTC и договоры на электроэнергию. Поэтому цена и difficulty могут некоторое время двигаться даже в одном направлении, которое кажется «нелогичным» при упрощённой модели.

Электричество, эффективность и точка выключения

Для практического майнера difficulty важна через количество ожидаемых BTC на киловатт-час. Устройство с низким энергопотреблением на терахеш дольше выдерживает рост конкуренции, потому что его переменные расходы на единицу вычислительной работы ниже. Старый ASIC с плохой энергоэффективностью может стать первым кандидатом на отключение при росте difficulty, даже если он технически исправен и продолжает выдавать паспортный хешрейт.

Точка выключения не определяется одной network difficulty. Нужно одновременно учитывать цену BTC, pool fee, фактический accepted hashrate, потери на блоках питания и охлаждении, стоимость электроэнергии, простой, ремонт и налоги. Для более широкой производственной модели полезно сверить отдельный материал о том, как подтверждать происхождение добытых монет и сохранять историю выплат: прибыльность и доказуемость операций лучше проектировать вместе.

Пул не отменяет влияние сетевой сложности

Пул сглаживает дисперсию: вместо редкой полной награды майнер получает более частые выплаты пропорционально принятой работе по правилам пула. Но сетевой target остаётся тем же. Если network difficulty выросла, пул в целом также должен выполнить больше ожидаемой работы для нахождения блока. Внутренняя share difficulty помогает измерять вклад участников и уменьшать служебную нагрузку, однако не создаёт более лёгкий путь к настоящему блоку.

При сравнении пулов отделяйте три уровня: network difficulty, share difficulty и схему выплат. Первое задаётся консенсусом Bitcoin, второе — инфраструктурой пула, третье — его экономическими правилами. Ошибка в этих понятиях приводит к неверному выводу, будто пул с «меньшей сложностью шар» каким-то образом добывает сетевые блоки легче конкурентов.

Почему сложность Bitcoin растёт или падает

Ввод нового оборудования и рост эффективности

Самая очевидная причина устойчивого роста хешрейта — появление новых ASIC и расширение инфраструктуры. Если индустрия способна выполнить больше SHA-256-хэшей за тот же календарный промежуток, блоки при прежнем target начинают идти быстрее. Следующий пересчёт компенсирует ускорение повышением difficulty. В долгом горизонте технологический прогресс превращается в серию ступенчатых корректировок.

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

Отключения, аварии и ограничение нагрузки

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

Кратковременное отключение не гарантирует заметную коррекцию. Если мощность вернулась до завершения окна, ускоренные блоки поздней части периода могут частично компенсировать раннее замедление. Поэтому громкий заголовок о выключении конкретной фермы нельзя автоматически переводить в прогноз «difficulty обязательно упадёт на X%». Нужна картина всего периода.

Миграция хешрейта между операторами не всегда меняет сеть

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

Количество транзакций не является входом формулы difficulty

Ещё одна частая ошибка — связывать рост сложности с тем, что люди начали чаще отправлять Bitcoin. Транзакционная активность влияет прежде всего на mempool и комиссии. Майнер может получить более высокий fee income, а это экономически способно поддержать хешрейт, но формула retarget не считает число транзакций. Пустой блок и заполненный блок подчиняются одному сетевому target.

Если вас интересует именно пользовательская стоимость отправки, полезнее смотреть руководство о том, как рассчитывается комиссия криптоплатежа. Difficulty отвечает за условия Proof-of-Work, а ставка комиссии — за приоритет конкретной транзакции среди других заявок на ограниченное пространство блока.

Что изменение difficulty означает для обычного владельца Bitcoin

Difficulty не устанавливает комиссию вашей транзакции

Пользователь кошелька не выбирает network difficulty и не платит её как сбор. Комиссия относится к размеру транзакции и конкуренции за место в блоках. Майнеры отбирают операции по экономическим критериям, а затем должны найти Proof-of-Work для всего кандидатного блока. Поэтому рост difficulty сам по себе не добавляет фиксированную надбавку к вашей комиссии.

Связь может появиться временно через темп блоков. Если хешрейт резко упал сразу после начала периода, а difficulty ещё высокая, блоки в среднем могут приходить реже. За то же календарное время сеть обработает меньше блоков, и при активном спросе mempool способен расти. Тогда пользователи конкурируют ставками сильнее. После retarget более низкая difficulty помогает вернуть средний темп, но это всё равно не формула «difficulty +10% = fee +10%».

Десять минут — не обещание подтверждения

Даже при идеально настроенной сложности транзакция не обязана получить одно подтверждение через десять минут после отправки. Во-первых, следующий блок находится случайно. Во-вторых, ваша операция может не попасть в него из-за низкой ставки комиссии или ограничений политики узлов и майнеров. В-третьих, отправитель мог использовать заменяемую транзакцию или кошелёк мог неправильно оценить текущий рынок комиссий.

Если перевод действительно завис, диагностировать нужно не график difficulty в одиночку, а TxID, факт распространения транзакции, ставку sat/vB, состояние mempool и возможность RBF/CPFP. Для этого есть отдельная практическая инструкция о том, что делать с зависшей транзакцией Bitcoin и когда применимы RBF или CPFP.

Высокая difficulty не защищает приватный ключ

Рост вычислительной работы, необходимой для сетевого блока, относится к безопасности цепочки Proof-of-Work. Он не мешает злоумышленнику украсть seed-фразу, заразить устройство или подменить адрес в буфере обмена. Пользовательская безопасность остаётся отдельным слоем. Можно использовать сеть с огромной суммарной работой и всё равно потерять BTC из-за фишинга.

Поэтому «безопасность Bitcoin» нужно раскладывать на части. Difficulty и chainwork затрудняют переписывание подтверждённой истории при честном большинстве вычислительной мощности; кошелёк защищает ключи; практика проверки адреса снижает операционные ошибки; глубина подтверждений управляет риском реорганизации. Нельзя заменить один слой другим.

Почему инвестору не стоит использовать difficulty как одиночный сигнал цены

Difficulty показывает, какой target установил протокол после истории блоков. Это полезный показатель состояния майнинговой конкуренции, но он не измеряет спрос на BTC, ликвидность бирж, макроэкономические ожидания или поведение держателей. Рост difficulty может совпадать с ростом цены, отставать от него или продолжаться некоторое время при коррекции рынка из-за инвестиционных циклов майнеров.

Если цель — оценить сам актив, рассматривайте difficulty вместе с эмиссией, ликвидностью, условиями хранения и риском позиции. Не превращайте технический параметр в торговый индикатор с гарантированным направлением. Высокая конкуренция майнеров может быть признаком экономической устойчивости отрасли, но не обещанием доходности для покупателя BTC.

Сложность и халвинг: два разных механизма Bitcoin

Retarget управляет темпом, халвинг — субсидией

Сложность и халвинг часто оказываются на одном графике майнинга, но выполняют разные функции. Difficulty adjustment меняет target Proof-of-Work, чтобы компенсировать устойчивое изменение вычислительной мощности. Халвинг уменьшает субсидию блока по заранее заданной высоте. Первый механизм связан с тем, как трудно найти следующий допустимый блок; второй — с тем, сколько новых BTC разрешено создать в награде.

Различается и периодичность. Retarget происходит через 2016 блоков, поэтому в нормальном темпе — примерно раз в две недели. Халвинг происходит через 210 000 блоков — приблизительно раз в четыре года. Между двумя халвингами difficulty успевает измениться много десятков раз. Поэтому нельзя считать, что после сокращения субсидии сеть будет работать на неизменной сложности до следующего халвинга.

Почему difficulty не обязана упасть в момент халвинга

Сама высота халвинга не является командой снизить difficulty. В момент перехода к меньшей субсидии target остаётся тем, который уже действует в текущем периоде. Дальше экономика майнеров может изменить хешрейт: неэффективные машины отключатся, новые эффективные продолжат работу, часть операторов перестроит режим. Только фактическая скорость блоков внутри расчётного окна определит следующий retarget.

Именно поэтому возможен сценарий, когда после халвинга difficulty продолжает расти. Если отрасль заранее ввела новое поколение ASIC и суммарный хешрейт увеличился сильнее, чем выключилась старая техника, блоки будут находиться быстро, и пересчёт повысит сложность. Халвинг создаёт давление на доход BTC за блок, но не диктует итоговую вычислительную мощность.

Как одновременно учитывать halving и difficulty в модели майнинга

Для оборудования важны оба изменения. Субсидия определяет базовое количество новых BTC в блоке, а difficulty влияет на вероятность получить долю этих блоков при фиксированном хешрейте. Если субсидия уменьшилась вдвое и одновременно difficulty выросла, доходность старого устройства может ухудшиться сильнее, чем показывает простая таблица «до/после халвинга». Если difficulty затем снизилась из-за отключений, часть давления компенсируется, но субсидия назад не возвращается.

Разумная модель строит отдельные сценарии по цене, difficulty и тарифу. Для понимания самого денежного события полезно читать отдельный разбор халвинга Bitcoin и изменения награды, а затем накладывать на него текущую и ожидаемую сложность. Так два механизма остаются понятными, а не смешиваются в одну «майнинговую цифру».

Как самостоятельно проверить difficulty через Bitcoin Core

getdifficulty — самый прямой ответ

Если у вас запущен синхронизированный Bitcoin Core, команда getdifficulty возвращает текущую Proof-of-Work difficulty как относительное число. Это удобный способ проверить показатель без браузерного агрегатора. Значение приходит от вашего собственного узла, который уже проверил цепочку по правилам консенсуса. Для базовой сверки этого достаточно: вы видите difficulty того tip, который считает лучшим ваш узел.

Важно помнить о состоянии синхронизации. Если узел заметно отстаёт, его «текущая» difficulty относится к старой высоте. Поэтому перед интерпретацией значения полезно сравнить blocks и headers, проверить initial block download и убедиться, что best block соответствует актуальной цепочке. Независимая проверка сильна только тогда, когда вы понимаете, какие данные реально проверил ваш экземпляр.

getblockchaininfo — контекст вокруг текущей сложности

getblockchaininfo полезнее одиночного числа, когда нужно понять контекст. Ответ включает высоту валидированной цепочки, число заголовков, хэш лучшего блока и current difficulty. Это позволяет одновременно зафиксировать, к какой высоте относится показатель. Для журналирования майнинговой модели полезно сохранять height, timestamp наблюдения и difficulty вместе, а не только копировать одно число.

Такой снимок помогает сравнивать расчёты через несколько периодов. Например, вы можете раз в день записывать высоту, difficulty и оценочный network hashrate, а затем отмечать границы retarget. В отличие от случайного просмотра графика, журнал показывает, какая часть изменения произошла внутри фиксированного периода, а какая — в момент смены target.

getnetworkhashps — оценка, а не прямой датчик

Команда getnetworkhashps оценивает количество хэшей в секунду по истории блоков и difficulty. Параметр blocks определяет окно. Значение -1 использует блоки с последнего изменения сложности, что удобно для оценки текущего периода. Это всё равно статистическая оценка, потому что сеть не передаёт узлу реальные телеметрические счётчики каждого ASIC.

При коротком окне показатель будет сильнее реагировать на удачу и неудачу в нахождении блоков. При длинном — сглаживаться. Если вы анализируете вопрос «почему блоки последние сутки шли быстрее», можно смотреть короткий период; если оцениваете устойчивую тенденцию оборудования, разумнее сравнивать несколько окон и фактический timespan текущего difficulty interval.

getblockheader и getblock — bits, target и chainwork

Для конкретного блока можно запросить заголовок или полное описание. В ответе есть bits — компактное кодирование target, difficulty и chainwork. Полный target можно интерпретировать как порог допустимого хэша. Чем он меньше, тем выше difficulty. Chainwork показывает накопленную ожидаемую работу цепочки и полезен для понимания того, почему узлы сравнивают цепочки не просто по количеству блоков.

Работа с конкретными заголовками особенно полезна при обучении. Выберите блок до границы retarget и первый блок после неё, сравните bits и difficulty. Затем найдите начало предыдущего 2016-блочного окна и сопоставьте timestamps. Так формула превращается из абстрактного текста в воспроизводимую проверку на реальной цепочке.

Как построить собственную проверку одного retarget

Практический алгоритм выглядит так. Сначала определите высоту блока, на котором начался новый период. Затем возьмите последний блок предыдущего периода и первый блок того окна, по которому считается timespan. Вычислите разницу временных меток. Сравните её с 1 209 600 секундами, примените границы четверть/четыре timespan и получите ожидаемый коэффициент изменения target. После этого сравните с bits нового периода.

Из-за компактного представления и округления не стоит ожидать идеального совпадения десятичных процентов до бесконечного количества знаков. Для пользователя важна логика: фактический период → ограниченный timespan → новый target → новая difficulty. Полный узел применяет точные целочисленные правила консенсуса, а ваша ручная таблица служит проверкой смысла.

Практические примеры пересчёта сложности

Пример 1. Период прошёл на 10% быстрее

Предположим, предыдущая difficulty условно равна 100, а 2016 блоков были найдены за 90% целевых двух недель. Протокол уменьшит target примерно до 90% прежнего. Поскольку difficulty обратно пропорциональна target, новая difficulty будет около 100 / 0,9 = 111,11. Рост составит примерно 11,11%, а не ровно 10%. Это важная деталь при чтении прогнозов retarget.

Причина проста: мы сначала масштабируем допустимую цель, а уже потом рассматриваем её обратную величину. Если аналитик говорит «период на 10% быстрее, значит difficulty +10%», это удобное приближение для небольшой величины, но не точная пропорция. На больших отклонениях разница становится заметнее.

Пример 2. Период занял на 20% больше времени

Теперь 2016 блоков прошли за 120% от целевого timespan. Новый target примерно 1,2 от старого. При старой difficulty 100 новая станет около 83,33. То есть снижение примерно 16,67%. Такой пример показывает, почему проценты времени и проценты difficulty нельзя механически переносить с одинаковым знаком и величиной.

Для майнера это означает некоторое облегчение конкуренции на единицу хешрейта после границы. Но если блоки замедлились из-за падения хешрейта на 30%, снижение difficulty на 16,7% не обязательно полностью восстановит прежнюю доходность конкретной фермы: нужно учитывать фактическую долю мощности, дальнейшие подключения и отключения, комиссии и цену BTC.

Пример 3. Хешрейт вырос в середине окна

Пусть первые 1008 блоков прошли примерно по целевому темпу, а затем крупные мощности включились и вторая половина периода оказалась на 20% быстрее. Весь 2016-блочный timespan ускорится не на 20%, а примерно на 10% относительно исходного, если грубо считать равные половины. Retarget реагирует на суммарное время, поэтому дата включения мощности внутри периода важна для ближайшей коррекции.

Это полезно при чтении новостей о запуске большого дата-центра. Если мощности вошли за несколько десятков блоков до границы, их полный эффект не успеет проявиться в текущем retarget; часть уйдёт в следующее окно. Поэтому прогнозы, которые сравнивают только заявленный EH/s проекта с текущим network hashrate, могут ошибаться во времени реакции.

Пример 4. Резкое отключение сразу после retarget

Если после границы исчезает значительная вычислительная мощность, сеть почти весь следующий период будет работать на слишком высокой для новой мощности difficulty. Блоки растянутся, и календарная дата следующего пересчёта отодвинется. Это отличается от ситуации, когда отключение произошло за 50 блоков до границы: тогда retarget быстро отреагирует, но оценит лишь небольшую часть медленного режима.

Именно поэтому фраза «difficulty меняется раз в две недели» технически является приближением. Меняется раз в 2016 блоков. Две недели — целевое время при среднем десятиминутном интервале. Когда хешрейт резко падает, 2016 блоков могут потребовать больше календарного времени; когда растёт — меньше.

Пример 5. Экстремальное ускорение и ограничитель

Представим теоретический период, который прошёл всего за одну пятую целевого timespan. Без ограничения target был бы умножен на 0,2, а difficulty выросла бы в пять раз. Но код подставляет минимум четверть целевого времени. Поэтому target уменьшается максимум примерно до 0,25 прежнего, а difficulty — максимум примерно в четыре раза за один retarget. Это защита от чрезмерного шага одного окна.

Такие крайности полезны как учебный пример, но не должны становиться основой повседневного прогноза. Реальные изменения обычно намного умереннее. Ограничитель важен прежде всего как характеристика устойчивости алгоритма: он задаёт предел того, насколько резко история одного периода может изменить требования следующего.

Как читать график сложности без ошибочных выводов

Смотрите ступени, а не воображаемую плавную линию

У сетевой difficulty естественная ступенчатая структура. Между границами значение фиксировано, затем пересчитывается. Некоторые интерфейсы рисуют сглаженную линию или прогноз следующего изменения, и новичок может решить, будто протокол уже постепенно повышает сложность каждый час. Нужно отделять фактически действующее значение от оценки будущего retarget.

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

Не путайте историческую difficulty и «следующую оценку»

Историческая difficulty уже записана в валидных блоках через bits и проверена узлами. «Next difficulty estimate» на сайте — модель, а не часть консенсуса до фактической границы. Она зависит от того, какое окно времени и какую высоту использует сервис. Два сайта могут давать разные прогнозы и при этом оба не противоречат сети.

Для критичного расчёта фиксируйте источник и высоту. Если вы покупаете оборудование на основании expected retarget, используйте диапазон, а не одно число. При сильной чувствительности экономики к нескольким процентам difficulty проект уже находится близко к маржинальной зоне, и это нужно считать риском, а не точностью прогноза.

Сравнивайте difficulty вместе с хешрейтом и временем блоков

Один график difficulty показывает уже совершившиеся корректировки, но не всегда объясняет причину. Добавьте оценку network hashrate и фактический темп блоков внутри текущего окна. Если difficulty стабильна, хешрейт растёт, а блоки ускорены, логично ожидать давление на повышение следующей сложности. Если хешрейт падает и блоки замедлены, картина обратная.

При этом не следует искать идеально синхронные линии. Хешрейт оценивается статистически, difficulty меняется ступенями, цена торгуется непрерывно, оборудование вводится пакетами. Временные лаги — нормальная часть системы. Анализ становится качественнее, когда вопрос формулируют причинно: что изменилось первым, как это повлияло на блоки и когда механизм сможет отреагировать.

Chainwork важнее простого количества блоков при сравнении веток

Внутри повседневного разговора пользователи говорят о «самой длинной цепочке», но полный принцип выбора связан с накопленной работой. Chainwork отражает суммарную ожидаемую вычислительную работу Proof-of-Work для цепочки. Difficulty каждого блока участвует в этом накоплении. Поэтому ветка с большим количеством крайне лёгких блоков не должна автоматически побеждать более тяжёлую валидную историю.

Для обычного кошелька не нужно вручную вычислять chainwork, но понимание термина полезно: difficulty — не декоративный график майнеров, а часть того, как узлы оценивают работу, вложенную в историю блоков. При исследовании конкретного блока Bitcoin Core показывает chainwork вместе с bits и difficulty.

Ошибки, которые искажают понимание difficulty

Ошибка: «чем выше difficulty, тем дольше любой следующий блок»

Если хешрейт растёт одновременно со сложностью, новый target может быть строже, но суммарная вычислительная мощность уже больше. Retarget как раз стремится подобрать эти величины так, чтобы средний интервал вернулся к ориентиру. Поэтому нельзя сравнивать две difficulty без знания соответствующего хешрейта и делать вывод о времени блока.

Ошибка: «difficulty растёт из-за популярности Bitcoin у пользователей»

Популярность может косвенно изменить цену, комиссии и инвестиции в майнинг, но формула не получает число пользователей. Прямой вход — временные метки блоков расчётного периода и параметры консенсуса. Если сеть стала популярнее, но майнинговая мощность не изменилась, само количество кошельков не заставит target стать строже.

Ошибка: «после падения difficulty майнинг гарантированно выгоден»

Снижение сложности улучшает ожидаемую добычу на единицу фиксированного хешрейта относительно сценария без снижения, но прибыль — денежная величина. Если одновременно цена BTC упала сильнее или электричество подорожало, ферма может оставаться убыточной. Также нужно учитывать комиссии пула, простой, ремонт и капитальные расходы.

Ошибка: «пул может выбрать сетевую сложность поменьше»

Пул выбирает внутренние параметры share для распределения работы между участниками, но валидный блок должен соответствовать network target. Если оператор сформирует блок с хэшем выше сетевой цели, узлы его отвергнут независимо от того, сколько shares пул начислил участникам.

Ошибка: «ретаргет происходит каждые ровно 14 календарных дней»

Правило задано по количеству блоков. 14 дней — целевой timespan для 2016 блоков при 600 секундах на блок. Когда вычислительная мощность не соответствует текущей difficulty, фактический календарный интервал сдвигается. Поэтому дата следующего retarget прогнозируется по высоте и текущему темпу, а не закреплена в календаре.

Ошибка: «резкое падение хешрейта мгновенно снижает difficulty»

На mainnet внутри периода difficulty сохраняется. Падение мощности сначала проявляется как более медленный темп блоков. Только после достижения следующей границы накопленный timespan превращается в новый target. Это означает, что сеть способна испытывать временный период замедления до адаптации.

Практический аудит майнинга при меняющейся сложности

Фиксируйте базовую точку перед любым прогнозом

Перед расчётом доходности запишите дату, высоту блока, действующую difficulty, оценку network hashrate, модель устройства, фактический accepted hashrate и потребление из розетки. Без базовой точки невозможно понять, почему результат через месяц отличается от прогноза. Если одновременно изменились прошивка, температура, пул и difficulty, простого сравнения «добывал раньше — добывает сейчас» недостаточно.

Особенно важно измерять реальный accepted hashrate, а не только локальный показатель интерфейса ASIC. Пул может отклонять stale или invalid shares, соединение может давать простои, а перегрев — снижать частоту. Network difficulty влияет на ожидаемую долю, но операционные потери способны дать сравнимый эффект. Хороший журнал отделяет внешний фактор сети от собственной эффективности площадки.

Стройте три сценария difficulty вместо одного прогноза

Для горизонта нескольких месяцев полезно иметь base, stress и optimistic сценарии. Base может предполагать умеренный рост difficulty вслед за тенденцией; stress — ускоренный ввод мощности и несколько последовательных повышений; optimistic — стабильность или временное снижение. Цель не угадать точный процент, а увидеть, при какой траектории проект перестаёт покрывать переменные и постоянные расходы.

Если экономическая модель остаётся устойчивой только при неизменной difficulty, это слабый проект. История Bitcoin показывает, что вычислительная конкуренция меняется. Даже без прогноза конкретных ASIC разумно заложить запас. Чем дольше срок окупаемости оборудования, тем больше периодов retarget оно переживёт и тем опаснее экстраполировать сегодняшние BTC/TH/day на весь срок.

Разделяйте доход в BTC и денежный результат

Сначала считайте ожидаемые BTC на фактический хешрейт после pool fee и операционных потерь. Отдельно переводите их в денежную выручку по сценарной цене. Это позволяет увидеть, что именно ухудшилось. Рост difficulty обычно давит на количество BTC, получаемое фиксированной мощностью. Падение курса снижает денежную ценность тех же BTC. Два эффекта могут происходить одновременно, но управляются разными механизмами.

Такое разделение полезно и при росте цены. Если денежная выручка выросла, а BTC на терахеш упали из-за difficulty, нельзя считать, что оборудование стало технически эффективнее. Просто рынок компенсировал сетевую конкуренцию более высокой оценкой актива. Для капитального решения важно знать оба слоя.

Порог выключения должен быть записан заранее

Определите уровень выручки или маржи, при котором оборудование переводится в экономичный режим, останавливается либо перемещается. Решение, принятое заранее, защищает от ошибки невозвратных затрат: уже купленный ASIC не обязан работать в минус только потому, что за него заплатили. Difficulty — один из факторов, способных привести к порогу, но итог должен считаться по полному денежному потоку.

В порог включайте не только электричество. Учитывайте вентиляцию, трансформаторные потери, аренду, ремонт, персонал, связь, комиссию пула, стоимость простоя и финансовые расходы. Если оператор считает прибыль как «BTC по курсу минус розетка», рост difficulty обнаруживает слабость модели слишком поздно.

После каждого retarget обновляйте модель, а не переписывайте историю

Новая difficulty — объективное изменение условий. Обновите прогноз, но сохраните старую версию. Тогда через несколько периодов можно оценить качество предположений: насколько быстро росла конкуренция, как часто вы недооценивали простой, какую часть результата дала цена. Такой архив превращает майнинг из набора впечатлений в управляемый производственный процесс.

Сравнивайте одинаковые интервалы. Не берите один удачный день после снижения difficulty и месяц с несколькими авариями до него. Лучше использовать полные недели или расчётные окна, отдельно отмечая retarget и изменения оборудования. Чем чище эксперимент, тем полезнее вывод о влиянии сети.

Target, nBits и chainwork: технический слой без лишней мистики

Почему хэш сравнивают с target как число

Хэш блока обычно показывают шестнадцатеричной строкой, но для правила Proof-of-Work его можно рассматривать как большое целое число. Валидность требует, чтобы значение было не выше target. Из-за распределения результатов уменьшение target уменьшает долю возможных хэшей, которые проходят проверку. Майнер не знает заранее, какой nonce или набор данных даст успех, поэтому перебирает варианты.

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

Зачем нужен компактный формат nBits

Полный target — 256-битное число, которое неудобно хранить и передавать в человекочитаемом виде для каждого заголовка. Поле bits содержит компактное представление цели. Узлы декодируют его и проверяют, соответствует ли target правилам следующей работы. Для пользователя nBits полезен как первичный объект сравнения блоков до и после retarget.

Не следует трактовать bits как обычное десятичное число difficulty. Это кодированная цель. RPC-интерфейс Bitcoin Core дополнительно выдаёт difficulty уже в понятном относительном формате, поэтому для большинства проверок лучше использовать готовое поле. К bits стоит обращаться, когда вы исследуете конкретный заголовок или хотите воспроизвести правила расчёта.

Почему difficulty и chainwork — не одно и то же

Difficulty относится к условию отдельного блока или периода. Chainwork накапливает ожидаемую работу по всей цепочке. Если долгое время difficulty растёт, новые блоки добавляют больше ожидаемой работы, чем ранние блоки с очень лёгким target. Поэтому chainwork — историческая сумма, а current difficulty — моментный параметр текущего tip.

Это различие помогает понять выбор лучшей цепочки. Узел не должен выбирать историю только потому, что в ней на один заголовок больше. Важна накопленная работа допустимой цепи. Такой подход препятствует примитивному сценарию, где атакующий генерирует огромное количество дешёвых блоков с произвольно низкой сложностью и объявляет их «длиннее»: правила target и накопленная работа не позволяют принять такую историю как нормальную mainnet-цепь.

Почему изменение difficulty не переписывает старые блоки

Каждый исторический блок уже был проверен по target, который действовал на его высоте. Новый retarget применяется к следующему периоду и не делает старые доказательства «недостаточно сложными». Узел хранит контекст цепочки и знает, какие правила работы ожидались на каждой высоте. Поэтому современная высокая difficulty не требует заново майнить блоки 2009 года.

Это важно при исследовании истории. Если сравнить difficulty первых лет и современную, разница огромна, но валидность ранних блоков не ставится под сомнение. Они соответствовали тогдашним правилам и являются частью цепочки, к которой позже добавилась огромная накопленная работа.

Как использовать difficulty в анализе сети, а не в гадании

Для майнера — как переменную конкурентной среды

В производственной модели difficulty отвечает на вопрос: насколько изменилась статистическая трудность получить сетевой результат при моём фиксированном хешрейте. Она должна входить в прогноз BTC-output и чувствительность проекта. Но решение о покупке или отключении оборудования нельзя принимать по ней одной; добавляются цена, тариф, эффективность, надёжность и стоимость капитала.

Для пользователя — как объяснение временного темпа блоков

Обычному владельцу BTC difficulty полезна главным образом для понимания того, почему сеть способна адаптироваться к изменению вычислительной мощности. Если крупная доля хешрейта исчезла, временное замедление до retarget не означает постоянную деградацию. Если мощность выросла, ускорение блоков не означает, что теперь сеть навсегда будет подтверждать всё вдвое быстрее.

Для инвестора — как характеристика майнинговой конкуренции

Долгосрочная динамика difficulty отражает, насколько строгим стал Proof-of-Work target вслед за историей хешрейта. Это может говорить о масштабировании индустрии и стоимости конкуренции, но остаётся техническим параметром. Использовать его разумно как часть картины, а не как кнопку buy/sell. Корреляция прошлых периодов не превращается в правило будущей цены.

Для исследователя — как проверяемую величину из собственной ноды

Одно из сильных свойств Bitcoin — возможность не доверять дашборду. Узел сам проверяет заголовки, target и цепочку. Вы можете получить current difficulty, посмотреть nBits конкретного блока, вычислить timespan периода и сверить retarget. Такой воспроизводимый подход полезнее спора о том, чей график «правильнее».

Если нужно подтвердить не только параметры блока, но и конкретную денежную операцию, используйте TxID и обозреватель или свой узел. Отдельная инструкция показывает, как проверить транзакцию по TXID. Это другой уровень проверки: difficulty говорит об условиях Proof-of-Work, а TxID — об идентичности конкретной транзакции.

Для автора прогноза — как величину с обязательным лагом

Любой прогноз следующего retarget должен явно учитывать, сколько блоков уже прошло в текущем периоде и какую долю окна занимает наблюдаемое изменение хешрейта. Прогноз после 100 блоков намного менее устойчив, чем после 1900. Если мощность изменяется сегодня, текущая difficulty не обязана отражать это сегодня. В модели нужен лаг до границы.

Полезно указывать не только процент ожидаемой коррекции, но и диапазон. Например: при сохранении текущего темпа ожидается рост в определённом коридоре; если средний интервал вернётся к норме, итог будет меньше. Такой язык честнее и лучше соответствует вероятностной природе блоков.

Чек-лист: как проверить утверждение о сложности Bitcoin

Проверьте, о какой сложности идёт речь

Сначала выясните, говорит источник о network difficulty или о share difficulty пула. Если не указано, любое сравнение может быть бессмысленным. Сетевой показатель относится к консенсусному target; внутренняя сложность shares нужна пулу для учёта вклада. Их числовые значения могут отличаться на порядки.

Проверьте высоту блока и дату

Difficulty имеет смысл вместе с высотой. Снимок без block height трудно воспроизводить. Зафиксируйте tip, дату и timezone. Если источник публикует историческое значение, найдите блок периода и сравните bits. Для текущего значения убедитесь, что узел синхронизирован.

Отделите факт от прогноза следующего retarget

Текущая difficulty уже действует. Ожидаемое изменение — прогноз до границы. Проверьте, сколько блоков осталось до следующего кратного 2016 и сколько прошло времени. Ранний прогноз должен восприниматься как черновой диапазон, а не как утверждённое значение.

Сверьте tempo и network hashrate

Если источник объясняет ожидаемый рост difficulty ростом мощности, посмотрите фактические интервалы блоков и несколько оценок хешрейта. Одно заявление о запуске оборудования не гарантирует, что машины уже хэшируют mainnet. Сеть учитывает результат, а не пресс-релиз.

Не выводите цену из difficulty без дополнительных данных

Фраза «difficulty выросла, значит BTC обязан вырасти» не следует из протокола. Если материал делает рыночный прогноз, он должен отдельно обосновать спрос, предложение на биржах, ликвидность и прочие факторы. Difficulty может быть одним входом аналитической модели, но не заменяет её.

Для майнинга пересчитайте свой BTC-output после retarget

После фактической смены difficulty обновите expected BTC на единицу accepted hashrate и только затем денежную выручку. Если ваш пул показывает отклонение сильнее ожидаемого, проверьте удачу пула, stales, downtime и схему выплат. Не списывайте любую разницу на сеть.

• Определить: network difficulty или share difficulty.
• Записать height, timestamp и источник.
• Проверить current difficulty через собственный узел или надёжный источник.
• Уточнить позицию внутри 2016-блочного периода.
• Сопоставить фактический темп блоков и оценочный хешрейт.
• Отделить факт retarget от прогноза.
• Для майнинга обновить модель BTC-output, цены и расходов отдельно.
• Не использовать difficulty как одиночный прогноз цены BTC.

Как пересчитать влияние difficulty на собственный ASIC без самообмана

Начните с фактической производительности, а не с коробки

Первый шаг — отказаться от паспортного хешрейта как от единственной исходной величины. ASIC может показывать в локальном интерфейсе номинальные 200 TH/s, но пул принимает только ту работу, которая дошла до сервера вовремя и соответствует его правилам. Поэтому для расчёта лучше брать средний accepted hashrate за достаточно длинный период без аварий. Если локальный показатель заметно выше принятого, сначала найдите причину потерь, а уже потом объясняйте снижение выплаты ростом сетевой сложности. Иначе два независимых эффекта окажутся смешаны в одной цифре.

Практически полезно иметь три значения: номинальный хешрейт устройства, локально измеренный хешрейт и принятый пулом. Номинал нужен как характеристика модели, локальный показатель помогает выявить аппаратную деградацию, а accepted hashrate ближе всего к экономически оплачиваемой работе. Если после retarget network difficulty выросла на 5%, но accepted hashrate одновременно упал на 7% из-за перегрева, реальная просадка BTC-output будет заметно сильнее простой сетевой коррекции. Такой разбор сразу показывает, где искать улучшение: в инфраструктуре или в ожиданиях от сети.

Считайте относительное изменение, если нужен быстрый сценарий

Для быстрой оценки без сложного калькулятора можно использовать относительный подход. При неизменном хешрейте, одинаковой субсидии и сопоставимых комиссиях ожидаемый BTC-output примерно обратно связан с difficulty. Если сложность выросла с условных 100 до 110, прежний ожидаемый результат следует умножить примерно на 100/110, то есть получить около 90,9% старого уровня. Это не гарантирует фактическую выплату конкретного дня из-за удачи пула и изменений комиссий, но даёт хороший первый сценарий сетевого влияния.

Если difficulty, наоборот, снизилась со 100 до 90, относительный коэффициент будет около 100/90 = 1,111. При прочих равных ожидаемая доля на фиксированный хешрейт вырастет примерно на 11,1%. Обратите внимание, что снижение difficulty на 10% даёт рост ожидаемого output чуть больше 10% из-за обратной зависимости. Такая арифметика полезна для быстрой проверки калькулятора: если сервис после снижения сложности на 10% показывает рост добычи ровно на 40% при неизменных остальных параметрах, нужно искать дополнительное объяснение.

Отдельно учитывайте субсидию и комиссии блока

Ожидаемая выручка майнера возникает не только из протокольной субсидии. В блок входят комиссии транзакций, и их величина может заметно меняться между днями. Поэтому два периода с одинаковой difficulty и хешрейтом способны давать разный доход пула в BTC. Для анализа сетевой сложности удобно сначала оценить базовый эффект на вероятность нахождения блоков, затем отдельно наложить фактический fee income. Не следует объяснять высокие выплаты пула снижением difficulty, если в этот день сеть переживала всплеск комиссий.

Для долгосрочной модели комиссии лучше задавать диапазоном, особенно если вы не хотите строить прогноз на редких экстремальных периодах mempool. Субсидия известна по высоте и меняется при халвинге, difficulty меняется через 2016 блоков, а fee component плавает вместе со спросом на пространство блоков. Три источника изменения дохода следует хранить в отдельных столбцах. Тогда после месяца работы можно объяснить результат, а не просто констатировать, что фактическая добыча не совпала с калькулятором.

Переводите BTC-output в деньги только после сетевого расчёта

Когда ожидаемое количество BTC определено, только затем добавляйте цену реализации. Это дисциплинирует модель. Если difficulty выросла и BTC-output снизился на 8%, но курс вырос на 15%, денежная выручка может оказаться выше. Нельзя из этого сделать вывод, что рост difficulty полезен майнеру: его техническая доля ухудшилась, а рынок временно компенсировал эффект ценой. В другой месяц цена может двигаться в противоположную сторону, и компенсация исчезнет.

Для бизнеса полезно иметь отчёт в двух валютах: BTC и фиатной валюте расходов. В BTC видно влияние difficulty, pool luck и fee income. В фиатной валюте видно, способен ли проект оплачивать электричество, аренду и обслуживание. Если все показатели сразу пересчитывать в рубли или доллары, становится сложнее понять, что именно изменилось в производственной эффективности. Разделение помогает принимать решения о модернизации оборудования независимо от краткосрочного курса.

Сравнивайте не день к дню, а сопоставимые окна

Дневная выплата пула слишком шумна для вывода о difficulty. Даже крупный пул может иметь удачные и неудачные серии блоков, а отдельный майнер — временные проблемы связи или охлаждения. Лучше сравнивать периоды, достаточно длинные для сглаживания дисперсии, и отмечать границу retarget. Например, можно взять семь полных суток до изменения и семь после, исключив дни с авариями. Это не идеальный научный эксперимент, но намного полезнее сравнения двух случайных выплат.

Если вы используете PPS-подобную схему выплат, дисперсия может быть сильнее сглажена оператором пула, но всё равно остаются изменения комиссии, условий тарифа и accepted hashrate. При PPLNS или других схемах роль удачи пула видна сильнее. Поэтому перед сравнением нужно знать, за что именно платит выбранная схема. Network difficulty одинакова для всех участников mainnet, а финансовое отражение одного retarget в интерфейсе разных пулов может выглядеть по-разному.

Учитывайте задержку между изменением хешрейта и новым экономическим режимом

Если network hashrate растёт внутри текущего периода, ваш относительный шанс конкурировать уже уменьшается, даже до формального повышения difficulty: больше участников делают попытки при том же target, поэтому блоки идут быстрее и ваш пул получает меньшую долю блоков относительно всей мощности, если его хешрейт не вырос. На границе retarget ускорение преобразуется в более строгий target. Экономическая конкуренция проявляется непрерывно, а difficulty фиксирует её результат ступенчато.

Эта деталь важна для прогнозов «после следующего пересчёта доход упадёт на X%». Часть ухудшения могла уже произойти из-за роста общей мощности до retarget. Если калькулятор использует текущий network hashrate и текущую difficulty, он может частично учитывать это заранее. Поэтому нужно понимать методику сервиса. Простое удвоение эффекта — сначала от роста хешрейта, потом ещё раз от difficulty — способно занизить доход дважды за одно и то же изменение сети.

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

Одна корректировка редко определяет судьбу оборудования на год. В период активного ввода ASIC difficulty способна расти несколькими ступенями подряд. Если каждая ступень составляет, например, 5%, три последовательных повышения не складываются просто в 15% при пересчёте ожидаемого output. Новая база каждый раз меняется: итоговая difficulty будет около 1,05³ = 1,1576 от исходной, то есть примерно на 15,76% выше. Ожидаемый BTC-output при фиксированном хешрейте будет около 1/1,1576 = 86,39% исходного.

Такой накопительный эффект объясняет, почему длинная окупаемость особенно чувствительна к росту сети. Проект, который выглядит комфортно при одной коррекции +3%, может быстро потерять запас маржи после шести похожих периодов. Поэтому в stress-сценарии полезно моделировать не фантастический разовый скачок, а реалистичную серию умеренных повышений. Она лучше показывает, насколько оборудование устойчиво к конкуренции нового поколения ASIC.

Не забывайте о собственном росте хешрейта

Майнинговая компания может компенсировать часть роста difficulty расширением собственного парка. Если network difficulty выросла на 10%, но собственный accepted hashrate увеличился на 20%, абсолютный BTC-output компании способен вырасти, хотя эффективность на единицу оборудования снизилась. Для управленческого отчёта нужно отделять результат всего парка от результата на TH/s и на кВт·ч. Иначе закупка новых машин создаст иллюзию, что старая инфраструктура стала эффективнее.

Лучший набор удельных метрик — BTC на PH/s, BTC на МВт·ч, денежная маржа на МВт·ч и uptime. Они позволяют сравнивать поколения оборудования и площадки в условиях меняющейся network difficulty. Абсолютная добыча важна для казначейства, но не показывает качество производства. Если компания добывает больше BTC только потому, что удвоила мощность при ещё большем росте затрат, экономическое улучшение может отсутствовать.

Сделайте retarget частью регулярного операционного цикла

Практически удобно привязать пересмотр модели к каждому фактическому retarget. В день смены difficulty зафиксируйте старое и новое значения, принятый хешрейт парка, среднее потребление, payout scheme и текущую цену электричества. Пересчитайте base/stress сценарии и отметьте оборудование, приблизившееся к порогу отключения. Такой ритм соответствует самому протоколу и не требует гадать, когда следует обновлять модель.

Между retarget следите за темпом блоков и техническим состоянием, но не перестраивайте капитальный план из-за каждого часа network hashrate estimate. Это статистический показатель, который шумит. Регулярный двухнедельный цикл с внеплановым пересмотром только при действительно крупных событиях даёт более устойчивое управление. В итоге difficulty перестаёт быть графиком для наблюдения и становится понятным входом производственного процесса.

FAQ о сложности сети Bitcoin

Что такое сложность сети Bitcoin одним предложением?

Это относительная мера строгости Proof-of-Work target: чем выше difficulty, тем меньше диапазон хэшей, которые подходят для валидного блока, и тем больше вычислительных попыток в среднем требуется при неизменной мощности.

Как часто меняется сложность Bitcoin?

На mainnet пересчёт выполняется через 2016 блоков. При целевом интервале около десяти минут это примерно две недели, но календарная длительность меняется: если блоки идут быстрее, граница наступит раньше, если медленнее — позже.

Почему сложность растёт?

Обычно потому, что предыдущие 2016 блоков были пройдены быстрее целевого времени. Частая причина — устойчивый рост суммарного хешрейта из-за ввода оборудования или повышения эффективности. Протокол реагирует на фактический темп блоков, а не на причину роста мощности.

Почему сложность падает?

Если расчётный период занял больше целевых двух недель, новый target становится мягче и difficulty снижается. Это часто связано с уменьшением хешрейта после отключения части оборудования, но формула видит только время прохождения блоков.

Связана ли difficulty с ценой Bitcoin?

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

Увеличивает ли высокая сложность комиссию перевода?

Не напрямую. Комиссия транзакции определяется её виртуальным размером, выбранной ставкой и конкуренцией в mempool. Difficulty влияет на условия нахождения блоков. Временное изменение темпа блоков способно косвенно изменить очередь, но между процентом difficulty и sat/vB нет фиксированной формулы.

Что важнее: хешрейт или сложность?

Они отвечают на разные вопросы и нужны вместе. Хешрейт оценивает поток вычислительных попыток, difficulty задаёт вероятность успеха одной попытки через target. Для оценки среднего темпа блоков и доходности майнинга нельзя корректно использовать только одно из двух.

Можно ли узнать difficulty без стороннего сайта?

Да. Синхронизированный Bitcoin Core предоставляет getdifficulty, а getblockchaininfo показывает difficulty вместе с текущей высотой. Для конкретных блоков getblockheader и getblock позволяют увидеть bits, target-related поля, difficulty и chainwork.

Что будет, если половина майнеров внезапно отключится?

Текущая difficulty сразу не изменится. Блоки в среднем замедлятся, и следующий 2016-блочный период будет завершаться дольше. На границе retarget фактический timespan приведёт к более мягкому target. Точный результат зависит от момента отключения и дальнейшего поведения хешрейта.

Гарантирует ли высокая difficulty безопасность моих BTC?

Нет. Высокая накопленная вычислительная работа усиливает защиту истории Proof-of-Work от переписывания, но не защищает вашу seed-фразу, устройство или адрес от кражи и ошибки. Для хранения нужны отдельные меры безопасности кошелька.

Вывод: difficulty — механизм самонастройки, а не магический индикатор

Сложность сети Bitcoin лучше понимать не как рейтинг «насколько сейчас тяжело майнить», а как часть системы обратной связи. Майнеры создают фактический темп блоков своим суммарным хешрейтом. Протокол наблюдает время прохождения 2016 блоков и на границе периода корректирует target. Если блоки шли быстрее нормы, цель становится строже; если медленнее — мягче. Так Bitcoin сохраняет долгосрочный ориентир около десяти минут на блок без центрального диспетчера мощности.

Для майнера difficulty — критическая переменная ожидаемого BTC-output, которую нужно регулярно включать в сценарную экономику. Для пользователя — объяснение того, почему сеть временно ускоряется или замедляется после изменений хешрейта. Для исследователя — проверяемый параметр, который можно получить из собственной ноды. Для инвестора — полезная характеристика майнинговой конкуренции, но не самостоятельный прогноз цены.

Самый надёжный способ не запутаться — держать рядом четыре понятия: target, difficulty, хешрейт и время блоков. Target задаёт порог, difficulty выражает его относительную строгость, хешрейт описывает поток попыток, а фактические интервалы показывают результат их взаимодействия. Retarget связывает историю этих интервалов со следующим target.

Если нужно применить материал на практике, начните с собственного снимка: height, current difficulty, getnetworkhashps и положение внутри периода. Затем сравните данные после следующего retarget. Такой простой эксперимент показывает работу механизма лучше любой метафоры и позволяет отличать протокольный факт от прогноза или рекламного графика.

Ещё один полезный принцип — не пытаться объяснить одним показателем все процессы Bitcoin. Difficulty отлично отвечает на вопрос о строгости текущей работы, но не заменяет анализ мемпула, комиссий, рыночной ликвидности или безопасности ключей. Чем точнее определён вопрос, тем меньше риск сделать красивый, но неверный вывод. Если речь идёт о майнинге, добавляйте accepted hashrate и себестоимость; если о подтверждении платежа — состояние транзакции и ставку комиссии; если о надёжности хранения — модель кошелька и резервную копию. Такой подход делает техническую метрику рабочим инструментом, а не универсальным объяснением рынка.

При повторной проверке через несколько периодов смотрите не только на процент изменения difficulty, но и на то, как быстро сеть пришла к новому равновесию после изменения мощности. Именно последовательность событий — хешрейт, темп блоков, retarget, новый темп — показывает работу механизма обратной связи. Когда эта последовательность понятна, исчезает большая часть мифов о «ручном управлении сложностью» или о том, что майнеры могут коллективно выбрать удобное значение. Правила одинаково применяются узлами к каждому новому блоку, а изменение становится следствием измеренной истории предыдущего периода.