автор команда XIMTRX

Добро пожаловать в XIMTRX

Зачем мы построили XIMTRX, как мы выросли до 85 нод в 11 странах и что мы будем публиковать здесь.

#depin #infrastructure #operations

Это первый пост в блоге XIMTRX, поэтому стоит честно объяснить, зачем существует этот сайт, кто мы и что планируем тут публиковать. Если вы пришли с лидерборда валидаторов, из анонса DePIN-протокола или по реферралу от другого оператора, добро пожаловать. Если попали сюда случайно, короткая версия: мы держим 85 нод в 11 странах для DePIN-сетей и публикуем то, что узнаём, эксплуатируя этот флот.

Откуда это всё взялось

XIMTRX не начинался как бизнес по операциям нод. В 2022-м это был сайд-проект на два Ethereum-валидатора на одном Hetzner-сервере, больше для того, чтобы понять, как стейкинговая экономика выглядит со стороны оператора, а не протокола. За полгода проект вырос до семнадцати нод в четырёх протоколах, и времени на него стало уходить больше, чем на основную работу.

Решение формализовать всё пришло, когда знакомый, запускавший небольшой тестнет, попросил забрать его инсентивированную аллокацию, облачный счёт начал выходить из-под контроля. Мы за две недели перевезли его нагрузку с одного us-east-1 региона на четыре стойки в коло-датацентрах во Франкфурте, Сингапуре, Сан-Паулу и Таллине. Месячные расходы на инфраструктуру упали на 61 процент, медианная p99-задержка аттестаций улучшилась с 1.4с до 380мс, и его перестали будить в 3 ночи из-за падений availability zone. Эта миграция и убедила нас, что это реальный бизнес.

К концу 2024-го мы держали 48 нод в девяти протоколах. Сейчас, в мае 2025-го, у нас 85 продакшен-нод в 11 странах с 30-дневным rolling uptime 99.94 процента. Команда осталась маленькой: пять инженеров, ни отдела продаж, ни маркетингового бюджета. Флот вырос, потому что базовый playbook масштабируется.

Чем мы занимаемся на самом деле

В DePIN-индустрии проблема со словарём. «Оператор нод» может означать что угодно от человека с одним Solana-RPC на Vultr до венчурно-финансированной конторы с $50M TVL под кастоди. Если говорить конкретно, XIMTRX обслуживает четыре класса нагрузок:

  • Валидаторы. Участники консенсуса L1 и L2 в Ethereum, Solana, Cosmos-сетях, Avalanche, NEAR и нескольких менее крупных сетях. Мы не храним клиентские ключи, операторы подписывают локально, мы держим инфраструктуру.
  • Архивные и RPC-ноды. Полное историческое состояние для сетей, где pruned-данных недостаточно. Сюда уходит большая часть нашей storage-ёмкости: около 240 ТБ NVMe и 760 ТБ HDD на флоте сейчас.
  • GPU inference-ноды. Bare-metal NVIDIA-железо (в основном L40S и A100 80GB) под inference для децентрализованных AI-протоколов. Ниже по объёму, но самая высокая выручка на ноду.
  • Операции в тестнетах. Инсентивированные тестнеты для протоколов, готовящихся к мейннету. Здесь живут самые интересные сценарии отказов.

Мы не владеем физическим железом. Флот распределён между восемью коло-провайдерами и тремя bare-metal-вендорами, выбирали по географии, сетевому пирингу и отсутствию single point of failure. Слой оркестрации наш: Kubernetes для stateless-нагрузок, обычные systemd-юниты для валидаторов (потому что systemd мы доверяем больше, чем себе самим, не накосячить в манифесте пода для slashing-чувствительной нагрузки).

Зачем мы ведём этот блог

Причин две.

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

Вторая причина - отраслевая. Сообщество операторов DePIN маленькое, и оно плохо обслуживается существующим инженерным контентом в интернете. Есть отличные материалы про Web2 SRE, много маркетинга от staking-as-a-service контор, и почти ничего между ними. Мы хотим публиковать технически-честное письмо, которого нам не хватало, когда мы начинали: что реально ломается в железе, какие slashing-инциденты мы видели, какие запросы в мониторинге ловят проблемы до того, как они ловят нас, как выглядит экономика небольшого флота и куда движется индустрия.

Что здесь будет

Неполный список из редакционного бэклога:

  • Прозрачность флота: почему мы публично публикуем реестр всех 85 нод (следующий пост).
  • Три slashing-постмортема, ни один не наш клиент, но все проанализированы детально.
  • Почему мы против single-validator-сетапов на consumer-железе, даже когда протокол говорит «ок».
  • Экономика хранилища для архивных нод: когда NVMe окупается, а когда нет.
  • Миграция с облака на коло без даунтайма: разбор кейса Cosmos-валидатора, которого мы онбордили этой весной.
  • Эксплуатация GPU inference-нод: бюджет питания, отказы охлаждения и разница между «Linux на GPU» и «продакшен GPU-инфраструктура».

Посты будут выходить примерно еженедельно. Подписки на рассылку нет, потому что мы не катаем трекеры и не хотим быть в email-бизнесе. Либо забукмаркьте страницу, либо подпишитесь через RSS, когда мы его выкатим, либо следите за каналами в футере.

Про тон

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

Если вы сами оператор и не согласны с чем-то из опубликованного, пишите. Контакты в футере.

Ещё раз добро пожаловать. Следующий пост объясняет, почему наш полный реестр нод опубликован в открытом Google Sheets и что это меняет в том, как клиенты оценивают нас.

Команда XIMTRX

← Все статьи