Web3-приложение: архитектура L2, оракулов и доказательств
Передаём систему вместе с её смыслом
Мы прошли от сетей исполнения до межсетевых сообщений, оракулов, автоматических отчётов и доказательств права. Заключительный результат курса — архитектурное досье учебной библиотеки. Оно должно позволять другому разработчику понять, что уже определено, что зависит от внешнего протокола и какие действия разрешены при отказе. Набор адресов без этих объяснений не является достаточной передачей системы.
В этой серии подготовлены учебные модели, фрагменты и ожидаемые сценарии. Мы не запускали узлы, workflow, генерацию proof, транзакции или проверочные программы. Поэтому досье не называется отчётом о работающем развёртывании. Оно задаёт договор и следующий отдельный этап исполнения, когда такое действие будет разрешено.
Начинаем с неизменных соглашений
Основной объект — курс 17 и его последовательные выпуски. Base CourseCatalog хранит объявление издателя. Для текущего формата contentHash равен SHA-256 точных сохранённых байтов release.json. Полный CID остаётся самостоятельным идентификатором. Досье корня хранения находится снаружи манифеста, чтобы файл не пытался включить корневой CID собственного выпуска.
В досье описываем, кто имеет право публиковать и деактивировать курс, как сохраняется история выпусков и где лежат исходные файлы. Не смешиваем публичную информацию выпуска с ключами издателя, секретами workflow или witness участников. Восстановление материалов и восстановление полномочий — разные процедуры.
Фиксированный Bitcoin-счёт 30000 сатоши не зависит от текущей USD-цены. Необязательный USD-режим имеет отдельную политику feed, единиц и свежести. Это соглашение переносится в интерфейс и техническую документацию, чтобы новый разработчик не добавил случайную ценовую зависимость всем урокам и счетам.
Карта модулей и прав
Составим минимальную карту. Каждый ряд обозначает отдельную ответственность, а не уже развёрнутый контракт.
| Модуль | Основание действия | Ограниченный результат |
|---|---|---|
| CourseCatalog | полномочие издателя | объявление выпуска |
| MirrorCatalog | доверенный транспорт и источник | отражение объявления |
| PricePolicy | допустимый feed и свежие единицы | предложение цены |
| ReleaseCheckRegistry | подлинный подходящий отчёт | запись наблюдения |
| AssignmentRegistry | зафиксированный запрос случайности | назначение варианта |
| AccessClaimRegistry | proof, контекст и журнал использования | одно право получателю |
Модуль хранения отвечает за байты, реплики и восстановление. Он не определяет издателя сам по себе. Workflow может проверить доступность, но не получает полномочие менять содержание курса. Управление группой участников допускает членство, но не подтверждает правильность решения упражнения без отдельной процедуры.
У каждого административного действия записывается роль. Смена feed, transport allowlist, verifier или workflow-источника имеет собственную ревизию и последствия для незавершённых операций. Формула «администратор может всё» не объясняет, какие обещания сохраняются при такой смене.
Профиль окружения
Общий учебный EVM-профиль использует Solidity 0.8.30, целевой Cancun, локальный chainId 31337, Node 22.14.0 и viem 2.37.9. Эти версии являются согласованной базой курса, а не заявлением о новейших релизах или установленном окружении. Реальные L2 в этой серии обозначались ролями A и B; их публичные идентификаторы и адреса не выдумывались.
Для будущего исполнения выбранные сети задаются явно. ChainId не заменяет CCIP chain selector. Адрес приложения относится к конкретной сети и версии развёртывания. Профиль транспорта включает актуальный SDK, router, параметры проверки и лимиты. Пример из старой версии документации нельзя смешивать с текущим callback без согласованной миграции.
Прежние Functions и Automation рассматриваются исторически. Документация Functions и Automation направляет новые маршруты в CRE. Профиль будущего workflow фиксирует фактическую версию CLI и SDK, схему report и consumer. В этой серии такие пакеты не устанавливались и фактическая совместимость исполнения не заявлялась.
Как документировать жизненный цикл
Для доставки объявления сохраняем идентификатор сообщения и стадию исполнения. Для отчёта — jobId, выпуск, revision, observedAt и принятый слот. Для случайного назначения — assignmentId, исходный requestId, зафиксированный набор и полученное слово. Для права — публичный контекст, допустимый корень, scope, nullifier и получатель.
Эти записи нельзя объединять в один общий id без правил. Межсетевой transport message не является выпуском, а запрос случайности не равен слоту проверки. Правильная связь идентификаторов помогает восстановить экранное состояние после перезагрузки, не создавая новых операций.
Досье содержит переходы состояния и запрещённые переходы. Например, принятый выпуск не откатывается поздним сообщением меньшей редакции; использованный scope не очищается сменой корня; задержка VRF не превращается в новый розыгрыш. Это конкретные свойства нашего продукта, которые нельзя вывести только из названий внешних сервисов.
Следующий этап исполнения
Будущий этап начинается с фиксации зависимостей и исходников каждого адаптера, а не с подключения реальных средств. Затем отдельно рассматриваются локальные модели контекста, кодирования и повторов. Лишь после этого выбираются поддерживаемые публичные тестовые сети и проверяется соответствие официальным параметрам. Этот порядок является планом, ничего из него здесь не запускалось.
Для bridges проверяется источник и поздняя доставка. Для feed — единицы, свежесть и восстановление sequencer. Для CRE — отчёт, revision и слот. Для ZK — верный verifier, message, старые корни и однократность. Для VRF — сопоставление requestId и невозможность переброса. В каждой будущей проверке ожидаемый эффект формулируется заранее, а реальный результат записывается отдельно.
При переходе от учебной модели к эксплуатации потребуется анализ административных ключей, восстановления состояния и внешних зависимостей. Он относится к конкретной архитектуре и выбранным сервисам. Нельзя объявить безопасность всего приложения на основании успешной арифметики одного фрагмента или корректного proof для упрощённого отношения.
Заключительная передача
Другому разработчику передаём исходники, формат манифеста, карту модулей, конфигурационные роли, версии отношений и журнал ожидаемых сценариев. Отдельно указываем, что примеры ещё не исполнены. Такая передача позволяет продолжить работу без ложного предположения, будто черновой consumer, воображаемый адрес и условный digest уже работают в одной сети.
Для пользователя сохраняется простой смысл: библиотека публикует учебные материалы, а дополнительные механизмы решают ограниченные задачи. Если дополнительная проверка недоступна, интерфейс объясняет область отказа. Если право принято, результат относится к зафиксированному получателю и выпуску. Если материалы восстановлены из архива, их байты сверяются с прежним объявлением.
Так завершается курс: не количеством подключённых сервисов, а ясным договором между содержимым, реестрами и пользовательским действием. Дальнейшее расширение начинается с нового самостоятельного результата и его границ, сохраняя уже определённые URL, форматы выпусков и смысл выданных прав.