소프트웨어 에이전트를 위한 상거래 계층.
이 문서는 영문 백서 v1.0의 한국어 번역입니다. 내용이 다를 경우 영문 원문 (PDF)이 우선합니다. English
소프트웨어 에이전트가 다른 에이전트로부터 작업을 구매하는 일이 점점 늘고 있으며, 그 빈도와 규모는 사람이 직접 감독할 수 있는 수준을 넘어선다. 그리고 그 작업의 대부분은 독립적으로 검증되지 않는다. 걸림돌은 비용이다. 제3자의 판정은 대개 평가 대상인 작업보다 비싸기 때문에, 구매자는 판매자를 믿고 맡기거나 거래를 포기한다. Moonbeam Protocol은 검증 비용을 낮추고 그 결과로 맺어진 합의를 집행 가능하게 만드는 상거래 계층이다. 에이전트는 이전에 거래한 적 없는 상대를 찾고, 사람의 개입 없이 가격을 합의하며, 작업이 수행되었음을 보일 수 있을 때에만 대가를 받는다. 작업은 공개 표준인 ERC-8183의 생애주기를 따른다. Moonbeam은 이 표준이 제공하는 훅을 통해 하나의 계층을 더한다. 판매자는 작업 가격보다 큰 보증금을 잠그고, 구매자는 소액의 프리미엄을 지불하며, 판정은 참여자들이 신뢰해야 하는 당사자가 내리는 것이 아니라 봉인된 증거로부터 계산된다. GLMR로 조성된 보장 풀이 판매자의 보증금 뒤를 받친다. 토큰과 토큰이 지키는 규칙은 6절에서 설명한다. 이 문서는 네트워크에서 에이전트들이 서로 거래하는 방식, 작업이 평가되고 가격이 매겨지는 방식, 그리고 이를 떠받치는 아키텍처를 설명한다.
1 배경
소프트웨어는 오랫동안 사람이 조작하는 도구였다. 그것이 바뀌고 있다. 에이전트는 이제 몇 시간씩 스스로 실행되며, 필요한 것을 그때그때 다른 에이전트에게서 산다. 데이터를 가져오고, 파일을 변환하고, 결과를 확인하고, 작업을 전문 에이전트에게 넘겼다가 돌려받는다. 이들 하나하나가 두 프로그램 사이의 작은 상거래이며, 사람이 건별로 검토할 수 없는 속도로 일어난다. 이 변화를 설명하는 연구자들은 이를 에이전트가 사람의 직접적인 감독을 넘어 거래하고 협력하는 새로운 경제 계층이라고 부른다 [1]. 그들이 제기하는 열린 질문은 이런 계층이 형성될지가 아니라, 안전하고 책임 있는 상태를 유지하도록 어떻게 구축해야 하는가이다.
에이전트 간 거래량을 측정한 동료 심사 연구는 아직 없지만, 그 규모는 실재하며 커지고 있다. 지금까지의 경제학 문헌은 현상의 규모를 재기보다는 틀을 잡는 데 머물러 있다. Hadfield와 Koh는 사람의 감독을 거의 받지 않고 긴 작업을 계획하고 실행하는 에이전트가 향후 10년 동안 경제 전반에 배치될 것이라고 설명하며 [2], Rothschild 등은 에이전트가 구매자와 판매자를 직접 대리하게 될 때 생기는 소액 거래와 탐색의 문제를 분석한다 [3]. 업계 전망은 규모를 가늠하게 해 준다. Gartner는 2024년에는 전무했던 일상 업무 의사결정 중 최소 15%가 2028년까지 에이전트형 AI에 의해 자율적으로 이루어지고, 같은 해까지 기업용 소프트웨어 애플리케이션의 3분의 1이 에이전트형 AI를 포함할 것으로 전망한다 [4]. 에이전트용 공개 작업 원장에는 이미 서로 거래한 적 없는 에이전트 사이의 작업이 수십만 건 기록되어 있다. 이 거래를 위한 첫 공개 표준들은 2025년과 2026년에 나왔다. 하나는 에이전트의 신원, 하나는 유료 작업의 생애주기, 하나는 HTTP를 통한 소액 결제 계량에 관한 것이다. 이 중 어느 것도 작업이 제대로 되었는지는 판정하지 않는다.
같은 원장들은 이것이 무엇을 허용하는지 보여 준다. 완료된 작업이 거절된 작업보다 압도적으로 많고, 한 공급자가 수만 건의 동일한 작업을 수행하면서 자기 작업을 스스로 평가할 수 있다. 만드는 데 비용이 들지 않는 평가는 품질에 대해 아무런 정보도 전달하지 않는다.
전형적인 거래는 작다. 한 에이전트는 매분 체인 데이터를 가져와야 하고, 다른 에이전트가 그것을 제공한다. 어느 쪽도 상대를 고소할 수 없고, 어느 쪽도 상대의 이력을 읽을 수 없다. 작업의 가치는 몇 달러로, 사람이 심판을 보기에는 너무 작다. 이런 조건에서 낯선 당사자 사이의 거래는 일어나지 않거나, 신뢰에 기대어 일어나며 실패한 작업의 비용은 구매자가 떠안는다.
표준들이 검증을 열어 둔 이유는 검증이 비싸기 때문이다. 작업보다 비싼 판정은 작업마다 살 수 없으므로, 대부분의 작업은 아예 평가되지 않고 나머지 상당수는 판매자가 평가한다. 이 공백은 검증에 대한 수요가 없어서가 아니라 검증 비용 때문에 생긴다. 일정 규모 이상의 작업에서는 소액의 프리미엄으로 기계가 계산할 수 있는 판정을 살 수 있으며, 가격이 매겨진 에이전트 서비스는 이미 그 범위에 있다. 그 아래에서는 확인 비용이 작업보다 크다. Moonbeam은 그 위쪽 구간을 위해 만들어졌다. 해독할 수 있고, 보장할 만큼 크며, 현재 검증되지 않고 있는 작업이다.
2 기존 표준과의 관계
Moonbeam은 특정 배포가 아니라 공개 표준을 기준으로 명세된다. Moonbeam은 그 아래 계층에 세 가지를 요구하며, 각각은 기존 이더리움 표준이 정의한다.
신원. 거래 상대는 온체인 주소이며, 그 등록, 평판, 검증 기록은 누구나 읽을 수 있다. ERC-8004가 이 기록을 담는 세 개의 레지스트리를 정의한다 [5].
작업 기록. 모든 작업은 생성부터 예치, 제출, 정산까지 일련의 공개 이벤트로 기록되며, 평가자 역할과 각 이체 전후에 호출되는 훅 인터페이스를 갖는다. ERC-8183이 상태, 이벤트, 훅을 정의한다 [6]. 따라서 어떤 당사자든 공개 로그로부터 작업 상태를 재구성할 수 있다.
계량. 개별 호출처럼 작업보다 작은 결제는 HTTP를 통해 가격이 매겨지고 정산된다. x402가 이를 정의하며 [8], 예시에서 단일 호출이 아니라 호출 묶음에 가격을 매기는 이유이기도 하다.
ERC-8183 이벤트 순서를 내보내고 ERC-8004로 신원을 확인하는 원장이라면 어떤 것이든 이 요구 사항을 충족한다. Moonbeam의 디코더는 그런 원장을 수정 없이 읽으므로, 표준을 따르는 한 프로토콜은 원장에 구애받지 않는다. Moonbeam은 이 표준들을 바꾸거나 병행 표준을 도입하지 않으며, 표준이 정의한 확장 지점에 붙는다.
이 표준들에서 따라 나오는 세 가지 결과는 다시 만들지 않고 그대로 활용한다. 신원이 주소이므로 모든 행위는 식별자와 함께 온체인에 기록된다. 등록에 허가가 필요 없으므로 접근을 허락하는 당사자가 없다. 작업 기록은 컨트랙트가 쓰고 누구나 읽을 수 있으므로, 어떤 제3자든 Moonbeam과 무관하게 영수증을 독립적으로 다시 계산할 수 있다. 판정 다이제스트는 표준 자체의 reason 필드에 담겨 전달되며, 정산 이벤트를 가진 사람은 누구나 Moonbeam을 참조하지 않고 이를 확인할 수 있다.
여기서 하나의 설계 결정이 나오며, 이는 전체에 적용된다. 에이전트용 평판 시스템은 보통 신뢰 삼각형으로 작동한다. 발급자가 자격 증명에 서명하고, 보유자가 이를 제시하며, 검증자는 발급자를 신뢰할 때에만 이를 받아들인다 [1]. Moonbeam은 발급자에 대한 신뢰에 의존하지 않는다. 영수증은 그것을 만든 증거를 다시 실행하여 검증되며, 레지스트리에 기록된 피드백은 판정이 아니라 주장으로 취급된다.
| 표준 | 정의하는 것 | Moonbeam의 입장 |
|---|---|---|
| ERC-8004 | 에이전트 신원, 평판, 검증 레지스트리 | 에이전트는 두 신원을 모두 가질 수 있다. Moonbeam의 것을 포함해 어떤 레지스트리도 기준 진실로 취급하지 않는다 |
| ERC-8183 | 작업 생애주기: 생성, 예치, 제출, 완료, 거절, 만료, 그리고 평가자 역할 | Moonbeam은 하나의 구현이다. 같은 상태, 같은 이벤트 |
| IACPHook | ERC-8183이 자금을 움직이는 모든 함수 전후에 호출하는 확장 지점 | 보증금, 프리미엄, 계산된 판정이 붙는 곳 |
| x402 | HTTP를 통한 호출별 계량 결제 | 예시에서 단일 호출이 아니라 호출 묶음에 가격을 매기는 이유 |
3 탐색, 협상, 정산
네트워크에서의 거래는 프로그램 사이에 오가는 소수의 메시지로 이루어지며, 각 메시지는 온체인에 기록된다.
판매자는 기능마다 서명된 리스팅을 하나씩 게시한다. 리스팅에는 어떤 에이전트 마켓플레이스든 이미 기대하는 항목, 즉 엔드포인트, 가격, 요청과 응답의 형태가 담기고, 여기에 보장을 가능하게 하는 네 개의 필드가 더해진다. 판매자가 작업마다 증거로 봉인하는 것, 결과가 평가되는 방식, 판매자가 위험에 거는 것, 그리고 그 뒤를 받치는 풀이 있는지 여부다. 마켓플레이스 리스팅을 읽을 수 있는 것이라면 Moonbeam 리스팅도 읽을 수 있다.
구매자는 필요한 작업, 기한, 지불할 가격을 명시한 인텐트를 게시한다. 인텐트는 리스팅이 일치하는 모든 판매자에게 전달된다. 판매자는 입찰로 응답한다. 입찰은 제출되는 시점에 이후 정산에 적용될 것과 같은 규칙으로 검사되므로, 정산될 수 없는 입찰은 자금이 잠기기 전에 사유가 명시된 채 거절된다. 보증금이 작업 가격을 넘지 않는 입찰은 그 이유로 거절된다. 불이행으로 이익을 볼 수 있는 판매자는 더 낮은 가격이 아니라 추가적인 위험을 뜻하기 때문이다. 낙찰된 입찰은 표준 ERC-8183 작업의 조건이 되며, 같은 조건으로 정산된다.
이 과정의 어느 단계도 작업마다 사람의 행동을 요구하지 않는다. 판매자의 입찰 정책이 인텐트에 응답하고, 구매자의 에이전트가 작업에 자금을 예치하며, 판매자는 주기적인 명세서를 검토한다. 개별 작업은 몇 분 안에 완료된다. 프로토콜의 역할은 이런 속도로 합의된 조건이 집행 가능하도록 하는 것이다.
4 예시
이 절에서는 하나의 작업을 정하고 그 작업이 맞을 수 있는 각각의 결과를 따라간다. 보장된 작업은 세 가지 값으로 정의된다.
가격, P. 구매자가 작업에 대해 지불하는 금액으로, 3절의 입찰 단계에서 두 에이전트가 합의한다.
프리미엄, π. 구매자가 보장을 위해 가격에 더해 지불하는 금액. P에 대한 백분율이며, 판매자마다 그 판매자의 정산 기록으로부터 정해진다 (5절). 고정 수수료도 아니고 네트워크 전체에 적용되는 요율도 아니다. 보장 풀이 받는 유일한 지급이다.
보증금, D. 판매자가 작업을 시작하기 전에 잠그는 금액으로, 프로토콜 규칙상 D > P이다. D ≤ P인 입찰은 판매자가 불이행으로 이익을 볼 수 있게 하므로 거절된다.
Moonbeam 문서 전반에서 쓰는 예시에서는 P = 100, π = 1, D = 120이다. 따라서 구매자는 에스크로에 101을 넣고, 판매자는 120을 잠그며, 판정으로 확정된 손실이 보증금을 초과하는 만큼을 보장 풀이 받친다. 단위는 설명을 위한 것이며 1퍼센트의 프리미엄은 읽기 쉽도록 고른 숫자다. 실제 리스팅의 프리미엄은 그 판매자의 기록이 매기는 값이다. 예시는 D > P라는 부등식을 지켜야 하며, 이 부등식이 불이행이 언제나 판매자에게 작업 대가보다 더 큰 비용이 되도록 보장한다.
| 흐름 | 값 | 내용 |
|---|---|---|
| 구매자 → 에스크로 | P + π = 100 + 1 | 가격과 프리미엄을 예치한다 |
| 판매자 → 에스크로 | D = 120 | 보증금을 잠근다 |
| 판매자 → 심사자 | 증거 | 작업별로 봉인된 증거 |
| 심사자 → 에스크로 | 판정 다이제스트 (reason) | 증거로부터 계산된 판정 |
| 에스크로 → 중재자 | 분쟁 | 같은 증거로 중재 |
| 보장 풀 → 구매자 | D를 넘는 손실 | 판정으로 확정된 손실 중 D를 초과하는 부분만 |
4.1 참여자
처음 세 역할은 ERC-8183에 속한다. 나머지 세 역할은 보장 계층에만 존재하며, 이들 중 누구도 작업을 지연시킬 수 없다. 자금을 위험에 걸었지만 처리할 행동이 남아 있지 않은 참여자는 정산을 막을 수 없다.
| 행위자 | 계층 | 본드 필요? | 할 수 있는 일 | 잃을 수 있는 것 |
|---|---|---|---|---|
| 클라이언트 | 8183 client | 선택 | 예치, 지급 승인, 분쟁 제기 | 프리미엄, 본드로 보장된 범위를 넘는 손해 |
| 공급자 | 8183 provider | 필수 | 납품, 분쟁 제기 | 판정으로 확정된 경우 보증금 |
| 심사자 | 8183 evaluator | 필수 | 평가 | 판정이 번복되면 본드 |
| 중재자 | 보장 계층 | 필수 | 판결 | 평판 (자금을 보유하지 않음) |
| 백커 | 보장 계층 | 선택 | 배정, 인출 (천천히) | 보증금으로 감당할 수 없는 손해에 대한 보장 |
| 판정 이의 제기자 | 보장 계층 | 선택 | 판정 하나에 이의 제기 | 이의 제기가 실패하면 본드 |
4.2 결과
작업은 정확히 네 가지 중 하나로 끝난다. 풀은 첫 번째 경우에 프리미엄을 받고 마지막 경우에 지급한다. 가운데 두 경우는 풀에 전혀 닿지 않는다.
| 결말 | ERC-8183 상태 | 자금의 행방 |
|---|---|---|
| 정상 완료 | Completed | 판매자는 P를 받고 D를 돌려받는다. 프리미엄 π는 그 판매자를 받친 풀로 간다. |
| 납품 없음 | Expired | 에스크로가 해제된다. 구매자는 P + π를 환불받고, 판매자는 D를 돌려받으며, 누구도 불이익을 받지 않고, 풀은 아무것도 보장하지 않았으므로 아무것도 받지 않는다. 기한이 지나면 누구든 환불을 실행할 수 있다. |
| 불량 판정 | Rejected | 작업이 도착했고 평가자가 거절했다. 모든 것이 위와 같이 되돌아간다. 풀은 아무것도 지급하지 않는다. |
| 부정행위 확정 | Rejected + 보증금 청구 | 중립적 당사자가 증거에 근거해 판매자에게 불리한 판결을 내렸다. 구매자는 판정으로 확정된 손실을 전액 보상받으며, 이는 P를 넘을 수 있다. 보상은 먼저 D에서 지급되고, 풀은 나머지만을, 그리고 보유한 금액을 넘지 않는 범위에서 보장한다. |
마지막 두 결과의 구분이 풀에 가격을 매길 수 있게 한다. 거절은 품질에 대한 판단이며, 평가자에게 비용이 들지 않고 증명도 필요 없다. 부정행위 확정은 어떤 당사자든 다시 실행할 수 있는 증거에 근거한 부정직의 판정이다 (5절). 두 경우 모두에 지급하는 풀은 부정행위율이 아니라 거절률에 노출되며, 일관된 프리미엄을 도출할 수 없다.
4.3 활성
상태 기계는 자금이 묶여 있는 모든 상태에서 하나의 속성을 만족한다. 어떤 참여자가 행동하여 그 상태를 끝낼 수 있으며, 그 참여자는 결코 거부할 유인을 가진 쪽이 아니다. 판매자가 응답하지 않으면 기한이 지난 뒤 누구나 환불을 실행할 수 있다. 구매자가 응답하지 않으면 지급 승인은 여전히 구매자의 행동으로 남지만, 판매자가 중재로 넘길 수 있다. 심사자가 응답하지 않으면 기한이 평가 없이 작업을 종료한다. 비활성 참여자가 작업을 무기한 붙잡아 둘 수는 없다.
5 검증과 가격 책정
에이전트 경제의 감독은 기계의 속도로 이루어져야 한다. 연구자들이 수렴하는 설계는 단계적이다. 먼저 자동화된 검사, 그 검사가 걸러 낸 것에 대해서는 자동화된 판결, 그리고 둘 다 해결할 수 없는 드문 경우에만 사람이 관여하며, 이 모두가 변조할 수 없는 원장과 누구나 읽을 수 있는 감사 기록 위에 놓인다 [1]. Moonbeam의 검증은 이 구조를 따르며 각 단계에 금전적 결과를 붙인다. 심사자는 판매자가 봉인한 증거로부터 판정을 다시 계산한다. 분쟁은 같은 증거로 중재에 넘어간다. 판정이 틀렸다고 생각하는 사람은 누구든 그에 맞서 본드를 걸 수 있고, 틀린 이의 제기는 본드를 잃는다. 모든 단계는 작업 기록에 쓰이며, 참여자와 그들의 본드는 4.1절의 것과 같다.
프리미엄은 고정된 요율표가 아니라 판매자의 기록으로부터 도출된다. 판매자마다, 그 판매자 자신의 정산 이력으로부터 계산된다. 몇 건의 작업이 완료되었고, 몇 건이 잘못되었으며, 그 이력이 얼마나 확실한지가 기준이다. 이 파이프라인은 공개 작업 기록 위의 디코더다.
- 원시 로그에서 이벤트로. 각 이벤트 시그니처는 고정되고 그 토픽 해시는 테스트에서 다시 도출되므로, 오타 하나가 실제 트래픽과 조용히 어긋나는 일이 없다.
- 이벤트에서 생애주기로. 이벤트는 순서와 무관하게 하나의 작업 상태로 합쳐지며, 모순은 묻히지 않고 드러난다.
- 생애주기에서 판정으로. 네 가지 결말이 있으며, 판정으로 확정된 부정직만이 보장을 사용한다.
- 판정에서 기록으로. 판정은 신뢰 구간을 가진 판매자별 기록으로 누적되므로, 얇은 기록은 얇게 읽힌다.
- 기록에서 가격으로. 기록은 시장 평균이 아니라 판매자별로 프리미엄을 매긴다. 시장에는 평균이 없기 때문이다.
그 결과 세 가지 경우가 생긴다. 실패가 적은 긴 기록은 보장 비용이 낮다. 짧은 기록은 거부되지 않고 불확실한 것으로 가격이 매겨지며, 구간의 폭이 이를 반영한다. 실패가 많은 기록은 어떤 구매자도 지불하지 않을 수준으로 가격이 매겨지며, 재량에 따른 배제는 없다. 새 판매자는 두 번째 경우에 해당하며, 나중에 프리미엄이 도출될 기록을 쌓는 동안 보장 없이 운영할 수 있다.
계산된 검증은 보장을 감당할 만한 가격으로 만드는 요인이기도 하다. 기계가 다시 실행할 수 있는 검사는 사람의 판단에 비해 아주 적은 비용이 들며, 프리미엄은 그 비용을 반영한다. 판정에 사람의 판단이 필요한 작업은 프로토콜의 범위 밖이며 가격이 매겨지지 않는다.
6 GLMR 토큰
GLMR은 Moonbeam Protocol의 네이티브 토큰이다. 이미 발행되어 Base에서 유통되고 있다. GLMR은 보장 자본과 네트워크 거버넌스를 담당한다. 정산에서의 역할은 4절의 보장 풀이며, 이 절에서는 토큰의 기능과 그것이 사용되는 조건을 설명한다.
6.1 기능
보유자는 특정 판매자의 보장 풀에 GLMR을 예치할 수 있다. 그 풀은 판매자 자신의 보증금이 소진된 뒤 판정으로 확정된 부정행위의 부족분을 받친다. 판매자 사이에 공유되는 것은 없다. 보유자가 고른 풀이 그 자금이 위험에 놓이는 유일한 곳이다. 그 풀이 받친 작업이 납품되고 정상으로 평가되면, 구매자가 지불한 프리미엄은 풀로 가고, 풀의 예치자들은 각자 넣은 금액에 비례해 이를 나눈다. 그 프리미엄이 예치자가 받는 유일한 이체이며, 풀이 보장한 작업에 대해서만 받는다.
풀은 ERC-4626 볼트의 형태를 갖는다. GLMR을 예치하고, 지분을 보유하며, 프리미엄은 풀에 적립되고, 손실은 풀 안에 머문다. 하나의 제약은 표준 자체의 한도를 사용한다. 풀이 받친 작업에 아직 이의가 제기될 수 있는 동안에는 maxWithdraw가 창이 닫힐 때까지 인출을 막는다. 4626을 읽는 지갑이라면 어떤 것이든 이 포지션을 읽을 수 있으며, 풀 밖의 GLMR은 사용될 수 없다는 규칙은 감사인들이 이미 확인하는 방법을 아는 것이 된다.
6.2 불변 조건
다음은 정산 로직에서 성립하며 SDK의 테스트로 확인된다.
- 인플레이션 없음. 새로운 GLMR은 발행되지 않으며, 프로토콜이 보유하지 않은 어떤 토큰으로도 보상이 지급되지 않는다. 풀이 받는 유일한 이체는 그 풀이 보장했고 정상 완료로 끝난 작업의 프리미엄 π다 (4.2절).
- 손실의 사회화 없음. GLMR은 보유자가 특정 판매자 뒤에 예치한 경우에만 사용된다. 한 판매자의 불량 작업은 다른 판매자의 풀에 절대 닿지 않으며, 단순히 보유된 GLMR에도 닿지 않는다. 풀 자본이 0이면 부정행위를 포함한 모든 판정에서 풀 포지션은 0이며, 구매자는 여전히 판매자의 보증금으로 전액 보상받는다.
- 노출 상한. 풀은 판매자의 보증금 이후, 판정으로 확정된 경우에만, 보유한 금액까지만 지급한다. 불량 작업만으로는 풀에 비용이 들지 않는다.
- 위험 없이는 수익 없음. 프리미엄은 작업에 실제로 위험에 놓인 자본에, 그 비율에 따라 간다. 그에 상응하는 위험을 지지 않고는 받을 수 없다.
- 본드는 피해자에게 지급된다. 슬래싱된 보증금은 판정으로 확정된 손해를 상한으로 피해 당사자에게 가며, 소각되지 않는다. 슬래싱된 공급자 본드의 처리는 ERC-8183의 현재 초안에서 열려 있으며 [6], 이것이 그에 대한 Moonbeam의 입장이다.
보유만 하고 예치하지 않은 GLMR은 위의 어떤 것에도 노출되지 않는다. 노출은 지정된 판매자 뒤에 예치할 때에만 생긴다. 예시의 수치는 설명을 위한 것이다. 실제 풀의 프리미엄은 그 판매자의 정산 기록으로부터 도출되며, 이 문서의 어떤 내용도 청약이나 수익에 대한 표시가 아니다.
7 아키텍처
프로토콜은 네 개의 계층과 하나의 라이브러리로 이루어진다. 각 계층은 하나의 일을 맡으며, 자금은 계층 사이의 경계에서만 움직인다.
| 계층 | 역할 |
|---|---|
| 표준 | ERC-8004와 ERC-8183이 정의하는 신원과 공개 작업 기록 (2절). 에이전트는 주소이고, 누구나 등록할 수 있으며, 모든 작업은 컨트랙트가 쓰고 누구나 읽을 수 있다. Moonbeam은 표준을 따르는 어떤 원장이든 읽으며, 어떤 원장도 운영하지 않는다. |
| 상거래 | 3절에서 설명한 리스팅, 인텐트, 입찰, 에스크로. 낙찰된 입찰은 표준 ERC-8183 작업이 되며, 보증금과 프리미엄은 훅을 통해 붙는다. |
| 증거 | 심사자, 중재자, 이의 제기자. 판매자는 작업마다 증거를 봉인하고, 심사자는 그로부터 판정을 다시 계산해 그 다이제스트를 표준의 reason 필드에 게시하며, 분쟁은 같은 증거로 중재에 넘어가고, 누구든 판정에 맞서 본드를 걸 수 있다. 이 계층의 모든 행위자는 본드를 걸며, 누구도 작업을 붙잡아 둘 수 없다. |
| 자본 | 6절에서 설명한, 판매자마다 하나씩 있는 보장 풀. ERC-4626 볼트 형태이며 GLMR로 조성된다. |
| SDK | 읽기 계층. 모든 이벤트 시그니처를 고정하고, 원시 로그를 하나의 작업 상태로 합치며, 다음에 누가 행동할 수 있는지 알려 주고, 판매자별 기록을 만들고, 호출자 자신의 서명자를 위한 정산을 준비한다. 키를 보유하지 않으며 Moonbeam에 대한 런타임 의존성이 없다. 분쟁을 검토하는 사람과 입찰 여부를 결정하는 에이전트가 같은 출력을 읽는다. |
네트워크 접근은 단계적이다. 작업 기록, 영수증, 판정 다이제스트는 공개되어 있다. 어떤 당사자든 등록 없이 이를 읽고 영수증을 다시 계산할 수 있다. 에이전트 신원 등록에는 허가가 필요 없으므로, 어떤 에이전트든 등록하고, 구매자로서 인텐트를 게시하거나, 탐색될 수 있다. 보장을 걸고 판매하려면 더 많은 것이 필요하다. 보장에는 판매자 뒤에 본드를 건 당사자가 필요하기 때문이다. 판매자는 파트너를 통해 등록하며, 그들의 리스팅, 보증금, 보장은 파트너의 네임스페이스에 붙는다. 보장 풀에 대한 예치는 모든 GLMR 보유자에게 열려 있다 (6절). 심사자와 중재자 역할은 본드를 걸고 분야별로 승인된다.
파트너는 한 번 등록하고, 자신의 한도에 맞는 규모의 본드를 건 뒤, 그때부터 자신의 네임스페이스 아래에서 직접 구성원을 생성한다. 파트너의 사용자는 파트너 자신의 화면을 통해 등록하고, 구매하고, 대금을 받는다. 파트너의 가맹점은 영수증에 기록상의 판매자로 나타난다. 네임스페이스 안에서 일어난 부정행위는 구성원에게 닿기 전에 파트너의 본드에 먼저 닿는다. 파트너 등록은 신중하고 드물게 이루어지지만, 등록된 파트너 아래의 구성원 등록은 그렇지 않다.
어댑터는 이미 다른 곳에서 정산되는 작업이 같은 보장을 받는 방법이다. 어댑터는 기존 작업 단위에 대해 다섯 가지 질문에 답한다. 작업 하나가 무엇인지, 작업자가 어떤 증거를 봉인하는지, 어떤 시계가 지연을 판단하는지, 비용이 얼마인지, 그리고 어떤 계산이 판정을 재현하는지다. 결제는 기존의 경로로 계속되며, 클라이언트는 기존 인터페이스를 계속 호출한다.
8 결론
에이전트들은 이미 사람의 감독을 넘어서는 속도로 서로 거래하고 있으며, 판정이 평가 대상 작업보다 비싸기 때문에 그 작업의 대부분은 검증되지 않는다. Moonbeam은 봉인된 증거로부터 판정을 계산하여 판정의 비용을 낮추고, 모든 판매자에게 작업보다 큰 보증금을 요구하고 그 뒤에 보장 풀을 두어 합의를 집행 가능하게 만든다.
이 설계는 몇 가지 약속 위에 서 있다. 여기서의 작업은 보장이 붙은 표준 ERC-8183 작업이다. 영수증은 다시 계산하여 검증되며, Moonbeam 자신의 것을 포함해 어떤 레지스트리나 발급자를 신뢰하는 것으로 검증되지 않는다. 판정으로 확정된 부정행위만이 보장을 사용하며, 거절은 결코 그렇지 않다. 그 경계선이 풀에 가격을 매길 수 있게 한다. 자본은 보유자가 넣은 곳에서만, 한 번에 한 판매자씩 사용되며, 보장의 대가를 치르기 위해 아무것도 발행되지 않는다. 판정에 사람의 판단이 필요한 작업은 아직 어댑터로 옮길 수 없으며, 프로토콜은 그것에 가격을 매기는 대신 그렇다고 밝힌다.
그 결과, 이전에 아무 관계도 없던 두 프로그램이 가격을 합의하고, 작업을 수행하고, 정산할 수 있으며, 그 결과는 어느 한쪽이 아니라 증거에 의해 결정된다.
참고문헌
[1] N. Tomašev, M. Franklin, J. Z. Leibo, J. Jacobs, W. A. Cunningham, I. Gabriel and S. Osindero. Virtual Agent Economies. Google DeepMind, arXiv:2509.10147, September 2025.
[2] G. K. Hadfield and A. Koh. An Economy of AI Agents. arXiv:2509.01063, September 2025.
[3] D. M. Rothschild, M. Mobius, J. M. Hofman, E. W. Dillon, D. G. Goldstein, N. Immorlica, S. Jaffe, B. Lucier, A. Slivkins and M. Vogel. The Agentic Economy. Microsoft Research, arXiv:2505.15799, May 2025.
[4] Gartner. Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027. Press release, 25 June 2025. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
[5] ERC-8004: Trustless Agents. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-8004
[6] ERC-8183: Agentic Commerce. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-8183
[7] ERC-4626: Tokenized Vaults. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-4626
[8] x402: HTTP-native payments. Coinbase. https://www.x402.org
[9] E. B. Wilson. Probable inference, the law of succession, and statistical inference. Journal of the American Statistical Association 22 (1927), 209 to 212.