Ritual Chain LLM 프리컴파일 (Precompile): 영수증이 실제로 구속하는 것은 무엇인가

LLM 호출에 대한 영수증(receipt)은 그것이 무엇을 뒷받침해야 하는지 말하기 전까지는 아무런 의미가 없습니다. Ritual Chain에서 던져야 할 가치 있는 질문은 모델의 답변이 체인 인접 인프라(chain-adjacent infrastructure)에 도달했는지 여부가 아닙니다. 질문은 더 좁아야 합니다. 즉, 영수증이 경로의 어느 부분을 실제로 구속(bind)하며, 어느 부분이 여전히 애플리케이션의 검증 작업으로 남아 있는가 하는 점입니다.

공시: 초안 작성 및 구조화에 AI의 도움을 받았습니다. 이 기사는 기술 교육용이며, 투자, 거래, 토큰, 수익률 또는 금융 자문이 아닙니다.

영수증 표면 (The Receipt Surface)

Ritual Chain의 문서는 오프체인에서 검증 가능한 머신 태스크(machine tasks)를 가진 EVM을 설명하며, 여기서 HTTP 및 LLM과 같은 프리컴파일 (precompile) 호출은 실제 작업을 TEE 실행기(executors)에게 위임합니다. 이 세부 사항이 바로 영수증의 경계(boundary)를 면밀히 살펴볼 가치가 있게 만드는 요소입니다. 여기서 컨트랙트(contract)를 마주하는 결과는 모든 검증자가 다시 실행하는 일반적인 결정론적(deterministic) EVM 연산이 아니므로, 결과가 어디에서 왔는지가 답변의 일부가 됩니다.

문서에서는 LLM 프리컴파일을 0x0802에 배치하고, 컨트랙트가 프롬프트(prompt)를 보내고 완료(completion)를 돌려받는 흐름을 설명합니다. 좁게 읽어보면, 이 진술은 하나의 구현 주장만을 뒷받침합니다. 즉, LLM 추론(inference)을 위한 문서화된 프리컴파일 표면이 존재한다는 것입니다. 하지만 그 답변이 참인지, 안전한지, 편향되지 않았는지, 또는 민감한 동작을 트리거할 준비가 되었는지에 대해서는 아무것도 말해주지 않습니다.

짧은 비동기 경로 (The Short Async Path)

문서의 실행 경로는 세 가지 방식으로 나뉩니다: 동기적 작업 (synchronous work), 짧게 실행되는 비동기 작업 (short-running async work), 그리고 더 긴 2단계 비동기 작업 (longer two-phase async work)입니다. 첫 번째 경계는 짧게 실행되는 경로에 존재하는데, 문서에서 HTTP, LLM, DKMS 호출을 해당 경로로 그룹화하고 반환된 데이터를 receipt.spcCalls를 통해 라우팅하기 때문입니다.

개발자에게 있어, 해당 경로는 문서화된 프리컴파일 (precompile) 호출이 무엇을 반환했는지 검사할 수 있는 구체적인 지점을 애플리케이션에 제공합니다. 하지만 이것이 의미론적 오라클 (semantic oracle)은 아닙니다. receipt.spcCalls에 위치한 값은 결과가 문서화된 경로를 통해 돌아왔다는 증거가 될 수는 있지만, 귀하의 도메인(domain) 관점에서는 여전히 형편없는 답변일 수 있습니다.

스트리밍의 함정 (The Streaming Trap)

문서에는 선택적인 스트리밍 (streaming)에 대해서도 다루고 있는데, 여기서 실행자(executor)가 푸시한 토큰은 최종 확정 전 프론트엔드에 도달할 수 있으며 EIP-712 서명을 포함합니다. 여기서 정밀함이 중요합니다. EIP-712는 타입화된 구조화된 데이터 서명 (typed structured data signing)을 정의할 뿐, 그 이상은 아닙니다. 이는 스트리밍된 토큰을 최종적인 체인 상태 (chain state)로 전환하지 않으며, 재전송 공격 방지 (replay protection)를 증명하지도 않고, 텍스트가 정확하다는 것을 증명하지도 않습니다.

스트리밍된 텍스트를 렌더링하는 프론트엔드는 최종 영수증 (receipt) 경로가 도달할 때까지 이를 미리보기 (preview)로 취급해야 합니다. 서명은 인터페이스가 출처와 구조를 추론하는 데 도움을 주지만, 그것이 애플리케이션의 수용과는 거리가 멉니다. 어떤 동작에 텍스트가 영향을 미칠지(혹은 영향을 미치지 않을지)는 여전히 귀하의 애플리케이션이 결정합니다.

증명 (Attestation)은 평가 입력값이다

TEE 실행자 (TEE executors)와 TEEServiceRegistry와 같은 컴포넌트 역할 (component roles)은 문서에서 별도로 다루어지는데, 문서에서는 이를 TEE 실행자와 증명 (attestation) 증거를 등록하는 컨트랙트로 나열합니다. 이는 컴포넌트 역할에 대한 주장(claim)을 뒷받침할 뿐, 모든 모델 출력이 정확한지에 대해서는 아무것도 말해주지 않습니다.

RFC 9334는 원격 검증 (Remote Attestation)을 증거 (evidence), 검증 (verification), 그리고 신뢰 당사자 평가 (relying-party appraisal)로 프레임화함으로써 이 문제에 도움을 줍니다. 이러한 프레임화는 상황을 정직하게 유지합니다. 검증 (attestation) 결과는 정책 결정 (policy decision)에 반영될 수 있지만, 신뢰 당사자 (relying party)는 자체적인 정책을 유지합니다. LLM 답변의 경우, 출처 (provenance) 및 환경 증거 (environment evidence)가 답변 자체를 검증하는 것을 대신할 수는 없습니다.

송신자 잠금 (Sender Lock) 과 그 간극

각 EOA가 한 번에 하나의 대기 중인 비동기 작업 (async job)만 보유할 수 있는 송신자 잠금 (sender-lock) 경계도 나타납니다. 동일한 실행 문서 (execution docs)는 비동기 간극 (async gap) 전반에 걸친 TOCTOU (Time-of-Check to Time-of-Use) 위험을 경고하며, 콜백 (callback)이 도착했을 때 전제 조건 (preconditions)을 확인하는 작업을 소비자 컨트랙트 (consumer contract)로 넘깁니다.

이 두 가지 세부 사항은 모두 중요합니다. 왜냐하면 영수증 (receipt)을 완전한 제어 평면 (control plane)으로 취급하는 것을 방지하기 때문입니다. 영수증 경계 (receipt boundary)는 하나의 조각일 뿐입니다. 여러분의 애플리케이션은 여전히 시간, 대기 중인 작업, 오래된 가정 (stale assumptions), 그리고 요청과 응답 사이에 변화하는 상태 (state)를 고려해야 합니다.

영수증 경계 아티팩트 (Receipt Boundary Artifact)

이 아티팩트를 ritual_llm_precompile_receipt_boundary.v1이라고 부릅니다. 이것은 공식적인 Ritual 표준은 아닙니다. 영수증이 뒷받침할 수 있는 것과 애플리케이션이 여전히 증명해야 하는 것을 구분하는 개발자 체크리스트라고 생각하십시오.

{
  "schema": "ritual_llm_precompile_receipt_boundary.v1",
  "surface": "ritual_chain_llm_precompile",
...

영수증 상위의 애플리케이션 체크

영수증을 최종적인 판결이 아닌, 애플리케이션 계층에서의 소스 맵 (Source Map)으로 취급하십시오. 실행 가능한 정책은 스키마 형태 (Schema shape), 허용된 출력 클래스 (Allowed output classes), 오래된 상태 (Stale state), 소스 또는 도구 교차 검증 (Source or tool cross-checks), 그리고 출력이 최종 영수증 데이터에서 왔는지 아니면 스트리밍된 미리보기 (Streamed preview)에서 왔는지 여부를 확인합니다.

그러한 정책이 바로 LLM의 답변이 자리를 잡거나 버려지는 지점입니다. 예를 들어, 어떤 모델이 특정 주소가 안전하다고 주장한다고 가정해 봅시다. 영수증은 어떤 경로가 해당 문장을 생성했는지 증명하는 데 도움을 줄 수 있습니다. 하지만 그것이 해당 주소가 안전하다는 것을 여전히 증명하지는 못합니다. 그 판단은 반드시 영수증 상위 계층에서 이루어져야 합니다.

출처 (Sources)

• Ritual Chain 문서: https://docs.ritualfoundation.org/
• EIP-712 타입화된 구조화된 데이터 서명 (Typed structured data signing): https://eips.ethereum.org/EIPS/eip-712
• RFC 9334 RATS 아키텍처: https://datatracker.ietf.org/doc/rfc9334/
• Cascade 프라이버시 컨텍스트 논문: https://arxiv.org/abs/2507.05228