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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что не входит в цепочку

Обычный байткод и вывод VM не могут войти в цепочку Ваучера. Необязательный скомпилированный путь тоже начинается с точных внешних исходника и входа потребителя. Контейнер lispex.vouch-compiled-artifact/v1, который всегда записывается одинаково, должен быть заново выведен из этого исходника до запуска проверенной Rust VM. Файл .lpxbc, хэш, результат верификатора байткода, отчёт о структурной проверке, наблюдение VM и отчёт сравнения tree/VM не заменяют запрос, аутентификацию, согласие текущего tree/Meaning или живую проверку допуска.

Необязательная байткодная VM Топаза является отдельным диагностическим маршрутом, а не ещё одним верификатором Ваучера. Её установленный продукт, JSON запроса и результата, вывод выполнения, наблюдение ресурсов и квитанцию compare-vms нельзя подать в vouch verify, скомпилированное повторное выполнение или vouch gate. Согласие с Топазом не создаёт и не усиливает разрешение.

Чего Ваучер не разрешает и не гарантирует

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

Куда дальше

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