Chainlink Functions и переход к CRE: выбор модели
Учебные материалы о Chainlink Functions часто показывают запрос из контракта, выполнение внешнего кода и поздний ответ. Эта модель полезна для понимания асинхронности, но сам сервис больше нельзя представлять как новый действующий маршрут. Официальная документация сообщает deprecated: mainnet с 30 июня 2026 года, testnet с 15 июня 2026 года, и направляет разработчиков к Chainlink Runtime Environment — CRE.
В уроке сохраним общую задачу библиотеки и составим современный договор workflow. Мы не создаём Functions-subscription, не устанавливаем старый starter kit, не используем Mumbai и не развёртываем CRE. Исторический подход рассматривается как источник идеи, а не инструкция запуска снятого сервиса.
Какая задача остаётся
Библиотека хочет получить внешний статус проверки выпуска курса 17 и сохранить допустимый результат. Источник отвечает вне EVM. Для принятия нужны идентичность задания, точная схема результата, доверенный маршрут и политика позднего ответа. Смена сервисной среды не отменяет этих прикладных вопросов.
Старый Functions-пример иллюстрировал разрыв между запросом и callback. Новый маршрут может запускаться по предусмотренному trigger, выполнять capabilities, формировать report и доставлять его подходящему consumer. Это не буквальная замена каждого прежнего метода одним новым именем. Конфигурация, кодирование и административные роли исследуются по нынешнему профилю.
назначение проверки выпуска
→ выбранный trigger workflow
→ получение допустимого внешнего ответа
→ согласованный report
→ предусмотренная доставка consumer
→ библиотечное решение по выпускуСхема является собственным проектированием. Она не заявляет, что публичный CourseCatalog уже умеет принимать reports. Для этого нужен отдельный модуль проверки с явно определёнными полномочиями.
Workflow и trigger
CRE описывает workflow как организованный процесс, который связывает trigger и обработку через capabilities. Поддерживаемое событие запуска может относиться к расписанию, HTTP или EVM-логу согласно текущему профилю. Для библиотеки выберем назначение: проверка конкретного подготовленного выпуска, а не произвольная ежедневная запись любого ответа в реестр.
Trigger сообщает начало процесса, но не доказывает успешную проверку материалов. Если внешний API недоступен, workflow должен сохранить предусмотренный отказ либо подходящий результат своей модели. Пользовательская карточка отличает запуск от принятых данных.
Также требуется область действия: курс, редакция, ожидаемый digest манифеста и версия схемы. Если новый выпуск появился во время выполнения, старый процесс не должен автоматически утверждать результат для него. Идентичность задания обсуждается следующей главой независимо от конкретного SDK.
Capabilities и согласование
Операции внешнего чтения и сетевого действия имеют предусмотренные механизмы исполнения CRE. Децентрализованное выполнение и согласование результата не превращают ненадёжный исходный API в безошибочный источник смысла. Если все участники получили одну и ту же неправильную запись, согласованный результат всё ещё может быть неподходящим для нашей задачи.
Поэтому библиотека валидирует схему, назначение и допустимость внешних данных. Недетерминированность обработки также требует внимания: локальные часы, случайный порядок и неоднозначное округление не должны незаметно менять результат разных участников. Конкретные правила изучаются по документации выбранного runtime.
В текущей работе CLI и SDK не установлены. На странице CRE changelog указан CLI 1.36.0 от 1 октября 2026 года; это наблюдение первичного источника, а не версия нашего локального проекта. Будущая лаборатория закрепит совместимые компоненты отдельно.
Report и onchain-приём
Документация описывает подписанный report и предусмотренный маршрут доставки через forwarder к consumer. Приёмник имеет собственную проверку доверенного входа и ожидаемого workflow-контекста по используемому профилю. Внутренний обработчик затем декодирует только согласованную схему.
Нельзя открыть обычную публичную функцию записи и считать её защищённой только потому, что её также вызывает workflow. Прямой посетитель не должен получить эквивалентные полномочия. Граница потребителя описывается явно, как ранее граница межсетевого сообщения.
Результат внешней проверки может храниться в отдельном ReleaseCheckRegistry. Базовый CourseCatalog сохраняет объявление издателя; новый модуль сообщает определённый проверочный статус. Такой статус не устанавливает качество всех уроков автоматически и не меняет SHA-256 манифеста.
Секреты и внешние данные
API-ключи и административные полномочия не попадают в исходный Markdown, публичный report или открытый контракт. CRE имеет предусмотренные механизмы работы с секретами и отдельные возможности конфиденциальности. Их наличие не оправдывает случайное раскрытие чувствительных полей полезной нагрузки.
Досье заранее определяет, какие сведения действительно нужны внешнему сервису. Проверка общего выпуска может обходиться без личных данных читателя. Отправка полного пользовательского профиля только ради технической корреляции создаёт лишнюю зависимость и приватностный риск.
Зашифрованный токен старого starter kit не является автоматически совместимой моделью секретов новой среды. При переходе исследуют текущий способ управления, область доступа и восстановление. В этой серии нет реальных токенов или интерфейсных скриншотов, изображающих якобы проведённую настройку.
При таком переходе полезно сохранить отдельную таблицу соответствий собственного проекта. Старое назначение «проверить выпуск» остаётся; старый транспортный requestId архивируется; новое выполнение workflow получает новую идентичность; схема результата сохраняется только после проверки совместимости. Это наша процедура, а не утверждение, что CRE предоставляет буквальный метод импорта всех старых запросов. Если формат результата изменился, адаптер сначала объявляет новую версию схемы и способ обработки незавершённых назначений. Старые ответы не декодируются новым способом случайно. Пользовательская карточка сохраняет редакцию и основание статуса, чтобы переход среды не выдал результат прежней проверки за наблюдение нового запуска.
Для нового consumer успешная аутентификация report ещё не означает, что внешний статус разрешает публикацию. Прикладное правило связывает его с определённой редакцией и допустимым результатом. Издательское объявление остаётся отдельным действием, что предотвращает автоматическую передачу publisher-полномочия любому внешнему API.
Что переносим в план миграции
Сохраняем назначение задачи, прикладную схему, правила корреляции и ожидания пользователя. Пересматриваем сервисный запуск, доверенную границу доставки, административные полномочия и наблюдение выполнения. Прежние subscription IDs и адреса нельзя просто переименовать в новую конфигурацию без официального сопоставления.
Для существующего проекта полезна опись незавершённых старых запросов. Их история не становится историей нового workflow автоматически. Процесс перехода определяет, какое состояние архивируется и какие назначения будут созданы заново. Дубли не должны повторно применять результат к одному выпуску.
Итог — современный архитектурный маршрут без инструкции создавать новый Functions-проект. Первичные основания: уведомление Functions, CRE concepts и построение consumer. Миграция и исполнение не выполнены; следующие главы раскрывают устойчивые прикладные правила запроса, схемы и бюджета.