Web3-оракул: бюджет запроса и лимиты исполнителя

Асинхронное задание имеет точную идентичность и допустимую схему ответа. Теперь библиотека должна ограничить его ресурс: сколько попыток допустимо, какой объём данных обрабатывается и когда требуется решение оператора. В уроке построим бюджет собственного процесса проверки выпуска, не подставляя выдуманные тарифы сервиса.

Все числа ниже выражены в условных учебных кредитах. Это не LINK, не газ, не USD и не наблюдённый счёт CRE. SDK и задания не запускаются. Результат — прикладная модель резервирования и остановки, которую позже можно связать с конкретными действующими условиями.

Бюджет имеет несколько измерений

Денежная или нативная стоимость не является единственным ограничением. У задания есть время, размер входа и ответа, количество попыток, число параллельных процессов и ресурс целевого обработчика. Превышение любого из этих пределов может остановить процедуру раньше расходования условных кредитов.

Если приложение ограничило только число повторов, один огромный ответ всё ещё способен занять чрезмерную память. Если ограничило только размер, бесконечная очередь маленьких запросов может перегрузить источник. Поэтому досье задаёт несколько независимых пределов и определяет владельца их изменения.

В конкретной CRE-интеграции исследуются актуальные quotas, поддержка сети и ресурсы capabilities. Для нашего курса не выбираем одинаковые параметры всем workflow. Условная модель показывает связь решений, а не гарантирует совместимость неизвестного профиля.

Резерв до попытки

Допустим, на одно намерение выделено 50 кредитов. Предельная условная стоимость одной попытки — 12 за получение и 3 за предусмотренный обработчик. Три попытки резервируют до 45, оставляя 5. Это арифметический пример по заданным правилам, не формула реального биллинга.

лимит намерения: 50
предел попытки: 12 + 3 = 15
предел числа попыток: 3
общий предусмотренный резерв: 45

Резерв не равен фактически понесённым затратам. Если сервис использует иной порядок оплаты, неизвестный результат или отдельные платные стадии, модель должна отражать это. Нельзя автоматически освобождать всё резервирование при тайм-ауте страницы, когда внешний процесс мог уже начаться.

Для собственного журнала сохраняем запланированный предел, известные затраты и неопределённую часть. Эти значения позволяют остановить новый повтор до превышения выбранного договора. Они не становятся точным внешним счётом без предусмотренного источника подтверждения.

Причина повтора

Временная недоступность может быть основанием ограниченного повторного получения. Неподдерживаемая схема или недопустимый источник обычно требуют изменения условий, а не трёх одинаковых вызовов подряд. Поэтому повторная политика получает код причины и состояние предыдущей попытки.

При неизвестной отправке сначала выполняется допустимая сверка, если сервис её предоставляет. Новая попытка может создать дополнительное внешнее выполнение, а не заменить старое. Бюджет учитывает эту возможность и сохраняет все идентичности. Неопределённость не скрывается тем, что приложение обнулило счётчик после перезапуска.

Задержка между повторами уменьшает нагрузку, но не является доказательством будущего успеха. Предельный срок и число попыток остаются явными. После их достижения оператор получает понятный результат: задача не завершена по выбранной политике, а не «API никогда не существует».

Ресурс ответа и consumer

Большой допустимый JSON может быть дорогим для обработчика. Для onchain-report дополнительно важен предел целевого исполнения и схема данных. В первом проекте библиотеки передаётся небольшой фиксированный результат, а подробный отчёт хранится отдельно. Это решение ограничивает обработку, не изменяя смысл проверки.

Не следует переносить правила оплаты и возврата газа одного механизма на другой. Межсетевой callback, CRE-capability и обычная транзакция могут иметь разные условия. Досье хранит актуальные источники для каждой стоимости. Наши условные 3 кредита не означают, что реальный обработчик всегда стоит именно столько.

Если consumer завершился отказом, внешний ресурс мог быть потрачен. Прикладной успех и биллинг различаются. Поэтому бюджет не списывает затраты только после положительного результата проверки, иначе повторяющаяся ошибка может выглядеть «бесплатной» в собственном журнале.

Параллельные задания

Курс 17 может иметь несколько редакций в подготовке. Каждый job имеет собственный предел, но сервису нужен ещё общий лимит параллельности. Иначе сотня допустимых индивидуальных заданий одновременно перегрузит один источник. Очередь связывает ресурс и приоритет, сохраняя идентичность каждого намерения.

При резервировании общий лимит должен изменяться атомарно по выбранной серверной модели. Два работника не должны оба увидеть последний свободный слот и создать два внешних процесса сверх ограничения. Проверка переменной в памяти одного экземпляра недостаточна для распределённой очереди.

Отмена или завершение освобождает ресурс только по согласованному критерию. Если внешняя попытка ещё имеет неизвестный результат, журнал хранит её незавершённость. Иначе новый процесс может превысить реальную нагрузку после того, как старый продолжит исполнение.

Срок пользователя и срок системы

Пользовательская карточка может перестать ждать через короткое время, а система продолжает наблюдение по общему пределу. Это помогает не удерживать вкладку открытой, сохраняя правильный поздний результат. Интерфейс сообщает стадию, а операторский журнал — оставшийся бюджет и причины попыток.

Если продукт действительно завершает намерение как expired, нужно определить судьбу позднего ответа. Он может быть сохранён для истории без нового прикладного действия. Бюджет нового задания не смешивается с прежним: разные намерения имеют разные решения и попытки.

Также не делаем дорогую операцию доступной любому посетителю без отдельного разрешения. Публичный просмотр статуса отличается от административного запуска проверки. Авторизация собственного приложения остаётся нужна независимо от качества внешней инфраструктуры.

Итог ресурсного договора

Подготовим пределы времени, размера, попыток и параллельности, правила резервирования и причины остановки. Ожидаемые случаи включают временный отказ, детерминированную ошибку, потерянный ответ, исчерпание лимита и позднее завершение. Программа бюджета и внешнее выполнение не исполнялись.

Актуальные возможности среды описаны в CRE, смысл обработки — в consensus computing. Следующая глава рассмотрит проверяемую случайность. Для неё нельзя механически применять правило «при задержке запросить новое значение»: возможность отбросить неудобный результат меняет смысл случайного выбора.

Оглавление серии