В начале этого года мы приняли решение, которое некоторые знакомые операторы посчитали либо смелым, либо глупым: мы опубликовали полный реестр нод в открытом Google Sheets с локацией на уровне страны, классом железа, протоколом, ролью и 30-дневным uptime по каждой ноде. На момент публикации в документе 85 нод в 11 странах, и он обновляется каждые шесть часов из того же внутреннего source of truth, что использует наша SRE-ротация.
Этот пост объясняет, что именно мы публикуем, что мы намеренно не публикуем и почему считаем, что компромисс играет в пользу прозрачности, и для нас, и для тех, кто платит нам за инфраструктуру.
Статус-кво в операциях нод
Если вы когда-либо оценивали оператора нод со стороны протокола или делегатора, вы наверняка проходили один и тот же танец. Вы спрашиваете спецификации железа и получаете маркетинговый PDF с фразами «инфраструктура enterprise-уровня» и «географически распределённая». Спрашиваете uptime, получаете один процент без методологии. Спрашиваете, где физически живут ноды, и разговор либо заканчивается, либо переключается на «готовы обсудить под NDA».
Часть этой непрозрачности оправдана: расположение конкретных машин и их хостнеймы - действительно чувствительная информация. Но большая часть - нет. Агрегированный футпринт оператора (сколько нод, в скольких странах, на каком общем уровне железа) - это та информация, которая нужна покупателю для информированного решения и которой операторы регулярно отказываются делиться. Результат: рынок, где побеждает самый громкий маркетинг, а маленькие, но лучше построенные операторы оказываются в структурно проигрышной позиции.
Мы рано решили, что не хотим конкурировать на маркетинге. У нас нет бюджета на это, и, честно, нет темперамента. Что у нас есть - это флот, который хорошо перформит, и внутренняя модель данных, которая уже трекает каждый операционно важный факт по каждой ноде. Поэтому мы её опубликовали.
Что есть в публичной таблице
Сейчас в таблице такие колонки:
- Node ID. Внутренний идентификатор. Не хостнейм, не IP. Просто непрозрачная строка, которая позволяет ссылаться на конкретную ноду в разговорах, ничего не утекая.
- Страна. Код ISO 3166-1 alpha-2. Не город, не фасилити, только страна.
- Класс провайдера. «Colo-A», «Colo-B», «Bare-metal-A» и так далее. Буквы скрывают, какой конкретный провайдер держит какую ноду, но клиент видит, что половина флота не сидит у одного вендора.
- Класс железа. «Validator-S» (маленькая, низкоспеком, под L1-валидаторов, которым не нужен высокий I/O), «Archival-L» (большая, NVMe-тяжёлая), «Inference-G1» (одна GPU), «Inference-G4» (четыре GPU) и так далее.
- Протокол и роль: «Ethereum / validator», «Filecoin / storage», «Aleo / prover».
- 30-дневный uptime. Процент, обновляется каждые шесть часов из нашего внутреннего мониторинга.
- Дата ввода в эксплуатацию. День, когда нода ушла в продакшен.
Этого хватает серьёзному покупателю для оценки и почти ничего - для атакующего. Страна даёт уверенность в географии; класс провайдера - в отсутствии single-vendor-экспозиции; класс железа - в производительности; uptime - в операциях. Ни одна строка не указывает на конкретную физическую машину.
Что мы намеренно не публикуем
Список того, чего в таблице нет, не менее продуман, чем список того, что есть. Мы не публикуем:
- Хостнеймы и IP-адреса. Самая частая причина атак на операторов нод: кто-то скоррелировал паттерн хостнеймов между анонсами клиента и маркетинговыми страницами оператора.
- Конкретные города или фасилити. Уровня страны хватает для compliance и заявлений про географию. Знание, что нода X в Франкфурте, стойка B12, не помогает никому, кто не планирует туда ехать.
- Привязку клиентов. Мы не публикуем, какой клиент работает на какой ноде. Несколько наших клиентов - это протоколы, чьи делегаторы не знают, кто их инфраструктура. Это решение клиента, а не наше.
- Real-time алерты. Колонка uptime - это rolling 30-дневное среднее, а не live-статусборд. Мы не хотим делать инцидент-респонс наблюдаемым в реальном времени, потому что это превращает каждый операционный сбой в репутационное событие.
- Вендора железа или конкретный SKU. «Validator-S» достаточно. Точная модель CPU и материнка не важны для оценки и зато прекрасно подойдут тому, кто планирует supply-chain атаку.
Принцип простой: публиковать то, что разумный покупатель захочет знать для оценки, и придерживать то, что создаёт явный attack surface без сопоставимой пользы для оценки.
Что меняется для клиентов
Таблица публична уже около четырёх месяцев. Проявились три паттерна.
Проверь-перед-разговором. Большинство серьёзных лидов приходят на первый звонок, уже посмотрев таблицу. Разговор начинается с «вижу, у вас 14 нод в Германии у двух коло-провайдеров, расскажите, как вы управляете per-provider failure domain», а не с «расскажите про инфраструктуру». Это сокращает цикл продажи для протокол-клиентов с примерно шести недель до примерно двух.
Capacity planning. Несколько клиентов используют таблицу для собственного capacity-планирования. Если они видят, что у нас уже есть inference-железо в Сингапуре и Сан-Паулу, им не надо просить нас «расшириться в LATAM», - они видят футпринт и размещают нагрузки соответственно. Это сдвигает разговор от «построй мне ёмкость» к «используй то, что есть, вот что мне нужно сверху».
Честные сравнения. Один фонд протокола, с которым мы работаем, недавно проводил сравнение шести операторов под запуск нового мейннета. Четыре из шести отказались делиться агрегированными данными по флоту даже под NDA. Двое (мы и ещё один) предоставили детальный реестр. Протокол выбрал оператора с лучшим uptime в нужных им регионах, и это оказались не мы под тот конкретный деплой. Мы тот тендер не выиграли. Но получили три follow-up разговора от фондов, которые наблюдали процесс и пришли к выводу, что прозрачность - это сигнал операционной зрелости.
Третий паттерн - самый важный. Аргумент за публикацию реестра не в том, что это выиграет каждый тендер: иногда данные покажут, что кто-то другой подходит лучше, и это нормально. Аргумент в том, что это фильтрует покупателей, которым нужно, чтобы им продали, оставляя тех, кто действительно хочет оценивать работу.
Что бы мы сделали иначе, если начинать заново
Две вещи.
Первая: собрали бы таблицу из структурированного бэкенда раньше. Сейчас пайплайн читает из внутренней inventory-базы, применяет правила редакции в одном Python-джобе и пишет в Google Sheet через API. Это нормально, но первые три месяца мы вели публичную таблицу руками, и это привело к нескольким неловким drift-багам, когда публичный uptime не сходился с тем, что показывали внутренние дашборды. Если делаете это - автоматизируйте с первого дня.
Вторая: опубликовали бы явную threat model рядом с таблицей. Мы предполагали, что обоснование самоочевидно, и оно по большей части таким и было, но несколько разговоров с security-командами клиентов прошли бы быстрее, если бы у нас была one-pager, явно перечисляющая «мы публикуем X, потому что Y; мы редактируем Z, потому что W». Этот документ существует внутри сейчас, и мы, скорее всего, опубликуем его позже в 2026-м.
Стоит ли вам делать то же самое?
Если вы оператор нод - скорее всего да, с двумя оговорками.
Первая оговорка: вы должны быть реально уверены в своих цифрах. Публиковать uptime-данные, которые потом окажутся оптимистичными, гораздо хуже, чем не публиковать ничего. Если в методологии мониторинга есть оговорки, задокументируйте их в таблице.
Вторая оговорка: вам нужна стабильная внутренняя inventory-модель. Таблица, которую обновляют руками, рано или поздно дрифтнет, а репутационная цена попадания со stale-данными высока. Сначала пайплайн, потом публикация.
Таблица слинкована из футера на каждой странице сайта. Обновляется каждые шесть часов, и мы рады пройтись по любой строке, если есть вопросы.
Команда XIMTRX