ErgoScript 수락 술어: AI 에이전트 결제를 위한 온체인 작업 검증

인간은 모호함을 다룰 수 있습니다. 계약자가 나쁜 일을 하면, 인간은 불평하거나 분쟁하거나 재협상하거나 향후 결제를 거부할 수 있습니다. 자율 에이전트는 더 명확한 규칙이 필요합니다.

간단한 에이전트 파이프라인을 생각해봅시다:

1. 연구 에이전트가 데이터 에이전트에게 데이터셋 비용을 지불합니다.
2. 데이터 에이전트가 정리 에이전트에게 정규화된 레코드 비용을 지불합니다.
3. 정리 에이전트가 모델 에이전트에게 추론 비용을 지불합니다.
4. 연구 에이전트가 편집자 에이전트에게 최종 출력 비용을 지불합니다.

각 단계마다 성공의 정의가 다릅니다. "결제가 발생했습니다"는 충분하지 않습니다. 파이프라인은 수락 규칙이 필요합니다:

• 데이터셋이 예상된 공급자에 의해 서명되었는가?
• 정리된 데이터가 예상된 스키마와 일치했는가?
• 모델 출력 해시가 커밋된 결과와 일치했는가?
• 응답이 마감일 전에 전달되었는가?
• 검증자가 수락에 서명했는가?

프로그래밍 가능한 수락 없이, 모든 규칙은 애플리케이션 코드에서 오프체인에 있습니다. 이는 중앙화된 신뢰 지점을 만듭니다.

최소 수락 술어는 네 가지 부분을 가집니다:

1. 작업 커밋 — 어떤 출력이나 증명이 예상되는가?
2. 마감일 — Note를 언제까지 환불할 수 있는가?
3. 수신자 또는 검증자 인증 — 누가 환불하거나 수락할 수 있는가?
4. 환불 규칙 — 지출 트랜잭션에서 무엇이 참이어야 하는가?

간단한 술어는 다음과 같이 말할 수 있습니다:

val submittedOutput = getVar[Coll[Byte]](0).get
val outputHashOk = blake2b256(submittedOutput) == TASK_HASH
val beforeDeadline = HEIGHT < EXPIRY_HEIGHT
val receiverOk = proveDlog(RECEIVER_PK)

sigmaProp(outputHashOk && beforeDeadline) && receiverOk

이는 다음을 의미합니다: 수신자는 만료되기 전에 환불할 수 있으며, 트랜잭션에 Blake2b-256 해시가 커밋된 작업 해시와 일치하는 작업 출력이 포함되는 경우입니다.

실제 시스템에서 출력은 전체 작업 결과가 아닐 수 있습니다. 서명된 영수증, 증명, 검증자 명령문, Merkle 루트 또는 외부 저장 아티팩트의 다이제스트일 수 있습니다.

ErgoScript 술어가 blake2b256을 사용하면, 클라이언트 코드는 동일한 다이제스트를 계산해야 합니다. 클라이언트에서 SHA-256을 계산하고 계약에서 Blake2b를 계산하지 마십시오. 문서가 코드가 의사코드임을 명확히 말하지 않는 한.

JavaScript 도우미는 다음과 같이 보여야 합니다:

import { blake2b } from "@noble/hashes/blake2b";
import { bytesToHex, utf8ToBytes } from "@noble/hashes/utils";

export function taskHash(output: string): string {
  const digest = blake2b(utf8ToBytes(output), { dkLen: 32 });
  return bytesToHex(digest);
}

const expected = taskHash("the answer is 42");
console.log(expected);

정확한 바이트가 중요합니다. 해시하기 전에 문자열, 인코딩 및 줄 끝을 정규화합니다. 그렇지 않으면 두 에이전트가 동일한 인간이 읽을 수 있는 출력의 다이제스트에 대해 동의하지 않을 수 있습니다.

전통적인 에스크로는 다음과 같이 말합니다: 자금을 중간에 넣고 누군가가 작업이 완료되었다고 결정한 후 출시합니다.

수락 술어는 다음과 같이 말합니다: 지출 조건에 릴리스 규칙을 넣습니다. 규칙은 객관적일 수 있고, 부분적으로 객관적이거나 검증자 기반일 수 있습니다.

올바른 설계는 작업에 따라 다릅니다. 해시 술어는 커밋된 출력에 대해 작동합니다. 검증자 서명은 주관적인 품질에 대해 작동합니다. 영지식 자격 증명은 개인정보 보호 수락에 대해 작동할 수 있습니다. 술어는 신뢰 모델을 보이게 합니다.

수락 술어는 다음에 대해 잘 작동할 수 있습니다:

• 정확한 출력 해시;
• 서명된 검증자 영수증;
• 마감일 확인;
• 예산 한도;
• 수신자 인증;
• 토큰 또는 Note 속성;
• Reserve 참조;
• Tracker 업데이트;
• 단순 데이터 커밋먼트;
• 트랜잭션 컨텍스트를 통과하는 증명.

술어는 임의의 오프체인 현실을 마법처럼 검사할 수 없습니다. 품질 기준이 인코딩되거나 검증자가 영수증에 서명하지 않는 한 생성된 에세이가 "좋은"지 알 수 없습니다. API 응답이 유용했는지는 그 유용성이 확인 가능한 조건으로 축소되지 않는 한 알 수 없습니다.

이것은 결함이 아닙니다. 이것은 규율입니다: 수락을 정의할 수 없으면, 결제를 안전하게 자동화할 수 없습니다.

Note 스타일 결제는 레지스터에 작업 데이터를 인코딩할 수 있습니다:

환불 트랜잭션은 컨텍스트 변수를 제공할 수 있습니다:

레이아웃을 문서화해 두십시오. 아무도 디코딩할 수 없는 술어는 사용 가능한 프로토콜이 아닙니다.

일부 작업은 주관적인 수락이 필요합니다. 이 경우, 술어는 검증자 서명을 요구할 수 있습니다.

val receipt = getVar[Coll[Byte]](0).get
val receiptHashOk = blake2b256(receipt) == RECEIPT_HASH
val verifierOk = proveDlog(VERIFIER_PK)
val beforeDeadline = HEIGHT < EXPIRY_HEIGHT

sigmaProp(receiptHashOk && beforeDeadline) && verifierOk

이것은 검증자 신뢰를 제거하지 않습니다. 이것은 범위를 지정합니다. 검증자의 역할은 명시적이며, 영수증은 애플리케이션 정책에 의해 보관되고, 감사되거나 이의를 제기할 수 있습니다.

Accord는 작업 계약 및 검증 영수증을 설명합니다. ErgoScript 수락 술어는 결제 레일에서 해당 영수증을 적용하는 한 가지 방법입니다.

향후 흐름은 다음과 같이 보일 수 있습니다:

1. Accord 계약은 작업, 가격 및 검증자를 정의합니다.
2. Ergo Note는 결제 가치, 만료 및 술어를 인코딩합니다.
3. 작업자가 작업을 완료합니다.
4. 검증자가 검증 영수증을 발행합니다.
5. 술어가 영수증을 허용하면 작업자가 Note를 환불합니다.
6. 결제 영수증은 환불 트랜잭션을 기록합니다.

이것은 완전한 작업-결제 루프입니다: 계약, 검증, 결제.

재생 공격

작업자가 여러 결제에 동일한 영수증을 재사용합니다. 완화: 서명된/검증 가능한 영수증에 callId, 계약 ID 또는 Note ID를 포함합니다.

늦은 환불

작업자가 마감일 이후에 환불합니다. 완화: 술어에 HEIGHT < expiry를 포함합니다.

잘못된 작업 출력

작업자가 다른 작업에 대한 출력을 제출합니다. 완화: 커밋먼트에 작업 해시, 계약 ID 및 지불자/수신자 데이터를 포함합니다.

검증자 포획

검증자가 나쁜 일을 수락합니다. 완화: 평판, 다중 검증자 임계값, 지분, 감사 로그 또는 가능한 경우 객관적인 술어를 사용합니다.

인코딩 불일치

에이전트가 다른 바이트 표현을 해시합니다. 완화: 정규 인코딩 및 테스트 벡터를 게시합니다.

계약 버그

술어에 논리 오류가 있습니다. 완화: 테스트넷, 형식 검토, 외부 감사 및 서명된 매니페스트.

• 술어 소스 및 컴파일된 해시를 게시합니다.
• 정규 인코딩을 사용합니다.
• 테스트 벡터를 포함합니다.
• 술어를 좁게 유지합니다.
• 결제 영수증을 작업 영수증과 분리합니다.
• 만료를 추가합니다.
• 재생 보호를 추가합니다.
• 검증자가 명시적이지 않는 한 주관적인 술어를 피합니다.
• 감사되지 않은 예제를 실제 자금으로 배포하지 않습니다.

수락 술어란 무엇입니까?

수락 술어는 결제 수단이 환불되기 전에 충족되어야 하는 프로그래밍 가능한 조건입니다. Ergo 에이전트 결제 컨텍스트에서, 환불을 작업 출력, 검증자 영수증, 마감일 또는 ErgoScript에 인코딩된 다른 조건에 바인딩할 수 있습니다.

이것은 에스크로의 필요성을 제거합니까?

특히 수락 규칙이 객관적일 때 일부 에스크로 사용 사례를 제거할 수 있습니다. 작업이 주관적인 판단이 필요하면, 여전히 검증자나 분쟁 절차가 필요할 수 있습니다. 차이점은 검증자의 역할을 인코딩하고 감사할 수 있다는 것입니다.

Ethereum이 동일한 아이디어를 구현할 수 있습니까?

Ethereum은 조건부 결제 계약을 구현할 수 있지만, 설계는 일반적으로 애플리케이션 수준이며 에스크로 계약, 업그레이더빌리티 선택, 오라클 설계, 가스 역학 및 계정 모델 위험을 포함할 수 있습니다. Ergo의 eUTXO 모델은 결제 객체와 지출 규칙을 명시적으로 만듭니다.

수락 술어가 프로덕션 준비가 되어 있습니까?

기본 ErgoScript 기능은 실제이지만, 모든 특정 술어는 검토되어야 합니다. 데모 술어는 프로덕션 계약이 아닙니다. 테스트넷을 사용하고 테스트 벡터를 게시한 후 메인넷 사용 전에 감사를 기다립니다.

가장 단순하고 유용한 술어는 무엇입니까?

가장 단순하고 유용한 술어는 작업 해시와 마감일을 확인합니다: 제출된 출력이 커밋된 다이제스트로 해시되고 만료되기 전인 경우에만 환불합니다. 제한적이지만, 핵심 개념을 보여줍니다.

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "ErgoScript 수락 술어: AI 에이전트 결제를 위한 온체인 작업 검증",
  "description": "ErgoScript 수락 술어가 작업 완료 조건을 결제 UTxO 내에 인코딩하여 AI 에이전트가 더 적은 오프체인 신뢰 가정으로 작업을 검증하는 방법을 배웁니다.",
  "datePublished": "2026-03-12",
  "dateModified": "2026-05-08",
  "author": { "@type": "Organization", "name": "Ergo Developer Relations" },
  "publisher": { "@type": "Organization", "name": "Ergo Platform" },
  "mainEntityOfPage": "https://www.ergoblockchain.org/blog/ergoscript-acceptance-predicates",
  "keywords": ["ErgoScript", "acceptance predicates", "AI agent payments", "eUTXO", "work verification"]
}

• 원본 문서: https://www.ergoblockchain.org/blog/ergoscript-acceptance-predicates
• Accord Protocol 저장소: https://github.com/accord-protocol/accord-protocol
• Ergo 기술 페이지: https://www.ergoblockchain.org/technology