Привет, Хабр. Меня зовут Олег Акулов, основатель и CEO Nomium. Сегодня расскажу историю, которую мы обычно не рассказываем клиентам на пресейле. Историю о том, как мы взяли проект, в котором не понимали вообще ничего, как клиент пропал на полгода, как наши подрядчики оказались бесполезны, и как мы осознанно обманули клиента по срокам.
И знаете что? Это был один из лучших проектов в нашей жизни.
Спойлер: сейчас RedRock Pool работает с хешрейтом ~2 EH/s, обрабатывает 10 000+ одновременных подключений ASIC, держит аптайм 99.9%+ и входит в топ-30 майнинг-пулов мира. Но путь туда был настолько сложным, что я до сих пор не понимаю, как мы выжили.
Когда к тебе приходят с задачей, в которой ты нихрена не понимаешь
Конец 2023 года. Через знакомого к нам выходит крупный промышленный майнер. У него десятки тысяч ASIC-ов, разбросанных по разным дата-центрам. Он хочет свой майнинг-пул — не публичный, а кастомный. Под свои нужды, без комиссий сторонних пулов, с полным контролем над инфраструктурой и выплатами.
Первая встреча. Мы сидим, слушаем, киваем головами. Внутри — тихая паника. У нас в компании ноль экспертизы в майнинге. Совсем. Мы делаем high-load системы, знаем блокчейн на уровне "биткоин существует", работали с финтехом. Но майнинг-пул? Stratum-протокол? Network difficulty? FPPS vs PPLNS? Это другая вселенная.
Но у нас есть внутренний принцип, который держит компанию на плаву: мы можем научиться всему, если у нас есть сильная команда и правильный подход. Достаточно сильные разработчики, опыт в распределённых системах, понимание нагруженных сервисов. Другой вопрос — как продать это клиенту, когда у тебя нет ни одного кейса в майнинге.
Решение нашлось быстро. У нас была партнёрская компания, которая занималась блокчейном — более сложные вещи на тот момент уже делала. Мы пошли к ним. Узнали, что экспертиза есть. Договорились: если что — они прикроют нас технически, мы возьмём их как субподряд.
На встрече с клиентом они продемонстрировали знания в майнинге, мы показали системный подход к разработке и управлению проектами. Клиент согласился работать с нами. Задача показалась ему решаемой, нам — амбициозной, но реальной.
Мы ушли на оценку. Посчитали, составили коммерческое предложение, отправили. Начали обсуждать детали, планировать старт.
И клиент пропал.
Полгода тишины и один важный провал
Клиент молчал. Мы пинговали — игнор. Писали — не отвечают. Прошёл месяц, второй, третий. Мы решили, что сделка сдохла. Закрыли её в Bitrix как проваленную и переключились на другие проекты.
Но за эти полгода произошло кое-что критически важное.
Мы начали работать с той самой партнёрской компанией — "экспертами в блокчейне" — на нескольких других задачах. Небольшие проекты, ничего сложного. И поняли, что они не могут делать продукты качественно. Они подводили дедлайны. Код был так себе. Коммуникация хромала. Они там достаточно сильно подвели нас на одном из проектов.
Стало очевидно: если мы пойдём с ними в майнинг-пул — они утопят его. Не со зла. Просто не дотянут.
Я принял решение: если клиент вернётся, мы идём без них. Полностью сами. Да, у нас нет экспертизы в майнинге. Но мы быстро учимся. А главное — мы не облажаемся там, где это критично: на архитектуре, на инфраструктуре, на коммуникации с клиентом.
И клиент правда вернулся.
Была конференция, мы там случайно встретились. Он сказал: "Всё в силе, просто решали legal вопросы — где регистрироваться, какую структуру выбрать. Месяца через два-четыре вернёмся, всё будет готово."
Через два месяца он действительно вышел на связь. Но мы уже были другими: без подрядчика, без "страховки", но с пониманием, что если берём проект — тащим его только сами. Никто нас не спасёт. Только мы.
Первые недели работы: когда понимаешь, что сроки — это фантастика
Стартанули. Погрузились в майнинг с головой.
Stratum-протокол — как ASIC-и общаются с пулом. Network difficulty — как считается сложность сети. Модели выплат: PPS, FPPS, PPLNS — какую выбрать и почему. Шардинг базы данных для обработки миллионов shares (долей работы, которые отправляют майнеры). Latency — почему даже 50 миллисекунд задержки могут стоить клиенту тысячи долларов.
Чем больше мы погружались, тем яснее становилось одно: это не просто сложно. Это пиздец как сложно.
И тут я осознанно понял: мы сроки зафакапим. Точно зафакапим.
Почему? Потому что у нас нет экспертизы. Мы разбираемся с нуля. На это нужно время — много времени. Даже при самом оптимистичном раскладе мы не уложимся в те цифры, которые озвучили клиенту на этапе оценки.
Но сказать клиенту на старте "мы не уложимся в сроки" — это самоубийство. Это убивает доверие. Это заставляет клиента задуматься: "А нужны ли мне эти ребята вообще?"
Поэтому я начал преподносить это потихонечку, дозированно.
"Вот тут оказалось сложнее, чем мы думали изначально."
"Здесь нужно больше времени на проектирование архитектуры — иначе в продакшене всё ляжет."
"Обнаружили bottleneck в базе данных, нужно переделывать схему шардинга."
Я не врал. Я просто дозировал правду. Показывал прогресс. Показывал, что мы работаем, думаем, решаем проблемы. Что мы не забиваем на проект и не исчезаем, как это сделал когда-то клиент.
Клиент нервничал. Задавал вопросы. Но видел, что мы движемся. А это главное.
Что спасло проект: параноидальная подготовка вместо экспертизы
Когда у тебя нет экспертизы в предметной области, у тебя два пути:
Делать на коленке, молиться и надеяться, что всё как-нибудь заработает.
Готовиться так параноидально, чтобы система выдержала всё — даже твои собственные ошибки.
Мы выбрали второй путь.
Service Level Objectives (SLO) — это первое, что мы сделали. Не абстрактные "быстро и надёжно", а конкретные, измеримые цифры:
Доступность (Availability): 99.9999% в месяц. Это ~4 минуты простоя. Жёстко? Да. Но меньше — уже не бизнес-требование.
Задержка (Latency): P99 времени ответа на сабмит share — не более 50 мс. Каждая миллисекунда задержки — это потенциальная потеря дохода клиента.
Обработка платежей (Payout Processing): от формирования транзакции до broadcast в сеть — не более 30 секунд.
Эти SLO стали нашим компасом. Когда хотелось срезать угол, сделать быстрее, проще — эти цифры не давали расслабиться. Они заставляли делать правильно.
Три недели на архитектуру — до того, как написали первую строчку кода. Зачем? Чтобы не переделывать всё в продакшене, когда клиент уже подключил реальные ASIC-и.
Мы спроектировали систему так:
Геораспределённые шлюзы (Stratum Proxy) — близко к дата-центрам клиента. Цель: зажать latency в 20-50 мс. Потому что разница между 50 мс и 100 мс — это процент потерянных shares. А это деньги.
Ingestion-конвейер — не просто "приёмник данных", а полноценный конвейер обработки: дедупликация, верификация сложности хэша, отсев мусора, отправка в очередь (Kafka) и хранилище (ClickHouse).
Биллинг на модели FPPS — клиент получает плату за каждую долю по фиксированному курсу, независимо от того, нашли мы блок или нет. Это превращает лотерею в предсказуемый cash-flow. Это то, зачем он вообще идёт в пул.
Система выплат — пакетные и on-demand (мгновенные), с полным аудитом каждой транзакции. Любая ошибка здесь — это не баг, это финансовый инцидент уровня S0.
Observability на стероидах — Prometheus, Grafana, Loki. Тысячи метрик, логи, трассировки. Мы видели всё: каждый запрос, каждую задержку, каждый сбой. Когда у тебя нет экспертизы, ты компенсируешь её видимостью. Ты не можешь предсказать, где будет проблема — но ты должен увидеть её в момент возникновения.
Самое болезненное: когда понял, что 3300 запросов в секунду — это не просто цифра
Когда мы начали разбираться в нагрузках, которые предстоит выдержать, я помню своё ощущение: "Ну ладно, 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, а от пикового.
Обновления без права на ошибку: канареечные релизы и graceful shutdown
Мы не могли просто взять и обновить все сервера разом. Если в новой версии баг — весь пул ляжет, клиент теряет тысячи долларов, мы теряем репутацию.
Поэтому каждый релиз у нас — это канареечный деплой. Обновляем одну ноду из кластера. Остальные работают на старой версии. Направляем на обновлённую ноду 5-10% трафика. Смотрим метрики: latency, error rate, CPU, количество обработанных шар. Если всё нормально — постепенно увеличиваем трафик до 100%. Только после этого обновляем следующую ноду. Процесс может занять несколько часов, но это гарантирует, что мы поймаем проблему до того, как она затронет весь пул. Метрики показывают аномалию — мгновенный откат, одна команда, и трафик возвращается на стабильные ноды.
Но самое сложное — это обновить ноды, которые принимают шары от ASIC-ов. Нельзя просто выключить сервер — майнеры потеряют подключение, шары в процессе обработки пропадут.
Мы реализовали graceful shutdown — корректное завершение работы без потери данных. Как это работает: убираем ноду из балансировщика, новые подключения идут на другие сервера. Закрываем приём новых соединений, но продолжаем работать с уже подключёнными ASIC-ами. Останавливаем выдачу новых задач — майнеры понимают, что новой работы не будет, заканчивают текущую. Ждём, пока все дошлют свои шары (есть разумный таймаут — 30-60 секунд). Принимаем и обрабатываем все in-flight запросы. Корректно закрываем каждое соединение — ASIC автоматически переподключается к другой ноде. Сбрасываем буферы: все накопленные шары уходят в базу батчами, ждём подтверждений записи. Фиксируем чекпойнты — какие офсеты обработаны, какие транзакции завершены (чтобы при перезапуске не обрабатывать данные дважды). Останавливаем процесс, обновляем. При старте прогреваем кэши, восстанавливаем состояние, запускаем проверку целостности. Возвращаем ноду в балансировщик.
Весь процесс — 2-5 минут на одну ноду. Но в это время остальные работают. Пул не останавливается. Майнеры ничего не замечают.
За всё время работы RedRock Pool у нас не было ни одного инцидента с потерей шар из-за обновлений. Аптайм 99.9%+ — это не красивая цифра для презентации клиенту, это результат параноидального подхода к каждому релизу.
Запуск: когда понимаешь, что не зря рисковал
Релиз. Подключаем реальные ASIC-и клиента.
Первый день: 1000 устройств. Работает.
Первая неделя: 5000 устройств. Работает.
Первый месяц: 10 000+ устройств, суммарный хешрейт ~2 EH/s.
Работает.
Средняя задержка (RTT): 80-120 мс даже при пиковых нагрузках.
Потери shares: менее 0.2%.
Аптайм: 99.9%+.
Клиент доволен. Мы — в шоке от того, что вытащили это. Команда — выжата как лимон, но счастлива.
RedRock Pool вошёл в топ-30 по хешрейту среди всех майнинг-пулов Bitcoin. Не сразу, но вошёл. И держится там.
Почему Nomium — одна из очень немногих аутсорс-команд, которая делает майнинг-пулы
Вот что интересно: все крупные майнинг-пулы делаются in-house командами. Компании собирают отдельный штат, строят систему годами, держат разработку внутри.
Nomium — одна из очень немногих аутсорс-компаний, которая делает майнинг-пулы под ключ. От требований до релиза и масштабирования. В продакшене. С реальными ASIC-ами и реальными деньгами на кону.
Почему так? Почему все остальные делают in-house?
Потому что остальные не готовы рисковать.
Взять проект без экспертизы — рискованно. Осознанно не уложиться в сроки и честно об этом говорить — рискованно. Отвечать за финансовые транзакции, где ошибка стоит тысячи долларов — рискованно.
Но мы не побоялись.
Мы подготовились так, чтобы система выдержала даже наши ошибки. Мы были честны с клиентом — дозированно, но честны. Мы тащили проект до конца, когда любая другая команда бы сдалась или передала клиенту недоделанный прототип.
И именно поэтому мы сделали то, что делают очень немногие в аутсорсе.
Что можно украсть из этой истории
1. Не бойтесь браться за проекты, в которых вы не эксперты.
Бойтесь браться за них без чётких SLO, продуманной архитектуры и готовности учиться быстрее, чем горит дедлайн.
2. Подготовка важнее экспертизы.
Параноидальное проектирование, запас прочности, observability — это компенсирует недостаток опыта в предметной области.
3. Сроки — это переговоры, а не обязательства.
Клиент понимает, если вы честны и показываете прогресс. Дозированная правда с демонстрацией движения вперёд работает лучше, чем обещания, которые вы не сможете выполнить.
4. Видимость системы спасает.
Когда у вас тысячи метрик и полная observability — вы не гадаете, вы знаете, где проблема. Это даёт уверенность даже в незнакомой предметной области.
5. Риск окупается, если вы готовы отвечать за него до конца.
Если вы берёте на себя ответственность и тащите проект, даже когда всё идёт не по плану — вы становитесь теми, кто может делать то, что другие боятся взять.
P.S. Сейчас RedRock Pool продолжает работать и масштабироваться. Клиент планирует расширение. А мы продолжаем доказывать, что аутсорс может делать сложные high-load fintech-системы не хуже, а иногда и лучше, чем внутренние команды.
А вы сталкивались с проектами, где отсутствие экспертизы заставляло вас готовиться параноидально? Где риск окупался сильнее, чем вы ожидали? Пишите в комментах — обсудим.
С уважением, Олег Акулов, основатель и CEO Nomium.