Ritual — организация и технологический стек для on-chain AI: подключение моделей и вычислений ИИ к смарт-контрактам и dApp с возможностью верификации результатов. Ключевая идея — превратить инференс/скoring моделей в «первоклассных граждан» Web3: смарт-контракты могут запросить модель, получить результат, проверить корректность (экономически или криптографически) и принять решение без доверия к единой централизованной стороне.
Ritual развивает инфраструктуру Infernet — слой маршрутизации запросов к моделям (off-chain исполнение с ончейн-подтверждением), реестр провайдеров и стандарт интерфейсов для безопасной интеграции ИИ в блокчейн-приложения.
Задача и позиционирование
- Подключить ИИ к Web3. Контракты и dApp получают доступ к LLM/ML моделям, классификаторам, детекторам аномалий и пр.
- Сделать вывод проверяемым. Результаты инференса сопровождаются проверками: крипто-квитанциями, экономическими залогами, квотами и аудитом трасс.
- Дать выбор провайдеров. Любой провайдер модели/компьютинга может подключиться к сети с прозрачной ответственностью и стимулом качества.
Архитектура (упрощённо)
| Компонент | Роль | Что важно в продакшене |
|---|---|---|
| Infernet (роутер) | Принимает запросы от dApp/контрактов, маршрутизирует к провайдерам | Квоты, приоритеты, аутентификация, сбор метрик |
| Провайдеры моделей | Исполняют инференс (LLM/визуальные/классические ML) | Репутация, проверка окружений, отчётность о ресурсах |
| Валидаторы | Проверяют корректность/согласованность результатов | Сэмплы-свидетели, экономические залоги, арбитраж споров |
| dApp/контракты | Формируют запросы и потребляют вывод модели | Жёсткие схемы вывода, лимиты затрат, fallback-логика |
*Где идёт вычисление?* Инференс исполняется off-chain у провайдера, но транзакционно «привязывается» к запросу: сеть фиксирует «кто, что и как» посчитал, чтобы контракт мог учесть результат и/или спорить.
Модели доверия и проверки
- Экономическая верификация. Провайдеры и валидаторы держат залоги; при споре проигравшая сторона теряет стейк.
- Криптографические доказательства (где применимо). Для некоторых классов задач — TEE-аттестация сред исполнения или лёгкие доказательства корректности (хэши, подписи, меркл-логика). См. Confidential Compute / TEE.
- Статистические проверки. Стратифицированные «контрольные» запросы, сравнение с базовыми моделями, эвристики на распределениях.
Сценарии использования
- DeFi-сигналы. Ончейн-стратегии запрашивают оценку риска/волатильности/анти-фрода и исполняют сделки при пороговых значениях.
- RAG/поиск знаний. dApp запрашивает у провайдера эмбеддинги или ответы LLM по корпоративному индексу, затем принимает ончейн-решение (например, выдача гранта/голоса).
- Модерация и KYC-паттерны. Классификаторы токсичности/спама/ботов в DAO-инструментах.
- Игры и NFT. Генеративные элементы, анти-чит-сигналы, «умные» правила миссий с проверкой со стороны валидаторов.
Интеграция: как разработчику подключиться
- Контрактный интерфейс. Вызов «запроса инференса» и обработчик «ответа/доказательства». Жёстко зафиксируйте формат вывода (JSON-схема, стоп-последовательности) и лимиты. См. Model serving для практик схемирования.
- Выбор провайдера. Учитывайте географию, профиль GPU/CPU, p95, политику приватности и доступные доказательства.
- Безопасность по умолчанию. Включайте «двухконтурную» проверку: экономическую (залог/репутация) + криптографическую/TEE, где доступно.
- Наблюдаемость. Логируйте id запроса, время, стоимость, используемую модель/версию, контрольные суммы; держите «золотые» наборы для evals.
Метрики и SLO
- Latency p50/p95/p99 от вызова до финального ответа (включая сеть).
- Надёжность. Доля успешных ответов, ретраи, частота споров и их исход.
- Качество. Метрики по eval-наборам (accuracy/F1/ROC-AUC или task-специфика; для LLM — faithfulness/контент-соответствие).
- Стоимость. Удельные расходы на запрос/1k токенов/кадр/фичу, комиссия валидаторов, споры.
Безопасность и комплаенс
- Данные и приватность. Не передавайте лишнее; используйте однократные ключи/TTL; для чувствительных кейсов — TEE и сегментацию данных.
- Защита LLM-каналов. Учитывайте evals для регулярной проверки качества и внедряйте схемы против prompt-инъекций/утечек (жёсткие форматы, стоп-правила).
- Аудит моделей. Фиксируйте версии/хэши весов и зависимостей; ведите журнал изменений для воспроизводимости.
Риски и ограничения
- Споры по результатам. Экономическая модель снижает риск, но не исключает его; закладывайте время/бюджет на арбитраж.
- Ограниченность доказательств. Не все задачи легко «доказать» криптографически; часть опирается на TEE и репутацию.
- Сетевые и ценовые флуктуации. Время/стоимость ответа зависят от загрузки провайдеров и рынка вычислений.
Мини-плейбук запуска
- Определите SLO (p95/стоимость/макс-время), формат вывода и «код возврата» на случай спора/таймаута.
- Выберите 2–3 провайдера и включите fallback при сбое/выбросе метрик.
- Подготовьте «золотые» eval-наборы и авто-сравнение вывода по ключевым метрикам.
- Включите TEE или иные доказательства там, где это критично; храните хэши артефактов.
- Настройте телеметрию и алерты по latency/ретраям/стоимости.
Частые вопросы (FAQ)
Можно ли полностью «доказать» корректность вывода любой модели?
Пока нет. Для части задач применимы TEE-аттестации и упрощённые доказательства; остальное закрывается экономикой залогов, аудитом и статистическими проверками.
Как выбирать провайдера модели?
Смотрите на p95/стоимость, доступные доказательства, журнал версий и политику приватности. Держите минимум двух провайдеров и fallback-маршрут.
Подходит ли Ritual для генеративных задач (LLM/изображения)?
Да, при условии жёсткой схемы вывода (JSON, ограничения длины/контекста) и наличия механизмов проверки (TEE/репутация/экономика споров).