Внешняя тестовая лаборатория и Community DevNet
Оригинал: External Test Lab & Community DevNet
Привет! Спасибо за предложение. Пара мыслей:
Qwen/Qwen3-4B-Instruct-2507, Qwen/Qwen2.5-7B-Instruct,
Я бы, вероятно, выбрал https://huggingface.co/Qwen/Qwen3-0.6B на ранней стадии. Для тестовой сети с небольшими моделями не имеет значения, какая модель — 0,6B или 7B. Поэтому, когда это тестовая сеть с небольшими моделями, любая модель/графический процессор должна подойти. Я бы посоветовал использовать самые дешевые графические процессоры.
Узлы вывода: компьютеры NVIDIA с графическим процессором и 24 ГБ видеопамяти, совместимые со стеком контейнеров/среды выполнения проекта CUDA 13.0.
Судя по предыдущему комментарию, требования могут быть снижены. Лучше использовать больше маленьких графических процессоров, чем несколько больших, для имитации основной сети.
Целевой размер: 9–11 постоянно работающих машин вывода.
Я бы включил сетевые узлы с несколькими MLNodes.
Учебники и извлеченные уроки задокументированы к концу пилотного проекта
Я бы сказал, что команде тестирования также придется поиграть с такими примитивами, как настройка порога проверки PoC и порога проверки вывода. Было бы полезно внести непосредственный вклад в документацию.
Увеличенный бюджет на тестирование графического процессора
Кто будет иметь доступ к этим ресурсам? Только команда тестирования? Я бы уточнил, как используются полноразмерные серверы.
Публичная панель мониторинга состояния DevNet и состояния узлов.
Я думаю, потребуются какие-то соглашения с нынешними сопровождающими приборной панели? Или какие информационные панели будут использоваться?
Будет ли такая тестовая сеть общедоступной? например может ли какой-нибудь хост поэкспериментировать с присоединением к тестовой сети перед присоединением к основной сети?
Смогут ли пользователи, не входящие в команду контроля качества, экспериментировать с логическими выводами, смарт-контрактами и т. д.?
С моей точки зрения, идея в целом хороша и должна быть весьма полезной. Я бы попытался уточнить публичный доступ (думаю, лучше сделать его полностью закрытым)
Спасибо, Глеб, это очень полезные моменты.
Согласен, начнем с Qwen3-0.6B или аналогичной модели и соответственно снизим требования к графическому процессору. Поскольку целью DevNet является моделирование распределенного поведения, а не пропускной способности, я бы предпочел использовать экономию средств для запуска большего количества узлов меньшего размера. Я также снизил ограничение на инфраструктуру DevNet.
Хороший момент и в отношении сетевых узлов с несколькими MLNodes. Уточню предполагаемую топологию.
По порогам и документации: тоже согласен. Группа тестирования должна не только проверять выпуски, но и документировать практические рабочие примитивы, такие как порог проверки PoC, порог проверки вывода и извлеченные уроки. Это должно стать частью общедоступных руководств, и там, где это имеет смысл, мы внесем эти результаты непосредственно в официальную документацию Gonka.
Что касается пакетных ресурсов графического процессора, я уточню доступ и использование. В настоящее время я считаю, что доступ должен координироваться группой тестирования/владельцами проекта во время пилотного проекта, в основном для кандидатов на выпуск и модельных тестов, с публичным сообщением об использовании и затратах.
Что касается информационных панелей, я об этом не подумал, но это интересный момент, который может сэкономить время и средства. Мы свяжемся с нынешними сопровождающими информационной панели, чтобы узнать, смогут ли они помочь. Если нет, мы будем использовать специальную панель мониторинга в стиле Grafana для проверки работоспособности DevNet и состояния узлов, как и планировалось.
Что касается публичного доступа: да, репетиция адаптации хоста перед основной сетью — это один из предполагаемых вариантов использования DevNet, а пользователи, не имеющие опыта обеспечения качества, экспериментирующие с логическими выводами и смарт-контрактами, — это то направление, которое нам нужно. В ходе пилотного проекта я бы реализовал это через упрощенный процесс запроса, в основном для управления злоупотреблениями, доступом и стабильностью узла, в то время как документы по мониторингу и адаптации все еще находятся в разработке. Целевым состоянием является более широкое участие, и я хочу перейти к полностью несанкционированному доступу, как только это позволят безопасность, ограничения на злоупотребления, документация по адаптации и мониторинг. Я просто пока не хочу обещать конкретную дату пилотного проекта.
Я обновил предложение, чтобы отразить эти моменты.
Конечно, нам следует использовать настройку с несколькими узлами, некоторые сетевые узлы будут находиться на серверах только с ЦП, некоторые - полные узлы.
Я считаю, что:
- Эта сеть разработки должна быть общедоступной с самого начала. Чтобы каждый мог подключить свой узел, никого не спрашивая. Это делает условия более реалистичными, и более того, нам это ничего не стоит.
Эта сеть разработки должна быть общедоступной с самого начала. Чтобы каждый мог подключить свой узел, никого не спрашивая. Это делает условия более реалистичными, и более того, нам это ничего не стоит.
- Ресурсы Burst GPU могут быть выделены разработчикам из основной команды, а также командам, у которых уже есть вознаграждение за коммиты протокола — в первую очередь, сопровождающим https://registry.kaitaku.ai/ (хотя, конечно, здесь мы ограничены бюджетом).
Ресурсы Burst GPU могут быть выделены разработчикам из основной команды, а также командам, у которых уже есть вознаграждение за коммиты протокола — в первую очередь, сопровождающим https://registry.kaitaku.ai/ (хотя, конечно, здесь мы ограничены бюджетом).
- Что касается дашбордов — трекер мы точно сможем поставить сами, благо его код открыт. В идеале нам следует привлечь разработчиков популярных трекеров и обозревателей блоков, чтобы они сами запускали дев-версии. Я думаю, им самим это будет интересно.
Что касается дашбордов — трекер мы точно сможем поставить сами, благо его код открыт. В идеале нам следует привлечь разработчиков популярных трекеров и обозревателей блоков, чтобы они сами запускали дев-версии. Я думаю, им самим это будет интересно.
Ах да, если мы имеем в виду хосты, подключающие свои машины к DevNet, то это, безусловно, следует приветствовать с самого начала. Я больше думал о контролируемом доступе к ресурсам, управляемым проектом, где возникают риски затрат, злоупотреблений или стабильности.
Контракт условного депонирования находится в цепочке
Идентификатор кода: 107, контрольная сумма 94b141625b7641e6ad57266420b18a4af72eac49b8110cb92719755590b463bd
Адрес условного депонирования: gonka1g57f45qjvn0529vpgj8x8mzt8r5k4audchm3pp9pezywxwf4rexqlj8ayw
- Источник: https://github.com/paranjko/testlab-devnet-escrow/tree/1b2e529876141816b5c2130840d04fb93694bf72.
В контракте содержится 88 000 долларов США + 80 000 GNK, и они выплачиваются по фиксированному графику, предусмотренному этим предложением. Никакого администрирования, никакой миграции: получатели и суммы никогда не изменятся. У руководства есть один рычаг: единовременный возврат средств, который возвращает все оставшиеся средства в пул сообщества, доступный в любой момент; каждый транш разблокируется с помощью 4-дневного буфера, поэтому 2-дневное голосование всегда подходит перед следующей выплатой.
Проверьте (требуется докер):
git clone https://github.com/paranjko/testlab-devnet-escrow && cd testlab-devnet-escrow ./build.sh && sha256sum артефакты/milestone_escrow.wasm # должно соответствовать: выведенный запрос wasm code-info 107
Предложение № 82 — Внешняя тестовая лаборатория и сообщество DevNet принято. (https://gonka.vote/governance/82)
Сейчас мы начинаем первый месяц: организуем аренду оборудования, подключаем к сети первоначальные узлы и начинаем процесс поиска и найма команды контроля качества. Мы будем использовать эту тему, чтобы делиться прогрессом.
Спасибо всем, кто рассмотрел предложение и проголосовал.
Первый отчет будет опубликован примерно 9 августа, за четыре дня до следующей разблокировки.
Как и было обещано, вот отчет за первый месяц для внешней тестовой лаборатории и сообщества DevNet (https://github.com/paranjko/external-test-lab/blob/main/reports/monthly/2026-08-month-1.md).
Все вспомогательные материалы и артефакты уже опубликованы в репозитории Test Lab (https://github.com/paranjko/external-test-lab/), который на данный момент останется основным источником обновлений проекта.
Привет, я живу в Дубае и буду рад поддержать проект на местном уровне, если местоположение в ОАЭ или странах Ближнего Востока и Северной Африки станет полезным для будущего тестирования или развертывания инфраструктуры.
Ранее я также работал над проектом CoolTank — концепцией двухфазного погружного охлаждения, первоначально разработанной для майнинга криптовалют и работы в жарких условиях. Тот же базовый подход потенциально может быть адаптирован к инфраструктуре серверов графических процессоров с высокой плотностью при условии проведения надлежащей инженерной проверки и проверок совместимости оборудования.
Вероятно, это не актуально для легких узлов Community DevNet, но, возможно, стоит обсудить это для будущих развертываний хостов Gonka с высокой плотностью или инфраструктуры класса H200/B200 в регионе MENA.
Обзор проекта: https://www.thecooltank.com/ (https://www.thecooltank.com/?utm_source=chatgpt.com)
Буду рад обсудить, имеет ли это отношение к дорожной карте проекта.
Внешняя тестовая лаборатория и сообщество DevNet
4-месячное пилотное предложение по созданию общественной инфраструктуры тестирования и потенциала обеспечения качества
1. Резюме
В этом предложении требуется финансирование четырехмесячного пилотного проекта внешней тестовой лаборатории и сообщества DevNet: принадлежащей сообществу функции тестирования обновлений протокола Gonka, DevShards, потоков вывода, операций хоста/брокера и поведения географически распределенной сети перед принятием решений по управлению и развертыванием производства.
2. Постановка задачи
Сегодня в Gonka отсутствует выделенный уровень проверки, принадлежащий сообществу, для важных изменений в сети. Внешняя лаборатория тестирования и Community DevNet призваны устранить этот пробел, предоставив возможности практического тестирования, общую инфраструктуру и общедоступные доказательства перед выпуском, принятием управленческих решений или развертыванием производства.
Внешняя лаборатория тестирования и сообщество DevNet будут:
- Проверяйте обновления протоколов, выпуски DevShard, потоки брокера/вывода, интеграцию и другие важные сетевые изменения, прежде чем они будут реализованы.
Проверяйте обновления протоколов, выпуски DevShard, потоки брокера/вывода, интеграцию и другие важные сетевые изменения, прежде чем они будут реализованы.
- Тестируйте поведение распределенной сети, которое трудно проверить в локальной или внутренней среде, включая задержку, синхронизацию, распространение и региональную нестабильность.
Тестируйте поведение распределенной сети, которое трудно проверить в локальной или внутренней среде, включая задержку, синхронизацию, распространение и региональную нестабильность.
- Используйте доступные возможности тестирования для превентивного поиска ошибок, регрессионных проверок и исследования известных слабых мест, когда ни один кандидат на выпуск не ожидает проверки.
Используйте доступные возможности тестирования для превентивного поиска ошибок, регрессионных проверок и исследования известных слабых мест, когда ни один кандидат на выпуск не ожидает проверки.
- Обеспечьте нейтральный путь тестирования для работы, выполняемой внешними командами и участниками экосистемы, прежде чем она будет принята, профинансирована или использована в производстве.
Обеспечьте нейтральный путь тестирования для работы, выполняемой внешними командами и участниками экосистемы, прежде чем она будет принята, профинансирована или использована в производстве.
- Помогите проверить отчеты об уязвимостях от исследователей, аудитов или программ, таких как HackerOne, посредством воспроизведения, оценки воздействия, регрессионного тестирования и подтверждения после исправления.
Помогите проверить отчеты об уязвимостях от исследователей, аудитов или программ, таких как HackerOne, посредством воспроизведения, оценки воздействия, регрессионного тестирования и подтверждения после исправления.
- Обеспечьте общую среду, в которой доверенные хосты и команды смогут безопасно тестировать предложения, интеграции, сценарии DevShard, поведение протоколов и идеи ранней реализации.
Обеспечьте общую среду, в которой доверенные хосты и команды смогут безопасно тестировать предложения, интеграции, сценарии DevShard, поведение протоколов и идеи ранней реализации.
- Предоставляйте более четкие доказательства тестирования для участников управления, включая планы тестирования, информационные панели, модули Runbook, средства отслеживания проблем, отчеты о дефектах, обработку конфиденциальной информации и сводки о готовности к выпуску.
Предоставляйте более четкие доказательства тестирования для участников управления, включая планы тестирования, информационные панели, модули Runbook, средства отслеживания проблем, отчеты о дефектах, обработку конфиденциальной информации и сводки о готовности к выпуску.
Это добавляет недостающий уровень проверки для экосистемы Gonka и дополняет тестирование Core Team.
3. Согласование дорожной карты
Данное предложение напрямую реализует два проекта из Дорожной карты развития сети Gonka (https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md).
Трек 4. Надежность и наблюдаемость сети — Проект 2. Лаборатория внешнего тестирования Дорожная карта определяет внешнюю лабораторию тестирования для изменений Gonka перед широким развертыванием, включая изменения от специалистов по сопровождению протоколов, финансируемых внешних команд и участников экосистемы.
В этом предложении этот проект реализуется через группу внешнего тестирования, планы тестирования, дымовые и регрессионные проверки, отчеты о дефектах, общедоступное отслеживание проблем и отчеты о готовности к выпуску.
Трек 7. Публичная песочница и тестовая сеть потребительского графического процессора — Проект 1. Песочница для публичного тестирования. Дорожная карта определяет отдельную тестовую среду для экспериментов с моделями, параметрами, интеграциями, сценариями DevShard, поведением на уровне протокола, проверкой, расчетом и тестированием обновлений перед основной сетью.
Данное предложение реализует этот проект через Community DevNet: небольшую, постоянно работающую, географически распределенную сеть для тестирования протоколов, узлов, DevShard, эксплуатации, интеграции и распределенного тестирования поведения.
4. Что мы строим
Проект состоит из трех взаимосвязанных компонентов.
5. Инфраструктура DevNet сообщества
- Целевой размер: 9–13 постоянно работающих машин вывода плюс необходимые сетевые узлы, где это возможно, в пределах ежемесячного ограничения инфраструктуры DevNet.
Целевой размер: 9–13 постоянно работающих машин вывода плюс необходимые сетевые узлы, где это возможно, в пределах ежемесячного ограничения инфраструктуры DevNet.
- Топология: часть DevNet работает как сетевые узлы с несколькими подключенными узлами MLNodes, что позволяет воспроизводить и тестировать реалистичные конфигурации хостов с несколькими узлами MLNode.
Топология: часть DevNet работает как сетевые узлы с несколькими подключенными узлами MLNodes, что позволяет воспроизводить и тестировать реалистичные конфигурации хостов с несколькими узлами MLNode.
- Ориентировочное распространение: Восточная Северная Америка, Западная Северная Америка, Великобритания, Германия, Франция, Финляндия и страны Азии в зависимости от качества сети и доступности хостинга.
Ориентировочное распространение: Восточная Северная Америка, Западная Северная Америка, Великобритания, Германия, Франция, Финляндия и страны Азии в зависимости от качества сети и доступности хостинга.
- Профиль модели: ожидается, что узлы вывода DevNet будут запускать облегченные модели инструкций, такие как Qwen/Qwen3-0.6B (https://huggingface.co/Qwen/Qwen3-0.6B) или эквивалентные модели.
Профиль модели: ожидается, что узлы вывода DevNet будут запускать облегченные модели инструкций, такие как Qwen/Qwen3-0.6B (https://huggingface.co/Qwen/Qwen3-0.6B) или эквивалентные модели.
- Узлы вывода: компьютеры NVIDIA с графическим процессором и 16 ГБ видеопамяти, совместимые со стеком контейнеров/среды выполнения проекта CUDA 13.0.
Узлы вывода: компьютеры NVIDIA с графическим процессором и 16 ГБ видеопамяти, совместимые со стеком контейнеров/среды выполнения проекта CUDA 13.0.
- Цель: тестирование протокола и распределенного поведения.
Цель: тестирование протокола и распределенного поведения.
- Мониторинг: общедоступная панель мониторинга доступности узлов.
Мониторинг: общедоступная панель мониторинга доступности узлов.
- Операции: руководитель инфраструктуры от хост-сообщества/DevOps, отвечающий за предоставление, мониторинг и обслуживание.
Операции: руководитель инфраструктуры от хост-сообщества/DevOps, отвечающий за предоставление, мониторинг и обслуживание.
Публичный доступ. DevNet предназначен для обслуживания более широкого сообщества, а не только группы тестирования. В ходе пилотного проекта доступ внешним участникам предоставляется через упрощенный процесс запроса — в первую очередь для управления злоупотреблениями, контроля доступа и стабильности узла, в то время как мониторинг и документация по адаптации все еще разрабатываются. Предполагаемые варианты внешнего использования включают в себя:
- хосты репетируют подключение и работу узлов перед присоединением к основной сети;
хосты репетируют подключение и работу узлов перед присоединением к основной сети;
- разработчики и пользователи экспериментируют с логическими выводами, смарт-контрактами и интеграциями за пределами плана тестирования команды контроля качества.
разработчики и пользователи экспериментируют с логическими выводами, смарт-контрактами и интеграциями за пределами плана тестирования команды контроля качества.
Целевым состоянием является более широкое участие: мы намерены перейти к полностью несанкционированному доступу, как только это позволят безопасность, ограничения на злоупотребления, документация по адаптации и мониторинг.
6. Увеличенный бюджет на тестирование графического процессора
- Используется только при необходимости для кандидатов на выпуск, тестов больших моделей, нагрузочных тестов и проверок совместимости моделей.
Используется только при необходимости для кандидатов на выпуск, тестов больших моделей, нагрузочных тестов и проверок совместимости моделей.
- Предполагаемое планирование: До одной календарной недели (168 часов) аренды в месяц.
Предполагаемое планирование: До одной календарной недели (168 часов) аренды в месяц.
- Для тестирования класса Kimi оценка требований предполагает узел ML с 4 NVIDIA B200 или 8 NVIDIA H200, общим объемом около 640 ГБ видеопамяти графического процессора, более 960 ГБ системной памяти, 16-ядерным процессором amd64 и хостом сетевого узла с 16-ядерным процессором, 64 ГБ+ ОЗУ, 1 ТБ NVMe и сетью со скоростью не менее 100 Мбит/с.
Для тестирования класса Kimi оценка требований предполагает узел ML с 4 NVIDIA B200 или 8 NVIDIA H200, общим объемом около 640 ГБ видеопамяти графического процессора, более 960 ГБ системной памяти, 16-ядерным процессором amd64 и хостом сетевого узла с 16-ядерным процессором, 64 ГБ+ ОЗУ, 1 ТБ NVMe и сетью со скоростью не менее 100 Мбит/с.
Доступ и подотчетность. Пакетная мощность графического процессора предоставляется и координируется группой внешнего тестирования совместно с владельцами проекта, в первую очередь для проверки кандидатов на выпуск, совместимости моделей и нагрузочных тестов. Запросы от специалистов по сопровождению протоколов и команд экосистемы удовлетворяются там, где позволяют возможности. Все пакетное использование подробно описано в ежемесячном общедоступном отчете: цель, затраченное время и стоимость выполнения теста, а также журналы тестирования, публикуемые вместе с ним.
7. Команда внешнего тестирования
В рамках предложения финансируются два внешних инженера по обеспечению качества и тестированию инфраструктуры.
Объем работ
- Вносить вклад в стандарты качества и тестировать стратегию сети.
Вносить вклад в стандарты качества и тестировать стратегию сети.
- Определить критерии приемки и планы тестирования для событий и компонентов жизненного цикла базовой сети.
Определить критерии приемки и планы тестирования для событий и компонентов жизненного цикла базовой сети.
- Создавайте системы проверки перед выпуском, включая дымовые проверки и регрессионное покрытие для известных шаблонов сбоев.
Создавайте системы проверки перед выпуском, включая дымовые проверки и регрессионное покрытие для известных шаблонов сбоев.
- Развертывание и проверка распределенных стеков узлов и сервисов в средах, аналогичных производственных.
Развертывание и проверка распределенных стеков узлов и сервисов в средах, аналогичных производственных.
- Комплексная проверка критически важных межсистемных потоков с использованием документированных доказательств и четкой эскалации дефектов — например, потоки участников и ключей, логический вывод и участие в доказательстве вычислений, поведение шлюза и прокси
Комплексная проверка критически важных межсистемных потоков с использованием документированных доказательств и четкой эскалации дефектов — например, потоки участников и ключей, логический вывод и участие в доказательстве вычислений, поведение шлюза и прокси
- Используйте сигналы работоспособности, цепочки запросов и журналы в качестве основных входных данных для проверки, а не только в качестве средств отладки.
Используйте сигналы работоспособности, цепочки запросов и журналы в качестве основных входных данных для проверки, а не только в качестве средств отладки.
- Проверка готовности обновления, возможности отката и работоспособности стека после изменений.
Проверка готовности обновления, возможности отката и работоспособности стека после изменений.
- Установите, настройте и задокументируйте практические рабочие примитивы, такие как пороговые значения проверки PoC и настройки пороговых значений проверки вывода, на основе опыта DevNet, и при необходимости внесите эти выводы непосредственно в официальную документацию Gonka.
Установите, настройте и задокументируйте практические рабочие примитивы, такие как пороговые значения проверки PoC и настройки пороговых значений проверки вывода, на основе опыта DevNet, и при необходимости внесите эти выводы непосредственно в официальную документацию Gonka.
- Поддержка проверки DevNet и оценки готовности к выпуску перед развертыванием производства.
Поддержка проверки DevNet и оценки готовности к выпуску перед развертыванием производства.
- Проверка восстановления и разрешения инцидентов посредством анализа первопричин и повторного тестирования.
Проверка восстановления и разрешения инцидентов посредством анализа первопричин и повторного тестирования.
- Сообщайте о дефектах с четкими этапами воспроизведения, оценкой воздействия и статусом блокировки выпуска.
Сообщайте о дефектах с четкими этапами воспроизведения, оценкой воздействия и статусом блокировки выпуска.
- Отслеживайте и передавайте показатели качества, отражающие работоспособность сети и эксплуатационную надежность.
Отслеживайте и передавайте показатели качества, отражающие работоспособность сети и эксплуатационную надежность.
Требуемые возможности
- 3+ года работы в сфере обеспечения качества систем/тестирования, SDET или DevOps/SRE, ориентированных на качество.
3+ года работы в сфере обеспечения качества систем/тестирования, SDET или DevOps/SRE, ориентированных на качество.
- Понимание жизненного цикла блокчейна, потоков ключей и аутентификации: регистрация, делегированные разрешения, предоставление комиссий.
Понимание жизненного цикла блокчейна, потоков ключей и аутентификации: регистрация, делегированные разрешения, предоставление комиссий.
- Опыт эксплуатации и проверки узлов блокчейна (предпочтительно Cosmos SDK): синхронизация, восстановление, RPC-запросы, фазовое поведение сети.
Опыт эксплуатации и проверки узлов блокчейна (предпочтительно Cosmos SDK): синхронизация, восстановление, RPC-запросы, фазовое поведение сети.
- Опыт проверки распределенных систем в производственных средах.
Опыт проверки распределенных систем в производственных средах.
- Сильный дизайн тестирования: планы тестирования, критерии приемки, дым/регрессия/e2e, крайние случаи, отрицательное тестирование.
Сильный дизайн тестирования: планы тестирования, критерии приемки, дым/регрессия/e2e, крайние случаи, отрицательное тестирование.
Solid Linux, SSH, сценарии оболочки и проверка на основе журналов
Solid Linux, SSH, сценарии оболочки и проверка на основе журналов
- Оркестровка Docker и контейнеров, включая поведение среды и конфигурации при перезагрузке.
Оркестровка Docker и контейнеров, включая поведение среды и конфигурации при перезагрузке.
Четкие отчеты о дефектах и документация — инструкции, результаты тестов, контрольные списки
Четкие отчеты о дефектах и документация — инструкции, результаты тестов, контрольные списки
- Комфорт благодаря ограниченной по времени проверке перед критическими сетевыми событиями.
Комфорт благодаря ограниченной по времени проверке перед критическими сетевыми событиями.
Предпочтительно/приятно иметь
- Опыт SDET: проверка по сценариям, конвейеры CI, автоматизированные проверки работоспособности.
Опыт SDET: проверка по сценариям, конвейеры CI, автоматизированные проверки работоспособности.
- Контроль качества блокчейна/Web3: операции тестовой сети, тестирование моста, потоки кошелька/ключей, регрессия обновления
Контроль качества блокчейна/Web3: операции тестовой сети, тестирование моста, потоки кошелька/ключей, регрессия обновления
Межсетевое тестирование: проверка тестовой сети EVM, потоки вывода средств, взаимодействие с контрактами
Межсетевое тестирование: проверка тестовой сети EVM, потоки вывода средств, взаимодействие с контрактами
Тестирование вывода GPU/ML: работоспособность работников, обслуживание моделей, доставка артефактов
Тестирование вывода GPU/ML: работоспособность работников, обслуживание моделей, доставка артефактов
Опыт скоординированных обновлений нескольких узлов
Опыт скоординированных обновлений нескольких узлов
Тестирование API-шлюза и прокси-сервера (сбои, задержки, отслеживание запросов)
Тестирование API-шлюза и прокси-сервера (сбои, задержки, отслеживание запросов)
Децентрализованный вывод или сети Proof of Compute
Децентрализованный вывод или сети Proof of Compute
8. Владельцы проектов и подотчетность
9. Прозрачность и отчетность
- Публичная панель мониторинга состояния DevNet и состояния узлов.
Публичная панель мониторинга состояния DevNet и состояния узлов.
- Общедоступная доска задач для запланированных, активных и завершенных работ по тестированию.
Общедоступная доска задач для запланированных, активных и завершенных работ по тестированию.
- Общедоступный трекер проблем для неконфиденциальных ошибок, регрессов и операционных результатов.
Общедоступный трекер проблем для неконфиденциальных ошибок, регрессов и операционных результатов.
- Ежемесячный публичный отчет с указанием результатов, инцидентов, расходов по статьям бюджета, оставшегося баланса, неиспользованных средств и плана на следующий месяц.
Ежемесячный публичный отчет с указанием результатов, инцидентов, расходов по статьям бюджета, оставшегося баланса, неиспользованных средств и плана на следующий месяц.
- Отчет о готовности каждого выпуска перед голосованием руководства или развертыванием производства, если кандидат на выпуск предоставляется вовремя.
Отчет о готовности каждого выпуска перед голосованием руководства или развертыванием производства, если кандидат на выпуск предоставляется вовремя.
- О результатах, важных для безопасности, сначала сообщается в частном порядке основной команде; При необходимости создается общедоступная проблема-заполнитель, а подробности раскрываются после исправления или согласованного окна раскрытия.
О результатах, важных для безопасности, сначала сообщается в частном порядке основной команде; При необходимости создается общедоступная проблема-заполнитель, а подробности раскрываются после исправления или согласованного окна раскрытия.
10. Координация сопровождения протокола
- Лаборатория внешнего тестирования предназначена для работы в координации с обслуживающими протоколами, оставаясь при этом функцией внешнего тестирования сообщества.
Лаборатория внешнего тестирования предназначена для работы в координации с обслуживающими протоколами, оставаясь при этом функцией внешнего тестирования сообщества.
- Ожидается, что специалисты по обслуживанию протоколов будут поддерживать первоначальную адаптацию, предоставляя технический контекст, соответствующую документацию, общие рекомендации, сценарии и примечания, ожидаемую направленность тестирования и разъяснения поведения, специфичного для протокола, где это необходимо.
Ожидается, что специалисты по обслуживанию протоколов будут поддерживать первоначальную адаптацию, предоставляя технический контекст, соответствующую документацию, общие рекомендации, сценарии и примечания, ожидаемую направленность тестирования и разъяснения поведения, специфичного для протокола, где это необходимо.
- Такая координация помогает команде тестирования быстрее повысить производительность и снижает риск неправильной интерпретации ожидаемого поведения сети. В то же время отчеты о проверке по-прежнему подготавливаются независимой лабораторией внешнего тестирования и публикуются для сообщества.
Такая координация помогает команде тестирования быстрее повысить производительность и снижает риск неправильной интерпретации ожидаемого поведения сети. В то же время отчеты о проверке по-прежнему подготавливаются независимой лабораторией внешнего тестирования и публикуются для сообщества.
11. Требования к передаче проверки релиза
Если запланировано голосование руководства или развертывание производства и тестируемые артефакты предоставляются вовремя, внешняя лаборатория тестирования публикует отчет о готовности, включающий протестированные области, результаты «пройдено/не пройдено», известные риски и рекомендации.
Если тестируемые артефакты предоставляются с опозданием или не в полном объеме, внешняя лаборатория тестирования все равно может выполнить ограниченную проверку, но в отчете будет четко указано сокращение объема, временные ограничения и известные ограничения.
12. Этапы и критерии приемки
Рабочий поток A: Инфраструктура DevNet
Рабочий поток B: Лаборатория внешнего тестирования
13. КПЭ
14. Бюджетная смета
Это плановая оценка для 4-месячного пилотного проекта. Неиспользованный бюджет аренды графического процессора может быть продлен в рамках пилотного проекта; любые неиспользованные средства по окончании пилотного проекта будут возвращены в пул сообщества.
Любые неиспользованные средства будут возвращены в пул сообщества по окончании пилотного проекта.
* Ограничение выше стоимости необработанных часов графического процессора распространяется на зарезервированные или непрерываемые экземпляры, необходимые для постоянной работы, региональные надбавки к ценам за пределами недорогих рынков США, хосты сетевых узлов только с ЦП для топологии с несколькими MLNode, хранилище и выход, а также временное дублирование узлов во время обновления и тестирования отказоустойчивости. Это ограничение, а не цель расходов: фактические расходы будут детализироваться ежемесячно, а неиспользованные средства будут возвращены в пул сообщества в конце пилотного проекта.
** Компания Nebius (https://nebius.com/prices) указала цену на B200 по требованию в размере 7,15 долларов США за час графического процессора, а цену на H200 по требованию — 4,50 доллара США за час графического процессора (июнь 2026 г.). При таких тарифах по требованию 4 × B200 на 168 часов будут стоить примерно 4,8 тыс. долларов, а 8 × H200 на 168 часов будут стоить примерно 6,05 тыс. долларов.
15. График платежей
16. Признание GNK в конце пилотного проекта
Руководитель проекта и руководитель инфраструктуры не получают ежемесячного вознаграждения из пилотного бюджета: все транши USDT финансируют инфраструктуру, инструменты и внешних инженеров по тестированию. Лидерская работа признается только посредством единовременного выделения ГНК, указанного ниже, которое выплачивается после завершения пилотного проекта и принятия окончательного отчета.
17. Открытый исходный код, право собственности и передача
- Вся неконфиденциальная документация, планы тестирования, модули Runbook, панели мониторинга, шаблоны проблем и отчеты по умолчанию будут общедоступными.
Вся неконфиденциальная документация, планы тестирования, модули Runbook, панели мониторинга, шаблоны проблем и отчеты по умолчанию будут общедоступными.
- Если создается код или скрипты, они будут публиковаться под лицензией с открытым исходным кодом, совместимой с нормами экосистемы Gonka, если только нет явных оснований безопасности не делать этого.
Если создается код или скрипты, они будут публиковаться под лицензией с открытым исходным кодом, совместимой с нормами экосистемы Gonka, если только нет явных оснований безопасности не делать этого.
- Доступ к инфраструктуре не будет зависеть от одного человека. Модель владельца, процесс экстренного доступа и процедура передачи обслуживания будут задокументированы.
Доступ к инфраструктуре не будет зависеть от одного человека. Модель владельца, процесс экстренного доступа и процедура передачи обслуживания будут задокументированы.
- В конце пилотного проекта одобренная сообществом команда должна иметь возможность взять на себя управление DevNet и лабораторией внешнего тестирования, используя опубликованные инструкции по запуску, документацию и процесс передачи доступа.
В конце пилотного проекта одобренная сообществом команда должна иметь возможность взять на себя управление DevNet и лабораторией внешнего тестирования, используя опубликованные инструкции по запуску, документацию и процесс передачи доступа.
Требуемое решение
Утвердить 4-месячный пилотный проект внешней испытательной лаборатории и сообщества DevNet с максимальным бюджетом в 88 000 долларов США, выплачиваемым четырьмя ежемесячными траншами по 22 000 долларов США каждый, и 80 000 GNK, выплачиваемыми после завершения пилотного проекта и принятия окончательного отчета.
Привет! Спасибо за предложение. Пара мыслей:
Qwen/Qwen3-4B-Instruct-2507, Qwen/Qwen2.5-7B-Instruct,
Я бы, вероятно, выбрал https://huggingface.co/Qwen/Qwen3-0.6B на ранней стадии. Для тестовой сети с небольшими моделями не имеет значения, какая модель — 0,6B или 7B. Поэтому, когда это тестовая сеть с небольшими моделями, любая модель/графический процессор должна подойти. Я бы посоветовал использовать самые дешевые графические процессоры.
Узлы вывода: компьютеры NVIDIA с графическим процессором и 24 ГБ видеопамяти, совместимые со стеком контейнеров/среды выполнения проекта CUDA 13.0.
Судя по предыдущему комментарию, требования могут быть снижены. Лучше использовать больше маленьких графических процессоров, чем несколько больших, для имитации основной сети.
Целевой размер: 9–11 постоянно работающих машин вывода.
Я бы включил сетевые узлы с несколькими MLNodes.
Учебники и извлеченные уроки задокументированы к концу пилотного проекта
Я бы сказал, что команде тестирования также придется поиграть с такими примитивами, как настройка порога проверки PoC и порога проверки вывода. Было бы полезно внести непосредственный вклад в документацию.
Увеличенный бюджет на тестирование графического процессора
Кто будет иметь доступ к этим ресурсам? Только команда тестирования? Я бы уточнил, как используются полноразмерные серверы.
Публичная панель мониторинга состояния DevNet и состояния узлов.
Я думаю, потребуются какие-то соглашения с нынешними сопровождающими приборной панели? Или какие информационные панели будут использоваться?
Будет ли такая тестовая сеть общедоступной? например может ли какой-нибудь хост поэкспериментировать с присоединением к тестовой сети перед присоединением к основной сети?
Смогут ли пользователи, не входящие в команду контроля качества, экспериментировать с логическими выводами, смарт-контрактами и т. д.?
С моей точки зрения, идея в целом хороша и должна быть весьма полезной. Я бы попытался уточнить публичный доступ (думаю, лучше сделать его полностью закрытым)
Спасибо, Глеб, это очень полезные моменты.
Согласен, начнем с Qwen3-0.6B или аналогичной модели и соответственно снизим требования к графическому процессору. Поскольку целью DevNet является моделирование распределенного поведения, а не пропускной способности, я бы предпочел использовать экономию средств для запуска большего количества узлов меньшего размера. Я также снизил ограничение на инфраструктуру DevNet.
Хороший момент и в отношении сетевых узлов с несколькими MLNodes. Уточню предполагаемую топологию.
По порогам и документации: тоже согласен. Группа тестирования должна не только проверять выпуски, но и документировать практические рабочие примитивы, такие как порог проверки PoC, порог проверки вывода и извлеченные уроки. Это должно стать частью общедоступных руководств, и там, где это имеет смысл, мы внесем эти результаты непосредственно в официальную документацию Gonka.
Что касается пакетных ресурсов графического процессора, я уточню доступ и использование. В настоящее время я считаю, что доступ должен координироваться группой тестирования/владельцами проекта во время пилотного проекта, в основном для кандидатов на выпуск и модельных тестов, с публичным сообщением об использовании и затратах.
Что касается информационных панелей, я об этом не подумал, но это интересный момент, который может сэкономить время и средства. Мы свяжемся с нынешними сопровождающими информационной панели, чтобы узнать, смогут ли они помочь. Если нет, мы будем использовать специальную панель мониторинга в стиле Grafana для проверки работоспособности DevNet и состояния узлов, как и планировалось.
Что касается публичного доступа: да, репетиция адаптации хоста перед основной сетью — это один из предполагаемых вариантов использования DevNet, а пользователи, не имеющие опыта обеспечения качества, экспериментирующие с логическими выводами и смарт-контрактами, — это то направление, которое нам нужно. В ходе пилотного проекта я бы реализовал это через упрощенный процесс запроса, в основном для управления злоупотреблениями, доступом и стабильностью узла, в то время как документы по мониторингу и адаптации все еще находятся в разработке. Целевым состоянием является более широкое участие, и я хочу перейти к полностью несанкционированному доступу, как только это позволят безопасность, ограничения на злоупотребления, документация по адаптации и мониторинг. Я просто пока не хочу обещать конкретную дату пилотного проекта.
Я обновил предложение, чтобы отразить эти моменты.
Конечно, нам следует использовать настройку с несколькими узлами, некоторые сетевые узлы будут находиться на серверах только с ЦП, некоторые - полные узлы.
Я считаю, что:
- Эта сеть разработки должна быть общедоступной с самого начала. Чтобы каждый мог подключить свой узел, никого не спрашивая. Это делает условия более реалистичными, и более того, нам это ничего не стоит.
Эта сеть разработки должна быть общедоступной с самого начала. Чтобы каждый мог подключить свой узел, никого не спрашивая. Это делает условия более реалистичными, и более того, нам это ничего не стоит.
- Ресурсы Burst GPU могут быть выделены разработчикам из основной команды, а также командам, у которых уже есть вознаграждение за коммиты протокола — в первую очередь, сопровождающим https://registry.kaitaku.ai/ (хотя, конечно, здесь мы ограничены бюджетом).
Ресурсы Burst GPU могут быть выделены разработчикам из основной команды, а также командам, у которых уже есть вознаграждение за коммиты протокола — в первую очередь, сопровождающим https://registry.kaitaku.ai/ (хотя, конечно, здесь мы ограничены бюджетом).
- Что касается дашбордов — трекер мы точно сможем поставить сами, благо его код открыт. В идеале нам следует привлечь разработчиков популярных трекеров и обозревателей блоков, чтобы они сами запускали дев-версии. Я думаю, им самим это будет интересно.
Что касается дашбордов — трекер мы точно сможем поставить сами, благо его код открыт. В идеале нам следует привлечь разработчиков популярных трекеров и обозревателей блоков, чтобы они сами запускали дев-версии. Я думаю, им самим это будет интересно.
Ах да, если мы имеем в виду хосты, подключающие свои машины к DevNet, то это, безусловно, следует приветствовать с самого начала. Я больше думал о контролируемом доступе к ресурсам, управляемым проектом, где возникают риски затрат, злоупотреблений или стабильности.
Контракт условного депонирования находится в цепочке
Идентификатор кода: 107, контрольная сумма 94b141625b7641e6ad57266420b18a4af72eac49b8110cb92719755590b463bd
Адрес условного депонирования: gonka1g57f45qjvn0529vpgj8x8mzt8r5k4audchm3pp9pezywxwf4rexqlj8ayw
- Источник: https://github.com/paranjko/testlab-devnet-escrow/tree/1b2e529876141816b5c2130840d04fb93694bf72.
В контракте содержится 88 000 долларов США + 80 000 GNK, и они выплачиваются по фиксированному графику, предусмотренному этим предложением. Никакого администрирования, никакой миграции: получатели и суммы никогда не изменятся. У руководства есть один рычаг: единовременный возврат средств, который возвращает все оставшиеся средства в пул сообщества, доступный в любой момент; каждый транш разблокируется с помощью 4-дневного буфера, поэтому 2-дневное голосование всегда подходит перед следующей выплатой.
Проверьте (требуется докер):
git clone https://github.com/paranjko/testlab-devnet-escrow && cd testlab-devnet-escrow ./build.sh && sha256sum артефакты/milestone_escrow.wasm # должно соответствовать: выведенный запрос wasm code-info 107
Предложение № 82 — Внешняя тестовая лаборатория и сообщество DevNet принято. (https://gonka.vote/governance/82)
Сейчас мы начинаем первый месяц: организуем аренду оборудования, подключаем к сети первоначальные узлы и начинаем процесс поиска и найма команды контроля качества. Мы будем использовать эту тему, чтобы делиться прогрессом.
Спасибо всем, кто рассмотрел предложение и проголосовал.
Первый отчет будет опубликован примерно 9 августа, за четыре дня до следующей разблокировки.
Как и было обещано, вот отчет за первый месяц для внешней тестовой лаборатории и сообщества DevNet (https://github.com/paranjko/external-test-lab/blob/main/reports/monthly/2026-08-month-1.md).
Все вспомогательные материалы и артефакты уже опубликованы в репозитории Test Lab (https://github.com/paranjko/external-test-lab/), который на данный момент останется основным источником обновлений проекта.
Привет, я живу в Дубае и буду рад поддержать проект на местном уровне, если местоположение в ОАЭ или странах Ближнего Востока и Северной Африки станет полезным для будущего тестирования или развертывания инфраструктуры.
Ранее я также работал над проектом CoolTank — концепцией двухфазного погружного охлаждения, первоначально разработанной для майнинга криптовалют и работы в жарких условиях. Тот же базовый подход потенциально может быть адаптирован к инфраструктуре серверов графических процессоров с высокой плотностью при условии проведения надлежащей инженерной проверки и проверок совместимости оборудования.
Вероятно, это не актуально для легких узлов Community DevNet, но, возможно, стоит обсудить это для будущих развертываний хостов Gonka с высокой плотностью или инфраструктуры класса H200/B200 в регионе MENA.
Обзор проекта: https://www.thecooltank.com/ (https://www.thecooltank.com/?utm_source=chatgpt.com)
Буду рад обсудить, имеет ли это отношение к дорожной карте проекта.
External Test Lab & Community DevNet
4-month pilot proposal for community-owned testing infrastructure and QA capacity
1. Executive Summary
This proposal requests funding for a 4-month pilot of External Test Lab & Community DevNet: a community-owned testing function for Gonka protocol upgrades, DevShards, inference flows, host/broker operations, and geographically distributed network behavior before governance decisions and production rollout.
2. Problem Statement
Today, Gonka lacks a dedicated community-owned validation layer for important network changes. The External Test Lab and Community DevNet are proposed to close this gap by providing practical testing capacity, shared infrastructure, and public evidence before releases, governance decisions, or production rollout.
The External Test Lab and Community DevNet will:
- Validate protocol upgrades, DevShard releases, broker/inference flows, integrations, and other critical network changes before they move forward.
Validate protocol upgrades, DevShard releases, broker/inference flows, integrations, and other critical network changes before they move forward.
- Test distributed-network behavior that is hard to verify in local or internal environments, including latency, synchronization, propagation, and regional instability.
Test distributed-network behavior that is hard to verify in local or internal environments, including latency, synchronization, propagation, and regional instability.
- Use available testing capacity for proactive bug hunting, regression checks, and investigation of known weak points when no release candidate is waiting for validation.
Use available testing capacity for proactive bug hunting, regression checks, and investigation of known weak points when no release candidate is waiting for validation.
- Provide a neutral testing path for work delivered by external teams and ecosystem contributors before it is accepted, funded further, or used in production.
Provide a neutral testing path for work delivered by external teams and ecosystem contributors before it is accepted, funded further, or used in production.
- Help validate vulnerability reports from researchers, audits, or programs such as HackerOne through reproduction, impact assessment, regression testing, and confirmation after remediation.
Help validate vulnerability reports from researchers, audits, or programs such as HackerOne through reproduction, impact assessment, regression testing, and confirmation after remediation.
- Provide a shared environment where trusted hosts and teams can safely test proposals, integrations, DevShard scenarios, protocol behavior, and early implementation ideas.
Provide a shared environment where trusted hosts and teams can safely test proposals, integrations, DevShard scenarios, protocol behavior, and early implementation ideas.
- Produce clearer testing evidence for governance participants, including test plans, dashboards, runbooks, issue trackers, defect reports, security-sensitive disclosure handling, and release-readiness summaries.
Produce clearer testing evidence for governance participants, including test plans, dashboards, runbooks, issue trackers, defect reports, security-sensitive disclosure handling, and release-readiness summaries.
This adds a missing validation layer for the Gonka ecosystem while complementing Core Team testing.
3. Roadmap Alignment
This proposal directly implements two projects from the Gonka Network Development Roadmap (https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md) .
Track 4. Network reliability and observability — Project 2. External testing lab The roadmap defines an external testing lab for Gonka changes before broad rollout, including changes from Protocol Maintainers, funded external teams, and ecosystem contributors.
This proposal implements that project through the External Testing Team, test plans, smoke and regression checks, defect reports, public issue tracking, and release-readiness reports.
Track 7. Public sandbox and consumer-GPU testnet — Project 1. Public testing sandbox The roadmap defines a separate test environment for experiments with models, parameters, integrations, DevShard scenarios, protocol-level behavior, validation, settlement, and upgrade testing before mainnet.
This proposal implements that project through Community DevNet: a small, always-on, geographically distributed network for protocol, node, DevShard, operational, integration, and distributed-behavior testing.
4. What We Are Building
The project has three connected components.
5. Community DevNet Infrastructure
- Target size: 9–13 always-on inference machines plus required network nodes, where feasible within the monthly DevNet infrastructure cap.
Target size: 9–13 always-on inference machines plus required network nodes, where feasible within the monthly DevNet infrastructure cap.
- Topology: part of the DevNet runs as Network Nodes with multiple attached MLNodes, so that realistic multi-MLNode host configurations can be reproduced and tested.
Topology: part of the DevNet runs as Network Nodes with multiple attached MLNodes, so that realistic multi-MLNode host configurations can be reproduced and tested.
- Indicative distribution: North America East, North America West, United Kingdom, Germany, France, Finland, and Asian locations depending on network quality and hosting availability.
Indicative distribution: North America East, North America West, United Kingdom, Germany, France, Finland, and Asian locations depending on network quality and hosting availability.
- Model profile: DevNet inference nodes are expected to run lightweight instruct models, such as Qwen/Qwen3-0.6B (https://huggingface.co/Qwen/Qwen3-0.6B) , or equivalent models.
Model profile: DevNet inference nodes are expected to run lightweight instruct models, such as Qwen/Qwen3-0.6B (https://huggingface.co/Qwen/Qwen3-0.6B) , or equivalent models.
- Inference nodes: NVIDIA GPU machines with 16 GB VRAM, compatible with the project’s CUDA 13.0 container/runtime stack.
Inference nodes: NVIDIA GPU machines with 16 GB VRAM, compatible with the project’s CUDA 13.0 container/runtime stack.
- Goal: protocol and distributed behavior testing.
Goal: protocol and distributed behavior testing.
- Monitoring: public dashboard for node availability.
Monitoring: public dashboard for node availability.
- Operations: infrastructure lead from the host/DevOps community responsible for provisioning, monitoring, and maintenance.
Operations: infrastructure lead from the host/DevOps community responsible for provisioning, monitoring, and maintenance.
Public access. The DevNet is intended to serve the broader community, not only the testing team. During the pilot, access for external participants is granted through a lightweight request process — primarily to manage abuse, access control, and node stability while monitoring and onboarding documentation are still being built. Intended external use cases include:
- hosts rehearsing onboarding and node operations before joining mainnet;
hosts rehearsing onboarding and node operations before joining mainnet;
- developers and users experimenting with inference, smart contracts, and integrations outside the QA team's test plan.
developers and users experimenting with inference, smart contracts, and integrations outside the QA team's test plan.
Broader participation is the target state: we intend to move to fully permissionless access as soon as safety, abuse limits, onboarding documentation, and monitoring allow it.
6. Burst GPU Testing Budget
- Used only when needed for release candidates, large model tests, load tests, and model compatibility checks.
Used only when needed for release candidates, large model tests, load tests, and model compatibility checks.
- Planning assumption: Up to one calendar week (168 hours) of rental per month.
Planning assumption: Up to one calendar week (168 hours) of rental per month.
- For Kimi-class testing, the requirement estimate assumes an ML Node with either 4× NVIDIA B200 or 8× NVIDIA H200, around 640 GB total GPU VRAM, 960 GB+ system RAM, 16-core amd64 CPU, and a Network Node host with 16-core CPU, 64 GB+ RAM, 1 TB NVMe, and at least 100 Mbps networking.
For Kimi-class testing, the requirement estimate assumes an ML Node with either 4× NVIDIA B200 or 8× NVIDIA H200, around 640 GB total GPU VRAM, 960 GB+ system RAM, 16-core amd64 CPU, and a Network Node host with 16-core CPU, 64 GB+ RAM, 1 TB NVMe, and at least 100 Mbps networking.
Access and accountability. Burst GPU capacity is provisioned and coordinated by the External Testing Team together with the project owners, primarily for release-candidate validation, model compatibility, and load tests. Requests from Protocol Maintainers and ecosystem teams are accommodated where capacity allows. All burst usage is itemized in the monthly public report: purpose, hours used, and cost per test run, with test logs published alongside.
7. External Testing Team
The proposal funds two external QA / Infrastructure Testing Engineers.
Scope of work
Contribute to quality standards and test strategy for the network
Contribute to quality standards and test strategy for the network
Define acceptance criteria and test plans for core network lifecycle events and components
Define acceptance criteria and test plans for core network lifecycle events and components
Build pre-release validation frameworks, including smoke checks and regression coverage for known failure patterns
Build pre-release validation frameworks, including smoke checks and regression coverage for known failure patterns
Deploy and verify distributed node and service stacks in production-like environments
Deploy and verify distributed node and service stacks in production-like environments
- Validate critical cross-system flows end to end, with documented evidence and clear defect escalation — e.g. participant and key flows, inference and proof-of-compute participation, gateway and proxy behavior
Validate critical cross-system flows end to end, with documented evidence and clear defect escalation — e.g. participant and key flows, inference and proof-of-compute participation, gateway and proxy behavior
Use health signals, chain queries, and logs as primary validation inputs, not just debugging aids
Use health signals, chain queries, and logs as primary validation inputs, not just debugging aids
Verify upgrade readiness, rollback feasibility, and post-change health across the stack
Verify upgrade readiness, rollback feasibility, and post-change health across the stack
- Establish, tune, and document practical operational primitives, such as PoC validation threshold and inference validation threshold settings, based on DevNet experience, and contribute these findings directly to the official Gonka documentation where appropriate.
Establish, tune, and document practical operational primitives, such as PoC validation threshold and inference validation threshold settings, based on DevNet experience, and contribute these findings directly to the official Gonka documentation where appropriate.
Support DevNet validation and release-readiness assessment before production rollouts
Support DevNet validation and release-readiness assessment before production rollouts
Validate recovery and incident resolution through root-cause analysis and re-testing
Validate recovery and incident resolution through root-cause analysis and re-testing
Report defects with clear reproduction steps, impact assessment, and release-blocking status
Report defects with clear reproduction steps, impact assessment, and release-blocking status
Track and communicate quality metrics that reflect network health and operational reliability
Track and communicate quality metrics that reflect network health and operational reliability
Required capabilities
3+ years in system QA / Test Engineering, SDET, or quality-focused DevOps/SRE
3+ years in system QA / Test Engineering, SDET, or quality-focused DevOps/SRE
Understanding of blockchain lifecycle, key and auth flows: registration, delegated permissions, fee grants
Understanding of blockchain lifecycle, key and auth flows: registration, delegated permissions, fee grants
- Experience in operation and validation of blockchain nodes (Cosmos SDK preferred): sync, recovery, RPC queries, network phase behavior
Experience in operation and validation of blockchain nodes (Cosmos SDK preferred): sync, recovery, RPC queries, network phase behavior
Experience validating distributed systems in production-like environments
Experience validating distributed systems in production-like environments
Strong test design: test plans, acceptance criteria, smoke/regression/e2e, edge cases, negative testing
Strong test design: test plans, acceptance criteria, smoke/regression/e2e, edge cases, negative testing
Solid Linux, SSH, shell scripting, and log-based verification
Solid Linux, SSH, shell scripting, and log-based verification
Docker & container orchestration - including environment and config reload behavior
Docker & container orchestration - including environment and config reload behavior
Clear defect reporting and documentation — runbooks, test results, sign-off checklists
Clear defect reporting and documentation — runbooks, test results, sign-off checklists
Comfort with time-boxed validation before critical network events
Comfort with time-boxed validation before critical network events
Preferred / Nice-to-Have
SDET experience: scripted validation, CI pipelines, automated health checks
SDET experience: scripted validation, CI pipelines, automated health checks
Blockchain / Web3 QA: testnet operations, bridge testing, wallet/key flows, upgrade regression
Blockchain / Web3 QA: testnet operations, bridge testing, wallet/key flows, upgrade regression
Cross-chain testing: EVM testnet validation, withdrawal flows, contract interaction
Cross-chain testing: EVM testnet validation, withdrawal flows, contract interaction
GPU/ML inference testing: worker health, model serving, artifact delivery
GPU/ML inference testing: worker health, model serving, artifact delivery
Experience with coordinated multi-node upgrades
Experience with coordinated multi-node upgrades
API gateway and proxy testing (failures, latency, request tracing)
API gateway and proxy testing (failures, latency, request tracing)
Decentralized inference or Proof of Compute networks
Decentralized inference or Proof of Compute networks
8. Project Owners and Accountability
9. Transparency and Reporting
- Public dashboard for DevNet health and node status.
Public dashboard for DevNet health and node status.
- Public task board for planned, active, and completed testing work.
Public task board for planned, active, and completed testing work.
- Public issue tracker for non-sensitive bugs, regressions, and operational findings.
Public issue tracker for non-sensitive bugs, regressions, and operational findings.
- Monthly public report with deliverables, incidents, spending by budget line, remaining balance, unused funds, and next-month plan.
Monthly public report with deliverables, incidents, spending by budget line, remaining balance, unused funds, and next-month plan.
- Per-release readiness report before governance vote or production rollout when a release candidate is provided in time.
Per-release readiness report before governance vote or production rollout when a release candidate is provided in time.
- Security-sensitive findings are reported privately to Core Team first; a public placeholder issue is created where appropriate, and details are disclosed after remediation or agreed disclosure window.
Security-sensitive findings are reported privately to Core Team first; a public placeholder issue is created where appropriate, and details are disclosed after remediation or agreed disclosure window.
10. Protocol Maintainer Coordination
- The External Test Lab is intended to work in coordination with Protocol Maintainers while remaining an external community testing function.
The External Test Lab is intended to work in coordination with Protocol Maintainers while remaining an external community testing function.
- Protocol Maintainers are expected to support initial onboarding by providing technical context, relevant documentation, general guidance, scripts and notes, expected test focus, and clarification of protocol-specific behavior where needed.
Protocol Maintainers are expected to support initial onboarding by providing technical context, relevant documentation, general guidance, scripts and notes, expected test focus, and clarification of protocol-specific behavior where needed.
- This coordination helps the testing team become productive faster and reduces the risk of misinterpreting expected network behavior. At the same time, validation reports remain independently prepared by the External Test Lab and are published for the community.
This coordination helps the testing team become productive faster and reduces the risk of misinterpreting expected network behavior. At the same time, validation reports remain independently prepared by the External Test Lab and are published for the community.
11. Release Validation Handoff Requirements
Where a governance vote or production rollout is scheduled and testable artifacts are provided in time, the External Test Lab publishes a readiness report covering tested areas, pass/fail results, known risks, and recommendations.
If testable artifacts are provided late or incomplete, the External Test Lab may still perform limited validation, but the report will clearly state the reduced scope, time constraints, and known limitations.
12. Milestones and Acceptance Criteria
Workstream A: DevNet Infrastructure
Workstream B: External Testing Lab
13. KPIs
14. Budget Estimate
This is a planning estimate for a 4-month pilot. Unused burst GPU rental budget may roll over within the pilot; any unused funds at the end of the pilot will be returned to the Community Pool.
Any unused funds will be returned to the Community Pool at the end of the pilot.
* The cap above raw GPU-hour pricing covers reserved or non-interruptible instances required for always-on operation, regional price premiums outside low-cost US marketplaces, CPU-only Network Node hosts for the multi-MLNode topology, storage and egress, and temporary node duplication during upgrade and failover testing. It is a cap, not a spend target: actual spending will be itemized monthly, and unused funds will be returned to the Community Pool at the end of the pilot.
** Nebius (https://nebius.com/prices) listed B200 on-demand pricing at $7.15/GPU-hour and H200 on-demand pricing at $4.50/GPU-hour (June 2026). At these on-demand rates, 4× B200 for 168 hours would cost approximately $4.8k, while 8× H200 for 168 hours would cost approximately $6.05k.
15. Payment Schedule
16. End-of-pilot GNK recognition
The Project Lead and Infrastructure Lead receive no monthly compensation from the pilot budget: all USDT tranches fund infrastructure, tooling, and the External Testing Engineers. Leadership work is recognized only through the one-time GNK allocation below, paid after pilot completion and final report acceptance.
17. Open Source, Ownership and Handoff
- All non-sensitive documentation, test plans, runbooks, dashboards, issue templates, and reports will be public by default.
All non-sensitive documentation, test plans, runbooks, dashboards, issue templates, and reports will be public by default.
- Where code or scripts are created, they will be published under an open-source license compatible with Gonka ecosystem norms unless there is a clear security reason not to.
Where code or scripts are created, they will be published under an open-source license compatible with Gonka ecosystem norms unless there is a clear security reason not to.
- Infrastructure access will not depend on a single individual. The owner model, emergency access process, and handoff procedure will be documented.
Infrastructure access will not depend on a single individual. The owner model, emergency access process, and handoff procedure will be documented.
- At the end of the pilot, a community-approved team should be able to take over the DevNet and External Testing Lab using the published runbooks, documentation, and access handoff process.
At the end of the pilot, a community-approved team should be able to take over the DevNet and External Testing Lab using the published runbooks, documentation, and access handoff process.
Decision Requested
Approve a 4-month pilot of External Test Lab & Community DevNet with a maximum budget authorization of 88,000 USDT, paid in four monthly tranches of up to 22,000 USDT each, and 80,000 GNK paid after pilot completion and final report acceptance.
Hi! Thanks for proposal. A couple thoughts:
Qwen/Qwen3-4B-Instruct-2507, Qwen/Qwen2.5-7B-Instruct,
I'd probably go with https://huggingface.co/Qwen/Qwen3-0.6B on early phase. For testnet with small models, it doesn't really matter if model is 0.6B or 7B. So when it's testnet with small models, any model/GPUs should be good. I'd suggest to go with cheapest possible GPUs
Inference nodes: NVIDIA GPU machines with 24 GB VRAM, compatible with the project’s CUDA 13.0 container/runtime stack.
Based on previous comment, requirements can be lowered. More small GPUs is better that few bigger ones to simulate mainnet
Target size: 9–11 always-on inference machines.
I'd include Network Nodes with multiple MLNodes
Runbooks and lessons learned documented by end of pilot
I'd say test team also will have to play with such primitives as setting up PoC validation threshold and inference validation threshold. Would be useful to contribute directly in documentation too
Burst GPU Testing Budget
Who will have access to this resources? Only testing team? I'd clarify how full size servers are used
Public dashboard for DevNet health and node status.
I think some agreements with current dashboard maintainers would required? Or which dashboards would be used?
Will such testnet be publicly available? E.g. can some host experiment with joining testnet before joining mainnet?
Will users not from QA team be able to experiment with inference, smart contracts, etc. ?
From my perspective the idea overall is good and should be quite helpful. I'd try to clarify the public access (i think it's better to make it fully permissionless)
Thanks Gleb, these are very helpful points.
I agree, we'll start with Qwen3-0.6B or a similar model and lower the GPU requirements accordingly. Since the point of the DevNet is to simulate distributed behavior rather than throughput, I'd rather use the cost savings to run a larger number of smaller nodes. I've also lowered the DevNet infrastructure cap.
Good point on Network Nodes with multiple MLNodes as well. I will clarify the intended topology.
On thresholds and documentation: agreed as well. The testing team should not only validate releases, but also document practical operational primitives such as PoC validation threshold, inference validation threshold, and lessons learned. This should become part of the public runbooks, and where it makes sense we'll contribute these findings directly to the official Gonka documentation.
For burst GPU resources, I’ll clarify access and usage. My current thinking is that access should be coordinated by the testing team / project owners during the pilot, mainly for release candidates and model tests, with usage and costs reported publicly.
For dashboards, I hadn’t thought about it that way, but it is an interesting point and may save some time and funds. We will contact the current dashboard maintainers to see if they can help. If not, we will use a dedicated Grafana-style dashboard for DevNet health and node status as planned.
On public access: yes, host onboarding rehearsal before mainnet is one of the intended DevNet use cases, and non-QA users experimenting with inference and smart contracts is the direction we want. During the pilot, I would gate this through a lightweight request process, mainly to manage abuse, access, and node stability while monitoring and onboarding docs are still being built. Broader participation is the target state, and I want to get to fully permissionless access as soon as safety, abuse limits, onboarding docs, and monitoring allow it. I just don't want to promise a specific date within the pilot yet.
I've updated the proposal to reflect these points.
Sure, we should use multinode setup, some network nodes will be on CPU only servers, some full nodes.
I believe that:
- This devnet should be public from the start. So that anyone can connect their node without asking anyone. It makes the conditions more realistic, and moreover, it costs us nothing.
This devnet should be public from the start. So that anyone can connect their node without asking anyone. It makes the conditions more realistic, and moreover, it costs us nothing.
- Burst GPU resources can be allocated to developers from the core team, as well as to teams that already have rewards for commits to the protocol — first and foremost, the maintainers of https://registry.kaitaku.ai/ (Though of course we're limited by the budget here.)
Burst GPU resources can be allocated to developers from the core team, as well as to teams that already have rewards for commits to the protocol — first and foremost, the maintainers of https://registry.kaitaku.ai/ (Though of course we're limited by the budget here.)
- Regarding dashboards — we can definitely stand up the tracker ourselves, since its code is open. Ideally, we should engage the developers of the popular trackers and block explorers so they launch dev versions themselves. I think they'll be interested in this on their own.
Regarding dashboards — we can definitely stand up the tracker ourselves, since its code is open. Ideally, we should engage the developers of the popular trackers and block explorers so they launch dev versions themselves. I think they'll be interested in this on their own.
Ah, yes, if we mean hosts connecting their own machines to the DevNet, then absolutely, that should be welcome from the start. I was thinking more about controlled access to project-managed resources, where cost, abuse, or stability risks are involved.
Escrow contract is on chain
Code ID: 107, checksum 94b141625b7641e6ad57266420b18a4af72eac49b8110cb92719755590b463bd
Escrow address: gonka1g57f45qjvn0529vpgj8x8mzt8r5k4audchm3pp9pezywxwf4rexqlj8ayw
Source: https://github.com/paranjko/testlab-devnet-escrow/tree/1b2e529876141816b5c2130840d04fb93694bf72
The contract holds 88,000 USDT + 80,000 GNK and pays them out on the fixed schedule from this proposal. No admin, no migration: recipients and amounts can never change. Governance keeps one lever: a one-time clawback that returns all remaining funds to the Community Pool, available at any moment; every tranche unlocks with a 4-day buffer so a 2-day vote always fits before the next payout.
Verify (needs docker):
git clone https://github.com/paranjko/testlab-devnet-escrow && cd testlab-devnet-escrow ./build.sh && sha256sum artifacts/milestone_escrow.wasm # must match: inferenced query wasm code-info 107
Proposal #82 — External Test Lab & Community DevNet has passed. (https://gonka.vote/governance/82)
We’re now starting Month 1: arranging hardware rentals, bringing the initial nodes online, and beginning the search and hiring process for the QA team. We’ll use this thread to share progress.
Thank you to everyone who reviewed the proposal and voted.
The first report will be published around August 9, four days before the next unlock.
As promised, here is the Month 1 report for the External Test Lab & Community DevNet (https://github.com/paranjko/external-test-lab/blob/main/reports/monthly/2026-08-month-1.md) .
All supporting materials and artifacts have already been published in the Test Lab repository (https://github.com/paranjko/external-test-lab/) which will remain the main source for project updates for now.
Hi, I’m based in Dubai and would be happy to support the project locally if a UAE or MENA location becomes useful for future testing or infrastructure deployment.
I have also previously worked on the CoolTank project, a two-phase immersion cooling concept originally developed for cryptocurrency mining and operation in hot environments. The same underlying approach may potentially be adaptable to high-density GPU server infrastructure, subject to proper engineering validation and hardware compatibility checks.
This is probably not relevant for the lightweight Community DevNet nodes, but it could be worth discussing for future high-density Gonka Host deployments or H200/B200-class infrastructure in the MENA region.
Project overview: https://www.thecooltank.com/ (https://www.thecooltank.com/?utm_source=chatgpt.com)
Happy to discuss if this is relevant to the project roadmap.
Внешняя тестовая лаборатория и сообщество DevNet
4-месячное пилотное предложение по созданию общественной инфраструктуры тестирования и потенциала обеспечения качества
1. Резюме
В этом предложении требуется финансирование четырехмесячного пилотного проекта внешней тестовой лаборатории и сообщества DevNet: принадлежащей сообществу функции тестирования обновлений протокола Gonka, DevShards, потоков вывода, операций хоста/брокера и поведения географически распределенной сети перед принятием решений по управлению и развертыванием производства.
2. Постановка задачи
Сегодня в Gonka отсутствует выделенный уровень проверки, принадлежащий сообществу, для важных изменений в сети. Внешняя лаборатория тестирования и Community DevNet призваны устранить этот пробел, предоставив возможности практического тестирования, общую инфраструктуру и общедоступные доказательства перед выпуском, принятием управленческих решений или развертыванием производства.
Внешняя лаборатория тестирования и сообщество DevNet будут:
Проверяйте обновления протоколов, выпуски DevShard, потоки брокера/вывода, интеграцию и другие важные сетевые изменения, прежде чем они будут реализованы.
Тестируйте поведение распределенной сети, которое трудно проверить в локальной или внутренней среде, включая задержку, синхронизацию, распространение и региональную нестабильность.
Используйте доступные возможности тестирования для превентивного поиска ошибок, регрессионных проверок и исследования известных слабых мест, когда ни один кандидат на выпуск не ожидает проверки.
Обеспечьте нейтральный путь тестирования для работы, выполняемой внешними командами и участниками экосистемы, прежде чем она будет принята, профинансирована или использована в производстве.
Помогите проверить отчеты об уязвимостях от исследователей, аудитов или программ, таких как HackerOne, посредством воспроизведения, оценки воздействия, регрессионного тестирования и подтверждения после исправления.
Обеспечьте общую среду, в которой доверенные хосты и команды смогут безопасно тестировать предложения, интеграции, сценарии DevShard, поведение протоколов и идеи ранней реализации.
Предоставляйте более четкие доказательства тестирования для участников управления, включая планы тестирования, информационные панели, модули Runbook, средства отслеживания проблем, отчеты о дефектах, обработку конфиденциальной информации и сводки о готовности к выпуску.
Это добавляет недостающий уровень проверки для экосистемы Gonka и дополняет тестирование Core Team.
3. Согласование дорожной карты
Данное предложение напрямую реализует два проекта из Дорожной карты развития сети Gonka (https://github.com/gonka-ai/gonka/blob/da8750873216e3a96a1ac19fbd64bbf052f2160b/proposals/gonka-network-development-roadmap.md).
Трек 4. Надежность и наблюдаемость сети — Проект 2. Лаборатория внешнего тестирования Дорожная карта определяет внешнюю лабораторию тестирования для изменений Gonka перед широким развертыванием, включая изменения от специалистов по сопровождению протоколов, финансируемых внешних команд и участников экосистемы.
В этом предложении этот проект реализуется через группу внешнего тестирования, планы тестирования, дымовые и регрессионные проверки, отчеты о дефектах, общедоступное отслеживание проблем и отчеты о готовности к выпуску.
Трек 7. Публичная песочница и тестовая сеть потребительского графического процессора — Проект 1. Песочница для публичного тестирования. Дорожная карта определяет отдельную тестовую среду для экспериментов с моделями, параметрами, интеграциями, сценариями DevShard, поведением на уровне протокола, проверкой, расчетом и тестированием обновлений перед основной сетью.
Данное предложение реализует этот проект через Community DevNet: небольшую, постоянно работающую, географически распределенную сеть для тестирования протоколов, узлов, DevShard, эксплуатации, интеграции и распределенного тестирования поведения.
4. Что мы строим
Проект состоит из трех взаимосвязанных компонентов.
5. Инфраструктура DevNet сообщества
Целевой размер: 9–13 постоянно работающих машин вывода плюс необходимые сетевые узлы, где это возможно, в пределах ежемесячного ограничения инфраструктуры DevNet.
Топология: часть DevNet работает как сетевые узлы с несколькими подключенными узлами MLNodes, что позволяет воспроизводить и тестировать реалистичные конфигурации хостов с несколькими узлами MLNode.
Ориентировочное распространение: Восточная Северная Америка, Западная Северная Америка, Великобритания, Германия, Франция, Финляндия и страны Азии в зависимости от качества сети и доступности хостинга.
Профиль модели: ожидается, что узлы вывода DevNet будут запускать облегченные модели инструкций, такие как Qwen/Qwen3-0.6B (https://huggingface.co/Qwen/Qwen3-0.6B) или эквивалентные модели.
Узлы вывода: компьютеры NVIDIA с графическим процессором и 16 ГБ видеопамяти, совместимые со стеком контейнеров/среды выполнения проекта CUDA 13.0.
Цель: тестирование протокола и распределенного поведения.
Мониторинг: общедоступная панель мониторинга доступности узлов.
Операции: руководитель инфраструктуры от хост-сообщества/DevOps, отвечающий за предоставление, мониторинг и обслуживание.
Публичный доступ. DevNet предназначен для обслуживания более широкого сообщества, а не только группы тестирования. В ходе пилотного проекта доступ внешним участникам предоставляется через упрощенный процесс запроса — в первую очередь для управления злоупотреблениями, контроля доступа и стабильности узла, в то время как мониторинг и документация по адаптации все еще разрабатываются. Предполагаемые варианты внешнего использования включают в себя:
хосты репетируют подключение и работу узлов перед присоединением к основной сети;
разработчики и пользователи экспериментируют с логическими выводами, смарт-контрактами и интеграциями за пределами плана тестирования команды контроля качества.
Целевым состоянием является более широкое участие: мы намерены перейти к полностью несанкционированному доступу, как только это позволят безопасность, ограничения на злоупотребления, документация по адаптации и мониторинг.
6. Увеличенный бюджет на тестирование графического процессора
Используется только при необходимости для кандидатов на выпуск, тестов больших моделей, нагрузочных тестов и проверок совместимости моделей.
Предполагаемое планирование: До одной календарной недели (168 часов) аренды в месяц.
Для тестирования класса Kimi оценка требований предполагает узел ML с 4 NVIDIA B200 или 8 NVIDIA H200, общим объемом около 640 ГБ видеопамяти графического процессора, более 960 ГБ системной памяти, 16-ядерным процессором amd64 и хостом сетевого узла с 16-ядерным процессором, 64 ГБ+ ОЗУ, 1 ТБ NVMe и сетью со скоростью не менее 100 Мбит/с.
Доступ и подотчетность. Пакетная мощность графического процессора предоставляется и координируется группой внешнего тестирования совместно с владельцами проекта, в первую очередь для проверки кандидатов на выпуск, совместимости моделей и нагрузочных тестов. Запросы от специалистов по сопровождению протоколов и команд экосистемы удовлетворяются там, где позволяют возможности. Все пакетное использование подробно описано в ежемесячном общедоступном отчете: цель, затраченное время и стоимость выполнения теста, а также журналы тестирования, публикуемые вместе с ним.
7. Команда внешнего тестирования
В рамках предложения финансируются два внешних инженера по обеспечению качества и тестированию инфраструктуры.
Объем работ
Вносить вклад в стандарты качества и тестировать стратегию сети.
Определить критерии приемки и планы тестирования для событий и компонентов жизненного цикла базовой сети.
Создавайте системы проверки перед выпуском, включая дымовые проверки и регрессионное покрытие для известных шаблонов сбоев.
Развертывание и проверка распределенных стеков узлов и сервисов в средах, аналогичных производственных.
Комплексная проверка критически важных межсистемных потоков с использованием документированных доказательств и четкой эскалации дефектов — например, потоки участников и ключей, логический вывод и участие в доказательстве вычислений, поведение шлюза и прокси
Используйте сигналы работоспособности, цепочки запросов и журналы в качестве основных входных данных для проверки, а не только в качестве средств отладки.
Проверка готовности обновления, возможности отката и работоспособности стека после изменений.
Установите, настройте и задокументируйте практические рабочие примитивы, такие как пороговые значения проверки PoC и настройки пороговых значений проверки вывода, на основе опыта DevNet, и при необходимости внесите эти выводы непосредственно в официальную документацию Gonka.
Поддержка проверки DevNet и оценки готовности к выпуску перед развертыванием производства.
Проверка восстановления и разрешения инцидентов посредством анализа первопричин и повторного тестирования.
Сообщайте о дефектах с четкими этапами воспроизведения, оценкой воздействия и статусом блокировки выпуска.
Отслеживайте и передавайте показатели качества, отражающие работоспособность сети и эксплуатационную надежность.
Требуемые возможности
3+ года работы в сфере обеспечения качества систем/тестирования, SDET или DevOps/SRE, ориентированных на качество.
Понимание жизненного цикла блокчейна, потоков ключей и аутентификации: регистрация, делегированные разрешения, предоставление комиссий.
Опыт эксплуатации и проверки узлов блокчейна (предпочтительно Cosmos SDK): синхронизация, восстановление, RPC-запросы, фазовое поведение сети.
Опыт проверки распределенных систем в производственных средах.
Сильный дизайн тестирования: планы тестирования, критерии приемки, дым/регрессия/e2e, крайние случаи, отрицательное тестирование.
Solid Linux, SSH, сценарии оболочки и проверка на основе журналов
Solid Linux, SSH, сценарии оболочки и проверка на основе журналов
Оркестровка Docker и контейнеров, включая поведение среды и конфигурации при перезагрузке.
Четкие отчеты о дефектах и документация — инструкции, результаты тестов, контрольные списки
Четкие отчеты о дефектах и документация — инструкции, результаты тестов, контрольные списки
Комфорт благодаря ограниченной по времени проверке перед критическими сетевыми событиями.
Предпочтительно/приятно иметь
Опыт SDET: проверка по сценариям, конвейеры CI, автоматизированные проверки работоспособности.
Контроль качества блокчейна/Web3: операции тестовой сети, тестирование моста, потоки кошелька/ключей, регрессия обновления
Межсетевое тестирование: проверка тестовой сети EVM, потоки вывода средств, взаимодействие с контрактами
Межсетевое тестирование: проверка тестовой сети EVM, потоки вывода средств, взаимодействие с контрактами
Тестирование вывода GPU/ML: работоспособность работников, обслуживание моделей, доставка артефактов
Тестирование вывода GPU/ML: работоспособность работников, обслуживание моделей, доставка артефактов
Опыт скоординированных обновлений нескольких узлов
Опыт скоординированных обновлений нескольких узлов
Тестирование API-шлюза и прокси-сервера (сбои, задержки, отслеживание запросов)
Тестирование API-шлюза и прокси-сервера (сбои, задержки, отслеживание запросов)
Децентрализованный вывод или сети Proof of Compute
Децентрализованный вывод или сети Proof of Compute
8. Владельцы проектов и подотчетность
9. Прозрачность и отчетность
Публичная панель мониторинга состояния DevNet и состояния узлов.
Общедоступная доска задач для запланированных, активных и завершенных работ по тестированию.
Общедоступный трекер проблем для неконфиденциальных ошибок, регрессов и операционных результатов.
Ежемесячный публичный отчет с указанием результатов, инцидентов, расходов по статьям бюджета, оставшегося баланса, неиспользованных средств и плана на следующий месяц.
Отчет о готовности каждого выпуска перед голосованием руководства или развертыванием производства, если кандидат на выпуск предоставляется вовремя.
О результатах, важных для безопасности, сначала сообщается в частном порядке основной команде; При необходимости создается общедоступная проблема-заполнитель, а подробности раскрываются после исправления или согласованного окна раскрытия.
10. Координация сопровождения протокола
Лаборатория внешнего тестирования предназначена для работы в координации с обслуживающими протоколами, оставаясь при этом функцией внешнего тестирования сообщества.
Ожидается, что специалисты по обслуживанию протоколов будут поддерживать первоначальную адаптацию, предоставляя технический контекст, соответствующую документацию, общие рекомендации, сценарии и примечания, ожидаемую направленность тестирования и разъяснения поведения, специфичного для протокола, где это необходимо.
Такая координация помогает команде тестирования быстрее повысить производительность и снижает риск неправильной интерпретации ожидаемого поведения сети. В то же время отчеты о проверке по-прежнему подготавливаются независимой лабораторией внешнего тестирования и публикуются для сообщества.
11. Требования к передаче проверки релиза
Если запланировано голосование руководства или развертывание производства и тестируемые артефакты предоставляются вовремя, внешняя лаборатория тестирования публикует отчет о готовности, включающий протестированные области, результаты «пройдено/не пройдено», известные риски и рекомендации.
Если тестируемые артефакты предоставляются с опозданием или не в полном объеме, внешняя лаборатория тестирования все равно может выполнить ограниченную проверку, но в отчете будет четко указано сокращение объема, временные ограничения и известные ограничения.
12. Этапы и критерии приемки
Рабочий поток A: Инфраструктура DevNet
Рабочий поток B: Лаборатория внешнего тестирования
13. КПЭ
14. Бюджетная смета
Это плановая оценка для 4-месячного пилотного проекта. Неиспользованный бюджет аренды графического процессора может быть продлен в рамках пилотного проекта; любые неиспользованные средства по окончании пилотного проекта будут возвращены в пул сообщества.
Любые неиспользованные средства будут возвращены в пул сообщества по окончании пилотного проекта.
* Ограничение выше стоимости необработанных часов графического процессора распространяется на зарезервированные или непрерываемые экземпляры, необходимые для постоянной работы, региональные надбавки к ценам за пределами недорогих рынков США, хосты сетевых узлов только с ЦП для топологии с несколькими MLNode, хранилище и выход, а также временное дублирование узлов во время обновления и тестирования отказоустойчивости. Это ограничение, а не цель расходов: фактические расходы будут детализироваться ежемесячно, а неиспользованные средства будут возвращены в пул сообщества в конце пилотного проекта.
** Компания Nebius (https://nebius.com/prices) указала цену на B200 по требованию в размере 7,15 долларов США за час графического процессора, а цену на H200 по требованию — 4,50 доллара США за час графического процессора (июнь 2026 г.). При таких тарифах по требованию 4 × B200 на 168 часов будут стоить примерно 4,8 тыс. долларов, а 8 × H200 на 168 часов будут стоить примерно 6,05 тыс. долларов.
15. График платежей
16. Признание GNK в конце пилотного проекта
Руководитель проекта и руководитель инфраструктуры не получают ежемесячного вознаграждения из пилотного бюджета: все транши USDT финансируют инфраструктуру, инструменты и внешних инженеров по тестированию. Лидерская работа признается только посредством единовременного выделения ГНК, указанного ниже, которое выплачивается после завершения пилотного проекта и принятия окончательного отчета.
17. Открытый исходный код, право собственности и передача
Вся неконфиденциальная документация, планы тестирования, модули Runbook, панели мониторинга, шаблоны проблем и отчеты по умолчанию будут общедоступными.
Если создается код или скрипты, они будут публиковаться под лицензией с открытым исходным кодом, совместимой с нормами экосистемы Gonka, если только нет явных оснований безопасности не делать этого.
Доступ к инфраструктуре не будет зависеть от одного человека. Модель владельца, процесс экстренного доступа и процедура передачи обслуживания будут задокументированы.
В конце пилотного проекта одобренная сообществом команда должна иметь возможность взять на себя управление DevNet и лабораторией внешнего тестирования, используя опубликованные инструкции по запуску, документацию и процесс передачи доступа.
Требуемое решение
Утвердить 4-месячный пилотный проект внешней испытательной лаборатории и сообщества DevNet с максимальным бюджетом в 88 000 долларов США, выплачиваемым четырьмя ежемесячными траншами по 22 000 долларов США каждый, и 80 000 GNK, выплачиваемыми после завершения пилотного проекта и принятия окончательного отчета.