Domínio de compatibilidade EVM isolado
O EVM Capsule é um domínio de compatibilidade isolado na borda do Orbitra L1. O bytecode e as ferramentas existentes do Ethereum são executados dentro de uma cápsula com medição, com seus próprios tetos de gás e de recursos, e os ativos só alcançam o núcleo por meio de um gateway governado e com limite de taxa. O ambiente de execução do núcleo é o NexusWASM; a cápsula amplia o alcance para desenvolvedores sem alterá-lo.
Como funciona
A ilustração desenha o EVM Capsule como um domínio isolado ao lado do núcleo do Orbitra L1, limitado por seus próprios tetos de recursos. A única conexão entre os dois é um gateway governado: os ativos o atravessam sob limites de taxa, e um mecanismo de interrupção pode fechá-lo sem interromper nenhum dos dois domínios. Um caminho de migração leva da cápsula até o NexusWASM.
O problema
Um vasto conjunto de código de contratos inteligentes, bibliotecas revisadas e práticas de desenvolvimento é escrito para a Máquina Virtual Ethereum (EVM). Uma nova rede que o ignora obriga cada equipe a começar do zero. Uma rede que adota a EVM como seu núcleo herda seu modelo de execução — uma unidade de gás combinada, acesso implícito a estado e processamento organizado em torno de uma única ordem global — nada disso foi projetado para um estado de mercado paralelo e determinístico.
O Orbitra L1 precisa das duas coisas ao mesmo tempo: um ambiente de execução do núcleo projetado para estado financeiro, e um caminho direto para equipes que já constroem com linguagens e ferramentas do Ethereum. Fundir as duas comprometeria a primeira. Ignorar a segunda restringiria o ecossistema.
O EVM Capsule resolve essa tensão com uma fronteira. As aplicações compatíveis são executadas dentro da cápsula sob regras familiares, o ambiente de execução do núcleo não carrega restrições do EVM, e tudo o que se move entre eles passa por um gateway com limites explícitos, monitoramento e mecanismos de interrupção.
Sequência operacional
A cápsula é um lugar para executar código existente, não um atalho para o estado do núcleo. Toda interação com ativos do núcleo segue o mesmo caminho governado.
O bytecode EVM existente é implantado na cápsula com ferramentas familiares do Ethereum. Endereços, chamadas e eventos se comportam como os desenvolvedores EVM esperam, dentro do domínio da cápsula.
As transações da cápsula pagam gás da cápsula sob tetos definidos de forma independente do núcleo, de modo que a demanda dentro da cápsula é precificada e limitada dentro da cápsula.
A cápsula é executada em seu próprio domínio, com seu próprio estado. Uma falha dentro dela não pode escrever em contratos NexusWASM, módulos de mercado ou saldos do núcleo.
Quando uma aplicação precisa de um ativo do núcleo, ela envia uma solicitação de transferência ao gateway. Nenhum caminho de chamada direto leva do código da cápsula ao núcleo.
O gateway verifica a solicitação em relação aos limites de taxa por ativo e por rota, ao status do mecanismo de interrupção e ao monitoramento das pontes, antes que qualquer coisa se mova.
As transferências aprovadas são confirmadas em ambos os lados em uma única transição finalizada pelo QSE. As solicitações recusadas ou pausadas deixam os dois domínios inalterados.
Quando uma equipe está pronta, os componentes migram para o NexusWASM um a um, com o gateway transportando ativos entre as versões da cápsula e as nativas durante a transição.
Arquitetura
A cápsula é deliberadamente simples em sua fronteira: um domínio, um gateway, um único conjunto de limites. A complexidade permanece do lado do muro a que pertence.
Executa bytecode EVM com semântica do Ethereum em um domínio sandbox que mantém seu próprio estado, separado do estado do núcleo, e expõe interfaces familiares para implantação, chamadas e eventos.
O gás da cápsula, a execução e o crescimento do armazenamento são limitados por tetos definidos separadamente do núcleo. O congestionamento dentro da cápsula é precificado e absorvido dentro da cápsula.
O único caminho para ativos que se movem entre a cápsula e o núcleo. As transferências têm limite de taxa por ativo e por rota, e cada movimento deixa um registro correspondente em ambos os lados.
Gatilhos automáticos pausam todo o gateway ou uma única rota quando os fluxos excedem os limites, a reconciliação falha ou o monitoramento detecta uma anomalia.
As representações do lado da cápsula de ativos do núcleo são reconciliadas continuamente com as reservas do núcleo que as respaldam. Uma divergência pausa a rota afetada em vez de deixá-la crescer.
Padrões e ferramentas para mover uma aplicação para o NexusWASM progressivamente, de um único caminho crítico de desempenho até a base de código completa.
Segurança e controle de falhas
A cápsula é projetada sob a premissa de que algumas aplicações EVM vão falhar — por defeitos de reentrância, atualizações defeituosas ou chaves comprometidas. A fronteira decide até onde essa falha pode chegar.
Nos três sistemas
Orbitra Prime
Inteligência de negociação
Os ativos que atravessam o gateway se tornam ativos comuns do núcleo. Uma vez listados sob as regras habituais, eles são negociados no Orbitra Prime por meio do ApexMatch, com o mesmo tratamento de risco do Aegis que qualquer outro ativo.
Orbitra L1
Liquidação e processamento
O EVM Capsule é um domínio de compatibilidade delimitado do Orbitra L1 que é executado ao lado do ambiente de execução do NexusWASM — nunca abaixo dele ou em seu lugar. Suas transições são finalizadas pelo QSE junto com o restante da rede.
Orbitra Realm
Aplicações e comércio
Equipes com aplicações Ethereum existentes podem entrar rapidamente no Orbitra Realm, alcançar usuários e liquidez por meio do gateway, e mover componentes críticos de desempenho para o NexusWASM quando decidirem. Ativos de outras blockchains chegam por meio do GateMesh; o gateway da cápsula conecta apenas a cápsula e o núcleo.
Valor
Especificações
Terminologia