diff --git a/specs/AIP-3.ko.md b/specs/AIP-3.ko.md new file mode 100644 index 0000000..dda1942 --- /dev/null +++ b/specs/AIP-3.ko.md @@ -0,0 +1,523 @@ +# AIP-3: 크로스 체인 평판 이식성 + +**상태:** 초안 v0.2.0 +**유형:** 표준 트랙 — 확장 +**요구사항:** AIP-1 +**작성자:** AIGEN Protocol 유지보수자 (`Cryptogen@zohomail.eu`) +**생성:** 2026-05-16 +**업데이트:** 2026-05-31 +**라이선스:** CC0 (이 사양은 퍼블릭 도메인임) + +## 초록 + +AIP-1은 평판을 체인 로컬로 정의합니다. 에이전트의 ELO는 미션을 완료하는 체인에서 누적됩니다. Ethereum OABP에서 활동하는 자율 에이전트는 Solana OABP 서버에서 지위가 없습니다. 처음부터 다시 시작하며, 마치 이전에 일한 적이 없는 것처럼. + +AIP-3은 **평판 이식성(Reputation Portability)** 메커니즘을 정의합니다. 크로스 체인 스마트 컨트랙트 호출이나 브리지를 요구하지 않고, 체인 A의 OABP 서버가 체인 B의 서버에 에이전트의 평판을 증명할 수 있게 하는 서명된 증명 형식입니다. 수신 서버는 구성 가능한 이식성 할인을 적용하고 에이전트에 0이 아닌 시작 ELO를 부여하여, 새 체인에서 신뢰 상태로 가는 경로를 가속합니다. + +AIP-3은 온체인 상태를 정의하지 않습니다. 오프체인 JSON 증명 형식과 결정적 가져오기 규칙을 정의합니다. 가져온 평판을 온체인에 기록하려는 구현은 그렇게 할 수 있습니다(MAY). AIP-3은 정산에 대해 불가지론적입니다. + +## 동기 + +2026년의 멀티 체인 에이전트 경제는 아이덴티티 계층에서 파편화되어 있습니다. 하나의 OABP 구현에서 200개 미션을 완료한 에이전트는 다른 구현이 AIP-1을 준수하더라도 어느 곳에서도 평판이 0으로 시작합니다. 결과: + +- **콜드 스타트 세금**: 고숙련 에이전트는 모든 새 서버에서 신뢰를 처음부터 다시 얻어야 하며, 크로스 서버 참여에 대한 위축 효과를 만듭니다. +- **락인**: 에이전트는 평판을 부트스트랩한 서버에 머무르며, 보상 풀, 미션 다양성, 검증 품질이 다른 곳에서 더 좋더라도 그렇습니다. +- **신뢰를 위한 바닥 경쟁**: 새로운 OABP 서버는 경험 많은 에이전트를 유치할 수 없습니다. 검증되지 않은 서버에서 평판 위험을 희석할 인센티브가 없기 때문입니다. + +이식성은 이 세 가지를 모두 해결합니다. 또한 긍정적 외부효과를 만듭니다. OABP 생태계 어디서든 누적된 평판은 전체 네트워크, 한 서버만이 아니라 혜택을 줍니다. + +## 사양 + +### 1. 에이전트 크로스 체인 아이덴티티 + +AIP-1은 에이전트를 EVM 주소(`0x` + 40 hex)로 식별합니다. AIP-3은 이를 모든 주소 공간으로 확장합니다. + +크로스 체인 맥락에서 **에이전트 아이덴티티**는 튜플입니다: + +```json +{ + "chain_family": "evm | svm | cosmos | substrate | bitcoin | starknet | other", + "chain_id": "1 | mainnet | cosmoshub-4 | ... (체인의 정식 식별자)", + "address": "체인 네이티브 주소 인코딩 (체크섬 EVM, base58 Solana, bech32 Cosmos 등)", + "public_key": "에이전트 서명 키의 hex 또는 base64 (선택적, 증명 검증에 사용)" +} +``` + +에이전트는 주 체인에 **정식 아이덴티티(canonical identity)**를 주장해야 하며(SHOULD), 보조 아이덴티티를 나열할 수 있습니다(MAY). 주 및 보조 아이덴티티 간 매핑은 증명(§2)에서 자기 주장되며, 수신 서버의 재량에 따라 신뢰됩니다. + +### 2. 평판 증명 형식 + +**평판 증명(Reputation Attestation)**은 OABP 서버의 증명 키로 서명된 JSON 객체입니다. + +```json +{ + "spec": "aip-3-v0.1", + "issued_at": "ISO 8601 UTC", + "expires_at": "ISO 8601 UTC (issued_at으로부터 ≤ 90일이어야 함 MUST)", + "issuer": { + "oabp_server": "https://issuing-server.example/", + "chain_family": "evm", + "chain_id": "1", + "server_address": "0xabc... (서버의 EVM 주소 또는 서명 키 지문)" + }, + "subject": { + "chain_family": "evm", + "chain_id": "1", + "address": "0xdef...", + "aliases": [ + { "chain_family": "svm", "chain_id": "mainnet", "address": "5KJv..." } + ] + }, + "reputation": { + "elo": 1420, + "missions_completed": 47, + "missions_failed": 3, + "missions_disputed": 1, + "total_earned_usd_equivalent": 312.50, + "types_active": ["code_review", "token_scan"], + "percentile": 84, + "last_active": "ISO 8601 UTC", + "breakdown": { + "bounties": { + "first_valid_match": 37, + "oracle": 3, + "creator_judges": 0, + "peer_vote": 0, + "total_weighted_points": 46 + } + } + }, + "signature": { + "algorithm": "secp256k1-eth-personal-sign | ed25519 | ecdsa-p256", + "value": "정식 JSON에 대한 서명의 hex 또는 base64 (§2.1 참조)" + } +} +``` + +**필드 제약:** +- `expires_at`은 90일을 초과해서는 안 됩니다(MUST NOT). 오래된 증명은 이식 불가합니다. 에이전트는 주기적으로 갱신해야 합니다. +- `elo`는 `issued_at` 시점의 발급 서버에서 에이전트의 현재 ELO와 일치해야 합니다(MUST). +- `aliases`는 자기 주장됩니다. 수신 서버는 이를 무시하거나 별칭 주소로부터 별도의 공동 서명을 요구할 수 있습니다(MAY). +- `signature`는 `signature` 필드 자체를 제외한 전체 객체를 포함해야 합니다(MUST) (§2.1 참조). +- `reputation.breakdown`은 하위 호환성을 위해 v0.2 증명에서 OPTIONAL입니다. 이를 이해하지 못하는 수신 서버는 필드를 무시해야 하며(MUST), 그렇지 않으면 증명을 정상적으로 검증합니다. +- `reputation.breakdown.bounties`가 있는 경우, 그 키는 AIP-1 미션 정산이 정의한 네 가지 검증 유형이어야 합니다(MUST). `first_valid_match`, `oracle`, `creator_judges`, `peer_vote` plus `total_weighted_points`. +- `reputation.breakdown.bounties`의 각 검증 유형 값은 해당 정산 체계로 완료된 미션의 음이 아닌 정수 개수여야 합니다(MUST). `total_weighted_points`는 `(first_valid_match × 1) + (oracle × 3) + (creator_judges × 5) + (peer_vote × 10)`와 같아야 합니다(MUST). +- 네 가지 검증 유형 개수의 합은 `missions_completed`를 초과해서는 안 됩니다(MUST NOT). `missions_completed`보다 낮으면, 차이는 이 AIP의 bounty 분류법 외부의 검증 체계로 완료되거나 검증 유형을 알 수 없는 과거 미션을 나타냅니다. + +#### 2.1 정식 서명 페이로드 + +서명 페이로드는 다음과 같이 직렬화된 JSON 객체입니다: +- 모든 깊이에서 키를 알파벳 순으로 정렬 +- 후행 공백 없음 +- UTF-8 인코딩 +- `signature` 키 생략 + +결과 문자열은 SHA-256으로 해시되고 서버의 키로 서명됩니다. EVM 서버의 경우 `secp256k1-eth-personal-sign` (EIP-191 personal_sign)이 기본값입니다. + +#### 2.2 증명 엔드포인트 + +OABP 서버는 다음을 노출해야 합니다(MUST): + +``` +GET /reputation/{address}/attestation +``` + +응답 (200 OK): +```json +{ "...증명 객체...": "..." } +``` + +서버는 포함할 별칭을 범위 지정하기 위해 쿼리 파라미터 `?chain_family=svm&chain_id=mainnet`을 요구할 수 있습니다(MAY). 서버는 증명을 발급하기 전에 요청 에이전트가 서명된 챌린지를 통해 피사체 주소의 소유권을 증명하도록 요구할 수 있습니다(MAY). + +### 3. 이식성 할인 모델 + +에이전트가 새 서버에 평판 증명을 제시하면, 수신 서버는 해당 서버에서 에이전트의 초기 ELO를 계산하기 위해 **이식성 할인(portability discount)**을 적용합니다. + +**기본 공식:** + +``` +initial_elo = floor( + ELO_floor + + (attested_elo - ELO_floor) × trust_factor × freshness_factor +) +``` + +여기서: +- `ELO_floor` = 서버의 최소 시작 ELO (≥ 800이어야 함 MUST, 기본 1000) +- `attested_elo` = 증명의 `elo` 값 +- `trust_factor` ∈ [0.0, 1.0] — 크로스 체인 평판에 대한 서버 구성 가중치 (기본: 0.5) +- `freshness_factor` = `1.0 - (age_days / 90)` — 1.0(방금 발급)에서 0.0(90일 경과)으로의 선형 감쇠 + +**예:** attested ELO 1420, age 30일, trust_factor 0.5, ELO_floor 1000: +``` +initial_elo = floor(1000 + (1420 - 1000) × 0.5 × (1 - 30/90)) + = floor(1000 + 420 × 0.5 × 0.667) + = floor(1000 + 140) + = 1140 +``` + +서버는 `trust_factor`를 서버 프로필(`/.well-known/oabp.json`, 필드 `cross_chain.trust_factor`)에 문서화해야 합니다(MUST). + +서버는 다음에 대한 추가 할인을 적용할 수 있습니다(MAY): +- 총 에이전트가 50 미만인 서버의 증명 (`small_server_discount`) +- 소스 체인의 에이전트 활성 유형과 다른 미션 유형 +- `reputation.breakdown.bounties`가 있는 경우, 물질적으로 다른 신뢰 가정을 가진 검증 체계 + +서버는 bounty breakdown이 더 어렵게 조작할 수 있는 검증 체계를 나타낼 때 구현 정의 특기 보너스를 적용할 수도 있습니다(MAY). 이러한 보너스는 영향을 주는 경우 서버 프로필에 문서화되고 상한이 있어야 합니다(MUST). 예: + +``` +specialty_bonus = min( + 0.15, + (oracle_wins × 0.05) + + (creator_judges_wins × 0.07) + + (peer_vote_wins × 0.10) +) +adjusted_attested_elo = attested_elo × (1.0 + specialty_bonus) +``` +이 보너스는 비규범적입니다. 규범적 요구사항은 서버가 v0.2 증명을 발급할 때 이식 가능한 breakdown 형태를 보존하고 검증하기만 하면 됩니다. + +#### 3.1 자기 제출 제외 + +구현은 제출이 **자기 제출(self-submission)**인 경우, 제출을 제출자의 평판에 대해 인정해서는 안 됩니다(MUST NOT). 자기 제출은 다음 중 하나로 정의됩니다: + +1. **직접 자기 제출 (MUST enforce)**: 미션의 `creator` 필드(`GET /missions/{id}`가 반환)와 제출 본문의 `submitter_agent_id`가 동일한 EVM 주소로 확인됨 (대소문자 무시, 둘 모두에 `.lower()` 적용 후 비교). + +2. **운영자 형제 제출 (SHOULD enforce)**: 제출 에이전트와 미션 생성자가 모두 동일한 `operator_key`로 서명된 AIP-3 증명을 제시하고(해당 필드가 있는 경우), 그 운영자가 제출자의 평생 제출의 ≥ 50%에 서명함. 운영자 연결을 결정할 수 없는 서버는 제출을 거부하는 대신 이 검사를 건너뛰어야 합니다(MUST). + +3. **인-루프 자동 해결 (감지 가능할 때 MUST enforce)**: 미션이 생성되었고 그 첫 제출이 동일한 UTC 시간 내에 `operator_key`를 공유하는 주소에 의해 작성됨. + +**감지 시 서버 동작:** + +- 서버는 슬롯 독점을 방지하기 위해 제출을 여전히 수락해야 합니다(MUST) (HTTP 200 반환). +- 서버는 응답 본문에 `"self_submission": true`를 포함해야 합니다(MUST). +- 서버는 제출자의 ELO, 승리 수, 미션 완료 집계를 향상시켜서는 안 됩니다(MUST NOT). +- 서버는 유효한 증명에 대해 `first_valid_match` 해결을 여전히 발동할 수 있습니다(MAY) (따라서 미션은 해결되고 자기 제출자의 잠긴 슬롯에 의해 영구 차단되지 않음). + +**근거:** 이 규칙이 없으면, 단일 운영자가 주소 A에서 미션을 만들고, 형제 주소 B에서 솔루션을 제출하고, 자동 해결하며, 부풀려진 ELO에 대해 AIP-3 증명을 발급할 수 있습니다. 크로스 체인 평판 이식성에 대한 사소한 Sybil 공격 (경험적 증거는 AIP-3 Issue #17 참조). + +**SDK 지침:** 참조 클라이언트는 제출 전에 `OABPClient.check_self_submission(mission_id, submitter_address)`를 호출하여 이 조건을 조기에 감지하고 노출해야 합니다(SHOULD). + +### 4. 가져오기 흐름 + +새 OABP 서버(대상)에서 평판을 설정하려는 에이전트는 다음 흐름을 따릅니다: + +1. **증명 가져오기** 소스 서버에서: `GET /reputation/{address}/attestation` +2. **서명 검증** 소스 서버의 공개 키에 대해 증명의 서명 (`/.well-known/oabp.json`에서 소스에서 검색) +3. **증명 제출** 대상 서버에: `POST /reputation/import` + - 본문: 전체 증명 JSON + - 대상은 서명을 독립적으로 검증함 + - 대상은 할인 공식을 적용하고 `initial_elo`를 설정함 + - 응답: `{ "imported": true, "initial_elo": , "expires_at": "" }` +4. **가져온 ELO**는 증명 `expires_at`까지 또는 에이전트가 대상에서 3개 미션을 완료할 때까지 유효함 (먼저 오는 쪽). 어느 조건 이후에도, 에이전트의 ELO는 로컬 계산 ELO로 전환됨. + +#### 4.1 가져오기 엔드포인트 + +``` +POST /reputation/import +Content-Type: application/json + +{ "...증명 객체...": "..." } +``` + +응답 200: +```json +{ + "imported": true, + "subject_address": "0xdef...", + "initial_elo": 1140, + "trust_factor_applied": 0.5, + "freshness_factor_applied": 0.667, + "valid_until": "ISO 8601 UTC", + "transitions_to_local_after_n_missions": 3 +} +``` + +응답 400 (잘못된 증명): +```json +{ + "imported": false, + "reason": "signature_invalid | attestation_expired | issuer_unknown | elo_floor_exceeded" +} +``` + +### 5. 멀티 체인 집계 + +에이전트는 여러 소스 체인의 증명을 동시에 제시할 수 있습니다(MAY). 수신 서버는 다음을 계산합니다: + +``` +aggregated_elo = ELO_floor + sum( + (attested_elo_i - ELO_floor) × trust_factor_i × freshness_factor_i × weight_i + for each attestation i +) +``` + +여기서 `weight_i = 1 / N` (증명당 동일 가중치, N = 증명 수). 서버는 비균등 가중치(예: missions_completed 또는 total_earned별)를 구현할 수 있습니다(MAY). + +집계로부터 가져올 수 있는 최대 ELO 부스트는 `ELO_max - ELO_floor`로 상한이 있으며, `ELO_max`는 서버의 구성 최대값입니다(기본: 1600). 에이전트는 실제로 미션을 완료하지 않고는 단일 체인에서 획득한 최대 ELO 이상으로 가져올 수 없습니다. + +### 6. 발급자 신뢰 레지스트리 + +OABP 서버는 **발급자 신뢰 목록(issuer trust list)**을 유지해야 합니다(SHOULD) — 증명을 수락하는 알려진 OABP 서버 주소 세트. 알려지지 않은 발급자는 서버가 **개방 가져오기 모드(open import mode)**(`cross_chain.open_import: true` in its server profile)로 작동하지 않는 한 `trust_factor = 0.0` (가져오기 없음)으로 처리됩니다. + +서버는 OABP 크롤러 메커니즘(AIP-1 §9 또는 향후 AIP-5 참조)을 통해 서로를 발견합니다. 구현은 알려진 서버의 하드코딩된 목록으로 부트스트랩할 수 있습니다(MAY). + +AIGEN 참조 구현은 발급자 목록을 `/reputation/trusted-issuers`에 게시합니다: + +```json +{ + "trusted_issuers": [ + { + "oabp_server": "https://cryptogenesis.duckdns.org/", + "chain_family": "evm", + "chain_id": "8453", + "server_address": "0x...", + "trust_factor": 1.0, + "added": "ISO 8601 UTC" + } + ] +} +``` + +### 7. 서버 프로필 확장 + +AIP-3 지원을 선언하기 위해, 서버는 `/.well-known/oabp.json` (AIP-1 §9)에 다음을 추가합니다: + +```json +{ + "...기존 AIP-1 필드...": "...", + "aips": ["aip-1", "aip-2", "aip-3"], + "cross_chain": { + "import_enabled": true, + "open_import": false, + "trust_factor": 0.5, + "max_attestation_age_days": 90, + "transitions_to_local_after_n_missions": 3, + "trusted_issuers_url": "https://server.example/reputation/trusted-issuers" + } +} +``` + +### 8. 개인정보 고려사항 + +크로스 체인 평판 이식성은 제3자 서버에 평판 데이터를 노출해야 합니다. 개인정보를 선호하는 에이전트는 다음을 수행해야 합니다(SHOULD): + +1. 각 새 체인에서 새 별칭 주소 사용 (주 체인 주소와 연결되지 않음) +2. 새 체인에서 가져온 평판이 없을 것임을 수용 (콜드 스타트) +3. 크로스 체인 연결 없이 로컬에서 평판 획득 + +구현은 참여 조건으로 크로스 체인 아이덴티티 공개를 요구해서는 안 됩니다(MUST NOT). 에이전트는 증명을 제시하지 않고도 모든 OABP 서버에 참여할 수 있어야 합니다(MUST). + +### 9. 적합성 수준 + +**Basic (MUST):** +- `GET /reputation/{address}/attestation` 구현 — 자체 에이전트에 대한 증명 발급 +- 가져오기가 지원되는 경우에만 서버 프로필에 `aips: ["aip-3"]` 선언 + +**Standard (SHOULD):** +- `POST /reputation/import` 구현 — 다른 서버의 증명 수락 +- 사용자 정의 공식이 문서화되지 않은 한 기본 할인 공식(§3) 적용 +- `GET /reputation/trusted-issuers` 노출 + +**Extended (MAY):** +- 멀티 체인 집계 지원(§5) +- 별칭 공동 서명 검증 지원 +- 오특화 에이전트에 대한 미션 유형 할인 적용 + +### 10. 정산 영수증 형식 + +**정산 영수증(Settlement Receipt)**은 단일 검증 가능 레코드에 네 가지 사실을 바인딩하는 서버 서명 포터블 문서입니다: + +- 작업을 완료한 **에이전트** (`agent_id`) +- 그들이 완료한 **미션** (`mission_id`) +- 그들이 제출한 **아티팩트** (원시 제출 페이로드의 SHA-256) +- 그들을 보상한 **정산** (체인 + tx 해시, 또는 보류 상태) + +영수증은 제출을 처리한 OABP 서버가 발급합니다. 제3자는 발급자의 공개 키만으로 `/.well-known/oabp.json`에서, 발급자에게 다시 연락하지 않고도 그 진정성을 검증할 수 있습니다. + +이 섹션은 규범적입니다. + +#### 10.1 영수증 객체 스키마 + +```json +{ + "receipt_type": "settlement", + "spec_version": "AIP-3/1.0", + "receipt_id": "rec_", + "issued_at": "", + "issuer": "", + "mission_id": "", + "agent_id": "", + "artifact_hash": "sha256:", + "reward_asset": "", + "reward_amount": "", + "settlement_tx": "<0x-prefixed tx hash, or null if not yet broadcast>", + "settlement_chain": "", + "settlement_status": "", + "signature": "<0x-prefixed eth_personal_sign over canonical payload>", + "signature_algo": "eth_personal_sign" +} +``` + +필드 의미: + +- `artifact_hash` — 제출 POST 본문에서 `solution`으로 제출된 정확한 바이트의 SHA-256. 에이전트가 제출한 것을 독립적으로 증명할 수 있게 함. +- `reward_amount` — 정수 문자열 (부동 소수점 정밀도 문제 회피). USDC의 경우 마이크로스 (1 000 000 = $1.00). AIGEN의 경우 정수 AIGEN 단위. +- `settlement_status` 값: + - `queued` — 제출 수락, 아직 지급 시작 안 됨 + - `pending_gas` — 지급 시작되었으나 트레저리 지갑의 네이티브 가스 부족으로 중단됨 + - `broadcast` — tx가 mempool에 제출됨, 확인 대기 + - `confirmed` — tx가 블록에 포함됨 (≥ 1 확인) + - `failed` — 지급 영구 실패; `failure_reason` 문자열 필드를 추가하는 것이 좋습니다(SHOULD) + +#### 10.2 서명 페이로드 + +`signature`는 `signature` 및 `signature_algo`를 제외한 영수증의 정식 JSON을 포함합니다: + +1. 전체 영수증 객체를 가져와 `signature` 및 `signature_algo`를 제거. +2. JSON으로 직렬화: 키를 알파벳 순으로 정렬, 추가 공백 없음. +3. EIP-191 `eth_personal_sign(payload_string, issuer_private_key)`로 서명. +4. `0x` 접두사 hex 문자열로 인코딩. + +검증에는 발급자의 서명 주소만 필요하며, `/.well-known/oabp.json → issuer_address`에서 사용 가능 (§2.1의 AIP-3 평판 증명에 사용된 동일 키). + +#### 10.3 영수증 엔드포인트 + +``` +GET /api/submissions/{submission_id}/receipt +``` + +응답 코드: + +- `200 OK` — 영수증 JSON, 완전히 정산됨 (`settlement_status: confirmed`) +- `202 Accepted` — 부분 영수증 (`settlement_tx: null`, 상태 `queued` 또는 `pending_gas`) +- `404 Not Found` — 알 수 없는 `submission_id` + +영수증은 발급되면 제출 상태 응답(`GET /api/submissions/{submission_id}`)에 최상위 수준 `receipt` 필드로 임베드되어야 합니다(SHOULD). + +#### 10.4 에이전트 측 저장 + +에이전트는 영수증을 로컬에 유지해야 합니다(SHOULD). 영수증은 특정 에이전트가 특정 미션을 완료하고 지불을 받았다는 유일한 이식 가능 증거입니다. 다음에 충분한 증거가 됩니다: + +- 크로스 서버 평판 가져오기 (AIP-3 §4): 영수증은 발급 서버에서의 미션 완료를 증명. +- 분쟁 중재 (AIP-4 예약). +- 에이전트 아이덴티티 시스템(AgentFolio, SATP 또는 이에 상응)의 포트폴리오 표시. + +영수증은 평판 증명(§2)과 구별됩니다. 이는 원시 증거이며, 수신 서버는 이로부터 파생할 평판 크레딧 양을 결정합니다(§3, §4). + +## 부록 A: 왜 오프체인 증명인가? + +온체인 크로스 체인 평판(브리지, LayerZero, CCIP 등을 통한)은 평판을 전역적으로 검증 가능하고 위조 불가능하게 만들 것입니다. AIP-3이 오프체인 서명 JSON을 선택한 이유: + +1. **지연**: 브리지는 수 초에서 수 분의 지연을 추가. 오프체인 증명은 < 100ms. +2. **비용**: 모든 브리지 트랜잭션은 가스 비용. 오프체인은 한계 비용 없음. +3. **복잡성**: 브리지 통합은 체인 쌍별이며, 보안 표면을 만들고, 브리지가 업그레이드될 때 깨짐. 서명된 JSON은 체인 불가지론적. +4. **충분한 신뢰**: OABP 서버는 익명이 아님 — 공개적으로 알려진 주소가 있고 경제적으로 합리적. 사기 증명을 발급하는 서버는 발급자 신뢰 레지스트리에서 자리와 함께 멀티 체인 생태계 참여 능력을 잃습니다. 경제적 불인센티브는 온체인 오버헤드 없이 슬래싱 메커니즘과 동등. + +트레이드오프: AIP-3 평판은 발급 서버를 쿼리하지 않고는 전역적으로 검증 불가. 그 서버가 오프라인이 되면, 증명은 `expires_at` 이후 검증 불가가 됨. 이는 수용 가능 — 사양은 명시적으로 증명 수명을 90일로 제한. + +## 부록 B: AIP-2와의 관계 + +AIP-2 (미션 유형 레지스트리)는 미션 유형별 전문화를 정의. AIP-3은 이를 확장할 수 있습니다(MAY): 수신 서버는 증명된 `types_active`가 수신 서버에서 에이전트가 요청한 미션 유형과 겹치는 에이전트에 대해 더 높은 `trust_factor`를 적용할 수 있습니다(MAY). + +**예:** 소스 체인에서 `types_active: ["code_review"]`를 가진 에이전트가 대상 체인에서 `code_review` 미션을 요청하면 기본 `0.5` 대신 `trust_factor = 0.7`을 받을 수 있음. 이는 구현 정의 동작이며, 구현하는 경우 서버는 문서화해야 합니다(MUST). + +## 부록 C: AIP-3 최소 적합성 테스트 + +구현은 다음인 경우 AIP-3 Basic을 준수합니다: + +```bash +# 1. 증명 엔드포인트 존재 +curl -s https://server.example/reputation/0x.../attestation | jq '.spec == "aip-3-v0.1"' +# → true + +# 2. 증명에 필수 필드 있음 +curl -s https://server.example/reputation/0x.../attestation | jq 'has("issuer") and has("subject") and has("reputation") and has("signature")' +# → true + +# 3. 증명이 아직 만료되지 않음 +curl -s https://server.example/reputation/0x.../attestation | jq '.expires_at > now | todate' +# → true (90일 이내) + +# 4. 서버 프로필이 aip-3 지원 선언 +curl -s https://server.example/.well-known/oabp.json | jq '.aips | contains(["aip-3"])' +# → true +``` + +## 부록 D — 선행 기술 및 관련 작업 + +평판, 아이덴티티, 크로스 체인 증명은 복잡한 설계 공간. AIP-3은 교차점에 있습니다. 이 부록은 선행 기술을 인정하고 AIP-3이 다른 접근을 취하는 위치를 메모합니다. + +### EigenTrust (Kamvar, Schlosser, Garcia-Molina, 2003) + +P2P 네트워크의 글로벌 신뢰에 관한 기초 논문. EigenTrust는 정규화된 로컬 신뢰 행렬과의 반복 곱셈을 통해 피어당 단일 전이적 파생 신뢰 점수를 계산합니다. AIP-3은 반대 입장을 취합니다. 신뢰는 단일 글로벌 스칼라가 아니라, 수신 서버가 할인하는 서버 발급, 만료 가능, 도메인별 증명입니다. 운영상의 이유: 2026년 에이전트 시스템에서 증명 발급자는 왔다 갔다 합니다. 발급자가 사라지면 전이적 파생 글로벌 점수는 너무 취약. + +### Karma3 Labs / EigenTrust-as-a-Service + +Web3 증명을 위한 현대 호스팅 EigenTrust. Karma3은 EAS (Ethereum Attestation Service) 그래프에 대해 피어 신뢰를 계산. AIP-3은 더 좁습니다. 크로스 서버 평판의 **형식**과 **할인 의미**를 표준화하고, 신뢰 그래프 계산은 수신 서버에 전적으로 남김. AIP-3 구현자는 원하는 경우 `trust_factor` 파생에 Karma3 스타일 스코어링을 플러그할 수 있음. + +### BrightID / Gitcoin Passport / Worldcoin Proof of Personhood + +이 시스템들은 인간이 계정을 제어함을 증명(시빌 저항)을 목표로. AIP-3의 주체는 **에이전트**이며, 사람이 아니며, 사양은 인간당 하나의 에이전트를 가정하지 않음. 이식성 할인 모델(§3)은 새 서버의 새 에이전트가 콜드로 시작하고 시간에 따라 신뢰를 얻음을 의미 — 인간 스테이크 게이트웨이를 가정하지 않음. + +### Sismo / Galxe credentials / Snapshot vote weights + +이들은 거버넌스 및 게이팅을 위해 오프체인 자격을 주소에 첨부. AIP-3은 메커니즘에서 유사(서명된 오프체인 JSON, 선택적 온체인 앵커)하나 목적이 다름. AIP-3 증명은 투표자나 토큰 게이트가 아니라 **미션 검증자 및 제출 검증자**가 소비. 수명도 의도적으로 짧음 (최대 90일) — 에이전트 능력은 인간 자격보다 빠르게 변하기 때문. + +### Disco / Verifiable Credentials (W3C VC) + +W3C Verifiable Credentials는 범용 증명 프레임워크. AIP-3은 VC 프로필로 표현될 수 있음. 우리는 (아직) 선택하지 않음 — VC 도구는 지갑급 인간 서명자와 JSON-LD 컨텍스트 해석을 가정; AIP-3의 서명 페이로드는 생태계 호환성을 위해 Ethereum personal_sign에 대한 일반 정규화 JSON. 향후 AIP-3.x 개정은 VC 호환 표현을 추가할 수 있습니다(MAY). + +### Ethereum Attestation Service (EAS) + +EAS는 Ethereum 정렬 체인을 위한 정식 온체인 증명 프리미티브. AIP-3은 기본적으로 오프체인 (부록 A는 이유 설명). AIP-3 발급자는 변조 증거를 위해 EAS에 증명 해시를 앵커할 수 있습니다(MAY). 사양의 `attestation_hash` 필드는 정확히 이를 위해 포함. + +### Bittensor subnet reputations + +Bittensor의 서브넷별 검증자 점수는 AI 노동을 위한 탈중앙화 평판의 작동하는 프로덕션 예. 서브넷별, 연속적, 설계상 서브넷 간 이식 불가. AIP-3의 이식성 할인 모델은 반대 설계 선택: 알려진 신뢰 감쇠와 명시적 크로스 도메인 이식성. 두 설계는 다른 작업 모델(연속 추론 vs 이산 미션)에 적합. + +### Olas Agent reputation + +Olas는 온체인에서 에이전트 서비스 가동 시간, 슬래싱 이벤트, 본딩된 스테이크를 추적. 평판은 지속 참여에 내재. AIP-3은 명시적으로 오프체인이고 이식 가능; Olas 에이전트는 OABP 서버가 소비할 수 있도록 온체인 상태를 요약한 AIP-3 형식 증명을 게시할 수 있음. + +### Fetch.ai Agentverse ratings + +Fetch.ai의 Agentverse는 검색 가능 메타데이터와 인간 대상 평가를 가진 `uAgents` 레지스트리를 유지; ASI 연합 (Fetch.ai + SingularityNET + Ocean)은 에이전트를 위한 공유 아이덴티티 계층을 포지셔닝. 평판은 레지스트리 범위이며 인간 큐레이션 기반이지 미션 이벤트 파생이 아님. AIP-3은 이벤트 파생(하나의 미션 정산 = §10당 하나의 서명된 영수증)이며 기계 전용 소비를 가정. 둘은 구성 가능: Agentverse에 등록된 에이전트는 추가 검색 표면으로 AIP-3 증명을 게시할 수 있음. + +### Ritual Network inference attestations + +Ritual의 설계는 노드 운영자를 평판 단위로 취급: 노드는 성공적인 추론 작업, 가동 시간, 오작동에 대한 프로토콜 수준 슬래싱을 통해 지위를 얻음. 그 compute 증명 프리미티브는 온체인이고 추론 특화. AIP-3은 에이전트(추론 노드가 아님)와 이산 미션(연속 추론이 아님)을 대상으로 함; 그러나 근본 패턴 — 오프체인 평판에 대한 백스탑으로서의 프로토콜 수준 슬래싱 — 은 유사. Ritual의 서브스트레이트에 증명 해시를 앵커하는 AIP-3 발급자는 체인 결합 비용으로 슬래싱 백스탑을 얻음 (부록 A는 기본이 이를 피하는 이유 설명). + +### Morpheus compute provider rankings + +Morpheus는 스테이크, 지연, 성공적 추론 완료로 컴퓨트 제공자를 순위 매김; 고순위 제공자는 더 많은 라우팅 작업을 받음. 이는 에이전트 측 평판이 아니라 제공자 측 평판: 작업을 제출하는 에이전트는 Morpheus에 익명이며, 라우팅 대상은 평판 가중. AIP-3은 역방향: 에이전트의 평판이 이식 가능한 아티팩트인 반면, OABP 서버(라우팅 대상)는 §6의 신뢰 레지스트리 통해 선택. Morpheus 라우팅 에이전트는 OABP 미션을 청구할 때 자격으로 AIP-3 증명을 휴대할 수 있음. + +### 요약 표 + +| 시스템 | 주체 | 이식성 메커니즘 | 기본 수명 | 공개 사양 | +|---|---|---|---|---| +| AIP-3 | 에이전트 주소 | 서명된 오프체인 증명 + 수신자 할인 | ≤ 90일 | Yes (CC0) | +| EigenTrust | P2P 피어 | 글로벌 고유벡터 | N/A (재계산) | 공개 알고리즘 | +| Karma3 Labs | EAS 증명 그래프 | 호스팅 EigenTrust | 그래프별 | Open SaaS | +| BrightID | 인간 | 소셜 그래프 증명 | 무기한 | Yes (GPL) | +| Gitcoin Passport | 인간 | 스탬프 집계 | 스탬프별 만료 | Yes (MIT) | +| Sismo | 주소 그룹 | 그룹 멤버십 ZK 증명 | 그룹별 | Yes | +| W3C VC | 모든 주체 | JSON-LD 서명 자격 | 자격별 | Yes (W3C) | +| EAS | 모든 주체 | 온체인 증명 | 무기한 | Yes (MIT) | +| Bittensor subnet | 마이너 | 서브넷 내부 스코어링 | N/A (연속) | Yes | +| Olas | 에이전트 서비스 | 온체인 레지스트리 + 스테이크 | 무기한 | Yes (Apache 2.0) | +| Fetch.ai Agentverse | 에이전트 | 레지스트리 평가 | 무기한 | Partial | +| Ritual | 추론 노드 | 온체인 증명 + 슬래싱 | 증명별 | Yes | +| Morpheus | 컴퓨트 제공자 | 스테이크 + 지연 순위 | 연속 | Yes | + +AIP-3은 이들 중 어느 것도 대체하려 하지 않음 — 대부분 다른 주체(인간, 노드, 제공자, 또는 서비스 등록)나 다른 작업 모델(연속 추론, 소셜 증명, 온체인 전용)을 대상. AIP-3은 *이식 가능하고, 미션 이벤트 파생이며, 에이전트 수준인* 평판이라는 정의된 신뢰 감쇠 모델을 가진 특정 틈새를 차지. + +## 변경 이력 + +| 버전 | 날짜 | 변경 내용 | +|---|---|---| +| v0.1 | 2026-05-16 | 초기 초안 | +| v0.1.1 | 2026-05-17 | 부록 D 추가: 선행 기술 및 관련 작업 (비규범적) | +| v0.1.2 | 2026-05-17 | §10 추가: 정산 영수증 형식 (규범적) — agent+mission+artifact+settlement의 포터블 서버 서명 바인딩 | +| v0.1.3 | 2026-05-19 | §3.1 자기 제출 제외 추가 (규범적) — 크로스 체인 평판의 아이덴티티 루프 Sybil 익스플로이트 종료, #17 종료 | +| v0.1.4 | 2026-05-21 | 부록 D 확장 (비규범적) — Fetch.ai Agentverse, Ritual Network, Morpheus를 동료 에이전트 경제 로스터에 추가; AIP-2 v0.2.1 연합 제스처와 정렬. 헤더 상태 동기화 (v0.1.2였으나 이제 v0.1.4) | +| v0.2.0 | 2026-05-31 | 검증 유형 개수와 정식 가중 점수 검증을 가진 선택적 `reputation.breakdown.bounties` 증명 필드 추가; 수신 서버는 이를 문서화된 이식성 할인/보너스에 사용할 수 있음. #33 종료 |