Radix Engine: um modelo melhor para “consagração

No meu artigo anterior , analisei como o Radix Engine evitou algumas das falhas do MoveVM da Sui. Para resumir:

• O MoveVM de Sui é de nível muito baixo e genérico, tornando-o um ambiente de programação DeFi complicado.
• Radix Engine é orientado para lógica de alto nível e ativos + negócios, permitindo que os desenvolvedores se concentrem na lógica DeFi em vez de detalhes de baixo nível.

O MoveVM de Sui segue o original Filosofia Ethereum de um protocolo “limpo, simples, bonito”, que delega tudo para a camada de aplicação. Isso permite aos desenvolvedores a liberdade de explorar qualquer domínio, inclusive os desconhecidos no momento.

Porém, um protocolo muito simples e desestruturado cria compromissos significativos. Por exemplo, recursos comuns do sistema, como autorização, exigiriam uma implementação complexa no espaço do aplicativo, as interfaces padrão poderiam se tornar mais fragmentadas e a otimização do desempenho se tornaria mais difícil.

O Radix Engine, por outro lado, foi projetado para executar lógica não genérica em todo o sistema como um objetivo técnico central, pois nos permite fazer o seguinte:

• Aplicar padrões/implementações em todo o sistema . Um padrão opinativo permite que o desenvolvimento/manutenção/ferramentas seja mais fácil em toda a pilha, pois as APIs não são fragmentadas (por exemplo, ERC-20 vs. ERC-721 vs. ERC-404), e a compreensão do comportamento não requer interpretação de bytecode (não mais Puxadores de tapete ERC-20). Isso oferece aos desenvolvedores e usuários finais uma experiência DeFi mais segura e consistente.
• Execute a lógica mais próxima do hardware . Como a lógica do sistema não precisa ser executada por um intérprete para ser correta, a execução dessa lógica pode ser executada o mais próximo possível do hardware.
• Paralelizar a execução. Ao ter conhecimento do comportamento de determinados objetos, fica mais fácil tomar decisões de análise estática antes da execução, permitindo a execução paralela.

Vitalik recentemente abordou essa ideia com o termo “ consagração ”, ou a ideia de romper seletivamente com a abstração para obter os benefícios da lógica imposta por protocolo. Roubando uma de suas imagens, ele enquadra o problema como uma troca entre abstração e consagração:

Esse equilíbrio entre apoiar a abstração (ou seja, necessidades futuras/diversas dos usuários) e manter o desempenho/segurança/usabilidade (ou seja, consagração) é na verdade um problema muito antigo da ciência da computação. O design de sistemas operacionais especificamente tem tentado resolver um problema semelhante nas últimas décadas: como podemos oferecer suporte a uma variedade de aplicativos abstratos e, ao mesmo tempo, manter um sistema rápido, seguro e utilizável?

Neste artigo, abordarei como o Radix Engine usa o modelo de sistema operacional para criar uma estrutura capaz de todos os tipos de “consagração” sem a carga de complexidade do protocolo ou perda de flexibilidade que Vitalik teme.

Vamos começar examinando o padrão atual da indústria, a Máquina Virtual Ethereum (“EVM”).

EVM como VM

O EVM é básico o suficiente para poder ser modelado como uma máquina virtual (“VM”) com os seguintes opcodes:

• Conjunto completo de opcode de Turing
• Opcodes para chamadas para outros contratos inteligentes
• Opcodes para leitura/gravação em armazenamento persistente pertencente ao contrato inteligente atual

Contratos inteligentes compilados em bytecode EVM podem então ser executados em tal VM.

Neste modelo, qualquer forma de “consagração” requer alterações no EVM ou no hardware da VM. Por exemplo, consagrar o suporte à assinatura BLS exigiria a adição de uma nova pré-compilação. Implementando EIP-2938 exigiria a adição de novos opcodes. Expandir o que está consagrado resulta inevitavelmente em uma VM maior e mais complicada e força o designer do protocolo a tomar uma ou outra decisão que Vitalik descreve.

O problema geral com este modelo é que a dicotomia Abstração/Consagração está muito acoplada à dicotomia Software/Hardware. Ou seja, consagrar qualquer lógica no protocolo força a sua incorporação na VM. Não há como expressar “software consagrado” ou software que faz parte do sistema.

Os sistemas operacionais resolveram essa dicotomia com a noção de “software de sistema”. Vamos olhar mais de perto.

O modelo do sistema operacional

Um dos principais objetivos de um Sistema Operacional é gerenciar a dicotomia software/hardware – ou, mais especificamente, a dicotomia aplicação/hardware. A parte central de qualquer sistema operacional é o kernel, software que gerencia aplicativos do espaço do usuário e seu acesso ao hardware. Módulos e drivers do kernel são peças adicionais de software de sistema que expandem o conjunto de hardware suportado ou estendem a funcionalidade do kernel.

\De uma perspectiva de “consagração”, o kernel e seus módulos são partes consagradas do sistema, mas possuem a flexibilidade do software. Módulos do kernel, máquinas virtuais (“VMs”) e processos do sistema no espaço do usuário são ainda mais “soft”, pois são abstraídos do próprio kernel.

Neste modelo, a camada de indireção entre aplicações e hardware permite dissociar a dicotomia software/hardware da dicotomia abstração/consagração. O “software do sistema” permite a consagração sem sobrecarregar o hardware.

Radix Engine como sistema operacional

Usando este modelo de sistema operacional como inspiração, o Radix Engine inclui múltiplas camadas, cada uma com uma responsabilidade e abstração específicas, permitindo modularidade e plugabilidade do sistema.

Esse design modular permite que a lógica do sistema seja aplicada, ao mesmo tempo que permite o seguinte:

• Herde as propriedades de isolamento da camada em que está . Por exemplo, um pacote consagrado, embora consagrado, não pode acessar estados arbitrários, mas deve seguir os limites da camada de aplicação. Este é um tipo semelhante de segurança visto em drivers de espaço do usuário ou design de microkernel. Ou seja, o risco é mitigado isolando cada parte do sistema para que eventuais atualizações no sistema (consagração) não exponham todo o sistema ao risco.
• Acesse os recursos da camada em que está. Por exemplo, um pacote consagrado pode herdar recursos de autenticação e/ou capacidade de atualização fornecidos pelo sistema.
• Desacoplar a governação. Este design modular permite que a inovação em cada um destes módulos ocorra em paralelo e em ritmos diferentes.

Vamos agora examinar cada uma dessas camadas e ver quais são suas responsabilidades.

Camada de aplicação

A camada de aplicação é responsável por definir a lógica de alto nível. O bytecode que descreve essa lógica, junto com outras informações estáticas, é agrupado em um formato executável chamado Pacote. Os pacotes são então armazenados no livro-razão e disponíveis para execução.

Os aplicativos escritos em Scripto, a linguagem baseada em Rust que construímos para o desenvolvimento DeFi, residem nesta camada. Os programas Crypto são compilados em programas WASM com acesso a um conjunto de exportações de funções que permitem ao programa acessar serviços do sistema/kernel. Esse API de chamada do sistema é semelhante ao Linux chamadas do sistema , que fornecem acesso a E/S compartilhada.

Camada VM

Passando para a próxima camada, a camada VM é responsável por fornecer o ambiente computacional para a camada de aplicação. Isso inclui uma VM Turing-completa, bem como a interface para acessar a camada do sistema.

Atualmente, o Radix Engine oferece suporte a duas VMs: uma VM Scrypto WASM usada para executar aplicativos Scrypto e uma VM nativa que executa pacotes nativos que são compilados no ambiente do host.

Se dermos uma olhada especificamente na VM Scripto WASM, ela se parecerá com isto:

Isto pode parecer essencialmente igual ao modelo EVM, mas existem duas diferenças cruciais:

• Remoção do acesso direto ao armazenamento. Em vez de cada contrato inteligente poder acessar apenas o armazenamento de sua propriedade, qualquer leitura/gravação de estado é feita por meio de chamadas de sistema. Esta camada de indireção permite que muitas coisas interessantes sejam implementadas no sistema, como compartilhamento de estado entre aplicativos, virtualização de estado, etc. memória virtual ou Linux descritores de arquivo .

  
  

• Adição de chamadas de sistema . Chamadas de sistema são o mecanismo pelo qual a camada de aplicação pode acessar serviços da camada de sistema, como fazer invocações para outras aplicações ou gravar dados em um objeto. Estas chamadas de sistema são semelhantes às instruções de interrupção de software em CPUs reais (por exemplo, INT instrução em x86).

Camada do sistema

A Camada do Sistema é responsável por manter um conjunto de Módulos do Sistema ou software conectável que pode estender a funcionalidade do sistema. Eles são semelhantes aos do Linux módulos do kernel .

Em cada chamada do sistema, cada módulo do sistema é chamado antes que a camada do sistema passe o controle para a camada do kernel. Quando chamado, cada módulo do sistema pode atualizar algum estado específico (por exemplo, taxas de atualização gastas) ou entrar em pânico para encerrar a transação (por exemplo, se o verificador de tipo falhar).

Esse padrão permite que o sistema implemente funcionalidades como autorização, royalties ou verificação de tipo enquanto é desacoplado das camadas de aplicativo e kernel.

Camada do Kernel

A camada kernel é responsável pelas duas funcionalidades principais do Radix Engine: acesso ao armazenamento e comunicação entre aplicações. Isso é um pouco semelhante à responsabilidade do sistema operacional tradicional pelo acesso ao disco e à rede.

Para Radix Engine, isso inclui o seguinte gerenciamento de baixo nível:

• Verifique se a semântica de movimentação/empréstimo é mantida em qualquer invocação ou gravação de dados. A regra de proprietário único e as regras de empréstimo são aplicadas pelo kernel. Caso qualquer uma dessas regras não seja cumprida, a transação entrará em pânico.
• Gerencie objetos transitórios versus persistentes. Um objeto pode estar no espaço global a qualquer momento ou pode pertencer a um quadro de chamada. O kernel mantém ponteiros corretos para esses objetos durante o tempo de execução à medida que as referências a esses objetos são transmitidas.
• Gerenciar atualizações de estado de transação. O kernel mantém registro das atualizações de estado que ocorreram durante uma transação e que serão posteriormente confirmadas no banco de dados no final da transação.

Software consagrado

Como essas camadas se relacionam com a consagração em um protocolo DLT? Semelhante à camada kernel em sistemas operacionais, essas camadas intermediárias do Radix Engine fornecem a indireção necessária para dissociar a dicotomia abstração/consagração da dicotomia software/hardware e criar a noção de “software consagrado”.

O software consagrado tem a flexibilidade e as propriedades de segurança do software, ao mesmo tempo que mantém a capacidade de impor a lógica em todo o sistema.

Vamos examinar alguns exemplos de consagração que estão atualmente em execução na rede Radix e ver como eles são implementados.

Recursos consagrados

O principal diferencial da plataforma Radix DeFi/Web3 é a ideia de que um recurso (ou seja, ativo) é um primitivo fundamental que deve ser entendido separadamente da lógica de negócios. A consagração desse conceito permite que todos os dApps, carteiras e ferramentas tenham um entendimento comum de como é a interface e o comportamento de um ativo, tornando a composição muito mais fácil.

Embora os recursos sejam uma das partes mais arraigadas do sistema, a implementação de sua consagração requer apenas dois softwares modulares:

• Um pacote nativo que lida com a lógica de objetos de recursos, como Buckets, Vaults e Proofs

• Um módulo de sistema que impõe os invariantes de vida desses objetos (como a mobilidade e a capacidade de gravação de recursos)

  
  

O fato de o Radix Engine poder expressar o conceito profundo de um recurso padronizado e móvel enquanto é abstraído do sistema/kernel mostra o poder de uma estrutura de software de sistema modular.

Autorização e Royalties Consagrados

O Radix Engine padroniza autorização e royalties desacoplando essa lógica da lógica de negócios e implementando-os como recursos do sistema. Isso permite que usuários e desenvolvedores tenham uma maneira comum integrada de entender os requisitos para acessar qualquer função no livro-razão.

A modularidade de dissociar a lógica de negócios da lógica do sistema também permite opções convenientes de desenvolvimento/depuração, como a capacidade de visualizar uma transação sem as verificações de autenticação normais (quer simular o resultado do envio de 10 milhões de USDC para algum lugar? Com a autorização desativada, sua transação de visualização pode faça a cunhagem!).

A consagração da autenticação e dos royalties exige quatro peças de software modular:

• Pacotes nativos de autenticação e royalties que permitem que a camada de aplicação acesse a autenticação/royalties de qualquer objeto (por exemplo, para recuperar a regra de autenticação para acessar um método ou para reivindicar royalties).

• Os módulos do sistema Auth e Royalties são chamados antes de uma chamada de método de objeto para verificar se o chamador tem autorização suficiente para fazer a chamada e coletar royalties.

  
  

  
  

Transação consagrada

A interface correta entre o usuário e o sistema é fundamental para que qualquer sistema seja utilizável. Para ser utilizável, a interface deve encontrar o equilíbrio certo entre facilidade de uso e potência/flexibilidade.

No mundo do sistema operacional, a interface mais comum é o terminal, um processo de espaço do usuário que fornece ao usuário uma ferramenta de linha de comando para chamar e compor várias chamadas do sistema.

No mundo DLT, esta interface é a transação. O padrão do setor para uma transação é usar uma única chamada de invocação genérica de baixo nível. Infelizmente, isso é muito simples, pois torna difícil entender o que alguém realmente está fazendo ao interagir com o sistema.

O Radix Engine, por outro lado, usa o padrão tradicional do sistema operacional e consagra uma linguagem de aplicação (semelhante a uma linguagem de script de terminal como o bash) para chamar e compor chamadas de sistema em uma única transação.

Como o ponto de entrada de uma transação opera na camada de aplicação, o intérprete de linguagem é implementado adicionando um pacote nativo do Processador de Transações.

BLS consagrado

As assinaturas BLS são uma criptografia primitiva importante, pois permitem a possibilidade de assinaturas de limite. Infelizmente, executar tal lógica no WASM consome rapidamente a unidade de custo máximo. Na recente atualização “Anemone”, consagramos o BLS ao executá-lo nativamente e encontramos um ganho de 500x no desempenho quando comparado ao WASM.

Como a lógica BLS não tem estado, ela pode ser facilmente adicionada como uma pré-compilação adicional à VM Scrypto WASM.

Conclusão

O que consagrar e o que não consagrar é importante para qualquer protocolo DLT. Infelizmente, o modelo de VM existente na indústria torna cada decisão de consagração uma decisão de alto risco.

Com o modelo de sistema operacional como inspiração, o Radix Engine resolve esse problema adicionando uma camada indireta entre “software” e “hardware”. Isso permite que o Radix Engine expresse a noção de “software consagrado” e torna mais fácil para o protocolo adicionar, modificar e expressar novos sistemas consagrados sem tomar decisões de compromisso de alto risco.

Originalmente, o sistema operacional deveria ser um pequeno software projetado para gerenciar recursos compartilhados para vários aplicativos. À medida que crescia a demanda dos usuários por uma plataforma melhor, mais rápida e mais segura, eles assumiram cada vez mais responsabilidades com um conjunto cada vez maior de software.

DeFi não será diferente. À medida que cresce a demanda por uma plataforma DeFi mais rápida, mais segura e mais utilizável, uma maior consagração se seguirá. O Radix Engine foi projetado com isso em mente e fornece a estrutura escalonável e segura necessária para expandir a consagração no futuro.