A atualização recente do Arbitrum apresenta a atualização Stylus VM, apresentando várias melhorias:

• Suporte de idioma expandido
• Custos e uso de memória reduzidos
• Pré-compiladores personalizáveis
• Compatibilidade com EVM

Essas melhorias resultam da integração do WASM, conhecido por seus inúmeros benefícios em ambientes nativos da nuvem. Mais detalhes sobre o papel do WASM serão abordados nas seções subsequentes.

Pioneiros

A Arbitrum introduziu o WASM em sua rede, mas não é a plataforma inaugural para fazê-lo. Polkadot permitiu anteriormente a criação de contratos inteligentes WASM. Ele oferece duas linguagens para isso: um script assembly semelhante a uma DSL incorporada e uma linguagem inspirada no Rust chamada ink!

Da mesma forma, o Cosmos utiliza o CosmWasm para a execução inteligente de contratos. Os desenvolvedores podem criar contratos inteligentes usando Rust aqui.

Antes de explorar a afinidade que o blockchain tem com o WASM, vamos revisar a justificativa de Cosmos e Polkadot para escolher o WASM.

Cosmos apregoa o WASM por estas vantagens:

• Compatibilidade da biblioteca Rust
• Uma ampla comunidade de desenvolvedores
• Segurança aprimorada, incluindo prevenção de ataques de reentrada
• Procedimentos de teste simplificados
• Performance superior

O tempo de execução WASM do Polkadot apresenta recursos como:

• Desempenho excepcional
• Interoperabilidade EVM
• Independência de plataforma de hardware e software
• Tamanho compacto
• Suporte para Rust e Assembly Script, semelhante ao Typescript

Polkadot, Cosmos e Arbitrum compartilham vários benefícios induzidos pelo WASM. No entanto, o Arbitrum tem ofertas distintas que discutiremos mais tarde, juntamente com as especificidades do Cosmos.

WASM

Vamos nos aprofundar no que é WASM e nas motivações por trás dele.

O que é WASM?

WebAssembly (WASM) é um formato de instrução binária. Ele permite que o código seja executado em velocidades comparáveis às de aplicativos nativos, especificamente em navegadores da web. Como alvo de compilação para linguagens como C e Rust, é otimizado para velocidade, eficiência e segurança. WASM melhora significativamente o desempenho da web e expande as funcionalidades da web.

WASM está intimamente ligado à web, pois opera em ambientes JavaScript como navegadores. Dentro desses ambientes, os desenvolvedores têm acesso total às APIs WASM, bem como suporte completo à API Web. Esse controle permite que os desenvolvedores ajustem as interações na web.

A Evolução do WASM

O conceito de WASM gira em torno do ideal de escrever código uma vez para executá-lo em qualquer lugar.

Em 2016, os programas introduziram frequentemente novos recursos por meio de linguagens específicas de domínio (DSLs). A criação de uma DSL envolveu equilibrar manutenção, eficiência e segurança. A indústria buscou um método para implantar funções em vários servidores sem comprometer esses aspectos.

Várias soluções foram examinadas, cada uma com seu próprio conjunto de desafios:

• As máquinas virtuais do sistema enfrentavam sobrecarga, falta de visibilidade do código para segurança e eram muito abstratas para alto desempenho.
• Os contêineres também não tinham visibilidade de código e eram igualmente abstratos, com sobrecarga significativa.
• As máquinas virtuais em nível de linguagem precisavam de modificações frequentes para segurança, incorriam em sobrecarga de VMs incorporadas como V8 e eram lentas na adoção de novas linguagens para se adequarem aos modelos de segurança.
• As Arquiteturas de Conjunto de Instruções (ISAs) eram difíceis de modificar para um sandbox eficiente e careciam de implementações maduras.

WASM surgiu como uma solução. O desenvolvimento de compiladores WASM começou e, em 2018, o conceito de compatibilidade universal de código entre várias arquiteturas e dispositivos foi expandido. Ao contrário do Java, o objetivo não era comprometer a segurança.

Em 2019, o modelo de componentes foi introduzido, elevando os módulos WASM para interoperabilidade entre idiomas. Esta inovação permitiu, por exemplo, a criação de uma biblioteca HTTP universal aplicável em diferentes idiomas, abordando questões complexas de forma inovadora.

ERA hoje

WASM possui uma série de recursos impressionantes:

• Alto desempenho : o código WASM é executado com eficiência e rapidez.
• Tamanho compacto : O formato binário do WASM garante um espaço pequeno.
• Portabilidade : permite que o mesmo bytecode opere em qualquer tempo de execução compatível com WASM.
• Suporte a idiomas : WASM oferece suporte a uma ampla variedade de linguagens, de C/C++ e Rust a Go e Swift, entre outras.
• Compatibilidade com mecanismos JavaScript : WASM funciona perfeitamente em mecanismos JS.
• Sandboxing : Um sandbox padrão robusto restringe o acesso à memória e à CPU para evitar interferências externas.
• Inicialização rápida : os módulos WASM normalmente inicializam em milissegundos.

A comunidade WASM está melhorando ativamente a integração e o desempenho em diferentes linguagens de programação.

Caneta

Explorar o potencial do WASM e seu uso em blockchains nos leva de volta às limitações do Arbitrum Stylus.

Funcionamento da caneta

Aqui está uma análise simplificada de como a Stylus funciona:

1. Os desenvolvedores usam compiladores WASM padrão, como Clang ou Rustc, para compilar seus contratos inteligentes para WASM.
2. O bytecode WASM resultante é então carregado na cadeia Arbitrum em um estado compactado.
3. Por meio do método compileProgram da pré-compilação ArbWasm , o bytecode passa por instrumentação para segurança, medição de gás e é compilado em código nativo adaptado para o hardware do validador. Esta etapa é crucial para melhorar o desempenho e a segurança.
4. Após a invocação, o contrato é executado em um tempo de execução WASM, como o Wasmer, que é significativamente mais rápido e mais eficiente em termos de gás do que o EVM.

O terceiro passo aparentemente adicional é, na verdade, vital. A conversão do código WASM em código de máquina nativo acelera as velocidades de execução. Além disso, esta fase adicional de compilação ajuda a evitar "bombas de compilação".

Uma "bomba de compilação" é um código malicioso projetado para esgotar os recursos do sistema durante a compilação, potencialmente travando ou paralisando o compilador. Isso atua como um ataque de negação de serviço que visa dificultar o processo de desenvolvimento de software.

Preocupações com a caneta

Suporte de linguas

A Stylus ampliou a comunidade de desenvolvedores do Arbitrum para incluir C++ e Rust. No entanto, ainda não abrangeu as comunidades de desenvolvedores mais prevalentes da atualidade. Facilita a execução inteligente de contratos em navegadores, mas ainda não oferece suporte a JavaScript e Python.

Existem projetos em estágios iniciais tentando unir Python e JavaScript ao WASM. Porém, eles não estão prontos para adoção generalizada devido às complexidades com a coleta de lixo e às questões de desempenho.

Compatibilidade de idioma

Stylus atualmente oferece suporte a C/C++ e Rust por meio de seus SDKs. Esses SDKs são compatíveis com as ferramentas das respectivas linguagens. Eles também permitem a integração de bibliotecas de terceiros, como criptografia nativa. A principal restrição é o custo do gás associado a essas bibliotecas.

O Rust SDK está em sua fase inicial, carecendo de algumas funcionalidades. O C SDK não oferece suporte à exportação de funções com ABI. Além disso, nenhum SDK oferece suporte ao uso de modificadores.

No momento, a Stylus não possui um ambiente de teste local. Os desenvolvedores são incentivados a realizar testes nos SDKs. A testnet é a única opção para executar contratos inteligentes na Stylus. No entanto, a testnet ainda não implementou a verificação de contratos inteligentes.

Há um trabalho contínuo para portar vários tokens ERC e plataformas como Uniswap V2 para Stylus.

Escolha do idioma

Escolher entre uma linguagem específica de domínio (DSL), uma DSL incorporada (eDSL) ou uma linguagem de programação geral é um desafio. Os desenvolvedores devem pesar os benefícios de trabalhar "próximo ao metal" para controle em relação à facilidade de uso oferecida pelas abstrações de nível superior, que podem limitar a flexibilidade.

A criação de uma nova DSL requer tempo para desenvolver suas cadeias de ferramentas e ecossistema. Uma eDSL, como subconjunto de uma linguagem de programação geral, mantém a mesma semântica e sintaxe. Ele permite que os desenvolvedores usem linguagens e ferramentas existentes, o que pode simplificar o processo de aprendizagem. Um eDSL também oferece melhor interoperabilidade com código de uso geral. Por exemplo, um eDSL para JavaScript ou Python seria estratégico para envolver as maiores comunidades de desenvolvedores.

Linguagens de programação gerais requerem o uso de um SDK para desenvolvimento. Isso adiciona camadas de ferramentas, aumenta a verbosidade e reduz a expressividade. Também pode resultar em chamadas de API demoradas e operações complexas de objetos.

Escolher a linguagem certa e criar um eDSL pode ser um compromisso ideal. Poderia atrair desenvolvedores de comunidades populares e oferecer ferramentas fáceis de usar. Os dados atuais mostram que a comunidade Ethereum continua a ser a maior entre os desenvolvedores de criptografia. No entanto, ecossistemas como Polkadot, Cosmos e Solana, que usam Rust para contratos inteligentes, também atraem um número significativo de desenvolvedores e experimentam um rápido crescimento.

Desempenho

WASM tem o potencial de aumentar significativamente a velocidade de execução e reduzir o tamanho do pacote. Embora a Stylus não tenha sido implantada na rede principal, benchmarks de outras redes servem como referência útil.

Esses benchmarks indicam que os tempos de execução podem ser reduzidos de 4 a 8 vezes e o tamanho compilado pode ser reduzido pela metade.

A Stylus impõe um limite no tamanho dos contratos, que é de cerca de 128 KB não compactados. Essa restrição torna difícil migrar contratos inteligentes muito grandes de linguagens como Solidity para Stylus. Essa limitação é evidente na base de código da Stylus:

 // arbos/programs/programs.go const MaxWasmSize = 128 * 1024 // Maximum WASM size allowed const initialFreePages = 2 // Number of initial free pages const initialPageGas = 1000 // Gas cost for an initial page const initialPageRamp = 620674314 // Adjusts for a target size cost const initialPageLimit = 128 // Maximum number of pages allowed const initialInkPrice = 10000 // Ink price per EVM gas const initialCallScalar = 8 // Scalar for call cost

É importante observar que o WASM incorre em alguma sobrecarga para inicialização e desligamento. Para operações muito leves, o EVM pode ser mais econômico que o WASM.

Interoperabilidade EVM-WASM

EVM e WASM usam os mesmos slots de armazenamento e árvore de estados. A Stylus alcança interoperabilidade com EVM implementando APIs EVM dentro do WASM. Essa integração utiliza o modo Host I/O amplamente adotado no WASM. Abaixo está a lista completa de APIs EVM suportadas no WASM, indicando suporte abrangente de interoperabilidade.

 read_args write_result storage_load_bytes32 storage_store_bytes32 call_contract delegate_call_contract static_call_contract do_call create1 create2 do_create read_return_data return_data_size emit_log account_balance account_codehash evm_gas_left evm_ink_left block_basefee block_coinbase block_gas_limit block_number block_timestamp chainid contract_address msg_reentrant msg_sender msg_value native_keccak256 tx_gas_price tx_ink_price tx_prigin memoery_grow console_log_text console_log console_tee

Pré-compilações personalizadas

Pré-compilações personalizadas são um conceito inovador. Eles têm o potencial de integrar criptografia primitivas avançadas na cadeia com custos de execução reduzidos. Por exemplo, cálculos de tensores poderiam ser pré-compilados para diminuir os custos de aprendizado de máquina on-chain. No entanto, não há evidências de funcionalidade de pré-compilação personalizada na base de código atual. Embora existam pré-compilações para o EVM, elas não foram projetadas para serem trocáveis.

É provável que esses recursos ainda estejam sendo desenvolvidos, aproveitando as capacidades do WASM. Isso permitiria ao EVM chamar funções escritas em WASM, que são então compiladas em código de máquina.

Reentrada

Em contraste com o modelo de ator do CosmWasm, que não oferece suporte à reentrada, o Rust SDK da Stylus inclui a reentrada como um recurso opcional. Por padrão, esse recurso está desativado. Os desenvolvedores têm a opção de habilitar a reentrada em seus contratos.

A ativação da reentrada afeta a API, pois os desenvolvedores devem garantir a limpeza do cache de armazenamento durante as chamadas e considerar outras medidas de segurança. Esta precaução é essencial para evitar possíveis vulnerabilidades associadas a chamadas reentrantes.

Conclusão

WASM está ganhando popularidade no domínio nativo da nuvem, com muitos blockchains adotando-o para execução inteligente de contratos. Embora a Arbitrum não seja pioneira nesta integração, a sua implementação poderá ser altamente impactante. O WASM não está posicionado para revisar completamente o cenário do blockchain ou substituir o EVM. No entanto, isso poderia aumentar a vantagem da Arbitrum contra os zk-rollups emergentes. O termo "EVM+" da Arbitrum descreve apropriadamente este cenário. O EVM estabelece as bases para plataformas de contratos inteligentes e o WASM pode fornecer um aumento adicional de desempenho para o Arbitrum.