Eu estava lendo algumas das discussões mais recentes sobre abstração de conta do Ethereum há algumas noites, especificamente em torno do envio do EIP-7702 com a atualização Pectra no ano passado, e em algum ponto no meio disso eu me vi pensando de novo no Newton Protocol — não porque alguém estivesse mencionando diretamente, mas porque um problema específico continuou aparecendo de um jeito que o Newton parece ter construído, mas que eu não tinha apreciado totalmente antes. A tensão central em qualquer modelo de delegação é surpreendentemente simples: se você dá a outra chave permissão para agir em seu nome, como garantir que ela faça apenas exatamente o que você pretendia e nada além disso? A maioria das implementações de contas inteligentes lida com isso por meio de chaves de sessão, credenciais temporárias com permissões limitadas anexadas, mas o vínculo normalmente é imposto no nível do contrato em uma única cadeia por meio da lógica que o desenvolvedor da carteira escreveu. O que o Newton parece estar fazendo de forma diferente é embutir esses limites dentro de um circuito de zero conhecimento, um zkPermission, antes mesmo de a chave de sessão ser emitida; assim, a restrição não é apenas uma regra que alguém escreveu em algum contrato, mas uma propriedade criptográfica da própria chave.
O que parece interessante para mim é o quanto essa distinção importa na prática quando você tenta pensar nos modos de falha, e não nos caminhos felizes. Uma abordagem padrão de session key só é tão confiável quanto a implementação do contrato que impõe o escopo dela. Se o desenvolvedor cometeu um erro nessa lógica, ou se existe um caso-limite que não foi previsto quando as permissões foram definidas, a chave potencialmente poderia ser usada de maneiras que passam na validação tecnicamente, mas violam o que o usuário realmente pretendia. Um circuito de zkPermission, por outro lado, codifica a regra de automação como uma restrição matemática e prova que qualquer ação dada a satisfaz antes que a execução prossiga. Às vezes me pergunto se a maioria das pessoas que fala sobre delegação de agentes em DeFi realmente pensou com cuidado nessa distinção, porque, do ponto de vista da confiança do usuário, esses dois modelos são significativamente diferentes, mesmo que pareçam superficialmente semelhantes quando tudo dá certo. A diferença aparece especificamente quando as coisas dão errado ou quando alguém está tentando ativamente explorar os limites do que um agente está autorizado a fazer.
A parte que ainda não resolvi completamente no meu raciocínio envolve a experiência do usuário ao definir, em primeiro lugar, essas restrições de zkPermission. Circuitos de conhecimento zero são expressivos e matematicamente rigorosos, mas também são notoriamente difíceis de trabalhar no nível de especificação. A pergunta que me ocorre é: o que acontece de verdade quando um usuário comum, e não um desenvolvedor, tenta expressar uma permissão mais nuançada como "transacionar apenas este ativo se o preço estiver acima de um certo limite e apenas entre estas horas, e nunca mais do que esta porcentagem do meu saldo em uma única transação". Converter esse tipo de intenção humana em um circuito que a capture com precisão, sem acabar sendo acidentalmente nem restritivo demais nem permissivo demais, parece um problema genuinamente difícil de design de interface — e que fica acima de toda a elegância criptográfica. O Newton's VaultKit SDK é projetado para abstrair isso para desenvolvedores, mas não tenho certeza de até onde essa abstração chega para usuários finais, que não têm interesse em pensar sobre restrições de circuitos.
Olhando de fora, também existe aqui uma questão mais ampla de timing que eu continuo levantando. A Newton está construindo em cima tanto do ERC-4337 quanto do EIP-7702, que juntos cobrem o panorama tanto de smart accounts feitos sob medida quanto das centenas de milhões de carteiras externamente gerenciadas existentes que o EIP-7702 agora pode adaptar com comportamento de smart-account, sem exigir migração. Em teoria, é uma área enorme para endereçar, mas a adoção prática desses padrões ainda é desigual entre carteiras, cadeias e ferramentas de desenvolvimento. O modelo de delegação e autorização da Newton é mais poderoso quando a camada da carteira por baixo já é nativa de smart-account, e essa condição ainda está se tornando verdadeira aos poucos, em vez de já ser universal. Se a abstração de carteiras vai amadurecer rápido o suficiente para atender à infraestrutura da Newton no meio do caminho, ou se a Newton acaba tendo que construir mais dessa ponte por conta própria, parece ser uma dessas dependências silenciosas que não aparece na documentação, mas molda a trajetória real de adoção mais do que quase qualquer outra coisa — enfim, só o tempo dirá💻