INC4 | Gonka Node Observability Platform

Платформа наблюдения за узлами Gonka

Предложение INC4 ( https://inc4.net ) | 16 апреля 2026 г.

Запрос на финансирование: 96 000 долларов США (USDT) на 12 месяцев.

Оглавление

Краткое изложение (№ 1-исполнительное резюме)

Постановка проблемы (#2-постановка проблемы)

Отраслевой контекст (#3-отраслевой контекст)

Предлагаемое решение (№ 4-предлагаемое-решение)

Технический подход (#5-технический подход)

Объем и результаты (#6-объем и результаты)

Бюджет и график платежей (#7-бюджет и график платежей)

Критерии успеха (#8-критерии успеха)

Команда (№9-команда)

1. Резюме

Сегодняшние проводники и информационные панели отображают только данные внутри цепочки, оставляя состояние валидаторов вне цепочки совершенно непрозрачным. Те немногие операторы, которые проводят собственный мониторинг, используют разные инструменты, разные показатели и разные исходные показатели, что приводит к разным интерпретациям и затрудняет координацию в случае возникновения проблем. В сети отсутствует единый источник достоверных данных и общая структура для измерения работоспособности валидаторов.

Даже сегодня, просто наблюдая за тем, как работают валидаторы, можно увидеть, что многие из них не реагируют вовремя на технические проблемы — растет процент промахов по выводу, снижается соотношение CPoC, отстает синхронизация сети. Эти закономерности сохраняются, поскольку у операторов нет возможности увидеть признаки раннего предупреждения или получить оповещения о чрезвычайной ситуации внутри своей собственной инфраструктуры.

Чтобы решить эту проблему, INC4 — активный оператор валидатора Gonka с практическим опытом работы в инфраструктуре блокчейна и наблюдаемости — предлагает создать платформу наблюдения за узлами Gonka — стек наблюдения с открытым исходным кодом, который объединяет метрики вне цепочки из сетевых узлов и узлов ML в общую общедоступную панель мониторинга. Платформа развертывается в независимой облачной инфраструктуре — без использования ресурсов какого-либо отдельного валидатора или предоставления кому-либо привилегированного доступа — так, чтобы все операторы имели равный доступ и видимость данных.

Для основной команды — единое представление всей сети, видимость проблемных узлов и периодов времени, данные для принятия обоснованных решений по протоколам, отчеты SLA и возможность оценить масштаб общесетевых проблем до и после обновлений. Для отдельных валидаторов — оповещения в реальном времени, сравнение производительности со средними показателями по сети, возможность совместного использования журналов для получения помощи в устранении неполадок и интерпретации показателей, а также отсутствие необходимости создавать собственный стек мониторинга.

Обнаружение и предотвращение даже одного крупного инцидента в масштабе всей сети или серии более мелких инцидентов на отдельных валидаторах может сэкономить экосистеме гораздо больше, чем годовая стоимость этой платформы. Основными бенефициарами являются сами операторы валидаторов, которые несут прямые затраты за каждую пропущенную эпоху и каждый час невыявленного простоя — особенно отдельные хосты без выделенного персонала DevOps, для которых создание и поддержка сопоставимого стека мониторинга самостоятельно просто неосуществимо.

Мы запрашиваем 96 000 долларов США в течение 12 месяцев, выплачиваемых ежеквартальными траншами, для развертывания и обслуживания платформы наблюдения производственного уровня — настраиваемых экспортеров Gonka, общепарковых и отдельных информационных панелей, агрегирования журналов по выбору, внешних проверок работоспособности конечных точек, оповещений и отчетов по SLA, практической адаптации валидаторов, поддержки реагирования на инциденты и текущего эксплуатационного обслуживания. Весь код, конфигурации и информационные панели будут иметь открытый исходный код и публиковаться в общедоступных репозиториях GitHub.

2. Постановка задачи

Состояние сети вне сети не видно

Gonka — это растущая сеть с более чем сотней валидаторов, еще большим количеством узлов машинного обучения и общим парком графических процессоров, превышающим 3000 карт. Существующие обозреватели блоков и информационные панели отображают данные в цепочке — высоту блоков, транзакции, силу голоса. Но инструментов для наблюдения за пределами сети в масштабах всей сети нет — состояние графического процессора, состояние контейнера, основные причины ошибок, время загрузки модели, показатели производительности LLM, тенденции инфраструктуры и т. д. Каждый оператор контролирует свою инфраструктуру изолированно или не контролирует вообще. Те, кто занимается мониторингом, настраивают свои собственные инструменты, по-разному рассчитывают показатели и используют разные базовые показатели, что приводит к недопониманию и путанице при обсуждении сетевых проблем.

В частности, существующие инструменты не показывают:

Почему процент промахов валидатора высок

Исчерпана ли оперативная или графическая память

Является ли ML или другие контейнеры аварийно-зацикливающимися

Сколько времени занимает загрузка модели после перезапуска

Доступен ли PUBLIC_URL извне

Сравнительная производительность валидаторов

На практике валидаторы сталкивались с длительными периодами высокой частоты ошибок или простоями вывода, не имея возможности определить основную причину. В то же время у основной команды не было возможности увидеть масштаб таких проблем в сети. Такие ситуации приводят к потере вознаграждения операторов и задержке реакции команды — проблемам, которые общая платформа наблюдения поможет обнаружить и решить гораздо быстрее.

Что происходит без решения

• Тихие сбои остаются незамеченными в течение нескольких часов или дней, что приводит к потере валидаторами пропущенных эпох и вознаграждений.

• Нет общей основы для отладки — каждый оператор использует разные инструменты, разные базовые показатели, разные определения «нормального».

• Основной команде не хватает прозрачности всего парка машин, что затрудняет диагностику проблем на уровне сети и планирование обновлений.

• Новые операторы действуют сами по себе — высокий барьер входа для небольших хостингов без опыта DevOps.

3. Отраслевой контекст

Сбор метрик валидаторов в одном месте — не новость.

Объединение телеметрии и показателей от валидаторов в общий бэкэнд — это хорошо зарекомендовавшая себя практика в индустрии блокчейнов. Несколько крупных сетей уже делают это:

• Солана — валидаторы передают показатели в общий бэкэнд; сеть публикует общедоступную панель управления Grafana по адресу https://metrics.solana.com:3000.

• Polkadot — узлы по умолчанию отправляют телеметрию на общий бэкэнд; общедоступная информационная панель в режиме реального времени доступна по адресу https://telemetry.polkadot.io.

• Кусама — использует ту же систему телеметрии субстрата, что и Polkadot, со своим собственным представлением по адресу https://telemetry.polkadot.io/#list/Kusama.

• NEAR — каждый узел поставляется с конечной точкой телеметрии по умолчанию ( telemetry.nearone.org ) и передает данные каждые 10 секунд.

• Aptos — все узлы по умолчанию передают метрики в централизованную службу телеметрии (telemetry.mainnet.aptoslabs.com); архитектура документирована в общедоступной спецификации SPEC.

• Celestia — поддерживает конечную точку сборщика OpenTelemetry ( otel.celestia.observer ) для узлов DA, а также стек наблюдения на основе Prometheus для узлов консенсуса.

Это не экзотическая идея. Именно так зрелые сети получают представление о своем состоянии, быстрее диагностируют проблемы и принимают решения на основе данных.

Во многих блокчейн-сетях телеметрия узлов собирается без ведома операторов — телеметрия часто включена по умолчанию в программном обеспечении узла, а в некоторых случаях у операторов вообще нет возможности отключить ее.

Платформа наблюдения за узлами Gonka, напротив, спроектирована как полностью добровольная система — валидаторы сами решают участвовать, и никакие данные не собираются без их явных действий.

Чем больше валидаторов присоединяются, тем более точной и полной становится картина работоспособности сети. Платформа, к которой подключено 30% валидаторов, дает полезную информацию; тот, у кого 80%, становится надежным источником истины для всей экосистемы.

4. Предлагаемое решение

Платформа наблюдения за узлами Gonka

Управляемый стек наблюдения с открытым исходным кодом, в котором операторы валидаторов добровольно переносят метрики вне цепочки на общую платформу, поддерживаемую INC4.

Принципы проектирования

Доставленная ценность

Для основной команды:

Агрегированные метрики и журналы по всему автопарку в одном месте

• Мгновенная видимость проблемных узлов, эпох и периодов времени.

Отчеты об уровне обслуживания и принятие решений на основе данных для обновления протокола

Поддержка реагирования на инциденты с анализом первопричин

Для валидаторов:

• Нет необходимости создавать и поддерживать собственный стек мониторинга.

• Сравните производительность вашего узла со средними показателями сети.

• Получайте оповещения через Telegram или Discord, если что-то пойдет не так.

• Делитесь журналами для совместного устранения неполадок при возникновении проблем.

Доступ к информационным панелям с любого устройства, включая мобильные

Практическая помощь в интерпретации показателей и диагностике инцидентов

Для сообщества:

Единый источник достоверных данных о показателях работоспособности сети

• Согласованные данные, на которые все участники могут ссылаться в обсуждениях.

Прозрачность сетевых операций

5. Технический подход

Платформа будет развернута в распределенной облачной инфраструктуре, обеспечивающей:

• Высокая доступность — отсутствие единой точки отказа; резервированная инфраструктура с соглашением об уровне обслуживания более 99,5 % времени безотказной работы

• Автоматическое масштабирование — платформа плавно растет по мере присоединения большего количества валидаторов, без необходимости ручного вмешательства.

• Сбор данных на основе push-уведомлений — валидаторы отправляют метрики через HTTPS; новые входящие порты не требуются, а существующие конфигурации брандмауэра полностью сохраняются.

Мы будем использовать хорошо зарекомендовавшие себя, проверенные в отрасли инструменты для наблюдения: Prometheus для сбора метрик, Grafana для информационных панелей и визуализации, Alertmanager для уведомлений, Promtail/Loki для унифицированного агрегирования журналов подписки и PagerDuty для управления инцидентами и эскалации по вызову.

INC4 имеет практический опыт создания и эксплуатации инфраструктуры наблюдения для сетей блокчейнов. Выбор каждого компонента в стеке обусловлен реальными эксплуатационными требованиями — надежностью под нагрузкой, простотой интеграции с существующими настройками валидаторов, минимальными затратами ресурсов на стороне узла и возможностью масштабирования без перепроектирования по мере роста сети. Этот практический опыт напрямую влияет на выбор архитектуры и инструментов этой платформы.

Подробная архитектура, включая конкретные определения метрик, потоки данных и спецификации экспортеров, будет документироваться отдельно и будет развиваться по мере развития платформы.

6. Объем и результаты

7. Бюджет и график платежей

Резюме

График платежей

Контактное лицо по передаче прав: https://github.com/rwxr-xr-x/gonka-usdt-vesting-schedule

Каждый транш выплачивается в первый день соответствующего периода.

Первый транш больше, поскольку он покрывает создание инфраструктуры и наиболее трудоемкий этап проекта.

Риски

• Низкое внедрение валидаторов — INC4 будет активно поддерживать адаптацию и демонстрировать ценность платформы через первых пользователей.

• Рост затрат на инфраструктуру — в бюджете заложен резерв; при необходимости возможен переход на более экономичное решение без прерывания обслуживания.

• Платформа не влияет на сеть Gonka — она работает как совершенно отдельный уровень; любая проблема с платформой не оказывает никакого влияния на валидаторов или консенсус

Бюджет рассчитан на один год. По истечении первого года соглашение может быть пересмотрено и продлено на тех же или измененных условиях. INC4 опубликует прозрачный отчет об использовании, внедрении и затратах платформы в конце периода действия гранта, что даст сообществу четкую основу для решения о продлении. Если сообщество решит не продлевать, полностью настроенная и работоспособная платформа, включая всю инфраструктуру, код и конфигурации, может быть передана основной команде.

8. Критерии успеха

Что дает INC4:

• Базовая версия платформы развернута и принимает метрики — в течение первой недели, с постоянными улучшениями и обновлениями.

• Экспортер, информационная панель автопарка и оповещения доступны в базовой версии — в течение первого месяца, постоянно совершенствуются на протяжении всего периода действия гранта.

• INC4 будет активно помогать валидаторам, желающим подключиться, предоставляя практическую поддержку наряду с документацией в репозиториях GitHub.

• Весь код, конфигурации и информационные панели опубликованы в общедоступных репозиториях GitHub — открыты для просмотра, аудита и внесения вклада всеми желающими.

Что зависит от сообщества:

• INC4 будет активно поддерживать адаптацию, но не может гарантировать уровень внедрения, поскольку участие является добровольным.

• Цель — широкое внедрение в сети в течение первого года.

Сценарий Sunshine: подключение к платформе становится стандартной частью настройки каждого валидатора

Ключевые показатели эффективности:

• Доступность платформы: время безотказной работы более 99 % на протяжении всего периода действия гранта.

• Совместимость: платформа проверена и работоспособна в течение 48 часов после каждого обновления сети Gonka.

• Регистрация: любой валидатор может подключиться к платформе менее чем за 30 минут, используя предоставленную документацию.

• Отчетность: ежеквартальные отчеты о ходе работы публикуются для сообщества.

• Внедрение: широкое внедрение в сети в течение первого года.

9. Команда

• Сайт: https://inc4.net.

Гитхаб: https://github.com/inc4

INC4 является активным участником экосистемы Gonka. Мы используем валидаторы в основной и тестовой сети, а также разрабатываем приложения для сети Gonka. Это предложение вытекает из нашего непосредственного опыта — мы, как операторы валидаторов, сталкиваемся с отсутствием общесетевой прозрачности и хотим решить эту проблему для всей сети.

INC4 участвует во многих инициативах экосистемы Gonka, одна из которых — платформа наблюдения. Например, мы также разрабатываем NOP (Node Onboarding Package) — утилиту с открытым исходным кодом для быстрого развертывания валидатора ( https://github.com/inc4/gonka-nop ). Наша приверженность сети носит долгосрочный характер и не ограничивается этим предложением.

Как компания, INC4 была основана в 2013 году, в ее состав вошли более 70 инженеров и более 230 реализованных проектов в области инфраструктуры блокчейнов и систем искусственного интеллекта. Практический опыт создания и обслуживания инфраструктуры майнинга Bitcoin, Ethereum, Filecoin.

Платформа наблюдения за узлами Gonka

Предложение от INC4 | 16 апреля 2026 г.

Запрос финансирования: $96,000 USD (USDT) на 12 месяцев

Содержание

Резюме (#1-%D1%80%D0%B5%D0%B7%D1%8E%D0%BC%D0%B5)

• Описание проблемы (#2-%D0%BE%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D1%8B)

• Отраслевой контекст (#3-%D0%BA%D0%BE%D0%BD%D1%82%D0%B5%D0%BA%D1%81%D1%82-%D0%B8%D0%BD%D0%B4%D1%83%D1%81%D1%82%D1%80%D0%B8%D0%B8)

• Предлагаемое решение (#4-%D0%BF%D1%80%D0%B5%D0%B4%D0%BB%D0%B0%D0%B3%D0%B0%D0%B5%D0%BC%D0%BE%D0%B5-%D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D0%B5)

• Технический подход (#5-%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9-%D0%BF%D0%BE%D0%B4%D1%85%D0%BE%D0%B4)

Объем и результаты (#6-scope-%D0%B8-результаты)

• Бюджет и график платежей (#7-%D0%B1%D1%8E%D0%B4%D0%B6%D0%B5%D1%82-%D0%B8-%D0%B3%D1%80% D0%B0%D1%84%D0%B8%D0%BA-%D0%B2%D1%8B%D0%BF%D0%BB%D0%B0%D1%82)

Критерии успеха (#8-%D0%BA%D1%80%D0%B8%D1%82%D0%B5%D1%80%D0%B8%D0%B8-%D1%83%D1%81%D0%BF%D0%B5%D1%85%D0%B0)

Команда (#9-%D0%BA%D0%BE%D0%BC%D0%B0%D0%BD%D0%B4%D0%B0)

1. Резюме

Существующие эксплореры и дашборды показывают только on-chain данные, оставляя off-chain состояние валидаторов полностью непрозрачным. Немногие операторы, которые всё же мониторят свою инфраструктуру, используют разные инструменты, разные метрики и разные baseline — что приводит к разным интерпретациям и затрудняет координацию при возникновении проблем. У сети нет единого источника правды и общего фреймворка для оценки здоровья валидаторов.

Даже сейчас, просто наблюдая за работой валидаторов, можно заметить, что многие не реагируют на технические проблемы вовремя — растущий Inference Miss Rate, падающий CPoC Ratio, отставание Network Node Sync. Эти паттерны сохраняются, потому что у операторов нет возможности увидеть ранние предупреждающие сигналы или получить экстренные алерты внутри собственной инфраструктуры.

Для решения этой проблемы INC4 — активный оператор валидаторов Gonka с практическим опытом в блокчейн-инфраструктуре и наблюдаемости — предлагает создать Gonka Node Observability Platform — open-source стек мониторинга с добровольным участием, который агрегирует off-chain метрики от Network-нод и ML-нод в общий, публично доступный дашборд. Платформа разворачивается на независимой облачной инфраструктуре — без использования ресурсов конкретных валидаторов и без предоставления кому-либо привилегированного доступа — чтобы все операторы имели равный доступ к данным и равную видимость.

Для Core Team — единое представление всей сети, видимость проблемных нод и временных периодов, данные для обоснованных решений по протоколу, SLA-отчёты и возможность оценить масштаб сетевых проблем до и после обновлений. Для Отдельных Валидаторов — алерты в реальном времени, сравнение производительности со средними по сети, добровольный обмен логами для помощи в диагностике и интерпретации метрик, и не нужно строить собственный стек мониторинга.

Обнаружение и предотвращение даже одного крупного общесетевого инцидента или серии более мелких инцидентов у отдельных валидаторов может сэкономить экосистеме значительно больше, чем годовая стоимость этой платформы. Главными выгодополучателями станут сами операторы валидаторов, которые несут прямые издержки от каждой пропущенной эпохи и каждого часа недиагностированного простоя — особенно индивидуальные хосты без выделенных DevOps-специалистов, для которых создание и поддержка сопоставимого стека мониторинга своими силами попросту нереализуемы.

Мы запрашиваем $96,000 в USDT на 12 месяцев с выплатой квартальными траншами для развёртывания и поддержки production-grade платформы — кастомные Gonka-экспортёры, общесетевые и индивидуальные дашборды, добровольная агрегация логов, внешние проверки доступности эндпоинтов, алертинг и SLA-отчётность, практический онбординг валидаторов, поддержка реагирования на инциденты и постоянная операционная поддержка. Весь код, конфигурации и дашборды будут open-source и опубликованы в публичных GitHub-репозиториях.

2. Описание проблемы

Off-chain состояние сети не видно

Gonka — растущая сеть с более чем сотней валидаторов, ещё большим количеством ML-нод и суммарным парком GPU, превышающим 3,000 карт. Существующие блокчейн-эксплореры и дашборды показывают on-chain данные — высоту блоков, транзакции, voting power. Но нет ни одного инструмента для наблюдения за off-chain состоянием сети: здоровье GPU, статус контейнеров, корневые причины miss rate, время загрузки моделей, метрики производительности LLM, тренды инфраструктуры и т.д. Каждый оператор мониторит свою инфраструктуру в изоляции — или не мониторит вообще. Те, кто мониторят, настраивают собственные инструменты, считают метрики по-разному и используют разные baseline — что приводит к недопониманию и путанице при обсуждении сетевых проблем.

В частности, существующие инструменты не показывают:

Почему у валидатора высокий miss rate

Исчерпана ли RAM или память GPU

Перезапускаются ли ML или другие контейнеры в цикле

Сколько времени занимает загрузка модели после рестарта

Доступен ли PUBLIC_URL извне

Сравнительную производительность между валидаторами

На практике валидаторы сталкивались с длительными периодами высокого miss rate или простоя инференса, не имея возможности определить причину. При этом у Core Team не было способа увидеть масштаб таких проблем по всей сети. Такие ситуации приводят к потере наград для операторов и замедленной реакции команды — проблемы, которые общая платформа мониторинга помогла бы обнаружить и решить значительно быстрее.

Что происходит без решения

Тихие отказы остаются незамеченными часами или днями — валидаторы теряют эпохи и награды

Нет общей базы для отладки — каждый оператор использует разные инструменты, разные baseline, разные определения «нормы»

У Core Team нет общей картины сети — сложнее диагностировать сетевые проблемы и планировать обновления

Новые операторы предоставлены сами себе — высокий порог входа для мелких хостов без DevOps-экспертизы

3. Контекст индустрии

Сбор метрик с валидаторов в единое место — не новая идея

Агрегация телеметрии и метрик от валидаторов в общий backend — устоявшаяся практика в блокчейн-индустрии. Множество крупных сетей уже это делают:

• Solana — валидаторы отправляют метрики в общий backend; сеть публикует публичный Grafana-дашборд на https://metrics.solana.com:3000

• Polkadot — ноды отправляют телеметрию по умолчанию в общий backend; публичный дашборд в реальном времени доступен на https://telemetry.polkadot.io

• Kusama — использует ту же систему Substrate Telemetry, что и Polkadot, с собственным представлением на https://telemetry.polkadot.io/#list/Kusama

• NEAR — каждая нода поставляется с дефолтным telemetry endpoint ( telemetry.nearone.org ) и отправляет данные каждые 10 секунд

• Aptos — все ноды отправляют метрики в централизованный telemetry-сервис ( telemetry.mainnet.aptoslabs.com ) по умолчанию; архитектура задокументирована в публичной SPEC

• Celestia — поддерживает OpenTelemetry collector endpoint ( otel.celestia.observer ) для DA-нод, плюс Prometheus-based observability stack для consensus-нод

Это не экзотическая идея. Именно так зрелые блокчейны получают видимость здоровья своей сети, быстрее диагностируют проблемы и принимают решения об обновлениях протокола на основе данных.

Во многих блокчейн-сетях телеметрия с нод собирается без полного ведома операторов — телеметрия часто включена по умолчанию в софте ноды, а в некоторых случаях у операторов вообще нет возможности её отключить.

В отличие от этого, Gonka Node Observability Platform спроектирована как полностью opt-in система — валидаторы сами решают, участвовать ли, и никакие данные не собираются без их явного действия.

Чем больше валидаторов подключится, тем точнее и полнее будет картина здоровья сети. Платформа с 30% подключённых валидаторов даёт полезные инсайты; платформа с 80% становится надёжным источником правды для всей экосистемы.

4. Предлагаемое решение

Платформа наблюдения за узлами Gonka

Managed open-source стек мониторинга, куда операторы валидаторов добровольно отправляют off-chain метрики на общую платформу, поддерживаемую INC4.

Принципы дизайна

Создаваемая ценность

Для основной команды:

Агрегированные метрики и логи всей сети в одном месте

Мгновенная видимость проблемных нод, эпох и временных периодов

SLA-отчёты и принятие решений об обновлениях протокола на основе данных

Поддержка реагирования на инциденты с анализом корневых причин

Для валидаторов:

Не нужно строить и поддерживать собственный стек мониторинга

Сравнение производительности своей ноды со средними показателями сети

Получение алертов через Telegram или Discord при проблемах

Возможность делиться логами для совместной диагностики при возникновении проблем

Доступ к дашбордам с любого устройства, включая мобильный

Практическая помощь в интерпретации метрик и диагностике инцидентов

Для сообщества:

Единый источник правды для метрик здоровья сети

Согласованные данные, на которые все участники могут ссылаться в обсуждениях

Прозрачность сетевых операций

5. Технический подход

Платформа будет развёрнута на распределённой облачной инфраструктуре, что обеспечивает:

Высокую доступность — отсутствие единой точки отказа; резервная инфраструктура с SLA 99.5%+ uptime

• Автоматическое масштабирование — платформа бесшовно растёт по мере подключения новых валидаторов, без ручного вмешательства

• Push-based сбор данных — валидаторы отправляют метрики наружу через HTTPS; никаких новых входящих портов не требуется, существующие конфигурации firewall полностью сохраняются

Мы будем использовать хорошо зарекомендовавшие себя, проверенные индустрией инструменты для мониторинга: Prometheus для сбора метрик, Grafana для дашбордов и визуализации, Alertmanager для уведомлений, Promtail/Loki для унифицированной добровольной агрегации логов и PagerDuty для управления инцидентами и эскалации дежурств.

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

Детальная архитектура, включая конкретные определения метрик, потоки данных и спецификации экспортёров, будет задокументирована отдельно и будет эволюционировать по мере развития платформы.

6. Scope и Deliverables

7. Бюджет и график выплат

Сводка

График выплат

Каждый транш выплачивается первого числа соответствующего периода.

Первый транш больше, так как покрывает развёртывание инфраструктуры и наиболее интенсивную фазу разработки проекта.

Риски

• Низкое подключение валидаторов — INC4 будет активно поддерживать онбординг и демонстрировать ценность платформы через первых участников

• Рост стоимости инфраструктуры — бюджет включает резерв; при необходимости возможна миграция на более экономичное решение без прерывания сервиса

• Платформа не влияет на работу сети Gonka — она работает как полностью отдельный слой; любая проблема платформы имеет нулевое влияние на валидаторов и консенсус

Бюджет рассчитан на один год. После первого года условия могут быть пересмотрены и продлены на тех же или скорректированных условиях. INC4 опубликует прозрачный отчёт об использовании платформы, adoption и расходах по итогам грантового периода — давая сообществу чёткую основу для решения о продлении. Если сообщество решит не продлевать, полностью настроенная и работающая платформа — включая всю инфраструктуру, код и конфигурации — может быть передана сообществу или Core Team.

8. Критерии успеха

Что поставляет INC4:

• Базовая версия платформы развёрнута и принимает метрики — в течение первой недели, с непрерывными улучшениями и обновлениями в дальнейшем

• Экспортёр, общесетевой дашборд и алертинг доступны в базовой версии — в течение первого месяца, с непрерывным улучшением на протяжении всего грантового периода

• INC4 будет активно помогать валидаторам, желающим подключиться — обеспечивая практическую поддержку онбординга наряду с документацией в GitHub-репозиториях

• Весь код, конфигурации и дашборды опубликованы в публичных GitHub-репозиториях — открыты для просмотра, аудита и контрибуций от любого желающего

Что зависит от сообщества:

INC4 будет активно поддерживать онбординг, но не может гарантировать уровень adoption, так как участие добровольное

Цель: широкое adoption по сети в течение первого года

Sunshine-сценарий: подключение к платформе становится неотъемлемой частью настройки каждого валидатора

Ключевые показатели эффективности:

Доступность платформы: 99%+ uptime на протяжении всего грантового периода

Совместимость: платформа проверена и работоспособна в течение 48 часов после каждого обновления сети Gonka

Онбординг: любой валидатор может подключиться к платформе менее чем за 30 минут, используя предоставленную документацию

Отчётность: квартальные отчёты о прогрессе, публикуемые для сообщества

Adoption: широкое adoption по сети в течение первого года

9. Команда

• Сайт: https://inc4.net.

Гитхаб: https://github.com/inc4

INC4 — активный участник экосистемы Gonka. Мы эксплуатируем валидаторы на mainnet и testnet, разрабатываем приложения для сети Gonka. Этот proposal вырос из нашего прямого опыта — мы сами столкнулись с отсутствием общесетевой видимости как операторы валидаторов и хотим решить эту проблему для всей сети.

INC4 вовлечён в несколько инициатив в экосистеме Gonka — платформа наблюдаемости лишь одна из них. Например, мы также разрабатываем NOP (Node Onboarding Package) — утилиту с открытым исходным кодом для быстрого запуска валидаторов ( https://github.com/inc4/gonka-nop ). Наше участие в сети — долгосрочное и не ограничивается данным proposal.

Как компания, INC4 основана в 2013 году, 70+ инженеров и 230+ реализованных проектов в блокчейн-инфраструктуре и AI-системах. Практический опыт в создании и поддержке майнинг-инфраструктуры для Bitcoin, Ethereum, Filecoin.

Привет, ребята, у меня уже был опыт работы с вами, и в любом случае я искренне желаю вам успехов и надеюсь, что вы останетесь с Gonka.

Могу ли я спросить, можно ли будет отменить какой-либо из будущих траншей, если планы впоследствии изменятся?

Контракт о передаче прав: https://github.com/rwxr-xr-x/gonka-usdt-vesting-schedule

Вопросы по предложению:

• Он ориентирован на оффчейн-метрики (которые уже предложены сообществом и по этому вопросу есть PR (https://github.com/gonka-ai/gonka/pull/1046)), но в сети есть некоторые проблемы, когда валидаторы могут перестать работать. И для выявления проблемы необходимы подробные метрики даже внутри слоев CosmosSDK, поскольку сокращение базы данных, тайм-ауты консенсуса и другие вещи также могут привести к невыявленным проблемам. Почему предложение ориентировано на оффчейн-метрики?

• Возможны DoS-атаки и другие попытки взлома. Почему предложение не охватывает метрики сети и анализ трафика

Как вы собираетесь идентифицировать отправителей и как собираетесь защитить сервер агрегации метрик от спама?

Это очень общий взгляд на предложение, и, похоже, ему не хватает многих технических деталей, которые должны быть отражены в спецификации, прежде чем ее можно будет применить.

Более того, было бы гораздо лучше увидеть первое доказательство концепции.

Идея предложения заключается в создании единой открытой платформы, на которой можно будет агрегировать телеметрию, метрики и журналы. Но да, может быть неочевидно, что показатели, перечисленные в тексте, являются всего лишь примерами. Если бы мы перечислили их все, они бы раздули разделы, в которых их нужно перечислить. Естественно, все предложенные метрики будут добавлены — именно это и подразумевается под созданием пользовательских экспортеров. И добавление новых метрик — это как раз одна из задач, за которую отвечает инженер.

Это сопроводительное письмо к запросу на финансирование. Обычно он включает общий обзор постановки проблемы и предлагаемого решения без слишком подробной информации о бюджете или технической реализации.