Multi-Model PoC

Предложение: мультимодельный PoC

Процедура POC — это краткосрочный тест для сравнения объема вычислительных ресурсов каждого хоста. Один раз в эпоху определяется вес для каждого хоста, который затем используется в качестве консенсусного веса для создания блоков и распределения задач между хостами. Кроме того, существует подтверждение (случайное) POC, которое используется для подтверждения веса, когда сеть недогружена путем вывода (чтобы убедиться, что оборудование все еще там).

Фазы POC:

ГЕНЕРАЦИЯ (блоки по 1-5 мин)

ВАЛИДАЦИЯ (блоки по 2-10 мин)

ФАЗА ВЫВОДА (нет POC, но иногда может быть прервана до POC подтверждения)

Теоретически проверка и вывод могут выполняться параллельно.

Текущая модель безопасности требует >50% общего консенсусного веса сети, чтобы проголосовать за «действительность». Без делегирования злоумышленнику необходимо >50 % общего веса сети, чтобы испортить проверку любого (и всех) хостов.

Часть вознаграждения в стиле биткойнов распределяется пропорционально этому весу. На ранней стадии это основная мотивация, поскольку вывод обходится намного дешевле.

Проблема

Цепочка должна поддерживать несколько моделей.

В настоящее время сеть не может поддерживать несколько моделей, поскольку у нас есть PoC для одной модели.

Почему мы не можем поддерживать несколько моделей с помощью PoC для одной модели?

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

Потому что а) мы хотим убедиться, что если нагрузка на сеть низкая - вычисления все еще есть б) до тех пор, пока качество бенчмаркинга оборудования по самому логическому выводу пользователей не будет достаточно высоким. Таким образом, вариант повторного развертывания моделей для PoC vs inference не может быть использован, и нам нужно выяснить, как поддерживать разные модели во время PoC и cPoC.

Предложение

Давайте попробуем построить систему, которая поддерживает несколько моделей одновременно, где процедура POC происходит без повторного развертывания, для каждой модели независимо. Такие разные POC соответствуют совершенно разной вычислительной мощности (по сути, они будут измерять не чистую вычислительную мощность, а то, насколько «оптимальна» конфигурация для конкретного оборудования). Поскольку POC является не только источником веса для распределения задач по конкретной модели, но и способом определения консенсусного веса, нам необходимо определить, как агрегировать веса от разных POC и как проверять результаты каждого POC.

Для агрегирования цепочка должна будет определить, насколько ценен вес каждого POC для цепочки. Коэффициенты, преобразующие вес POC в консенсусный вес, могут быть определены как параметры управления путем прямого голосования. Их можно определить таким образом, что более крупные, мощные и популярные модели будут иметь больший вес. Поскольку новейшее оборудование также оптимизировано для обслуживания моделей высшего уровня (большое количество видеопамяти, быстрое соединение между графическими процессорами, поддержка FP4/FP8 и т. д.), это естественным образом будет стимулировать хосты переключать новые графические процессоры на самые мощные модели, чтобы получить больший вес за доллар. Для роста сети важно сделать обслуживание лучших моделей (которые требуют наиболее оптимизированных графических процессоров) наиболее прибыльными.

Это предложение ставит целью поддерживать одинаковый стиль проверки POC — каждый хост проверяет каждый другой хост (или его вероятностную аналогию для случая слотов). Один из подходов к достижению этой цели — заставить каждый хост участвовать (иметь аппаратное обеспечение) в каждой модели. Но такой подход непрактичен и слишком сильно повысит требования к оборудованию. Чтобы избежать этого, предложение вводит делегирование PoC от хоста к другому хосту, которому он доверяет. Такое делегирование позволяет поддерживать свойство проверки большинством консенсусных полномочий (но наверняка вводит новое предположение о безопасности, подробнее об этом в Приложении A).

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

Предупреждение. В этом предложении предполагается модель проверки O(N^2) (порог веса >50%). Проверка на основе слотов выходит за рамки. Скорее всего, подход на основе слотов будет работать таким же образом, с независимым назначением слотов в каждой группе. Но необходимо дважды проверить, использовать ли $votingPower$ или $consensusWeight$ для хостов в группе.

Условия

Пусть эпоха $S$ текущая. Следующее определяет вычисление веса для эпохи $S+1$ . Предварительное право на участие ( $PreE_{S+1}$ ) определяется $N$ блоков до начала эпохи $S+1$ PoC. В этом разделе $*_S$ обозначает значения из эпохи $S$ и используются в качестве входных данных для эпохи $S+1$. Членство в группе и делегирование оцениваются на уровне предварительного отбора и считаются фиксированными для эпохи.

• $group_i$ — группа моделей для модели $i$ (участниками являются хосты с MLNodes, обслуживающими модель $i$). Сеть поддерживает модели $M$ в цепочке.

$group_i$ — группа моделей для модели $i$ (участниками являются хосты с MLNodes, обслуживающими модель $i$). Сеть поддерживает модели $M$ в цепочке.

• $pocWeight_S(group_i, p)$ — вес хоста $p$ в $group_i$ в эпоху $S$ . Равно количеству одноразовых номеров, вычисленных $p$ в процедуре PoC для этой группы и успешно проверенных. Локальный вес внутри группы.

$pocWeight_S(group_i, p)$ — вес хоста $p$ в $group_i$ в эпоху $S$ . Равно количеству одноразовых номеров, вычисленных $p$ в процедуре PoC для этой группы и успешно проверенных. Локальный вес внутри группы.

• $consensusKoeff_i$ — коэффициент, преобразующий $pocWeight$ в $group_i$ в консенсусный вес. Определяется управлением для каждой модели.

$consensusKoeff_i$ — коэффициент, преобразующий $pocWeight$ в $group_i$ в консенсусный вес. Определяется управлением для каждой модели.

• $consensusWeight_S(p) = \sum_{i: group_i \in E_S} консенсусKoeff_i \times pocWeight_S(group_i, p)$ — (см. Приложение A для защиты ограничения)

$consensusWeight_S(p) = \sum_{i: group_i \in E_S} консенсусKoeff_i \times pocWeight_S(group_i, p)$ — (см. Приложение A для защиты ограничения)

• $members(group_i) = \lbrace p : p \text{ для модели развернут MLNode } i \rbrace$ — хосты с развернутым MLNode для модели

$members(group_i) = \lbrace p : p \text{ для модели развернут MLNode } i \rbrace$ — хосты с развернутым MLNode для модели

• $hosts_S(group_i) = \lbrace p : консенсусВес_S(p) > 0 \text{ и } p \inmembers(group_i) \rbrace$ Члены с ненулевым консенсусным весом. Вес может исходить из любой подходящей группы, не обязательно $group_i$ .

$hosts_S(group_i) = \lbrace p : консенсусВес_S(p) > 0 \text{ и } p \inmembers(group_i)\rbrace$

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

• $PreE_{S+1}$ — набор предварительно подходящих групп для эпохи $S+1$ . Группа $group_i \in PreE_{S+1}$, если выполняются условия 1–3: Модель $i$ одобрена руководством с определенным $consensusKoeff_i$ $\sum_{p \inmembers(group_i)} консенсусВес_S(p) \geq W_{порог} \times \sum_{p} консенсусВес_S(p)$ $|hosts_S(group_i)| \geq V_{min}$

$PreE_{S+1}$ — набор предварительно подходящих групп для эпохи $S+1$ . Группа $group_i \in PreE_{S+1}$, если выполняются условия 1-3:

Модель $i$ одобрена руководством с определенным $consensusKoeff_i$

$\sum_{p \inmembers(group_i)} консенсусВес_S(p) \geq W_{порог} \times \sum_{p} консенсусВес_S(p)$

$|hosts_S(group_i)| \geq V_{min}$

• $E_{S+1}$ — набор допущенных к консенсусу групп для эпохи $S+1$ . Группа $group_i \in E_{S+1}$, если: $group_i \in PreE_{S+1}$ Как минимум $V_{min}$ хосты в группе проходят проверку PoC в эпоху $S+1$ (см. правило проверки ниже).

$E_{S+1}$ — набор допущенных к консенсусу групп для эпохи $S+1$ . Группа $group_i \in E_{S+1}$, если:

$group_i \in PreE_{S+1}$

• По крайней мере $V_{min}$ хосты в группе проходят проверку PoC в эпоху $S+1$ (см. правило проверки ниже).

$W_{threshold}$ — минимальная доля общего консенсусного веса сети, необходимая для допуска группы (параметр управления)

$W_{threshold}$ — минимальная доля общего консенсусного веса сети, необходимая для допуска группы (параметр управления)

$V_{min}$ — минимальное количество хостов с ненулевым консенсусным весом, необходимое в группе (параметр управления)

$V_{min}$ — минимальное количество хостов с ненулевым консенсусным весом, необходимое в группе (параметр управления)

• В настоящее время $group_{Qwen3-235B-FP8}$ является единственной подходящей группой (PoC для одной модели). Это предложение распространяется на несколько групп.

В настоящее время $group_{Qwen3-235B-FP8}$ является единственной подходящей группой (PoC для одной модели). Это предложение распространяется на несколько групп.

• Первоначальная группа ( $group_{Qwen3-235B-FP8}$ ) освобождена от ограничения веса (Приложение A) и обеспечивает базовый консенсусный вес для проверки новых групп.

Первоначальная группа ( $group_{Qwen3-235B-FP8}$ ) освобождена от ограничения веса (Приложение A) и обеспечивает базовый консенсусный вес для проверки новых групп.

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

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

• $delegation_S(group_i, p_{from}, p_{to})$ — консенсусный вес, делегированный от хоста $p_{from}$ хосту $p_{to}$ для проверки в $group_i$ в эпоху $S$ . Хост $p_{from} \notinmembers(group_i)$ ; хост $p_{to} \inmembers(group_i)$ . Делегирование устанавливается до начала эпохи; изменения, произошедшие в течение эпохи, вступают в силу со следующей эпохи.

$delegation_S(group_i, p_{from}, p_{to})$ — консенсусный вес, делегированный от хоста $p_{from}$ хосту $p_{to}$ для проверки в $group_i$ в эпоху $S$ . Хост $p_{from} \notinmembers(group_i)$ ; хост $p_{to} \inmembers(group_i)$ . Делегирование устанавливается до начала эпохи; изменения, произошедшие в течение эпохи, вступают в силу со следующей эпохи.

• $r_{delegation}$ — доля делегатора вознаграждения в стиле биткойн, делящегося с делегатом (параметр управления, например, 1% на каждую группу??)

$r_{delegation}$ — доля делегатора вознаграждения в стиле биткойн, делящегося с делегатом (параметр управления, например, 1% на каждую группу??)

• $r_{refusal}$ — доля вознаграждения в стиле биткойнов, отправляемая управлению, когда хост явно отказывается участвовать в группе; должно быть > $r_{делегирование}$ (параметр управления, например, 5% на каждую группу??)

$r_{refusal}$ — доля вознаграждения в стиле биткойнов, отправляемая управлению, когда хост явно отказывается участвовать в группе; должно быть > $r_{делегирование}$ (параметр управления, например, 5% на каждую группу??)

• $r_{penalty}$ — доля вознаграждения в стиле биткойнов, теряемая, когда хост не может сделать выбор участия для какой-либо группы, одобренной руководством (параметр управления, целевой показатель 100%)

$r_{penalty}$ — доля вознаграждения в стиле биткойнов, теряемая, когда хост не может сделать выбор участия для какой-либо группы, одобренной руководством (параметр управления, целевой показатель 100%)

• $T_{grace}$ — продолжительность льготного окна после одобрения руководства до применения штрафов (параметр управления, например, 3 эпохи)

$T_{grace}$ — длительность льготного окна после одобрения руководства до применения штрафов (параметр управления, например, 3 эпохи)

• $votingPower_S(group_i, p) = консенсусВес_S(p) + \sum_{p_{from}} Delegation_S(group_i, p_{from}, p)$ — общее количество голосов при проверке хоста $p$ в $group_i$. Ограничения делегирования: $delegation_S(group_i, p_{from}, p_{to}) \ge 0$ и для каждого $(group_i, p_{from})$ , $\sum_{p_{to}} Delegation_S(group_i, p_{from}, p_{to}) \le консенсусВеайт_S(p_{from})$ .

$votingPower_S(group_i, p) = консенсусВес_S(p) + \sum_{p_{from}} Delegation_S(group_i, p_{from}, p)$ — общее количество голосов при проверке хоста $p$ в $group_i$

Ограничения делегирования: $delegation_S(group_i, p_{from}, p_{to}) \ge 0$ и для каждого $(group_i, p_{from})$ , $\sum_{p_{to}} Delegation_S(group_i, p_{from}, p_{to}) \le консенсусВеайт_S(p_{from})$ .

Вопрос 1. Может ли хост разделить делегирование между несколькими хостами в одной группе?

Соответствующие группы

Вес, рассчитанный в процедуре PoC для подходящих групп моделей, способствует общему консенсусному весу посредством коэффициента, определяемого руководством. Консенсусный вес определяет:

Блокировать право подписи

Право голоса в управлении

Право голоса при проверке PoC

Распределение вознаграждений в стиле биткойнов (пропорционально консенсусному весу)

Внутри группы запросы на вывод распределяются согласно $pocWeight_S(group_i, p)$ . Награды за умозаключение распределяются таким же образом.

Проверка PoC

Делегирование: хосты, не входящие в группу, могут делегировать свой консенсусный вес тому хосту, который входит в нее. Делегат голосует от своего имени. Делегирование осуществляется для каждой группы и устанавливается до начала эпохи.

Правило проверки: Результат PoC хоста $p$ в подходящей $group_i$ принимается, если:

$$\frac{\sum_{v \text{ голосов действительны для } p} VotingPower_S(group_i, v)}{\sum_{q} консенсусВес_S(q)} > \frac{1}{2}$$

Числитель: сумма $votingPower_S(group_i, v)$ от всех валидаторов $v$, которые одобрили $p$

• Знаменатель: общий консенсусный вес сети (все хосты, все группы).

Хозяева, не входящие в группу и не делегирующие полномочия, фактически голосуют против одобрения. Поэтому делегирование необходимо для любой группы, прямые члены которой владеют менее 50% общего веса сети.

Подробности о голосовании:

• Количество MLNodes не имеет значения: 1 MLNode или 100 MLNodes дают одинаковое количество голосов.

Изменения делегирования вступают в силу со следующей эпохи

Модель доверия: делегат доверяет делегату, который проголосует правильно.

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

Обязательное групповое участие и стимулирование

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

• Присоединяйтесь к группе — развертывайте оборудование и участвуйте непосредственно в группе.

• Делегировать — делегировать право голоса участнику группы; делегатор делится $r_{delegation}$ с делегатом, стимулируя членов группы укреплять доверие

Явный отказ — отказ делегировать полномочия или присоединиться; стоит $r_{отказ}$ ; должен обновляться каждую эпоху

В течение льготного периода (периодов $T_{grace}$ после одобрения руководства) организаторы должны сделать выбор для участия, но за любой выбор штраф не налагается. После окончания льготного периода применяются штрафы: хосты, которые не сделали выбор, теряют $r_{penalty}$ своего вознаграждения в стиле биткойнов.

Это стимулирует более 50% общего консенсусного веса участвовать в проверке PoC для каждой одобренной руководством группы.

Незарегистрированные модели

Любой хост может добавить модель в цепочку и предоставить вывод без одобрения руководства (за дополнительную плату).

Свойства:

Никакой проверки вывода другими хостами

Цена устанавливается непосредственно хозяином

Запросы отправляются непосредственно хосту

• Хост хранит полезную нагрузку локально, но без перекрестной проверки.

• За каждый платеж GNK взимается комиссия, отправляемая руководству.

Никаких наград в стиле биткойнов

Цель: построить демо-кейс для предложения по управлению, чтобы показать спрос на модель.

Жизненный цикл модели

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

• Предложение по управлению — модель одобрена с определенным $consensusKoeff_i$, группа создана.

• Grace window (эпохи $T_{grace}$) — применяются обязательные правила участия, но без штрафов; организаторы делают выбор участия (присоединиться/делегировать/отказаться); PoC работает для группы

• После льготного периода — применяются штрафы ( $r_{penalty}$ , $r_{делегирование}$ , $r_{refusal}$ ); право на участие по-прежнему зависит от условий выполнения ($W_{threshold}$, $V_{min}$, прохождение проверки PoC)

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

Реализация

[Будет определено позднее]

Приложение A. Атака и защита на основе делегирования

Атака: Хост накапливает >50% $votingPower$ посредством делегирования, проверяет поддельного участника, претендующего на большой вес, получает консенсусный контроль.

Вариант защиты: ограничить вес каждой группы подтвержденным весом участников в другом месте.

$$\text{Консенсусный вес от } group_i \leq f \times \sum_{p \inmembers(group_i)} \text{(}p\text{Консенсусный вес от других подходящих групп)}$$

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

Для ясности: «другие подходящие группы» относятся к консенсусному весу, уже полученному от подходящих групп, за исключением самой $group_i$ (т. е. с использованием вкладов $consensusWeight_S$ от $E_S \setminus \lbrace group_i \rbrace$ ), чтобы избежать циклической зависимости.

Освобождение от налога для начальной группы (без ограничения)

$f$ — параметр управления

Делегирование влияет на $votingPower$, но не на ограничение (ограничение основано на весе PoC)

Это ограничивает ущерб от фейковых участников: даже если они пройдут валидацию, их весовой вклад ограничивается реальной долей участников в других группах. Кепка — вторичная защита; валидация (>50% веса сети) остается основной.

Вопрос 5: Каким должен быть $f$?

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

Вопросы

• Когда хост A делегирует свой голос хосту B в другой группе моделей, он добавляет право голоса хосту B. Но почему это не уменьшает количество голосов хоста A?

Когда хост A делегирует свой голос хосту B в другой группе моделей, он добавляет право голоса хосту B. Но почему это не уменьшает количество голосов хоста A?

• Если какой-то хост А доверяет хосту Б, то создается впечатление, что они уже находятся в группе доверия, имеют общение и могут договориться о совместных действиях. Собственно какая разница, если бы это был один хост?

Если какой-то хост А доверяет хосту Б, то создается впечатление, что они уже находятся в группе доверия, имеют общение и могут договориться о совместных действиях. Собственно какая разница, если бы это был один хост?

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

Как участник может выбрать, какому хосту делегировать свой вес? Как это можно практически скоординировать? Было бы более понятно, если бы был реальный пример с пошаговым планом: если есть новая модель и есть новые хосты, которые хотят ее запустить, как им начать? Как они получают делегирование, как хосты из других групп начинают понимать, что им нужно делегировать, и как они могут решить, какому хосту делегировать свой голос?

• Сколько хостов должно запустить модель, чтобы начать групповую работу. Например, если есть только 2 хоста, получат ли они вознаграждение? Если есть 3 хоста? Сформируйте, какому количеству хостов мы можем доверять группе (похоже, это связано с вопросом Q5)

Сколько хостов должно запустить модель, чтобы начать групповую работу. Например, если есть только 2 хоста, получат ли они вознаграждение? Если есть 3 хоста? Сформируйте, какому количеству хостов мы можем доверять группе (похоже, это связано с вопросом Q5)

• Как можно избежать следующего сценария? Начинается новый льготный период. Злоумышленник создает несколько хостов, которые будут участвовать с участниками модели из других групп, поскольку они лично не знают, кому делегировать голосование, делегируйте его «случайному кому-то». Также злоумышленник делегирует свои голоса (от нескольких хостов) своим хостам в новой группе. И злоумышленник получает контроль над группой

Как можно избежать следующего сценария? Начинается новый льготный период. Злоумышленник создает несколько хостов, которые будут участвовать с участниками модели из других групп, поскольку они лично не знают, кому делегировать голосование, делегируйте его «случайному кому-то». Также злоумышленник делегирует свои голоса (от нескольких хостов) своим хостам в новой группе. И злоумышленник получает контроль над группой

• Не проще ли создать новую модельную группу семян (генезиса)? Например, хосты, у которых уже есть право голоса, могут запустить некоторые из своих мультинодов с новой моделью и получить дополнительное вознаграждение за участие в раннем запуске группы новой модели. Они помогают создать новую модельную группу (поскольку у них есть ресурсы и они заинтересованы в развитии сети), поскольку у них уже есть право голоса, но при этом не возникнет всех сложностей (не только технических, но и реально-практических) делегирования.

Не проще ли создать новую модельную группу семян (генезиса)? Например, хосты, у которых уже есть право голоса, могут запустить некоторые из своих мультинодов с новой моделью и получить дополнительное вознаграждение за участие в раннем запуске группы новой модели. Они помогают создать новую модельную группу (поскольку у них есть ресурсы и они заинтересованы в развитии сети), поскольку у них уже есть право голоса, но при этом не возникнет всех сложностей (не только технических, но и реально-практических) делегирования.

п.с. Незарегистрированные модели - очень хороший момент.

Но почему это не уменьшает количество голосов хоста A? Хост A не имеет права голоса в этой модельной группе, его нельзя уменьшить. Хост A может либо иметь MLNode с этой моделью, либо делегировать свою проверку PoC. Важно: это не влияет на консенсусный вес каких-либо хостов.

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

Сколько хостов должно запустить модель, чтобы начать групповую работу. Например, если есть только 2 хоста, получат ли они вознаграждение? Если есть 3 хоста? Сформируйте, какому количеству хостов мы можем доверять группе (похоже, это связано с вопросом Q5). Я не думаю, что какая-либо проверка может произойти при наличии менее трех хостов. Но мы также должны иметь ограничение на общий консенсусный вес участников этой модельной группы. Думаю, не должно быть меньше хотя бы 5-10% сети (если говорить о сегодняшних размерах)

Как можно избежать следующего сценария? С моей точки зрения, это должна быть комбинация ограничений на:

• минимальная сила консенсуса от другой группы, которой должны обладать хосты, чтобы группа имела право на участие (5-10%+)

ограничить вес, который может иметь одна группа (чтобы не получить контроль над всей цепочкой)

Я согласен, что делегирование «случайному кому-то» вызывает серьезную озабоченность, и механизм основан на том факте, что принимающая сторона должна принять обоснованное решение о делегировании. Есть ли у вас какие-то дополнительные идеи, как защититься?

Не проще ли создать новую модельную группу семян (генезиса)? Например, хосты, у которых уже есть право голоса, могут запустить некоторые из своих мультинодов с новой моделью и получить дополнительное вознаграждение за участие в раннем запуске группы новой модели. Они помогают создать новую модельную группу (поскольку у них есть ресурсы и они заинтересованы в развитии сети), поскольку у них уже есть право голоса, но при этом не возникнет всех сложностей (не только технических, но и реально-практических) делегирования.

Я не понимаю, как это поможет избежать делегирования. Вопрос в том, какой консенсусный вес будет иметь такая группа. Если учитывается только их вес, то при текущем ограничении такая начальная группа должна контролировать > 2/3 общей мощности сети, чтобы PoC мог пройти. Что невозможно. Если PoC внутри этой новой группы будет рассчитываться только по весу участников — такие ранние начальные узлы тоже можно легко обмануть.

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

Извините, я использовал в комментарии 2/3 вместо 50%, так как обнаружил, что в основной сети уже используется 2/3 в качестве порога.

Предложение тестировать новые модели без вознаграждения в стиле биткойнов очень сильное.

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

Я надеюсь, что будут приняты соответствующие меры против этого.

Спасибо, что написали об этом — направление высокого уровня (многомодельное PoC без повторного развертывания; веса PoC для каждой модели, агрегированные в консенсусный вес) имеет смысл. Прочитав все предложение + Приложение А, я думаю, что есть несколько пробелов с высоким риском и несколько пунктов, которые необходимо уточнить, прежде чем это станет безопасным/реализуемым.

1) Делегирование переносит полномочия по проверке с «аппаратного обеспечения» на «социальную координацию» (безопасность + работоспособность).

Агрегация взяточничества/делегирования становится самым дешевым вектором атаки

Когда собственные члены новой группы владеют гораздо меньшим глобальным порогом> 50%, делегирование становится единственным практическим способом пройти проверку PoC во время холодного запуска. В этом режиме злоумышленник может получить большинство голосов, подкупив/стимулируя небольшое количество делегаторов с высоким консенсусом, что потенциально намного дешевле, чем предоставление эквивалентного оборудования.

Тупик «холодного старта»/структурное вето со стороны действующих компаний

Поскольку для «действительности» требуется> 50% глобального консенсусного веса, новая модельная группа может застрять, если хосты с большим весом не будут активно делегировать (апатия, затраты на координацию или стратегический отказ). Это фактически дает действующим операторам право вето и делает внедрение новых моделей во многом зависимым от координации вне цепочки.

Задержка отзыва/реакции по-прежнему является задачей TODO.

В предложении упоминается необходимость отзыва делегирования в середине эпохи, но не уточняется, как:

делегаты достаточно быстро обнаруживают неправомерное поведение делегатов (окна PoC составляют минуты),

отзыв вступает в силу в ту же эпоху,

• потери обрабатываются, если обнаружение происходит после окна проверки.

2) Необходимо пояснение: «расходы» делегирования и «репликация».

В текущем определении voicePower(group_i, p) (добавка к делегированным суммам) легко интерпретировать делегирование как добавление веса к делегату без явного «удаления» его из эффективного бюджета делегатора внутри этой группы.

Просьба: пожалуйста, явно определите семантику делегирования как передачу бюджета проверки для конкретной группы (а не репликацию). Конкретно:

• как только p_from делегирует p_to для group_i , теряет ли p_from какое-либо прямое влияние на голосование/проверку в этой группе на эпоху?

• влияет ли делегирование только на групповое голосование по проверке или на вес глобального управления/производства блоков?

Мое предложение таково: делегирование должно быть ограничено только групповой проверкой (без изменений глобального веса производства блоков/управления) и должно моделироваться как бюджет без двойного расходования внутри группы.

Кроме того, пожалуйста, разъясните, что означает «неучастие фактически является отказом от голосования» в математике: учитывается ли воздержание через знаменатель, исключается ли воздержание или просто отсутствует в числителе, в то время как знаменатель остается глобальной суммой?

3) Масштабируемость: проверку O(G · N^2) трудно считать устойчивой.

Сохранение проверки O(N^2) для каждой группы становится O(G·N^2), когда несколько подходящих групп работают параллельно. Даже если пропускная способность в порядке, проверка подписи ЦП, обработка состояния, повторные попытки и восстановление вилки, скорее всего, станут узким местом — особенно в окнах продолжительностью 2–10 минут.

Кроме того, «PoC/проверка и вывод могут выполняться параллельно» требует конкретной истории изоляции ресурсов/приоритетов. Даже при использовании отдельных графических процессоров в группе конкуренция между сетью и ЦП все равно может ухудшить задержку вывода и UX.

Запрос: напишите либо:

конкретный план масштабирования (выборка/пакетирование/квоты), который сохраняет семантику> 50%, или

• почему O(G·N^2) приемлемо при реалистичных целевых показателях N и G.

4) Ограничение (Приложение A) не полностью обеспечивает захват/справедливость на уровне группы.

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

Ограничение также зависит от веса, полученного в других зрелых группах → сильная зависимость от пути/преимущество действующего оператора (новые участники структурно ограничены, даже если они лучше всех работают в новой модели).

Просьба: уточнить, какое ограничение предназначено для смягчения (глобальное поглощение или захват на уровне группы), и рассмотреть дополнительные механизмы для корректности/справедливости на уровне группы (оспорение/апелляция, сокращение, возможность проверки и т. д.).

5) «Независимое оборудование для каждой группы» сегодня выглядит мягким требованием.

Без поддающегося проверке механизма аттестации (TEE/отпечатков оборудования/аттестации поставщика) требование «независимого оборудования для каждой подходящей группы» является технически неисполнимым. Актеры потенциально могут использовать виртуализацию (vGPU) или приемы планирования, чтобы появляться в нескольких группах с одного и того же физического оборудования.

Просьба: следует ли нам рассматривать это как политику максимальных усилий, а не как основу безопасности (и сказать об этом прямо), или ввести некоторую форму регистрации/аттестации/аудита технических характеристик оборудования?

6) Дополнительные направления улучшения (на уровне приложения, но стоит обсудить)

• Проверка выборки на основе слотов/VRF: Учитывая O(G·N^2), рассмотрите выборку валидаторов на основе VRF для каждой группы с количественным анализом безопасности (вероятность отказа в зависимости от веса состязательности, размера выборки).

• Укрепите незарегистрированную фазу в качестве периода наблюдения: используйте реальные сигналы спроса GNK (доходы + отдельные плательщики + ставки споров/возвратов) для ограничения/рекомендации консенсуса Koef вместо чисто управленческого усмотрения (необходимы защитные меры против мошенничества/антисивиллы).

• План аттестации оборудования: даже если он еще не готов, обсудите, может ли аттестация платформы (TEE/SEV/TPM) или аттестация поставщика сократить повторное использование оборудования между группами.

Будем рады помочь уточнить параметры (W_threshold, V_min, T_grace, f) или предложить размеры выборки/математические модели угроз. IMO, элементы критического пути: семантика делегирования + холодный старт/жизнеспособность + план масштабируемости.

Делегирование переносит полномочия проверки с «аппаратного обеспечения» на «социальную координацию» (безопасность + живучесть). Взяточничество/агрегирование делегирования становится самым дешевым вектором атаки.

Честно говоря, не уверен, как это меняет модель безопасности. Существует то же предположение BFT, что> 2/3 хостов честны, в том числе и с точки зрения взяточничества. Если мы предположим, что злоумышленник может подкупить честное сверхбольшинство, тогда он сможет подкупить их и во время проверки PoC без делегирования, я что-то упускаю?

Тупик «холодного старта»/структурное вето со стороны действующих компаний

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

Задержка отзыва/реакции по-прежнему является задачей TODO.

Эпоха сейчас составляет около 24 часов. Я думал о случае, когда в середине эпохи N хост A понимает, что хост B пытается обмануть. А затем он пытается отозвать делегирование, чтобы его вес не использовался при голосовании за веса эпохи N+1. Я предполагаю, что делегирование для всей эпохи N получается во время начала эпохи N. В основном вопрос заключается в том, когда делегировать снимки или разрешать динамические изменения.

Необходимо пояснение: делегирование «расходов» против «репликации» после того, как p_from делегирует p_to для group_i, теряет ли p_from какое-либо прямое влияние на голосование/проверку в этой группе на эпоху?

По моему мнению, p_from должен иметь возможность либо делегировать свой вес в group_i, либо голосовать самостоятельно в group_i. Поэтому, если он делегировал полномочия, он не может голосовать, а также не может иметь MLNode в этой группе. Если p_from решит развернуть MLNode в group_i, он отменит все проверки в group_i.

влияет ли делегирование только на групповое голосование по проверке или на вес глобального управления/производства блоков?

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

Делегирование происходит по ключу (p_from, p_to, model_id), отдельно по каждой модели.

Масштабируемость: проверку O(G · N^2) трудно считать устойчивой.

Просто чтобы уточнить: вопрос в сложности проверки PoC или в самой цепочке? Если о цепочке

Даже если пропускная способность в порядке, проверка подписи ЦП, обработка состояния, повторные попытки и восстановление вилки, скорее всего, станут узким местом — особенно в окнах продолжительностью 2–10 минут.

Само производство цепочек/блоков не зависит от количества модельных групп. Все эти данные используются в одной основной сети. Таким образом, почти нет изменений в повторных попытках, восстановлении вилки и т. д. из-за многомодельного PoC (пара новых полей в существующих транзакциях MsgPoCV2StoreCommit, MsgMLNodeWeightDistribution и MsgSubmitPocValidationsV2).

Если о проверке PoC

В обновлении v0.2.10 появился механизм на основе слотов https://github.com/gonka-ai/gonka/blob/main/proposals/poc/optimize.md. Он позволяет изменить сложность на O(G * N * N_SLOTS) с рекомендуемым N_SLOTS=128.

Механизм можно активировать голосованием по параметрам, без апгрейда.

Существует также случайная выборка артефактов PoC для проверки, этот механизм уже активен.

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

Вы имеете в виду часть?

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

Я думаю, что нет необходимости предъявлять какие-либо реальные требования к конкретному оборудованию. Процедура PoC происходит для всех моделей одновременно. Таким образом, если хост может отправлять артефакты для модели A и модели B в одном и том же PoC, и эти артефакты проверяются другими хостами, он предполагает, что у этого хоста есть оборудование для развертывания обеих моделей. С моей точки зрения, не так уж важно, если одно и то же оборудование представлено в разных группах, поскольку его вычислительная мощность / ресурсы VRAM также будут разделены между группами. Таким образом, от таких действий не будет никакой выгоды, просто участие в обеих группах, что хорошо для безопасности.

Ограничение (Приложение A) не полностью решает проблему группового захвата/справедливости. Ограничение ограничивает влияние новой группы на глобальный консенсусный вес (инфляция/внезапное доминирование), но не останавливает групповой захват, например скоординированное голосование, чтобы признать честных участников недействительными или монополизировать доход от вывода популярной новой модели. Ограничение также зависит от веса, полученного в других зрелых группах → сильная зависимость от пути/преимущество действующего оператора (новые участники структурно ограничены, даже если они лучше всех работают в новой модели). Просьба: уточнить, какое ограничение предназначено для смягчения (глобальное поглощение или захват на уровне группы), и рассмотреть дополнительные механизмы для корректности/справедливости на уровне группы (оспорение/апелляция, сокращение, возможность проверки и т. д.).

Основной механизм ограничения группового доминирования – использование общего консенсусного веса в знаменателе. Итак, если общий вес цепочки равен 1000 (из всех групп), чтобы пройти проверку внутри group_i, хост должен быть одобрен хостами с весом голосования > 666 (в исходном тексте это было 50%, это была моя ошибка, цепочка уже использует 2/3). Итак, подавляющее большинство из всей цепочки подтвердило артефакты PoC / делегировало свои голоса PoC.

Вы имеете в виду какую-то конкретную групповую локальную атаку захвата?

Про TEE есть отдельная ветка, где я полностью согласен с его необходимостью :) #951 (https://github.com/gonka-ai/gonka/discussions/951)

Обзор уровня реализации текущей базы кода

Общее руководство и анализ безопасности, проведенный @jacky6block (https://github.com/jacky6block), надежны. Я рассмотрел текущую реализацию PoC, чтобы выявить конкретные пробелы, которые необходимо устранить в предложении. Они дополняют уже поднятые проблемы делегирования/масштабирования.

1. Хранение веса для каждой модели не поддерживается текущей моделью данных.

MLNodeInfo.poc_weight — это плоский int64 без контекста модели (activeparticipants.proto:58). Родительский EpochGroupData поддерживает подгруппы через sub_group_models ( epoch_group_data.proto:19 ), но состояние подгруппы находится только в памяти — epoch_group.go:111 хранит их в карте [string]*EpochGroup, которая перестраивается во время выполнения и никогда не сохраняется в цепочке.

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

• Расширьте MLNodeInfo полем model_id и сохраните отдельные записи для каждой модели.

• Создайте новую коллекцию в цепочке с ключом (эпоха, model_id, участник) -> poc_weight.

Второй более чистый — он позволяет избежать раздувания ActiveParticipant.ml_nodes[] (который уже повторяется в нескольких горячих путях, таких как model_assignment.go и epoch_group.go:55-78 ) и позволяет независимое сокращение для каждой модели.

2. Спор о параллельном PoC-графическом процессоре недостаточно конкретизирован

В предложении говорится, что «PoC работает одновременно во всех подходящих группах в одну и ту же эпоху». В настоящее время фазы эпохи являются последовательными: ГЕНЕРАЦИЯ -> ПРОВЕРКА -> ВЫВОД (types/params.go:165-183, продолжительность в блоках). Брокер назначает каждый графический процессор ровно одной модели во время PoC ( model_assignment.go ).

С M одновременными PoC:

• Каждому хосту требуются отдельные графические процессоры для каждой модели — это признается («требуется отдельное оборудование для каждой группы»), но у брокера нет механизма для разделения графических процессоров по задачам PoC. StartPoCNodeCommandV2 нацелен на одну модель для каждого узла ( node_worker_commands.go:196-210 ).

• Окно проверки масштабируется с помощью M — WeightCalculator (chainvalidation.go:44-192) обрабатывает проверки последовательно для каждого участника. При использовании моделей M x N задержка проверки растет линейно. Текущее PocValidationDuration = 6 блоков (~ 1 минута) может быть слишком коротким.

• Ухудшение вывода во время PoC — в предложении говорится, что проверка и вывод могут выполняться параллельно, но когда все графические процессоры заняты M параллельными PoC, пропускная способность вывода падает до нуля на этапе PoC.

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

3. Консенсус Коэффа, цикличность управления

В предложении консенсусKoeff_i определяется как параметр управления. Но количество голосов в управлении = вес консенсуса = f(consensusKoeff). Группа, члены которой имеют консенсусный вес большинства, может проголосовать за увеличение своего собственного консенсусаKoeff, что еще больше концентрирует власть.

Ограничение в Приложении A (ограничение веса по весу участников в других группах) частично смягчает это для новых групп, но не касается исходной группы (group_Qwen3-235B-FP8 явно освобождается от ограничения).

Предложение: Ограничить диапазон консенсусаKoeff для каждой модели (например, [0,5, 2,0] относительно базового уровня) и потребовать сверхбольшинства (67%) для изменений, что соответствует порогу BFT, уже используемому для консенсуса.

4. PoC подтверждения не адресован

Предложение охватывает основной PoC, но не упоминает PoC подтверждения (confirmation_poc_v1.go:10-63). cPoC запускается на этапе вывода для проверки наличия оборудования на узлах — это важно для жизнеспособности.

С мультимоделью:

• Должен ли cPoC проверять все модели, которые, по утверждению хоста, они обслуживают? Это умножает нагрузку cPoC на G (количество групп).

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

• Текущий cPoC использует ConfirmationWeight из EpochGroupData ( epoch_group_data.proto:47 ) — одно поле, а не для каждой модели.

Это требует четкого проектирования — cPoC — это защита от хостов, которые передают основной PoC, а затем освобождают оборудование.

5. Распределение вознаграждения за урегулирование между группами

Предложение определяет консенсусWeight(p) = sum(consensusKoeff_i * pocWeight(group_i, p)) для силы консенсуса, но не определяет, как вознаграждения в стиле биткойнов (основной экономический стимул) распределяются между группами.

Текущий расчет ( bitcoin_rewards.go ) распределяет вознаграждения пропорционально глобальному весу с ограничением веса подтверждения. С мультимоделью:

• Объединяются ли вознаграждения глобально и распределяются ли они по совокупному консенсусному весу? Тогда хосты в группах с высоким консенсусом по Коэффу зарабатывают непропорционально.

• Или сначала разделить по группам, а затем распределить внутри группы? Затем нам нужно определить коэффициент разделения (по консенсусу Коэфф? по требованию вывода?).

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

Конкретный путь реализации (предложение)

Учитывая сложность, поэтапное внедрение кажется практичным:

Фаза 1 может осуществляться независимо и полезна даже без делегирования — она позволяет отслеживать вес каждой модели, чего в сети сейчас нет.

Будем рады помочь с обзором реализации или созданием прототипа любой из этих областей.