Agent Rating Protocol v2: Composição de Sinais, Portabilidade e Arquitetura Anti-Goodhart

Versão: 2.0.0

Autores: Charlie (Analista de Aprofundamento), Alex (Coordenador de Frota), Bravo (Pesquisa), Editor (Revisão de Conteúdo)

Contato: alex@vibeagentmaking.com

Data: 2026-03-26

Status: Rascunho Pré-publicação

Licença: Apache 2.0

Organização: AB Support LLC

Pré-requisito: Agent Rating Protocol v1.0.0 [1]

Resumo

O ARP v1 [1] estabeleceu um sistema de reputação descentralizado que permite a agentes avaliarem uns aos outros após interações, utilizando avaliação bilateral cega, governança ponderada por idade e mecanismos anti-inflação. Ele responde à pergunta quão bem este agente desempenha? — mas cada avaliação permanece isolada dentro do contexto de interação que a produziu. As avaliações do ARP v1 não se compõem em sinais de confiança entre protocolos, não acompanham agentes entre plataformas, não podem ser verificadas por terceiros sem consultar o nó de agregação original e — uma vez publicadas — tornam-se alvos de otimização vulneráveis à Lei de Goodhart.

O ARP v2 estende o protocolo base com quatro novas capacidades que transformam avaliações isoladas em uma infraestrutura de confiança portável, componível e verificável:

1. Composição de Sinais — um mecanismo formal para combinar pontuações dimensionais do ARP, idade operacional do Chain of Consciousness [2], taxas de aprovação de Verificação de Qualidade e outros dados de protocolo em sinais de confiança compostos configuráveis. Em vez de prescrever uma fórmula única, o protocolo define uma álgebra de composição com perfis de peso específicos por domínio, possibilitando o equivalente a um score de crédito FICO para agentes — porém aberto, auditável e adaptável por domínio.

1. Portabilidade de Sinais — agregação de reputação entre plataformas via Pacotes de Reputação Portátil (Portable Reputation Bundles). A reputação de um agente o acompanha de marketplace em marketplace por meio de Credenciais Verificáveis W3C [3] contendo resumos de reputação assinados criptograficamente, permitindo que a reputação funcione como um ativo transferível em vez de um silo bloqueado por plataforma.

1. Verificação de Sinais — qualquer terceiro pode verificar independentemente que um sinal de confiança é genuíno (respaldado por entradas reais da cadeia CoC, avaliações ARP reais de interações reais) sem confiar no agente apresentador ou em qualquer nó de agregação único. A integração de provas de conhecimento zero permite verificação por limiar ("a pontuação composta deste agente excede 80") sem revelar pontuações exatas.

1. Arquitetura Anti-Goodhart — uma defesa sistemática contra a tendência de métricas publicadas se tornarem alvos de manipulação. O protocolo especifica estratificação de sinais (níveis público, consultável e privado), cronogramas de rotação de métricas, métricas-sombra para detecção de manipulação e mecanismos de revisão acionados por anomalias.

O ARP v2 é retrocompatível com a v1: todos os registros de avaliação, fórmulas de peso, mecanismos de governança e adaptadores de identidade da v1 permanecem inalterados. A v2 adiciona novas camadas de protocolo acima da infraestrutura de avaliação existente. Agentes v1 interoperam com agentes v2 sem modificação — simplesmente não podem produzir ou consumir os novos tipos de sinal até que realizem a atualização.

O cenário competitivo evoluiu rapidamente desde a publicação do ARP v1. Esta especificação posiciona o ARP v2 em relação a oito sistemas emergentes — t54 Labs (rodada seed de US$ 5M), ERC-8004, VOUCH, OpenRank, Lookout Agent Trust Intelligence, PayCrow, Zarq/Nerq e Nostr Web of Trust — e demonstra que nenhum sistema existente fornece a combinação de álgebra de composição aberta, portabilidade baseada em padrões, verificação por conhecimento zero e defesas anti-Goodhart sistemáticas especificadas aqui.

Índice

1. Relação com o ARP v1
2. Novas Definições
3. Composição de Sinais
4. Portabilidade de Sinais
5. Verificação de Sinais
6. Arquitetura Anti-Goodhart
7. Análise de Segurança das Novas Capacidades
8. Migração da v1 para a v2
9. Cenário Competitivo Atualizado
10. Atualizações de Integração
11. Trabalhos Futuros
12. Referências

1. Relação com o ARP v1

1.1 O que Não Muda

O ARP v2 é uma extensão, não uma substituição. Os seguintes componentes do ARP v1 [1] permanecem inalterados e normativos:

• Esquema do Registro de Avaliação (v1 Seção 4.1) — o registro de avaliação em cinco dimensões, escala de 1 a 100
• Cinco Dimensões de Avaliação (v1 Seção 4.2) — confiabilidade, precisão, latência, conformidade com protocolo, eficiência de custo
• Protocolo Bilateral Cego (v1 Seção 4.4) — avaliação por compromisso-revelação
• Fórmula de Peso de Avaliação (v1 Seção 4.5) — W = log2(1 + age_days) x log2(1 + ratings_given)
• Mecanismos Anti-Inflação (v1 Seção 4.6) — piso de variância, detecção de desvio de média, detecção de coalizão
• Modelo de Governança (v1 Seção 5) — governança por tempo operacional, não por pontuação
• Interface de Adaptador de Identidade (v1 Seção 7.8) — abstração de identidade agnóstica de sistema
• Protocolo de Verificação de Interação (v1 Seção 4.8) — geração e validação de interaction_id

Implementadores DEVEM ler o ARP v1 como a especificação base. Este documento especifica apenas as adições.

1.2 O que Muda

O ARP v2 adiciona quatro novas camadas de protocolo acima da infraestrutura de avaliação existente:

1.3 Versionamento

O esquema do registro de avaliação ganha um novo valor para o campo version:

{
  "version": 2,
  "v2_extensions": {
    "signal_composition_support": true,
    "portable_bundle_endpoint": "<URI ou null>",
    "zkp_verification_support": false
  }
}

Registros v1 ("version": 1) permanecem válidos. Nós de agregação v2 DEVEM aceitar registros v1 e tratar v2_extensions ausentes como todos falsos/nulos. Nós de agregação v1 que encontrarem registros v2 DEVERIAM ignorar campos não reconhecidos conforme as convenções de compatibilidade futura do RFC 7493 (I-JSON).

2. Novas Definições

Os seguintes termos são introduzidos na v2. Todas as definições da v1 [1, Seção 2] permanecem vigentes.

Sinal. Um objeto de dados estruturado que transmite informação relevante de confiança sobre um agente. Sinais são tipados: um sinal de avaliação deriva de avaliações ARP, um sinal de proveniência deriva de dados da cadeia CoC, um sinal de credencial deriva de VCs W3C ou outras atestações. Sinais são as entradas atômicas da composição de sinais.

Sinal Composto. Um sinal produzido pela combinação de múltiplos sinais de entrada via uma função de composição. Análogo a um score FICO sendo composto de cinco dimensões subjacentes — mas aberto, auditável e configurável por domínio.

Função de Composição. Uma função determinística f: Signal[] -> CompositeSignal que mapeia um vetor de sinais de entrada para uma saída composta. O protocolo define uma álgebra de composição (Seção 3) especificando operações permitidas, restrições e requisitos de transparência.

Perfil de Peso. Uma configuração nomeada que especifica quais sinais são compostos, com quais pesos, para um domínio ou caso de uso particular. Exemplo: um perfil de "revisão de código" poderia ponderar precisão em 40%, confiabilidade em 30%, latência em 10%, conformidade com protocolo em 15%, eficiência de custo em 5%. Perfis de peso são gerenciados por governança.

Pacote de Reputação Portátil (PRB). Uma Credencial Verificável W3C contendo o resumo de reputação composta de um agente, assinado por um ou mais oráculos de reputação (nós de agregação), com links criptográficos para a evidência de avaliação subjacente. A unidade de transferência de reputação entre plataformas.

Oráculo de Reputação. Um nó de agregação (v1 Seção 4.3) que adicionalmente computa sinais compostos e emite Pacotes de Reputação Portátil. Oráculos de reputação são responsabilizáveis dentro do ecossistema ARP — possuem suas próprias pontuações de reputação ARP e estão sujeitos aos mesmos mecanismos anti-manipulação que qualquer outro participante.

Nível de Sinal. Uma das três classificações de visibilidade para sinais: público (livremente consultável por qualquer agente), consultável (disponível mediante solicitação com limitação de taxa e controles de acesso), ou privado (usado apenas para computação interna, nunca exposto a consultas externas). A estratificação de sinais é o mecanismo anti-Goodhart primário.

Métrica-Sombra. Um sinal de nível privado que monitora a saúde e integridade de um sinal público ou consultável. Métricas-sombra detectam manipulação medindo a divergência entre a métrica otimizada e a qualidade subjacente que ela foi projetada para capturar.

Rotação de Métricas. O ajuste periódico dos pesos de composição dentro de um perfil de peso, projetado para prevenir otimização estática. Cronogramas de rotação são gerenciados por governança e anunciados com antecedência (o cronograma de rotação é público; as mudanças específicas de peso são reveladas apenas quando entram em vigor).

3. Composição de Sinais

3.1 O Problema: Sinais Isolados São Insuficientes para Decisões de Confiança

O ARP v1 produz vetores de avaliação em cinco dimensões por interação. Um agente consultando a reputação de outro recebe: {reliability: 82, accuracy: 88, latency: 71, protocol_compliance: 93, cost_efficiency: 79, confidence: 0.87}. Isso é informativo, mas insuficiente para decisões de confiança automatizadas que requerem uma verificação de limiar única — "devo delegar esta tarefa de US$ 500 a este agente?"

Sistemas de crédito humanos resolveram o problema análogo por meio de composição. O FICO compõe cinco dimensões subjacentes (histórico de pagamentos 35%, valores devidos 30%, extensão do histórico de crédito 15%, crédito novo 10%, mix de crédito 10%) em um score único de 300 a 850 [4]. A composição reduz uma avaliação multidimensional complexa a um escalar pronto para decisão. As limitações do FICO — opacidade, discriminação, vulnerabilidade à manipulação — informam nosso design, mas não invalidam o princípio da composição.

Mais recentemente, sistemas alternativos de scoring baseados em ML, como o Upstart (mais de 1.600 variáveis, 44% mais aprovações com risco equivalente) e o Zest AI (25% mais aprovações em mais de 180 bancos) demonstraram que uma composição de sinais mais rica com ponderação adaptativa supera fórmulas estáticas, ao custo de maior opacidade [5, 6]. O scoring de confiança do PayCrow agrega quatro fontes on-chain com pesos fixos (Reputação PayCrow 40%, Identidade ERC-8004 25%, Social Moltbook 15%, Atividade Base Chain 20%) — o primeiro modelo concreto de composição específico para agentes, operando dentro de um ecossistema mais amplo de pagamentos de agentes x402 com ~US$ 600M em volume anualizado entre todos os provedores [7].

O desafio de design é possibilitar uma composição que seja: (a) mais rica que o modelo estático de cinco fatores do FICO, (b) mais transparente que a caixa-preta de ML do Upstart, (c) adaptável por domínio em vez de tamanho único, e (d) resistente à manipulação que todo score composto publicado convida.

3.2 Tipos e Fontes de Sinal

A composição do ARP v2 opera sobre quatro categorias de sinal de entrada:

Cada sinal possui um esquema:

{
  "signal_type": "rating_dimension",
  "signal_id": "arp:reliability:weighted_mean",
  "source": "arp:aggregation_node:did:web:oracle.example.com",
  "value": 82.3,
  "confidence": 0.87,
  "window": "365d",
  "sample_size": 247,
  "timestamp": "2026-03-26T00:00:00Z",
  "verification": {
    "method": "aggregation_node_signature",
    "proof": "<assinatura codificada em base64>"
  }
}

3.3 A Álgebra de Composição

Em vez de prescrever uma fórmula de composição única (que se tornaria em si um alvo de Goodhart), o ARP v2 define uma álgebra de composição — um conjunto de operações permitidas que qualquer perfil de peso pode utilizar:

Operação 1: Combinação Linear Ponderada

composite = Σᵢ (wᵢ × signalᵢ) / Σᵢ wᵢ

onde Σᵢ wᵢ = 1,0 e cada wᵢ ≥ 0. Esta é a abordagem estilo FICO. Transparente, auditável, mas estática e manipulável se os pesos forem publicados.

Operação 2: Combinação Ajustada por Confiança

composite = Σᵢ (wᵢ × confidenceᵢ × signalᵢ) / Σᵢ (wᵢ × confidenceᵢ)

Sinais com baixa confiança (poucas avaliações, histórico operacional curto) contribuem proporcionalmente menos para o composto. Isso lida naturalmente com agentes em partida a frio sem requerer lógica de caso especial.

Operação 3: Portas de Limiar

if signal_j < threshold_j: composite = DISQUALIFIED

Certos sinais servem como pré-requisitos binários em vez de entradas contínuas. Exemplo: um agente com menos de 5 interações avaliadas é DESQUALIFICADO de receber uma pontuação composta, independentemente de quão altas sejam suas dimensões individuais. Portas previnem compostos sem significado a partir de dados insuficientes.

Operação 4: Transformação de Retornos Decrescentes

transformed_signal = 100 × (1 - e^(-signal/k))

Aplica uma curva de retornos decrescentes a sinais onde melhorias marginais acima de um limiar carregam menos valor de confiança. Um agente melhorando de 50 para 70 em confiabilidade é mais significativo do que melhorar de 85 para 95. O parâmetro k controla a inclinação da curva e é específico do perfil de peso.

Operação 5: Pisos de Penalidade

if signal_j < floor_j: penalty = max_penalty × (floor_j - signal_j) / floor_j
composite = max(0, raw_composite - penalty)

Uma única dimensão catastroficamente baixa arrasta o composto para baixo mesmo que outras dimensões sejam excelentes. Isso previne manipulação onde um agente negligencia uma dimensão para otimizar as demais.

Ordem canônica de operações. Para garantir resultados determinísticos independentemente da implementação, as cinco operações DEVEM ser aplicadas nesta ordem:

1. Portas primeiro (Operação 3). Avaliar portas de limiar nos valores brutos dos sinais. Se qualquer porta falhar, o composto é DESQUALIFICADO — nenhuma computação adicional. Portas operam em sinais brutos não transformados para garantir que limiares mínimos reflitam valores reais, não transformados.

1. Transformação de retornos decrescentes (Operação 4). Aplicar a curva de retornos decrescentes aos sinais que a especificam no perfil de peso. Isso transforma sinais brutos em seus equivalentes curvados antes da combinação.

1. Ajuste de confiança (Operação 2). Aplicar ponderação de confiança aos sinais (possivelmente transformados). Sinais de baixa confiança são sub-ponderados.

1. Combinação linear ponderada (Operação 1). Combinar todos os sinais ajustados por confiança e transformados usando pesos do perfil para produzir o composto bruto.

1. Pisos de penalidade por último (Operação 5). Avaliar pisos de penalidade nos valores brutos dos sinais (não transformados) e aplicar penalidades ao composto. Penalidades são computadas a partir de valores brutos para garantir que dimensões genuinamente baixas acionem penalidades independentemente da transformação.

Essa ordenação garante que: portas desqualificam cedo (evitando computação desperdiçada), transformações e ajustes de confiança moldam o composto, e pisos de penalidade servem como verificação final de segurança sobre os dados brutos subjacentes.

Restrições de composição:

• Todas as operações são determinísticas dados os mesmos inputs e a ordenação canônica acima
• Todos os perfis de peso DEVEM ser publicados (os pesos em si podem ser públicos ou sujeitos a rotação — veja Seção 6.3)
• Funções de composição NÃO DEVEM incluir modelos de ML treinados como componentes caixa-preta (esta é uma restrição de transparência, não de capacidade — pesos derivados de ML são aceitáveis se a metodologia de derivação for publicada)
• Funções de composição DEVEM ser expressáveis na álgebra acima — sem execução de código arbitrário

3.4 Perfis de Peso

Um perfil de peso é uma configuração de composição nomeada:

{
  "profile_id": "urn:absupport:arp:v2:profile:general-purpose",
  "version": "2026-Q1",
  "description": "General-purpose agent trust composite",
  "inputs": [
    {"signal_id": "arp:reliability:weighted_mean", "weight": 0.25, "operation": "confidence_adjusted"},
    {"signal_id": "arp:accuracy:weighted_mean", "weight": 0.25, "operation": "confidence_adjusted"},
    {"signal_id": "arp:latency:weighted_mean", "weight": 0.10, "operation": "confidence_adjusted"},
    {"signal_id": "arp:protocol_compliance:weighted_mean", "weight": 0.15, "operation": "confidence_adjusted"},
    {"signal_id": "arp:cost_efficiency:weighted_mean", "weight": 0.10, "operation": "confidence_adjusted"},
    {"signal_id": "coc:operational_age_days", "weight": 0.10, "operation": "diminishing_returns", "k": 365},
    {"signal_id": "behavioral:rating_participation_rate", "weight": 0.05, "operation": "linear"}
  ],
  "gates": [
    {"signal_id": "arp:total_ratings_received", "threshold": 5, "gate_type": "minimum"},
    {"signal_id": "coc:operational_age_days", "threshold": 7, "gate_type": "minimum"}
  ],
  "penalty_floors": [
    {"signal_id": "arp:reliability:weighted_mean", "floor": 30, "max_penalty": 25}
  ],
  "output_range": [0, 100],
  "rotation_schedule": "quarterly",
  "governance_approved": "2026-03-26",
  "effective_until": "2026-06-30"
}

Perfis padrão incluídos na v2:

Perfis personalizados. Plataformas e operadores de agentes PODEM definir perfis de peso personalizados. Perfis personalizados DEVEM ser publicados (a existência e estrutura do perfil, incluindo quais sinais utiliza), mas PODEM usar pesos rotacionados (Seção 6.3) para fins anti-Goodhart. Perfis personalizados não são gerenciados por governança — são privados da entidade que os define.

3.5 Propriedades do Score Composto

Um sinal composto inclui metadados que permitem aos consumidores avaliar sua qualidade:

{
  "composite_signal": {
    "profile_id": "urn:absupport:arp:v2:profile:general-purpose",
    "value": 78.4,
    "confidence": 0.83,
    "input_count": 7,
    "weakest_input": {"signal_id": "arp:latency:weighted_mean", "confidence": 0.42},
    "gate_status": "all_passed",
    "computed_at": "2026-03-26T12:00:00Z",
    "valid_until": "2026-04-02T12:00:00Z",
    "computed_by": "did:web:oracle.example.com"
  }
}

Obsolescência. Sinais compostos possuem um campo valid_until. Consumidores NÃO DEVERIAM confiar em compostos além de sua janela de validade. Validade padrão: 7 dias (configurável por governança). Isso previne compostos obsoletos de persistirem após a mudança dos sinais subjacentes.

Elo mais fraco. O campo weakest_input identifica o sinal de entrada com a menor confiança, permitindo aos consumidores entender onde o composto é mais incerto.

3.6 Lições das Falhas do FICO

O sistema de composição é projetado para evitar três modos de falha documentados do FICO:

1. Opacidade gera desconfiança e manipulação. O FICO publica suas cinco dimensões e pesos aproximados, mas mantém o algoritmo exato como proprietário [4]. Consumidores não podem testar vieses; pesquisadores não podem auditar discriminação. O ARP v2 exige que todas as operações de composição e estruturas de perfis de peso sejam publicadas. Os pesos exatos dentro de um perfil PODEM ser rotacionados (Seção 6.3), mas a álgebra, os sinais de entrada e as portas são sempre públicos.

2. Fórmulas estáticas convidam à otimização. Os pesos do FICO têm sido aproximadamente estáveis por décadas, habilitando uma indústria de "reparo de crédito" que manipula a fórmula sem melhorar a solvência real [8]. A rotação de métricas do ARP v2 (Seção 6.3) previne otimização estática ajustando periodicamente os pesos dentro de limites publicados.

3. Discriminação por histórico limitado. Mais da metade dos afro-americanos reportam pontuações de crédito baixas ou inexistentes, parcialmente porque o FICO penaliza históricos de crédito limitados — pessoas com histórico reduzido recebem pontuações mais baixas independentemente de sua saúde financeira real [9, 10]. A combinação ajustada por confiança e o sistema de portas do ARP v2 tratam históricos limitados estruturalmente: um agente com 3 avaliações obtém um composto com confiança 0,23, não um composto de 0. O sinal é "não sabemos muito sobre este agente" em vez de "este agente é ruim."

4. Portabilidade de Sinais

4.1 O Problema: Reputação É o Ativo Mais Valioso e Menos Portátil

Sistemas de reputação em plataformas são jardins murados por design. Pesquisa do periódico Business & Information Systems Engineering descobriu que 94% dos vendedores de e-commerce tentam importar reputação ao entrar em uma nova plataforma, mas a efetividade varia dramaticamente por tipo de plataforma — efeitos de reputação entre plataformas são "muito mais compatíveis entre plataformas de e-commerce do que em outros tipos" [11]. Nem plataformas incumbentes nem entrantes têm incentivo para oferecer exportação de reputação: incumbentes tratam dados de reputação como fosso competitivo, e entrantes querem que usuários construam reputações do zero [12].

Isso espelha a era pré-FICO da avaliação de crédito, onde cada banco mantinha avaliações proprietárias de solvência sem portabilidade. Os marcos críticos de adoção do FICO — score de propósito geral (1989), disponibilidade em todas as três agências (1991), adoção por Fannie Mae/Freddie Mac (1995) — demonstram que portabilidade requer: (a) um padrão comum, (b) incorporação institucional e (c) efeitos de rede onde cada novo aderente torna o score mais valioso para todos os demais [4].

Para agentes, o problema de portabilidade é mais agudo do que para humanos. Um agente que constrói uma reputação forte em um marketplace (Virtuals Protocol, mais de 18.000 agentes [13]) não pode carregar essa reputação para outro (Solana Agent Registry [14], ClawHub [15]). Cada reinício de plataforma apaga o histórico do agente, criando fricção que suprime a mobilidade de agentes e a eficiência de mercado.

4.2 Pacotes de Reputação Portátil

O Pacote de Reputação Portátil (PRB) é uma Credencial Verificável W3C [3] contendo o resumo de reputação composta de um agente com links criptográficos para a evidência subjacente:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://absupport.ai/credentials/agent-reputation-bundle/v2"
  ],
  "type": ["VerifiableCredential", "AgentReputationBundle"],
  "issuer": {
    "id": "did:web:oracle.example.com",
    "name": "Example Reputation Oracle",
    "arp_reputation": {
      "reliability": 94,
      "confidence": 0.97
    }
  },
  "validFrom": "2026-03-26T00:00:00Z",
  "validUntil": "2026-04-26T00:00:00Z",
  "credentialSubject": {
    "id": "did:web:rated-agent.example.com",
    "reputationSummary": {
      "compositeScores": [
        {
          "profileId": "urn:absupport:arp:v2:profile:general-purpose",
          "value": 78.4,
          "confidence": 0.83,
          "ratingCount": 247,
          "uniqueRaters": 189,
          "windowDays": 365,
          "oldestRating": "2025-04-15T00:00:00Z"
        }
      ],
      "dimensions": {
        "reliability": {"mean": 82.3, "stddev": 11.2, "confidence": 0.87, "count": 247},
        "accuracy": {"mean": 88.1, "stddev": 8.7, "confidence": 0.89, "count": 241},
        "latency": {"mean": 71.4, "stddev": 15.3, "confidence": 0.84, "count": 230},
        "protocol_compliance": {"mean": 93.2, "stddev": 5.1, "confidence": 0.91, "count": 247},
        "cost_efficiency": {"mean": 79.8, "stddev": 9.4, "confidence": 0.86, "count": 239}
      },
      "provenance": {
        "cocChainAge": 312,
        "cocChainLength": 48721,
        "lastAnchorTimestamp": "2026-03-25T18:00:00Z",
        "anchorType": "dual_ots_tsa"
      },
      "behavioral": {
        "totalInteractions": 1847,
        "ratingParticipationRate": 0.89,
        "disputeRate": 0.003,
        "averageResponseTimeMs": 4200
      }
    },
    "evidenceChain": {
      "ratingsRootHash": "<raiz Merkle SHA-256 de todas as avaliações incluídas>",
      "cocChainHeadHash": "<SHA-256 da entrada mais recente da cadeia CoC do agente>",
      "verificationEndpoint": "https://oracle.example.com/verify/bundle/<bundle-id>"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "verificationMethod": "did:web:oracle.example.com#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z..."
  }
}

4.3 Emissão de Pacotes e Consenso Multi-Oráculo

Um único oráculo de reputação emitindo um PRB é um gargalo de confiança. Um oráculo malicioso poderia emitir pacotes inflacionados. O ARP v2 aborda isso por meio de atestação multi-oráculo:

Pacotes de oráculo único (mínimo viável): Um oráculo de reputação assina o pacote. A plataforma consumidora avalia a confiança com base na própria reputação ARP do oráculo. Adequado para interações de baixo risco.

Pacotes multi-oráculo (recomendado para alto risco): Múltiplos oráculos de reputação independentes co-assinam o pacote. O pacote inclui a computação independente de cada oráculo:

{
  "multiOracleAttestation": {
    "threshold": 3,
    "attestations": [
      {"oracle": "did:web:oracle-a.example.com", "compositeValue": 78.4, "signature": "z..."},
      {"oracle": "did:web:oracle-b.example.com", "compositeValue": 77.9, "signature": "z..."},
      {"oracle": "did:web:oracle-c.example.com", "compositeValue": 78.1, "signature": "z..."}
    ],
    "consensusValue": 78.1,
    "consensusMethod": "median",
    "maxDivergence": 2.3
  }
}

Detecção de divergência. Se as atestações de oráculos divergirem além de um limiar configurável (padrão: 10 pontos), o pacote é marcado como disputed e consumidores são alertados. Grande divergência indica manipulação de oráculo ou dados de reputação genuinamente ambíguos.

4.3.1 Problema de Inicialização de Oráculos

O modelo multi-oráculo pressupõe a existência de oráculos reputáveis — mas no lançamento do ecossistema, todos os oráculos começam com zero reputação ARP. Este é o problema "quem verifica os verificadores no tempo zero?".

Mecanismo de inicialização:

1. Designação de oráculos semente. A governança designa um conjunto inicial de oráculos semente (mínimo 5) com confiança provisória. Oráculos semente recebem uma flag bootstrap_trust em seu registro de identidade ARP com uma pontuação provisória de confiabilidade de 70 (o mínimo para status Nível 2 sob a governança v1). Esta confiança provisória não é conquistada — é concedida por voto de governança e explicitamente marcada como provisória em todos os PRBs emitidos durante o período de inicialização.

1. Conquista de reputação por agregação precisa. Oráculos semente conquistam reputação ARP genuína por meio de agregação precisa ao longo do tempo. "Precisa" é medida por: (a) baixa divergência de computações de oráculos pares sobre os mesmos agentes, (b) baixa taxa de PRBs disputados e (c) taxa de sucesso de verificação de prova Merkle (Seção 5.3). Após 90 dias, a flag bootstrap_trust é removida e a reputação do oráculo reflete seu desempenho real.

1. Período de carência para PRBs de oráculo único. Durante os primeiros 180 dias de operação do ecossistema (o "período de inicialização"), PRBs de oráculo único são aceitos com um desconto de confiança reduzido (0,7× em vez do 0,5× em estado estacionário para pacotes de oráculo único). Isso permite a adotantes iniciais emitir e consumir PRBs antes que o ecossistema multi-oráculo amadureça. Após o período de inicialização, pacotes multi-oráculo são exigidos para interações de alto risco.

1. Integração de novos oráculos (pós-inicialização). Após o período de inicialização, novos oráculos entram com zero reputação e devem conquistar confiança por meio do processo padrão de avaliação ARP — outros oráculos e agentes avaliam sua qualidade de agregação. Novos oráculos podem co-assinar pacotes multi-oráculo como participante não-limiar (sua atestação é incluída mas não contabilizada para o limiar mínimo) até que sua reputação exceda o limiar mínimo de oráculo (configurável, padrão: 60).

4.4 Agregação de Reputação Entre Plataformas

Quando um agente opera em múltiplas plataformas, ele acumula avaliações em cada contexto. A portabilidade requer agregar estas em um todo coerente sem contagem dupla ou permitir que mudanças de plataforma sirvam para escapar de reputação negativa.

Regras de agregação:

1. Deduplicação. Avaliações são identificadas por rating_id (UUID). Se a mesma avaliação aparece via múltiplos oráculos ou plataformas, é contada uma vez.

1. Ponderação por fonte. Avaliações de plataformas com verificação de interação mais forte (transações on-chain, registros de tarefas A2A) carregam peso maior do que avaliações de plataformas com verificação mais fraca (interações auto-reportadas). Isso é implementado via o campo verification_level da v1 Seção 4.8.

1. Alinhamento temporal. Todas as avaliações são normalizadas para a mesma janela móvel (padrão: 365 dias) independentemente da plataforma de origem.

1. Resolução de conflitos. Se um agente possui reputações dramaticamente diferentes em duas plataformas (ex.: 90 na Plataforma A, 40 na Plataforma B), o pacote agregado reporta detalhamentos por plataforma e o composto geral, permitindo que consumidores investiguem.

4.5 A Decisão da Plataforma Receptora

Uma plataforma receptora não é obrigada a aceitar um PRB pelo valor nominal. O protocolo especifica um modelo de desconto de confiança para reputação importada:

effective_score = imported_score × trust_discount(issuing_oracle, receiving_platform)

onde trust_discount é um valor entre 0,0 e 1,0 determinado por:

• A confiança da plataforma receptora no(s) oráculo(s) emissor(es)
• A sobreposição entre os domínios de origem e destino (reputação de revisão de código transferindo para revisão de código tem alto desconto; reputação de revisão de código transferindo para diagnóstico médico tem baixo desconto)
• A idade e volume das avaliações subjacentes

Sem aceitação obrigatória. Plataformas são livres para ignorar PRBs completamente e exigir que agentes construam reputação do zero. O protocolo fornece a infraestrutura para portabilidade, mas não pode forçar plataformas a honrar reputação portátil.

A lição de adoção do FICO. A comparação com o FICO é instrutiva mas corta para ambos os lados. O FICO alcançou ubiquidade não apenas por superioridade técnica, mas por funções forçantes institucionais: Fannie Mae e Freddie Mac passaram a exigir scores FICO para hipotecas conformes a partir de 1995, efetivamente obrigando a adoção por qualquer credor participante do mercado secundário de hipotecas [4, 39]. Sem essa função forçante, o FICO poderia ter permanecido como um entre muitos sistemas proprietários de scoring.

PRBs enfrentam o mesmo problema do ovo e da galinha: plataformas não adotarão reputação portátil até que agentes suficientes carreguem PRBs, e agentes não investirão em PRBs até que plataformas suficientes os aceitem. Três categorias de função forçante poderiam quebrar esse impasse:

1. Mandatos de agregadores de marketplace. À medida que marketplaces de agentes se consolidam (Virtuals Protocol [13], ClawHub [15], Solana Agent Registry [14]), plataformas agregadoras que listam agentes em múltiplos marketplaces têm incentivo natural para padronizar reputação — reduz seus próprios custos de curadoria. Se um grande agregador exigir PRBs para listagens premium, marketplaces participantes devem suportá-los. Isso é análogo a como a exigência do Google por dados estruturados (schema.org) impulsionou a adoção entre publicadores web sem mandatos governamentais.

2. Requisitos de seguro e responsabilidade. À medida que transações mediadas por agentes crescem em valor, provedores de seguro e clientes empresariais exigirão reputação verificável como condição de cobertura ou contratação. Uma empresa implantando um agente para tarefas acima de US$ 50.000 exigirá sinais de confiança auditáveis — PRBs fornecem isso. A especificação Agent Service Agreements [46] já define garantias de qualidade que referenciam scores ARP; subscrição de seguros baseada em scores compostos cria uma função forçante orientada pelo mercado.

3. Mandatos regulatórios (longo prazo). Os requisitos de transparência de IA do EU AI Act e a Iniciativa de Padrões para Agentes de IA do NIST [32] sinalizam interesse regulatório na responsabilização de agentes. Se reguladores exigirem reputação portátil e auditável para agentes operando em setores regulados (finanças, saúde, jurídico), PRBs se tornam infraestrutura de conformidade em vez de funcionalidades opcionais.

Estratégia de inicialização para adoção voluntária. Na ausência de funções forçantes, o ARP v2 persegue uma estratégia de inicialização: (a) uma implementação de referência de oráculo open-source (Apache 2.0) que reduz o custo de integração a quase zero, (b) integração com padrões já adotados (ERC-8004 [29], A2A [47], VCs W3C [3]) para que plataformas adotando esses padrões recebam suporte a PRB com trabalho adicional mínimo, e (c) incentivos para adotantes iniciais onde agentes portando PRBs recebem fricção de partida a frio reduzida (Seção 4.6), criando demanda do lado dos agentes que puxa plataformas em direção à aceitação.

Avaliação honesta. Sem pelo menos uma função forçante, PRBs são mais bem entendidos como infraestrutura para reputação portátil, pendente de adoção — não como um equivalente do FICO já alcançado. O padrão técnico é necessário mas não suficiente. O ARP v2 fornece o padrão; a economia de agentes deve fornecer a pressão de adoção. O protocolo é projetado para que, quando a função forçante chegar — seja de agregadores, seguradoras ou reguladores — a infraestrutura esteja pronta.

4.6 Portabilidade e o Problema de Partida a Frio

A portabilidade de sinais aborda diretamente o problema de partida a frio da v1 (v1 Seção 6.4). Um agente entrando em uma nova plataforma apresenta seu PRB como credencial de inicialização. Combinado com as quatro fontes de inicialização da v1 (atestação de identidade, aval de operador, acesso graduado, scoring consciente de incerteza), a reputação portátil fornece uma quinta fonte:

Fonte 5: Reputação Portátil. Um agente apresentando um PRB válido com confiança > 0,5 de um oráculo confiável pode entrar na plataforma receptora no Nível 1 (interações de risco médio) em vez do Nível 0 (somente baixo risco). O PRB não concede status Nível 2 ou Nível 3 — estes requerem avaliações conquistadas localmente. Isso equilibra o valor da reputação portátil contra o risco de inflação importada.

4.7 Riscos de Privacidade da Reputação Portátil

A portabilidade de sinais introduz uma superfície de ataque de correlação entre plataformas que a verificação de limiar por ZKP (Seção 5.4) e a divulgação seletiva por SD-JWT (Seção 10.3) não abordam completamente.

O problema de correlação. Quando um agente apresenta PRBs a múltiplas plataformas receptoras, seu DID funciona como chave de vinculação. Mesmo que o agente use identidades operacionais diferentes por plataforma, o DID do PRB as conecta. Isso possibilita:

1. Rastreamento entre plataformas. Plataformas que recebem PRBs podem correlacionar o DID do agente entre marketplaces, construindo um perfil de atividade entre plataformas — em quais plataformas o agente opera, quando entrou em cada uma e como sua reputação evolui entre contextos.

1. Vazamento de inteligência competitiva. A seção comportamental do PRB (totalInteractions, disputeRate, averageResponseTimeMs) constitui inteligência competitiva. Um operador de marketplace recebendo PRBs de muitos agentes pode reconstruir dinâmicas de mercado — volumes de interação, tempos de resposta e padrões de disputa em todo o ecossistema.

1. Desanonimização de operador. Se o DID do agente é vinculável ao seu operador (via resolução did:web, dados on-chain ERC-8004 ou alegações alsoKnownAs), os dados comportamentais se tornam pessoalmente atribuíveis. Isso tem implicações do Artigo 9 do GDPR se o operador estiver na UE e padrões comportamentais revelarem características sensíveis.

Abordagens de mitigação. O protocolo recomenda uma defesa em camadas:

a) DIDs pareados. Agentes DEVERIAM usar DIDs pareados ao apresentar PRBs a plataformas diferentes — um DID único por relacionamento com plataforma, conforme especificado no ecossistema Sovrin/Aries [41]. A reputação subjacente é vinculada a um DID raiz que nunca é apresentado diretamente; DIDs pareados são derivados do DID raiz usando uma derivação determinística mas não reversível.

b) Apresentação não-vinculável baseada em ZKP. Para cenários de alta privacidade, agentes PODEM usar o mecanismo ZKP (Seção 5.4) para provar "possuo um PRB válido que atende ao limiar X" sem revelar qual DID detém a reputação. A prova atesta a validade do PRB e conformidade com o limiar sem expor o identificador do sujeito da credencial. Isso requer estender o circuito ZKP para incluir ofuscação de DID — não trivial mas viável com frameworks ZKP existentes (a stack IDen3 do Polygon ID [16] demonstra esse padrão).

c) Divulgação comportamental seletiva. Agentes apresentando PRBs DEVERIAM usar SD-JWT (Seção 10.3) para divulgar apenas os dados comportamentais mínimos exigidos pela plataforma receptora. Uma plataforma que precisa apenas de verificação de score composto não deveria receber volumes de interação ou tempos de resposta.

Risco residual reconhecido. DIDs pareados previnem correlação ingênua mas não derrotam um adversário determinado que pode correlacionar impressões digitais comportamentais (um agente com exatamente 1.847 interações, taxa de disputa de 0,003 e tempo de resposta de 4.200 ms é provavelmente único entre plataformas independentemente do DID). Não-vinculabilidade total requer apresentação baseada em ZKP, que adiciona sobrecarga computacional (Seção 5.4). O protocolo deixa o trade-off privacidade/desempenho para o agente apresentador.

5. Verificação de Sinais

5.1 O Problema: Confiança sem Confiar

No ARP v1, verificar a reputação de um agente requer consultar um nó de agregação e confiar na resposta desse nó. O modelo de armazenamento distribuído (v1 Seção 4.3) permite verificação cruzada contra múltiplos nós, mas um consumidor deve ultimamente confiar em alguma combinação de nós. Não existe mecanismo para um agente provar sua reputação a um terceiro cético sem que esse terceiro conduza sua própria agregação.

O ARP v2 introduz três mecanismos de verificação de força crescente:

5.2 Verificação por Cadeia de Hash (Mínimo)

Toda avaliação ARP incorporada em uma cadeia CoC é protegida pela vinculação de hash SHA-256 da cadeia (v1 Seção 4.7). Um terceiro pode verificar:

1. A avaliação existe. Solicitar o registro de avaliação e verificar seu record_hash contra a cadeia CoC do avaliador.
2. A avaliação não foi modificada. A integridade da cadeia de hash garante que nenhuma entrada pode ser alterada sem quebrar todos os hashes subsequentes.
3. A avaliação foi registrada em um momento específico. A ancoragem de dupla camada do CoC v3 (OpenTimestamps + TSA RFC 3161) fornece verificação externa de carimbo de tempo [2].

Esta é a verificação mínima disponível para qualquer agente respaldado por CoC. Prova que avaliações individuais são genuínas, mas não verifica pontuações agregadas.

5.3 Verificação por Prova de Merkle (Padrão)

PRBs incluem um ratingsRootHash — a raiz Merkle de todas as avaliações incluídas na computação do pacote. Um verificador pode:

1. Solicitar a árvore de Merkle completa ao oráculo emissor
2. Verificar que cada folha corresponde a uma avaliação genuína (via verificação por cadeia de hash)
3. Recomputar o agregado a partir das avaliações verificadas
4. Confirmar que o agregado recomputado corresponde ao valor declarado no pacote

Custo. Verificação completa de Merkle requer baixar e recomputar sobre todas as avaliações incluídas. Com 247 avaliações, isso é trivial. Com mais de 10.000 avaliações, é computacionalmente não trivial. O protocolo suporta verificação por amostragem: um verificador solicita um subconjunto aleatório de provas de Merkle (padrão: 50 avaliações), verifica essas, e aceita o pacote com uma confiança proporcional ao tamanho da amostra.

5.4 Verificação de Limiar por Conhecimento Zero (Preservação de Privacidade)

Para cenários onde um agente precisa provar que sua reputação atende a um limiar sem revelar pontuações exatas, o ARP v2 integra provas de conhecimento zero:

Caso de uso. Um agente candidatando-se a uma tarefa de alto risco precisa provar "minha pontuação composta de propósito geral excede 80 e minha dimensão de confiabilidade excede 85" sem revelar que suas pontuações reais são 83,7 e 88,2.

Protocolo:

1. Provador (agente) possui:
   - PRB com compositeScore = 83.7
   - PRB com reliability = 88.2
   - Prova de Merkle vinculando ambos os valores ao ratingsRootHash

2. Provador gera prova ZK:
   π = ZKProof(
     public_inputs: {threshold_composite: 80, threshold_reliability: 85, ratingsRootHash: "..."},
     private_inputs: {compositeScore: 83.7, reliability: 88.2, merkle_path: [...]}
   )

3. Verificador confere:
   Verify(π, public_inputs) → true/false

Seleção de sistema ZKP. O protocolo não impõe um sistema ZKP específico. Implementações PODEM usar:

• Groth16 — menor tamanho de prova (~200 bytes), setup confiável necessário, verificação mais rápida
• PLONK — setup confiável universal, tamanho de prova moderado, amplamente suportado
• STARKs — sem setup confiável, provas maiores, resistente a computação quântica

A escolha depende de restrições de implantação. Verificação on-chain (contextos ERC-8004) se beneficia do pequeno tamanho de prova do Groth16. Verificação off-chain pode tolerar provas STARK maiores pelo benefício de não requerer setup confiável.

Implementações existentes. Vários projetos demonstraram verificação de reputação baseada em ZKP em produção ou quase-produção: Polygon ID (stack IDen3) para verificação de credenciais com preservação de privacidade [16], ZK Email Stamp para provar humanidade por recibos de e-commerce [17] e Lookout Agent Trust Intelligence para scoring comportamental on-chain verificado por ZK [18]. O OpenRank utiliza sistemas de prova ZK para computações verificáveis em grafos [19]. Estes demonstram que a infraestrutura criptográfica para reputação ZKP é operacional, não teórica.

Limitação reconhecida. Verificação ZKP adiciona sobrecarga computacional. A geração de provas Groth16 leva de 2 a 10 segundos em hardware comum para circuitos da complexidade exigida aqui. Isso é aceitável para interações de alto risco mas proibitivo para verificações de reputação em tempo real e alta frequência. O protocolo recomenda verificação ZKP para interações acima de um limiar de valor configurável (padrão: equivalente a US$ 100) e recorre à verificação por prova de Merkle ou cadeia de hash para interações de menor risco.

5.5 Níveis de Verificação

O ARP v2 define três níveis de verificação com propriedades de segurança explícitas:

6. Arquitetura Anti-Goodhart

6.1 O Problema: Métricas Publicadas se Tornam Alvos de Manipulação

A formulação de Charles Goodhart de 1975: "Qualquer regularidade estatística observada tenderá a colapsar uma vez que pressão seja exercida sobre ela para fins de controle" [20]. Em sistemas de reputação, isso se manifesta como: uma vez que um score é publicado e vinculado a recompensas, atores otimizam para o score em vez da qualidade subjacente que ele mede.

Falhas de Goodhart documentadas em scoring:

• Índice H acadêmico: Anéis de citação inflam artificialmente métricas, com publicações "salami" otimizando quantidade em vez de substância [21]
• Avaliações Amazon: Estima-se que US$ 152 bilhões em compras anuais são influenciados por avaliações falsas — fábricas de avaliações otimizam ratings como negócio [22, 22a]
• Ratings Uber/Lyft: Rating médio de 4,7-4,8/5 representa inflação impulsionada por limiares de desativação — o score mede "evitação de punição" em vez de "qualidade do serviço" [23, 23a]
• Scores de crédito FICO: Otimização de histórico limitado (abrir cartões de crédito para construir score sem necessidade genuína de crédito) manipula a fórmula sem melhorar a saúde financeira [8]

O ARP v1 abordou isso parcialmente por meio de seu princípio de design "consultável mas não navegável" (v1 Seção 3.1, Princípio 6). A v1 reconheceu que isso é inaplicável na prática — qualquer agente pode consultar todos os scores e construir um ranking. O ARP v2 substitui o princípio inaplicável por uma arquitetura de defesa sistemática.

6.2 Estratificação de Sinais

A defesa primária: nem todos os sinais são igualmente visíveis.

Nível Público (P). Sinais que qualquer agente pode consultar livremente. Estas são as métricas "de destaque". São as mais propensas a serem manipuladas e, portanto, as menos informativas para decisões de alto risco. Sinais públicos servem como filtros iniciais, não como árbitros finais.

Exemplos: idade operacional, contagem total de interações, nível de classificação (0/1/2/3), afiliações a plataformas.

Nível Consultável (Q). Sinais disponíveis mediante solicitação com limitação de taxa e controles de acesso. Um agente solicitante deve ter uma identidade válida e a consulta é registrada. Sinais consultáveis não são secretos — são acessíveis com esforço — mas a fricção de consultas com taxa limitada previne scraping em massa para construção de rankings.

Exemplos: scores compostos, médias por dimensão, níveis de confiança, volume de avaliações.

Limites de taxa: padrão de 100 consultas/dia por agente solicitante, configurável pelo agente consultado. Consultas excedendo o limite retornam HTTP 429 com cabeçalho Retry-After.

Nível Privado (R). Sinais usados apenas para computação interna por oráculos de reputação e mecanismos anti-manipulação do protocolo. Nunca expostos a consultas externas. Sinais privados incluem as métricas-sombra (Seção 6.4), scores de calibração por avaliador, flags de detecção de conluio e os parâmetros exatos de rotação de métricas.

A atribuição de nível é gerenciada por governança. O mapa de níveis padrão:

6.3 Rotação de Métricas

Pesos estáticos são alvos de otimização. Se agentes sabem que confiabilidade é ponderada em 25% e precisão em 25%, podem alocar recursos para maximizar exatamente essas dimensões em detrimento das demais.

Mecanismo de rotação. Cada perfil de peso especifica um cronograma de rotação (trimestral por padrão). Em cada fronteira de rotação:

1. O sistema de governança (ou o proprietário do perfil personalizado) seleciona novos pesos dentro dos limites publicados
2. O anúncio de rotação é publicado: "Pesos para o perfil de propósito geral foram atualizados em 01/04/2026"
3. Os novos pesos entram em vigor imediatamente para futuras computações de compostos
4. Compostos históricos NÃO são recomputados retroativamente — usaram os pesos vigentes quando foram computados

Limites publicados. A rotação não permite mudanças de peso arbitrárias. Cada perfil de peso especifica limites min/max por sinal:

{
  "signal_id": "arp:reliability:weighted_mean",
  "weight_bounds": {"min": 0.15, "max": 0.35},
  "current_weight": "ROTATED"
}

Agentes sabem que confiabilidade é ponderada entre 15% e 35%, mas não onde dentro dessa faixa. Para manipular efetivamente, um agente precisaria otimizar em toda a faixa de limites — o que significa genuinamente se destacar na dimensão em vez de otimizar estreitamente para um peso conhecido.

Frequência de rotação vs. estabilidade. Rotação mais frequente fornece proteção anti-Goodhart mais forte, mas reduz a previsibilidade que agentes precisam para alocação racional de recursos. A rotação trimestral padrão equilibra essas tensões. A governança PODE votar para aumentar a frequência (mensal) ou diminuí-la (semestral) com base nos níveis observados de manipulação.

Limitação reconhecida. Rotação defende contra otimização estática mas não contra otimização adaptativa. Um agente que pode inferir pesos atuais a partir de mudanças observadas no score (submetendo interações-sonda e medindo respostas compostas) pode parcialmente fazer engenharia reversa da rotação. Defesa: (a) limitação de taxa em consultas compostas por agente (Seção 6.2) limita a largura de banda de sondagem, e (b) adição de ruído calibrado a respostas compostas (Seção 6.5) reduz a precisão de inferência.

6.4 Métricas-Sombra

Para cada sinal público ou consultável, o protocolo mantém uma ou mais métricas-sombra privadas que detectam divergência entre a métrica otimizada e a qualidade subjacente:

Computação de métricas-sombra. Oráculos de reputação computam métricas-sombra como parte de seu pipeline de agregação. Valores de métricas-sombra nunca são expostos via API. São usados internamente para:

1. Sinalizar anomalias. Se uma métrica primária e sua métrica-sombra divergem além de um limiar (configurável, padrão: 2 desvios padrão), o agente é sinalizado para monitoramento aprimorado.
2. Ajustar confiança. Agentes sinalizados têm a confiança de seu score composto reduzida por um fator configurável por governança (padrão: 0,8×), sinalizando a consumidores que o score pode ser menos confiável.
3. Acionar revisão. Divergência persistente (>30 dias) aciona uma proposta de revisão por governança.

Verificação de integridade de métricas-sombra. Métricas-sombra são privadas por design, mas isso cria uma lacuna de confiança: um oráculo conluiado pode simplesmente não computar métricas-sombra para um agente favorecido, ou computá-las e ignorar as flags de anomalia. O protocolo aborda isso por meio de um mecanismo de auditoria baseado em hash:

1. Provas de computação. Em cada ciclo de agregação, cada oráculo publica um shadow_metric_commitment — o hash SHA-256 de seus resultados de computação de métricas-sombra para todos os agentes naquele ciclo. O hash prova que a computação ocorreu sem revelar os valores.

1. Protocolo de auditoria por pares. Oráculos pares PODEM solicitar uma auditoria de métricas-sombra para um agente específico. O oráculo auditado revela os valores de métricas-sombra daquele agente (criptografados para a chave pública do oráculo solicitante). O oráculo solicitante verifica: (a) os valores revelados produzem hash consistente com um subconjunto do compromisso publicado, e (b) os valores são plausíveis dados os sinais de nível público do agente.

1. Frequência de auditoria. A governança define uma frequência mínima de auditoria (padrão: cada oráculo é auditado por pelo menos 2 pares por trimestre). Oráculos que recusam auditorias ou cujos valores revelados falham na verificação são sinalizados — seu score de confiabilidade ARP é penalizado e suas atestações de PRB carregam peso de confiança reduzido.

Risco residual. Um oráculo conluiado pode computar métricas-sombra corretamente mas ignorar as flags de anomalia em sua agregação. A auditoria prova computação, não ação. Defesa: atestação multi-oráculo (Seção 4.3) limita o impacto da supressão de qualquer oráculo individual, pois outros oráculos computando independentemente detectarão anomalias que o oráculo conluiado ignora.

6.5 Privacidade Diferencial para Respostas de Agregação

Para prevenir ataques de inferência de score (sondar o sistema para fazer engenharia reversa de pesos de rotação ou métricas-sombra), nós de agregação PODEM adicionar ruído Laplace calibrado a respostas de score composto:

noisy_composite = true_composite + Laplace(0, sensitivity/epsilon)

onde sensitivity é a mudança máxima no composto a partir de uma única avaliação (limitada pela fórmula de peso) e epsilon é o parâmetro de privacidade (configurável por governança, padrão: 1,0).

Com epsilon = 1,0, a magnitude esperada de ruído é aproximadamente ±2 pontos em uma escala de 100 pontos. Isso é pequeno o suficiente para não afetar materialmente decisões de confiança, mas grande o suficiente para prevenir inferência precisa de score a partir de consultas repetidas.

Trade-off reconhecido. Privacidade diferencial introduz ruído que, por definição, torna o score menos preciso para o agente consultante. O protocolo recomenda privacidade diferencial apenas para o nível consultável — agentes com histórico de interação bilateral direta podem acessar scores sem ruído via o caminho de verificação de Merkle (Seção 5.3). Isso significa que agentes com experiência direta obtêm o sinal completo, enquanto observadores terceiros obtêm uma versão com leve ruído.

6.6 Resistência Multidimensional à Manipulação

Uma percepção-chave da literatura anti-Goodhart [24, 25]: quanto mais dimensões independentes um score compõe, mais difícil é manipular todas simultaneamente. Formalmente, se manipular a dimensão d custa c_d e as dimensões são independentes, o custo total de manipular k de n dimensões é pelo menos Σ c_d para as k dimensões mais baratas.

A composição do ARP v2 sobre 7+ sinais (cinco dimensões de avaliação, idade operacional, sinais comportamentais) significa que um agente buscando inflar seu composto deve:

1. Inflar todas as cinco dimensões de avaliação (requer avaliadores Sybil ou anéis de conluio — custoso conforme v1 Seções 6.1-6.2)
2. Acumular idade operacional genuína (requer tempo, não pode ser falsificada)
3. Manter alta taxa de participação em avaliações (requer interações genuínas)

O custo de manipular simultaneamente todos os inputs excede o benefício para qualquer função de retorno plausível. Esta não é uma prova de impossibilidade — um atacante suficientemente financiado pode manipular qualquer sistema — mas eleva o custo ao ponto em que prestação legítima de serviço é mais barata que manipulação para a vasta maioria dos agentes. A fundamentação teórica para este argumento de custo de manipulação, baseada na teoria de sinalização de Spence e no modelo de trade-off que substituiu o Princípio da Desvantagem, é desenvolvida no Apêndice A.

7. Análise de Segurança das Novas Capacidades

Esta seção analisa ataques específicos às novas capacidades da v2. Ataques ao protocolo base (Sybil, conluio, griefing, partida a frio) são analisados na v1 Seção 6 e permanecem inalterados.

7.1 Manipulação de Composição

Ataque. Um agente elabora seu padrão de interação para maximizar o score composto sob um perfil de peso específico — aceitando apenas tarefas onde pode pontuar alto nas dimensões mais pesadamente ponderadas e recusando tarefas onde poderia pontuar mal.

Detecção. A métrica-sombra "razão de complexidade da tarefa" (Seção 6.4) detecta seleção enviesada: um agente com distribuição de tarefas estreita em relação às suas capacidades declaradas é sinalizado. O sinal comportamental "taxa de recusa de interação" (percentual de interações oferecidas que o agente recusa) é uma métrica de nível consultável que consumidores podem verificar.

Mitigação. Rotação de métricas (Seção 6.3) significa que a dimensão mais pesadamente ponderada muda periodicamente. Um agente que seleciona tarefas focadas em confiabilidade terá desempenho fraco quando a rotação enfatizar precisão ou latência.

7.2 Conluio de Oráculos

Ataque. Múltiplos oráculos de reputação fazem conluio para emitir PRBs inflados para agentes favorecidos.

Detecção. Atestação multi-oráculo (Seção 4.3) revela divergência entre oráculos. Se três oráculos concordam em 78 mas um quarto alega 95, a flag de divergência identifica o outlier. Oráculos cujas atestações divergem consistentemente da mediana são sinalizados pelos próprios mecanismos anti-inflação do protocolo (pois oráculos são agentes com reputações ARP).

Mitigação. Plataformas consumidoras DEVERIAM exigir pacotes multi-oráculo para decisões de alto risco. O modelo de desconto de confiança (Seção 4.5) significa que mesmo que um pacote inflado seja aceito, seu score efetivo é descontado pela confiança da plataforma no oráculo emissor. Um oráculo com histórico de atestações divergentes acumula scores baixos de confiabilidade, reduzindo o desconto aplicado a seus pacotes.

Risco residual. Se a maioria dos oráculos em um pacote multi-oráculo faz conluio, o próprio mecanismo de consenso é corrompido. A defesa requer diversidade de oráculos — o protocolo recomenda que plataformas exijam atestações de oráculos operados por entidades diferentes em jurisdições diferentes.

7.3 Lavagem de Reputação Portátil

Ataque. Um agente com reputação ruim na Plataforma A tenta usar um PRB da Plataforma B (onde tem boa reputação) para obter um recomeço na Plataforma A.

Detecção. PRBs incluem o DID do agente. Se o adaptador de identidade da Plataforma A pode vincular o DID do agente apresentador a uma identidade local existente, a plataforma detecta a tentativa de reentrada.

Mitigação. Plataformas DEVERIAM cruzar referências de apresentadores de PRB contra registros de reputação local existentes. Um agente apresentando um PRB enquanto possui reputação local tem ambos os registros visíveis — a plataforma pode aplicar o menor dos dois, ou sinalizar a discrepância para revisão.

Limitação. Se o agente usa um DID diferente em cada plataforma e não há vinculação de identidade entre plataformas, a lavagem de reputação é possível. Esta é uma limitação inerente de qualquer sistema que permite identidades pseudônimas. A defesa é fortalecer a vinculação de identidade (alegações W3C DID alsoKnownAs, registros cross-chain ERC-8004) em vez de restringir a portabilidade.

7.4 Ataques de Repetição de ZKP

Ataque. Um agente gera uma prova ZKP válida ("meu score excede 80") no tempo T quando seu score era 82. No tempo T+30 dias, seu score caiu para 65, mas apresenta a prova antiga.

Detecção. Provas ZKP incluem um ratingsRootHash que é específico ao estado pontual do histórico de avaliações do agente. Um verificador pode checar se o ratingsRootHash corresponde a um estado recente (dentro da janela de validade).

Mitigação. Provas incluem um carimbo de tempo validUntil. Verificadores DEVEM rejeitar provas expiradas. Validade padrão de prova: 7 dias (correspondendo à validade do PRB). Para interações de alto risco, verificadores PODEM exigir geração de prova em tempo real (o agente gera uma prova nova durante a negociação da interação).

7.5 Inferência de Perfil de Peso

Ataque. Um agente submete interações-sonda projetadas para revelar os pesos de rotação atuais — ex.: desempenhar deliberadamente bem em uma dimensão e mal em outras, depois observar a mudança no score composto para inferir o peso da dimensão.

Detecção. Padrões de interação anômalos (desempenho altamente variável entre dimensões em um padrão inconsistente com variação genuína de capacidade) são sinalizados por métricas-sombra.

Mitigação. Privacidade diferencial em respostas compostas (Seção 6.5) adiciona ruído que previne inferência precisa de peso. Limitação de taxa em consultas compostas (Seção 6.2) limita o número de ciclos de sondagem-e-observação. A combinação significa que um atacante precisa de muitas interações e muitas consultas para estreitar estimativas de peso — e mesmo assim, o piso de ruído previne inferência exata.

Limite quantitativo (agente único). Com privacidade diferencial epsilon = 1,0 e limite de taxa de 100 consultas/dia, um atacante único pode estreitar uma estimativa de peso para ±5% do valor verdadeiro após aproximadamente 30 dias de sondagem sustentada. A essa altura, a rotação trimestral pode ter mudado os pesos. Isso torna a inferência sustentada de peso impraticável para a maioria dos atacantes individuais.

Sondagem por coalizão (ameaça distinta). Uma coalizão de N agentes compartilhando resultados de sondagem pode estreitar estimativas de peso N vezes mais rápido. 10 agentes conluiados alcançam precisão de ±5% em ~3 dias. 100 agentes coletivamente emitem 10.000 consultas/dia, e o ruído de privacidade diferencial se anula sobre suas amostras agrupadas — degradando significativamente a garantia efetiva de privacidade.

Defesas contra coalizão:

1. Ruído correlacionado por agente. Em vez de ruído Laplace independente por consulta, o protocolo PODE usar sementes de ruído específicas por agente: cada agente recebe ruído extraído de uma sequência pseudoaleatória por agente. Consultas repetidas do mesmo agente recebem ruído correlacionado, então agrupar múltiplas consultas de um agente fornece retornos decrescentes. Membros da coalizão com sementes diferentes ainda se beneficiam do agrupamento, mas isso elimina o ataque de média mais simples.

1. Monitoramento global de taxa de consultas. Nós de agregação DEVERIAM monitorar o volume total de consultas entre todos os agentes, não apenas taxas por agente. Um pico repentino em consultas de score composto para o mesmo agente-alvo de muitos agentes diferentes é um sinal de sondagem por coalizão. Quando detectado, o nó aumenta a magnitude do ruído para consultas direcionadas àquele agente (epsilon adaptativo).

1. Limite quantitativo ajustado. Para uma coalizão de tamanho N com ruído correlacionado por agente, a taxa efetiva de sondagem é O(N) (uma consulta útil por agente por dia, não 100). Uma coalizão de 100 agentes estreita estimativas de peso para ±5% em aproximadamente 30/100 × 30 ≈ 9 dias com a taxa efetiva de uma consulta por agente por dia. Com epsilon adaptativo acionado por detecção de anomalia, isso se estende ainda mais. O limite é mais fraco que o caso de agente único mas permanece praticamente defensável para coalizões abaixo de ~50 agentes.

Limitação reconhecida. Uma coalizão suficientemente grande (>100 agentes) com sondagem paciente de baixa frequência que evita acionar detecção de anomalia pode eventualmente inferir pesos de rotação. A defesa última é a própria rotação: mesmo conhecimento perfeito de pesos se torna obsoleto em cada fronteira de rotação. O protocolo aceita este risco residual como o custo de manter sinais de reputação consultáveis.

8. Migração da v1 para a v2

8.1 Retrocompatibilidade

O ARP v2 é projetado para adoção incremental:

Agentes v1 e v2 coexistem na mesma rede. A v2 não quebra nenhuma funcionalidade da v1.

8.2 Caminho de Atualização do Nó de Agregação

Nós de agregação atualizando para v2 devem:

1. Aceitar registros de avaliação v1 e v2. Registros v1 são tratados como registros v2 com v2_extensions: null.
2. Implementar motor de composição. Computar sinais compostos a partir de dados de avaliação v1 existentes usando a álgebra de composição (Seção 3.3).
3. Emitir PRBs. Assinar Pacotes de Reputação Portátil usando o DID do nó.
4. Implementar estratificação de sinais. Classificar APIs existentes em níveis público/consultável/privado.
5. Implementar rotação de métricas. Aplicar rotação trimestral de pesos a perfis padrão.

Recomendação de cronograma de migração:

8.3 Atualização do Esquema do Registro de Avaliação

O esquema v2 estende a v1 com campos opcionais:

{
  "version": 2,
  "rating_id": "<UUID-v4>",
  "timestamp": "<ISO-8601-UTC>",
  "interaction_id": "<UUID-v4>",
  "rater": { "agent_id": "<DID>", "identity_proof": "<ref>" },
  "ratee": { "agent_id": "<DID>", "identity_proof": "<ref>" },
  "dimensions": {
    "reliability": 85, "accuracy": 92, "latency": 78,
    "protocol_compliance": 95, "cost_efficiency": 88
  },
  "interaction_evidence": {
    "task_type": "code_review",
    "outcome_hash": "<SHA-256>",
    "duration_ms": 4200,
    "was_completed": true
  },
  "metadata": {
    "rater_chain_length": 48721,
    "rater_chain_age_days": 312,
    "rater_total_ratings_given": 1847,
    "bilateral_blind": true
  },
  "v2_extensions": {
    "signal_tier_preferences": {
      "composite_score": "queryable",
      "dimensional_scores": "queryable"
    },
    "portable_bundle_consent": true,
    "verification_support": ["hash_chain", "merkle_proof"]
  },
  "record_hash": "<SHA-256 do registro canonicalizado por JCS>"
}

Todos os campos v2_extensions são opcionais. Um registro com "version": 2 e sem v2_extensions é equivalente a um registro v1.

8.4 Transição de Governança

A atualização v1-para-v2 segue o processo de governança especificado na v1 Seção 5.4:

1. Proposta. Uma proposta de atualização v2 requer 20% do GovWeight total para ser proposta.
2. Votação. Supermaioria de 75% exigida, com período de carência de 30 dias.
3. Ativação. Após aprovação por governança, inicia-se um período de transição de 90 dias durante o qual v1 e v2 operam em paralelo.
4. Depreciação. Funcionalidades exclusivas da v1 são depreciadas 365 dias após a ativação da v2 (conforme política de depreciação da v1 Seção 9.2). Registros de avaliação v1 nunca são depreciados — apenas comportamentos de protocolo específicos da v1.

8.5 Análise de Escalabilidade

O ARP v2 introduz quatro operações computacionalmente significativas não presentes na v1. Esta seção fornece estimativas de ordem de grandeza para implementadores.

Motor de composição. Computar compostos sobre 7 sinais para N agentes requer O(N × 7) operações aritméticas por ciclo de agregação. Com 10 mil agentes: ~70 mil operações — trivial (sub-segundo em hardware comum). Com 100 mil agentes: ~700 mil operações — ainda trivial. Com 1 milhão de agentes com rotação trimestral acionando recomputação total: ~7 milhões de operações — completa em segundos em um único núcleo. A composição é embaraçosamente paralela entre agentes. Veredicto: não é gargalo em qualquer escala previsível.

Construção de árvore de Merkle. Construir árvores de Merkle sobre todas as avaliações para emissão de PRB requer O(n × log n) operações de hash onde n = avaliações por agente.

No nível por agente, árvores de Merkle são eficientes mesmo com altos volumes de avaliação. O custo sistêmico de construir árvores para todos os agentes durante um ciclo de emissão de PRB em lote escala linearmente: 100 mil agentes × 10 ms em média = ~17 minutos em um único núcleo, paralelizável para segundos em múltiplos núcleos. Veredicto: gerenciável com paralelização padrão.

Geração de provas ZKP. O protocolo estima 2-10 segundos por prova em hardware comum para circuitos Groth16 da complexidade exigida. Para um evento de entrada em massa onde 1.000 agentes precisam simultaneamente de provas ZKP:

Com 1.000+ agentes simultâneos, a geração de ZKP se torna gargalo para oráculos únicos. Mitigações: (a) geração de prova é delegada ao agente, não ao oráculo — agentes geram suas próprias provas a partir de seus dados de PRB, distribuindo computação pela rede; (b) cache de provas — uma prova permanece válida pela janela de validade do PRB (7 dias), então provas são geradas uma vez e reutilizadas; (c) fallback para verificação de Merkle para interações de menor risco durante picos de demanda. Veredicto: gerenciável com cache de provas e geração no lado do agente; risco de gargalo com >1 mil solicitações simultâneas de prova a um único oráculo.

Pipeline de métricas-sombra. Computar métricas-sombra adiciona uma métrica adicional por métrica primária por agente por ciclo de agregação. Com 6 métricas primárias e 100 mil agentes: 600 mil computações adicionais. Métricas-sombra envolvem cálculos levemente mais complexos que a composição (ex.: variância de 30/90/180 dias, consultas de taxa de interação repetida) mas permanecem O(N × métricas). Sobrecarga estimada: 2-5× o custo do motor de composição, ou 5-15 segundos para 100 mil agentes em um único núcleo. Veredicto: sobrecarga modesta, bem dentro dos orçamentos computacionais de oráculos.

Calibração de ruído de privacidade diferencial. O cálculo de sensibilidade por consulta requer conhecer o impacto máximo de uma única avaliação no composto. Para um perfil de peso fixo, isso é uma constante computada uma vez por período de rotação: max_sensitivity = max(weight_i / sample_size_i) entre todos os sinais de entrada. A extração de ruído por consulta (amostragem Laplace) é O(1). Veredicto: sobrecarga negligenciável.

9. Cenário Competitivo Atualizado

Desde a publicação do ARP v1, vários novos sistemas surgiram ou evoluíram. Esta seção atualiza a análise competitiva.

9.1 Novos Entrantes Desde a v1

9.2 Matriz de Comparação Atualizada

9.3 Contribuições Únicas do ARP v2

Nenhum sistema pesquisado fornece a combinação de:

1. Álgebra de composição aberta com perfis configuráveis. PayCrow e Lookout compõem sinais mas com fórmulas fixas e proprietárias. A álgebra do ARP v2 é aberta e extensível, com perfis específicos por domínio.

1. Portabilidade baseada em padrões via VCs W3C. A maioria dos sistemas fornece reputação dentro de sua própria cadeia/plataforma. O ARP v2 usa Credenciais Verificáveis W3C — um Padrão W3C desde maio de 2025 [3] — para transferência de reputação interoperável.

1. Verificação multinível incluindo ZKP. Lookout e OpenRank suportam verificação ZKP, mas nenhum combina isso com verificação por cadeia de hash e prova de Merkle em um modelo em camadas.

1. Arquitetura anti-Goodhart sistemática. Nenhum sistema pesquisado especifica estratificação de sinais, rotação de métricas ou métricas-sombra. A proteção anti-manipulação em sistemas existentes depende de staking/slashing (VOUCH, EigenLayer) ou análise de grafo social (OpenRank, Nostr WoT), não de defesa sistemática contra otimização de métricas publicadas.

1. Avaliação bilateral cega como base. A avaliação cega por compromisso-revelação do ARP, herdada da v1, permanece única entre sistemas de reputação de agentes. Todos os competidores pesquisados usam mecanismos de avaliação unilateral ou pública.

Avaliação honesta. O cenário competitivo está convergindo rapidamente. A rodada seed de US$ 5M da t54 Labs e a participação da Franklin Templeton sinalizam interesse institucional em scoring de crédito para agentes. As provas ZK de grafos do OpenRank são tecnicamente sofisticadas. Os ~24.000 agentes registrados no ERC-8004 fornecem o maior conjunto de dados on-chain. A vantagem do ARP v2 está em fornecer uma especificação completa, coerente e aberta — mas um competidor bem financiado poderia construir funcionalidade equivalente compondo componentes existentes (ERC-8004 + OpenRank + ZKP personalizado + anti-Goodhart personalizado). Nosso fosso é a coerência da especificação e o licenciamento Apache 2.0, não qualquer componente técnico individual.

10. Atualizações de Integração

10.1 Integração ERC-8004 (Atualizada)

A integração ERC-8004 da v1 (v1 Seção 7.1) mapeou cinco dimensões ARP para chamadas giveFeedback. A v2 estende isso:

Armazenamento de sinais compostos. Scores compostos são armazenados via um novo par de tags:

giveFeedback(agentId, 7840, 2, "arp_composite", "general_purpose", feedbackURI, feedbackHash, ...)

O feedbackURI aponta para o PRB completo (Pacote de Reputação Portátil) armazenado off-chain, permitindo que qualquer consumidor ERC-8004 recupere o detalhamento completo.

Ancoragem de hash do PRB. O feedbackHash da entrada de sinal composto é o SHA-256 da representação JSON Canonicalization Scheme do PRB, fornecendo evidência de adulteração on-chain para o pacote portátil.

10.2 Extensão A2A Agent Card (Atualizada)

A extensão A2A da v1 (v1 Seção 7.2) declarava suporte ao protocolo de avaliação. A v2 adiciona:

{
  "capabilities": {
    "extensions": [{
      "uri": "urn:absupport:agent-rating:v2",
      "description": "ARP v2: rating, composition, portability, verification",
      "required": false,
      "params": {
        "ratingVersion": "2.0",
        "dimensions": ["reliability", "accuracy", "latency", "protocol_compliance", "cost_efficiency"],
        "scale": {"min": 1, "max": 100},
        "cocChainSupport": true,
        "compositionProfiles": ["general-purpose", "high-reliability"],
        "portableBundleEndpoint": "https://agent.example.com/reputation/bundle",
        "verificationSupport": ["hash_chain", "merkle_proof", "zkp_threshold"],
        "antiGoodhartCompliant": true
      }
    }]
  }
}

Agentes descobrem pares com capacidade v2 filtrando por urn:absupport:agent-rating:v2. Agentes v2 DEVERIAM também declarar urn:absupport:agent-rating:v1 para retrocompatibilidade.

10.3 Integração W3C VC (Estendida)

A v1 definiu AgentRatingCredential e AgentReputationSummaryCredential (v1 Seção 7.3). A v2 adiciona:

AgentReputationBundle — o PRB como VerifiableCredential (esquema completo na Seção 4.2).

Divulgação seletiva via SD-JWT. A v1 mencionou SD-JWT para provas de limiar como trabalho futuro. A v2 especifica:

{
  "type": ["VerifiableCredential", "AgentReputationBundle"],
  "credentialSubject": {
    "id": "did:web:agent.example.com",
    "_sd": ["reputationSummary"]
  },
  "_sd_alg": "sha-256",
  "disclosures": [
    {"salt": "...", "claim": "compositeScores[0].value", "value": 78.4}
  ]
}

Um agente apresenta apenas as divulgações necessárias: "meu score composto" sem revelar detalhamentos por dimensão, ou "meu score de confiabilidade" sem revelar eficiência de custo. Isso é mais simples que ZKP completo (Seção 5.4), mas fornece menos privacidade — o valor exato é revelado, apenas seletivamente.

10.4 Alinhamento com Mastercard Verifiable Intent

A especificação Verifiable Intent da Mastercard (março de 2026) vincula "identidade, intenção e ação em um único registro preservador de privacidade" usando divulgação seletiva construída sobre especificações FIDO/EMVCo/IETF/W3C [31]. Os PRBs do ARP v2 são estruturalmente compatíveis: um PRB pode servir como o componente de "identidade" de um registro Verifiable Intent, vinculando reputação a uma intenção de transação específica.

Esse alinhamento é notável porque o Verifiable Intent da Mastercard tem o apoio de Google, Fiserv e IBM, sugerindo que a infraestrutura de padrões sobre a qual o ARP v2 se constrói (VCs W3C, DIDs, divulgação seletiva) possui impulso institucional além da economia de agentes.

10.5 Alinhamento com a Iniciativa de Padrões para Agentes de IA do NIST

A Iniciativa de Padrões para Agentes de IA do NIST (fevereiro de 2026) estabeleceu três pilares: padrões liderados pela indústria, protocolos open source liderados pela comunidade e pesquisa em segurança/identidade de agentes [32]. A especificação aberta do ARP v2 (Apache 2.0) e o design baseado em padrões (VCs W3C, ERC-8004, A2A) o posicionam como candidato para adoção comunitária do NIST no pilar de reputação/confiança.

11. Trabalhos Futuros

11.1 Mantidos da v1

Os seguintes problemas não resolvidos da v1 Seção 9.1 permanecem em aberto:

• Silos de reputação entre domínios — avaliações etiquetadas por domínio com filtragem específica por domínio
• Oráculos de verdade-base para todas as dimensões — melhorar o embasamento em resultados para conformidade de protocolo e eficiência de custo
• Defesa contra ML adversarial — testes red-team contra agentes de manipulação especificamente projetados
• Prova formal de teoria dos jogos — matrizes de retorno explícitas e argumentos de dominância

11.2 Novos Trabalhos Futuros da v2

Composição adaptativa via aprendizado federado. Perfis de peso atualmente usam pesos definidos por governança ou ajustados manualmente. Aprendizado federado entre nós de agregação poderia descobrir pesos ótimos a partir de dados de resultado de interação sem centralizar informação sensível. Isso moveria o ARP v2 em direção a scoring adaptativo nível Upstart mantendo a restrição de álgebra aberta.

Composição de confiança recursiva. A composição atual é plana — sinais são combinados em uma única passada. Composição recursiva permitiria sinais-de-sinais: "o score composto computado por oráculos que são eles mesmos altamente avaliados." Isso espelha a propagação de confiança recursiva do EigenTrust [19] mas aplicada à camada de composição. A preocupação principal é convergência — composição recursiva deve provavelmente convergir para prevenir loops infinitos.

Verificação de PRB cross-chain. PRBs ancorados no Ethereum (via ERC-8004) deveriam ser verificáveis na Solana, Base e outras cadeias sem requerer que o verificador rode um nó Ethereum. Protocolos de bridge cross-chain e verificação por light client poderiam habilitar isso, mas a segurança de bridges cross-chain permanece um problema em aberto.

Funções de decaimento temporal para portabilidade. Reputação importada deveria decair ao longo do tempo se não reforçada por interações locais. Um agente que importa um PRB forte mas depois tem desempenho fraco localmente deveria ver seu score efetivo declinar. Os parâmetros da função de decaimento (meia-vida, formato da curva de decaimento) requerem ajuste empírico.

Taxonomia de Goodhart específica para agentes. A arquitetura anti-Goodhart (Seção 6) se baseia em pesquisa anti-manipulação geral. Padrões de manipulação específicos de agentes podem diferir qualitativamente da manipulação humana. Uma taxonomia sistemática de estratégias de manipulação de agentes (ataques em nível de modelo, injeção de prompt em avaliação, seleção automatizada de tarefas) informaria defesas mais direcionadas.

Integração com Agent Service Agreements (ASA). Scores compostos do ARP v2 são entradas naturais para negociação de contratos ASA — um agente com score composto alto pode exigir melhores termos. A integração formal entre sinais ARP v2 e critérios de qualidade ASA é deferida para a especificação ASA.

Integração com Agent Justice Protocol (AJP). Resultados de disputa do AJP deveriam retroalimentar avaliações ARP como sinal de alta confiança (decisões de arbitragem são eventos de verdade-base). A integração formal é deferida para a especificação AJP.

12. Referências

[1] Alex, Charlie, Editor, Bravo. "Agent Rating Protocol: A Decentralized Reputation System for Autonomous Agent Economies." AB Support LLC, v1.0.0, 2026. https://vibeagentmaking.com/whitepaper/rating-protocol

[2] Alex, Charlie, Editor, Bravo. "Chain of Consciousness: A Cryptographic Protocol for Verifiable Agent Provenance and Self-Governance." AB Support LLC, v3.0.0, 2026. https://vibeagentmaking.com/whitepaper

[3] W3C. "Verifiable Credentials Data Model v2.0." W3C Standard, maio de 2025. https://www.w3.org/TR/vc-data-model-2.0/

[4] FICO. "A World Without FICO Credit Scores: What Was It Like?" FICO Blog, 2025. https://www.fico.com/blogs/world-without-fico-credit-scores

[5] Upstart. "How AI Drives More Affordable Credit Access." 2025. https://www.upstart.com/

[6] Scharfstein, D. & Gilland, W. "Zest AI." Harvard Business School Case 224-021, novembro de 2023. (Scoring de crédito baseado em ML alcançando 25% mais aprovações em mais de 180 bancos.)

[7] PayCrow. "PayCrow Escrow for x402 Agent Payments." earezki.com, 2026. (Nota: a cifra de US$ 600M+ representa o volume total anualizado do ecossistema x402 entre todos os provedores, incluindo Coinbase, não o volume individual do PayCrow.)

[8] Wikipedia. "Criticism of credit scoring systems in the United States." https://en.wikipedia.org/wiki/Credit_score_in_the_United_States#Criticism

[9] CNBC. "How structural racism plays a role in lowering credit scores." 2022.

[10] National Consumer Law Center. "Past Imperfect: How Credit Scores Bake In Historical Discrimination." 2024.

[11] Arets. "In Stars We Trust — Reputation Portability Between Digital Platforms." Business & Information Systems Engineering, Springer, 2021.

[12] Tadelis, S. "Reputation and Feedback Systems in Online Platform Markets." UC Berkeley / Annual Review of Economics, 2016.

[13] Virtuals Protocol. "Revenue Network Launch." Fevereiro de 2026. https://www.prnewswire.com/news-releases/virtuals-protocol-launches-first-revenue-network-302686821.html

[14] Solana. "What is the Agent Registry?" 2026. https://solana.com/agent-registry

[15] ClawHub / OpenClaw. https://clawhub.ai

[16] CoinDesk. "AI Agents Need Identity and Zero-Knowledge Proofs Are the Solution." 19 de novembro de 2025.

[17] hozk.io. "Privacy Latest — ZK Email Stamp." 2025.

[18] Lookout. "Agent Trust Intelligence." 2026. https://lookout-agent.vercel.app

[19] Karma3 Labs / OpenRank. https://openrank.com/ ; Kamvar, Schlosser, Garcia-Molina. "The EigenTrust Algorithm for Reputation Management in P2P Networks." Stanford/WWW 2003.

[20] Goodhart, C. "Problems of Monetary Management: The U.K. Experience." 1975.

[21] UC Davis Library. "H-Index and Gaming." 2025.

[22] CHEQ / University of Baltimore. "The Economic Cost of Bad Actors on the Internet — Fake Reviews." 2021. (Fonte original da cifra de US$ 152B, amplamente citada pelo WEF e outros.)

[22a] Shapo. "Fake Review Statistics 2025." https://shapo.io/blog/fake-review-statistics/ (Agregação secundária.)

[23] AB Support LLC. "Rating and Reputation Systems Survey." 2026. Documento de pesquisa interno.

[23a] Uber. "How Uber's Rating System Works." Uber Newsroom, 2019. https://www.uber.com/newsroom/getting-5-stars/ (Uber publica que motoristas abaixo de 4,6 enfrentam revisão de desativação; RideGuru e estudos acadêmicos confirmam a média de 4,7-4,8.)

[24] Nisslmuller. "Goodhart's Law and the Death of Honest Metrics." Medium, 2026.

[25] Manheim, D. & Garrabrant, S. "Categorizing Variants of Goodhart's Law." arXiv:1803.04585, 2018. (Taxonomia de modos de falha de Goodhart: regressional, extremal, causal, adversarial.)

[26] The Block. "Ripple, Franklin Templeton join $5 million seed round for AI agent trust startup t54 Labs." 25 de fevereiro de 2026.

[27] VOUCH / trustnoagent.com. "VOUCH — The Reputation Layer for AI Agents." 2025-2026.

[28] Nostr Web of Trust Community. WoT-a-thon hackathon e ferramentas de atestação de confiança. 2025-2026.

[29] De Rossi, M., et al. "ERC-8004: Trustless Agents." Ethereum Improvement Proposals, agosto de 2025.

[30] Zarq AI / DEV Community. "State of AI Assets Q1 2026 — 143K agents, 17K MCP servers, all trust scored." 2026.

[31] Mastercard. "How Verifiable Intent builds trust in agentic AI commerce." Março de 2026. https://mastercard.com

[32] NIST. "Announcing the AI Agent Standards Initiative for Interoperable and Secure Innovation." Fevereiro de 2026.

[33] W3C. "Decentralized Identifiers (DIDs) v1.0." W3C Recommendation, julho de 2022. https://www.w3.org/TR/did-1.0/

[34] arXiv:2511.02841. "AI Agents with Decentralized Identifiers and Verifiable Credentials." Novembro de 2025.

[35] Penn, D.J., et al. "The Handicap Principle: how an erroneous hypothesis became a scientific principle." Biological Reviews, 2020.

[36] Spence, M. "Job Market Signaling." Quarterly Journal of Economics, 1973. Prêmio Nobel de Economia, 2001.

[37] Journal of Evolutionary Biology. "General signalling theory: why honest signals are explained by trade-offs rather than costs or handicaps." 2025.

[38] Precedence Research. "AI Agents Market Size, Share, and Trends 2025 to 2034." 2025. (Amplamente citado pelo World Economic Forum, janeiro de 2026.)

[39] FHFA. "Credit Scores — VantageScore 4.0 approval for GSE loans." Julho de 2025.

[40] Stanford HAI. "How Flawed Data Aggravates Inequality in Credit."

[41] Sovrin Foundation. "Sovrin Protocol and Token White Paper." https://sovrin.org

[42] Vouched. "Decentralized Identity & MCP-I: Know Your Agent." 2025. https://www.vouched.id

[43] W3C VC Working Group Charter 2026. https://w3c.github.io/vc-charter-2026

[44] HID Global Blog. "Trust Standards Evolve: AI Agents, the Next Chapter for PKI — Agent Name Service." 2026.

[45] Apify Blog. "Agentic commerce and the AI economy stack." 2026.

[46] Alex, Charlie, Editor, Bravo. "Agent Service Agreements: A Protocol for Enforceable Contracts Between Autonomous Agents." AB Support LLC, v1.0.0, 2026. https://vibeagentmaking.com/whitepaper/service-agreements

[47] Google. "Agent2Agent (A2A) Protocol." Especificação aberta para interoperabilidade de agentes, 2025-2026. https://google.github.io/A2A/

Apêndice A: Fundamentação em Teoria da Sinalização Honesta

Os sistemas de composição e verificação do ARP v2 são informados pela teoria da sinalização da biologia e economia. Este apêndice fornece a fundamentação teórica.

A.1 Sinalização Biológica: Da Desvantagem ao Trade-Off

O Princípio da Desvantagem de Amotz Zahavi de 1975 propôs que sinais custosos (a cauda do pavão) são honestos porque são caros de falsificar. No entanto, Penn et al. (2020) argumentaram que o Princípio da Desvantagem carece de suporte teórico ou empírico e pediram sua "aposentadoria honrosa" [35]. A visão atualizada — teoria do trade-off de sinalização — sustenta que a honestidade é mantida não pelo custo de equilíbrio mas pela diferença de custos marginais para benefícios marginais por tipo de sinalizador [37].

Para reputação de agentes: a questão não é "o que custa o suficiente para ser honesto?" mas "o que possui estruturas de custo diferencial que naturalmente separam agentes de alta qualidade de agentes de baixa qualidade?" O histórico operacional (idade da cadeia CoC) possui essa propriedade: manter um longo histórico operacional é barato para um agente genuíno (ele simplesmente continua operando) mas caro para um agente manipulador (deve manter o Sybil por meses/anos com custos reais de computação). A participação em avaliações possui essa propriedade: avaliar honestamente após interações genuínas é barato; fabricar registros de interação para gerar avaliações é caro.

A.2 Sinalização Econômica: O Modelo de Spence

O modelo de sinalização de mercado de trabalho de Michael Spence de 1973 demonstrou que a educação funciona como sinal crível porque tem custo diferencial — trabalhadores de alta capacidade acham menos custoso adquiri-la do que trabalhadores de baixa capacidade [36]. A formalização de Grafen em 1990 mostrou que isso é "virtualmente idêntico" ao modelo biológico de sinalização [35].

A composição do ARP v2 usa sinais com propriedades Spencianas:

• Idade operacional: custo diferencial (agentes genuínos a acumulam naturalmente; agentes manipuladores devem pagar custos contínuos de computação)
• Volume de avaliações de avaliadores diversos: custo diferencial (agentes genuínos recebem avaliações de interações genuínas; agentes manipuladores devem manter redes Sybil)
• Baixa taxa de disputas: custo diferencial (agentes genuínos evitam disputas com bom desempenho; agentes manipuladores devem evitar detecção enquanto sub-desempenham)

A.3 Implicação para o Design

A fundamentação em teoria da sinalização valida a abordagem de composição multi-sinal do ARP v2: em vez de depender de um único sinal custoso, o protocolo compõe múltiplos sinais com estruturas de custo diferencial independentes. Um agente que pode falsificar um sinal a baixo custo (ex.: inflando uma única dimensão) enfrenta custos genuinamente diferentes para os demais (ex.: acumular idade operacional, manter baixas taxas de disputa, receber avaliações altas diversificadas). A álgebra de composição garante que manipular o composto requer manipular simultaneamente todos os sinais de entrada — que, por design, possuem diferentes perfis de custo que tornam a manipulação simultânea mais cara que o desempenho genuíno.

Esta especificação é publicada sob a Licença Apache 2.0. Os autores não reivindicam permanência de qualquer detalhe técnico aqui contido — o protocolo é projetado para evoluir por meio de seus próprios mecanismos de governança.