아키텍처

삼자 커밋먼트: 결제 의도, 실행 트랜스크립트, 정산을 하나의 검증 가능한 영수증으로 묶는 방법

글쓴이: IdeaBosque최종 업데이트: 2026年7月30日

핵심 요약

삼자 커밋먼트는 결제 의도, 실행 트랜스크립트 다이제스트, 정산 txid를 하나의 영수증으로 해시한다——감사자는 각각을 독립적으로 검증하고 결합 해시가 세 가지 모두를 커버하는지 확인한다——커밋먼트는 모든 단계를 커버하거나 커버하지 않거나이며, 부분 커버리지는 존재하지 않는다 (IETF draft-hopley-x402-retention-chain-06, 2026).
세션 간 재생은 해시 불일치로 감지되며, 정책으로 방지되지 않는다——binding_ref가 payment_hash와 action_ref를 함께 해시하기 때문에, 세션 A의 결제를 세션 B의 실행과 교체하면 다른 결합 해시가 생성된다; 검증자가 재계산하면 불일치가 발생한다 (x402 GitHub issue #2332, 2026).
MCP 모듈이 실행 트랜스크립트를 네이티브로 생성한다——각 도구 호출(벤더 컴플라이언스 스크리닝, 서플라이어 조회, 견적 작성)은 인수, 결과, 타임스탬프와 함께 기록된다; 트랜스크립트 다이제스트는 action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp}))이며, 네 개의 필드를 보유한 모든 당사자가 재계산할 수 있다 (IETF draft-etcheverry-action-ref-02, 2026).
x402의 Base 상 정산은 약 200ms 내에 payment_hash를 생성한다——온체인 트랜잭션 해시는 Base 블록체인을 조회하여 독립적으로 검증 가능; 운영자나 퍼실리테이터에 대한 신뢰가 불필요 (Chainalysis, 2026).
모든 구성은 SHA-256과 JCS(RFC 8785)를 사용한다——Hermus Agent 감사 추적이 사용하는 것과 동일한 정규화 표준(GitHub issue #487)으로, 실행 트랜스크립트 다이제스트는 에이전트 자체 감사 시스템에 의해 네이티브로 생성되며, 후에 부착되지 않는다.

문제: 각 단계를 개별적으로 감사하는 것은 필요하지만 충분하지 않다

6개 프로토콜의 에이전트 커머스 스택(UCP, A2A, MCP, ACP, AP2, x402)은 발견, 통신, 툴링, 체크아웃, 인가, 정산을 커버한다. 각 프로토콜은 자체 증거를 생성한다: x402는 결제 해시를 생성하고, MCP는 도구 호출 로그를 생성하며, AP2는 인가 mandate를 생성한다. 각 단계를 개별적으로 감사하는 것은 필요하다——결제가 정산되었는지, 실행이 발생했는지, 인가가 유효했는지 검증해야 한다.

하지만 분리된 감사 추적만으로는 충분하지 않다. 바인딩 없이, 공격자는 세션 A의 실제 결제를 세션 B의 실제 실행과 혼합할 수 있다. 둘 다 진짜 아티팩트이다. 어느 것도 위조되지 않았다. 하지만 같은 세션에서 발생하지 않았다. 결제 영수증은 결제가 발생했음을 증명한다. 실행 로그는 스크리닝이 실행되었음을 증명한다. 그것들을 암호학적으로 연결하는 바인딩 없이는, 그것들이 같은 거래라는 증거가 없다.

이것이 세션 간 재생 공격이다: 완료된 거래에서 진짜 payment_hash를 가져오고, 다른 거래에서 진짜 action_ref를 가져와서 페어링한다. 감사 시스템이 두 아티팩트가 개별적으로 유효하기 때문에 이 페어링을 신뢰하면, 위조된 복합체를 수용한다. 감사 추적은 정산된 결제와 실행된 스크리닝을 보여준다——하지만 그것들은 다른 거래에서 온 것이다.

바인딩 단계가 이 공격을 감지하는——또는 감지하지 못하는——곳이다.

아키텍처: 스택이 각 컴포넌트를 어떻게 생성하는가

아래 다이어그램은 전체 삼자 커밋먼트 흐름을 보여준다——어떤 시스템이 어떤 아티팩트를 생성하는지, 바인딩 레이어가 그것들을 어떻게 구성하는지, 감사자가 어떻게 검증하는지:

스택에서 각 컴포넌트가 어떻게 생성되는가

결제 의도: x402 서명 오퍼

에이전트가 유료 벤더 컴플라이언스 스크리닝 API를 호출하면, 서버는 서명된 오퍼와 함께 HTTP 402를 반환한다. offer-receipt 확장(x402 프로토콜에 병합됨)은 서버를 특정 결제 조건에 커밋한다: amount, asset, payTo address, fulfill되는 정확한 resource, 유효 기간. 오퍼는 EIP-712(Ethereum wallet 기반) 또는 JWS(모든 비대칭 키, Solana Ed25519 포함)로 서명된다.

오퍼는 결제 의도——에이전트가 지불하려는 것——이다. 감사자는 독립적으로 해시한다:

offer_hash = SHA-256(JCS(signed offer terms))

감사자는 서명된 오퍼 조건에서 재계산하고 서버의 서명을 검증한다. payment backend와의 연락은 불필요——오퍼는 휴대 가능한 서명된 아티팩트이다.

실행 트랜스크립트: MCP 도구 호출 로그

MCP 모듈은 에이전트를 벤더 컴플라이언스 API, 서플라이어 카탈로그, 결제 rails에 연결한다. 각 MCP 도구 호출은 기록된다: 어떤 모듈이 호출되었는지, 어떤 인수가 전달되었는지, 어떤 결과가 반환되었는지, 어떤 타임스탬프에, 어떤 정책 버전 하에서. 이것이 실행 트랜스크립트이다.

Hermes Agent 감사 추적(GitHub issue #487)은 RFC 8785(JCS) 정규화를 사용한 SHA-256 해시 체인 액션 로깅을 구현한다——action_ref와 binding_ref가 사용하는 것과 동일한 표준이다. 실행 트랜스크립트 다이제스트는 에이전트 자체 감사 시스템에 의해 네이티브로 생성된다:

action_ref = SHA-256(JCS({
  agent_id: "procurement-agent-001",
  action_type: "compliance.screen",
  scope: "vendor:acme-corp screening-type:sanctions",
  timestamp: "2026-07-31T19:45:23.482Z"
}))

감사자는 이 네 개의 preimage 필드에서 action_ref를 재계산한다. 에이전트나 그 운영자와의 연락은 불필요. 정규화는 RFC 8785에 의해 정의되며, 직렬화자에 의해 정의되지 않는다——따라서 해시는 구현 간에 결정적이다.

policy_bound_ref는 액션이 실행되었을 때 유효했던 정책 버전을 바인딩한다. 제재 목록이 2026년 6월과 7월 사이에 업데이트된 경우, 정책 해시가 변경되고 감사자는 어떤 버전이 활성이었는지 감지할 수 있다. gate_ref는 컴플라이언스 스크리닝의 ALLOW/DENY 판정을 정책 참조에 바인딩하여, 결과가 그것을 생성한 규칙 버전에 증명 가능하게 연결된다.

정산: Base 상의 온체인 txid

x402 퍼실리테이터는 에이전트의 서명된 결제 인가를 검증하고, 온체인 트랜잭션을 구성하고, Base에서 브로드캐스트한다. 정산은 약 200ms 내에 완료된다. 퍼실리테이터는 트랜잭션 해시(payment_hash)를 서버에 반환하고, 서버는 이를 PAYMENT-RESPONSE 헤더에서 에이전트에게 전달한다.

감사자는 Base 블록체인을 조회하여 payment_hash를 검증한다——txid는 공개적이고 불변한 기록이다. 퍼실리테이터나 payment backend에 대한 신뢰가 불필요. 감사자는 다음을 확인한다:

트랜잭션이 Base에 존재함
amount가 오퍼 조건과 일치함
payTo address가 오퍼와 일치함
트랜잭션이 확인됨(보류 중이 아님)

바인딩: binding_ref가 3개를 어떻게 구성하는가

binding_ref(IETF draft-hopley-x402-retention-chain-06)는 세 개의 해시를 하나의 커밋먼트로 구성한다:

binding_ref = SHA-256(JCS({
  offer_hash,      // 약속된 내용(결제 의도)
  action_ref,      // 실행된 내용(MCP 트랜스크립트 다이제스트)
  payment_hash     // 정산된 내용(온체인 txid)
}))

이것은 삼자 커밋먼트이다. 감사자는 각 컴포넌트를 독립적으로 검증한다:

offer_hash — 서명된 오퍼 조건에서 재계산, 서버 서명 검증
action_ref — 네 개의 preimage 필드에서 SHA-256 재계산, 에이전트 연락 불필요
payment_hash — Base 블록체인 조회, txid 존재 및 정산 확인

그런 다음 감사자는 세 가지 모두에서 binding_ref를 재계산하고 일치하는지 확인한다. 어떤 컴포넌트가 교체된 경우——세션 A의 결제를 세션 B의 실행과 페어링한 경우——결합 해시는 일치하지 않을 것이다. 커밋먼트는 세 단계 모두를 커버하거나 커버하지 않는다. 부분 커버리지는 존재하지 않는다.

세션 간 재생이 어떻게 감지되는가

세션 간 재생 공격은 다음과 같이 작동한다: 공격자는 세션 A의 완료된 거래에서 진짜 payment_hash를 가져오고, 세션 B의 다른 거래에서 진짜 action_ref를 가져와서 페어링한다. 두 아티팩트 모두 진짜이다. 어느 것도 위조되지 않았다. 하지만 같은 세션에서 발생하지 않았다.

바인딩 없이, 감사 시스템은 payment_hash와 action_ref를 별도로 검사하고, 둘 다 유효하다고 판단하여 복합체를 수용한다. 감사 추적은 정산된 결제와 실행된 스크리닝을 보여준다——하지만 그것들은 다른 거래에서 온 것이다.

binding_ref를 사용하면, 감사자는 영수증의 실제 payment_hash와 action_ref에서 결합 해시를 재계산한다. 공격자가 하나를 다른 세션에서 교체한 경우, 해시는 다른 preimage 컨텍스트에서 온 것이며, 결합된 binding_ref는 영수증의 값과 일치하지 않을 것이다. 검증자는 불일치를 감지한다. 커밋먼트가 모든 단계를 커버하지 않으므로 거부된다.

이것이 바인딩 단계를 신뢰의 원시 요소로 만드는 것: 새로운 증거를 추가하는 것이 아니라, 기존 증거를 암호학적으로 연결한다. Base 상의 결제 해시는 검증 가능하다. 실행 로그는 검증 가능하다. 바인딩 증명이 그들 간의 연결을 검증 가능하게 만든다. 연결 없이, 각각은 독립적인 주장이다. 연결이 있으면, 감사자가 엔드 투 엔드로 검증할 수 있는 하나의 복합 영수증이다.

이것이 빌드에 의미하는 바

컴플라이언스를 위해 주당 85개의 서플라이어를 스크리닝하는 조달 에이전트는 감사 추적에 삼자 커밋먼트가 필요하다. 스택에서의 구현:

MCP 모듈이 실행 트랜스크립트를 생성한다. 각 도구 호출은 인수, 결과, 타임스탬프, 정책 버전과 함께 기록된다. 트랜스크립트 다이제스트는 action_ref이며, JCS 정규화를 사용하여 Hermes Agent 감사 시스템에 의해 네이티브로 계산된다.
x402가 정산을 처리한다. 퍼실리테이터는 Base에서 정산하고 payment_hash를 반환한다. offer-receipt 확장은 402 응답 시 결제 의도에 서명한다.
감사 레이어(에이전트나 payment backend가 아님)가 offer_hash, action_ref, payment_hash에서 binding_ref를 계산한다. 또한 정책 버전과 컴플라이언스 판정을 바인딩하기 위해 policy_bound_ref와 gate_ref도 계산한다.
휴먼 인 더 루프 체크포인트는 결제 인가 시 복합 영수증을 본다: 오퍼 조건, 실행 결과, 정산 확인, 정책 버전, 판정——모두 binding_ref로 연결.
외부 감사자(규제자, 카운터파티, 내부 컴플라이언스)는 각 해시를 독립적으로 재계산하여 복합 영수증을 검증한다. 에이전트, payment backend, 감사 레이어 운영자와의 연락은 불필요.

검증은 몇 초 걸린다: txid를 위해 Base를 조회하고, 네 개의 필드에서 action_ref를 재계산하고, 서명된 조건에서 offer_hash를 재계산하고, 세 가지에서 binding_ref를 재계산한다. 커밋먼트는 모든 단계를 커버하거나 커버하지 않는다. 이것이 에이전트 커머스를 엔드 투 엔드로 감사 가능하게 만드는 원시 요소이다.