Привет, Хабр. Меня зовут Олег Акулов, я основатель и CEO Nomium. Обычно я пишу код или руковожу проектами, но сегодня — расскажу историю. Историю о том, как мы замахнулись на проект, который по всем канонам должен был разорить нас и клиента, а в итоге стал одним из наших главных кейсов экспертизы. Это был не просто «ещё один майнинг-пул». Это был вызов на грани фола.
Запускать в 2025 году свой майнинг-пул? Серьёзно? Все крупные игроки уже поделены, битва за хешрейт давно закончилась. Но наш клиент пришёл не за «очередным пулом». У него был парк в десятки тысяч ASIC-ов, разбросанных по разным уголкам планеты, и конкретная бизнес-задача — не просто майнить, а делать это с максимальной эффективностью и контролем. И он понимал, что типовые решения его не устраивают. Вот тут-то и началось самое интересное.
Зачем лезть в казалось бы закрытую нишу?
Короткий ответ: потому что кастомные решения всегда открывают ниши. Длинный — наш клиент, крупный промышленный майнер, столкнулся с тем, что публичные пулы съедали его маржу комиссиями, не давали нужной глубины аналитики и не позволяли гибко управлять приоритетами выплат. Его цель была не в том, чтобы стать новым F2Pool, а в том, чтобы построить высокоточный инструмент для своего собственного бизнеса.
Вызов был простым и одновременно пугающим:
Обеспечить стабильную работу с десятками тысяч одновременных подключений ASIC-ов.
Гарантировать отказоустойчивость на уровне 99.9999% — каждая минута простоя это тысячи долларов убытков.
Добиться минимальной задержки (latency) между майнером и сервером пула. Разница в даже 100 мс напрямую влияет на количество принятых шар и, следовательно, на доход.
Спроектировать и реализовать честную, прозрачную и безотказную систему мгновенных выплат.
И всё это — в условиях жёстких бюджетных и временных рамок. Стандартный путь «возьмём готовое опенсорсное решение и накрутим сверху» отпал сразу. Опыт подсказывал, что на таких масштабах оно ляжет в первый же час пиковой нагрузки.
С чего начинается ад? С неправильных SLO
Первое, что мы сделали — не побежали писать код. Мы сели и стали формулировать Service Level Objectives (SLO). Это не про формальности. Это про то, чтобы все — от заказчика до самого junior-разработчика — понимали, что значит для системы «работать нормально».
Ошибка №1, которую делают многие: ставят абстрактные цели типа «система должна быть быстрой и надёжной». Фигня. Быстро — это сколько? Надёжно — это сколько? Мы договорились до цифр:
Доступность (Availability): 99.9999% в месяц. Это примерно 4 минуты простоя в месяц. Жесть? Да. Но меньше — уже не бизнес-требование, а фантазия.
Задержка (Latency): P99 (99-й процентиль) времени ответа сервера пула на сабмит шар — не более 50 мс.
Сквозная обработка платежа (Payout Processing): От момента формирования транзакции до её broadcast в сеть — не более 30 секунд.
Формулировка этих SLO — и было нашим первым «гениальным провалом». Мы тогда ещё не до конца осознавали, во что ввязались. Но именно эти цифры, как компас, вели нас весь проект, не позволяя халтурить и принимать половинчатые решения.
И знаете что? В продакшене мы по некоторым пунктам даже превзошли эти цели. Нам удалось удержать среднюю задержку (RTT) на уровне 80-120 мс даже при пиковых нагрузках, а потери шар составили менее 0.2% — это был прямой результат той самой параноидальной подготовки.
Архитектура до MVP: зачем проектировать то, чего ещё
Здесь многие agile-евангелисты меня сейчас возненавидят. Мы не стали сразу делать «минимально жизнеспособный продукт» в понимании «слепили кое-как на коленке и будем итеративно переделывать». С итерациями — да. Но стартовать с архитектурного хаоса на таком проекте — это самоубийство.
Мы потратили почти три недели только на проектирование высокоуровневой архитектуры. Зачем?
Чтобы говорить на одном языке. От DevOps до бизнес-аналитика — все видели одну и ту же картинку.
Чтобы выявить узкие места до того, как они выявят себя сами в продакшене. Например, мы сразу поняли, что база данных станет главным бутылочным горлышком, если пойти по пути монолита.
Чтобы оценить риски и стоимость. Когда у тебя есть схема, ты понимаешь, во сколько встанет каждая единица масштабирования.
Наша архитектура с самого начала была заточена под горизонтальное масштабирование и отказоустойчивость. В итоге мы построили систему, которую внутри назвали RedRock Pool (RRPool). Мы отказались от идеи единого центрального сервера в пользу геораспределённой сети шлюзов (Stratum Proxy), расположенных близко к крупным дата-центрам клиента. Каждый шлюз принимал подключения от майнеров, агрегировал данные и пересылал их на центральный ingestion-конвейер.
Поток данных был выстроен в чёткий конвейер:
ASIC → Stratum Proxy (балансировка, кэширование джоб).
Proxy → Ingestion (дедупликация, верификация хэша и сложности).
Ingestion → ClickHouse (для аналитики и расчётов) + Очередь сообщений.
Биллинг-движок (расчёт по модели FPPS с учётом network difficulty).
Система выплат (пакетные и on-demand, с полным аудитом).
Такая модульность позволила нам добиться главного: линейного масштабирования под нагрузку. Итоговый результат — запуск за ~6 месяцев и рост до ≈2 EH/s суммарного хешрейта уже в первый месяц работы. Система стабильно выдерживала подключения 10 000+ ASIC-ов.
Что пошло не так? Всё. И это было лучшее, что могло произойти
Мы запустили первый тестовый кластер с имитацией нагрузки в 5000 подключений. И всё полетело к чертям. База данных не выдерживала write-load, шлюзы начинали терять пакеты при скачках нагрузки, а один из серверов решил уйти в ребут посреди теста.
Команда была в легком шоке. Но именно здесь и проявилась ценность подготовки.
Вместо хаотичных правок кода мы действовали по плану, который в итоге стал нашим стандартом для всех высоконагруженных проектов:
Изолировали проблему через тотальную Observability. Мы с первого дня заложили в систему Prometheus, Grafana, Loki — тысячи метрик, логи и трассировки. Мы видели всё. Мы знали не просто «что сломалось», а «на каком именно запросе и почему».
Не стали костылить. Соблазн «быстро починить» давал временное решение, но ломал архитектуру. Мы вместо этого пересмотрели дизайн проблемных модулей.
Усилили слабые места. Тот самый «провал» в тестировании показал нам реальные, а не гипотетические узкие места. Мы укрепили их с запасом, который изначально казался избыточным.
Например, проблема с базой данных заставила нас перейти с «шаблонного» шардинга на более сложную, кастомную схему распределения данных, которая учитывала географию майнеров. Это было сложнее, дольше, но в итоге — в разы эффективнее.
Почему это было гениально? Потому что мы сымитировали катастрофу в контролируемых условиях, а не в продакшене, когда на кону были бы реальные деньги клиента. Мы не испугались провала, а использовали его как самый ценный источник данных для доработки архитектуры.
Итогом этой борьбы стал не просто работающий пул, а система с аптаймом 99.9%+, которая без простоев переживала релизы и миграции благодаря hot-reload конфигураций и канареечным деплоям.
Что в итоге? И при чём здесь следующий пост
В результате мы получили не «ещё один пул», а высоконагруженную платформу уровня дата-центра — RedRock Pool. Платформу, которая превратила хаотичные подключения десятков тысяч устройств в управляемый поток данных и выплат.
Но самая интересная часть — это даже не бекенд с его террабайтами логики. Самое сложное началось, когда мы спроектировали сквозной поток данных и, что важнее, — систему выплат. Именно здесь кроется 80% всех подводных камней таких проектов.
В следующей статье я детально разберу:
Как мы реализовывали финансовое ядро на FPPS, чтобы выплаты были не просто быстрыми, но и абсолютно прозрачными и предсказуемыми.
Как построили два интерфейса: кабинет майнера с дашбордами хешрейта и историей выплат, и мощную операторскую панель с картой подключений и алертами.
Нашу дорожную карту: Stratum V2, Merged Mining, автопрофили для ASIC — и что из этого мы уже внедрили.
Резюмирую для коллег: Не бойтесь сложных проектов. Бойтесь подходить к ним без чётких SLO и продуманной архитектуры. История с RedRock Pool лишний раз доказала: правильная архитектура, заложенная на старте, позволяет не просто «выжить» под нагрузкой в 2 EH/s, а масштабироваться дальше — предсказуемо и без боли. Иногда «провал» на стадии тестирования — это не повод для паники, а лучший инвестиционный вклад в успех. Потому что он показывает вам слабые места до того, как они покажут себя вашим клиентам.
А вы сталкивались с проектами, где «перебдеть» оказалось гораздо выгоднее, чем «недобдеть»? Какие архитектурные решения спасли вам проект на грани провала? Пишите в комментах, обсудим как коллеги.
С уважением к вашему времени и коду,
Олег Акулов, основатель Nomium.