Gonka Protocol Proposals (GiP) :: Переход к открытой архитектуре
По мере масштабирования сети Gonka подход к управлению протоколом и его технической эволюции становится более структурированным. Команда официально анонсировала запуск Gonka Protocol Proposals (GiP) Call.
Это формализованный процесс принятия архитектурных решений, зеркально отражающий принципы открытого технического управления, принятые в крупных сетях (таких как Ethereum и Bitcoin).
1. Что такое GiP Call?
GiP Call — это регулярные технические собрания, посвященные планированию следующих крупных шагов в развитии сети. Это открытый форум, где контрибьюторы и разработчики сообщества могут предлагать, обсуждать и критиковать формальные изменения в протоколе Gonka.
2. Правила (Scope)
Фокус встреч остается строго инженерным. Модерация четко разделяет допустимые и недопустимые темы:
- [ IN SCOPE ] Предложения, которые фундаментально изменяют или улучшают базовый протокол, архитектуру узлов или слои приватности.
- [ OUT OF SCOPE ] Любые инициативы по развитию бизнеса, маркетингу, партнерствам, а также реализации на уровне приложений (например, проекты вроде «Я создал DEX на Gonka»).
3. Главная инициатива: Scaling for AI Agents
Ключевым вектором текущего обсуждения стала подготовка архитектуры к полноценной работе с AI-агентами на масштабе (Scaling for AI Agents). Цель — сделать Gonka сопоставимой с классическими провайдерами инференса (поддержка любых моделей, любых юзкейсов и любого количества GPU), сохраняя при этом децентрализацию.
Для решения текущих проблем сети опубликованы три взаимосвязанных предложения:
1️⃣ Inference Scaling (PR #801)
- Problem: В данный момент каждый инференс создает 3 ончейн-транзакции для биллинга, из-за чего сеть начинает с трудом справляться с нагрузкой.
- Solution: Внедрение полностью офчейн-обработки инференса. Пользователи открывают сессию одной ончейн-транзакцией, выполняют все запросы напрямую с подгруппой хостов и производят расчет (settlement) один раз в конце.
- Problem: Поддержка малых моделей (например, embeddings) создает вектор атаки, когда оборудование появляется только для прохождения PoC и исчезает во время реальной работы.
- Solution: Протокол, определяющий, как несколько моделей могут сосуществовать в PoC и cPoC без этой уязвимости. Гарантирует, что хостам не придется переразвертывать (redeploy) модели между фазами.
- Problem: Злонамеренные хосты могут слишком быстро разворачивать малые модели для прохождения PoC/cPoC, не участвуя в реальном инференсе.
- Solution: Внедрение непрерывного PoC, который работает параллельно с пользовательским инференсом, утилизируя остаточные неиспользуемые мощности. Это снимает зависимость безопасности от одной крупной модели (например, Qwen3-235B).
Детальный разбор этой архитектуры и технических шагов уже доступен в специальной ветке Discord.
>_ ACTION REQUIRED: Как подать свой GiP
Первый звонок состоится 2 марта в 9:00 AM PST. Дедлайн для подачи предложений — 28 февраля в 23:59 PST.
Алгоритм внесения изменений в протокол:
- Draft it: Создайте новое обсуждение в GitHub Discussions репозитория Gonka.
- Include: Обязательно укажите историю ваших контрибьюций, мотивацию, высокоуровневое решение проблемы, дорожную карту внедрения (roadmap) и список открытых вопросов.
- Register: Отправьте ссылку на ваше обсуждение в GitHub в соответствующий тред Discord вместе с кратким описанием.
Изучайте предложения на GitHub, задавайте вопросы и делитесь фидбеком
>_ HARDWARE LAYER: Поддержка инфраструктуры
Развитие протокола невозможно без физического масштабирования сети. Если вы хотите поддержать проект вычислительными мощностями, но не располагаете собственными Enterprise-кластерами (уровня NVIDIA H100), вы можете делегировать ресурсы через коллективные пулы (Compute Pools). Участие в пулах — это прямой вклад в децентрализацию инференса и безопасность сети по модели Proof of Compute 2.0.
Изучить подробности и выбрать оператора пула можно на [ Gonka Nexus ]
⚠ WARNING: THIRD_PARTY_PROTOCOL. DYOR.
Сторонние пулы не управляются командой протокола.
Всегда проводите собственное исследование перед тем, как ALLOCATE_CAPITAL.