Continuous PoC
Оригинал: Continuous PoC
Реализация этой идеи напрямую позволит добавить обратно небольшие графические процессоры.
100% загрузка графических процессоров в режиме 24/7 приведет к высокому энергопотреблению, перегрузкам серверов, проблемам с производительностью и т. д., верно?
Несмотря на математическую красоту, это решение имеет серьезный побочный эффект в виде высокого энергопотребления. Это отходит от философии использования большей части вычислительной мощности для вывода. Также существует значительный риск того, что при высокой нагрузке на логический вывод вычислительная мощность для генерации одноразовых номеров может быть очень низкой, что делает согласование вычислений PoC и логического вывода чрезвычайно сложным в долгосрочной перспективе.
Основная проблема — это сценарий, в котором злоумышленник может обойти cPoC и PoC, загрузив модель достаточно быстро и сгенерировав достаточное количество одноразовых номеров в окне генерации.
Давайте рассмотрим некоторые альтернативы. Что касается доказательства вычислений:
- Немедленное начало генерации cPoC. В этом случае генерация nonce начинается в блоке триггера — льготный период не допускается. В этом случае злоумышленник вынужден покрывать время загрузки модели более высокими объемами вычислений (грубое соотношение — 1 / (время окна – время загрузки)). например - если время загрузки модели занимает 50% времени окна генерации, для достижения такого же веса необходимо иметь в два раза больше исходной вычислительной мощности.
- Улучшение - Короткое окно генерации PoC/cPoC. Если предположить, что общее окно генерации близко к времени загрузки модели, то практически невозможно достичь коэффициента подтверждения 50% без наличия онлайн-вычислительных мощностей.
Что касается общего состояния сети (избегая злоупотребления обслуживанием только небольших моделей):
- Ограничение веса на MLNode для определенных моделей. Мы вводим максимальный вес, которого может достичь MLNode. В этом сценарии мы можем ввести жесткий барьер для входа на рынок с конкретными графическими процессорами, что сделает размещение на графических процессорах среднего класса более эффективным и оставит возможности открытыми для моделей высокого класса.
- Выбор модели, принудительный к сети. Первоначальный дизайн включал идею о том, что валидаторы могут обслуживать несколько моделей, и сеть решает, какие валидаторы обслуживают конкретную модель (динамические изменения, вызванные спросом). Этот механизм можно использовать, чтобы гарантировать, что для обслуживания конкретной небольшой модели будет выбран только диапазон MLNodes во всей сети. Это значительно снижает вероятность того, что выбранный валидатор будет заинтересован в манипуляциях с выделенной вычислительной мощностью.
Примечание. Это также имеет отрицательный эффект, поскольку некоторые валидаторы могут быть исключены из сети из-за отсутствия спроса. Однако если модельный ряд превышает пропускную способность сети, это не должно быть проблемой. Кроме того, на самом деле это механизм саморегулирования, когда субсидия на блок становится ниже дохода от обработки выводов.
Предлагаю:
модель распределения вознаграждений RDM
Распределение вознаграждений на основе модели экономики потребления и ежедневного дохода
Вознаграждения распределяются пропорционально фактическому потреблению вычислений различными моделями (например, количеству запросов на вывод, токенам ввода/вывода) и их вкладу в ежедневный доход сети от реальных потребителей.
Распределение происходит не сразу, а через 24 часа на основе фактических показателей (коэффициенты пропусков, использование, доля дохода). Это стимулирует честное поведение, поскольку фиктивные рабочие нагрузки не принесут немедленных выгод. Этот механизм по существу прост в организации и обслуживании. это гарантирует динамичный и справедливый рынок. Распределяемые вознаграждения аналогичны выплаченным вознаграждениям. QWEN3 5 узлов вес/пропорция - 180 тыс. gnk, оплата 24 часа ок, GLM 20 узлов вес/пропорция - 285 тыс. gnk ок. простая, прозрачная и полезная статистика.
Преимущества: Снижает риски от небольших моделей (низкий доход – низкое вознаграждение), все данные уже доступны.
- Жесткое распределение аппаратных графических процессоров по группам на основе ресурсов — от маленьких к маленьким моделям или от более эффективных моделей к более эффективным и т. д.
Описание. Классифицируйте графические процессоры по мощности (VRAM, ядра, флопсы, память, диск и т. д.) и объединяйте их в группы: небольшие графические процессоры (например, <8 ГБ видеопамяти) запускают только небольшие модели (<1 млрд параметров), средние → средние модели, большие → большие модели. Это предотвращает эксплойты, при которых небольшие графические процессоры фальшиво загружают большие модели только для PoC.
Упрощенный PoC: регистрация характеристик графического процессора при присоединении узла (самоотчет + проверка с помощью эталонного nonce). require: реализовать сетевой инструмент для динамического назначения моделей группам в зависимости от спроса. все еще требуется RDM.
- много гибридных моделей, в противном случае имхо не становится более понятным, все трюки для - сложного/короткого PoC/cPoC + окон генерации + ограничений веса + изящества - только усложняют весь процесс и добавляют в разы более сложное кодирование/проверки.
Это предложение тесно связано с предложением о мультимодельном PoC (https://github.com/gonka-ai/gonka/discussions/800) и может рассматриваться как его продолжение.
Проблема
Если мы хотим обслуживать небольшие модели, нам нужно выполнять PoC и через небольшие модели (см. предложение многомодельного PoC).
Но это открывает нам вектор атаки, когда злонамеренный хост может достаточно быстро развернуть небольшую модель, чтобы участвовать как в PoC, так и в cPoC с новыми узлами, которые не участвовали в выводе пользователей. Этот вектор атаки стал причиной перехода на PoCv2 внутри vLLM и выбора для него большой модели (Qwen3-235B-FP8).
Примечание. Если кто-то все еще пытается обмануть и не всегда имеет в своем распоряжении 100 % своих вычислительных ресурсов, то, как правило, сеть может уловить такое поведение из-за увеличения частоты промахов — это работает для больших моделей. Но для того, чтобы эффективно использовать вычисления с развернутыми небольшими моделями, цепочке придется обслуживать огромное количество пользовательских выводов, а накладные расходы на запись их метаданных будут более значительными, что является параллельной инженерной задачей, которую цепочка сейчас решает. Таким образом, на данный момент практически невозможно обнаружить какое-либо злонамеренное поведение участников, обслуживающих небольшие модели, поскольку их уровень ошибок никогда не будет достаточно высоким из-за недостаточного использования вычислительных ресурсов. Эту проблему можно решить, предложив масштабирование вывода (https://github.com/gonka-ai/gonka/discussions/801).
Предложение
Текущая реализация POCv2 имеет довольно искусственное ограничение — графический процессор одновременно выполняет только один тип вычислений: либо логический вывод, либо проверку nonce. Де-факто, внутри это точно такие же вычисления, и они могут выполняться полностью параллельно, если позволяет графический процессор (в одном пакете, с использованием всех оптимизаций движка, таких как динамическое пакетирование).
Если мы избавимся от этого ограничения, не будет необходимости в разных фазах: POC и ВЫВОД. POC может работать параллельно с логическим выводом и проверять все оборудование, которое в данный момент не используется реальными запросами (поддержание уровня использования, чтобы не замедлять запросы пользователей).
Таким образом, по сути, если хост имеет 100 графических процессоров, но в цепочке есть запросы на использование только 0,5 из них, 99,5 будут проверены процедурой POC.
Остается открытым вопрос, как правильно «взвесить», сколько одноразовых номеров должно быть компенсировано конкретными выводами с разной длиной ввода/вывода. Очень важно убедиться, что UX реальных выводов не меняется (сам вывод не замедляется).
Такой непрерывный POC не приведет к значительным накладным расходам, поскольку в цепочке записываются только легкие коммиты. Настоящие артефакты хранятся локально и запрашиваются напрямую. Сама проверка не обязательно должна охватывать 100% блока эпохи, но может быть рандомизированной и вызывать некоторую повторную проверку для вредоносных фрагментов.
Реализация
[будет обсуждено]
Реализация этой идеи напрямую позволит добавить обратно небольшие графические процессоры.
100% загрузка графических процессоров в режиме 24/7 приведет к высокому энергопотреблению, перегрузкам серверов, проблемам с производительностью и т. д., верно?
Несмотря на математическую красоту, это решение имеет серьезный побочный эффект в виде высокого энергопотребления. Это отходит от философии использования большей части вычислительной мощности для вывода. Также существует значительный риск того, что при высокой нагрузке на логический вывод вычислительная мощность для генерации одноразовых номеров может быть очень низкой, что делает согласование вычислений PoC и логического вывода чрезвычайно сложным в долгосрочной перспективе.
Основная проблема — это сценарий, в котором злоумышленник может обойти cPoC и PoC, загрузив модель достаточно быстро и сгенерировав достаточное количество одноразовых номеров в окне генерации.
Давайте рассмотрим некоторые альтернативы. Что касается доказательства вычислений:
- Немедленное начало генерации cPoC. В этом случае генерация nonce начинается в блоке триггера — льготный период не допускается. В этом случае злоумышленник вынужден покрывать время загрузки модели более высокими объемами вычислений (грубое соотношение — 1 / (время окна – время загрузки)). например - если время загрузки модели занимает 50% времени окна генерации, для достижения такого же веса необходимо иметь в два раза больше исходной вычислительной мощности.
- Улучшение - Короткое окно генерации PoC/cPoC. Если предположить, что общее окно генерации близко к времени загрузки модели, то практически невозможно достичь коэффициента подтверждения 50% без наличия онлайн-вычислительных мощностей.
Что касается общего состояния сети (избегая злоупотребления обслуживанием только небольших моделей):
- Ограничение веса на MLNode для определенных моделей. Мы вводим максимальный вес, которого может достичь MLNode. В этом сценарии мы можем ввести жесткий барьер для входа на рынок с конкретными графическими процессорами, что сделает размещение на графических процессорах среднего класса более эффективным и оставит возможности открытыми для моделей высокого класса.
- Выбор модели, принудительный к сети. Первоначальный дизайн включал идею о том, что валидаторы могут обслуживать несколько моделей, и сеть решает, какие валидаторы обслуживают конкретную модель (динамические изменения, вызванные спросом). Этот механизм можно использовать, чтобы гарантировать, что для обслуживания конкретной небольшой модели будет выбран только диапазон MLNodes во всей сети. Это значительно снижает вероятность того, что выбранный валидатор будет заинтересован в манипуляциях с выделенной вычислительной мощностью.
Примечание. Это также имеет отрицательный эффект, поскольку некоторые валидаторы могут быть исключены из сети из-за отсутствия спроса. Однако если модельный ряд превышает пропускную способность сети, это не должно быть проблемой. Кроме того, на самом деле это механизм саморегулирования, когда субсидия на блок становится ниже дохода от обработки выводов.
Предлагаю:
модель распределения вознаграждений RDM
Распределение вознаграждений на основе модели экономики потребления и ежедневного дохода
Вознаграждения распределяются пропорционально фактическому потреблению вычислений различными моделями (например, количеству запросов на вывод, токенам ввода/вывода) и их вкладу в ежедневный доход сети от реальных потребителей.
Распределение происходит не сразу, а через 24 часа на основе фактических показателей (коэффициенты пропусков, использование, доля дохода). Это стимулирует честное поведение, поскольку фиктивные рабочие нагрузки не принесут немедленных выгод. Этот механизм по существу прост в организации и обслуживании. это гарантирует динамичный и справедливый рынок. Распределяемые вознаграждения аналогичны выплаченным вознаграждениям. QWEN3 5 узлов вес/пропорция - 180 тыс. gnk, оплата 24 часа ок, GLM 20 узлов вес/пропорция - 285 тыс. gnk ок. простая, прозрачная и полезная статистика.
Преимущества: Снижает риски от небольших моделей (низкий доход – низкое вознаграждение), все данные уже доступны.
- Жесткое распределение аппаратных графических процессоров по группам на основе ресурсов — от маленьких к маленьким моделям или от более эффективных моделей к более эффективным и т. д.
Описание. Классифицируйте графические процессоры по мощности (VRAM, ядра, флопсы, память, диск и т. д.) и объединяйте их в группы: небольшие графические процессоры (например, <8 ГБ видеопамяти) запускают только небольшие модели (<1 млрд параметров), средние → средние модели, большие → большие модели. Это предотвращает эксплойты, при которых небольшие графические процессоры фальшиво загружают большие модели только для PoC.
Упрощенный PoC: регистрация характеристик графического процессора при присоединении узла (самоотчет + проверка с помощью эталонного nonce). require: реализовать сетевой инструмент для динамического назначения моделей группам в зависимости от спроса. все еще требуется RDM.
- много гибридных моделей, в противном случае имхо не становится более понятным, все трюки для - сложного/короткого PoC/cPoC + окон генерации + ограничений веса + изящества - только усложняют весь процесс и добавляют в разы более сложное кодирование/проверки.
This proposal is closely related to proposal for multi-model PoC (https://github.com/gonka-ai/gonka/discussions/800) and can be seen as it’s continuation.
Problem
If we want to serve small models - we need to do PoCs via small models as well (see proposal multi-model PoC).
But this opens us to an attack vector when a malicious host can deploy a small model quick enough to participate in both PoC and cPoC with new nodes that were not participating in users’ inference. This attack vector was the reason behind switching to PoCv2 inside vLLM and selecting a large model (Qwen3-235B-FP8) for it.
Note: If someone still tries to cheat and doesn’t have 100% of their compute available at all times, in general, the network can catch such behaviour because of increasing miss rate - this works for large models. But in order to significantly utilize compute with deployed small models, the chain would have to serve an enormous amount of user inferences and overhead on recording their metadata would be more significant, which is a parallel engineering challenge the chain is solving now. Thus, for now, it is practically impossible to catch any malicious behaviour of participants serving small models because their miss rate will never be high enough because of the underutilization of compute. This can be solved by proposal for inference scaling (https://github.com/gonka-ai/gonka/discussions/801) .
Proposal
Current implementation of POCv2 has quite an artificial limitation - the GPU executes only one type of computation at a time: either inference or nonce check. De-facto, it’s the exactly same computation internally and can be computed fully parallel if GPU allows (in the same batch, utilizing all engine’s optimizations like dynamic batching)
If we get rid of this limitation, there is no need to have different phases: POC and INFERENCE. POC can work in parallel with inference and verify all the hardware which is not utilized by real requests at the moment (maintaining utilization level not to slow-down user requests).
So, essentially if the host has 100 GPU but chain has requests to utilize only 0.5 of them, 99.5 will be verified by the POC procedure.
There is an open question how to properly “weight” how many nonces should be compensated by particular inferences with different input / output lengths. It’s quite important to make sure that the UX of real inferences doesn’t change (inference itself is not slower).
Such continuous POC would not introduce significant overhead as only lightweight commits are recorded on-chain. The real artifacts are stored locally and requested directly. The validation itself doesn’t have to cover 100% of the epoch block but can be randomized and trigger some-revalidation for malicious fragments.
Implementation
[to be discussed]
Implementation of this idea would directly enable adding back small GPUs.
24/7 100% utilization of GPUs will lead to high power consumption, servers overhead, performance issues etc., right ?
Whilst having mathematical beauty - this solution has a serious adverse effect of high energy consumption. This drives away from the philosophy of devoting most of the compute power to inference. There is also a significant risk that during high inference load, the compute capacity for generating nonces might be very low, thus making the reconciliation of PoC compute vs inference extremely challenging on the long run.
The primary problem is a scenario where a malicious actor can bypass the cPoC and PoC by loading the model fast enough and generating enough nonces within the generation window.
Let’s consider some alternatives. In regards to Proof of Compute:
- Immediate cPoC generation start. In this case nonce generation starts on the trigger block - no grace period is allowed. In this case the malicious actor is forced to cover the load time of the model with higher amounts of compute (rough ratio - 1 / (window time – load time) ). E.g. - if model load time takes 50% of the generation window time, to achieve the same amount of weight it is required to have 2x of the original compute capacity.
- Enhancement - Short PoC / cPoC generation window. If we assume that the overall generation window is close to model load time – it is near to impossible to achieve the confirmation ratio of 50% without having the compute capacity online.
In regards to overall network health (avoiding abuse of serving only small models):
- Weight cap per MLNode for specific models. We introduce a maximum weight that can be achieved by an MLNode. In this scenario we might introduce a hard barrier for entry with specific GPUs, making it more efficient to be hosted on mid-range GPUs, and leave the capacity open for high-end models
- Network enforced model selection. The initial design included the idea that validators can serve multiple models, and it is decided by the network which validators serve the exact model (demand induced dynamic changes). This mechanism can be used to ensure that only a range of MLNodes across the whole network are selected to serve the specific small model. This significantly lowers the chances that a selected validator will be interested in manipulating with allocated compute power.
Note – This also has an adverse effect that some validators might be excluded from the network due to absence of demand. However in case the model range exceeds the network capacity, that should not be an issue. Also - that is actually a self-regulation mechanism once the block subsidy is lower than inference processing revenue.
Suggesting:
reward distribution model RDM
Reward distribution based on model consumption economics and daily revenue
Rewards are distributed proportionally to the actual compute consumption of different models (e.g., the number of inference requests, input/output tokens) and their contribution to network revenue per day from real consumers.
Distribution does not occur immediately, but rather after 24 hours, based on actual metrics (miss rates, utilization, revenue share). This incentivizes honest behavior, as fake workloads will not yield immediate benefits. This mechanism is essentially easy to organize and maintain. it guarantees a dynamic and fair market. The rewards distributed are the same as the rewards paid out. QWEN3 5 nodes weight/proportion - 180k gnk paid 24h ok, GLM 20 nodes weight/proportion - 285k gnk ok. simple, transparent, useful stats.
Advantages: Reduces risks from small models (low income - low rewards), all data is already available
- Hard assignment of HW GPUs to resource - based groups - small to small models, or amd to amd more effective models & etc.
Description: Classify GPUs by power (VRAM, cores, flops, mem, disk & etc ) and lock them into groups: small GPUs (e.g., <8GB VRAM) only run small models (<1B params), medium → medium models, large → large models. This prevents exploits where small GPUs fake-load large models just for PoC.
Simpler PoC: Register GPU specs on node join (self-report + validation via benchmark nonce). require: To implement a network enforcer to dynamically assign models to groups based on demand. still require RDM.
- a lot of hybrid models, imho doesn't make it more clear otherwise, all tricks for - complex/short PoC/cPoC + generation windows + weight caps + grace - only overcomplicate all process & add in times more complex coding/checks.
Это предложение тесно связано с предложением о мультимодельном PoC (https://github.com/gonka-ai/gonka/discussions/800) и может рассматриваться как его продолжение.
Проблема
Если мы хотим обслуживать небольшие модели, нам нужно выполнять PoC и через небольшие модели (см. предложение многомодельного PoC).
Но это открывает нам вектор атаки, когда злонамеренный хост может достаточно быстро развернуть небольшую модель, чтобы участвовать как в PoC, так и в cPoC с новыми узлами, которые не участвовали в выводе пользователей. Этот вектор атаки стал причиной перехода на PoCv2 внутри vLLM и выбора для него большой модели (Qwen3-235B-FP8).
Примечание. Если кто-то все еще пытается обмануть и не всегда имеет в своем распоряжении 100 % своих вычислительных ресурсов, то, как правило, сеть может уловить такое поведение из-за увеличения частоты промахов — это работает для больших моделей. Но для того, чтобы эффективно использовать вычисления с развернутыми небольшими моделями, цепочке придется обслуживать огромное количество пользовательских выводов, а накладные расходы на запись их метаданных будут более значительными, что является параллельной инженерной задачей, которую цепочка сейчас решает. Таким образом, на данный момент практически невозможно обнаружить какое-либо злонамеренное поведение участников, обслуживающих небольшие модели, поскольку их уровень ошибок никогда не будет достаточно высоким из-за недостаточного использования вычислительных ресурсов. Эту проблему можно решить, предложив масштабирование вывода (https://github.com/gonka-ai/gonka/discussions/801).
Предложение
Текущая реализация POCv2 имеет довольно искусственное ограничение — графический процессор одновременно выполняет только один тип вычислений: либо логический вывод, либо проверку nonce. Де-факто, внутри это точно такие же вычисления, и они могут выполняться полностью параллельно, если позволяет графический процессор (в одном пакете, с использованием всех оптимизаций движка, таких как динамическое пакетирование).
Если мы избавимся от этого ограничения, не будет необходимости в разных фазах: POC и ВЫВОД. POC может работать параллельно с логическим выводом и проверять все оборудование, которое в данный момент не используется реальными запросами (поддержание уровня использования, чтобы не замедлять запросы пользователей).
Таким образом, по сути, если хост имеет 100 графических процессоров, но в цепочке есть запросы на использование только 0,5 из них, 99,5 будут проверены процедурой POC.
Остается открытым вопрос, как правильно «взвесить», сколько одноразовых номеров должно быть компенсировано конкретными выводами с разной длиной ввода/вывода. Очень важно убедиться, что UX реальных выводов не меняется (сам вывод не замедляется).
Такой непрерывный POC не приведет к значительным накладным расходам, поскольку в цепочке записываются только легкие коммиты. Настоящие артефакты хранятся локально и запрашиваются напрямую. Сама проверка не обязательно должна охватывать 100% блока эпохи, но может быть рандомизированной и вызывать некоторую повторную проверку для вредоносных фрагментов.
Реализация
[будет обсуждено]