Cortex (CTXC) — это блокчейн-платформа, в которой смарт-контракт может вызывать инференс (выполнение) модели машинного обучения как часть своей логики. В отличие от обычных сетей, где контракт работает только с детерминированной арифметикой/логикой, здесь появляется «примитив для ИИ»: модель подключается к контракту, получает вход, возвращает выход и фиксируется в консенсусе. Базовая цель — сделать решения на основе моделей проверяемыми и прозрачными для всех участников сети.
Чтобы говорить на одном языке: — современные ончейн-интеграции чаще всего используют диалоговые модели и эмбеддинги; см. основы LLM; — исполнение модели в продакшене имеет профиль задержек и стоимости, разбор — в Инференс; — архитектура моделей «новой волны» строится вокруг механизма внимания, см. Трансформер.
Кому и зачем нужен Cortex (CTXC)
- DeFi/финансовые протоколы. Ончейн-скоринг/метрики риска, фильтры аномалий, «мягкие» триггеры ликвидаций с параметрами, зависящими от модели.
- Игры/метавселенные. NPC/экономика с реакцией на состояние мира и события на цепи; оракулы игровых решений.
- Маркетплейсы данных и сигналов. Фиксация исходов инференса в логах контракта, чтобы их можно было агрегировать/переиспользовать.
- DAO и модерация. Голосования с рекомендациями модели (не «автономное» решение, а подсказка, видимая всем и неизменяемая задним числом).
- Оракулы контента. Проверка цифровых артефактов (подписи, стили, простые классификации) как часть ончейн-процедур.
Где Cortex уместен? Там, где важны прозрачность и повторяемость решения модели, а сам вход можно привести к компактному/детерминированному виду.
Архитектура: из чего состоит ИИ-контракт
Минимальный набор сущностей:
| Сущность | Что это | Зачем |
| Модельный артефакт | Замороженное представление модели и конфигурации | Повторяемость, версионирование, контроль размера |
| Контракт-вызов | Метод смарт-контракта, который формирует вход для модели и вызывает инференс | Встраивает ИИ в бизнес-логику |
| Исполнитель инференса | Узел/механизм, который исполняет модель по детерминированным правилам сети | Согласованность результата |
| Оракул/коммит-ревил | Механика доставки внешних признаков/предсказаний, если прямой инференс на сети невыгоден | Баланс скорости и цены |
| Логи/события | Ончейн-след решения модели | Аудит, повторная проверка, индексация |
Два пути исполнения:
- On-chain (прямо в контексте блока): детерминированное, повторяемое всеми валидаторами исполнение ограниченной модели/операций. Плюс — прозрачность; минус — стоимость/лимиты.
- Off-chain + верификация: модель считается вне сети, результаты загружаются через оракул и проверяются детерминированным чекером/коммит-ревилом. Плюс — скорость; минус — сложности доверия/проверок.
На практике протоколы часто комбинируют оба: критичные части — «на цепи», тяжёлые сегменты — «вне цепи» с верификацией.
Как это работает: жизненный цикл инференса
1. Подготовка модели — выбирается архитектура (обычно компактная), замораживаются веса, фиксируются версии зависимостей и формат входа/выхода;
— модельный артефакт публикуется с метаданными: размер, хэши, область применимости, метрики.
2. Встраивание в контракт — контракт содержит ссылку/идентификатор модели и код формирования входа (нормализация, усечение, кодирование);
— задаются ограничения по газу/памяти и «путь деградации» (fallback, если инференс не проходит).
3. Инференс — узлы сети выполняют модель (или принимают результат оракула) и фиксируют выход как часть состояния/события;
— результат используется в логике: порог, штраф, коэффициент, выбор ветки кода.
4. Верификация и аудит — любой участник может воспроизвести инференс по логу входа и артефакту модели;
— обновления модели идут через «комплаенс-рамку»: голосование, пин версий, обратная совместимость.
Что за модели подходят для ончейн
Ключевой компромисс — между точностью и затратами. Полноразмерные языковые модели часто избыточны для ончейн-контекстов. На практике применяют:
| Тип модели | Где уместна | Почему |
| Лёгкие классификаторы | Фрод-флаги, фильтры аномалий | Малый вход, детерминированный вывод |
| Градиентный бустинг/линейные | Скоринг/метрики | Прозрачно и быстро |
| Компактные трансформеры | Нормализация/ранжирование простых текстов/событий | Редко на цепи, чаще через оракул |
| Векторные проверяющие | Сходство/пороговые решения | Лёгкие операции, детерминируемость |
Большие генеративные модели можно держать off-chain, а в контракте фиксировать только пороговые решения/оценки.
Данные и детерминизм
Смарт-контракт — про повторяемость. Требования к данным:
- вход должен быть однозначно воспроизводимым из ончейн-состояния или из оракула с коммит-ревилом;
- нормализация и токенизация — строгие, версионированные;
- округления/пороговые правила — зафиксированы;
- любые рандомизированные шаги заменяются псевдослучайностью с публичным seed.
Профиль исполнения модели подчиняется ограничениям инференса (контекст/память/времена); см. практику и рычаги оптимизации в Инференс.
Сценарии использования
DeFi-скоринг и риск-менеджмент. Пул ликвидности применяет коэффициент, зависящий от флагов аномалий/волатильности на основе модели; действие прозрачно — входы/выходы и сама модель доступны в логах.
Маркетплейсы сигналов. Поставщики моделей публикуют предсказания (через оракул) и получают вознаграждение, если сигнал проходит ончейн-верификацию и помогает достижению KPI контракта (например, снижает просадку пула).
Игровые механики. Контракты вызывают компактные классификаторы, чтобы определять исход мини-ивентов/награды NPC. Профиль нагрузки пакетируется, тяжёлые расчёты вынесены за сеть.
Аудит контента/подписи. Контракт принимает решение «похоже/не похоже» по эмбеддингам/хэшам — быстрый проверяющий шаг «на цепи» вместо доверия веб-бэкенду.
Экономика и стоимость инференса
Ончейн-инференс тратит газ. В расчётах учитывайте:
| Вклад | Как влияет | Как оптимизировать |
| Преобразование входа | ↑ газ/время | Держать формат компактным, предобрабатывать вне сети |
| Размер модели | ↑ газ/память | Квантование/сжатие весов, лёгкие архитектуры |
| Количество шагов | ↑ время | Пороговые решения/агрегации вместо «разгона» генерации |
| Оракул | Комиссии/задержка | Батчи, коммит-ревил, агрегаторы |
Правило «цена/эпизод». Считайте полную стоимость завершённого решения (включая подготовку и верификацию), а не только «газ за вызов». Для задач на языковых моделях учитывайте длину контекста и токены/сек (см. LLM).
Наблюдаемость и SLO
Ончейн даёт аудит по умолчанию (логи), но для продуктов обычно добавляют:
| Метрика | Зачем | Где смотреть |
| Успех ончейн-вызовов | Видеть долю удачных инференсов | Логи событий/выполнений |
| P95 задержки (сквозной) | UX и арбитраж | Индексаторы/оракульные батчи |
| Цена/эпизод | Экономика | Аггрегаторы заявок/выплат |
| Доля реверт-вызовов | Качество входов/лимитов газа | Мониторинг транзакций |
| Версионность моделей | Контроль регрессий | Регистр артефактов |
Риски и модель угроз
| Риск | Проявление | Как снижать |
| Недетерминизм | Разные узлы получают разные результаты | Фиксация версий, целочисленные операции, чекеры |
| Манипуляция оракулом | Смещение данных/результатов | Коммит-ревил, мульти-источники, штрафы |
| «Залипание» модели | Старые веса дают неверные решения | Версионирование, A/B-сравнение, канарейки |
| Дорого/медленно | Газ/батчинг «забивают» UX | Off-chain вычисления + on-chain проверка |
| Юридика/PII | Нельзя тянуть чувствительные данные | Анонимизация, агрегаты, чёткие политики данных |
| Атаки на вход | Адверсариальные perturbations | Нормализация, клиппинг входов, детекторы аномалий |
Интеграция: шаг-за-шагом
- Определите use-case и SLO: P95, цена/эпизод, доля успешных вызовов.
- Выберите модель и формат входа; зафиксируйте версии токенизаторов/нормализации.
- Решите, что считать on-chain, а что — off-chain с верификацией.
- Реализуйте контракт-вызов с fallback-логикой.
- Настройте регистры артефактов (хэши, размеры, области применимости).
- Добавьте канарейки и выборочную репликацию off-chain результатов.
- Введите наблюдаемость: события, индексы, алерты на деградацию.
- Определите политику обновлений модели (голосование DAO, лимиты по частоте).
Таблица: когда on-chain, а когда через оракул
| Критерий | On-chain инференс | Off-chain + верификация |
| Размер входа | Малый/структурный | Средний/большой/неструктурный |
| Класс модели | Простой/компактный | Средний/тяжёлый |
| Требование к прозрачности | Максимальное (логика в блоке) | Высокое (лог + доказуемость) |
| Цена/время | Выше | Ниже/гибко |
| Примеры | Флаги аномалий, пороги | Генерация, сложные классификации, ранжирование |
Анти-паттерны эксплуатации
- «Затащим LLM прямо в контракт». Большие модели не дружат с газом. Оставляйте on-chain только проверяемые пороговые куски.
- «Нечёткие входы». Без строгих конвертеров и версий токенизаторов воспроизводимость ломается.
- «Всегда off-chain без проверок». Без коммит-ревила/мульти-источников получаете «чёрный ящик» вместо доверия.
- «Один провайдер оракула». Точка отказа и стимул для манипуляций. Дублируйте и штрафуйте.
- «Без плана деградации». Если инференс не проходит, контракт должен вести себя предсказуемо.
Чек-лист для команды
- Описан контракт данных (формат входа/выхода), версии нормализации.
- Выбран путь исполнения: on-chain vs off-chain + проверка.
- Модельный артефакт версионирован, хэши зафиксированы.
- Настроены канарейки и выборочная репликация результатов.
- Включены метрики: цена/эпизод, P95, доля успехов, реверт-вызовы.
- Прописана политика обновлений модели (голос/кворум, обратная совместимость).
- Реализован fallback на случай отказа инференса/оракула.
Таблица ориентиров оптимизации
| Рычаг | Влияние | Комментарий |
| Квантование/сжатие | ↓ цена/газ, ↑ вместимость | Следите за точностью порогов |
| Усечение входа | ↓ время, ↓ газ | Явные правила тримминга |
| Пакетирование оракула | ↓ комиссии, ↑ задержка | Балансировать с UX |
| Детерминированные операции | ↑ воспроизводимость | Избегайте нефиксированных округлений |
| Коммит-ревил | ↓ манипуляции | Стоит дополнительных шагов |
FAQ
Можно ли сделать голосование DAO, где LLM «объясняет» решение? Да, но генерацию лучше держать off-chain, а в контракт возвращать краткую оценку/категорию плюс ссылку на лог. На цепи — только проверяемые части.
Как часто обновлять модель? Редко и через процедуру: пин версий, A/B на малой доле вызовов, обратная совместимость конвертеров.
Чем Cortex отличается от «LLM-бота поверх RPC»? Здесь решение модели фиксируется в состоянии/логах и может влиять на активы; требуется детерминизм и верифицируемость.
Где узкое место по цене? Преобразование входов и размер модели. Держите ончейн-часть минимальной и считайте цену/эпизод со всеми накладными.
Насколько безопасны оракулы? Это компромисс. Используйте коммит-ревил, мульти-источники и штрафы. Доверие строится на верифицируемых логах и воспроизводимости.
Словарь терминов
- Инференс — выполнение модели на входных данных для получения предсказания.
- Оракул — механизм ввода внешних данных/результатов в блокчейн.
- Коммит-ревил — схема «сначала скрытая фиксация, затем раскрытие», чтобы снизить манипуляции.
- Модельный артефакт — зафиксированный пакет весов/конфигурации/зависимостей.
- Детерминизм — свойство получать один и тот же результат при одинаковых входах/версиях.
- Fallback — предсказуемая альтернативная ветка при отказе инференса/оракула.