В мире блокчейн-разработки есть два типа команд: те, кто обещает "DeFi-протокол за месяц", и те, кто понимает, что архитектура важнее дедлайнов. Мы сделали ставку на честный инжиниринг и выиграли нетривиальную партию: создали промышленный майнинг-пул для Bitcoin без предыдущего опыта в разработке майнинг-пулов.
RedRock Pool — высоконагруженная платформа, которая обрабатывает подключения десятков тысяч ASIC-майнеров, держит ≈2 EH/s хешрейта и показывает 99.9%+ uptime.
Рассказываю, как это было: с деталями и цифрами.
У нас есть сильная команда, но без профильной экспертизы нужно было показать компетентность
— Давайте начнем с самого начала. Как к вам попал этот проект?
Меня порекомендовали знакомые, которые были связаны с ребятами, у которых огромные мощности в сфере майнинга — ряд майнинг-отелей, где размещается оборудование. У них была идея построить свой пул, потому что оборудования настолько много, что в принципе уже можно майнить самостоятельно, не прибегая к другим пулам.
Нас познакомили. Мы провели ряд встреч, обсудили детали, спроектировали драфт. Но тут важный момент: у нас на тот момент не было экспертизы именно в майнинг-пулах. Совсем. Мы делали высоконагруженные системы, работали с блокчейном, но майнинг-пулы — это отдельная специфика.
— И как вы решили эту проблему? Насколько это было вообще смело — браться за такой проект?
У нас есть сильная техническая команда с опытом в разных областях. Достаточно сильные ребята работают внутри компании — мы понимали, что можем освоить любую технологию. Другой вопрос — как показать эту компетентность клиенту без профильного опыта в майнинге.
Поэтому мы подстраховались партнёрской компанией, которая больше в сфере крипты, блокчейна точнее, более сложные вещи уже делала на тот момент. Мы пошли к ним узнать, есть ли у них экспертиза. Соответственно, получили информацию, что экспертиза есть. И мы понимали, что если что, мы подстрахованы другой компанией.
На первой встрече мы просто познакомились, поняли задачу. У них уже было небольшое описание — клиент понимал, что хочет получить. Мы общались на три стороны — моя компания, компания на подряде и клиент. Выясняли детали, нюансы и ушли на оценку.
— А что было дальше? Клиент сразу согласился?
Сделали оценку продукта и через месяц начали сотрудничество.
— За это время что-то изменилось с вашей стороны?
Да. В ходе этого времени пока клиент думал, мы поработали по нескольким проектам с этой подрядной компанией. И поняли, что они не могут делать продукты качественно.
Поэтому я принял решение, что мы не пойдём с ними в работу совместно. И уже когда мы начали работу над этим проектом, мы фактически были без субподрядной компании. Поняли, что мы полностью будем решать вопросы все сами.
Был определенный страх, что не уложимся в сроки, что можем сильно забуксовать на каких-то моментах. Но не было страха, что вообще не сделаем.
«Я осознанно понимал, что мы все сроки зафакапим. Прям точно»
— То есть вы изначально знали, что не уложитесь в сроки?
Да. Потому что у нас не было экспертизы в майнинге. Нужно было во всем разобраться, а на это нужно время. Я сразу понимал, что заявленные сроки — это фантастика.
Поэтому, само собой, клиенту мы говорили об этом постепенно. Не сразу "мы не укладываемся", а показывали прогресс и честно объясняли, где нужно больше времени.
И, соответственно, даже несмотря на то, что клиент может быть недоволен срывом сроков, нам нужно отдать качественный продукт. Поэтому он будет доделан, несмотря на то, что мы сроки потеряли.
— То есть честность перед собой важнее, чем красивая презентация сроков?
Именно. Изначально мы должны были сделать проект за шесть месяцев, но сделали за девять. Мы общались с коллегами по цеху, с командами, которые делали pool in-house. И все говорили, что они примерно разрабатывали полтора года и ещё полгода тестировали.
Получается, мы сделали протестированный пул за 9 месяцев. Да, первый месяц работали с минимальными мощностями. Но уже со второго месяца вышли на больше 2 EH/s. Поэтому я считаю, что мы уложились в отличные сроки.
— Почему вообще клиент выбрал вас? Outsource-команду без опыта в майнинге
Я думаю, здесь ряд факторов. Первый — это рекомендация от людей, которые нас хорошо знают и понимают, как мы работаем.
Второе — клиент оценил системный подход. Даже на пресейле было видно, что мы не первый день в теме, понимаем архитектуру и процессы. Это тоже повлияло на выбор.
Со стороны клиента это было не просто смело — это было реально смело.
— Насколько это было вообще смело и рискованно? Потому что майнинг-пулов в мире не так много, разработчиков ещё меньше.
Крупных майнинг-пулов в мире — штук 15-20. Ну, если считать только известные. Всего пулов может быть больше сотни, но мелкие не в счёт.
Сама задача была смелая. Все крупные пулы делают in-house — собирают команду с нуля, растят её годами. А мы — аутсорс-компания, уже готовая слаженная команда. И клиент выбрал именно нас.
Это было смело со стороны клиента, а мы понимали, что у нас нет права на ошибку.
Мы сейчас, я думаю, единственная аутсорс-команда на русскоязычном рынке, которая делала майнинг-пулы под ключ — от требований до релиза и масштабирования в продакшене. Остальные либо работают in-house, либо обещают много, а делают мало.
— Когда вы пришли к команде и сказали "мы делаем майнинг-пул", как они отреагировали?
Реакции в команде были разные. Техлиды загорелись сразу — классная задача, интересный челлендж. Разработчики отнеслись трезвее: некоторые не верили в сроки. Но в целом восприняли нормально — не первый наш большой high-load проект.
— Сколько людей было задействовано?
От 4 человек на старте до 8 в пике. Команда росла по мере необходимости: нужно тестирование — подключали тестировщиков, нужен backend — добавляли бэкендеров. Костяк — 5 человек, стабильно.
В любом крупном проекте есть сложные участки — туда просто нужно больше времени
— Как вообще была устроена разработка? У вас был какой-то конкретный подход?
У нас есть два этапа, когда мы идём в разработку. Первый этап — предпроект. Мы на этом этапе в рамках месяца обычно пишем подробно техническое задание, рисуем архитектуру системы, проектируем базу данных. В общем, мы продумываем до мелочей всё, и в том числе формируем уже бэклог для дальнейшей разработки.
Мы на этом этапе прям очень глубоко копаем и разбираемся. Соответственно, глобально архитектура не поменялась. Добавлялись какие-то дополнительные функции, джобы, какие-то микросервисы, но основная часть кор, которую мы закладывали, она и осталась такой же.
— Было что-то технически сложное или нестандартное?
В большом проекте всегда есть сложные участки — туда просто нужно больше времени. Да, были моменты, где приходилось глубоко погружаться. Но всё решаемо.
— А смелые технические решения были?
Не было. Наш подход скорее научный. Много систем с высокой нагрузкой за плечами, понимаем, как строить архитектуру.
Смелые решения в финтехе — это риск. А майнинг-пул — финтех. Тут каждая минута простоя стоит денег. Надёжность важнее креатива.
Поэтому ставим на проверенные технологии. Те, что отработаны годами.
Когда high-load перестал быть абстракцией
— Давайте поговорим про конкретные технические вызовы. Что было самым сложным?
Когда мы начали разбираться в нагрузках, которые предстоит выдержать, я помню своё ощущение: "Ну ладно, high-load, не первый раз". А потом увидел реальные цифры — и понял, что это реально сложно.
20,000 ASIC-ов. Каждый шлёт ~10 шар в минуту. Итого: 200,000 шар в минуту на сервер. Или 3300 запросов в секунду.
Каждую шару нужно провалидировать (проверить хэш, сложность), записать в базу без потерь, отправить в биллинг для начисления. В реальном времени. Потому что задержка или потеря данных — это прямая потеря дохода майнера.
Запустили первые тесты. База данных начала захлебываться. Write-load был слишком высоким. Запросы копились. Latency росла. Мы видели, как система трещит по швам, и я понял: в продакшене при первой же пиковой нагрузке это всё ляжет. А простой майнинг-пула — это не "сайт недоступен". Это тысячи долларов убытков клиента каждую минуту. Пока пул недоступен, ASIC-и либо простаивают, либо переключаются на резервный пул и платят комиссию конкурентам.
Когда на кону не просто удобство пользователей, а реальные деньги, которые тикают как счётчик такси, подход к разработке меняется радикально.
— Как решили?
Vardiff — переменная сложность задачи.
Если ASIC слишком мощный и шлёт шары слишком часто, мы автоматически повышаем сложность его задачи. Он дольше считает, реже отправляет данные на сервер. На его доход это не влияет — он получает плату пропорционально своей работе. Но для нас это означает выравнивание RPS и снижение пиковых нагрузок. Вместо хаотичного потока — управляемый.
Батч-запись в базу данных.
Мы перестали писать каждую шару по отдельности. Запросы проходят валидацию, попадают в буфер, накапливаются (100-500 записей, в зависимости от нагрузки) и уходят в базу одним батчем. Это радикально снизило количество операций записи. Плюс, если база временно недоступна (сетевой сбой, миграция), данные не пропадают — копятся в буфере и отправляются, как только связь восстанавливается.
Многоуровневая балансировка.
L4 (транспортный уровень) для быстрой маршрутизации TCP-соединений. L7 (уровень приложений) для умного распределения с учетом состояния серверов и географии. Поток данных равномерно распределился между нодами — один сервер больше не захлёбывался, пока остальные простаивали.
Система начала стабильно обрабатывать 3300+ запросов в секунду без потерь. Latency держалась в пределах 80-120 мс. База перестала быть узким местом. Но главное — мы поняли: в high-load системах недостаточно "сделать быстро". Нужно сгладить пики, снизить количество операций, распределить удар. Иначе система ломается не от среднего RPS, а от пикового.
— А как обновляете систему без простоя?
Мы не могли просто взять и обновить все сервера разом. Если в новой версии баг — весь пул ляжет, клиент теряет тысячи долларов, мы теряем репутацию.
Поэтому каждый релиз у нас — это канареечный деплой. Обновляем одну ноду из кластера. Остальные работают на старой версии. Направляем на обновленную ноду 5-10% трафика. Смотрим метрики: latency, error rate, CPU, количество обработанных шар. Если всё нормально — постепенно увеличиваем трафик до 100%. Только после этого обновляем следующую ноду. Процесс может занять несколько часов, но это гарантирует, что мы поймаем проблему до того, как она затронет весь пул. Метрики показывают аномалию — мгновенный откат, одна команда, и трафик возвращается на стабильные ноды.
Но самое сложное — это обновить ноды, которые принимают шары от ASIC-ов. Нельзя просто выключить сервер — майнеры потеряют подключение, шары в процессе обработки пропадут.
Мы реализовали graceful shutdown — корректное завершение работы без потери данных. Как это работает:
Убираем ноду из балансировщика, новые подключения идут на другие сервера
Закрываем приём новых соединений, но продолжаем работать с уже подключёнными ASIC-ами
Останавливаем выдачу новых задач — майнеры понимают, что новой работы не будет, заканчивают текущую
Ждём, пока все дошлют свои шары (есть разумный таймаут — 30-60 секунд)
Принимаем и обрабатываем все in-flight запросы
Корректно закрываем каждое соединение — ASIC автоматически переподключается к другой ноде
Сбрасываем буферы: все накопленные шары уходят в базу батчами, ждём подтверждений записи
Фиксируем чекпойнты — какие офсеты обработаны, какие транзакции завершены
Останавливаем процесс, обновляем
При старте прогреваем кэши, восстанавливаем состояние, запускаем проверку целостности
Возвращаем ноду в балансировщик
Весь процесс — 2-5 минут на одну ноду. Но в это время остальные работают. Пул не останавливается. Майнеры ничего не замечают.
За всё время работы RedRock Pool у нас не было ни одного инцидента с потерей шар из-за обновлений. Аптайм 99.9%+ — это не красивая цифра для презентации клиенту, это результат параноидального подхода к каждому релизу.
99.9% uptime — результат мониторинга, кластеров и параноидальной подготовки
— Как вы добивались стабильности? Вы часто про это говорите.
Мы очень много времени тратим на инфраструктуру. Мы её постоянно мониторим.
Во-первых, у нас всё покрыто различными способами мониторинга и алертинга. То есть каждый инцидент мы сразу узнаём об этом за долю секунды.
Плюс дежурный 24/7 следит за показателями серверов. И сам подход к разработке. Мы пишем качественный код — сразу думаем про производительность, про оптимизацию базы. Закладываем это на старте, чтобы потом не переделывать под нагрузкой.
Стараемся заложить запас прочности на старте. Меньше проблем в продакшене.
Инфраструктура: несколько дата-центров, всё в кластерах. Базы, сервисы — всё дублируется.
В случае даже проблемы у хостер-провайдера у нас есть резервные каналы, которые сразу же переключаются, и мы не теряем трафик.
— И это сработало с первого релиза?
За годы в IT я видел десятки запусков. Обычно первые недели в продакшене — это ад. Стабильность хромает у всех, даже у сильных команд.
У нас глобальных проблем не было. Пара мелких сбоев — не в счёт. А для майнинга это критично: минута простоя = тысячи долларов потерь. Поэтому готовились с запасом.
Когда достигли 2 EH/s — понял: мы это сделали
— Какой был самый эмоциональный момент за весь проект?
Когда клиент через 4 месяца после релиза сказал, что почти окупил разработку — охренеть! Вот это было круто.
— А когда пришло осознание: "Да, мы реально это сделали"?
Когда достигли 2 EH/s. Это уже не тестовые несколько машинок — это промышленный пул. Полноценный работающий сервис.
Вот тогда — да, мы это вытащили. 9 месяцев вместо 6, но не полтора года, как у других. Не затянули.
— Если бы вам нужно было заново делать этот проект, что бы вы сделали по-другому?
Я бы, наверное, завел сразу большую команду, потому что мы долго раскачивались, мы долго разбирались в специфике, в некоторых специфичных моментах.
Сейчас уже есть экспертиза. Но, наверное, на первом этапе надо было больше подключать команду, чтобы успеть построить основную бизнес-логику, которая не завязана на сам процесс майнинга, а просто бизнес-логику вокруг.
Чтобы тогда мы, скорее всего, могли бы даже, может быть, уложиться в сроки или же затянуть не на 3 месяца, а на месяц всего.
— А если сейчас придёт ещё один заказ на майнинг-пул, за сколько вы его сделаете?
Я думаю, месяца за 3.
Блокчейн будет интегрирован в нашу жизнь рано или поздно
— Было ли что-то кардинальное, что полностью изменило ваш подход или заставило пересмотреть взгляды?
Кардинальных выводов нет. Но есть несколько наблюдений.
Майнинг оказался интересным и очень прибыльным. Я это знал, но не представлял масштабов.
Плюс было интересно погрузиться в Bitcoin. Мы обычно делаем Web3-проекты на Ethereum — это другая архитектура, другая логика. А Bitcoin — это основа основ, первый блокчейн. Глубокое погружение в него меняет понимание технологии.
— А почему вам вообще нравится блокчейн? Что там цепляет?
Блокчейн рано или поздно встроится в нашу жизнь. Просто бизнес пока не готов — не умеет считать экономическую эффективность внедрения.
Но через 5-10 лет блокчейн будет везде. Как минимум это снизит зависимость от централизованных компаний — тех, кто сейчас держит серверы, приложения, банковские системы.
Для пользователей это означает больше безопасности и контроля.
Вместо заключения: Что мы поняли за эти 9 месяцев
RedRock Pool — это история не про блокчейн и не про майнинг. Это история про то, как правильно взяться за сложную задачу.
Что можно взять из этой истории:
Не бойтесь браться за проекты, в которых вы не эксперты.
Бойтесь браться за них без четких SLO, продуманной архитектуры и готовности учиться быстрее, чем горит дедлайн.Подготовка важнее экспертизы.
Параноидальное проектирование, запас прочности, observability — это компенсирует недостаток опыта в предметной области.Сроки — это переговоры, а не обязательства.
Клиент понимает, если вы честны и показываете прогресс. Дозированная правда с демонстрацией движения вперед работает лучше, чем обещания, которые вы не сможете выполнить.Мониторинг и метрики решают всё.
Когда у вас тысячи метрик и полная observability — вы не гадаете, вы знаете, где проблема. Это дает уверенность даже в незнакомой предметной области.Риск окупается, если вы готовы отвечать за него до конца.
Если вы берёте на себя ответственность и тащите проект даже когда всё идёт не по плану — вы становитесь теми, кто может делать то, что другие боятся взять.
P.S. RedRock Pool работает и масштабируется. Клиент планирует расширение.
Nomium — одна из немногих аутсорс-компаний на русскоязычном рынке, которая делает промышленные майнинг-пулы под ключ. Результаты: 99.9% uptime, 2 EH/s в продакшене, окупаемость за 4 месяца.
Есть проект, на который смотришь и думаешь: "Охренеть, мы это сделали"? Делитесь историями в комментах.