image

À medida que os agentes computacionais se tornam cada vez mais capazes de tomar decisões autônomas, está surgindo uma nova classe de participantes da rede que pode interagir com protocolos Ethereum em escala e sofisticação sem precedentes. No entanto, as abordagens atuais para a integração do agente-BlockChain sofrem de vulnerabilidades de segurança fundamentais que impossibilitam a operação autônoma segura.

Esta postagem propõe uma proposta de proposta para implementações de protocolo de contexto de modelo canônico (MCP) que permitiriam interações seguras e verificáveis com o Ethereum. Em vez de debater se os agentes devem participar da rede, focamos em garantir que, quando o fizerem, suas interações sejam criptograficamente verificáveis, não custodiais e alinhadas com os princípios fundamentais do Ethereum.

O Model Context Protocol (MCP) é um padrão emergente para permitir que os sistemas de IA interajam com segurança com serviços e APIs externos. O MCP fornece uma camada de interface estruturada que permite aos agentes de IA descobrir, entender e utilizar recursos externos, mantendo limites claros de segurança.

No contexto da blockchain, os servidores MCP atuam como camadas de tradução entre o raciocínio do agente de linguagem natural e as operações de protocolo de baixo nível. Essa abstração é crucial porque permite que os agentes expressem intenções de alto nível que são traduzidas em transações de blockchain específicas.

As integrações atuais de blockchain-AI normalmente seguem um padrão inseguro:

// Problematic: Agent holds private keys
const transaction = await blockchainAPI.transfer({
privateKey: "0x...",
to: "recipient.eth",
amount: "10.0"
});

Esta abordagem cria várias vulnerabilidades críticas:

  1. Violação de custódia: as chaves privadas devem ser compartilhadas com a infraestrutura do agente
  2. Centralização de confiança: nenhuma maneira de verificar a legitimidade do código de integração de blockchain
  3. Superfície de ataque: integrações maliciosas ou comprometidas podem roubar fundos em escala

Quando dimensionados para milhões de agentes autônomos que gerenciam valor significativo, essas vulnerabilidades se tornam riscos sistêmicos para todo o ecossistema.

Propomos uma arquitetura de três componentes que mantém a segurança, permitindo recursos sofisticados de agentes:

Separação de componentes

  1. Protocolo MCP Server: traduz intenções de alto nível em transações não assinadas
  2. Servidor MCP do Signer: lida com operações de chave privada (como metamask, carteiras de hardware, etc.)
  3. Agente: orquestra o fluxo de trabalho enquanto nunca tocava em chaves particulares

Essa separação garante que a lógica de interação do protocolo possa ser auditada e verificada independentemente do gerenciamento-chave, enquanto os agentes mantêm a capacidade de executar estratégias sofisticadas de várias etapas.

A questão crítica de segurança:

Como os agentes podem verificar se seus servidores MCP de protocolo são impostores legítimos e não maliciosos?

Registro de código na cadeia

Propomos uma abordagem de registro na cadeia que permita a auto-verificação do agente.

Auto-verificação do agente

Antes de executar quaisquer operações financeiras, os agentes podem verificar criptograficamente suas ferramentas:

contract CanonicalMCPRegistry {
struct Implementation {
bytes32 codeHash;
string version;
uint256 timestamp;
bool active;
}

mapping(string => Implementation) public canonicalImplementations;

function registerCanonical(
string memory protocolName,
bytes32 codeHash,
string memory version
) external onlyMaintainer {
canonicalImplementations(protocolName) = Implementation({
codeHash: codeHash,
version: version,
timestamp: block.timestamp,
active: true
});
}
}

Isso oferece aos agentes a capacidade de recusar a operação se não puderem verificar a legitimidade de seus recursos de interação do protocolo.

Em vez de buscar isso como uma iniciativa de pesquisa, propomos seguir a especificação formal do protocolo com testes de conformidade.

Componentes de especificação

async function verifyProtocolMCP(agent: Agent): Promise {
const mcpInfo = await agent.introspectProvider("ethereum-protocols");
const canonicalHash = await REGISTRY.canonicalImplementations("EVM_MCP");
return mcpInfo.codeHash === canonicalHash.codeHash && canonicalHash.active;
}

Embora o foco inicial se concentre nas interações defi, o potencial mais amplo da integração segura de agente-protocolo se estende muito além dos aplicativos financeiros:

Sistemas de identidade e reputação

  • Agentes Gerenciando domínios ENS e identidade descentralizada
  • Pontuação e verificação de reputação autônoma
  • Gerenciamento de gráficos sociais e participação da comunidade

Participação de governança

  • Análise de proposta automatizada e votação
  • Otimização da estratégia de delegação
  • Coordenação de Governança de Protocolo Cross

Conteúdo e mídia

  • Curadoria de coleta da NFT e gerenciamento
  • Estratégias automatizadas de monetização de conteúdo
  • Licenciamento de propriedade intelectual e gerenciamento de royalties

Serviços de infraestrutura

  • Orquestração de armazenamento descentralizada
  • Calcule a alocação e otimização de recursos
  • Gerenciamento de infraestrutura de rede e monitoramento

O principal insight é que os agentes podem processar e agir com informações em escalas impossíveis para os participantes humanos, potencialmente desbloqueando categorias inteiramente novas de utilização de protocolo.

Após o modelo de diversidade do cliente Ethereum, previmos várias implementações compatíveis:

  • Implementação de referência: TypeScript/JavaScript para ampla compatibilidade
  • Implementação de desempenho: ferrugem ou vá para aplicativos de alto rendimento
  • Implementação incorporada: versões leves para ambientes com restrição de recursos
  • Implementações especializadas: otimizações específicas de domínio para casos de uso específicos

Todas as implementações devem passar nos testes idênticos de conformidade e produzir resultados criptograficamente equivalentes.

Propriedades de segurança

  • Não custodial: os agentes nunca lidam diretamente com as chaves privadas diretamente
  • Verificável: todas as interações do protocolo usam implementações canônicas e auditadas
  • Transparente: processo de tomada de decisão do agente totalmente audível
  • Composto: interfaces claras permitem estratégias sofisticadas de multiprotocolo

Efeitos de rede

  • Adoção do protocolo: os agentes podem utilizar protocolos muito complexos para interfaces de usuário típicas
  • Provisão de liquidez: participação contínua do mercado algorítmico
  • Aceleração de inovação: iteração rápida nos padrões de interação do protocolo
  • Acessibilidade: estratégias complexas disponíveis através de interfaces de linguagem natural

Propomos a seguinte trajetória de desenvolvimento:

  1. Revisão da comunidade: Reunir feedback sobre abordagem arquitetônica e modelo de segurança
  2. Desenvolvimento de especificação: Formalizar interfaces e requisitos de conformidade
  3. Implementação de referência: Construir e auditar a implementação do TypeScript canônico
  4. Implantação de registro: implantação na infraestrutura de verificação na cadeia
  5. Implementações alternativas: apoiar diversos esforços de implementação
  6. Suporte de integração: Auxiliar as principais estruturas de agentes com a adoção

Esta proposta representa uma abordagem sistemática para um desafio complexo: permitir que agentes autônomos sofisticados participem com segurança no ecossistema de protocolo da Ethereum. Acreditamos que a separação da arquitetura de preocupações, combinada com especificações formais e testes de conformidade, fornece um caminho para a interação segura do agente-protocolo em escala.

Perguntas -chave para consideração da comunidade:

  1. Modelo de segurança: o sistema de verificação proposto aborda adequadamente as preocupações de confiança?
  2. Especificação Escopo: Existem padrões críticos de interação do protocolo não cobertos por essa abordagem?
  3. Estratégia de implementação: que considerações adicionais são necessárias para implantação segura?
  4. Governança: Como a manutenção e as atualizações da implementação canônica devem ser gerenciadas?

O surgimento de agentes autônomos capazes não é uma questão de se, mas quando. Ao estabelecer padrões de integração seguros e padronizados agora, podemos garantir que, quando os agentes participarem da rede, eles o fazem de maneiras que se fortalecem em vez de comprometer os princípios fundamentais do Ethereum.

Fontesethresear

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *