Это вторая глава моего исследования ICP - честно говоря, я не думал, что смогу закончить так быстро, после публикации первой части меня мучил один вопрос: почему блокчейны на протяжении многих лет не могут поддерживать настоящие приложения?
Чем глубже я исследую, тем яснее становится ответ: большинство блокчейнов поддерживают постоянный реестр.
Почти ни один блокчейн не может предоставить среду выполнения, в которой приложения действительно работают, что приводит меня к изначально несколько тревожному выводу: большинство цепей могут записывать приложения, но не могут их поддерживать.
Только ICP может действительно реализовать работу приложений в цепи.
Почему? Потому что модель Canister + Subnet не предназначена для оптимизации TPS (транзакций в секунду), а для предоставления приложению среды выполнения, которая может выполнять, эволюционировать и оставаться криптографически проверяемой.
Это идеально соответствует видению Caffeine: сделать приложения, сгенерированные искусственным интеллектом, не только работоспособными, но и доказуемыми.
Мой опыт использования Caffeine AI
Я пытался построить простой агрегатор новостей X402:
https://x402news-akn.caffeine.xyz
Архитектура
Процесс удивительно элегантен:
На основе вашей идеи он генерирует spec.md
Он использует Motoko для написания фронтенда и бэкенда
И разворачивает все напрямую на ICP
После множества итераций - и множества ошибок - оно наконец заработало. Опыт Vibe-Coding сейчас еще не может сравниться с уровнем Vercel, но это не самое удивительное, что я увидел. Настоящим шоком для меня стало то, что я впервые почувствовал: "Мое приложение действительно работает на блокчейне."
Это не контракт и не транзакция, а бэкенд-сервис - размещенный на цепи, работающий непрерывно, доступный для вызова и способный самостоятельно выполнять логику.
Эта способность на большинстве цепей вообще отсутствует, и смарт-контракты в других местах не могут инициировать выполнение, они могут только реагировать; ICP предоставляет то, что другие компании в отрасли никогда не строили: уровень выполнения на уровне цепи.
Почему Caffeine AI является лучшим подарком ICP? Но это не просто еще один пример применения блокчейна. Причина, по которой Caffeine AI так привлекательна, заключается в том, как она превращает концепцию "всегда онлайн" приложения в реальность на ICP.
Для Caffeine AI акцент ставится не только на построение приложений, но и на создание проверяемых, долговременных, цепных приложений, которые могут продолжать работать, эволюционировать и улучшаться, никогда не останавливаясь.
Это именно причина, по которой Caffeine AI является лучшим подарком ICP: он не только демонстрирует технический потенциал ICP, но и переводит истинную силу ICP в реальный мир, открывая дверь для большего числа разработчиков, позволяя им легко создавать приложения, существование которых гарантируется лишь при постоянной работе узлов.
Могут ли другие экосистемы сделать это? Теоретически могут:
Отправка хеш-значения в Ethereum
Хранение кода на Filecoin или EthStorage
Использование zkVM для реализации проверяемого исполнения
Кодирование на основе Git, как у Vercel, с доказательством отправки в цепь
Да, вы можете собрать "проверяемый канал обновлений", но ключевое в том, что, когда вы разворачиваете с Caffeine AI, ваше приложение разворачивается в среде выполнения ICP, и пока узлы продолжают работать, ваше приложение может поддерживать свою работу.
Это чувство гарантии сохранности - это "мое приложение действительно живет на цепи" - крайне трудно заменить, и именно поэтому я пишу вторую часть.
В первой статье мы переопределили проблему: если децентрализация остановится на реестре, интернет все равно останется вне цепи. Эта статья сделала две вещи - она перенаправила внимание с "транзакций" на "приложения" и изменила критерии оценки с "более быстрой скорости воспроизведения" на работоспособные, эволюционные и проверяемые результаты.
Эта статья сохраняет эту позицию, но классифицирует ее в инженерной области: мы больше не спрашиваем "как сделать цепь быстрее", а отвечаем на вопрос, что считается приложением, работающим в пределах протокольной границы, и какие институциональные возможности ему нужны.
Механизм принятия решений по целям: рассматривать "транзакции" как цель будет склонять систему к расчетам и воспроизведению, в то время как рассматривать "приложения" как цель потребует полного пути публикации, который позволяет работать, эволюционировать и проверять.
Поэтому мы сосредоточили внимание на контейнерах ICP (Canister): как они объединяют код, состояние, хранение и публикацию в одной проверяемой границе; как они поддерживают высокочастотную эволюцию, не теряя памяти; и почему Caffeine AI, как "самопишущее приложение", должно работать непосредственно в контейнере, а не через собранную архитектуру "облачное + контракт".
Эта статья содержит конструктивные диаграммы и последовательные схемы и указывает на ключевые компромиссы и граничные условия.
1. Переход цели: от транзакций к приложениям
Типичная "высокопроизводительная цепь" всё еще сосредоточена на транзакциях: контракты являются пассивными, исполнение временно, глобальное состояние общее, фронтенд работает вне цепи.
ICP перенаправляет цели на приложения: контейнеры инкапсулируют код, состояние, долговременное хранилище и проверяемый интерфейс публикации, и работают по модели Actor / асинхронной модели.
Основные моменты
Семантика процессов: долговременное, планируемое, асинхронное взаимодействие между контейнерами, больше не "функция, уничтожаемая после одного вызова".
Единые границы: фронтенд, бэкенд, состояние, публикация и доказательства находятся в одной и той же границе безопасности и проверяемости.
Граница не является пропускной способностью, а граничным условием. Высокопроизводительная цепь оптимизирует границу "все повторяют один и тот же реестр", контейнер же переписывает границу на "приложение, которое длительно работает в протоколе и которое может проверить конечный пользователь". Первая расширяет пропускную способность, вторая же завершает замкнутый цикл возможностей.
2. Полная проверяемость: интеграция фронтенда и данных в "цепь публикации".
Чтобы весь сайт мог надежно работать в цепи, конечный пользователь должен иметь возможность в браузере проверять, что "то, что я вижу, было выпущено конкретным контейнером под конкретным корнем состояния". ICP предоставляет сертифицированные активы (статические ресурсы) и сертифицированные переменные (динамические снимки) для завершения этой цепи публикации.
Инструкции по реализации
Сертифицированные активы: создание хеш-деревьев во время построения и возврат доказательства в ответе, браузер проверяет через агрегированные подписи подсети и открытый ключ на уровне цепи.
Сертифицированные переменные: экспорт доказательства динамического снимка, чтобы избежать воспроизведения на клиенте, страницы получают данные и их криптографические источники, связанные с конкретным корнем состояния.
Публикация — это обязательство: когда фронтенд и ключевые переменные вступают в цепь сертификации, каждая публикация становится криптографическим обязательством: издатель, содержимое публикации, на каком основании консенсуса, "просмотр" превращается в "доказательство", "версия" превращается в "доказательство".
3. Эволюция структуры: сделать "изменение схемы" аудируемым обновлением
Продукты на основе искусственного интеллекта часто меняют структуры данных и процессы; неявная миграция (скрипты захватывают поля или сужают типы) - самая распространенная скрытая ошибка в традиционном облаке. Контейнеры используют стабильную память и хуки обновления, чтобы четко определить границы эволюции, превращая обновления в аудируемые институциональные события.
Контрольный список операций
Версионирование слотов: сохранение предыдущих слотов в стабильной памяти, явная обработка значений по умолчанию/расширений после обновления и откат в случае неудачи.
CI контроль доступа: проверки различий в моделях, совместимости типов и идемпотентных миграций перед развертыванием, чтобы предотвратить "непроверенные миграции".
Обновление выдает доказательство: после миграции сразу обновляются сертифицированные переменные, чтобы клиенты получили проверенный новый снимок.
Эволюция должна быть институционализирована; неявная миграция оставляет риски на вероятность, явное обновление интегрирует риски в процесс. "Сбой становится доказательством, откат имеет путь, снимок сертифицирован" - строгий инженерный дизайн позволяет часто эволюционировать.
4. Асинхронная топология между контейнерами: параллельно, но с четкими границами
Приложения, сгенерированные Caffeine, часто разбиваются на несколько контейнеров (пользователь, аутентификация, заказы, счета, контент), чтобы максимально сохранить горячие пути в одной подсети для снижения задержек и отправить холодные пути в асинхронный режим.
Cycles отслеживают ресурсы: CPU/пропускная способность/хранение измеряются по ресурсам, перекрестные вызовы предоплачены, возвращается неиспользованная часть.
Топологическая стратегия: размещение операций чтения и записи с высокой частотой/сильной согласованностью в одной подсети, длительные/слабо связные процессы выполняются асинхронно.
Наблюдаемость: затраты ресурсов по каждому пути подлежат атрибуции и могут предоставлять информацию для корректировки архитектурной тяжести.
Работоспособное также должно быть управляемым, преобразование вызова из "ощущаемых затрат" в "учетные затраты" закладывает основу инженерных компромиссов: локализация горячих путей, асинхронизация холодных путей, чтобы проект и стоимость оставались согласованными.
5. Уровень подсети: институционализация параллелизма
Каждая подсеть является кластером выполнения PBFT + порогового BLS: она обеспечивает локальную детерминированную конечность и выдает агрегированные подписи на основе корня состояния, протокольный уровень регистрирует подсети и ключевые материалы, Chain-Key открывает единую верификационную поверхность для всей сети.
Исполнение и доказательства запускаются в подсети
Полная проверка сети упрощается до одного открытого ключа и цепи доказательств
Нет необходимости в глобальном воспроизведении; параллелизм — это свойство протокола, а не операционная уловка.
Параллельная обработка не является временной мерой, а является институциональным дизайном, перемещая проверку из централизованного "повторного выполнения" в независимо проверяемую цепь доказательств, даже клиент может провести проверку - что обеспечивает параллелизм и безопасность.
6. Идентификация и сессии: сделать вход в систему переносимым правом
Caffeine использует Internet Identity 2.0: вход без пароля (Passkey) и агрегирует информацию для входа Google / Apple / Microsoft, сессии передаются в приложение как проверяемое делегирование, а не с использованием куки платформы. Существующие пользователи могут обновить свою идентификацию во время входа.
Таким образом, "кто может получить доступ и на каком основании" остается согласованным с проверяемыми границами приложения, избегая скрытых суверенитетов внешних платформ.
7. Пути доставки Caffeine: от обсуждения до доказательства
"Самопишущие приложения" должны переходить от естественного языка к "проверяемым поставкам", каждое действие должно производить проверяемые промежуточные результаты.
В конечном итоге пользователь видит интерфейс с доказательством: ресурсы UI и ключевые данные могут быть проверены в браузере через цепь доказательств, больше не "доверяя платформе".
Преобразование модели поставки от "доверять платформе" к "проверке на краю"; для Caffeine выбор контейнера не сделан из соображений TPS, а для того, чтобы "публикация была поддержана доказательствами, эволюция имела процесс, идентификация была переносимой, а стоимость была контролируемой" как основной принцип.
8. Оценка стоимости трех механизмов для одной и той же цели
Эта таблица отражает два аспекта: проектирование пропускной способности (исполнение/хранение/параллелизм) и проверяемые границы (доказательства/идентификация/стоимость), которые должны быть выполнены, чтобы приложение могло развиваться от "выполнения одной транзакции" к "долгосрочной работе".
9. От "более быстрого реестра" к "механизму для приложений"
Сначала мы переименовали эту проблему: если децентрализация остановится на реестре, интернет все равно останется вне цепи.
Теперь мы можем ответить на этот вопрос:
Разместите фронтенд и данные на проверяемой цепи публикации, чтобы конечные пользователи больше не зависели от доверия к платформе.
Рассматривайте эволюцию структуры как аудируемое событие обновления для быстрой итерации с институциональной гарантией.
Внедрите институциональный уровень параллелизма на уровне подсети, чтобы масштаб стал свойством протокола, а не инженерной уловкой.
Рассматривайте идентификацию как переносимое право, таким образом, вход в систему становится проверяемым делегированием, а не правом, предоставленным платформой.
Все это вместе составляет приложение, работающее в пределах протокольной границы - не "контракт на цепи", а "все приложение в пределах проверяемой границы".
Механизм принятия решений по целям, когда цель переходит от "транзакций" к "приложениям", система должна эволюционировать от "как быстрее воспроизвести реестр" к "как поддерживать работоспособность, эволюцию и проверяемость приложения", при этом одновременно удовлетворяя все три требования — не быстрее ли реестр, а децентрализованная среда выполнения приложений.
Контейнер — это единица выполнения, Chain-Key / NNS обеспечивает верификацию и управление, Cycles / II 2.0 интегрирует затраты и гражданство в повседневную деятельность.
Для Caffeine этот выбор не сделан из соображений повествования, а является неизбежным: когда ИИ постоянно переписывает приложения, результаты должны быть работоспособными и проверяемыми для пользователей - это именно то, что ICP стремится решить.
Следующая остановка неосуществленной мечты
В первой статье мы упомянули, что акцент революции блокчейна никогда не был на создании токенов, а на переосмыслении носителей доверия. Десять лет спустя мы достигли децентрализации реестра, но интернет все еще работает на централизованных серверах.
ICP вдохновил возможность преобразования блокчейна из мирового реестра в мировую операционную систему.
В этой статье рассматривается вопрос с инженерной точки зрения: контейнер (Canister) превращает приложение из "контракта + клея вне цепи" в среду выполнения, где код, состояние, интерфейс и идентификация находятся в рамках протокольной границы; параллелизм подсетей, проверка ключей цепи и обновления стабильной памяти делают эту модель осуществимой с инженерной точки зрения, проверяемой с криптографической точки зрения и подотчетной с экономической точки зрения.
С началом итеративного построения, развертывания и развития услуг искусственным интеллектом, ему не нужен более быстрый реестр, ему нужен децентрализованный вычислитель приложений.
Caffeine выбирает ICP не из-за TPS, а потому что он в конечном итоге делает "всеобъемлющие цепные и проверяемые поставки" стандартом для протокола - это правильное начало для децентрализованного интернета.
От реестра к компьютеру и к среде выполнения приложений - неосуществленная мечта блокчейна продолжает двигаться вперед, заменяя "доверие платформе" на "доказательство на краю".
Содержимое IC, которое вас интересует
Технический прогресс | Информация о проекте | Глобальные события
Подписаться на канал IC Binance
Оставайтесь в курсе последних новостей
