DR
n-VM é uma arquitetura totalmente nova que roda N VMs heterogêneas (EVM, SVM, Bitcoin Script e mais podem ser adicionados) como verdadeiros cidadãos de primeira classe e coiguais em um único consenso e árvore de estado compartilhada. Ele substitui identidades fragmentadas e transferências de token dependentes de ponte por um compromisso de identidade de 32 bytes e um registro de token unificado. As transferências entre VMs são atômicas por design, eliminando completamente toda a classe de explorações de ponte que custaram ao ecossistema mais de US$ 2,8 bilhões.
Motivação
O ecossistema blockchain ainda está dolorosamente fragmentado. EVM, SVM, Bitcoin Script e outros têm seus próprios modelos de conta, formatos de endereço e padrões de token. Os usuários fazem malabarismos com várias carteiras, a liquidez permanece isolada e cada movimento entre cadeias depende de pontes – historicamente o #1 fonte de explorações DeFi.
Ainda ontem (18 de abril de 2026), vimos esse risco ocorrer novamente em escala: os invasores exploraram uma vulnerabilidade na ponte rsETH alimentada por LayerZero do Kelp DAO, drenando aproximadamente 116.500 rsETH sem suporte (~US$ 293 milhões). Eles despejaram os tokens falsos diretamente no Aave V3/V4 como garantia, emprestaram WETH real e deixaram o protocolo com dívidas inadimplentes substanciais. Aave teve que congelar os mercados rsETH e a TVL caiu mais de US$ 6 bilhões. Mais uma vez, uma falha de ponte única resultou em dor sistêmica.
Os projetos multi-VM existentes (Sei v2, Movement, Eclipse, etc.) ainda tratam uma VM como primária e o restante como camadas subordinadas. A identidade permanece fragmentada e o movimento de tokens ainda requer mecanismos semelhantes a pontes.
n-VM faz isso de forma diferente: um tempo de execução, N VMs iguais, zero pontes.
Arquitetura Central
A pilha é simples – apenas quatro camadas:
- Camada de consenso (pipeline BFT + Atestar – Executar – Provar)
- n-VM Dispatcher (roteamento de prefixo de código de operação)
- Mecanismos VM conectáveis (EVM, SVM, etc.)
- Árvore de estado unificada + camada de identidade + razão de token
Roteamento baseado em Opcode
O primeiro byte de cada transação a encaminha de forma determinística para a VM correta. Adicionar uma nova VM é tão fácil quanto registrar um intervalo de opcode não utilizado – sem alterações nos mecanismos existentes ou no estado compartilhado. As transações com falha são automaticamente capturadas e revertidas, mantendo tudo isolado.
Camada de identidade unificada
Um único compromisso de 32 bytes id_com = Poseidon(REV, salt, domain) ancora endereços em todas as VMs por meio de derivação determinística separada por domínio:
- EVM:
SHA-256("evm:" || id_com)(12:32)(20bytes) - SVM:
SHA-256("svm:" || id_com)(32 bytes) - …e assim por diante para os outros.
Os usuários obtêm uma identidade raiz, mas cada VM mantém seu formato de endereço nativo. Carteiras (MetaMask, Phantom, etc.) funcionam imediatamente por meio de “entrada de cadeia bruta” – a cadeia recupera a assinatura e a vincula ao unificado id_com.
Livro razão de token unificado
Todos os tokens residem em um único livro-razão. ERC-20 e SPL são simplesmente visualizações diferentes dos mesmos slots de armazenamento (codificados por id_com). Uma transferência de um contrato EVM para um programa SVM é apenas uma transição de estado atômico:
balance(M)(id_comA) -= value;
balance(M)(id_comB) += value;
Nenhum ciclo de bloqueio-queimadura-liberação. Não há contratos-ponte. Não há comitês multi-assinaturas. O design elimina exatamente o tipo de ataque colateral sem respaldo que atingiu Aave ontem.
Execução Paralela
Detecção de conflitos de conjunto de gravação + fragmentação opcional baseada em contexto (64 fragmentos por padrão) fornecem forte paralelismo.
Segurança e Determinismo
As falhas de VM são totalmente isoladas. O determinismo em nível de bloco é garantido para todos os validadores. As assinaturas legadas vinculam-se com segurança à identidade unificada sem enfraquecer o modelo.
Comparação
| Sistema | VMs | Identidade | Transferência de token |
|---|---|---|---|
| Movimento | EVM + Mover | Separar | Ponte |
| Eclipse | SVM no Ethereum | Separar | Ponte L1↔L2 |
| Sei v2 | EVM + CosmWasm | Ponteiro | Ponteiro |
| De bolinhas | Por parachain | Por parachain | XCM |
| n-VM | n VMs iguais | ID único_com | Razão unificada |
O papel
Eu adoraria ouvir a opinião da comunidade – especialmente sobre a compatibilidade do EVM, as compensações do roteamento de opcode e como isso poderia funcionar com as ferramentas Ethereum ou L2s existentes.
Aguardamos seu feedback!
Fontesethresear



