리스펙스 바우치

바우치가 어떤 결정을 확인하는지, 어떤 근거가 남는지, 서명이 인증하는 내용, 요청 결속과 현재 재실행과 로컬 게이트가 이어지는 순서를 설명합니다.

바우치는 “이 결정 기록을 믿어도 되는가?”라는 한 문장을 서로 독립적인 네 가지 정확한 질문으로 나눕니다.

  1. 인증. 내가 허용한 키가 정확히 이 내용에 서명했는가?
  2. 요청 결속. 그 내용이 지금 내가 고른 정확한 소스와 입력을 가리키는가?
  3. 현재 실행 일치. 현재 네이티브 인터프리터로 다시 실행해도 같은 전체 결과가 나오는가?
  4. 로컬 결정. 그 결과가 이 호출에서 요구한 결정과 정확히 같은가?

각 단계는 앞 단계가 이름 붙여 남긴 결과를 입력으로 받습니다. 이 분리가 바우치의 핵심입니다.

어떤 결정을 다루나요?

확인 대상은 리스펙스 규칙 하나가 정확한 입력 하나를 받아 낸 결과입니다. 예를 들어 환불 규칙이 approvedeny를 돌려준 실행이 여기에 해당합니다. 바우치는 실행 기록을 확인하고 로컬 결정을 호출 애플리케이션에 전달합니다. 환불과 결제와 배포 같은 외부 동작은 호스트 애플리케이션이 실행합니다.

어떤 증거가 남나요?

발행자는 네이티브에서 정확한 소스 바이트, 입력 바이트, 프로필, 완전한 실행 기록을 하나의 결합된 컨텍스트로 묶어 서명합니다. 이 서명 결과가 봉투입니다. 봉투와 소스·입력 바이트를 한 파일로 함께 나르는 형식이 묶음입니다. 묶음은 정확한 바이트를 운반하고, 소비자의 신뢰 정책이 허용 키와 엔진 신원과 검토한 소스를 제공해 인증합니다.

무엇을 믿을지는 소비자가 신뢰 정책으로 정합니다. 신뢰 정책은 증거를 받는 쪽이 직접 검토한 공개 키와 규칙을 실행할 정확한 프로그램의 짧은 지문과 허용할 정확한 소스 식별자로 구성합니다.

서명된 기록이 제공하는 것

인증에 성공하면 정책이 허용한 키가 정확히 결속된 컨텍스트에 서명했다는 사실이 기록됩니다. 신원 매핑과 시각 정책은 소비자의 신뢰 정책이 소유하고, 규칙 선택과 요청 승인은 애플리케이션이 소유합니다. 봉투 안의 실행 기록은 발행 시점 관측을 담고, 현재 실행 일치는 --reexecute가 새로 기록합니다.

왜 요청을 먼저 결속해야 하나요?

묶음에는 발행자가 선택한 소스와 입력이 들어갑니다. 묶음은 인증 대상이고, 소비자는 별도 --source--input으로 현재 재실행과 게이트가 사용할 요청을 선택합니다. 네이티브 재실행과 게이트는 두 외부 경로를 모두 받으며 불완전한 쌍은 파일을 읽기 전에 거부합니다.

검증을 마친 리스펙스 이미지는 --source-image로 정확한 소스 바이트를 공급할 수 있습니다. 이미지가 바꾸는 것은 소스를 실어 나르는 방식뿐입니다. 입력 선택, 신뢰 정책, 재실행, 게이트의 단계는 그대로 남습니다.

확인 도구가 증거를 소비하는 방법

네이티브는 실행을 두 가지 경로로 확인합니다. 하나는 소스를 그대로 읽어 내려가는 tree 경로이고, 다른 하나는 같은 소스를 먼저 옮겨 놓은 Meaning 경로입니다. 문서에서는 이 둘을 묶어 tree/Meaning이라고 씁니다. 아래 표에 나오는 Rust VM은 소스를 직접 읽지 않고 컴파일된 명령을 실행하는 가상 머신입니다.

알고 싶은 것사용할 작업얻는 것
파일 구조가 맞는가?lispex vouch inspect서명하지 않은 구조 검사
허용한 키가 서명했는가?lispex vouch verify인증 보고서
내가 고른 소스·입력과 같은가?vouch verify--source--input 추가요청 결속 인증 보고서
지금 tree/Meaning 실행도 같은가?네이티브 vouch verify --reexecute인증과 현재 실행을 분리한 보고서
정확한 소스에서 만든 컴파일 산출물과 VM도 같은가?네이티브 재실행에 --compiled-artifact 추가정확한 재유도 결과, 바이트코드 검증기 결과, 현재 Rust VM 결과
지금 요구한 결정과 같은가?네이티브 vouch gate --require-decision, 필요하면 --compiled-artifact 추가소스 전용 또는 컴파일 경로의 로컬 통과나 거부
저장해 둔 예제 모음이 달라졌는가?npm lispex vouch replay고정 사례 비교
외부 엔진 보고서를 검사하고 싶은가?브릿지 검사기별도 종류의 파일에 대한 구조·결속 검사

가장 안전한 기본 순서는 다음과 같습니다.

  1. 소비자가 검토한 공개 키, 규칙을 실행할 정확한 프로그램, 규칙 소스로 신뢰 정책을 만듭니다.
  2. 발행자는 네이티브로 정확한 소스와 입력의 묶음을 발행합니다.
  3. 소비자는 자신이 고른 --source--input을 요청으로 제공합니다.
  4. 네이티브나 npm으로 먼저 인증합니다.
  5. 현재 실행 일치가 필요할 때만 네이티브에서 --reexecute를 사용합니다.
  6. 검증된 Rust VM 일치도 필요할 때만 같은 정확한 소스로 컴파일 산출물을 만들고 검사한 뒤 --compiled-artifact를 추가합니다.
  7. 애플리케이션이 특정 결정을 요구할 때만 같은 네이티브 호출 안에서 게이트를 사용합니다.

전체 명령은 바우치 전체 흐름에 순서대로 있습니다.

컴파일 산출물과 토파즈의 역할

선택형 컴파일 경로는 소비자가 밖에서 준 정확한 소스와 입력에서 시작합니다. 그 소스로 정규 lispex.vouch-compiled-artifact/v1을 다시 유도하고 바이트코드를 검사한 뒤 검증된 Rust VM을 실행합니다. 소스 요청과 인증과 현재 tree/Meaning 일치와 컴파일 관측과 살아 있는 게이트 전이는 한 체인의 이름 붙은 단계입니다.

토파즈 바이트코드 VM은 별도 진단 비교 경로를 제공합니다. 설치 제품은 요청· 결과 JSON과 실행 출력과 자원 관측과 compare-vms 영수증을 만듭니다. 현재 네이티브 바우치 경로가 프로세스 안의 로컬 게이트 통과를 맡습니다.

바우치의 권한과 범위

  • 유효한 서명은 정확히 검사한 바이트에 대해 허용된 키를 인증합니다. 수신자 신뢰 정책이 그 키를 조직과 배포 환경에 연결합니다.
  • 정확한 요청 일치는 제공된 소스와 입력을 결속합니다. 신선도와 만료와 폐기와 재전송 정책은 호출 애플리케이션이 관리합니다.
  • tree/Meaning과 VM 일치는 하나의 Rust 계보 안에서 두 실행 경로와 이번 호출이 검사한 정확한 프로파일을 기록합니다.
  • 컴파일 일치는 이번 호출이 검사한 정확한 산출물과 소스와 입력과 실행 기록과 상한을 검증합니다.
  • 게이트 통과는 현재 네이티브 호출 안에서 살아 있으며 로컬 결정 하나로 호출 애플리케이션에 전달됩니다.
  • 보고서와 묶음과 이미지와 바이트코드와 VM 결과와 브릿지 아티팩트는 살아 있는 검증 체인의 입력으로 사용됩니다.
  • 외부 결제와 환불과 배포를 포함한 모든 부작용의 승인은 호출 애플리케이션이 책임집니다.

다음으로

바우치 전체 흐름에서 실제 명령을 실행하거나, 아티팩트와 보고서에서 각 파일의 정확한 역할을 조회하세요.

리스펙스 바우치 · 리스펙스