Песочница

Ваучер Лиспекса

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

Какое решение проверяется

Правило Лиспекса представляет собой программу, которая на один и тот же вход всегда выдаёт одно и то же решение, например approve. Ваучер отвечает на общий вопрос «можно ли доверять этому JSON с решением?», разделяя его на четыре независимых вопроса.

  1. Аутентификация. Разрешённый ключ подписал именно эти байты?
  2. Привязка запроса. Описывают ли эти байты точный исходник и вход, которые выбрал сам потребитель?
  3. Согласие текущего выполнения. Воспроизводит ли текущий интерпретатор Native тот же полный результат?
  4. Локальное решение. Совпадает ли живой результат с решением, которое требует именно этот вызов?

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

Какие свидетельства сохраняются

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

Что фиксируют переносимые файлы

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

Почему запрос привязывается до любых полномочий

Пакет переносит исходник и вход, выбранные издателем, и служит объектом аутентификации. Потребитель выбирает запрос через собственные --source и --input. Native принимает оба внешних пути для повторного выполнения и локального шлюза и отклоняет неполную пару до чтения файла.

Полностью проверенное изображение Лиспекса может передать точные байты исходника через --source-image. Меняется только способ переноса исходника, а выбор входа, политика доверия, повторное выполнение и проверка допуска остаются отдельными этапами.

Как этапы используют артефакты

У Native есть два штатных пути проверки выполнения. Первый называется tree и представляет собой обход дерева самого исходника. Второй называется Meaning Graph, то есть граф смысла, в который тот же исходник переводится заранее. В документации эта пара обозначается как tree/Meaning. Повторное выполнение сравнивает их текущее согласие с подписанными полными протоколами. В таблице также упоминается проверенная Rust VM, виртуальная машина, которая выполняет скомпилированные инструкции вместо чтения исходника. Выберите операцию по своему вопросу.

Что нужно узнатьОперацияРезультат
Файл структурно согласован?lispex vouch inspectПроверка структуры без подписи
Его подписал разрешённый ключ?lispex vouch verifyОтчёт аутентификации
Он совпадает с моими исходником и входом?Добавьте --source и --input к vouch verifyОтчёт аутентификации с привязкой запроса
Текущее выполнение tree/Meaning совпадает?Native vouch verify --reexecuteРаздельные результаты аутентификации и текущего выполнения
Согласна ли также проверенная Rust VM с артефактом, точно выведенным из исходника?Добавьте --compiled-artifact к повторному выполнению NativeТочное повторное выведение, результат верификатора байткода и результат текущей Rust VM
Живой результат равен требуемому решению?Native vouch gate --require-decision, при необходимости с --compiled-artifactЛокальное разрешение или отказ исходного либо скомпилированного пути
Изменился ли сохранённый набор примеров?npm lispex vouch replayСравнение фиксированных случаев
Это отчёт внешнего движка?Проверка BridgeПроверка отдельного вида файлов

Безопасный путь по умолчанию

  1. Потребитель создаёт политику доверия из независимо проверенных открытого ключа, точной программы, которая выполняет правило, и исходника правила.
  2. Издатель создаёт в Native транспортный пакет для точных байтов исходника и входа.
  3. Потребитель передаёт свои --source и --input в качестве запроса.
  4. Native или npm выполняет аутентификацию.
  5. Повторное выполнение в Native добавляется только тогда, когда нужно сверить текущее поведение.
  6. Если требуется также согласие проверенной Rust VM, из того же точного исходника собирается и проверяется артефакт, затем явно добавляется --compiled-artifact.
  7. Проверка допуска в Native используется только тогда, когда приложению нужно одно точное решение в том же вызове.

Команды в этом порядке находятся в полном процессе Ваучера.

Роли скомпилированного пути и Топаза

Скомпилированный путь начинается с точных внешних исходника и входа потребителя. Из исходника заново выводится канонический контейнер lispex.vouch-compiled-artifact/v1, затем проверяется байткод и запускается проверенная Rust VM. Запрос, аутентификация, текущее согласие tree/Meaning, скомпилированное наблюдение и локальный шлюз остаются именованными этапами одной цепочки.

Байткодная VM Топаза предоставляет отдельный диагностический маршрут сравнения. Установленный продукт создаёт JSON запроса и результата, вывод выполнения, наблюдение ресурсов и квитанцию compare-vms. Текущий маршрут Native Vouch отвечает за локальное разрешение внутри процесса.

Полномочия и область Ваучера

  • Действительная подпись аутентифицирует разрешённый ключ над точными проверенными байтами. Политика доверия получателя связывает ключ с организацией и средой развёртывания.
  • Точное равенство запроса связывает предоставленные исходник и ввод. Вызывающее приложение управляет свежестью, сроком действия, отзывом и политикой повторного предъявления.
  • Согласие tree/Meaning и VM фиксирует два маршрута выполнения в одной линии Rust и точный профиль, проверенный этим вызовом.
  • Скомпилированное согласие проверяет точные артефакт, исходник, ввод, протокол и лимиты этого вызова.
  • Результат проверки допуска живёт внутри текущего вызова Native и передаётся вызывающему приложению как одно локальное решение.
  • Отчёты, пакеты, изображения, байткод, результаты VM и артефакты Bridge служат входами живой цепочки проверки.
  • Вызывающее приложение управляет платежами, возвратами, развёртываниями и всеми другими внешними действиями.

Куда дальше

Выполните полный процесс или откройте Артефакты и отчёты, чтобы узнать точную роль каждого файла.