O lançamento do EOS EVM é o evento mais aguardado pela comunidade neste trimestre. Após o trabalho de diversas equipes durante mais de um ano, o EOS EVM será lançado no dia 14 de abril.
Assim que o EOS EVM estiver ativo, a EOS será exposta a uma série de novos desenvolvedores e projetos de outros ecossistemas. O EOS EVM está posicionado para ser um dos EVMs de maior desempenho do mercado, mantendo a compatibilidade e a paridade de recursos com os ambientes Solidity tradicionais. Neste artigo, vamos nos aprofundar no que torna essa peça crítica de infraestrutura tão poderosa e explicar um pouco da arquitetura por trás dela.
Você pode ouvir o bate-papo com os desenvolvedores neste episódio no YouTube
EOS EVM em poucas palavras
EVM significa Ethereum Virtual Machine. No ecossistema Ethereum, é uma série de smart contracts que permitem aos desenvolvedores implantar e executar aplicativos descentralizados (dApps) escritos em Solidity. O EOS EVM é uma emulação do Ethereum EVM, alojado em um smart contract EOS.
Ele oferece paridade de recursos com outros EVMs no espaço, mas com velocidade, desempenho e compatibilidade mais avançadas. Tudo isso graças à arquitetura do design e à natureza do EOS nativo.
EOS EVM: o ativador Ethereum
Quando o EOS foi lançado pela primeira vez, muitos se referiram a ele como um assassino de Ethereum, mas esse nunca foi o objetivo do EOS e isso não muda com o lançamento do EOS EVM. Em vez disso, o EOS EVM será um ativador do Ethereum, permitindo que os desenvolvedores do Solidity acessem escalabilidade em seus projetos.
A funcionalidade completa do EOS nativo, desenvolvida pelo Antelope.io, mal foi explorada. Portanto, há muitas novas oportunidades de desenvolvimento para criar a próxima geração de aplicativos Web3 nessa camada. Mas essa oportunidade de crescimento é uma faca de dois gumes. Atualmente, há uma falta de ferramentas adequadas, recursos educacionais e infraestrutura que possam permitir que os desenvolvedores dApp comecem a funcionar rapidamente na camada nativa.
Por outro lado, a linguagem nativa do Ethereum, Solidity, tornou-se um pilar da indústria Web3. Há um grande número de ferramentas, tutoriais, projetos e desenvolvedores de código aberto que vêm crescendo no ecossistema Ethereum desde seu lançamento inicial em 2015. Portanto, é muito fácil para um novo desenvolvedor aprender os fundamentos do desenvolvimento Web3 e começar a construir o mais rápido possível acessando as bibliotecas do Solidity.
Com o lançamento do EOS EVM, os desenvolvedores recebem o melhor dos dois mundos, combinando o desempenho da pilha de tecnologia EOS com os recursos acessíveis da comunidade Ethereum. Por causa disso, habilitar o desenvolvimento do Solidity no EOS é o próximo grande passo para a adoção em massa da rede.
O papel do EOS Native na adoção em massa
Apesar do foco atual no EOS EVM, a camada nativa do EOS continua sendo um produto principal do ecossistema. Com o próximo lançamento do Leap v4.0.0, o EOS nativo continuará a ser inovado em conjunto com o EOS EVM.
O EOS nativo é escrito em C++, uma linguagem popular entre os desenvolvedores tradicionais devido à sua velocidade e bibliotecas robustas. É frequentemente usado em projetos técnicos que possuem requisitos de desempenho rígidos, como sistemas operacionais e jogos.
Devido a essa arquitetura subjacente, os smar contracts construídos no EOS nativo são muito mais eficientes e geralmente preferidos por desenvolvedores que entram no espaço da Web2 ou de outras áreas tradicionais da ciência da computação. Com o GameFi em ascensão, o EOS nativo continua sendo um forte vetor de adoção, permitindo que os desenvolvedores de jogos que já estavam construindo em um ambiente Web2 integrem perfeitamente os elementos Web3 conforme necessário.
À medida que o trabalho de infraestrutura continua no EOS nativo e as ferramentas atuais do ecossistema Ethereum são lançadas no EOS EVM, surgirão oportunidades de inovação que não serão possíveis em nenhum outro ecossistema. Pensando nisso, a EOS está se posicionando como um ambiente de desenvolvimento de soma positiva. O lugar perfeito para veteranos da Web3 ou para aqueles que estão entrando no espaço para coordenar recursos e inovar de forma colaborativa.
Sutilezas técnicas do EOS EVM
Há muita coisa acontecendo sob o capô do EOS EVM para garantir que ele maximize o desempenho e a facilidade de uso. Aqui estão apenas algumas das opções de design inovadoras que foram implementadas no ano passado.
Arquitetura Silkworm
Um grande aumento de arquitetura que contribuiu para a mudança na linha do tempo de lançamento foi a implementação do Silkworm como o cliente de execução do EOS EVM. Silkworm é uma implementação C++ de um nó Ethereum, sob a especificação da Erigon. Ele está sendo usado para dar suporte ao RPC e aumentar a compatibilidade nessa área.
O objetivo de seu design é ser o cliente Ethereum mais rápido, sem sacrificar o desempenho ou a legibilidade de seu código. Abaixo estão os principais destaques que contribuem para o poder do Silkworm, conforme apresentado em um artigo da EtherWorld:
- O Silkworm é mais fácil de entender, pois a base de código é nova e não contém nenhum recurso herdado importante.
- Tem um sentimento neutro na comunidade de desenvolvedores.
- O Silkworm é licenciado sob a licença Apache-2.0. Esta licença é Permissiva, ou seja, tem menos restrições e pode ser usada na maioria dos projetos.
- O Silkworm usa evmone como seu interpretador EVM, que já é conhecido por ser a implementação EVM mais rápida e totalmente compatível.
- O Silkworm usa MDBX, que é o armazenamento de valor-chave integrado mais rápido, com transações totalmente ACID.
Uma das principais razões para esse projeto de arquitetura é atender às solicitações de RPC de maneira escalável e totalmente compatível com outras áreas do ecossistema. Desenvolvedores e usuários exigem métodos para acessar o estado mais recente do ambiente EVM para consultar dados na chain ou gerar novas transações. É aqui que o RPC entra em jogo.
Uma transação EVM é processada primeiro na blockchain EOS pelo contrato EVM. Posteriormente, ele é extraído da blockchain EOS por um EVM node baseado em Silkworm separado para ser reprocessado para que o node mantenha sua visão do estado do ambiente EVM em sincronia com o que o contrato deve ver. Esse estado é o que permite que o RPC node atenda a solicitações RPC padrão de clientes, como uma carteira MetaMask.
Ao manter os RPC nodes separados dos nós Leap que processam o blockchain EOS, novas instâncias dos RPC nodes podem ser criadas como um meio de dimensionar para atender às demandas das solicitações RPC do cliente. Cada RPC node adicional, que só precisa rastrear o estado do EVM, pode simplesmente ser alimentado com blocos EOS de um número muito menor de Leap nodes, que são responsáveis por rastrear todo o estado EOS.
Além disso, um grande benefício do uso do Silkworm, em oposição a uma implementação de node alternativo, no EOS EVM é que ele permite que muito código principal seja compartilhado entre o contrato EVM e os nodes que atendem às solicitações RPC. Isso reduz o risco de incompatibilidade entre os dois ambientes. Como o Silkworm é implementado em C++, era trivial compilar em um WebAssembly e executar dentro do contrato EVM. Manter a compatibilidade entre os dois ambientes inerentemente compartilhando o mesmo código tem sido uma vantagem especialmente importante, pois foram necessárias alterações adicionais no código do Silkworm para oferecer suporte a funções personalizadas no EOS EVM, como a ponte confiável.
Com tudo isso em mente, apesar dos atrasos causados, a migração para o Silkworm tornou-se um aspecto importante do EOS EVM.
Criptografia primitiva
Uma discussão importante no cenário atual da Web3 é a da privacidade do usuário. À medida que mais aplicativos corporativos entram no espaço, a implementação da tecnologia de preservação da privacidade torna-se ainda mais necessária. Isso levou a um aumento na popularidade de ferramentas como zk-SNARKS, que não podiam ser executadas no EOS até recentemente.
Quando ocorreu o hard fork do Leap 3.1, o recurso Crypto Primitives foi introduzido no protocolo Antelope para habilitar novas funcionalidades que poderiam suportar esta e outras operações complexas. O recurso disponibiliza novas funções de host para todos os contratos EOS, enquanto mapeia 1 para 1 com as pré-compilações de criptografia Ethereum.
O ecossistema Ethereum já possui muitas dessas funções e elas podem ser executadas em teoria. No entanto, taxas caras de gás e transações lentas podem levar a obstáculos técnicos e econômicos. Com o EOS EVM, essas barreiras desaparecem e os desenvolvedores podem experimentar bibliotecas que seriam difíceis de executar em outros ambientes.
Além de trazer a funcionalidade do zk-SNARKS para o EOS EVM, os desenvolvedores agora podem aproveitar as mesmas primitivas na camada nativa do EOS. Isso novamente desempenhará um papel importante na adoção do EOS nativo, juntamente com o EOS EVM.
Tempos de bloco de 1 segundo
Conforme observado anteriormente, desempenho e compatibilidade foram considerações importantes no desenvolvimento do EOS EVM. Ambos entraram em jogo ao tomar uma decisão sobre o quão rápido os tempos de bloqueio EVM deveriam ser. Enquanto o EOS nativo possui tempos de bloco de meio segundo, os tempos de bloco EOS EVM são de um segundo.
Tempos de bloco de meio segundo são mais rápidos do que um segundo em teoria, mas na prática é mais complicado. Primeiro, a métrica discutida aqui é a latência e não a taxa de transferência. O EOS EVM se beneficia do alto rendimento habilitado pela blockchain EOS, independentemente de quais tempos de bloco foram escolhidos. Em segundo lugar, na prática, a latência real observada desde o envio de uma transação até a confirmação de que ela está incluída em um bloco não cai pela metade simplesmente reduzindo o tempo de bloqueio de um segundo para meio segundo; a redução na latência é menos significativa do que isso. Portanto, diminuir o tempo de bloqueio de um segundo para meio segundo traz pequenos ganhos de desempenho, mas traz perdas potencialmente significativas no lado da compatibilidade do design.
Isso se deve às especificações do Ethereum, em relação a qual é o intervalo de tempo do bloco, o opcode EVM para retornar o timestamp do bloco atual tem apenas uma resolução de segundos. Isso significa que para haver um mapeamento de blocos um-para-um, onde cada bloco EOS corresponde a um bloco EVM, é necessário truncar o carimbo de data/hora e enviar um carimbo de data/hora idêntico para dois blocos consecutivos distintos.
Embora a duplicação do carimbo de data/hora em blocos distintos possa não causar muitos danos, seria um risco de projeto porque é uma quebra na forma como os contratos tradicionais do Solidity esperam interagir com um EVM. Ao desenvolver o EOS EVM, era importante garantir que os desenvolvedores vindos da Ethereum tivessem uma experiência o mais semelhante possível à sua cadeia nativa. Então a escolha foi feita por um tempo de bloqueio que teria o menor dano à compatibilidade.
Além disso, o design possibilita desacoplar os tempos de bloqueio nativo e EVM. Isso significa que, no futuro, se a rede EOS decidir alterar a frequência do bloco, isso não afetará o tempo de execução do EVM. Embora não haja planos para fazer atualizações a esse respeito, os desenvolvedores podem ter certeza de que os dApps criados no EOS EVM serão compatíveis com quaisquer alterações futuras na arquitetura de rede do EOS.
Acesse o financiamento, construa e prepare-se para o lançamento!
O EOS EVM está posicionado para se tornar um dos EVMs mais amplamente adotados e permitir uma nova onda de desenvolvedores Ethereum em EOS. Isso se deve em grande parte às escolhas arquitetônicas explicadas neste artigo, incluindo:
- A implementação C++ do Silkworm para dar suporte ao RPC, permitindo que os nós sejam dimensionados para atender às demandas de RPC dos clientes.
- A arquitetura Crypto Primitives foi introduzida com o Leap 3.1, permitindo zk-SNARKS e outros cálculos complexos tanto no EOS EVM quanto no EOS nativo.
- Tempos de bloco de um segundo, o que permite ótimo desempenho, mantendo a compatibilidade máxima entre o EOS EVM e o Ethereum EVM tradicional.
Nesta semana, o EOS EVM alcançou o código completo e o novo testnet foi lançado no dia 27 de março. Com a mainnet entrando em operação em 14 de abril, nunca houve um momento melhor para começar a desenvolver em EOS.
Apesar de todos os avanços pelos quais o EOS EVM passou, o trabalho não está diminuindo no EOS nativo. Na verdade, com menos recursos necessários no EVM neste ponto, os desenvolvedores de protocolos principais podem dedicar mais atenção ao EOS nativo. Isso garantirá que o EOS nativo continue a servir como um produto principal da rede EOS, enquanto ainda permite que os projetos do Solidity aproveitem todos os benefícios que o EOS tem a oferecer.
Quer alguém esteja construindo em EOS EVM ou EOS nativo, há muitos recursos e financiamento disponíveis para ajudar os projetos a começarem a funcionar rapidamente.
Fonte: https://eosnetwork.com/blog/eos-evm-architecture-deep-dive/
