Recentemente fiz uma integração com a DFNS, uma dessas plataformas, e quero compartilhar o que aprendi.
Gerenciar chaves privadas em sistemas de produção é um dos problemas mais difíceis em blockchain.
A abordagem tradicional gerar uma chave, armazenar como variável de ambiente e rezar para não vazar não escala nem em segurança nem em operação.
Plataformas MPC (Multi-Party Computation) resolvem isso de forma elegante: a chave privada nunca existe inteira em nenhum lugar. Em vez disso, múltiplos fragmentos criptográficos são distribuídos entre partes distintas (servidores, HSMs, dispositivos), e uma assinatura só é produzida quando um quórum desses fragmentos colabora — sem que nenhum deles precise se reunir para reconstruir a chave. O resultado é que não existe um ponto único de comprometimento: nem ataque externo nem insider consegue extrair a chave completa.
A documentação é excelente e os exemplos práticos no GitHub cobrem bem os casos de uso mais comuns. A curva de aprendizado foi surpreendentemente baixa para uma plataforma de nível enterprise — em poucos dias já estava executando transações on-chain sem armazenar nenhuma chave privada no servidor.
O que me chamou atenção foi a abordagem para contas de sistema. Em outras plataformas MPC que avaliei (Fireblocks, ForDefi), você precisa exportar um arquivo com a chave privada e injetar isso como variável de ambiente — funciona, mas é delicado de rotacionar e de integrar com pipelines automatizados. A DFNS trata contas de serviço como cidadãos de primeira classe: você cria uma service account, gera uma credencial RSA, e a autenticação é feita por assinatura de challenge. Muito mais limpo de operar.
O esquema de policies é outro diferencial real. A granularidade de permissões é alta, você consegue definir regras por rede, por tipo de operação, por valor, com aprovadores distintos. Isso coloca a plataforma em pé de igualdade com Fireblocks e ForDefi no quesito governança.
A limitação de 10 contas no plano de trial acabou sendo uma restrição criativa. Em vez de uma integração pontual, acabei construindo uma plataforma completa acessível via internet, com:
- dfns-integration — serviço Node.js/TypeScript que consome filas RabbitMQ e executa operações on-chain via DFNS MPC: deploy automático de contratos ERC-20, ERC-721 e ERC-1155 na rede Ethereum Sepolia
- BFF — API Node.js/Express com MongoDB, Redis e RabbitMQ, autenticação Cognito OIDC, fluxos de conversão FIAT ↔ token com aprovação administrativa
- Dashboard — frontend Angular para os usuários finais: saldo, conversões, transferências entre contas
- Backoffice — painel admin Angular para gestão de usuários, aprovações e monitoramento de operações
- Landing page — apresentação pública da plataforma
- Portal do desenvolvedor — onboarding e gestão de API keys para a CaaS API (developers.tokeniza.online)
- CaaS API — Crypto as a Service em Rust/Axum: mint, burn, pause, gestão de wallets e saldos ERC-20
- 2 SDKs — TypeScript e Python para consumo da CaaS API
Ao todo foram quase 200 transações executadas entre deploys de contratos, criação de contas e transferências.
O experimento com AI agêntica
Paralelamente, usei esse projeto como laboratório para testar desenvolvimento com Claude Code em modo autônomo. Ao invés de ter um arquiteto, um desenvolvedor e um QA separados, rodei um único agente 3 em 1: ele analisou requisitos, decidiu a arquitetura, implementou e escreveu os testes. O resultado foi surpreendentemente coeso — todos os componentes acima foram desenvolvidos nesse formato, com CI/CD completo, cobertura de testes e deploys automatizados na AWS.
O processo não foi hands-off: revisei e validei cada Pull Request gerado, e em alguns pontos intervim diretamente no código para ajustes que exigiam julgamento de contexto mais amplo — decisões de arquitetura que o agente não tinha como inferir sozinho, ou refinamentos que só fazem sentido com conhecimento do domínio do negócio. Isso reforçou uma percepção importante: o agente acelera muito a execução, mas a curadoria técnica continua sendo responsabilidade do engenheiro.
Ficou claro que o papel do engenheiro nesse cenário muda bastante: menos tempo escrevendo boilerplate, mais tempo revisando decisões arquiteturais e garantindo que o agente está trabalhando no problema certo.
O código da integração com a DFNS está em: https://github.com/alexjavabraz/cripto-dfns-integration
Comentários
Postar um comentário