바우치는 “이 결정 기록을 믿어도 되는가?”라는 한 문장을 서로 독립적인 네 가지 작은 질문으로 나눕니다.
- 인증: 내가 허용한 키가 정확히 이 내용에 서명했는가?
- 요청 결속: 그 내용이 지금 내가 고른 정확한 소스와 입력을 가리키는가?
- 현재 실행 일치: 현재 네이티브 인터프리터로 다시 실행해도 같은 전체 결과가 나오는가?
- 로컬 결정: 그 결과가 이 호출에서 요구한 결정과 정확히 같은가?
앞 질문을 통과했다고 뒤 질문까지 자동으로 통과한 것은 아닙니다. 이 분리가 바우치의 핵심입니다.
어떤 결정을 다루나요?
확인 대상은 리스펙스 규칙 하나가 정확한 입력 하나를 받아 낸 결과입니다.
예를 들어 환불 규칙이 approve나 deny를 돌려준 실행이 여기에 해당합니다.
바우치는 그 실행의 기록을 확인할 뿐, 결정을 새로 내리거나 환불 같은 외부
행위를 실행하지 않습니다.
어떤 증거가 남나요?
발행자는 네이티브에서 정확한 소스 바이트, 입력 바이트, 프로필, 완전한 실행 기록을 하나의 결합된 컨텍스트로 묶어 서명합니다. 이 서명 결과가 봉투(envelope)입니다. 봉투와 소스·입력 바이트를 한 파일로 함께 나르는 형식이 묶음(bundle)입니다. 묶음은 운반 상자일 뿐이라서, 그 자체로는 신뢰도 권한도 만들지 않습니다.
무엇을 믿을지는 소비자가 신뢰 정책(trust policy)으로 정합니다. 정책에는 소비자가 직접 검토한 공개 키, 실행 엔진 다이제스트, 허용할 정확한 소스 식별자가 들어갑니다. 검증할 아티팩트에서 신뢰를 끌어내지 않습니다.
서명된 기록이 증명하는 것
인증에 성공하면 “정책이 허용한 키가 정확히 이 결합된 컨텍스트에 서명했다”는 사실 하나가 성립합니다. 서명은 사람이나 조직의 신원, 서명한 시각, 규칙 내용의 정당성을 증명하지 않습니다. 봉투 안의 실행 기록도 발행 시점에 선언된 관측일 뿐, 지금 다시 실행해도 같으리라는 보장은 아닙니다. 그래서 현재 실행 일치는 인증과 분리된 별도 질문으로 남습니다.
왜 요청을 먼저 결속해야 하나요?
묶음에는 소스와 입력이 들어갈 수 있지만, 그것은 발행자가 운반해 온
컨텍스트입니다. 소비자가 별도 소스와 입력을 주지 않으면 묶음은 인증
대상일 뿐, 현재 실행이나 gate가 사용할 요청을 정할 수 없습니다. 그래서
네이티브 재실행과 gate는 외부 --source·--input 쌍을 모두 요구하고,
하나만 주는 호출도 시작 전에 거부합니다.
완전히 증명된 리스펙스 이미지는 --source-image로 정확한 소스 바이트를
공급할 수 있습니다. 이미지가 바꾸는 것은 소스 표현뿐입니다. 입력 선택,
신뢰 정책, 재실행, gate의 단계는 그대로 남습니다.
확인 도구가 증거를 소비하는 방법
| 알고 싶은 것 | 사용할 작업 | 얻는 것 |
|---|---|---|
| 파일 구조가 맞는가? | 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 추가 | 소스 전용 또는 컴파일 경로의 로컬 grant·거부 |
| 변경 전후 코퍼스가 같은가? | npm lispex vouch replay | 고정 사례 비교 |
| 외부 엔진 보고서를 검사하고 싶은가? | Bridge 검사기 | 별도 아티팩트 클래스의 구조·결속 검사 |
가장 안전한 기본 순서는 다음과 같습니다.
- 소비자가 검토한 공개 키, 실행 엔진, 규칙 소스로 신뢰 정책을 만듭니다.
- 발행자는 네이티브로 정확한 소스와 입력의 묶음을 발행합니다.
- 소비자는 묶음만 믿지 않고, 자신이 고른
--source와--input을 다시 제공합니다. - 네이티브나 npm으로 먼저 인증합니다.
- 현재 실행 일치가 필요할 때만 네이티브에서
--reexecute를 사용합니다. - 검증된 Rust VM 일치도 필요할 때만 같은 정확한 소스로 컴파일 산출물을
만들고 검사한 뒤
--compiled-artifact를 추가합니다. - 애플리케이션이 특정 결정을 요구할 때만 같은 네이티브 호출 안에서 gate를 사용합니다.
전체 명령은 바우치 전체 흐름에 순서대로 있습니다.
컴파일 산출물과 Topaz는 특별 취급하지 않습니다
일반 바이트코드와 VM 출력은 이 체인에 들어갈 수 없습니다. 선택적인 컴파일
경로도 소비자가 밖에서 준 정확한 소스와 입력에서 시작합니다. 그 소스로
lispex.vouch-compiled-artifact/v1을 다시 유도해 정확히 일치시킨 뒤에만
검증된 Rust VM을 실행합니다. .lpxbc 파일, 해시, verifier 결과, 검사
보고서, VM 관측, tree/VM 비교 보고서는 소스 요청·인증·현재 tree/Meaning
일치·살아 있는 gate 전이를 대신하지 못합니다.
선택형 Topaz 바이트코드 VM은 별도 진단 경로이지 또 하나의 바우치 검증자가
아닙니다. 설치 제품, 요청·결과 JSON, 실행 출력, 자원 관측, compare-vms
영수증은 vouch verify, 컴파일 재실행, vouch gate에 넣을 수 없습니다.
Topaz와 일치해도 grant가 생기거나 강해지지 않습니다.
바우치가 승인하거나 보장하지 않는 것
- 유효한 서명은 사람·조직의 신원이나 서명 시각을 증명하지 않습니다.
- 정확한 요청 일치는 신선도, 만료, 폐기, 재전송 방지를 제공하지 않습니다.
- tree/Meaning과 VM 일치는 같은 Rust 계보의 근거일 뿐 독립 구현의 증언이나 전체 언어 동등성 증명이 아닙니다.
- 컴파일 일치는 이번 호출이 검사한 정확한 산출물·소스·입력·실행 기록·상한 밖의 compiler 정확성을 증명하지 않습니다.
- gate grant는 직렬화하거나 다른 프로세스로 넘길 수 있는 권한 토큰이 아닙니다.
- 보고서, 묶음, 이미지, 바이트코드, VM 결과, Bridge 아티팩트는 스스로 grant로 승격될 수 없습니다.
- 외부 결제·환불·배포 같은 부작용의 승인은 호출 애플리케이션이 따로 책임집니다.
다음으로
바우치 전체 흐름에서 실제 명령을 실행하거나, 아티팩트와 보고서에서 각 파일이 세우는 것과 세우지 않는 것을 조회하세요.