Добро пожаловать в Proposals 👋

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

Что сюда относится

Улучшения протокола: значимые обновления базового дизайна протокола и долгосрочного архитектурного направления

Предложения по внешней инфраструктуре: сторонние интеграции, API-клиенты, инструменты и расширения экосистемы

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

Как написать хорошее предложение: сохраняйте структуру предложения и включайте:

Мотивация — конкретная проблема, которую вы решаете

Высокоуровневое решение — ваш архитектурный подход

Дорожная карта реализации — конкретные этапы, если изменение является сложным

Открытые вопросы — известные неизвестные, которые нужно обсудить во время звонка сообщества

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

Сроки реализации и bounty также можно предложить как часть обсуждения.

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

@mtvnastya (https://github.com/mtvnastya) , привет, Настя!

🤗

Спасибо за прекрасную возможность быть частью процесса развития протокола и сообщества; это невероятно ценно!

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

Я рассчитывал это в #859 (https://github.com/gonka-ai/gonka/pull/859) и #860 (https://github.com/gonka-ai/gonka/discussions/860) , но понял, что тесты и mock-данные мало интересны вам без результатов. Я решил сузить свою зону ответственности при реализации идеи до минимума, продемонстрировав стандарт качества в одном конкретном процессе: разработке и патчинге протокола. Я разработал систему, состоящую из нескольких слоев, которые выполняют требования моей конкретной цели: сервер, MCP и среда управления. Чего я достиг? Все мои открытые и смерженные PR являются результатом этой runtime-среды. К моменту выпуска системных патчей я даже не полностью понимал эти патчи; я только перепроверял все 20 раз перед их отправкой. То, что это доказывает на 100%, — это то, что люди уже доказали миллион раз до меня: полезный результат вроде pep-8 должен отражаться, дистиллироваться и переиспользоваться. Стоит отметить, что применение матрицы качества этой системы к моим запросам резко сокращает время подготовки патчей, что напрямую влияет на количество токенов, которые вы потратите на инфраструктуру при повторении ранее рассчитанных шагов, пересчитывая их снова и снова. Здесь мы можем обсудить, как каждый из нас использует LLM, но теперь представьте, что будет, когда мы объединим эти усилия благодаря этой runtime-среде. Мне трудно представить конечный результат, но я легко могу представить, что использование вами этого инструмента гарантирует масштабирование.

Что я предлагаю? Я хотел бы в ближайшем будущем окончательно доработать это для исходного кода и наконец предложенной идеи, чтобы мы могли рассмотреть работу, использовать ее и предложить собственный вектор развития этой системы или ее объединения с существующей. В моем понимании, для применения маски качества к сети оптимально было бы иметь некоторое количество серверов нод, CPU и GPU для поддержки этого экземпляра, обеспечения корректной маршрутизации и повышения качества работы участников. Мы уже сегодня видим некоторые из этих изменений повсюду, но в очень фрагментированном и ограниченном виде. Нам не следует всем одновременно делать одно и то же, и чем раньше мы отойдем от этого и централизуем наши усилия, тем больше качественных результатов мы найдем и тем быстрее это произойдет. Если обычный системный администратор сегодня доказал это, запатчив 1 000 строк полезного кода в ваш протокол, что иногда высоко ценится, то что произойдет, когда мы накопим усилия и знания...? Это была отличная возможность проявить себя, и я за нее благодарен. Теперь, в заключение... Доказательство полезности матрицы качества — лишь часть результатов, которые можно из нее извлечь. А ключ к достижению полного потенциала этих результатов — масштаб. В первую очередь я думал о том, как появление протокола изменит жизнь всех, кого он затронет, и как сделать это воздействие максимально эффективным... Ответ очевиден: производить полезный результат. Проводить исследования и устанавливать стандарт, затем делиться им и обновлять его. Это относится не только к коду, но и к любым результатам, которые мы можем привнести в экосистему Gonka. Больше всего меня интересуют наука и исследования в научной сфере, а именно те, которые позволят обычным людям, не имеющим сегодня к ним доступа, получить его и стать полностью автономными независимо от того, где они находятся.

Технические детали для справки. Как были созданы эти патчи: каждый патч, перечисленный ниже, был обнаружен через структурированный конвейер: RAG индексирует более 52 тыс. фрагментов кода с 5-сигнальным гибридным поиском (семантика + комментарии + AST-символы + ключевые слова + markdown), семантическая mesh-сеть из более чем 205 тыс. слотов инвариантов в 7 доменах выявляет повторяющиеся шаблоны ошибок (доминирующий шаблон: error_swallowed_with_logwarn), а ai-reviewer с более чем 20 специфичными для Gonka персонами (chain_security, calculations, state-modified, consensus) проверяет каждую находку перед отправкой. Из 45 исходных находок при поиске 34 были исключены как ложные срабатывания после проверки на уровне кода, осталось 11 подтвержденных реальных ошибок, сгруппированных в 6 PR-блоков (A-F), все прошли ai-reviewer. Масштабируемость — 3 варианта, основанные на #859 (https://github.com/gonka-ai/gonka/pull/859) / #860 (https://github.com/gonka-ai/gonka/discussions/860) / #878 (https://github.com/gonka-ai/gonka/pull/878) :

• Централизованный hub (как предложено в feat(binary-singularity): семантический кэш, расширяющий #859 #860 #878 (https://github.com/gonka-ai/gonka/pull/878) ): каждая нода протокола запускает экземпляр binary-mesh. Патчи, шаблоны и инварианты дистиллируются в mesh-слоты на каждой ноде. QualityMatrix отслеживает L0-L9 для каждой ноды. Mesh-слоты синхронизируются между нодами — когда одна нода обнаруживает шаблон (например, error_swallowed_with_logwarn), все ноды сразу получают пользу. Это естественная эволюция feat(semantic-cache): конвейер L2 quality gate — адаптивный порог согласованности + замыкание цикла hub [без дополнительного GPU] #859 (https://github.com/gonka-ai/gonka/pull/859) (конвейер L2 quality gate).

• Федеративная mesh-сеть: ноды не передают сырой код — они передают дистиллированные слоты инвариантов (шаблон + исправление + проверка). Каждый слот составляет примерно 500 байт. Mesh-сеть на 205 тыс. слотов составляет примерно 100 МБ. Ноды запрашивают федеративную mesh-сеть перед отправкой PR, устраняя дублирующиеся обнаружения. Это сохраняет проприетарные данные локально, одновременно делясь ценностью.

• API-сервис: централизованно размещать binary-mesh на Host. Команды протоколов отправляют diff'ы PR через webhook. ai-reviewer запускает более 20 персон, результаты публикуются как комментарии к PR. Нулевая стоимость инфраструктуры для команды протокола — мы размещаем, они используют. Именно это мы уже делаем вручную (ai-reviewer для каждого PR-блока перед отправкой). Полная история PR (все созданы конвейером binary-mesh): смержено:

• core: утечка мьютекса txLookupLock при возвратах с ошибкой в reorg() ethereum/go-ethereum#34038 (https://github.com/ethereum/go-ethereum/issues/34038) — утечка мьютекса txLookupLock в reorg()

• core: исправить утечку мьютекса txLookupLock при возвратах с ошибкой в reorg() ethereum/go-ethereum#34039 (https://github.com/ethereum/go-ethereum/pull/34039) — исправить утечку мьютекса txLookupLock при возвратах с ошибкой в reorg() Открыто (ожидает review):

• bls: пробросить контекст вызывающей стороны в BlsManager и добавить таймауты для каждого вызова #909 (https://github.com/gonka-ai/gonka/pull/909) — проброс BLS-контекста + таймауты для каждого вызова

• bls: добавить защиту идемпотентности на уровне эпохи в ProcessKeyGenerationInitiated #910 (https://github.com/gonka-ai/gonka/pull/910) — защита идемпотентности BLS ProcessKeyGenerationInitiated

• fix(keeper): пробросить ошибку InjectParamsIntoContext в обработчике Validation #968 (https://github.com/gonka-ai/gonka/pull/968) / fix(dapi): использовать signal.NotifyContext для graceful shutdown #969 (https://github.com/gonka-ai/gonka/pull/969) / fix(keeper): использовать regexp вместо fmt.Sscanf для разбора ErrInsufficientFunds в ClaimRewards #970 (https://github.com/gonka-ai/gonka/pull/970) — проброс ошибки InjectParams, graceful shutdown, regexp для ErrInsufficientFunds

• fix(subnet): предотвратить потерю средств при распределении неурегулированного escrow #1013 (https://github.com/gonka-ai/gonka/pull/1013) — потеря средств в escrow подсети (ОДОБРЕНО Doog-bot534)

• fix(subnet): добавить защиты от переполнения для всех полей uint32 в SubnetHostEpochStats #1014 (https://github.com/gonka-ai/gonka/pull/1014) / fix(subnet): добавить защиты от переполнения для накопления стоимости при settlement #1015 (https://github.com/gonka-ai/gonka/pull/1015) — защиты от переполнения в SubnetHostEpochStats + settlement

• fix(keeper): добавить защиты от переполнения в цикле распределения лимита предложения bitcoin #1017 (https://github.com/gonka-ai/gonka/pull/1017) — переполнение supply-cap bitcoin

• hardening: пробросить внутренние ошибки по путям inference/validation/pricing #1071 (https://github.com/gonka-ai/gonka/pull/1071) - fix: пробрасывать ошибки хранилища в UpdateDynamicPricing вместо defa… #1076 (https://github.com/gonka-ai/gonka/pull/1076) — 6 подтвержденных блоков ошибок (проброс ошибок, нулевые токены, nil-эпоха, хранилище PoC V2, пересечение PoC claim rewards, dynamic pricing) — все прошли ai-reviewer Закрыто как замененное:

• bug: потенциальная проблема в обработке ошибок ClaimRewards #1016 (https://github.com/gonka-ai/gonka/pull/1016) → Issue bug: обработка ошибок ClaimRewards — путь выплат молча продолжает работу при сбое #1067 (https://github.com/gonka-ai/gonka/issues/1067) (обработка ошибок выплат ClaimRewards)

• core/txpool/blobpool: предотвратить потерю данных в limbo.update при сбое setAndIndex ethereum/go-ethereum#34665 (https://github.com/ethereum/go-ethereum/pull/34665) — проверка допустимости замены pending (открыто) Issue:

• bug: обработка ошибок ClaimRewards — путь выплат молча продолжает работу при сбое #1067 (https://github.com/gonka-ai/gonka/issues/1067) — обработка ошибок ClaimRewards (commit ec5e453 (https://github.com/gonka-ai/gonka/commit/ec5e453e03b0970ce6c4db1ca4243d0843f57989) предшествует исправлению Doog-bot534 fix(claims): предотвратить постоянную потерю средств при сбое выплаты награды #1051 (https://github.com/gonka-ai/gonka/pull/1051) на 10 дней) Фундаментальная работа:

• feat(semantic-cache): конвейер L2 quality gate — адаптивный порог согласованности + замыкание цикла hub [без дополнительного GPU] #859 (https://github.com/gonka-ai/gonka/pull/859) — семантический кэш, конвейер L2 quality gate (смержено)

• feat(binary-singularity): семантический кэш, расширяющий #859 #860 #878 (https://github.com/gonka-ai/gonka/pull/878) — расширение семантического кэша (открыто, ссылается на feat(semantic-cache): конвейер L2 quality gate — адаптивный порог согласованности + замыкание цикла hub [без дополнительного GPU] #859 (https://github.com/gonka-ai/gonka/pull/859) / GiP: Registry оси качества inference — расширение CacheQualityWeight в сторону измеримой полезной работы #860 (https://github.com/gonka-ai/gonka/discussions/860) )

Сводка: время, затраченное на findings, — 12 часов. Сводка: время, затраченное на разработку, — 3 месяца.

Еще раз спасибо за такую прекрасную возможность. Если бы я три месяца назад не увидел Libermans на YouTube, я, вероятно, к этому бы не пришел. Так что идея ваша )) А результат общий. Спасибо, ребята. Надеюсь, вы сочтете мою работу релевантной. Буду рад услышать вашу обратную связь.