10 постов с тегом "Децентрализованные вычисления"

Восемь независимых реализаций за 24 часа. Именно это произошло, когда Ethereum Foundation представил ERC-8004 «Trustless Agents» в августе 2025 года. Для сравнения: ERC-20 — стандарту, который обеспечил бум ICO, — потребовались месяцы для появления первых реализаций. ERC-721, на котором работали CryptoKitties, ждал широкого признания шесть месяцев. ERC-8004 взорвал рынок за одну ночь.

Причина? У ИИ-агентов наконец-то появился способ доверять друг другу, не доверяя никому.

Проблема: ИИ-агенты не могут координироваться​

Рынок ИИ-агентов превысил 7,7 млрд долларов по рыночной капитализации токенов, а ежедневный объем торгов приближается к 1,7 млрд долларов. Согласно прогнозам генерального директора Bitget Грейси Чен, этот сектор может достичь 60 млрд долларов к концу 2025 года. Но есть фундаментальная проблема: эти агенты работают в изоляции.

Когда ИИ-агенту для трейдинга нужен аудит кода, как ему найти надежного агента-аудитора? Когда оптимизатор DeFi хочет нанять специализированного стратега по доходности, как ему убедиться, что этот стратег не украдет его средства? До сих пор ответом были централизованные посредники, что сводит на нет саму цель децентрализованных систем.

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

ERC-8004 решает эту проблему, создавая бездоверительный слой координации непосредственно на Ethereum.

Архитектура: три реестра, один уровень доверия​

ERC-8004 вводит три облегченных ончейн-реестра, которые служат основой для взаимодействия автономных агентов. Соавторами стандарта стали Марко Де Росси из MetaMask, Давиде Крапис из Ethereum Foundation, Джордан Эллис из Google и Эрик Реппель из Coinbase — коалиция, представляющая инфраструктуру кошельков, разработку протоколов, облачные вычисления и биржевые операции.

Реестр идентификации (Identity Registry) присваивает каждому агенту уникальную ончейн-личность с использованием стандарта ERC-721. Каждый агент получает переносимый, устойчивый к цензуре идентификатор, который сопоставляется с его доменом и Ethereum-адресом. Это создает глобальное пространство имен для автономных агентов — своего рода DNS для экономики машин.

Реестр репутации (Reputation Registry) предоставляет стандартный интерфейс для публикации и получения сигналов обратной связи. Вместо хранения сложных репутационных баллов ончейн (что было бы дорого и негибко), реестр управляет авторизацией отзывов между агентами. Баллы варьируются от 0 до 100, с дополнительными тегами и ссылками на подробные офчейн-отзывы. Протокол поддерживает доказательства оплаты x402 для проверки того, что отзывы могут оставлять только платящие клиенты, что предотвращает спам и фальшивые отзывы.

Реестр валидации (Validation Registry) предоставляет механизмы для запроса и записи независимых проверок валидаторов через криптоэкономические механизмы стейкинга. Если агент заявляет, что может оптимизировать доходность, валидаторы могут внести токены в стейкинг, чтобы подтвердить это заявление, и получить вознаграждение за точные оценки или столкнуться со слешингом за ложные.

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

Как агенты будут использовать это на практике​

Представьте себе такой сценарий: агент по управлению портфелем, удерживающий 10 млн долларов в DeFi-позициях, должен провести ребалансировку в трех протоколах. Он запрашивает в Реестре идентификации специализированных агентов по стратегиям, фильтрует их по репутационным баллам из Реестра репутации и в конечном итоге выбирает агента с более чем 500 положительными отзывами и показателем доверия 94/100.

Перед тем как делегировать капитал, портфельный агент запрашивает независимую валидацию. Три агента-валидатора, каждый из которых внес в стейкинг по 50 000 долларов, повторно выполняют предложенную стратегию в симуляции. Все трое подтверждают ожидаемые результаты. Только после этого портфельный агент авторизует транзакцию.

Весь этот процесс — поиск, проверка репутации, валидация и авторизация — происходит за считанные секунды, без участия человека и без какого-либо централизованного координатора.

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

• Аудит кода: Агенты безопасности могут создавать проверяемую историю обнаруженных уязвимостей с валидацией от других аудиторов, которые ставят свои средства на подтверждение их выводов.
• Управление DAO: Агенты предложений могут демонстрировать историю успешного участия в управлении, где репутация взвешивается по результатам предыдущих голосований.
• ИИ в здравоохранении: Агенты медицинской диагностики могут поддерживать учетные данные, сохраняющие конфиденциальность и подтвержденные уполномоченными медицинскими учреждениями.
• Децентрализованные маркетплейсы: Сервисные агенты могут накапливать кросс-платформенную репутацию, которая следует за ними независимо от того, на каком маркетплейсе они работают.

Ставка Ethereum Foundation на ИИ​

Ethereum Foundation не оставляет успех ERC-8004 на волю случая. В августе 2025 года она создала команду dAI специально для продвижения стандарта и создания вспомогательной инфраструктуры. Команда под руководством ведущего разработчика Давиде Краписа преследует две приоритетные цели: предоставить ИИ-агентам возможность платить и координировать действия без посредников, а также создать децентрализованный стек ИИ, который позволит избежать зависимости от небольшого числа крупных компаний.

Это стратегическая ставка на то, что Ethereum может стать уровнем координации для машинной экономики — не просто уровнем расчетов для транзакций между людьми. В течение 24 часов после релиза ERC-8004 в социальных сетях появилось более 10 000 спонтанных упоминаний.

Выбор времени не случаен. Протокол NEAR позиционирует себя как «блокчейн для ИИ», разрабатывая такие фреймворки, как Shade Agents, которые позволяют автономным ботам работать в разных сетях, сохраняя конфиденциальность данных. Solana активно развивает инфраструктуру для агентов через различные интеграции с DeFi. Конкуренция за право стать базовым уровнем экономики ИИ обостряется.

Преимущество Ethereum заключается в сетевых эффектах: крупнейшая экосистема разработчиков, самая глубокая ликвидность и широчайшая совместимость со смарт-контрактами. ERC-8004 нацелен на то, чтобы превратить эти преимущества в доминирование в сфере координации агентов.

Связь с x402: Как агенты платят друг другу​

ERC-8004 существует не изолированно. Он разработан для интеграции с x402 — протоколом HTTP-платежей, который Coinbase и ее партнеры разработали для обеспечения микроплатежей между машинами (M2M). Эта комбинация создает полноценный стек для экономики агентов.

x402 возрождает давно не использовавшийся код состояния HTTP 402 «Payment Required». Когда агент запрашивает услугу, поставщик может ответить условиями оплаты. Запрашивающий агент автоматически согласовывает и проводит платеж — в стейблкоинах, ETH или других токенах — без участия человека.

Протокол платежей агентов Google (AP2), разработанный совместно с Coinbase, расширяет эти возможности. Анонсированный в ходе консультаций с более чем 60 компаниями, включая Salesforce, American Express и Etsy, AP2 предоставляет инфраструктуру безопасности и доверия для платежей на базе агентов. Расширение A2A x402 специально ориентировано на готовые к промышленному использованию криптоплатежи между агентами.

Open-source проект Agent-8004-x402 демонстрирует, как эти стандарты сочетаются. Торговый агент может находить контрагентов через Реестр идентификации ERC-8004, проверять их репутацию, запрашивать валидацию их стратегий, а затем проводить расчеты по сделкам через x402 — и все это автономно.

Что может пойти не так​

Стандарт не лишен рисков. Уязвимости в системе безопасности приватных ключей агентов или смарт-контрактов могут стать катастрофическими. Баг в Реестре идентификации может позволить выдавать себя за другого агента. Ошибка в Реестре репутации может сделать возможными манипуляции с рейтингом. Механизм стейкинга в Реестре валидации может быть использован скоординированными злоумышленниками.

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

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

Ethereum Foundation осознает эти опасения. Стандарт включает положения о снижении репутации со временем (чтобы неактивные агенты не сохраняли завышенные баллы), ротации валидаторов (чтобы ни одна группа валидаторов не доминировала) и механизмы восстановления личности (чтобы компрометация ключей не уничтожала идентификаторы агентов навсегда).

Возможность на 47 миллиардов долларов​

Мировой рынок ИИ-агентов в 2024 году достиг 5,1 млрд долларов США, и, по прогнозам, к 2030 году он составит 47,1 млрд долларов США. Token Metrics прогнозирует, что к концу 2025 года на долю умных ИИ-агентов может приходиться 15-20% объема транзакций в DeFi, что выведет протоколы с интеграцией ИИ на уровень TVL (общая заблокированная стоимость) в 200-300 млрд долларов США к концу 2026 года.

Ожидается, что потребление газа (gas) контрактами на идентификацию и исполнение агентов будет расти на 30-40% ежеквартально после широкого внедрения таких стандартов, как ERC-8004. Это создает петлю обратной связи: больше агентов означает больше координации, больше координации означает больше активности в сети, а большая активность означает более высокий доход сети.

Для Ethereum ERC-8004 представляет собой одновременно и возможность, и необходимость. Если агенты станут значимыми экономическими субъектами — а все признаки указывают на это — тот блокчейн, который захватит их уровень координации, получит огромную долю машинной экономики.

Что дальше​

ERC-8004 все еще находится на стадии рассмотрения, но внедрение уже началось. Эксперименты проводятся в основной сети Ethereum и сетях уровня 2 (Layer-2), таких как Taiko и Base. В январе 2026 года несколько крипто- и ИИ-платформ начали обсуждать ERC-8004 как ключевой строительный блок для рынков агентов.

Стандарт может быть включен в хардфорки Ethereum 2026 года — возможно, Glamsterdam (Гламстердам) или Hegota (Хегота). Полная интеграция будет означать нативную поддержку идентификации, репутации и валидации агентов на уровне протокола.

Восемь реализаций за 24 часа не были случайностью. Это был сигнал о том, что рынок ждал эту инфраструктуру. ИИ-агенты существуют. У них есть капитал. Им нужно координировать действия. ERC-8004 дает им способ делать это, не доверяя никому, кроме математики.

---

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

В январе 2025 года сооснователь Farcaster Дэн Ромеро сделал поразительное признание: «Мы 4,5 года пытались ставить социальную составляющую на первое место, но это не сработало». Платформа, которая когда-то достигла 80 000 ежедневно активных пользователей и привлекла $ 180 млн, полностью сменила вектор с социальных сетей на кошельки.

Тем временем Lens Protocol только что завершил одну из крупнейших миграций данных в истории блокчейна, перенеся 650 000 профилей пользователей и 125 ГБ данных социального графа в собственную сеть второго уровня (Layer 2). Два протокола. Две радикально разные ставки на будущее децентрализованных социальных сетей. И рынок объемом $ 10 млрд, ожидающий ответа на вопрос, кто же окажется прав.

Согласно данным Chainalysis, сектор SocialFi вырос на 300 % в годовом исчислении, достигнув $ 5 млрд в 2025 году. Но за впечатляющими цифрами скрывается более сложная история технических компромиссов, проблем с удержанием пользователей и фундаментального вопроса: смогут ли децентрализованные социальные сети когда-либо конкурировать с гигантами Web2.

Web3 обещал дать пользователям право владения их социальными графами. Спустя пять лет это обещание проверяется на прочность двумя протоколами, которые используют радикально разные подходы к одной и той же проблеме: Farcaster с его оценкой в 1 млрд долларов и 60 000 активных пользователей в день, и Lens Protocol, недавно запустивший собственную сеть на базе ZK с новым финансированием в размере 31 млн долларов.

Ставки невероятно высоки. По прогнозам, рынок децентрализованных социальных сетей вырастет с 18,5 млрд долларов в 2025 году до 141,6 млрд долларов к 2035 году. Токены SocialFi уже имеют рыночную капитализацию в 2,4 млрд долларов. Тот, кто выиграет эту битву, не просто захватит социальные медиа — он захватит слой идентификации для самого Web3.

Но есть и неудобная правда: ни один из протоколов еще не достиг массового внедрения. Farcaster достиг пика в 80 000 активных пользователей в месяц, прежде чем их число упало до менее чем 20 000 к концу 2025 года. У Lens мощная инфраструктура, но он с трудом привлекает внимание потребителей, которого заслуживает его технология.

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

Что если бы вы могли выполнять инференс ИИ на своих самых конфиденциальных медицинских записях, а ИИ при этом никогда бы не «видел» данные, которые он обрабатывает? Это не научная фантастика — это основное обещание слепых вычислений (blind computing), и проект Nillion привлек 50 миллионов долларов от таких инвесторов, как Hack VC, HashKey Capital и Distributed Global, чтобы сделать этот метод стандартом обработки конфиденциальной информации в интернете.

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

Визуальные эффекты в сериале «Мир Дикого Запада» обходятся HBO примерно в 10 миллионов долларов за серию. Один фильм Marvel может поглотить 200 миллионов долларов на работу над VFX . И где-то в Лос-Анджелесе стартап под названием OTOY нашел способ сократить эти расходы на 70 % — а затем пошел дальше, создав децентрализованную сеть GPU , которая сегодня обеспечивает работу как голливудских блокбастеров, так и революции в сфере ИИ .

Render Network незаметно отрендерила более 65 миллионов кадров, сожгла 530 000 токенов только в 2025 году (рост на 279 % по сравнению с 2024 годом) и теперь обрабатывает задачи логического вывода ИИ ( AI inference ), на которые приходится 40 % ее вычислительных мощностей. То, что начиналось как инструмент для 3D-художников, превратилось в нечто гораздо более амбициозное: децентрализованную альтернативу AWS и Google Cloud для эпохи ИИ .

Когда президент Трамп объявил о проекте Stargate стоимостью $500 миллиардов в январе 2025 года — крупнейшей разовой инвестиции в инфраструктуру ИИ в истории — большинство криптоинвесторов просто пожали плечами. Централизованные дата-центры. Партнерства с Big Tech. Ничего интересного.

Они совершенно упустили суть.

Stargate — это не просто строительство инфраструктуры ИИ. Это формирование кривой спроса, которая сделает децентрализованные вычисления ИИ не просто жизнеспособными, а необходимыми. В то время как гиперскейлеры пытаются развернуть 10 гигаватт вычислительных мощностей к 2029 году, параллельная сеть из более чем 435 000 GPU-контейнеров уже работает, предлагая те же услуги на 86% дешевле.

Конвергенция ИИ и крипто — это не просто нарратив. Это рынок объемом $33 миллиарда, который удваивается, пока вы читаете эти строки.

Когда Mysten Labs объявила в марте 2025 года, что её протокол Walrus привлек $140 млн от Standard Crypto, a16z и Franklin Templeton, это стало четким сигналом: войны за децентрализованное хранение данных вступают в новую фазу. Но в ландшафте, уже населенном амбициями Filecoin по работе с предприятиями и обещаниями Arweave о вечном хранении, что делает Walrus настолько уникальным, чтобы оправдать оценку в $2 млрд еще до первого дня работы?

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

Проблема хранения, которую никто не решил​

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

Filecoin, крупнейший игрок с рыночной капитализацией, которая значительно колебалась на протяжении 2025 года, требует от пользователей заключения сделок на хранение с провайдерами. Когда срок действия этих сделок истекает, ваши данные могут исчезнуть. Использование сети в третьем квартале 2025 года достигло 36 % — это улучшение по сравнению с 32 % в предыдущем квартале, но всё еще оставляет вопросы об эффективности при масштабировании.

Arweave предлагает вечное хранение по модели «плати один раз, храни вечно», но эта долговечность имеет свою цену. Хранение данных на Arweave может стоить в 20 раз дороже, чем на Filecoin при эквивалентной емкости. Для приложений, обрабатывающих терабайты пользовательских данных, такая экономика просто не работает.

IPFS, тем временем, на самом деле не является хранилищем — это протокол. Без сервисов «пининга» (pinning) для поддержания жизни ваших данных, контент исчезает, когда узлы удаляют его из кэша. Это похоже на строительство дома на фундаменте, который может решить переехать в другое место.

В этот фрагментированный ландшафт вступает Walrus, и его секретное оружие — это математика.

RedStuff: Инженерный прорыв​

В основе Walrus лежит RedStuff — протокол двумерного стирающего кодирования (erasure coding), который представляет собой подлинную инновацию в инженерии распределенных систем. Чтобы понять, почему это важно, рассмотрим, как традиционное децентрализованное хранение справляется с избыточностью.

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

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

RedStuff решает эту проблему с помощью матричного кодирования, которое создает как первичные, так и вторичные «слайверы» (slivers). При сбое узла оставшиеся узлы могут восстановить недостающие данные, загрузив только то, что было потеряно, а не весь блоб целиком. Пропускная способность восстановления масштабируется как O(|blob|/n), а не O(|blob|), и эта разница становится колоссальной при масштабировании.

Протокол достигает безопасности при репликации всего в 4,5 раза, по сравнению с 10–30-кратной репликацией, необходимой при наивных подходах. Согласно собственному анализу команды Walrus, это приводит к снижению затрат на хранение примерно на 80 % по сравнению с Filecoin и до 99 % по сравнению с Arweave при эквивалентной доступности данных.

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

Вотум доверия на $140 миллионов​

Раунд финансирования, завершившийся в марте 2025 года, говорит сам за себя. Лидером выступил Standard Crypto, при участии криптоподразделения a16z, Electric Capital и Franklin Templeton Digital Assets. Участие Franklin Templeton особенно примечательно — когда один из крупнейших в мире управляющих активами поддерживает блокчейн-инфраструктуру, это сигнализирует об институциональной уверенности, выходящей за рамки типичных венчурных сделок в криптосфере.

Токенсейл оценил общее предложение токенов WAL в $2 млрд при полной эмиссии (FDV). Для контекста: Filecoin — с годами работы и сложившейся экосистемой — торгуется с рыночной капитализацией, которая демонстрировала значительную волатильность, резко упав в октябре 2025 года перед восстановлением. Рынок делает ставку на то, что технические преимущества Walrus трансформируются в значимое внедрение.

Токеномика WAL отражает уроки, извлеченные из предыдущих проектов. Общий объем предложения в 5 миллиардов включает 10 % на стимулы для пользователей, с первоначальным аирдропом в 4 % и 6 %, зарезервированными для будущих распределений. Дефляционные механизмы наказывают за краткосрочную смену стейка частичным сжиганием, а штрафы (слэшинг) для плохо работающих узлов хранения защищают целостность сети.

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

Реальные успехи​

С момента запуска основной сети 27 марта 2025 года Walrus привлек более 120 проектов и разместил 11 веб-сайтов, полностью работающих на децентрализованной инфраструктуре. Это не просто «vaporware» — это реальное использование в продакшене.

Decrypt, известное Web3-издание, уже начало хранить контент на Walrus. TradePort, крупнейший NFT-маркетплейс в сети Sui, использует протокол для динамических метаданных NFT, что позволяет создавать компонуемые и обновляемые цифровые активы, которые были невозможны при использовании статических решений для хранения.

Варианты использования выходят за рамки простого хранения файлов. Walrus может служить недорогим уровнем доступности данных (data availability layer) для роллапов, где секвенсоры загружают транзакции, а исполнителям нужно лишь временно реконструировать их для обработки. Это позиционирует Walrus как важную инфраструктуру для тезиса о модульных блокчейнах, который доминирует в разработке в последнее время.

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

Ландшафт «войн хранилищ»​

Walrus выходит на рынок, объем которого, по прогнозам Fundamental Business Insights, к 2034 году достигнет 6,53 млрд $, при ежегодном росте более чем на 21 %. Этот рост обусловлен растущей обеспокоенностью по поводу конфиденциальности данных, увеличением киберугроз и регуляторным давлением, подталкивающим организации к поиску альтернатив централизованным облачным хранилищам.

Конкурентное позиционирование выглядит благоприятным. Filecoin ориентируется на корпоративные рабочие нагрузки с помощью своей модели на основе сделок. Arweave занимает нишу постоянного хранения архивов, юридических документов и культурного наследия. Storj предлагает S3-совместимое объектное хранилище с фиксированной ценой (0,004 $ за ГБ в месяц по состоянию на начало 2025 года).

Walrus находит свою нишу в высокодоступном и экономически эффективном хранении, которое связывает ончейн- и оффчейн-миры. Его интеграция с Sui обеспечивает естественный поток разработчиков, но уровень хранения технически независим от блокчейна (chain-agnostic) — приложения, созданные на Ethereum, Solana или в других сетях, могут подключаться к нему для оффчейн-хранения.

Общий адресный рынок децентрализованных хранилищ остается лишь малой частью более широкой индустрии облачных хранилищ, которая в 2025 году оценивается в 255 млрд $и, по прогнозам, достигнет 774 млрд$ к 2032 году. Даже захват небольшого процента этой миграции будет означать колоссальный рост.

Глубокое погружение в техническую архитектуру​

Архитектура Walrus отделяет управление и метаданные (работающие на Sui) от самого уровня хранения. Это разделение позволяет протоколу использовать быструю финализацию Sui для координации, сохраняя при этом агностицизм уровня хранения.

Когда пользователь сохраняет блоб (blob), данные проходят кодирование RedStuff, разделяясь на фрагменты (slivers), распределяемые по узлам хранения для данной эпохи. Каждый узел обязуется хранить и предоставлять назначенные фрагменты. Экономические стимулы выстраиваются через стейкинг — узлы должны вносить залог, который может быть подвергнут слэшингу за низкую производительность или недоступность данных.

Устойчивость данных исключительна: Walrus может восстановить информацию, даже если две трети узлов хранения выйдут из строя или станут враждебными. Эта византийская отказоустойчивость (Byzantine fault tolerance) превосходит требования большинства производственных систем.

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

Что может пойти не так​

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

Конкуренция со стороны существующих игроков: Filecoin имеет многолетний опыт развития экосистемы и корпоративные связи. Arweave обладает узнаваемостью бренда в нише постоянного хранения. Вытеснение устоявшихся игроков требует не только лучших технологий, но и лучшей дистрибуции.

Зависимость от Sui: Хотя уровень хранения технически независим от чейна, тесная интеграция с Sui означает, что судьба Walrus частично связана с успехом этой экосистемы. Если Sui не удастся добиться массового внедрения, Walrus потеряет свой основной канал привлечения разработчиков.

Токеномика на практике: Дефляционные механизмы и штрафы за стейкинг хорошо выглядят на бумаге, но реальное поведение участников рынка часто расходится с теоретическими моделями. Разблокировка токенов инвесторов в марте 2026 года станет первым серьезным испытанием для стабильности цены WAL.

Регуляторная неопределенность: Децентрализованное хранение находится в «серой зоне» регулирования в различных юрисдикциях. Остается неясным, как власти будут относиться к уровням доступности данных — особенно к тем, которые потенциально могут хранить конфиденциальный контент.

Вердикт​

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

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

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

---

Строите на Sui или изучаете решения для децентрализованного хранения данных для вашего Web3-приложения? BlockEden.xyz предоставляет RPC-инфраструктуру корпоративного уровня и API-сервисы, которые легко интегрируются с развивающимися экосистемами. Изучите наш маркетплейс API, чтобы обеспечить ваш следующий проект инфраструктурой, созданной для децентрализованного будущего.

JAM (Join-Accumulate Machine) Chain от Polkadot представляет собой наиболее значительную инновацию в архитектуре блокчейна со времен запуска Ethereum, фундаментально переосмысливающую работу децентрализованных вычислений. Представленная доктором Гэвином Вудом в документе JAM Gray Paper в апреле 2024 года, JAM превращает Polkadot из релейной цепи, ориентированной на парачейны, в универсальный, не требующий разрешений «почти когерентный бездоверительный суперкомпьютер», способный обеспечить в 42 раза большую доступность данных (850 МБ/с) и теоретическую пропускную способность более 3,4 миллиона TPS. Протокол решает проблему постоянного разделения, преследующую современные блокчейн-системы, обеспечивая синхронную компонуемость в динамических границах шардов при сохранении параллельного выполнения на более чем 350 ядрах. В отличие от L2-ориентированной стратегии роллапов Ethereum или модели суверенных зон Cosmos, JAM встраивает шардированное выполнение с когерентным состоянием непосредственно в уровень консенсуса, используя новую виртуальную машину Polkadot (PVM) на базе RISC-V и бестранзакционную архитектуру, где все вычисления проходят через конвейер Refine→Accumulate. С 43 командами разработчиков, соревнующимися за призы в размере 10 миллионов DOT, несколькими клиентами, достигшими 100% соответствия к августу 2025 года, и развертыванием основной сети, запланированным на начало 2026 года, JAM призвана реализовать то, что обещала первоначальная концепция Ethereum 2.0: нативное масштабируемое выполнение без ущерба для компонуемости или безопасности.

Вычислительная модель: как процессы JAM работают в масштабе​

JAM представляет принципиально новую вычислительную парадигму под названием CoreJAM (Collect, Refine, Join, Accumulate), которая разбивает выполнение блокчейна на отдельные фазы, оптимизированные для распараллеливания и эффективности. Название JAM происходит от ончейн-частей — Join и Accumulate, в то время как Collect и Refine происходят офчейн. Эта архитектура устанавливает две основные среды выполнения, которые работают согласованно: внутриядерное выполнение для тяжелых параллельных вычислений и ончейн-выполнение для интеграции состояний.

На стадии Refine (внутриядерное выполнение) рабочие элементы подвергаются безстатусной параллельной обработке на нескольких ядрах валидаторов, при этом каждое ядро обрабатывает до 15 МБ входных данных за 6-секундный временной интервал и выдает сжатые выходные данные размером не более 90 КБ — замечательный коэффициент сжатия 166x. Эта стадия обеспечивает 6 секунд времени выполнения PVM на ядро, что в три раза превышает 2-секундный лимит текущих функций валидации парачейнов Polkadot (PVF). Функция Refine выполняет основную вычислительную работу полностью офчейн, при этом единственной операцией с состоянием является поиск прообраза, что обеспечивает массовое распараллеливание без конфликтов состояний.

После уточнения, стадия Accumulate (ончейн-выполнение) интегрирует результаты работы в состояние цепи посредством операций с состоянием, ограниченных примерно 10 миллисекундами на выход. Эта функция выполняется на всех валидаторах и может считывать хранилище из любого сервиса, записывать в собственное хранилище ключ-значение, переводить средства между сервисами, создавать новые сервисы, обновлять код и запрашивать доступность прообраза. Резкий контраст в бюджетах выполнения — 6 секунд офчейн против 10 миллисекунд ончейн — отражает фундаментальное понимание JAM: вынося дорогостоящие вычисления офчейн и распараллеливая их, система резервирует драгоценное ончейн-время только для существенных переходов состояний.

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

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

Архитектурная трансформация от релейной цепи к сервисно-ориентированным вычислениям​

JAM фундаментально переосмысливает архитектуру Polkadot, переходя от высокоспециализированного, парачейн-ориентированного дизайна к минималистичному, универсальному вычислительному субстрату. Текущая релейная цепь Polkadot закрепляет парачейны непосредственно в протоколе с жестким ограничением примерно в 50 слотов, требует доступа на основе аукционов, стоящих миллионы DOT, и выполняет всю логику парачейна через фиксированные пути валидации. JAM заменяет это сервисами — не требующими разрешений, инкапсулированными средами выполнения, которые любой может развернуть без одобрения управления или аукционов, ограниченными только криптоэкономическими факторами (депозиты DOT).

Философский сдвиг в архитектуре глубок: от обновляемой релейной цепи к фиксированному протоколу с обновляемыми сервисами. Если Polkadot 1.0 поддерживал высокообновляемую релейную цепь, которая со временем накапливала сложность, то JAM фиксирует основные параметры протокола (кодирование заголовка блока, схемы хеширования, сетевой протокол QUIC, параметры времени) для агрессивной оптимизации и упрощения множественных реализаций. Функциональность на уровне приложений, включая стейкинг, управление и распределение кортайма, находится в сервисах, которые могут обновляться независимо, не затрагивая основной протокол. Эта необновляемая архитектура цепи значительно снижает сложность, сохраняя гибкость там, где это наиболее важно — на уровне приложений.

Парачейны становятся одним из многих типов сервисов в модели JAM. Вся функциональность парачейнов Polkadot 1.1 будет консолидирована в единый сервис «Parachains» или «CoreChains», обеспечивая полную обратную совместимость с жестко закодированными гарантиями. Существующие парачейны автоматически переходят на работу поверх JAM при обновлении релейной цепи, не требуя изменений в коде. Модель сервисов обобщает возможности парачейнов в произвольные шаблоны выполнения: смарт-контракты, развернутые непосредственно на ядрах, акторные фреймворки, такие как CorePlay, ZK-роллапы, сервисы доступности данных и совершенно новые, еще не придуманные модели выполнения.

Модель управления состоянием также значительно трансформируется. Текущий Polkadot использует постфактумные корни состояния в заголовках блоков — блоки ждут завершения полного вычисления перед распределением. JAM использует предварительные корни состояния, которые отстают на один блок, что позволяет конвейеризацию: легкие вычисления (примерно 5% рабочей нагрузки) выполняются немедленно, блок распределяется до завершения тяжелых задач накопления, и следующий блок начинает обработку до завершения выполнения текущего блока. Этот архитектурный выбор означает, что JAM использует полное 6-секундное время блока для вычислений, достигая от 3 до 3,5 секунд эффективного времени вычисления на блок по сравнению с менее чем 2 секундами в текущем Polkadot.

Переход JAM от WebAssembly к виртуальной машине Polkadot (PVM) на базе RISC-V представляет собой еще один фундаментальный сдвиг. RISC-V, имея всего 47 базовых инструкций, предлагает превосходную детерминированность, исключительную скорость выполнения на обычном оборудовании, легкую трансляцию в x86/x64/ARM, официальную поддержку инструментария LLVM и естественную обработку продолжений со стеком в памяти. Критически важно, что PVM обеспечивает «бесплатное измерение» по сравнению с накладными расходами WebAssembly на измерение, в то время как регистровая архитектура (в отличие от стековой архитектуры WASM) избегает NP-полной проблемы распределения регистров. Это позволяет продолжениям, поддерживающим RISC-V, устанавливать новые стандарты для масштабируемого многоядерного кодирования, позволяя программам приостанавливаться и возобновляться через границы блоков — что крайне важно для асинхронной, распараллеленной архитектуры JAM.

Технические характеристики: целевые показатели производительности и требования к валидаторам​

JAM нацелена на выдающиеся показатели производительности, которые позиционируют ее как скачок поколений в вычислительной мощности блокчейна. Система стремится к доступности данных 850 МБ/с — улучшение в 42 раза по сравнению с обычным Polkadot до улучшений Asynchronous Backing и на порядки превосходящее 1,3 МБ/с Ethereum. Это означает совокупную пропускную способность примерно 2,3 Гбит/с по всем ядрам, при этом каждое ядро обрабатывает 5 МБ входных данных за 6-секундный слот.

Пропускная способность транзакций масштабируется значительно: теоретический максимум более 3,4 миллиона TPS на основе целевого показателя доступности данных 850 МБ/с. Реальные стресс-тесты подтверждают эти прогнозы — Kusama достигла 143 000 TPS при загрузке всего 23% в августе 2025 года, в то время как стресс-тест Polkadot «Spammening» достиг 623 000 TPS в 2024 году. С дополнительными оптимизациями JAM и увеличенным количеством ядер (целевое значение 350 ядер с эластичным масштабированием), порог в 1 миллион+ TPS становится достижимым в производстве.

Вычислительная мощность оценивается в 150 миллиардов газа в секунду при полной работоспособности согласно оценкам Gray Paper, что отражает общее выполнение PVM по всем ядрам. Механизм консенсуса поддерживает 6-секундное время блока с детерминированной финализацией через GRANDPA примерно за 18 секунд (примерно 3 блока). SAFROLE, алгоритм производства блоков JAM на основе SNARK, обеспечивает почти беcфорковую работу за счет анонимного выбора валидаторов с использованием zkSNARKs и RingVRF, при этом билеты служат анонимными входами в производство блоков за две эпохи вперед.

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

• ЦП: минимум 8 физических ядер @ 3,4 ГГц (приоритет производительности однопоточных вычислений)
• ОЗУ: минимум 128 ГБ
• Хранилище: минимум 2 ТБ NVMe SSD (приоритет латентности над пропускной способностью), с постоянным ростом, оцениваемым в 50 ГБ/месяц
• Сеть: минимум 500 Мбит/с симметричное соединение (предпочтительно 1 Гбит/с) для обработки большого количества сервисов и обеспечения контроля перегрузок
• Операционная система: на базе Linux (ядро 5.16 или новее)
• Время безотказной работы: требуется 99%+ для избежания штрафов за слэшинг

Набор валидаторов состоит из 1023 валидаторов — такое же количество, как и в текущем Polkadot — все они получают равные вознаграждения за блоки независимо от поддерживаемой ими доли. Такое равное распределение вознаграждений создает экономические стимулы для распределения доли между валидаторами, а не для ее концентрации у нескольких крупных операторов, способствуя децентрализации. Минимальные требования к доле являются динамическими; исторически для входа в активный набор валидаторов требовалось примерно 1,75 миллиона DOT общей доли (собственная доля плюс номинации), хотя минимальное намерение номинации составляет 250 DOT. 28-дневный период разблокировки остается неизменным по сравнению с текущим Polkadot.

Сетевой уровень JAM переходит на протокол QUIC для прямых двухточечных соединений между всеми 1000+ валидаторами, избегая проблем с исчерпанием сокетов традиционных сетевых стеков. Поскольку JAM фундаментально бестранзакционна (нет мемпула или сплетен), система использует grid-diffusal для широковещания: валидаторы располагаются в логической сетке, и сообщения распространяются по строкам, а затем по столбцам, что значительно снижает требования к пропускной способности по сравнению с полными протоколами сплетен.

Тестовая среда JAM Toaster демонстрирует масштаб инфраструктуры, поддерживающей разработку: 1023 узла с 12 276 ядрами и 16 ТБ ОЗУ, расположенные в Polkadot Palace в Лиссабоне, входят в число 500-1000 крупнейших суперкомпьютеров мира. Эта полномасштабная тестовая инфраструктура устраняет исторические ограничения, когда небольшие тестовые сети не могли имитировать крупномасштабную динамику сети, а производственные сети не имели комплексных возможностей мониторинга.

Экономическая модель: токеномика DOT и ценообразование на основе кортайма​

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

Токеномика претерпела серьезные изменения в 2025 году с принятием Референдума 1710, который установил ограничение предложения DOT в 2,1 миллиарда и график поэтапного снижения инфляции. Ежегодные эмиссии токенов будут сокращаться вдвое каждые два года, начиная с марта 2026 года, создавая модель дефицита, подобную Bitcoin. Текущая годовая инфляция составляет 7,56% (снизилась с первоначальных 10%), прогнозируется, что к 2040 году общее предложение DOT достигнет примерно 1,91 миллиарда по сравнению с 3,4 миллиарда по предыдущей модели. Это дефляционное давление направлено на поддержку долгосрочного накопления стоимости при сохранении достаточных вознаграждений за безопасность сети.

Структура комиссий переходит от аукционов парачейнов к ценообразованию на основе кортайма, заменяя сложный механизм аукционов слотов Polkadot 1.0 гибкими опциями:

Bulk Coretime предоставляет ежемесячные подписки для постоянного доступа к вычислительным ядрам, что позволяет проектам с гарантированной пропускной способностью предсказуемо планировать бюджет. On-Demand Coretime предлагает оплату по мере использования для спорадического использования, значительно снижая барьеры для входа по сравнению с миллионными аукционами слотов парачейнов. Эта гибкая модель кортайма позволяет приобретать вычислительные ресурсы на срок от секунд до лет, оптимизируя эффективность капитала.

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

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

Экономика валидаторов продолжает использовать Nominated Proof-of-Stake (NPoS) Polkadot с равными вознаграждениями за блоки, распределяемыми между всеми активными валидаторами за эпоху, независимо от размера доли. Валидаторы устанавливают свои собственные ставки комиссии, вычитаемые из общих вознаграждений до распределения номинаторам. Источники дохода включают вознаграждения за блоки (основные), бонусы за очки эпохи за активное участие, чаевые от пользователей (100% валидатору) и комиссии от номинаторов. Текущая статистика стейкинга показывает 58% уровень участия с 825,045 миллионами DOT, застейканными среди 600 активных валидаторов.

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

Модель экономической безопасности опирается на экономических валидаторов (ELV) — циничный механизм роллапов, где случайно выбранные валидаторы повторно выполняют работу для проверки корректности. Этот подход оказывается примерно в 4000 раз более экономически эффективным, чем ZK-доказательства, для обеспечения вычислительной корректности, используя проверенную криптоэкономическую модель безопасности Polkadot. При оспаривании результатов работы механизм вынесения решения может приостановить финализацию на срок до 1 часа, пока валидаторы достигают консенсуса, сохраняя гарантии безопасности даже в условиях противодействия.

Статус разработки: реализации, тестовые сети и дорожная карта к основной сети​

По состоянию на октябрь 2025 года разработка JAM достигла критической массы: 43 активные команды разработчиков в пяти языковых категориях соревнуются за призовой фонд в 10 миллионов DOT + 100 000 KSM (оценивается в 60-100 миллионов долларов США). Это беспрецедентное разнообразие разработчиков направлено на распространение опыта за пределы одной команды, обеспечение устойчивости протокола за счет разнообразия клиентов и выявление неоднозначностей спецификации посредством независимых реализаций.

Несколько реализаций достигли 100% соответствия JAM к августу 2025 года, включая JAM DUNA (Go), JamZig (Zig), Jamzilla (Go), JavaJAM (Java), SpaceJam (Rust), Vinwolf (Rust), Jamixir (Elixir) и Boka (Swift). Панель мониторинга соответствия JAM предоставляет бенчмарки производительности в реальном времени, результаты фаззинг-тестирования и сравнения реализаций, что позволяет прозрачно оценивать зрелость каждого клиента. Реализация PolkaJAM от Parity на Rust в настоящее время лидирует по показателям производительности.

JAM Gray Paper прошла несколько редакций: v0.7.0 выпущена 25 июня 2025 года с подробным псевдокодом для выполнения PVM и агрегирующего планировщика, за которой последовала v0.7.1 26 июля 2025 года, включающая отзывы сообщества. Gray Paper имитирует подход Ethereum Yellow Paper, предоставляя формальные математические спецификации, позволяющие создавать несколько независимых реализаций, а не полагаться на одного эталонного клиента.

Активность тестовой сети ускорилась в течение 2025 года: мероприятие JAM Experience Event в Лиссабоне (9-11 мая) ознаменовало крупный публичный запуск тестовой сети, на котором присутствовали международные разработчики. Тестовая сеть Minimum Viable Rollup запущена в июне 2025 года, позволяя разработчикам тестировать базовую функциональность JAM в реальной сетевой среде. Несколько команд разработчиков постоянно запускают частные тестовые сети, а Parity выпустила экспериментальный бинарный файл PolkaJAM, позволяющий разработчикам создавать свои собственные тестовые сети JAM для экспериментов.

Приз для разработчиков JAM структурирует вознаграждения по пяти этапам для каждого пути реализации (валидирующий узел, не-PVM валидирующий узел или легкий узел):

Этап 1 (IMPORTER): 100 000 DOT + 1 000 KSM за прохождение тестов на соответствие переходу состояний и импорт блоков. Прием заявок открылся в июне 2025 года, их рассматривает Polkadot Fellowship. Этап 2 (AUTHORER): Дополнительно 100 000 DOT + 1 000 KSM за полное соответствие, включая производство блоков, сеть и офчейн-компоненты. Этап 3 (HALF-SPEED): 100 000 DOT + 1 000 KSM за достижение производительности уровня Kusama, предоставляя доступ к JAM Toaster для полномасштабного тестирования. Этап 4 (FULL-SPEED): 100 000 DOT + 1 000 KSM за производительность уровня основной сети Polkadot с бесплатным профессиональным внешним аудитом безопасности. Этап 5 (SECURE): Финальные 100 000 DOT + 1 000 KSM за прохождение полных аудитов безопасности без значительных уязвимостей.

Языковое разнообразие охватывает традиционные корпоративные языки (Java, Kotlin, C#, Go в Наборе A), языки с нативной производительностью (C, C++, Rust, Swift, Zig в Наборе B), лаконичные скриптовые языки (Python, JavaScript, TypeScript в Наборе C) и языки, ориентированные на корректность (OCaml, Elixir, Julia, Haskell в Наборе D). Набор Z предлагает максимум 5 000 KSM за реализации на эзотерических языках, таких как Brainfuck или Whitespace, демонстрируя игривый дух сообщества и доказывая ясность спецификации.

График развертывания основной сети следует амбициозному расписанию:

• Конец 2025 года: Окончательные редакции Gray Paper (v0.8.0, v0.9.0, приближение к v1.0), продолжение подачи и рассмотрения заявок на этапы, расширенное участие в тестовой сети.
• 1 квартал 2026 года: Целевое обновление основной сети JAM в сети Polkadot после одобрения управления через референдум OpenGov.
• 2026 год: Развертывание CoreChain Фазы 1, официальная публичная тестовая сеть JAM, полный переход сети Polkadot на архитектуру JAM.

Стратегия развертывания предполагает единое комплексное обновление, а не итеративные инкрементальные изменения, что позволяет точно ограничивать действия после обновления и минимизировать накладные расходы разработчиков от постоянных критических изменений. Этот подход консолидирует все критические изменения в один переход, избегая накопления сложности, которое преследовало эволюцию Polkadot 1.0. Однако одобрение управления остается обязательным — JAM требует прохождения децентрализованного ончейн-управления Polkadot с голосованием держателей токенов DOT. Прецедент почти единогласного одобрения Референдума 682 в мае 2024 года (поддержка более 31 миллиона DOT) предполагает сильную поддержку сообщества, хотя окончательное развертывание основной сети требует отдельного одобрения управления.

Реальные реализации уже появляются. Acala Network анонсировала JAMVerse в августе 2025 года, создавая первую dApp-цепь, нативную для JAM, с клиентом JAM B-класса на Swift (Boka). Их дорожная карта включает миграцию основных сервисов DeFi (Swap, Staking, LDOT) в JAM для операций с задержкой менее блока, разработку адаптера JAM-XCM для сохранения совместимости с парачейнами Substrate и демонстрацию межцепочечных флеш-кредитов, обеспечиваемых синхронной компонуемостью. Unique Network Quartz переходит на внутренние тестовые среды для архитектуры JAM, планирование завершено к октябрю 2025 года.

Влияние на экосистему: обратная совместимость и стратегии миграции​

Дизайн JAM отдает приоритет полной обратной совместимости с существующими парачейнами Polkadot, гарантируя, что переход скорее улучшит, чем нарушит экосистему. Официальная документация подтверждает, что «часть предложения будет включать инструменты и жестко закодированные гарантии совместимости», а Web3 Foundation заверяет, что «парачейны останутся первоклассными гражданами даже после JAM». Когда JAM будет запущен, релейная цепь обновится, и парачейны автоматически станут сервисами, работающими поверх JAM, без необходимости каких-либо изменений в коде.

Сервис парачейнов (альтернативно называемый CoreChains или ChainService) консолидирует всю функциональность парачейнов Polkadot 1.1 в единый сервис JAM. Существующие парачейны на базе Substrate продолжают работать через этот уровень совместимости с функционально неизменным поведением — «Функциональность любого из парачейнов, работающих в настоящее время на Polkadot, не будет затронута». С точки зрения команд парачейнов, «технологический стек не сильно отличается. Они будут продолжать валидироваться валидаторами» с аналогичными рабочими процессами разработки.

Три пути миграции позволяют командам внедрять возможности JAM в своем собственном темпе:

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

Вариант B: Частичная миграция позволяет использовать гибридные подходы, когда команды продолжают работать как традиционный парачейн, развертывая при этом определенную функциональность в качестве нативных сервисов JAM. Например, парачейн DeFi может продолжать свои основные операции без изменений, развертывая сервис ZK-роллапов для функций конфиденциальности или сервис оракулов для ценовых потоков непосредственно на ядрах JAM. Этот постепенный переход позволяет тестировать новые возможности без полной приверженности, сохраняя обратную совместимость при выборочном доступе к расширенным функциям.

Вариант C: Полная миграция включает перестройку с использованием сервисной модели JAM с отдельными точками входа Refine, Accumulate и onTransfer. Этот путь обеспечивает максимальную гибкость — развертывание без разрешений, синхронную компонуемость через Accords, акторные фреймворки CorePlay и прямой доступ к новым моделям выполнения JAM. JAMVerse от Acala является примером такого подхода: создание полной нативной реализации JAM при сохранении работы устаревшего парачейна во время перехода. Полная миграция требует значительных усилий по разработке, но раскрывает весь потенциал JAM.

Инфраструктура поддержки миграции включает инструмент миграции Omicode, упомянутый в документации Acala как обеспечивающий «плавную миграцию в JAM без необходимости модификации логики выполнения» — по-видимому, это уровень совместимости для существующих парачейнов Substrate. Polkadot SDK остается совместимым с JAM, хотя функции валидации парачейнов (PVF) перенацелены с WebAssembly на PVM. Поскольку PVM представляет собой незначительную модификацию RISC-V (уже являющегося официальной целью LLVM), существующие кодовые базы, скомпилированные в WASM, обычно могут быть перекомпилированы в PVM с минимальными изменениями.

Переход от WASM к PVM предлагает несколько преимуществ: бесплатное измерение устраняет накладные расходы на газ во время выполнения, регистровая архитектура избегает NP-полной проблемы распределения регистров, присущей стековой архитектуре WASM, естественная поддержка продолжений позволяет программам приостанавливаться и возобновляться через границы блоков, а исключительная скорость выполнения на обычном оборудовании обеспечивает повышение производительности без изменений инфраструктуры. Паллеты Substrate FRAME продолжают работать в рамках сервисов парачейнов, хотя измерительная система JAM часто устраняет необходимость в частых бенчмарках, которые обременяли разработку Substrate.

Эволюция XCM (формата межконсенсусных сообщений) обеспечивает интероперабельность на протяжении всего перехода. Полный XCMP (передача межцепочечных сообщений) становится обязательным в JAM — если текущий HRMP (горизонтальная передача сообщений через релейную цепь) хранит все данные сообщений в релейной цепи с ограничением полезной нагрузки в 4 КБ, то XCMP JAM размещает только заголовки сообщений ончейн с неограниченной передачей офчейн-данных. Это архитектурное требование вытекает из строгих ограничений на передачу данных между стадиями Refine и Accumulate, что позволяет использовать реалистичные полезные нагрузки данных без узких мест релейной цепи.

Адаптеры JAM-XCM поддерживают интероперабельность между сервисами JAM и парачейнами Substrate в течение переходного периода. Улучшения XCM v5, выпущенные в 2025 году, включают многоходовые транзакции, многоцепочечные платежи за комиссии, меньшее количество требуемых подписей и лучшую защиту от ошибок — все это разработано для бесперебойной работы при переходе от Polkadot к JAM. Accords вводят синхронные возможности XCM, позволяющие взаимодействовать с минимальным доверием, например, прямую телепортацию токенов между цепями без посредников на основе резервов.

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

Переход валидаторов остается простым — операторам потребуется запускать клиенты, совместимые с JAM, а не текущие клиенты Polkadot, но обязанности валидаторов по производству блоков, валидации транзакций (теперь рабочих пакетов) и поддержанию консенсуса остаются неизменными. Переход от BABE+GRANDPA к SAFROLE+GRANDPA для консенсуса в основном затрагивает внутреннюю реализацию клиента, а не операционные процедуры. Валидаторы, поддерживающие 99%+ времени безотказной работы, оперативно отвечающие на запросы валидации и участвующие в консенсусе, будут продолжать получать равные вознаграждения за эпоху, как и в текущем Polkadot.

Опыт разработчика: от смарт-контрактов к сервисам и за их пределы​

JAM фундаментально преобразует опыт разработчиков, устраняя барьеры для входа и расширяя возможности. Если Polkadot 1.0 заставлял команды выбирать между смарт-контрактами (ограниченные возможности, простое развертывание) или парачейнами (полные возможности, доступ на основе аукционов), то JAM предоставляет гибкую и богатую среду как для того, так и для другого, а также новые модели выполнения.

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

Смарт-контракты ink! продолжают процветать в экосистеме JAM с потенциальным прямым развертыванием на ядрах JAM через выделенные сервисы, устраняя необходимость в промежуточном хостинге парачейнов. Инструментарий остается зрелым: cargo-contract для компиляции, ink! playground для экспериментов, rustfmt и rust-analyzer для разработки, обозреватель Chainlens для верификации контрактов и фреймворки интеграционного тестирования. Путь перехода от концепции к производству остается ясным: начните с контрактов ink! для быстрой итерации, подтвердите соответствие продукта рынку, затем мигрируйте на сервисы JAM или парачейны, когда этого потребуют требования к производительности — повторно используя код Rust, тесты и компоненты фронтенда на протяжении всего процесса.

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

Функция Refine обрабатывает безстатусные вычисления, которые преобразуют входные данные роллапа в выходные. Она принимает до 15 МБ рабочих элементов за 6-секундный слот, выполняется до 6 секунд газа PVM и производит сжатые результаты размером не более 90 КБ. Refine выполняется офчейн параллельно на подмножествах валидаторов, при этом для доступа к данным доступны только поиски прообразов. Эта функция выполняет основную вычислительную работу — обработку транзакций, проверку доказательств, преобразование данных — полностью изолированно от глобального состояния.

Функция Accumulate интегрирует выходные данные Refine в состояние сервиса посредством операций с состоянием, ограниченных примерно 10 миллисекундами на выход. Она может считывать хранилище из любого сервиса (что позволяет выполнять межсервисные запросы), записывать в собственное хранилище ключ-значение, переводить средства между сервисами, создавать новые сервисы, обновлять собственный код и запрашивать доступность прообраза. Accumulate выполняется синхронно на всех валидаторах, что делает ее дорогой, но по умолчанию защищенной. Асимметрия — 6 секунд для Refine против 10 миллисекунд для Accumulate — навязывает архитектурную дисциплину: выносите вычисления офчейн, минимизируйте обновления состояния.

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

CorePlay представляет собой экспериментальный акторный фреймворк, демонстрирующий уникальные возможности JAM. Актёры, развернутые непосредственно на ядрах, могут использовать обычные синхронные шаблоны программирования — стандартный код в стиле fn main() с синтаксисом async/await. Когда актёры на одном ядре вызывают друг друга, выполнение происходит синхронно. При вызове актёров на разных ядрах продолжения PVM автоматически приостанавливают выполнение, сериализуют состояние и возобновляют его в более позднем блоке, когда приходят результаты. Эта абстракция делает многоблочное асинхронное выполнение синхронным для разработчиков, значительно упрощая логику распределенных приложений.

Улучшения в инструментарии разработчика включают упрощенное развертывание за счет создания сервисов без разрешений, сокращение требований к бенчмаркингу благодаря измерительному выполнению PVM в JAM, прозрачное и предсказуемое ценообразование кортайма (избегая волатильности комиссий в стиле Ethereum) и доступ к JAM Toaster для разработчиков, достигших Этапа 3+, предоставляющий полномасштабную симуляцию сети из 1023 узлов для реалистичного тестирования производительности. Поддержка нескольких языков — команды работают на Rust, Go, Swift, Zig, Elixir, OCaml и других — демонстрирует ясность спецификации и позволяет разработчикам выбирать знакомые инструментарии.

Синхронная компонуемость преобразует возможности многоцепочечных приложений. Текущие парачейны Polkadot обмениваются данными асинхронно через XCM, требуя от приложений обработки задержек ответов, тайм-аутов и сценариев отката. Accords JAM обеспечивают многоэкземплярные смарт-контракты, управляющие протоколами взаимодействия между сервисами с гарантиями синхронного выполнения. Например, дорожная карта Acala демонстрирует «инициирование флеш-кредита в Ethereum и выполнение арбитража между несколькими цепями через единый синхронизированный вызов» — атомарность, ранее невозможная в фрагментированных блокчейн-экосистемах.

Переход от паллетов Substrate к сервисам JAM снижает трения в управлении — паллеты Substrate требуют одобрения ончейн-управления для развертывания и обновлений, в то время как сервисы JAM развертываются без разрешений, как смарт-контракты. Разработчики сохраняют совместимость с Substrate SDK и могут продолжать использовать FRAME для сервисов парачейнов, но нативные сервисы JAM получают доступ к упрощенным моделям разработки без накладных расходов на координацию обновлений паллетов.

Документация и образовательные ресурсы значительно расширились в течение 2025 года: JAM 2025 World Tour охватил 9 городов на 2 континентах и привлек более 1300 разработчиков. Техническая документация включает исчерпывающий Gray Paper, разделы JAM в Polkadot Wiki, официальные руководства для разработчиков и учебные пособия, созданные сообществом. Программа Decentralized Futures от Web3 Foundation финансирует образовательные инициативы JAM, а приз для разработчиков создает экономические стимулы для создания высококачественной документации и инструментов для разработчиков.

Стратегическое видение: разрешение трилеммы блокчейна через архитектурные инновации​

Видение Гэвина Вуда для JAM направлено на устранение того, что он определяет как фундаментальное ограничение блокчейна — антагонизм размер-синхронность, когда системы должны выбирать между масштабом и когерентностью. Монолитные цепи, такие как Bitcoin и Ethereum L1, достигают высокой синхронности и компонуемости, но не могут масштабироваться за пределы вычислительных ограничений одного узла. Шардированные системы, такие как Ethereum L2, парачейны Polkadot и зоны Cosmos, достигают масштаба за счет разделения, но жертвуют когерентностью, вынуждая приложения работать в изолированных хранилищах только с асинхронной межшардовой связью.

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

Стратегическая цель сосредоточена на создании «почти когерентного бездоверительного суперкомпьютера», который сочетает три исторически несовместимых свойства:

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

Безопасные побочные вычисления, распараллеленные по масштабируемой сети узлов, впервые реализованные Polkadot, обеспечивают общую безопасность для всех сервисов через полный набор из 1023 валидаторов. В отличие от зон Cosmos с независимой безопасностью или Ethereum L2 с различными предположениями о доверии, каждый сервис JAM наследует идентичные гарантии безопасности с первого дня. Параллельное выполнение на ядрах обеспечивает вычислительное масштабирование без фрагментации безопасности — добавление сервисов не снижает безопасность, а увеличивает общую пропускную способность системы.

Синхронная компонуемость в пределах когерентных границ выполнения раскрывает сетевые эффекты. Протоколы DeFi могут атомарно компоноваться между сервисами для флеш-кредитов, арбитража и ликвидаций. Торговые площадки NFT могут атомарно объединять активы из нескольких цепей. Игровые приложения могут синхронно взаимодействовать с примитивами DeFi для внутриигровых экономик. Эта компонуемость, исторически ограниченная монолитными цепями, становится доступной в масштабируемой, распараллеленной среде.

Долгосрочное позиционирование Вуда для JAM выходит за рамки блокчейна к общим вычислениям. Слоган «децентрализованный глобальный компьютер» намеренно перекликается с ранними описаниями Ethereum, но с архитектурными основами, поддерживающими эту метафору в масштабе. Если «мировой компьютер» Ethereum быстро столкнулся с ограничениями масштабируемости, что потребовало прагматизма L2, то JAM строит вычислительное масштабирование в своей основе через парадигму Refine-Accumulate и поддержку продолжений PVM.

Эволюция от Polkadot 1.0 к JAM отражает философию «меньше мнений» — переход от предметно-ориентированного к универсальному, от закрепленных парачейнов к произвольным сервисам, от обновляемой сложности протокола к фиксированной простоте с обновляемыми приложениями. Этот архитектурный минимализм открывает возможности для оптимизации, невозможные в постоянно развивающихся системах: фиксированные параметры позволяют агрессивную оптимизацию сетевой топологии, известные тайминги позволяют точные алгоритмы планирования, неизменяемые спецификации позволяют аппаратное ускорение без риска устаревания.

Пять движущих факторов мотивируют дизайн JAM:

Устойчивость через децентрализацию требует более 1000 независимых операторов валидаторов, поддерживающих безопасность всех сервисов. Дизайн JAM сохраняет новаторский NPoS Polkadot с равными вознаграждениями валидаторам, предотвращая концентрацию доли, сохраняя при этом надежную отказоустойчивость к византийским ошибкам.

Универсальность, позволяющая выполнять произвольные вычисления, выходит за рамки специфических для блокчейна вариантов использования. PVM принимает любой код RISC-V, поддерживая языки от Rust и C++ до более экзотических реализаций. Сервисы могут реализовывать блокчейны, платформы смарт-контрактов, ZK-роллапы, уровни доступности данных, оракулы, сети хранения или совершенно новые вычислительные паттерны.

Производительность, достигающая «более или менее неограниченного масштабирования», достигается за счет горизонтального распараллеливания — добавление ядер масштабирует пропускную способность без архитектурных ограничений. Целевой показатель 850 МБ/с представляет собой стартовую пропускную способность; эластичное масштабирование и экономические рынки кортайма позволяют увеличивать пропускную способность по мере роста спроса без изменений протокола.

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

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

Конкурентная среда: JAM против альтернативных подходов Layer 0 и Layer 1​

Позиционирование JAM по отношению к дорожной карте Ethereum выявляет принципиально разные философии масштабирования. Ethereum преследует L2-ориентированную модульность, где L1 обеспечивает доступность данных и расчеты, в то время как выполнение мигрирует на оптимистические и ZK-роллапы, такие как Arbitrum, Optimism, Base и zkSync. Proto-danksharding (EIP-4844) добавил блоб-транзакции, обеспечивающие временную доступность данных, а полный danksharding планируется для увеличения пропускной способности в 100 раз. Разделение Proposer-Builder (PBS) и анонсированный редизайн уровня консенсуса Beam Chain продолжают оптимизировать L1 для его сужающейся роли.

Эта стратегия создает постоянное разделение: L2 остаются изолированными экосистемами с фрагментированной ликвидностью, различными предположениями о доверии, 7-дневными периодами вывода средств для оптимистических роллапов, рисками централизации секвенсоров и волатильностью комиссий во время перегрузки L1, которая каскадно распространяется на все L2. Компонуемость работает плавно внутри каждого L2, но меж-L2 взаимодействия возвращаются к асинхронному обмену сообщениями с рисками мостов. Сообщество Ethereum приняло прагматизм L2 после того, как первоначальное видение шардинга Ethereum 2.0 оказалось слишком сложным — но этот прагматизм принимает фундаментальные ограничения как неотъемлемые компромиссы.

JAM преследует то, что изначально обещал Ethereum 2.0: нативное шардированное выполнение с когерентным состоянием, встроенным в уровень консенсуса. Там, где Ethereum перенес выполнение офчейн на L2, JAM встраивает параллельное выполнение в консенсус L1 через модель Refine-Accumulate. Там, где Ethereum принял фрагментированные экосистемы L2, JAM обеспечивает унифицированную безопасность и компонуемость на уровне протокола через сервисы и Accords. Архитектурная ставка принципиально отличается — Ethereum делает ставку на специализированные инновации L2, JAM делает ставку на обобщенную масштабируемость L1.

Целевые показатели производительности иллюстрируют амбиции: Ethereum обрабатывает примерно 15 транзакций в секунду на L1 с доступностью данных 1,3 МБ на блок, в то время как L2 коллективно обрабатывают тысячи TPS с различными предположениями о безопасности. JAM нацелена на доступность данных 850 МБ/с (примерно в 650 раз больше, чем Ethereum L1) и теоретическую пропускную способность более 3,4 миллиона TPS с унифицированной безопасностью. Вычислительная модель также расходится — последовательное выполнение EVM в Ethereum против параллельной обработки на 350 ядрах в JAM представляет принципиально разные подходы к проблеме масштабирования.

Cosmos с протоколом Inter-Blockchain Communication (IBC) представляет собой альтернативное видение Layer 0, отдающее приоритет суверенитету над общей безопасностью. Зоны Cosmos — это независимые суверенные блокчейны со своими собственными наборами валидаторов, управлением и моделями безопасности. IBC обеспечивает бездоверительную связь через верификацию легких клиентов — цепи независимо проверяют состояние контрагента, не завися от общих валидаторов или пулов безопасности.

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

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

Подсети Avalanche представляют собой еще одну сравнительную архитектуру, где подсети являются суверенными блокчейнами Layer 1, которые валидаторы выбирают для валидации. Валидаторы основной сети (требующие 2000 AVAX в стейке) могут дополнительно валидировать любые выбранные ими подсети, что позволяет настраивать наборы валидаторов для каждой подсети. Эта горизонтальная модель безопасности (больше подсетей = больше наборов валидаторов) контрастирует с вертикальной моделью безопасности JAM (все сервисы используют полный набор валидаторов).

Архитектура подсетей позволяет оптимизацию для конкретных приложений — игровые подсети могут иметь высокую пропускную способность и низкую финализацию, подсети DeFi могут отдавать приоритет безопасности и децентрализации, корпоративные подсети могут реализовывать валидаторов с разрешениями. Консенсус Snowman от Avalanche обеспечивает финализацию менее чем за секунду внутри подсетей. Однако подсети остаются в значительной степени изолированными: Avalanche Warp Messaging (AWM) обеспечивает базовую межподсетевую связь, но без компонуемости на уровне протокола или синхронного выполнения, которые обеспечивают Accords JAM.

Позиционирование по производительности показывает, что Avalanche делает акцент на финализации менее чем за секунду (примерно 1 секунда против 18 секунд у JAM), но с более фрагментированной безопасностью в подсетях, а не с унифицированными 1023 валидаторами на сервис, как у JAM. Архитектура состояний также принципиально отличается: подсети Avalanche поддерживают полностью изолированные машины состояний, в то время как сервисы JAM используют общий уровень накопления, позволяющий межсервисные чтения и синхронные взаимодействия при планировании на одно и то же ядро.

Внешние протоколы интероперабельности, такие как LayerZero, Wormhole, Chainlink CCIP и Axelar, служат иным целям, чем нативный XCMP JAM. Эти протоколы соединяют совершенно разные блокчейн-экосистемы — Ethereum с Solana, Bitcoin с Cosmos — полагаясь на внешних валидаторов, оракулов или релейные сети для обеспечения безопасности. LayerZero использует модель Oracle + Relayer, обеспечивающую более 6 миллиардов долларов общей заблокированной стоимости в более чем 50 цепях. Wormhole использует 19 Guardians, валидирующих более 1 миллиарда сообщений с полностью разводненной оценкой в 10,7 миллиарда долларов.

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

Стратегическое позиционирование предполагает сосуществование, а не конкуренцию: JAM использует XCMP для внутренней связи, потенциально интегрируя LayerZero, Wormhole или аналогичные протоколы для внешней цепной связи. Сервисы JAM могут обертывать внешние протоколы для соединения с Ethereum, Solana, Bitcoin или Cosmos, обеспечивая наилучшую из обеих миров связь — бездоверительные внутренние операции с прагматичными внешними мостами.

Основы исследований: академическая строгость и новые вклады в информатику​

JAM Gray Paper закладывает академическую основу протокола, имитируя Ethereum Yellow Paper, предоставляя формальные математические спецификации, позволяющие создавать несколько независимых реализаций. Выпущенный в апреле 2024 года в версии 0.1, документ постоянно дорабатывался — v0.7.0 в июне 2025 года добавила подробный псевдокод PVM, v0.7.1 в июле включила отзывы сообщества — приближаясь к v1.0, ожидаемой к началу 2026 года. Такое итеративное развитие спецификации с проверкой сообщества параллельно академическому рецензированию, улучшая ясность и выявляя неоднозначности.

Аннотация Gray Paper кристаллизует теоретический вклад JAM: "Мы представляем всеобъемлющее и формальное определение Jam, протокола, сочетающего элементы Polkadot и Ethereum. В единой когерентной модели Jam предоставляет глобальную одноэлементную среду объектов без разрешений — очень похожую на среду смарт-контрактов, впервые примененную Ethereum, — в сочетании с безопасными побочными вычислениями, распараллеленными по масштабируемой сети узлов, предложение, впервые примененное Polkadot." Этот синтез, казалось бы, несовместимых свойств — компонуемости без разрешений Ethereum с параллельной общей безопасностью Polkadot — представляет собой основную теоретическую проблему, которую решает JAM.

Выбор RISC-V для основ PVM отражает строгий анализ компьютерной архитектуры. RISC-V возник из исследований Калифорнийского университета в Беркли как архитектура набора инструкций с открытым исходным кодом, отдающая приоритет простоте и расширяемости. Имея всего 47 базовых инструкций по сравнению с сотнями в x86 или ARM, RISC-V минимизирует сложность реализации, сохраняя при этом вычислительную полноту. Регистровая архитектура избегает NP-полной проблемы распределения регистров, присущей стековым виртуальным машинам, таким как WebAssembly, что обеспечивает более быструю компиляцию и более предсказуемую производительность.

PVM JAM вносит минимальные изменения в стандартный RISC-V, в основном добавляя детерминированное управление памятью и измерение газа, сохраняя при этом совместимость с существующими инструментариями RISC-V. Этот консерватизм дизайна позволяет использовать десятилетия исследований компьютерной архитектуры и производственные компиляторы (LLVM), а не создавать пользовательскую инфраструктуру компиляторов. Языки, компилирующиеся в RISC-V — Rust, C, C++, Go и многие другие — автоматически становятся совместимыми с JAM без модификаций компилятора, специфичных для блокчейна.

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

Дуализм Refine-Accumulate концептуально отображается на модель программирования MapReduce, впервые примененную Google для распределенных вычислений. Refine действует как фаза Map — легко распараллеливаемое, безстатусное преобразование входных данных в выходные на распределенных рабочих узлах (ядрах валидаторов). Accumulate действует как фаза Reduce — последовательная интеграция преобразованных результатов в унифицированное состояние. Этот паттерн информатики, доказавший свою эффективность в массовом масштабе в традиционных распределенных системах, элегантно адаптируется к бездоверительной среде блокчейна с криптографической верификацией, заменяющей централизованную координацию.

Механизм консенсуса SAFROLE основан на десятилетиях исследований распределенных систем. Алгоритм эволюционировал из SASSAFRAS (Semi-Anonymous Sortition of Staked Assignees for Fixed-time Rhythmic Assignment of Slots), упрощая его для специфических требований JAM, сохраняя при этом ключевые свойства: бесфорковое производство блоков за счет анонимного выбора валидаторов, устойчивость к целенаправленным DoS-атакам за счет анонимности на основе zkSNARK до производства блоков и детерминированное время, обеспечивающее точное планирование ресурсов.

Криптографические основы сочетают Ring Verifiable Random Functions (RingVRF) для анонимного доказательства членства в наборе валидаторов с zkSNARKs для эффективной верификации. Система билетов с двухэпохальным авансом — валидаторы отправляют билеты за две эпохи до производства блоков — предотвращает различные атаки, сохраняя при этом гарантии анонимности. Это представляет собой элегантное применение современных криптографических примитивов для решения практических проблем консенсуса.

Экономические валидаторы (ELV) как альтернатива верификации ZK-доказательств обеспечивают новый анализ компромисса между безопасностью и стоимостью. Документация JAM утверждает, что ELV примерно в 4000 раз более экономически эффективны, чем доказательства с нулевым разглашением, для обеспечения вычислительной корректности. Модель опирается на криптоэкономическую безопасность: случайно выбранные валидаторы повторно выполняют работу для проверки корректности, при этом некорректные результаты вызывают споры и потенциальный слэшинг. Этот «оптимистический» подход, при котором корректность предполагается, если не оспаривается, отражает оптимистические роллапы, но работает на уровне протокола с немедленной финализацией после аудитов валидаторов.

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

Новые теоретические вклады от JAM включают:

Бестранзакционная парадигма блокчейна оспаривает фундаментальное предположение архитектуры блокчейна. Bitcoin, Ethereum и почти все преемники организуются вокруг транзакций — подписанных действий пользователей в мемпуле, конкурирующих за включение в блок. JAM полностью исключает транзакции: все изменения состояния проходят через рабочие пакеты, содержащие рабочие элементы, которые проходят стадии Refine и Accumulate. Эта принципиально иная модель поднимает интересные исследовательские вопросы о MEV (максимально извлекаемой ценности), устойчивости к цензуре и пользовательском опыте, которые академические исследования еще не полностью изучили.

Частично когерентный консенсус представляет собой новую позицию между полностью когерентными (монолитные цепи) и полностью некогерентными (изолированные шарды) системами. JAM гарантирует когерентность для критических 6-секундных окон, когда сервисы совместно размещаются на ядрах, принимая при этом асинхронность между ядрами. Экономические механизмы, управляющие паттернами когерентности — секвенсоры, оптимизирующие состав рабочих пакетов для максимизации пропускной способности и минимизации задержки — создают интересную проблему теории игр. Как рациональные экономические акторы организуют сервисы на ядрах? Какие равновесия возникают? Эти вопросы ожидают эмпирической проверки.

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

Оптимизация смешанного потребления ресурсов создает интересную проблему планирования и экономики. Сервисы имеют разнообразные профили ресурсов — некоторые ограничены вычислениями (верификация ZK-доказательств), другие ограничены данными (сервисы доступности), третьи сбалансированы. Оптимальное использование ресурсов валидатора требует сопоставления комплементарных сервисов в рабочих пакетах. Какие механизмы возникают для координации этого сопоставления? Как развиваются рынки для комплементарной пакетной обработки сервисов? Это неисследованная территория в исследованиях экономики блокчейна.

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

Усилия по формальной верификации продолжаются: Runtime Verification разрабатывает семантику K Framework для PVM. K Framework обеспечивает математическую строгость для определения семантики языков программирования и виртуальных машин, позволяя формально доказывать свойства корректности. Результаты включают эталонные спецификации, отладчики и инструменты для тестирования свойств. Этот уровень математической строгости, хотя и распространен в аэрокосмическом и военном программном обеспечении, остается относительно редким в разработке блокчейна, что представляет собой созревание области в сторону формальных методов.

Синтез: место JAM в эволюции блокчейна и последствия для Web3​

JAM представляет собой кульминацию более чем десятилетних исследований масштабируемости блокчейна, пытаясь построить то, что обещали, но не смогли реализовать предыдущие поколения. Bitcoin представил децентрализованный консенсус, но не смог масштабироваться за пределы 7 TPS. Ethereum добавил программируемость, но столкнулся с аналогичными ограничениями пропускной способности. Первоначальное видение Ethereum 2.0 предлагало нативный шардинг с 64 шардовыми цепями, но оказалось слишком сложным, переключившись на L2-ориентированный прагматизм. Polkadot впервые применил общую безопасность для парачейнов, но с фиксированными ограничениями в 50 цепей и доступом на основе аукционов.

JAM синтезирует уроки этих попыток: поддерживать децентрализацию и безопасность (урок Bitcoin), обеспечивать произвольные вычисления (урок Ethereum), масштабироваться за счет распараллеливания (попытка Ethereum 2.0), обеспечивать общую безопасность (инновация Polkadot), добавлять синхронную компонуемость (недостающий элемент) и снижать барьеры для входа (доступность).

Компромисс между теоретической элегантностью и практической сложностью остается центральным риском JAM. Дизайн протокола интеллектуально когерентен — дуализм Refine-Accumulate, продолжения PVM, консенсус SAFROLE, частично когерентное выполнение — все логически сочетается. Но теоретическая обоснованность не гарантирует практического успеха. Переход Ethereum от нативного шардинга к L2 был обусловлен не теоретической невозможностью, а практической сложностью в реализации, тестировании и координации.

Единая комплексная стратегия обновления JAM усиливает как преимущества, так и недостатки. Успех обеспечивает все улучшения одновременно — 42-кратную доступность данных, сервисы без разрешений, синхронную компонуемость, производительность RISC-V — в одном скоординированном развертывании. Неудача или задержки влияют на все обновление, а не на поэтапное внедрение улучшений. 43 независимые команды разработчиков, обширные фазы тестовой сети и полномасштабное тестирование JAM Toaster направлены на снижение рисков, но координация 1023 валидаторов при крупном архитектурном переходе остается беспрецедентной в истории блокчейна.

Переход экономической модели от аукционов парачейнов к рынкам кортайма представляет собой в значительной степени непроверенный механизм в масштабе. Хотя Agile Coretime Polkadot был запущен в 2024 году, сервисная модель JAM с развертыванием без разрешений создает совершенно новую экономическую динамику. Как рынки кортайма будут оценивать различные типы сервисов? Будет ли ликвидность концентрироваться в определенных ядрах? Как секвенсоры оптимизируют состав рабочих пакетов? На эти вопросы нет эмпирических ответов до развертывания основной сети.

Принятие разработчиками зависит от того, обеспечит ли новая модель программирования JAM — точки входа Refine/Accumulate/onTransfer, безстатусное, а затем статусное выполнение, асинхронность на основе продолжений — достаточную ценность, чтобы оправдать кривую обучения. Успех Ethereum отчасти был обусловлен знакомством разработчиков с EVM, несмотря на неэффективность. PVM JAM предлагает превосходную производительность, но требует переосмысления архитектуры приложений вокруг рабочих пакетов и сервисов. Развертывание без разрешений и устранение аукционов значительно снижают финансовые барьеры, но изменения в ментальной модели могут оказаться более сложными, чем финансовые.

Конкурентная динамика меняется по мере развертывания JAM. L2 Ethereum имеют значительные сетевые эффекты, ликвидность и внимание разработчиков. Solana предлагает исключительную производительность с более простыми моделями программирования. Cosmos обеспечивает суверенитет, который некоторые проекты высоко ценят. JAM должна не только предоставлять технические возможности, но и привлекать участников экосистемы — разработчиков, пользователей, капитал — которые делают блокчейн-сети ценными. Существующая экосистема Polkadot обеспечивает основу, но расширение за пределы текущих участников требует убедительных ценностных предложений для миграции.

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

Долгосрочные последствия для Web3, если JAM преуспеет, включают фундаментальные изменения в архитектуре децентрализованных приложений. Текущая парадигма «развернуть на блокчейне» (Ethereum L1, Solana, Avalanche) или «создать свой собственный блокчейн» (Cosmos, парачейны Polkadot) добавляет промежуточный вариант: «развернуть как сервис» с мгновенной общей безопасностью, гибким распределением ресурсов и компонуемостью с более широкой экосистемой. Это может ускорить инновации, устраняя проблемы инфраструктуры — команды сосредотачиваются на логике приложений, в то время как JAM обрабатывает консенсус, безопасность и масштабируемость.

Видение децентрализованного глобального компьютера становится архитектурно осуществимым, если JAM достигнет целевых показателей производительности. При доступности данных 850 МБ/с, 150 миллиардах газа в секунду и пропускной способности более 3,4 миллиона TPS, вычислительная пропускная способность приближается к уровням, на которых значительные традиционные приложения могут мигрировать на децентрализованную инфраструктуру. Не для всех вариантов использования — приложения, чувствительные к задержкам, по-прежнему сталкиваются с фундаментальными ограничениями скорости света, требования к конфиденциальности могут конфликтовать с прозрачным выполнением — но для проблем координации, финансовой инфраструктуры, отслеживания цепочек поставок, цифровой идентификации и многих других приложений децентрализованные вычисления становятся технически жизнеспособными в масштабе.

Показатели успеха JAM в ближайшие 2-5 лет будут включать: количество развернутых сервисов помимо устаревших парачейнов (измерение расширения экосистемы), фактическую пропускную способность и доступность данных, достигнутые в производстве (подтверждение заявлений о производительности), экономическую устойчивость рынков кортайма (доказательство работоспособности экономической модели), показатели принятия разработчиками (активность на GitHub, трафик документации, участие в образовательных программах) и историю безопасности (отсутствие крупных эксплойтов или сбоев консенсуса).

Окончательный вопрос заключается в том, представляет ли JAM инкрементальное улучшение в пространстве дизайна блокчейна — лучше, чем альтернативы, но не принципиально отличающееся по возможностям — или скачок поколений, который позволяет создавать совершенно новые категории приложений, невозможные на текущей инфраструктуре. Архитектурные основы — частично когерентное выполнение, продолжения PVM, дуализм Refine-Accumulate, Accords — предполагают, что последнее возможно. Превратится ли потенциал в реальность, зависит от качества исполнения, создания экосистемы и факторов рыночного времени, которые выходят за рамки чисто технических достоинств.

Для исследователей Web3 JAM предоставляет богатую экспериментальную платформу для изучения новых механизмов консенсуса, архитектур выполнения, механизмов экономической координации и моделей безопасности. Следующие несколько лет принесут эмпирические данные, проверяющие теоретические предсказания о частично когерентном консенсусе, бестранзакционной архитектуре и сервисно-ориентированной организации блокчейна. Независимо от коммерческих результатов, полученные знания будут формировать дизайн протоколов блокчейна на десятилетия вперед.

Введение​

Децентрализованные рынки ИИ-выводов/обучения призваны использовать глобальные вычислительные ресурсы и общедоступные модели без необходимости доверия. Такие проекты, как Bittensor, Gensyn и Cuckoo Network (Cuckoo AI), демонстрируют, как блокчейн-технологии могут обеспечивать работу открытых ИИ-маркетплейсов. Каждая платформа токенизирует ключевые ИИ-активы — вычислительную мощность, модели машинного обучения, а иногда и данные — в ончейн-экономические единицы. Далее мы углубимся в технические архитектуры, лежащие в основе этих сетей, способы токенизации ресурсов, их структуры управления и стимулирования, методы отслеживания владения моделями, механизмы распределения доходов и возникающие поверхности атаки (например, атаки Сивиллы, сговор, фрирайдерство, отравление данных). Сравнительная таблица в конце подытоживает все ключевые аспекты Bittensor, Gensyn и Cuckoo AI.

Технические архитектуры​

Bittensor: Децентрализованный «Нейронный Интернет» на подсетях​

Bittensor построен на основе кастомного блокчейна уровня 1 (цепочка Subtensor, основанная на Substrate), который координирует сеть узлов ИИ-моделей в многочисленных специализированных подсетях. Каждая подсеть представляет собой независимую мини-сеть, ориентированную на конкретную ИИ-задачу (например, подсеть для генерации языка, другая — для генерации изображений и т. д.). Участники Bittensor выполняют различные роли:

• Майнеры — они запускают модели машинного обучения на своем оборудовании и предоставляют ответы на запросы (или даже выполняют обучение) для задачи подсети. По сути, майнер — это узел, размещающий ИИ-модель, которая будет отвечать на запросы.
• Валидаторы — они запрашивают модели майнеров с помощью промптов и оценивают качество ответов, формируя мнение о том, какие майнеры вносят ценные результаты. Валидаторы эффективно оценивают производительность майнеров.
• Владельцы подсетей — они создают и определяют подсети, устанавливая правила для выполнения задач и проведения валидации в этой подсети. Владелец подсети может, например, указать, что подсеть предназначена для определенного набора данных или модальности, и определить процедуру валидации.
• Делегаторы — держатели токенов, которые не запускают узлы, могут делегировать (стейкать) свои токены Bittensor (TAO) майнерам или валидаторам, чтобы поддержать лучших исполнителей и получить долю вознаграждения (аналогично стейкингу в сетях Proof-of-Stake).

Механизм консенсуса Bittensor является новаторским: вместо традиционной валидации блоков Bittensor использует консенсус Yuma, который является формой «доказательства интеллекта». В консенсусе Yuma оценки валидаторов майнеров агрегируются в ончейне для определения распределения вознаграждений. Каждые 12 секунд сеть выпускает новые токены TAO и распределяет их в соответствии с консенсусом валидаторов относительно того, какие майнеры выполнили полезную работу. Оценки валидаторов объединяются по схеме медианы, взвешенной по стейку: выбросы мнений отсекаются, и преобладает честное большинство. Это означает, что если большинство валидаторов согласны с тем, что майнер был высококачественным, этот майнер получит значительное вознаграждение; если валидатор сильно отклоняется от других (возможно, из-за сговора или ошибки), этот валидатор наказывается меньшим заработком. Таким образом, блокчейн Bittensor координирует петлю обратной связи между майнером и валидатором: майнеры соревнуются за создание лучших ИИ-выводов, а валидаторы курируют и ранжируют эти выводы, при этом обе стороны зарабатывают токены пропорционально ценности, которую они добавляют. Эта архитектура часто описывается как «децентрализованная нейронная сеть» или «глобальный мозг», где модели учатся на сигналах друг друга и коллективно развиваются. Примечательно, что Bittensor недавно обновил свою цепь для поддержки совместимости с EVM (для смарт-контрактов) и представил dTAO, систему токенов и стейкинга для конкретных подсетей (объясняется позже) для дальнейшей децентрализации контроля над распределением ресурсов.

Gensyn: Протокол доверенных распределенных вычислений​

Gensyn подходит к децентрализованному ИИ с точки зрения протокола распределенных вычислений для машинного обучения. Его архитектура соединяет разработчиков (отправителей), у которых есть ИИ-задачи (например, обучение модели или выполнение задачи вывода), с поставщиками вычислений (решателями) по всему миру, у которых есть свободные ресурсы GPU/TPU. Первоначально Gensyn планировал цепь Substrate L1, но затем перешел на создание на Ethereum в качестве роллапа для повышения безопасности и ликвидности. Таким образом, сеть Gensyn является уровнем 2 Ethereum (роллап Ethereum), который координирует размещение заданий и платежи, в то время как вычисления происходят вне цепи на оборудовании поставщиков.

Ключевым нововведением в дизайне Gensyn является его система верификации для офчейн-работы. Gensyn использует комбинацию оптимистической верификации (доказательства мошенничества) и криптографических методов для обеспечения того, что когда решатель заявляет о выполнении задачи обучения/вывода, результат является правильным. На практике протокол включает несколько ролей участников:

• Отправитель — сторона, запрашивающая задание (например, тот, кому нужно обучить модель). Они оплачивают комиссию сети и предоставляют модель/данные или спецификацию задачи.
• Решатель — узел, который делает ставки на выполнение ML-задачи на своем оборудовании и выполняет ее. Он будет обучать модель или выполнять вывод по запросу, а затем представит результаты и доказательство вычислений.
• Верификатор/Челленджер — узлы, которые могут проверять или выборочно проверять работу решателя. Gensyn реализует схему в стиле Truebit, где по умолчанию результат решателя принимается, но верификатор может оспорить его в течение определенного окна, если подозревает неправильное вычисление. В случае оспаривания используется интерактивный «бинарный поиск» по шагам вычисления (протокол доказательства мошенничества) для выявления любых расхождений. Это позволяет цепи разрешать споры, выполняя только минимальную критическую часть вычисления в ончейне, а не повторяя всю дорогостоящую задачу.

Важно отметить, что Gensyn разработан для избежания массовой избыточности наивных подходов. Вместо того чтобы множество узлов повторяли одну и ту же ML-задачу (что уничтожило бы экономию средств), подход Gensyn «доказательство обучения» использует метаданные обучения для проверки того, что был достигнут прогресс в обучении. Например, решатель может предоставить криптографические хеши или контрольные точки промежуточных весов модели и краткое доказательство того, что они прогрессировали в соответствии с обновлениями обучения. Это вероятностное доказательство обучения может быть проверено гораздо дешевле, чем повторный запуск всего обучения, что позволяет осуществлять доверенную верификацию без полного дублирования. Только если верификатор обнаружит аномалию, в крайнем случае будет запущено более тяжелое ончейн-вычисление. Этот подход значительно снижает накладные расходы по сравнению с проверкой методом грубой силы, делая децентрализованное ML-обучение более осуществимым. Таким образом, архитектура Gensyn сильно акцентирует внимание на криптоэкономическом игровом дизайне: решатели вносят стейк или залог, и если они обманывают (представляют неверные результаты), они теряют этот стейк в пользу честных верификаторов, которые их поймают. Объединяя координацию блокчейна (для платежей и разрешения споров) с офчейн-вычислениями и умной верификацией, Gensyn создает маркетплейс для ML-вычислений, который может использовать простаивающие GPU в любой точке мира, сохраняя при этом отсутствие доверия. Результатом является гипермасштабируемый «протокол вычислений», где любой разработчик может получить доступ к доступной, глобально распределенной вычислительной мощности по требованию.

Cuckoo AI: Полнофункциональная децентрализованная платформа ИИ-сервисов​

Cuckoo Network (или Cuckoo AI) использует более вертикально интегрированный подход, стремясь предоставлять сквозные децентрализованные ИИ-сервисы, а не просто сырые вычисления. Cuckoo построил свой собственный блокчейн (первоначально уровень 1 под названием Cuckoo Chain на Arbitrum Orbit, фреймворке роллапов, совместимом с Ethereum) для оркестрации всего: он не только сопоставляет задания с GPU, но также размещает ИИ-приложения и обрабатывает платежи в одной системе. Дизайн является полнофункциональным: он сочетает блокчейн для транзакций и управления, децентрализованный уровень ресурсов GPU/CPU и пользовательские ИИ-приложения и API сверху. Другими словами, Cuckoo интегрирует все три уровня — блокчейн, вычисления и ИИ-приложения — в рамках единой платформы.

Участники Cuckoo делятся на четыре группы:

• Разработчики ИИ-приложений (Координаторы) — это разработчики, которые развертывают ИИ-модели или сервисы на Cuckoo. Например, разработчик может разместить генератор изображений Stable Diffusion или чат-бота LLM в качестве сервиса. Они запускают Узлы-координаторы, которые отвечают за управление своим сервисом: прием пользовательских запросов, разделение их на задачи и назначение этих задач майнерам. Координаторы стейкают нативный токен ($CAI), чтобы присоединиться к сети и получить право использовать майнеров. По сути, они действуют как оркестраторы уровня 2, которые взаимодействуют между пользователями и поставщиками GPU.
• Майнеры GPU/CPU (Узлы задач) — это поставщики ресурсов. Майнеры запускают клиент Cuckoo для задач и предоставляют свое оборудование для выполнения задач вывода для ИИ-приложений. Например, майнеру может быть назначен запрос на генерацию изображения (с заданной моделью и промптом) координатором, и он использует свой GPU для вычисления результата. Майнеры также должны стейкать $CAI для обеспечения обязательств и хорошего поведения. Они зарабатывают токен-вознаграждения за каждую правильно выполненную задачу.
• Конечные пользователи — потребители ИИ-приложений. Они взаимодействуют через веб-портал Cuckoo или API (например, генерируют искусство через CooVerse или общаются с ИИ-персонажами). Пользователи могут либо платить криптовалютой за каждое использование, либо, возможно, предоставлять свои собственные вычисления (или стейк) для компенсации затрат на использование. Важным аспектом является устойчивость к цензуре: если один координатор (поставщик услуг) заблокирован или выходит из строя, пользователи могут переключиться на другого, обслуживающего то же приложение, поскольку несколько координаторов могут размещать аналогичные модели в децентрализованной сети.
• Стейкеры (Делегаторы) — члены сообщества, которые не запускают ИИ-сервисы или майнинговое оборудование, все еще могут участвовать, стейкая $CAI на тех, кто это делает. Голосуя своим стейком за доверенных координаторов или майнеров, они помогают сигнализировать о репутации и взамен получают долю сетевых вознаграждений. Этот дизайн создает уровень репутации Web3: хорошие акторы привлекают больше стейка (и, следовательно, доверия и вознаграждений), в то время как плохие акторы теряют стейк и репутацию. Даже конечные пользователи могут стейкать в некоторых случаях, что соответствует их интересам в успехе сети.

Цепочка Cuckoo (сейчас находится в процессе перехода от автономной цепи к роллапу с общей безопасностью) отслеживает все эти взаимодействия. Когда пользователь вызывает ИИ-сервис, узел-координатор создает ончейн-назначения задач для майнеров. Майнеры выполняют задачи офчейн и возвращают результаты координатору, который их проверяет (например, проверяет, что выходное изображение или текст не является бессмыслицей) и доставляет окончательный результат пользователю. Блокчейн обрабатывает расчеты по платежам: за каждую задачу смарт-контракт координатора платит майнеру в $CAI (часто агрегируя микроплатежи в ежедневные выплаты). Cuckoo подчеркивает отсутствие доверия и прозрачность — все участники стейкают токены, и все назначения и выполнения задач записываются, поэтому мошенничество пресекается угрозой потери стейка и публичной видимостью производительности. Модульный дизайн сети означает, что новые ИИ-модели или варианты использования могут быть легко добавлены: хотя она начиналась с генерации текста в изображение в качестве доказательства концепции, ее архитектура достаточно универсальна для поддержки других ИИ-нагрузок (например, вывод языковых моделей, транскрипция аудио и т. д.).

Примечательным аспектом архитектуры Cuckoo является то, что она изначально запустила свой собственный блокчейн уровня 1 для максимизации пропускной способности для ИИ-транзакций (достигая 300 тыс. ежедневных транзакций во время тестирования). Это позволило выполнить пользовательские оптимизации для планирования ИИ-задач. Однако команда обнаружила, что поддержание автономного L1 является дорогостоящим и сложным, и по состоянию на середину 2025 года они решили прекратить поддержку собственной цепи и перейти на модель роллапа/AVS (Active Validated Service) на Ethereum. Это означает, что Cuckoo будет наследовать безопасность от Ethereum или L2, такого как Arbitrum, вместо того чтобы запускать свой собственный консенсус, но продолжит управлять своим децентрализованным ИИ-маркетплейсом на этом уровне общей безопасности. Изменение призвано улучшить экономическую безопасность (используя надежность Ethereum) и позволить команде Cuckoo сосредоточиться на продукте, а не на низкоуровневом обслуживании цепи. В итоге, архитектура Cuckoo создает децентрализованную платформу для обслуживания ИИ, где любой может подключить оборудование или развернуть сервис ИИ-модели, а пользователи по всему миру могут получить доступ к ИИ-приложениям с меньшими затратами и меньшей зависимостью от инфраструктуры Big Tech.

Механизмы токенизации активов​

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

• Вычислительная мощность: Все три платформы превращают вычислительную работу в токены вознаграждения. В Bittensor полезные вычисления (вывод или обучение, выполненные майнером) количественно оцениваются с помощью оценок валидаторов и вознаграждаются токенами TAO за каждый блок. По сути, Bittensor «измеряет» внесенный интеллект и выпускает TAO как товар, представляющий этот вклад. Gensyn явно рассматривает вычисления как товар — его протокол создает маркетплейс, где время GPU является продуктом, а цена устанавливается спросом и предложением в токенах. Разработчики покупают вычисления, используя токен, а поставщики зарабатывают токены, продавая свои аппаратные циклы. Команда Gensyn отмечает, что любой цифровой ресурс (вычисления, данные, алгоритмы) может быть представлен и продан на аналогичном доверенном рынке. Cuckoo токенизирует вычисления с помощью токена ERC-20 $CAI, выпускаемого в качестве оплаты за выполненные задачи. Поставщики GPU, по сути, «майнят» CAI, выполняя работу по ИИ-выводу. Система Cuckoo создает ончейн-записи задач, поэтому можно рассматривать каждую выполненную задачу GPU как атомарную единицу работы, оплачиваемую токенами. Предпосылка для всех трех заключается в том, что иначе простаивающая или недоступная вычислительная мощность становится токенизированным, ликвидным активом — либо через эмиссию токенов на уровне протокола (как в Bittensor и раннем Cuckoo), либо через открытый рынок ордеров на покупку/продажу вычислительных заданий (как в Gensyn).

• ИИ-модели: Представление ИИ-моделей в виде ончейн-активов (например, NFT или токенов) все еще находится на ранней стадии. Bittensor не токенизирует сами модели — модели остаются офчейн во владении майнеров. Вместо этого Bittensor косвенно оценивает модели, вознаграждая те, которые хорошо работают. По сути, «интеллект» модели превращается в заработок TAO, но нет NFT, который бы представлял веса модели или позволял другим использовать модель. Gensyn фокусируется на вычислительных транзакциях, а не на явном создании токенов для моделей. Модель в Gensyn обычно предоставляется разработчиком офчейн (возможно, с открытым исходным кодом или проприетарная), обучается решателями и возвращается — нет встроенного механизма для создания токена, который владеет моделью или ее ИС. (Тем не менее, маркетплейс Gensyn потенциально может облегчить торговлю артефактами или контрольными точками моделей, если стороны выберут это, но сам протокол рассматривает модели как содержимое вычислений, а не как токенизированный актив.) Cuckoo находится где-то посередине: он говорит об «ИИ-агентах» и моделях, интегрированных в сеть, но в настоящее время нет невзаимозаменяемого токена, представляющего каждую модель. Вместо этого модель развертывается разработчиком приложения, а затем обслуживается через сеть. Права на использование этой модели неявно токенизируются тем, что модель может зарабатывать $CAI при использовании (через координатора, который ее развертывает). Все три платформы признают концепцию токенизации моделей — например, предоставление сообществам владения моделями через токены — но практические реализации ограничены. В отрасли токенизация ИИ-моделей (например, в виде NFT с правами собственности и долей прибыли) все еще исследуется. Подход Bittensor, при котором модели обмениваются ценностью друг с другом, является формой «маркетплейса моделей» без явного токена для каждой модели. Команда Cuckoo отмечает, что децентрализованное владение моделями обещает снизить барьеры по сравнению с централизованным ИИ, но требует эффективных методов проверки выходов и использования моделей в ончейне. В итоге, вычислительная мощность немедленно токенизируется (легко платить токенами за выполненную работу), тогда как модели токенизируются косвенно или в перспективе (вознаграждаются за свои выходы, возможно, представлены стейком или репутацией, но пока не рассматриваются как передаваемые NFT на этих платформах).

• Данные: Токенизация данных остается самой сложной. Ни Bittensor, ни Gensyn, ни Cuckoo не имеют полностью обобщенных ончейн-маркетплейсов данных (где наборы данных торгуются с принудительными правами использования). Узлы Bittensor могут обучаться на различных наборах данных, но эти наборы данных не являются частью ончейн-системы. Gensyn может позволить разработчику предоставить набор данных для обучения, но протокол не токенизирует эти данные — они просто предоставляются офчейн для использования решателем. Cuckoo аналогично не токенизирует пользовательские данные; он в основном обрабатывает данные (например, пользовательские промпты или выходы) временным образом для задач вывода. В блоге Cuckoo прямо говорится, что «децентрализованные данные остаются сложными для токенизации», несмотря на то, что это критически важный ресурс. Данные чувствительны (проблемы конфиденциальности и владения) и трудно обрабатываются с помощью текущих блокчейн-технологий. Таким образом, хотя вычисления становятся товаром, а модели начинают им быть, данные в основном остаются офчейн, за исключением особых случаев (некоторые проекты за пределами этих трех экспериментируют с объединениями данных и токен-вознаграждениями за вклад данных, но это выходит за рамки нашей текущей области). В итоге, вычислительная мощность теперь является ончейн-товаром в этих сетях, модели оцениваются через токены, но еще не токенизированы индивидуально как активы, а токенизация данных все еще остается открытой проблемой (помимо признания ее важности).

Управление и стимулы​

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

• Управление Bittensor: На ранних этапах разработка Bittensor и параметры подсетей в значительной степени контролировались основной командой и набором из 64 «корневых» валидаторов в основной подсети. Это было точкой централизации — несколько влиятельных валидаторов имели чрезмерное влияние на распределение вознаграждений, что привело к тому, что некоторые называли «олигархической системой голосования». Для решения этой проблемы Bittensor в 2025 году ввел управление dTAO (децентрализованный TAO). Система dTAO перевела распределение ресурсов на рыночное и контролируемое сообществом. Конкретно, держатели TAO могут стейкать свои токены в пулы ликвидности для конкретных подсетей (по сути, они «голосуют» за то, какие подсети должны получать больше эмиссии сети) и получать альфа-токены, которые представляют собой право собственности в этих пулах подсетей. Подсети, которые привлекают больше стейка, будут иметь более высокую цену альфа-токена и получать большую долю ежедневной эмиссии TAO, тогда как непопулярные или плохо работающие подсети будут терять капитал (и, следовательно, эмиссию). Это создает петлю обратной связи: если подсеть производит ценные ИИ-сервисы, больше людей стейкают в нее TAO (в поисках вознаграждений), что дает этой подсети больше TAO для вознаграждения своих участников, способствуя росту. Если подсеть стагнирует, стейкеры выводят средства в более прибыльные подсети. По сути, держатели TAO коллективно управляют фокусом сети, финансово сигнализируя, какие ИИ-области заслуживают больше ресурсов. Это форма ончейн-управления по весу токенов, согласованная с экономическими результатами. Помимо распределения ресурсов, основные обновления протокола или изменения параметров, вероятно, по-прежнему проходят через предложения по управлению, за которые голосуют держатели TAO (Bittensor имеет механизм для ончейн-предложений и референдумов, управляемых Фондом Bittensor и избранным советом, аналогично управлению Polkadot). Со временем можно ожидать, что управление Bittensor будет становиться все более децентрализованным, при этом фонд будет отходить на второй план, поскольку сообщество (через стейк TAO) будет управлять такими вещами, как уровень инфляции, утверждение новых подсетей и т. д. Переход на dTAO является большим шагом в этом направлении, заменяя централизованных лиц, принимающих решения, рынком заинтересованных сторон токенов, согласованным по стимулам.

• Стимулы Bittensor: Структура стимулов Bittensor тесно вплетена в его консенсус. Каждый блок (12 секунд) ровно 1 TAO выпускается и делится между участниками каждой подсети на основе производительности. Разделение вознаграждения за блок по умолчанию для каждой подсети составляет 41% майнерам, 41% валидаторам и 18% владельцу подсети. Это гарантирует, что все роли вознаграждаются: майнеры зарабатывают за выполнение работы по выводу, валидаторы зарабатывают за свои усилия по оценке, а владельцы подсетей (которые, возможно, загрузили данные/задачу для этой подсети) получают остаток за предоставление «маркетплейса» или дизайн задачи. Эти проценты фиксированы в протоколе и направлены на согласование стимулов всех участников для получения высококачественного ИИ-вывода. Механизм консенсуса Yuma дополнительно уточняет стимулы, взвешивая вознаграждения в соответствии с оценками качества — майнер, который предоставляет лучшие ответы (согласно консенсусу валидаторов), получает большую часть этих 41%, а валидатор, который точно следует честному консенсусу, получает больше из доли валидатора. Плохие исполнители экономически отсеиваются. Кроме того, делегаторы (стейкеры), которые поддерживают майнера или валидатора, обычно получают долю от заработка этого узла (узлы часто устанавливают комиссию и отдают остальное своим делегаторам, аналогично стейкингу в сетях PoS). Это позволяет пассивным держателям TAO поддерживать лучших участников и получать доход, что еще больше укрепляет меритократию. Токен Bittensor (TAO) таким образом является утилитарным токеном: он требуется для регистрации новых майнеров (майнеры должны потратить небольшое количество TAO, чтобы присоединиться, что борется со спамом Сивиллы) и может быть застейкан для увеличения влияния или заработка через делегирование. Он также рассматривается как платежный токен, если внешние пользователи хотят потреблять услуги из сети Bittensor (например, платить TAO за запрос языковой модели в Bittensor), хотя внутренний механизм вознаграждения до сих пор был основной «экономикой». Общая философия стимулирования заключается в вознаграждении «ценного интеллекта» — то есть моделей, которые помогают производить хорошие ИИ-результаты — и в создании конкуренции, которая постоянно улучшает качество моделей в сети.

• Управление Gensyn: Модель управления Gensyn структурирована таким образом, чтобы развиваться от контроля основной команды к контролю сообщества по мере созревания сети. Первоначально Gensyn будет иметь Фонд Gensyn и избранный совет, который будет контролировать обновления протокола и решения по казначейству. Ожидается, что этот совет будет состоять из членов основной команды и ранних лидеров сообщества. Gensyn планирует Событие генерации токенов (TGE) для своего нативного токена (часто называемого GENS), после чего власть управления будет все больше переходить в руки держателей токенов через ончейн-голосование. Роль фонда заключается в представлении интересов протокола и обеспечении плавного перехода к полной децентрализации. На практике Gensyn, вероятно, будет иметь ончейн-механизмы предложений, где изменения параметров (например, длительность игры верификации, ставки комиссий) или обновления будут голосоваться сообществом. Поскольку Gensyn реализуется как роллап Ethereum, управление также может быть связано с безопасностью Ethereum (например, использование ключей обновления для контракта роллапа, которые в конечном итоге передаются DAO держателей токенов). Раздел децентрализации и управления в лайтпейпере Gensyn подчеркивает, что протокол в конечном итоге должен принадлежать всему миру, что соответствует этике, согласно которой «сеть для машинного интеллекта» должна принадлежать ее пользователям и участникам. В итоге, управление Gensyn начинается полуцентрализованным, но спроектировано так, чтобы стать DAO, где держатели токенов GENS (потенциально взвешенные по стейку или участию) принимают решения коллективно.

• Стимулы Gensyn: Экономические стимулы в Gensyn представляют собой прямую рыночную динамику, дополненную криптоэкономической безопасностью. Разработчики (клиенты) платят за ML-задачи в токене Gensyn, а Решатели зарабатывают токены, правильно выполняя эти задачи. Цена за вычислительные циклы определяется открытым рынком — предположительно, разработчики могут выставлять задачи с вознаграждением, а решатели могут делать ставки или просто брать задачу, если цена соответствует их ожиданиям. Это гарантирует, что пока есть предложение свободных GPU, конкуренция будет снижать стоимость до справедливой ставки (команда Gensyn прогнозирует снижение затрат до 80% по сравнению с облачными ценами, поскольку сеть находит самое дешевое доступное оборудование по всему миру). С другой стороны, решатели заинтересованы в заработке токенов за работу; их оборудование, которое иначе простаивало бы, теперь приносит доход. Для обеспечения качества Gensyn требует от решателей стейкать залог при выполнении задания — если они обманывают или производят неверный результат и их ловят, они теряют этот стейк (он может быть сокращен и передан честному верификатору). Верификаторы стимулируются возможностью получить «джекпот» в случае поимки мошеннического решателя, аналогично дизайну Truebit, который периодически вознаграждает верификаторов, успешно выявляющих неверные вычисления. Это поддерживает честность решателей и мотивирует некоторые узлы действовать как наблюдатели. В оптимальном сценарии (без мошенничества) решатели просто получают плату за задачу, а роль верификатора в основном простаивает (или один из участвующих решателей может выступать в качестве верификатора для других). Токен Gensyn, таким образом, служит как валютой для оплаты газа для покупки вычислений, так и залоговым стейком, который обеспечивает безопасность протокола. В лайтпейпере упоминается тестовая сеть с неперманентными токенами и то, что ранние участники тестовой сети будут вознаграждены на TGE реальными токенами. Это указывает на то, что Gensyn выделил часть предложения токенов для бустрапинга — вознаграждения ранних пользователей, тестовых решателей и членов сообщества. В долгосрочной перспективе плата за реальные задания должна поддерживать сеть. Также может быть небольшая протокольная комиссия (процент от каждого платежа за задачу), которая поступает в казну или сжигается; эта деталь пока не подтверждена, но многие протоколы маркетплейсов включают комиссию для финансирования разработки или выкупа и сжигания токенов. В итоге, стимулы Gensyn согласованы вокруг честного выполнения ML-заданий: выполняй работу, получай оплату; пытайся обмануть, теряй стейк; проверяй других, зарабатывай, если поймаешь мошенников. Это создает саморегулирующуюся экономическую систему, направленную на достижение надежных распределенных вычислений.

• Управление Cuckoo: Cuckoo Network с самого начала встроила управление в свою экосистему, хотя оно все еще находится на стадии развития. Токен $CAI явно является токеном управления в дополнение к его утилитарным ролям. Философия Cuckoo заключается в том, что операторы узлов GPU, разработчики приложений и даже конечные пользователи должны иметь право голоса в развитии сети — это отражает ее видение, ориентированное на сообщество. На практике важные решения (например, обновления протокола или экономические изменения) будут приниматься путем голосования, взвешенного по токенам, предположительно через механизм DAO. Например, Cuckoo может проводить ончейн-голосования за изменение распределения вознаграждений или внедрение новой функции, и держатели$CAI (включая майнеров, разработчиков и пользователей) будут голосовать. Уже сейчас ончейн-голосование используется как система репутации: Cuckoo требует, чтобы каждая роль стейкала токены, а затем члены сообщества могут голосовать (возможно, делегируя стейк или через модули управления) за то, какие координаторы или майнеры заслуживают доверия. Это влияет на оценки репутации и может влиять на планирование задач (например, координатор с большим количеством голосов может привлекать больше пользователей, или майнер с большим количеством голосов может получать больше задач). Это сочетание управления и стимулов — использование токенов управления для установления доверия. Фонд Cuckoo или основная команда до сих пор руководили направлением проекта (например, приняли недавнее решение о прекращении поддержки цепи L1), но их блог указывает на приверженность переходу к децентрализованному владению. Они определили, что запуск собственной цепи повлек за собой высокие накладные расходы, и что переход на роллап позволит более открытую разработку и интеграцию с существующими экосистемами. Вероятно, что после перехода на общий уровень (например, Ethereum) Cuckoo реализует более традиционный DAO для обновлений, при этом сообщество будет голосовать с использованием CAI.

• Стимулы Cuckoo: Дизайн стимулов для Cuckoo имеет две фазы: начальная фаза бустрапинга с фиксированными распределениями токенов и будущее состояние с распределением доходов, зависящим от использования. При запуске Cuckoo провела «честный запуск» распределения 1 миллиарда токенов CAI. 51% предложения было выделено для сообщества, распределено следующим образом:

  • Вознаграждения за майнинг: 30% от общего предложения зарезервировано для оплаты GPU-майнерам за выполнение ИИ-задач.
  • Вознаграждения за стейкинг: 11% предложения для тех, кто стейкает и помогает обеспечивать безопасность сети.
  • Аирдропы: 5% для ранних пользователей и членов сообщества в качестве стимула к принятию.
  • (Еще 5% было выделено на гранты для разработчиков для поощрения создания на Cuckoo.)

  Это большое распределение означало, что на ранних этапах сети майнеры и стейкеры вознаграждались из пула эмиссии, даже если фактический пользовательский спрос был низким. Действительно, на начальном этапе Cuckoo предлагала высокую APY-доходность за стейкинг и майнинг, что успешно привлекало участников, но также и «фармеров доходности», которые были там только ради токенов. Команда отметила, что многие пользователи ушли, как только ставки вознаграждения упали, что указывает на то, что эти стимулы не были связаны с реальным использованием. Учитывая это, Cuckoo переходит к модели, где вознаграждения напрямую коррелируют с реальной ИИ-нагрузкой. В будущем (и частично уже сейчас), когда конечный пользователь платит за ИИ-вывод, этот платеж (в CAI или, возможно, другом принятом токене, конвертированном в CAI) будет разделен между участниками:

  • GPU-майнеры получат большую часть за предоставленные вычисления.
  • Координатор (разработчик приложения) получит часть как поставщик услуг, который предоставил модель и обработал запрос.
  • Стейкеры, которые делегировали этим майнерам или координаторам, могут получить небольшую долю или инфляционное вознаграждение, чтобы продолжать стимулировать поддержку надежных узлов.
  • Сеть/Казначейство может удерживать комиссию за текущую разработку или для финансирования будущих стимулов (или комиссия может быть нулевой/номинальной для максимизации доступности для пользователей).

  По сути, Cuckoo переходит к модели распределения доходов: если ИИ-приложение на Cuckoo приносит доход, этот доход распределяется между всеми участниками этого сервиса справедливым образом. Это согласовывает стимулы таким образом, что участники получают выгоду от фактического использования, а не только от инфляции. Уже сейчас сеть требовала от всех сторон стейкать CAI — это означает, что майнеры и координаторы зарабатывают не только фиксированное вознаграждение, но и, возможно, вознаграждения на основе стейка (например, координатор может зарабатывать больше, если многие пользователи стейкают на него или если он сам стейкает больше, аналогично тому, как зарабатывают валидаторы Proof-of-Stake). Что касается стимулов для пользователей, Cuckoo также представила такие вещи, как портал аирдропов и краны (которые некоторые пользователи обманывали) для стимулирования начальной активности. В будущем пользователи могут быть стимулированы через токен-ребейты за использование услуг или через вознаграждения за управление за участие в курировании (например, возможно, зарабатывая небольшие токены за оценку выходов или предоставление данных). Суть в том, что токен Cuckoo ($CAI) является многоцелевым: это токен газа/комиссии в цепи (все транзакции и платежи используют его), он используется для стейкинга и голосования, и это единица вознаграждения за выполненную работу. Cuckoo явно упоминает, что хочет привязать токен-вознаграждения к KPI на уровне сервиса (ключевым показателям производительности) — например, времени безотказной работы, пропускной способности запросов, удовлетворенности пользователей — чтобы избежать чисто спекулятивных стимулов. Это отражает созревание токеномики от простого майнинга ликвидности к более устойчивой, ориентированной на полезность модели.

Владение моделями и атрибуция ИС​

Обработка интеллектуальной собственности (ИС) и прав собственности на ИИ-модели является сложным аспектом децентрализованных ИИ-сетей. Каждая платформа заняла несколько иную позицию, и в целом это развивающаяся область, пока не имеющая полного решения:

• Bittensor: Модели в Bittensor предоставляются узлами-майнерами, и эти майнеры сохраняют полный контроль над весами своих моделей (которые никогда не публикуются в ончейне). Bittensor явно не отслеживает, кто «владеет» моделью, помимо того факта, что она работает по определенному адресу кошелька. Если майнер уходит, его модель уходит вместе с ним. Таким образом, атрибуция ИС в Bittensor происходит офчейн: если майнер использует проприетарную модель, в ончейне нет ничего, что бы это обеспечивало или даже знало. Философия Bittensor поощряет открытые вклады (многие майнеры могут использовать модели с открытым исходным кодом, такие как GPT-J или другие), и сеть вознаграждает производительность этих моделей. Можно сказать, что Bittensor создает репутационную оценку для моделей (через рейтинги валидаторов), и это является формой признания ценности модели, но права на саму модель не токенизируются и не распределяются. Примечательно, что владельцы подсетей в Bittensor могут рассматриваться как владельцы части ИС: они определяют задачу (которая может включать набор данных или метод). Владелец подсети выпускает NFT (называемый UID подсети) при создании подсети, и этот NFT дает ему право на 18% вознаграждений в этой подсети. Это фактически токенизирует создание маркетплейса моделей (подсети), если не экземпляров моделей. Если определение подсети (скажем, задача распознавания речи с определенным набором данных) рассматривать как ИС, то это по крайней мере записывается и вознаграждается. Но индивидуальные веса моделей, которые обучают майнеры — записи о владении ими в ончейне нет. Атрибуция происходит в виде вознаграждений, выплачиваемых на адрес этого майнера. Bittensor в настоящее время не реализует систему, где, например, несколько человек могли бы совместно владеть моделью и получать автоматическую долю дохода — человек, запускающий модель (майнер), получает вознаграждение, и от него зависит, соблюдать ли офчейн любые лицензии ИС на используемую им модель.

• Gensyn: В Gensyn владение моделями прямолинейно: отправитель (тот, кто хочет обучить модель) предоставляет архитектуру модели и данные, и после обучения получает результирующий артефакт модели. Решатели, выполняющие работу, не имеют прав на модель; они подобны подрядчикам, получающим оплату за услугу. Протокол Gensyn, таким образом, предполагает традиционную модель ИС: если у вас были законные права на модель и данные, которые вы предоставили, они остаются у вас после обучения — вычислительная сеть не претендует на какое-либо владение. Gensyn упоминает, что маркетплейс также может торговать алгоритмами и данными, как и любым другим ресурсом. Это намекает на сценарий, когда кто-то может предложить модель или алгоритм для использования в сети, возможно, за плату, тем самым токенизируя доступ к этой модели. Например, создатель модели может разместить свою предварительно обученную модель на Gensyn и позволить другим дообучать ее через сеть за плату (это фактически монетизировало бы ИС модели). Хотя протокол не обеспечивает соблюдение условий лицензии, можно закодировать требования к оплате: смарт-контракт может требовать плату для разблокировки весов модели для решателя. Однако это спекулятивные варианты использования — основной дизайн Gensyn заключается в обеспечении выполнения задач обучения. Что касается атрибуции, если несколько сторон вносят вклад в модель (скажем, одна предоставляет данные, другая — вычисления), это, вероятно, будет регулироваться любым контрактом или соглашением, которое они заключили до использования Gensyn (например, смарт-контракт может разделить платеж между поставщиком данных и поставщиком вычислений). Сам Gensyn не отслеживает в ончейне «эта модель была создана X, Y, Z» помимо записи о том, какие адреса были оплачены за работу. В итоге, ИС модели в Gensyn остается у отправителя, и любая атрибуция или лицензирование должны обрабатываться через юридические соглашения вне протокола или через пользовательские смарт-контракты, построенные поверх него.

• Cuckoo: В экосистеме Cuckoo создатели моделей (разработчики ИИ-приложений) являются первоклассными участниками — они развертывают ИИ-сервис. Если разработчик приложения дообучает языковую модель или разрабатывает пользовательскую модель и размещает ее на Cuckoo, эта модель по сути является его собственностью, и он выступает в качестве владельца сервиса. Cuckoo не захватывает никакого владения; вместо этого она предоставляет инфраструктуру для монетизации использования. Например, если разработчик развертывает чат-бота с ИИ, пользователи могут взаимодействовать с ним, и разработчик (плюс майнеры) зарабатывают CAI от каждого взаимодействия. Таким образом, платформа приписывает доход от использования создателю модели, но не публикует явно веса модели и не превращает их в NFT. Фактически, для запуска модели на GPU майнеров узел-координатор, вероятно, должен отправить модель (или среду выполнения) майнеру в какой-либо форме. Это вызывает вопросы ИС: может ли злонамеренный майнер скопировать веса модели и распространить их? В децентрализованной сети такой риск существует, если используются проприетарные модели. Текущий фокус Cuckoo был на достаточно открытых моделях (Stable Diffusion, модели, производные от LLaMA и т. д.) и на создании сообщества, поэтому мы еще не видели обеспечения прав ИС через смарт-контракты. Платформа потенциально может интегрировать такие инструменты, как зашифрованное выполнение моделей или защищенные анклавы в будущем для защиты ИС, но в документации ничего конкретного не упоминается. Что она действительно отслеживает, так это кто предоставил сервис модели для каждой задачи — поскольку координатор является ончейн-идентичностью, все использование его модели учитывается ему, и он автоматически получает свою долю вознаграждений. Если бы кто-то передал или продал модель кому-то другому, он фактически передал бы контроль над узлом-координатором (возможно, даже просто передал бы ему приватный ключ или NFT, если роль координатора была токенизирована). В настоящее время общественное владение моделями (через доли токенов) не реализовано, но видение Cuckoo намекает на децентрализованный ИИ, управляемый сообществом, поэтому они могут изучить возможность позволить людям коллективно финансировать или управлять ИИ-моделью. Токенизация моделей за пределами индивидуального владения все еще является открытой областью в этих сетях — это признается целью (позволить сообществам владеть ИИ-моделями, а не корпорациям), но на практике это требует решений для вышеупомянутых проблем ИС и верификации.

В итоге, владение моделями в Bittensor, Gensyn и Cuckoo обрабатывается офчейн традиционными способами: лицо или сущность, запускающая или отправляющая модель, фактически является владельцем. Сети обеспечивают атрибуцию в виде экономических вознаграждений (оплачивая вкладчику модели его ИС или усилия). Ни одна из трех платформ пока не имеет встроенной лицензии или механизма принудительного взимания роялти за использование модели на уровне смарт-контракта. Атрибуция происходит через репутацию и вознаграждение: например, лучшие модели Bittensor получают высокие оценки репутации (что является публичной записью) и больше TAO, что является неявным кредитом их создателям. Со временем мы можем увидеть такие функции, как веса моделей, привязанные к NFT, или децентрализованные лицензии для лучшего отслеживания ИС, но в настоящее время приоритетом является обеспечение функционирования сетей и стимулирование вкладов. Все согласны с тем, что проверка происхождения и выходов моделей является ключом к созданию настоящих рынков активов моделей, и исследования в этом направлении продолжаются.

Структуры распределения доходов​

Все три платформы должны решить, как разделить экономический пирог, когда несколько сторон сотрудничают для получения ценного ИИ-выхода. Кто получает оплату и сколько, когда используется ИИ-сервис или когда выпускаются токены? Каждая имеет свою уникальную модель распределения доходов:

• Bittensor: Как упоминалось в разделе о стимулах, распределение доходов Bittensor определяется протоколом на уровне блоков: 41% майнерам, 41% валидаторам, 18% владельцу подсети за каждый выпуск TAO в блоке. Это фактически встроенное распределение доходов для ценности, генерируемой в каждой подсети. Доля владельца подсети (18%) действует как роялти за «дизайн модели/задачи» или за бустрапинг экосистемы этой подсети. Майнеры и валидаторы, получающие равные доли, гарантируют, что без валидации майнеры не получают вознаграждения (и наоборот) — они симбиотичны, и каждый получает равную часть выпущенных вознаграждений. Если мы рассмотрим внешнего пользователя, платящего TAO за запрос модели, в вайтпейпере Bittensor предполагается, что этот платеж также будет аналогично разделен между майнером, который отвечает, и валидаторами, которые помогли проверить ответ (точное разделение может быть определено протоколом или рыночными силами). Кроме того, делегаторы, которые стейкают на майнеров/валидаторов, фактически являются партнерами — как правило, майнер/валидатор делится процентом своего заработанного TAO со своими делегаторами (это настраивается, но часто большая часть достается делегаторам). Таким образом, если майнер заработал 1 TAO за блок, это может быть разделено, например, 80/20 между его делегаторами и им самим, в зависимости от стейка. Это означает, что даже не-операторы получают долю дохода сети пропорционально своей поддержке. С введением dTAO был добавлен еще один уровень распределения: те, кто стейкает в пул подсети, получают альфа-токены, которые дают им право на часть эмиссии этой подсети (подобно фармингу доходности). По сути, любой может сделать ставку на успех конкретной подсети и получать долю вознаграждений майнеров/валидаторов, владея альфа-токенами (альфа-токены дорожают по мере того, как подсеть привлекает больше использования и эмиссии). В итоге, распределение доходов Bittensor фиксировано кодом для основных ролей и далее распределяется по социальным/стейкинговым соглашениям. Это относительно прозрачное, основанное на правилах разделение — каждый блок участники точно знают, как распределяется 1 TAO, и, таким образом, знают свой «заработок» за вклад. Эта ясность является одной из причин, по которой Bittensor иногда сравнивают с Биткойном для ИИ — детерминированная денежная эмиссия, где вознаграждение участников математически установлено.

• Gensyn: Распределение доходов в Gensyn более динамично и ориентировано на рынок, поскольку задачи оцениваются индивидуально. Когда отправитель создает задание, он прикрепляет вознаграждение (скажем, X токенов), которое он готов заплатить. Решатель, который выполняет задание, получает эти X (за вычетом любой сетевой комиссии). Если задействован верификатор, обычно действует правило: если мошенничество не обнаружено, решатель сохраняет полную оплату; если мошенничество обнаружено, решатель подвергается слэшингу — теряя часть или весь свой стейк — и эта сокращенная сумма передается верификатору в качестве вознаграждения. Таким образом, верификаторы не зарабатывают на каждой задаче, только когда они ловят плохой результат (плюс, возможно, небольшая базовая комиссия за участие, в зависимости от реализации). Здесь нет встроенной концепции оплаты владельцу модели, потому что предполагается, что отправитель либо является владельцем модели, либо имеет права на ее использование. Можно представить сценарий, когда отправитель дообучает чью-то предварительно обученную модель, и часть платежа идет первоначальному создателю модели — но это должно быть обработано вне протокола (например, по соглашению или отдельному смарт-контракту, который соответствующим образом делит платеж в токенах). Распределение на уровне протокола Gensyn, по сути, происходит по схеме клиент -> решатель (-> верификатор). Модель токена, вероятно, включает некоторое распределение для казначейства протокола или фонда; например, небольшой процент от платежа за каждую задачу может идти в казну, которая может использоваться для финансирования разработки или страховых пулов (это не указано явно в доступных документах, но многие протоколы так делают). Кроме того, на ранних этапах Gensyn может субсидировать решателей через инфляцию: пользователям тестовой сети обещаны вознаграждения при TGE, что фактически является долей дохода от первоначального распределения токенов (ранние решатели и сторонники получают часть токенов за помощь в бустрапинге, сродни аирдропу или вознаграждению за майнинг). Со временем, по мере того как реальные задания будут доминировать, инфляционные вознаграждения будут сокращаться, а доход решателей будет в основном поступать от пользовательских платежей. Подход Gensyn можно резюмировать как модель дохода «плата за услугу»: сеть облегчает прямую оплату от тех, кому нужна работа, тем, кто ее выполняет, при этом верификаторы и, возможно, стейкеры токенов получают доли только тогда, когда они играют роль в обеспечении этой услуги.

• Cuckoo: Распределение доходов Cuckoo развивалось. Изначально, поскольку не было много платящих конечных пользователей, распределение доходов по сути было распределением инфляции: 30% на майнинг и 11% на стейкинг из предложения токенов означали, что майнеры и стейкеры делили токены, выпущенные пулом честного запуска сети. На практике Cuckoo осуществляла такие вещи, как ежедневные выплаты CAI майнерам пропорционально выполненным задачам. Эти выплаты в основном поступали из выделения вознаграждений за майнинг (которое является частью зарезервированного фиксированного предложения). Это похоже на то, как многие блокчейны уровня 1 распределяют вознаграждения за блоки майнерам/валидаторам — это не было привязано к фактическому использованию внешними пользователями, это было скорее для стимулирования участия и роста. Однако, как подчеркивается в их блоге от июля 2025 года, это привело к использованию, которое стимулировалось фармингом токенов, а не реальным спросом. Следующий этап для Cuckoo — это настоящая модель распределения доходов, основанная на платах за услуги. В этой модели, когда конечный пользователь использует, скажем, сервис генерации изображений и платит $1 (в криптовалютном выражении), эти токены на $1 будут разделены, возможно, следующим образом: 0,70 майнеру, который выполнил работу на GPU, 0,20 разработчику приложения (координатору), который предоставил модель и интерфейс, и 0,10 стейкерам или казначейству сети. (Примечание: точные соотношения гипотетические; Cuckoo еще не опубликовала их, но это иллюстрирует концепцию.) Таким образом, все участники предоставления услуги получают долю дохода. Это аналогично, например, экономике совместных поездок, но для ИИ: транспортное средство (GPU-майнер) получает большую часть, водитель или платформа (координатор, создавший сервис модели) получает долю, и, возможно, управление/стейкеры платформы получают небольшую комиссию. Упоминание Cuckoo о «моделях распределения доходов и токен-вознаграждениях, напрямую привязанных к метрикам использования» предполагает, что если конкретный сервис или узел обрабатывает большой объем, его операторы и сторонники будут зарабатывать больше. Они отходят от фиксированной доходности за простое блокирование токенов (что было в случае с их начальной APY за стейкинг). В конкретных терминах: если вы стейкаете на координатора, который в итоге обеспечивает работу очень популярного ИИ-приложения, вы можете заработать часть комиссий этого приложения — сценарий стейкинга как инвестирования в полезность, а не стейкинга просто ради инфляции. Это согласовывает стимулы всех участников на привлечение реальных пользователей, которые платят за ИИ-сервисы, что, в свою очередь, возвращает ценность держателям токенов. Стоит отметить, что цепочка Cuckoo также имела комиссии за транзакции (газ), поэтому майнеры, которые производили блоки (изначально GPU-майнеры также способствовали производству блоков в цепочке Cuckoo), также получали комиссии за газ. С закрытием цепочки и миграцией на роллап комиссии за газ, вероятно, будут минимальными (или на Ethereum), поэтому основным доходом станут сами комиссии за ИИ-сервисы. В итоге, Cuckoo переходит от модели, основанной на субсидиях (сеть платит участникам из своего пула токенов), к модели, основанной на спросе (участники зарабатывают на фактических платежах пользователей). Токен по-прежнему будет играть роль в стейкинге и управлении, но ежедневный заработок майнеров и разработчиков приложений должен все больше поступать от пользователей, покупающих ИИ-сервисы. Эта модель более устойчива в долгосрочной перспективе и тесно отражает распределение доходов SaaS в Web2, но реализована через смарт-контракты и токены для прозрачности.

Поверхности атаки и уязвимости​

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

• Атаки Сивиллы (фальшивые личности): В открытой сети злоумышленник может создать множество личностей (узлов), чтобы получить непропорциональные вознаграждения или влияние.

  • Bittensor: Устойчивость к атакам Сивиллы обеспечивается в основном стоимостью входа. Для регистрации нового майнера или валидатора в Bittensor необходимо потратить или застейкать TAO — это может быть сжигание или требование залога. Это означает, что создание N фальшивых узлов влечет за собой N-кратные затраты, что делает крупные рои Сивиллы дорогостоящими. Кроме того, консенсус Bittensor связывает влияние со стейком и производительностью; Сивилла без стейка или с плохой производительностью мало зарабатывает. Злоумышленнику придется вложить значительные средства, а также заставить свои узлы Сивиллы фактически вносить полезную работу, чтобы получить какое-либо значительное вознаграждение (что не является типичной стратегией Сивиллы). Тем не менее, если у злоумышленника действительно много капитала, он может приобрести большинство TAO и зарегистрировать много валидаторов или майнеров — фактически, Сивилла за счет богатства. Это пересекается со сценарием атаки 51%: если одна сущность контролирует >50% застейканных TAO в подсети, она может сильно повлиять на консенсус. Введение dTAO в Bittensor немного помогает здесь: оно распределяет влияние по подсетям и требует поддержки сообщества для процветания подсетей, что затрудняет контроль над всем одной сущности. Тем не менее, атаки Сивиллы со стороны хорошо финансируемого противника остаются проблемой — анализ Arxiv явно отмечает, что стейк сейчас довольно сконцентрирован, поэтому барьер для атаки большинства не так высок, как хотелось бы. Для смягчения этой проблемы были предложены такие меры, как ограничения на стейк для каждого кошелька (например, ограничение эффективного стейка 88-м процентилем для предотвращения доминирования одного кошелька). В итоге, Bittensor полагается на идентичность, взвешенную по стейку (вы не можете дешево создавать личности без пропорционального стейка) для борьбы с Сивиллами; это достаточно эффективно, за исключением очень ресурсного злоумышленника.
  • Gensyn: Атаки Сивиллы в Gensyn проявились бы в том, что злоумышленник запускает множество узлов-решателей или верификаторов, чтобы обмануть систему. Защита Gensyn является чисто экономической и криптографической — сами по себе личности не имеют значения, но выполнение работы или внесение залога имеют. Если злоумышленник создает 100 фальшивых узлов-решателей, но у них нет заданий или стейка, они ничего не добьются. Чтобы выиграть задачи, узел Сивиллы должен будет конкурировать в ставках и иметь оборудование для выполнения работы. Если они занижают ставки без достаточной мощности, они потерпят неудачу и потеряют стейк. Аналогично, злоумышленник может создать множество верификаторов, надеясь быть выбранным для проверки (если протокол случайным образом выбирает верификаторов). Но если их слишком много, сеть или отправитель задания могут ограничить количество активных верификаторов. Кроме того, верификаторам, возможно, придется выполнять вычисления для проверки, что дорого; наличие множества фальшивых верификаторов не поможет, если вы не можете фактически проверять результаты. Более актуальный аспект атаки Сивиллы в Gensyn заключается в том, что злоумышленник пытается заполнить сеть поддельными заданиями или ответами, чтобы потратить время других. Это смягчается требованием депозита и от отправителей (злонамеренный отправитель, размещающий фальшивые задания, теряет свою оплату или депозит). В целом, использование Gensyn обязательных стейков/залогов и случайного выбора для верификации означает, что злоумышленник мало что получает от наличия нескольких личностей, если он также не приносит пропорциональные ресурсы. Это становится более дорогостоящей атакой, а не дешевой. Оптимистическая модель безопасности предполагает наличие хотя бы одного честного верификатора — Сивиллы должны будут подавить и быть всеми верификаторами, чтобы постоянно обманывать, что снова сводится к владению большинством стейка или вычислительной мощности. Устойчивость Gensyn к атакам Сивиллы, таким образом, сравнима с устойчивостью оптимистического роллапа: пока есть хотя бы один честный актор, Сивиллы не могут легко причинить системный вред.
  • Cuckoo: Предотвращение атак Сивиллы в Cuckoo основано на стейкинге и проверке сообществом. Каждая роль в Cuckoo (майнер, координатор, даже пользователь в некоторых случаях) требует стейкинга $CAI. Это немедленно увеличивает стоимость личностей Сивиллы — злоумышленнику, создающему 100 фиктивных майнеров, потребуется приобрести и заблокировать стейк для каждого. Более того, дизайн Cuckoo имеет человеческий/общественный элемент: новые узлы должны зарабатывать репутацию через ончейн-голосование. Армия Сивиллы из новых узлов без репутации вряд ли получит много задач или доверия пользователей. Координаторы, в частности, должны привлекать пользователей; фальшивый координатор без послужного списка не получит использования. Для майнеров координаторы могут видеть их статистику производительности (успешные задачи и т. д.) на Cuckoo Scan и будут предпочитать надежных майнеров. Cuckoo также имела относительно небольшое количество майнеров (40 GPU в один момент в бета-версии), поэтому любой странный приток множества узлов был бы заметен. Потенциально слабым местом является то, что злоумышленник также использует систему репутации — например, он стейкает много CAI на своих узлах Сивиллы, чтобы они выглядели респектабельными, или создает фальшивые «пользовательские» учетные записи, чтобы голосовать за себя. Это теоретически возможно, но поскольку все это курируется токенами, это стоит токенов (вы, по сути, будете голосовать своим собственным стейком за свои собственные узлы). Команда Cuckoo также может корректировать параметры стейкинга и вознаграждений, если наблюдается поведение Сивиллы (особенно сейчас, когда она становится более централизованным сервисом роллапа; они могут приостанавливать или сокращать плохих акторов). В целом, Сивиллы сдерживаются требованием «шкурного интереса» (стейка) и необходимостью одобрения сообщества. Никто не может просто так прийти с сотнями фальшивых GPU и получать вознаграждения без значительных инвестиций, которые честные участники могли бы лучше потратить на реальное оборудование и стейк.

• Сговор: Здесь мы рассматриваем сговор нескольких участников для обмана системы — например, сговор валидаторов и майнеров в Bittensor, или решателей и верификаторов в Gensyn и т. д.

  • Bittensor: Сговор был признан реальной проблемой. В первоначальном дизайне несколько валидаторов могли сговориться, чтобы всегда одобрять определенных майнеров или самих себя, несправедливо искажая распределение вознаграждений (это наблюдалось как концентрация власти в корневой подсети). Консенсус Yuma обеспечивает некоторую защиту: принимая медиану оценок валидаторов и наказывая тех, кто отклоняется, он предотвращает драматическое повышение целевого объекта небольшой сговорившейся группой, если только они не составляют большинство. Другими словами, если 3 из 10 валидаторов сговариваются, чтобы дать майнеру очень высокую оценку, но остальные 7 этого не делают, оценки сговорщиков-выбросов отсекаются, и вознаграждение майнера основывается на медианной оценке (таким образом, сговор не помогает значительно). Однако, если сговорщики составляют >50% валидаторов (или >50% стейка среди валидаторов), они фактически являются консенсусом — они могут договориться о ложных высоких оценках, и медиана будет отражать их точку зрения. Это классический сценарий атаки 51%. К сожалению, исследование Arxiv показало, что в некоторых подсетях Bittensor коалиция всего 1–2% участников (по количеству) контролировала большинство стейка из-за высокой концентрации токенов. Это означает, что сговор нескольких крупных держателей был реальной угрозой. Смягчение, которое Bittensor преследует через dTAO, заключается в демократизации влияния: позволяя любому держателю TAO направлять стейк в подсети, это разбавляет власть закрытых групп валидаторов. Также предложения, такие как вогнутый стейкинг (уменьшающаяся отдача от чрезмерного стейка) и ограничения на стейк, направлены на то, чтобы лишить одну сговорившуюся сущность возможности собрать слишком много голосующей силы. Предположение безопасности Bittensor теперь аналогично Proof-of-Stake: ни одна сущность (или картель) не контролирует >50% активного стейка. Пока это сохраняется, сговор ограничен, потому что честные валидаторы будут отменять плохие оценки, а сговорившиеся владельцы подсетей не могут произвольно увеличивать свои собственные вознаграждения. Наконец, что касается сговора между владельцами подсетей и валидаторами (например, владелец подсети подкупает валидаторов, чтобы они высоко оценивали майнеров его подсети), dTAO устраняет прямой контроль валидаторов, заменяя его решениями держателей токенов. Сговориться с «рынком» сложнее, если только вы не выкупите все предложение токенов — в этом случае это не совсем сговор, это поглощение. Таким образом, основной метод борьбы со сговором в Bittensor — это алгоритмический консенсус (отсечение медианы) и широкое распределение токенов.
  • Gensyn: Сговор в Gensyn, вероятно, будет включать сговор решателя и верификатора (или нескольких верификаторов) для обмана системы. Например, решатель может произвести поддельный результат, а сговорившийся верификатор может намеренно не оспаривать его (или даже подтвердить, что он правильный, если протокол просил верификаторов подписать). Для смягчения этого, модель безопасности Gensyn требует наличия хотя бы одного честного верификатора. Если все верификаторы сговариваются с решателем, то плохой результат остается неоспоренным. Gensyn решает эту проблему, поощряя множество независимых верификаторов (любой может верифицировать) и используя теорию игр, согласно которой верификатор может получить большое вознаграждение, выйдя из сговора и оспорив (потому что он получит стейк решателя). По сути, даже если есть группа, согласившаяся на сговор, у каждого члена есть стимул дезертировать и забрать награду себе — это классическая дилемма заключенного. Надежда состоит в том, что это сохраняет группы сговорщиков небольшими или неэффективными. Другой потенциальный сговор — между несколькими решателями для повышения цен или монополизации задач. Однако, поскольку разработчики могут выбирать, куда размещать задачи (и задачи не являются идентичными единицами, которые можно легко монополизировать), сговор решателей по ценам было бы трудно координировать глобально — любой не сговорившийся решатель мог бы предложить более низкую цену, чтобы выиграть работу. Динамика открытого рынка противодействует ценовому сговору, предполагая наличие хотя бы нескольких конкурентоспособных участников. Еще один аспект: сговор верификаторов для «гриферства» решателей — например, верификаторы ложно обвиняют честных решателей, чтобы украсть их стейк. Доказательство мошенничества Gensyn является бинарным и ончейн; ложное обвинение потерпит неудачу, когда ончейн-пересчет не обнаружит ошибки, и предположительно злонамеренный верификатор тогда что-то потеряет (возможно, депозит или репутацию). Таким образом, сговор верификаторов, пытающихся саботировать решателей, будет пойман процессом верификации протокола. В итоге, архитектура Gensyn надежна, пока хотя бы одна сторона в любом сговорившемся наборе имеет стимул быть честной — свойство оптимистической верификации, аналогичное требованию наличия одного честного майнера в Биткойне, чтобы в конечном итоге разоблачить мошенничество. Сговор теоретически возможен, если злоумышленник сможет контролировать всех верификаторов и решателей в задаче (как большинство сети), но тогда они могли бы просто обманывать без необходимости сговора как такового. Криптоэкономические стимулы устроены так, чтобы поддержание сговора было иррациональным.
  • Cuckoo: Сговор в Cuckoo может произойти несколькими способами:
    1. Координатор в сговоре с майнерами — например, координатор может всегда назначать задачи группе дружественных майнеров и делить вознаграждения, игнорируя других честных майнеров. Поскольку координаторы имеют право по своему усмотрению планировать задачи, это может произойти. Однако, если дружественные майнеры работают некачественно, конечные пользователи могут заметить медленное или плохое обслуживание и уйти, поэтому координатор не заинтересован в чистом фаворитизме, который вредит качеству. Если сговор направлен на манипулирование вознаграждениями (скажем, отправку фальшивых задач для выдачи токенов майнерам), это будет обнаружено в ончейне (много задач с, возможно, идентичными входными данными или без фактического пользователя) и может быть наказано. Ончейн-прозрачность Cuckoo означает, что любые необычные паттерны могут быть отмечены сообществом или основной командой. Кроме того, поскольку все участники стейкают, сговорившееся кольцо координатор-майнер рискует потерять свой стейк, если будет поймано на злоупотреблении системой (например, если управление решит сократить их за мошенничество).
    2. Майнеры сговариваются между собой — они могут обмениваться информацией или формировать картель, чтобы, скажем, голосовать друг за друга в репутационной системе или все отказываться обслуживать определенного координатора, чтобы получить более высокие комиссии. Эти сценарии менее вероятны: голосование за репутацию осуществляется стейкерами (включая пользователей), а не самими майнерами, голосующими друг за друга. А отказ от обслуживания только заставит координаторов искать других майнеров или поднимет тревогу. Учитывая относительно небольшой текущий масштаб, любой сговор будет трудно скрыть.
    3. Сговор с целью манипулирования управлением — крупные держатели CAI могут сговориться, чтобы принять предложения в свою пользу (например, установить непомерную комиссию или перенаправить казну). Это риск в любом токен-управлении. Лучшее смягчение — это широкое распределение токена (честный запуск Cuckoo отдал 51% сообществу) и активный надзор со стороны сообщества. Кроме того, поскольку Cuckoo отказалась от L1, непосредственное ончейн-управление может быть ограничено, пока они не перейдут на новую цепь; команда, вероятно, сохраняет мультисиг-контроль в промежутке, что, по иронии судьбы, предотвращает сговор злонамеренных посторонних за счет временной централизации. В целом, Cuckoo опирается на прозрачность и стейкинг для борьбы со сговором. Существует элемент доверия к координаторам, чтобы они вели себя хорошо, потому что они хотят привлекать пользователей в конкурентной среде. Если сговор приводит к ухудшению обслуживания или очевидной игре с вознаграждениями, заинтересованные стороны могут проголосовать против или прекратить стейкинг на плохих акторов, а сеть может сократить или заблокировать их. Достаточно открытый характер (любой может стать координатором или майнером, если он стейкает) означает, что сговор потребует больших скоординированных усилий, которые будут очевидны. Это не так математически предотвращено, как в Bittensor или Gensyn, но сочетание экономического стейка и управления сообществом обеспечивает проверку.

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

  • Bittensor: Известной проблемой фрирайдерства в Bittensor является «копирование весов» ленивыми валидаторами. Валидатор может просто скопировать мнение большинства (или оценки другого валидатора) вместо независимой оценки майнеров. При этом они избегают затрат на выполнение ИИ-запросов, но все равно получают вознаграждение, если их представленные оценки соответствуют консенсусу. Bittensor борется с этим, измеряя согласованность консенсуса и информационный вклад каждого валидатора. Если валидатор всегда просто копирует других, он может хорошо согласовываться (поэтому его не сильно наказывают), но он не добавляет уникальной ценности. Разработчики протокола обсуждали предоставление более высоких вознаграждений валидаторам, которые предоставляют точные, но не чисто избыточные оценки. Такие методы, как «введение шума» (намеренное предоставление валидаторам немного разных запросов), могут заставить их фактически работать, а не копировать — хотя неясно, реализовано ли это. Arxiv предлагает методы взвешенной по производительности эмиссии и композитного скоринга для лучшей связи усилий валидатора с вознаграждением. Что касается майнеров, одним из возможных видов фрирайдерства было бы, если майнер запрашивает других майнеров и передает ответ (форма плагиата). Дизайн Bittensor (с децентрализованными запросами) может позволить модели майнера вызывать другие через свой собственный дендрит. Если майнер просто передает ответ другого, хороший валидатор может это заметить, потому что ответ может не соответствовать заявленным возможностям модели майнера. Это сложно обнаружить алгоритмически, но майнер, который никогда не вычисляет оригинальные результаты, в конечном итоге должен получить низкие оценки по некоторым запросам и потерять репутацию. Другой сценарий фрирайдерства — делегаторы, зарабатывающие вознаграждения без выполнения ИИ-работы. Это намеренно (для вовлечения держателей токенов), поэтому это не атака — но это означает, что часть эмиссии токенов идет людям, которые только стейкали. Bittensor оправдывает это как согласование стимулов, а не растраченные вознаграждения. Короче говоря, Bittensor признает проблему фрирайдерства валидаторов и настраивает стимулы (например, дает «оценки доверия валидаторов», которые повышают тех, кто не отклоняется и не копирует). Их решение, по сути, заключается в более явном вознаграждении за усилия и правильность, так что бездействие или слепое копирование со временем приносит меньше TAO.
  • Gensyn: В Gensyn фрирайдерам было бы трудно зарабатывать, потому что нужно либо предоставлять вычисления, либо ловить кого-то на мошенничестве, чтобы получить токены. Решатель не может «подделать» работу — он должен предоставить либо действительное доказательство, либо рискнуть быть сокращенным. Нет механизма получения оплаты без выполнения задачи. Верификатор теоретически может сидеть без дела и надеяться, что другие поймают мошенников — но тогда он ничего не заработает (потому что только тот, кто поднимает доказательство мошенничества, получает вознаграждение). Если слишком много верификаторов пытаются быть фрирайдерами (фактически не пересчитывают задачи), то мошеннический решатель может проскользнуть, потому что никто не проверяет. Дизайн стимулов Gensyn решает эту проблему с помощью джекпот-вознаграждения: достаточно одного активного верификатора, чтобы поймать мошенника и получить большую выплату, поэтому рационально, чтобы хотя бы один всегда выполнял работу. Другие, не выполняющие работу, не вредят сети, кроме как бесполезностью; они также не получают вознаграждения. Таким образом, система естественным образом отсеивает фрирайдеров: только те верификаторы, которые фактически верифицируют, будут получать прибыль в долгосрочной перспективе (другие тратят ресурсы на узлы впустую или очень редко случайно получают вознаграждение). Протокол также может рандомизировать, какой верификатор получает возможность оспорить, чтобы отговорить всех верификаторов от предположения «кто-то другой это сделает». Поскольку задачи оплачиваются индивидуально, нет аналога «вознаграждений за стейкинг без работы», кроме временных стимулов тестовой сети. Одна область, на которую стоит обратить внимание, — это оптимизация нескольких задач: решатель может попытаться повторно использовать работу между задачами или тайно передать ее кому-то более дешевому (например, использовать централизованное облако) — но это не совсем вредное фрирайдерство; если они предоставляют правильные результаты вовремя, неважно, как они это сделали. Это скорее арбитраж, чем атака. В итоге, дизайн механизма Gensyn оставляет мало места для фрирайдеров, потому что каждый распределенный токен соответствует выполненной работе или наказанному мошенничеству.
  • Cuckoo: Начальная фаза Cuckoo непреднамеренно создала проблему фрирайдерства: аирдроп и высокодоходный стейкинг привлекли пользователей, которые были там только для фарминга токенов. Эти пользователи циклически пропускали токены через краны или обманывали задачи аирдропа (например, постоянно используя бесплатные тестовые промпты или создавая множество учетных записей для получения вознаграждений), не внося вклад в долгосрочную ценность сети. Cuckoo признала это проблемой — по сути, люди «использовали» сеть не для ИИ-вывода, а для спекулятивной выгоды. Решение о прекращении поддержки цепочки L1 и переориентации было частично направлено на устранение этих несоответствий стимулов. Привязывая будущие токен-вознаграждения к фактическому использованию (т. е. вы зарабатываете, потому что сервис фактически используется платящими клиентами), привлекательность фрирайдерства уменьшается. Существует также сценарий фрирайдерства со стороны майнеров: майнер может присоединиться, получить назначенные задачи и каким-то образом не выполнить их, но все равно требовать вознаграждение. Однако координатор проверяет результаты — если майнер возвращает нулевой или плохой результат, координатор не будет считать это выполненной задачей, поэтому майнер не получит оплату. Майнеры также могут пытаться выбирать легкие задачи и отказываться от сложных (например, если некоторые промпты медленнее, майнер может отключиться, чтобы избежать их). Это может быть проблемой, но координаторы могут отмечать надежность майнера. Если майнер часто отключается, координатор может прекратить назначать ему задачи или сократить его стейк (если такой механизм существует или просто не вознаграждать его). Фрирайдерство пользователей — поскольку многие ИИ-сервисы имеют бесплатные пробные версии, пользователь может спамить запросы, чтобы получить выводы без оплаты (если есть субсидируемая модель). Это не столько проблема на уровне протокола, сколько на уровне сервиса; каждый координатор может решить, как обрабатывать бесплатное использование (например, требовать небольшую оплату или дросселировать). Поскольку Cuckoo изначально раздавала бесплатные услуги (например, бесплатную генерацию ИИ-изображений для привлечения пользователей), некоторые воспользовались этим, но это было частью ожидаемого маркетинга роста. По мере окончания этих акций пользователям придется платить, таким образом, не будет бесплатного обеда для эксплуатации. В целом, новая стратегия Cuckoo по привязке распределения токенов к реальной полезности явно направлена на устранение проблемы фрирайдерства «майнинга токенов за бессмысленные циклы».

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

  • Bittensor: Отравление данных в Bittensor означало бы, что майнер намеренно дает неверные или вредоносные ответы, или валидаторы целенаправленно неправильно оценивают хорошие ответы как плохие. Если майнер постоянно выдает мусор или вредоносный контент, валидаторы будут давать низкие оценки, и этот майнер будет мало зарабатывать и в конечном итоге отсеется — экономический стимул заключается в предоставлении качества, поэтому «отравление» других не приносит пользы злоумышленнику (если только его цель не чисто саботаж за свой счет). Может ли злонамеренный майнер отравить других? В Bittensor майнеры не обучают друг друга напрямую (по крайней мере, не по замыслу — нет глобальной модели, которая обновляется и может быть отравлена). Модель каждого майнера отдельна. Они учатся в том смысле, что майнер может брать интересные образцы у других для дообучения себя, но это полностью необязательно и зависит от каждого. Если злонамеренный актор спамит бессмысленные ответы, честные валидаторы отфильтруют это (они оценят это низко), поэтому это не окажет значительного влияния на процесс обучения любого честного майнера (плюс, майнер, вероятно, будет использовать знания высокооцененных коллег, а не низкооцененных). Таким образом, классическое отравление данных (введение плохих обучающих данных для повреждения модели) минимально в текущей настройке Bittensor. Более актуальным риском является манипуляция ответами модели: например, майнер, который выдает тонко предвзятый или опасный контент, который не очевиден для валидаторов. Однако, поскольку валидаторы также являются агентами, разработанными человеком или, по крайней мере, алгоритмическими, явная токсичность или ошибка, вероятно, будет поймана (некоторые подсети могут даже иметь ИИ-валидаторов, проверяющих на небезопасный контент). Худший сценарий — если злоумышленник каким-то образом имеет большинство валидаторов и майнеров, сговаривающихся, чтобы продвигать определенный неверный вывод как «правильный» — они могли бы тогда исказить консенсус сети по ответам (например, все сговаривающиеся валидаторы одобряют вредоносный ответ). Но чтобы внешний пользователь пострадал от этого, он должен фактически запросить сеть и доверять выводу. Bittensor все еще находится на стадии, когда он наращивает возможности, а не широко используется для критических запросов конечными пользователями. К тому времени, когда это произойдет, можно надеяться, что он будет иметь фильтрацию контента и разнообразие валидаторов для смягчения таких рисков. Со стороны валидаторов злонамеренный валидатор может подавать отравленные оценки — например, постоянно занижать оценки определенному честному майнеру, чтобы устранить конкуренцию. При достаточном стейке они могут преуспеть в вытеснении этого майнера (если вознаграждения майнера упадут так низко, что он уйдет). Это атака на механизм стимулирования. Опять же, если они не составляют большинство, отсечение медианы помешает валидатору-выбросу. Если они составляют большинство, это сливается со сценарием сговора/51% — любое большинство может переписывать правила. Решение возвращается к децентрализации: не допускать доминирования одной сущности. В итоге, дизайн Bittensor по своей сути наказывает отравленные данные/вклады моделей через свою систему оценки — плохие вклады получают низкий вес и, следовательно, низкое вознаграждение. Нет постоянного репозитория моделей для отравления; все динамично и постоянно оценивается. Это обеспечивает устойчивость: сеть может постепенно «забывать» или игнорировать плохих акторов, поскольку их вклады отфильтровываются валидаторами.
  • Gensyn: Если решатель захочет отравить обучаемую модель (например, внедрить бэкдор или предвзятость во время обучения), он может попытаться сделать это скрытно. Протокол Gensyn проверит, что обучение проходило в соответствии с указанным алгоритмом (шаги стохастического градиентного спуска и т. д.), но он не обязательно обнаружит, если решатель внедрил тонкий триггер бэкдора, который не проявляется в обычных метриках валидации. Это более коварная проблема — это не сбой вычислений, это манипуляция в рамках допустимых степеней свободы обучения (например, корректировка весов в сторону триггерной фразы). Обнаружение этого является активной исследовательской проблемой в области безопасности ML. Gensyn не имеет специального механизма для отравления моделей, помимо того факта, что отправитель может оценить конечную модель на выбранном им тестовом наборе. Опытный отправитель всегда должен тестировать возвращенную модель; если он обнаружит, что она не работает на некоторых входных данных или имеет странное поведение, он может оспорить результат или отказаться от оплаты. Возможно, протокол мог бы позволить отправителю указать определенные критерии приемлемости (например, «модель должна достичь как минимум X точности на этом секретном тестовом наборе»), и если результат решателя не соответствует, решатель не получает полную оплату. Это предотвратило бы отравление, потому что злоумышленник не соответствовал бы критериям оценки. Однако, если отравление не влияет на точность при обычных тестах, оно может проскользнуть. Верификаторы в Gensyn проверяют только целостность вычислений, а не качество модели, поэтому они не поймают преднамеренное переобучение или трояны, пока журналы обучения выглядят действительными. Таким образом, это остается проблемой доверия на уровне задачи: отправитель должен доверять либо тому, что решатель не отравит модель, либо использовать методы, такие как ансамблирование нескольких результатов обучения от разных решателей, чтобы ослабить влияние любого отдельного решателя. Другой аспект — отравление данных: если отправитель предоставляет обучающие данные, злонамеренный решатель может игнорировать эти данные и обучать на чем-то другом или добавлять мусорные данные. Но это, вероятно, снизит точность, что отправитель заметит в производительности выходной модели. Тогда решатель не получит полную оплату (поскольку предположительно он хочет достичь целевого показателя производительности). Таким образом, отравление, которое ухудшает производительность, само по себе является проигрышным для вознаграждения решателя. Только отравление, которое нейтрально по производительности, но злонамеренно (бэкдор), представляет реальную опасность, и это выходит за рамки типичной блокчейн-верификации — это проблема безопасности машинного обучения. Лучшее смягчение Gensyn, вероятно, социальное: использовать известные авторитетные модели, проводить несколько циклов обучения, использовать инструменты с открытым исходным кодом. Что касается задач вывода (если Gensyn также используется для задач вывода), сговорившийся решатель может возвращать неверные выходы, которые искажают определенный ответ. Но верификаторы поймают неверные выходы, если они запускают ту же модель, так что это меньше отравление и больше просто мошенничество, которое решается доказательствами мошенничества. В итоге, Gensyn обеспечивает безопасность процесса, а не намерения. Он гарантирует, что обучение/вывод были выполнены правильно, но не то, что результат хороший или свободен от скрытых неприятностей. Это остается открытой проблемой, и вайтпейпер Gensyn, вероятно, еще не полностью решает ее (немногие это делают).
  • Cuckoo: Поскольку Cuckoo в настоящее время фокусируется на выводе (обслуживании существующих моделей), риск отравления данных/моделей относительно ограничен манипуляцией выводами или отравлением контента. Злонамеренный майнер может попытаться подделать модель, которую ему дали для запуска — например, если ему предоставили контрольную точку Stable Diffusion, он мог бы заменить ее другой моделью, которая, возможно, вставляет какой-то тонкий водяной знак или рекламу в каждое изображение. Однако координатор (который является владельцем модели) обычно отправляет задачи с ожиданием формата вывода; если майнер постоянно возвращает нестандартные выводы, координатор пометит и заблокирует этого майнера. Кроме того, майнеры не могут легко модифицировать модель, не влияя заметно на ее выводы. Другой сценарий — если Cuckoo введет модели, обученные сообществом: тогда майнеры или поставщики данных могут попытаться отравить обучающие данные (например, ввести много неправильных меток или предвзятого текста). Cuckoo потребуется реализовать валидацию краудсорсинговых данных или взвешивание вкладчиков. Это пока не является функцией, но интерес команды к персонализированному ИИ (например, их упоминание об ИИ-коуче или обучающих приложениях) означает, что они могут в конечном итоге обрабатывать пользовательские обучающие данные, что потребует тщательных проверок. Что касается безопасности контента, поскольку майнеры Cuckoo выполняют вывод, можно беспокоиться о том, что они выдают вредоносный контент, даже если модель обычно этого не делает. Но майнеры не заинтересованы в произвольном изменении выходов — им платят за правильные вычисления, а не за творчество. Во всяком случае, злонамеренный майнер может пропустить полное вычисление, чтобы сэкономить время (например, вернуть размытое изображение или общий ответ). Координатор или пользователь увидят это и понизят рейтинг этого майнера (и, вероятно, не заплатят за эту задачу). Конфиденциальность — еще один аспект: злонамеренный майнер может утечь или записать пользовательские данные (например, если пользователь ввел конфиденциальный текст или изображения). Это не отравление, но это атака на конфиденциальность. Позиция Cuckoo в отношении конфиденциальности заключается в том, что она исследует методы сохранения конфиденциальности (упоминание VPN, сохраняющего конфиденциальность в экосистеме, предполагает будущий фокус). Они могли бы включить такие методы, как защищенные анклавы или разделенный вывод, чтобы сохранить данные конфиденциальными от майнеров. Пока не реализовано, но является известным соображением. Наконец, блог Cuckoo подчеркивает эффективную проверку выходов моделей и обеспечение безопасной децентрализованной работы моделей как ключ к жизнеспособности токенизации моделей. Это указывает на то, что они осознают, что для истинной децентрализации ИИ необходимо защищаться от таких вещей, как отравленные выходы или неисправные модели. Возможно, они намерены использовать комбинацию криптоэкономических стимулов (сокращение стейка для плохих акторов) и систем пользовательских рейтингов (пользователи могут помечать плохие выходы, и эти майнеры теряют репутацию). Система репутации может помочь здесь: если майнер возвращает даже один очевидно вредоносный или неверный результат, пользователи/координаторы могут понизить его рейтинг, что сильно повлияет на его будущую способность зарабатывать. Зная это, майнеры заинтересованы в том, чтобы быть последовательно правильными и не допускать никакого отравления. По сути, Cuckoo полагается на «доверяй, но проверяй»: это более традиционно в том смысле, что если кто-то ведет себя неправильно, вы его идентифицируете и удаляете (с потерей стейка в качестве наказания). У него пока нет специализированных защит от тонкого отравления моделей, но структура, предусматривающая конкретных владельцев приложений (координаторов), добавляет уровень надзора — эти владельцы будут мотивированы обеспечить, чтобы ничто не скомпрометировало целостность их модели, поскольку их собственный доход и репутация зависят от этого.

В заключение, хотя децентрализованные ИИ-сети вводят новые поверхности атаки, они также развертывают комбинацию криптографических, игровых и общественно-управленческих защит: Устойчивость к атакам Сивиллы в основном обеспечивается требованием экономического стейка для участия. Устойчивость к сговору достигается за счет согласования стимулов (честное поведение более выгодно) и механизмов консенсуса, которые ограничивают влияние небольших сговорившихся групп. Предотвращение фрирайдерства достигается путем тесной привязки вознаграждений к фактической полезной работе и наказания или устранения тех, кто ничего не вносит. Отравление и связанные с ним атаки остаются сложными, но системы смягчают явные случаи посредством непрерывной оценки и возможности сокращения или исключения злонамеренных акторов. Эти платформы активно исследуют и совершенствуют эти дизайны — о чем свидетельствуют постоянные доработки Yuma и dTAO в Bittensor, а также изменение токеномики в Cuckoo — для обеспечения безопасной, самоподдерживающейся децентрализованной ИИ-экосистемы.

Сравнительная оценка​

Чтобы выделить различия и сходства Bittensor, Gensyn и Cuckoo AI, следующая таблица предоставляет параллельное сравнение по ключевым параметрам:

Параметр	Bittensor (TAO)	Gensyn	Cuckoo AI (CAI)
Технический стек	Кастомный L1 (цепочка Subtensor на базе Substrate) с более чем 93 специализированными ИИ-подсетями. Совместим с EVM (после недавнего обновления) на собственной цепи.	Роллап на базе Ethereum (изначально планировался L1, теперь роллап ETH). Офчейн-вычисления с ончейн-верификацией.	Запущен как цепочка уровня 2 Arbitrum Orbit (роллап EVM). Полнофункциональная платформа (собственная цепь + вычисления + пользовательский интерфейс приложения). Переходит от кастомного L1 к общей безопасности Ethereum (роллап/AVS).
Основное направление	Децентрализованная ИИ-сеть моделей («нейронный интернет»). Узлы вносят вклад в коллективный вывод и обучение моделей по различным задачам (LLM, зрение и т. д.).	Децентрализованный маркетплейс вычислений для ML. Акцент на офчейн-обучении моделей и выводе с помощью глобальных GPU, верификация работы через блокчейн.	Децентрализованная платформа ИИ-сервисов. Фокус на обслуживании/выводе моделей (например, генеративное искусство, LLM API) с использованием распределенных GPU-майнеров. Интегрирует конечные пользовательские приложения с бэкенд-маркетплейсом GPU.
Ключевые роли	Владелец подсети: определяет задачу и валидацию в подсети (получает 18% вознаграждений). Майнеры: запускают ИИ-модели (вывод/обучение), предоставляют ответы. Валидаторы: отправляют запросы и оценивают выходы майнеров (курируют качество). Делегаторы: стейкают TAO на майнеров/валидаторов для усиления влияния и получения доли.	Отправитель (Разработчик): размещает ML-задание (с моделью/данными) и оплату. Решатель: выполняет задачу на своем оборудовании, отправляет результат. Верификатор (Наблюдатель): проверяет результат решателя; может оспорить через доказательство мошенничества, если он неверен. (Отдельной роли «владельца» нет, так как отправитель предоставляет модель; роли управления через держателей токенов).	Разработчик ИИ-приложений (Координатор): развертывает ИИ-сервис, стейкает CAI, управляет задачами для майнеров. Майнер (Поставщик GPU/CPU): стейкает CAI, выполняет назначенные задачи вывода, возвращает результаты. Конечный пользователь: использует ИИ-приложения (платит криптовалютой или предоставляет ресурсы). Стейкер (Делегатор): стейкает на координаторов/майнеров, голосует в управлении, получает долю вознаграждений.
Technical Stack	Custom L1 (Substrate-based Subtensor chain) with 93+ specialized AI subnets. EVM-compatible (after recent upgrade) on its own chain.	Ethereum-based rollup (originally planned L1, now an ETH rollup). Off-chain compute with on-chain verification.	Launched as an Arbitrum Orbit Layer-2 chain (EVM rollup). Full-stack platform (own chain + compute + app UI). Migrating from custom L1 to Ethereum shared security (rollup/AVS).
Primary Focus	Decentralized AI network of models (“neural internet”). Nodes contribute to collective model inference and training across tasks (LLM, vision, etc.).	Decentralized compute marketplace for ML. Emphasis on off-chain model training and inference by global GPUs, verifying the work via blockchain.	Децентрализованная платформа ИИ-сервисов. Фокус на обслуживании/выводе моделей (например, генеративное искусство, LLM API) с использованием распределенных GPU-майнеров. Интегрирует конечные пользовательские приложения с бэкенд-маркетплейсом GPU.
Key Roles	Владелец подсети: определяет задачу и валидацию в подсети (получает 18% вознаграждений). Майнеры: запускают ИИ-модели (вывод/обучение), предоставляют ответы. Валидаторы: отправляют запросы и оценивают выходы майнеров (курируют качество). Делегаторы: стейкают TAO на майнеров/валидаторов для усиления влияния и получения доли.	Отправитель (Разработчик): размещает ML-задание (с моделью/данными) и оплату. Решатель: выполняет задачу на своем оборудовании, отправляет результат. Верификатор (Наблюдатель): проверяет результат решателя; может оспорить через доказательство мошенничества, если он неверен. (Отдельной роли «владельца» нет, так как отправитель предоставляет модель; роли управления через держателей токенов).	Разработчик ИИ-приложений (Координатор): развертывает ИИ-сервис, стейкает CAI, управляет задачами для майнеров. Майнер (Поставщик GPU/CPU): стейкает CAI, выполняет назначенные задачи вывода, возвращает результаты. Конечный пользователь: использует ИИ-приложения (платит криптовалютой или предоставляет ресурсы). Стейкер (Делегатор): стейкает на координаторов/майнеров, голосует в управлении, получает долю вознаграждений.
Consensus & Verification	Yuma Consensus: custom “proof-of-intelligence” – validators’ scores of AI output are aggregated (stake-weighted median) to determine miner rewards. Underlying chain consensus is PoS-like (Substrate) for blocks, but block validity hinges on the AI consensus each epoch. Resistant to outlier scoring and collusion up to 50%.	Optimistic verification (Truebit-style): assume solver’s result correct unless a verifier challenges. Uses interactive on-chain fraud proofs to pinpoint any incorrect step. Also implementing cryptographic proofs-of-computation (proof-of-learning) to validate training progress without re-execution. Ethereum provides base consensus for transactions.	Консенсус Proof-of-Stake цепи + валидация задач координаторами: Cuckoo Chain использовала валидаторы PoS для производства блоков (изначально майнеры также помогали обеспечивать безопасность блоков). Результаты ИИ-задач проверяются узлами-координаторами (которые проверяют выходы майнеров на соответствие ожидаемому поведению модели). Специализированных криптографических доказательств пока нет — полагается на стейк и репутацию (отсутствие доверия в той степени, в какой неправомерное поведение приводит к сокращению стейка или понижению рейтинга, а не к автоматическому математически доказанному обнаружению). Переходит на консенсус Ethereum (роллап) для безопасности реестра.