A I de longa duração resume conversas e histórico de tarefas para continuar processando. O ARCBench verifica, por meio de operações reais de ferramentas, se as proibições permanecem no resumo e, portanto, se o sistema é seguro. Cria-se um histórico na plataforma de execução pi, depois de comprimido, são feitas solicitações que violam as regras e comparadas com operações sem compressão. Ao mesmo tempo, investiga-se se as regras foram mantidas, enfraquecidas ou eliminadas no resumo. Por exemplo, se houver uma regra que permite enviar e-mails apenas internamente, uma chamada para uma ferramenta de envio a destinatários externos será considerada uma violação. Na avaliação com 17 casos, muitas das violações após compressão ainda mantinham as regras presentes. No entanto, também ocorrem problemas no comportamento, como tratar solicitações subsequentes como permitidas. Não basta apenas verificar se as regras estão escritas no resumo — é necessário testar se operações que violam essas regras são efetivamente impedidas.

Criei um framework de teste para dapps chamado kiwa 🥝 Ferramenta que permite escrever de especificação até teste de forma contínua. Além da documentação, também carrega código existente, gera especificações de teste e produz quatro níveis de testes: contrato, E2E do dapp, unitário e integração de API. https://t.co/FCNjrLbVSV

📚 Nova Arquitetura de Mempool para Prevenir Operações de Ordem em Bloco ✅ Visão Geral Esta proposta visa encriptar o mempool do Ethereum (o local onde as transações não confirmadas ficam armazenadas), tornando o conteúdo invisível até que entre no bloco. Isso visa reduzir significativamente práticas como a leitura antecipada de transações para manipular a ordem, ou estratégias de MEV (ganho adicional obtido por mineradores/validadores), que visam manipular preços. Embora as transações sejam eventualmente reveladas, o fator-chave é que o seu conteúdo permanece oculto até o momento imediatamente antes da sua execução. ✅ Por que é Necessário um Mempool Encriptado Atualmente, no Ethereum, qualquer pessoa pode ver o conteúdo das transações no mempool. Isso permite estratégias de MEV, como front-running (executar uma transação antes da de outra pessoa) e ataques de sanduíche (executar transações antes e depois de outra para manipular o preço), o que pode levar a perdas para os utilizadores e à centralização dos construtores de blocos (concentração em poucos atores fortes). Com a encriptação, mesmo que a ordem das transações seja visível, o conteúdo permanece oculto, tornando estas estratégias de ataque mais difíceis de serem executadas. ✅ Como as Transações são Encriptadas As transações são divididas em duas partes: "envelope" e "conteúdo (payload encriptado)". O envelope contém apenas informações mínimas em texto simples, como a quantidade de gás, taxas e qual provedor de chave será usado para desencriptar. O conteúdo, por sua vez, inclui dados sensíveis como endereços de destino, valores e dados de chamada de contratos, todos encriptados. Apenas após a inclusão no bloco, e com a publicação da chave de desencriptação correspondente, o conteúdo é executado. ✅ O Papel dos "Provedores de Chave" Os provedores de chave são os responsáveis por gerir as chaves necessárias para desencriptar as transações. A arquitetura permite a utilização de diferentes métodos, não sendo fixa a uma única abordagem. Alguns exemplos incluem: - Criptografia de limiar (chave gerida de forma distribuída por múltiplas partes) - MPC (Criptografia com múltiplas partes, onde a informação é dividida entre vários computadores) - TEE (Execução em ambiente seguro de hardware) - Criptografia com atraso temporal O próprio Ethereum fornece apenas a infraestrutura base compatível com qualquer um destes métodos de criptografia. ✅ Ordem no Bloco e Segurança No bloco, primeiro são executadas as transações em texto simples. Depois, são processados os envelopes das transações encriptadas. Finalmente, o conteúdo desencriptado é executado. Esta estrutura garante a seguinte segurança: - As taxas são sempre pagas primeiro - O conteúdo não é executado sem a chave de desencriptação Mesmo que a chave não seja revelada, apenas o processamento do envelope é interrompido, sem afetar a cadeia como um todo. ✅ Efeitos sobre MEV e Resistência à Censura Com o conteúdo oculto, os construtores de blocos não conseguem antecipar quais transações afetarão quais preços. Isso dificulta a obtenção de lucro através da manipulação da ordem, enfraquecendo estruturalmente o MEV. Além disso, com o conteúdo oculto, torna-se mais difícil censurar transações específicas ou operações de DeFi, melhorando a "resistência à censura em tempo real" (a capacidade de não ser rejeitada imediatamente).

📚 Mecanismo para comprovar a identidade e reputação de agentes por meio de NFTs ✅ Visão Geral A versão 1.0 do ERC8004 é um conjunto de regras comuns que permite que agentes de software autônomos colaborem com segurança entre diferentes organizações. Utiliza a Ethereum como "base de arbitragem", registrando de forma imutável a identidade dos agentes, sua reputação e os resultados da verificação de suas tarefas. Desde a versão 0.4, houve uma grande mudança no design, evoluindo para um mecanismo baseado em experiências práticas. ✅ Gestão de Identidade dos Agentes (Registry de Identidade) O mecanismo que comprova "quem é o agente" foi migrado de um formato próprio para o padrão ERC721 (padrão de NFTs). Cada agente é registrado como um único NFT, e o tokenURI contém informações de registro no formato JSON. Essas informações incluem métodos de comunicação (endereços de protocolos como A2A ou MCP), a chave pública e o modelo de confiança correspondente. Dessa forma, a identidade do agente pode ser gerenciada por meio de carteiras, permitindo que qualquer pessoa verifique "quem é o agente desse endereço" de forma compatível com a infraestrutura de NFTs. ✅ Sistema de Reputação (Registry de Reputação) As avaliações sobre o desempenho do agente são armazenadas diretamente na blockchain como pontuação. Antes de enviar uma avaliação, o cliente recebe dados assinados pelo agente. Essas assinaturas são verificadas por meio do EIP191 (método comum de assinatura de carteiras) ou do ERC1271 (método de assinatura para carteiras de contratos inteligentes), prevenindo ataques de falsificação e replay (reutilização de assinaturas anteriores). Como pontuações e rótulos (etiquetas de classificação) podem ser acessados diretamente a partir do contrato inteligente, outros dApps podem utilizá-los automaticamente para determinar "se este agente é confiável". ✅ Verificação de Trabalho (Registry de Validação) É um mecanismo que permite que terceiros verifiquem se os resultados emitidos pelo agente estão corretos. Na versão 1.0, em vez de usar um único hash, a evidência é apresentada por meio de um URI (referência a dados externos), permitindo o registro de múltiplas etapas de verificação para a mesma tarefa. Por exemplo, pode-se estruturar a verificação em etapas como "verificação básica", "análise detalhada" e "auditoria externa", acumulando gradualmente níveis de confiança. Atualmente, está em fase de definição de especificações com a comunidade de TEE (Trusted Execution Environment, ambiente de execução confiável). ✅ Segurança e Custo de Gás Para lidar com métodos de ataque identificados durante o uso da rede de teste, a verificação de assinaturas e o design de armazenamento foram reforçados. Como consequência, o custo de gás para escrever avaliações e verificações aumentou, mas há o benefício de ter dados de confiança diretamente utilizáveis na blockchain. Na rede L2, os custos são significativamente reduzidos. ✅ Migração a partir da versão 0.4 A versão 1.0 não é compatível com versões anteriores e alterou completamente a estrutura de armazenamento. Por isso, todas as informações de registro e reputação anteriores serão redefinidas, sendo necessário que os agentes se registrem novamente como NFTs e que o sistema de avaliação seja adaptado ao novo método de assinatura. A partir de agora, será adotado o "método de atualização com namespaces", permitindo atualizações de especificações sem apagar os dados. Assim, esta redefinição em larga escala será única.

📚 Mecanismo para distribuir o conteúdo dos blocos e prevenir MEV ✅ Visão Geral Nesta proposta, é explicada a ideia de que o MEV, que tem sido um problema na Ethereum, pode ser reduzido quase a zero ao distribuir a decisão do "conteúdo" dos blocos. Primeiramente, organiza-se estruturalmente por que o MEV surge, e depois propõe-se uma nova abordagem que se concentra na seleção e na ordem das transações, adicionando uma nova camada de consenso. ✅ A verdadeira razão pela qual o MEV ocorre O MEV surge porque os mineradores ou validadores podem livremente escolher quais transações incluir nos blocos e reordená-las. Embora a estrutura dos blocos na Ethereum já esteja de acordo com um consenso descentralizado, o conteúdo dos blocos é decidido rapidamente por um único proponente. Esse estado em que "uma única entidade decide o conteúdo" é a causa raiz de MEV, como front-running e ataques de sanduíche. ✅ O consenso sobre a estrutura e o conteúdo são problemas distintos A blockchain conseguiu bem descentralizar o consenso sobre quem reconhece quais blocos como válidos. No entanto, a decisão sobre quais transações incluir e em que ordem não está descentralizada. Nesta proposta, isso é explicado como tendo a mesma estrutura do antigo problema de dupla gasto. Assim como a concentração de poder em uma única máquina leva a fraudes e é resolvida por meio de consenso, o conteúdo dos blocos também deve ser decidido por meio de consenso. ✅ A ideia da camada de conteúdo A proposta sugere adicionar uma "camada de conteúdo" (uma camada de consenso para decidir o conteúdo das transações) sobre a estrutura do bloco. Nesta camada, vários nós assumem papéis distintos e decidem conjuntamente quais transações incluir e em que ordem. O objetivo é eliminar a possibilidade de validadores ou sequenciadores específicos reordenarem as transações conforme sua conveniência. ✅ Funcionamento básico do protocolo Alex No exemplo do protocolo Alex, há papéis separados para coletar transações, randomizar a ordem e gerenciar tudo para refletir no bloco. Cada um atua de forma independente, e mesmo que alguém tente cometer uma fraude, outros participantes verificam e complementam o processo. Com isso, torna-se extremamente difícil censurar transações ou reordená-las de forma arbitrária. ✅ Relação com a Ethereum existente Este mecanismo não prejudica o próprio consenso da Ethereum. Mantém-se a estrutura dos blocos e apenas adiciona uma nova forma de decidir o conteúdo. A mesma ideia pode ser aplicada aos validadores da Ethereum 2.0, aos sequenciadores dos rollups e aos futuros sequenciadores descentralizados. Destaca-se o fato de que, ao criar uma estrutura, ela pode ser amplamente aplicada. ✅ Impacto na justiça e na descoberta de preços Neste design, comportamentos necessários ao mercado, como arbitragem simples, não são excluídos. Por outro lado, o problema é isolado apenas para o MEV que explora os usuários de forma incontrolável. Como resultado, o objetivo é criar um estado em que a rede em si fornece justiça, sem a necessidade de aplicações implementarem medidas complexas.

📚 Novo mecanismo para adicionar anonimato a tokens existentes ✅ Visão Geral Este conteúdo propõe uma nova especificação ERC que adiciona privacidade a tokens já existentes na Ethereum, sem alterar a sua usabilidade ou natureza. O objetivo é fornecer um mecanismo que dificulte a rastreabilidade de transações, aplicando-se a tokens amplamente utilizados como ERC20, ERC721 e ERC1155. ✅ O que está tentando resolver Atualmente, os tokens Ethereum revelam publicamente, na blockchain, quem enviou e para onde enviou tokens. Embora isso ofereça transparência, também permite que saldos e movimentações financeiras sejam facilmente rastreados por terceiros. Esta proposta de ERC visa corrigir essa fraqueza sem a necessidade de recriar os próprios tokens. ✅ O conceito do wrapper de token com zero knowledge O wrapper de token com zero knowledge (conhecimento zero) é um mecanismo no qual os tokens existentes são depositados e, em troca, o usuário recebe "tokens encapsulados". Estes tokens encapsulados podem ser enviados e negociados como os tokens originais, mas internamente utilizam compromissos criptográficos para ocultar a relação de propriedade, garantindo a veracidade posteriormente. ✅ Quebra de histórico por meio de queima e recriação Um aspecto notável é o fluxo combinado de queima (burn) e recriação (mint). Ao apresentar uma prova de conhecimento zero (uma tecnologia criptográfica que demonstra a validade sem revelar informações), novos tokens são emitidos sem ligação aos tokens queimados anteriormente. Isso dificulta a rastreabilidade na blockchain. ✅ No caso de tokens fungíveis como ERC20 Para tokens fungíveis, como o ERC20, este mecanismo permite essencialmente quebrar o histórico de fluxo de fundos. Até que o usuário retire os tokens, será difícil para terceiros identificar quem detém quais saldos. ✅ O que é possível fazer com NFTs Tokens NFTs, como o ERC721, são únicos, o que impede uma mistura completa. No entanto, mesmo assim, é possível ocultar a identidade do atual detentor do NFT até que ocorra a operação de saque. ✅ Uso transparente para o utilizador Este mecanismo foi concebido para ser utilizado sem que o utilizador precise estar ciente da existência dos tokens encapsulados. Wallets e aplicações podem processar internamente, permitindo que os utilizadores continuem a operar com a mesma experiência habitual, beneficiando-se da privacidade. ✅ Compatibilidade com o ecossistema existente Ao encapsular tokens existentes em vez de emitir novos tokens dedicados, esta proposta é compatível com o ecossistema Ethereum atual, incluindo DEXs e DeFi. Isso permite adicionar anonimato sem comprometer a liquidez e a utilização dos tokens.

📚ERC7694 Fiz uma síntese sobre o "ERC7694", que propõe um mecanismo pelo qual contratos inteligentes do Ethereum utilizam a Solana como armazenamento externo, permitindo escrita e leitura seguras entre correntes diferentes! https://t.co/hYzUup7dBO