하나보다 둘이 낫다 — AI 에이전트를 위한 양방향 출처 증명 (Bilateral Provenance)

한 AI 에이전트가 재무 보고서를 생성합니다. 당신은 이를 공증합니다 — NEAR에 앵커링(anchored)되고 독립적인 공증인이 서명한 239바이트의 암호화 기록입니다. 이 기록은 다음을 증명합니다: 이 해시(hash)가 이 타임스탬프에 존재했으며, 증명(attestation)을 위해 0.01 USDC가 지불되었다.

일주일 후, 누군가 당연한 질문을 던집니다: 에이전트가 보고서를 작성했다는 것을 누가 증명했는가?

아무도 없습니다. 공증인은 클라이언트가 제출한 해시를 서명했을 뿐입니다. 누구든 그 해시를 제출할 수 있었습니다. PDR은 해당 해시가 존재했다는 것을 증명할 뿐 — 그 뒤에 있는 콘텐츠를 에이전트가 작성했다는 것을 증명하지는 않습니다.

이것이 바로 **양방향 서명 (Bilateral Signature, v0x04)**이 메우는 간극입니다. 에이전트는 자신의 Ed25519 키로 작업 해시(work hash)에 직접 서명합니다. 그 서명은 PDR에 융합됩니다. 이제 기록은 에이전트와 공증인이라는 두 개의 독립적인 서명을 가지게 되며, 어느 당사자도 이를 부인할 수 없습니다.

바인딩 해시 (The binding hash)

메커니즘은 단일 해시입니다:

binding_hash = sha256(work_hash + sig_A + agent_pubkey)

• work_hash — 에이전트 출력물의 SHA-256 값 (32 bytes)
• sig_A — work_hash에 대한 에이전트의 Ed25519 서명, NEP-413 표준 (64 bytes)
• agent_pubkey — 에이전트의 Ed25519 공개 키 (32 bytes)

이 바인딩 해시는 PDR의 payload_hash 필드에서 work_hash를 대체합니다. 그런 다음 공증인은 이미 바인딩 해시를 포함하고 있는 전체 175바이트 페이로드(payload)에 서명합니다. 따라서 공증인의 서명은 에이전트의 서명을 내부에 포함하고 있는 기록을 커버하게 됩니다.

v0x04 PDR을 위조하려면 두 개의 개인 키가 필요합니다: 공증인의 Ed25519 시드(seed)와 에이전트의 Ed25519 키입니다. 일반적인 v0x03의 경우 공증인의 키만 있으면 됩니다. 양방향 방식은 침해 요구 사항을 두 배로 늘립니다.

실제로 무엇이 바뀌었나

구조적으로는 거의 바뀌지 않았습니다 — 그리고 그것이 핵심입니다.

	v0x03 (ordinary)	v0x04 (bilateral)
Version byte	0x03	0x04
...	...	...

이진 레이아웃(binary layout)은 동일합니다. 동일한 239바이트이며, 동일한 NEP-413 공증 서명(notary signature)을 사용합니다. 파서(parser)는 버전 바이트(version byte)를 확인하여 두 형식을 모두 처리합니다. 기존의 9개 메인넷 PDR(v0x03)은 모두 유효하게 유지되며, 마이그레이션(migration)이나 포크(fork)가 필요하지 않습니다.

공증인(notary)은 버전을 자동으로 선택합니다: 요청에 agent_sig + agent_pubkey가 포함되어 있으면 → v0x04를 사용합니다. 포함되어 있지 않으면 → v0x03을 사용합니다. 명시적인 버전 파라미터는 없습니다.

에이전트가 먼저 서명합니다

어떠한 정보가 공증인에게 도달하기 전에, 에이전트는 자신의 작업 해시(work hash)에 서명합니다:

import hashlib, struct, base64
from nacl.signing import SigningKey

...

NEP-413은 원시(raw) 버퍼에 서명하며, SHA-256 사전 해싱(pre-hash)을 수행하지 않습니다. 서명은 Tag + Len + work_hash_bytes를 직접 포함합니다. 이는 NEAR가 트랜잭션 서명(transaction signing)에 사용하는 것과 동일한 표준입니다.

에이전트 서명으로 공증하기

curl -s https://api.aotrust.link/v1/notarize \
  -H "Content-Type: application/json" \
  -H "X-Payment: <base64-encoded EIP-3009 payload>" \
...

공증인 내부 동작:

1. agent_pubkey를 통해 sig_A를 검증 — 결제 전, 다른 모든 단계 이전에 수행됩니다.
2. Base에서의 EIP-3009 결제를 검증합니다 (~2초 소요).
3. binding_hash = sha256(work_hash + sig_A + agent_pubkey)를 계산합니다.
4. 239바이트 PDR을 생성합니다 — 버전은 0x04, payload_hash에 바인딩 해시(binding hash)를 포함합니다.
5. 공증인의 Ed25519 키로 175바이트 페이로드(payload)에 서명합니다.
6. base64 형식의 PDR을 반환합니다.

{
  "job_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "status": "notarized",
...

PDR은 BQ로 시작합니다. 이는 0x04 0x01(version=bilateral, scheme=Ed25519)의 base64 표현입니다. 일반적인 PDR은 Aw(0x03 0x01)로 시작합니다. 한눈에 어떤 버전인지 식별할 수 있습니다.

두 개의 독립적인 검증 경로

이것이 진정한 이점입니다. 공증이 완료되면, 각각 독립적으로 검증 가능하며 서로 다른 공개 키(public key)를 요구하는 **두 개의 분리된 암호학적 증명(cryptographic proofs)**을 갖게 됩니다.

경로 1: 공증인 서명 (PDR 자체)

curl -s "https://api.aotrust.link/v1/pdr/verify/BQFCAUJ...your_pdr_b64..."

{
  "valid": true,
  "version": 4,
...

또는 완전히 오프라인으로 수행할 수도 있습니다 — 파서(parser)는 단일 Python 파일이며, 의존성(dependencies)이 전혀 없습니다:

curl -sO https://raw.githubusercontent.com/GitSerge-crypto/aotrust-skills/main/pdr_parser.py

python3 pdr_parser.py --pdr "BQFCAUJ..." \
...

PDR v2.4 — Valid ✓
  version:           4 (bilateral)
  payload_hash:      b3c4d5e6... (binding hash)
...

이는 다음을 증명합니다: 공증인(notary)이 기록에 서명했고, 결제가 확인되었으며, 타임스탬프(timestamp)가 증명되었고, 해당 기록이 NEAR에 앵커링(anchored)되었습니다.

경로 2: 에이전트 서명 (원장(ledger)에 저장됨)

에이전트의 sig_A는 PDR 바이너리에 들어있지 않습니다 — 이는 공증인 원장(notary ledger)에 들어있습니다 (PDR은 원본 서명이 아닌 바인딩 해시(binding hash)를 포함합니다). 에이전트의 저작권을 확인하려면:

import struct, base64
from nacl.signing import VerifyKey

...

이는 다음을 증명합니다: 에이전트의 Ed25519 키가 이 특정 work_hash에 서명했다는 사실입니다. 에이전트는 저작권을 부인할 수 없습니다.

두 개의 서명. 두 개의 키. 두 개의 독립적인 증명. 어느 한 쪽 당사자만을 침해하여 위조할 수 있을까요? 아니요. 바인딩 해시(binding hash)가 이들을 하나로 묶습니다 — 공증인의 서명은 에이전트의 서명이 해시 내에 융합되어 포함된 페이로드(payload)를 커버합니다.

양방향 증명(bilateral)을 사용하는 경우

에이전트가 Ed25519 키를 가지고 있다면 — v0x04를 사용하세요. 비용은 동일하고($0.01), 크기도 동일하며(239 bytes), 부인 방지(non-repudiation) 기능을 무료로 얻을 수 있습니다.

에이전트가 키를 가지고 있지 않다면 (제3자가 타인의 작업을 공증하거나, 대량의 타임스탬프를 찍는 경우) — v0x03로 충분합니다. 이는 신원 바인딩(identity binding)이 없는 존재 증명(proof-of-existence)입니다.

흥미로운 사례는 **멀티 에이전트 파이프라인(multi-agent pipelines)**입니다. 에이전트 A가 출력을 생성하고, 에이전트 B가 이를 정제하며, 에이전트 C가 최종 보고서를 컴파일합니다. 각 단계는 해당 단계의 에이전트 키로 서명된 양방향 PDR로 공증될 수 있습니다. 이를 통해 모든 연결 고리가 기록 내에 바인딩된 고유의 Ed25519 서명을 가지며, 공증인이 각 연결 고리를 독립적으로 증명하는 관리 연속성(chain of custody)을 확보할 수 있습니다.

하위 호환성 (Backward compatibility)

파서는 두 버전을 모두 투명하게 처리합니다:

from pdr_parser import parse_external_pdr

parsed = parse_external_pdr(base64.b64decode(pdr_b64))
...

기존의 9개 메인넷 PDR은 v0x03입니다. 이들은 v0x03 상태를 유지합니다. 새로운 양방향 (Bilateral) PDR은 v0x04입니다. 마이그레이션(Migration)이나 재발행(Re-issuance)은 없습니다. 파서(Parser)가 분기되는 유일한 기준은 버전 바이트(Version byte)입니다.

명세 및 파서 (Spec and parser)

• PDR 명세 (v2.3 + v2.4): pdr-spec.md
• 독립형 파서 (Standalone parser): pdr_parser.py — MIT 라이선스, 의존성 없음 (zero dependencies), v0x02/v0x03/v0x04 처리 가능

실행해보기 (Try it)

# 상태 확인 (인증 없음)
curl -s https://api.aotrust.link/health

...

• API: api.aotrust.link
• 문서 (Docs): docs.aotrust.link
• MCP: api.aotrust.link/mcp
• 소스 (Source): github.com/GitSerge-crypto/aotrust-skills

서비스는 메인넷(Mainnet)에서 운영 중입니다. 양방향 PDR (v0x04)은 2026년 7월부터 지원됩니다 — 가격, 크기, 검증 흐름(Verification flow)은 동일합니다. 에이전트(Agent)는 자신이 작업을 수행했음을 증명하고, 공증인(Notary)은 그것이 공증되었음을 증명합니다. 둘 다 수학(Math)입니다.