Como migrar da Ethereum para a Solana: um guia para devs

Sobre o que é este artigo?

A Ethereum é uma das inovações mais importantes dos últimos tempos. Pela primeira vez na história, temos uma plataforma descentralizada e global criada para a coordenação social, com potencial para revolucionar muitos setores. Apesar de sua importância, o ambiente de execução da Ethereum, a Ethereum Virtual Machine (EVM), não foi criado para aplicações voltadas ao consumidor em seu estado atual. É uma rede de thread única, baseada em gas e com taxas voláteis. Em contrapartida, a Solana se destaca como uma rede de alto throughput e baixa latência. Ela oferece uma infraestrutura paralelizada com taxas baixas e previsíveis. A Solana enfrenta diretamente as limitações da EVM e aprimora seu projeto original, tornando-se uma opção atraente para desenvolvedores que desejam criar aplicações escaláveis e eficientes.

Este artigo é um guia abrangente de migração para desenvolvedores de EVM interessados em criar aplicações na Solana. Ele aborda as diferenças fundamentais entre as duas redes, examinando os mecanismos de consenso da Ethereum e da Solana, como elas processam transações e as linguagens usadas no desenvolvimento de contratos inteligentes. Em seguida, aborda o modelo de contas da Solana, que propõe uma abordagem mais uniforme e multifacetada para contas. O artigo também explora Solang e Neon EVM, duas ferramentas compatíveis com Solidity que aprimoram a experiência de desenvolvimento na Solana.

Diferenças fundamentais

Esta seção explora as principais diferenças entre Ethereum e Solana, duas blockchains que buscam criar uma máquina de estado descentralizada para coordenação global. No entanto, elas diferem significativamente em seus mecanismos de consenso, métodos de processamento de transações e linguagens usadas no desenvolvimento de contratos inteligentes. Uma compreensão mais profunda dessas diferenças fundamentais evidencia a vantagem específica da Solana sobre a Ethereum como uma máquina de estado global de alto desempenho.

Mecanismos de consenso

Os mecanismos de consenso sustentam todas as redes blockchain. Eles determinam como as transações são verificadas e como os blocos são adicionados à blockchain de maneira segura, eficiente e descentralizada. Tanto a Ethereum quanto a Solana são redes de Proof of Stake (PoS). Embora compartilhem uma base comum em PoS, suas abordagens para alcançar consenso diferem por causa de suas regras de confirmação.

A Ethereum usa o Gasper, uma combinação do Casper the Friendly Finality Gadget (Casper-FFG) com o algoritmo de escolha de fork LMD-GHOST. Essa combinação forma o mecanismo de consenso que protege a Ethereum.

O Casper é um sistema de finalidade baseado em PoS que eleva o status de confirmação de um bloco para “finalizado”. Um bloco é considerado finalizado na Ethereum quando dois terços do stake total votam a favor da inclusão desse bloco e outro bloco é criado sobre ele. Como a finalidade exige que dois terços do stake total concordem que um bloco é canônico, um invasor não pode criar uma cadeia finalizada alternativa sem possuir ou manipular dois terços do stake total e destruir pelo menos um terço por meio de slashing. O Casper permite que novos participantes sincronizem com confiança com a cadeia canônica. 

LMD-GHOST é um acrônimo de “Latest Message-Driven Greedy Heaviest Observed Sub-Tree”. É um algoritmo que decide qual fork da Ethereum deve ser seguido. Para isso, ele escolhe o fork que recebeu mais apoio, ou “peso”, dos validadores da rede — daí a expressão “greedy heaviest sub-tree”. Em seguida, garante que apenas a mensagem mais recente de cada validador seja considerada. Sempre que um novo bloco é proposto à Ethereum, os validadores usam essa regra para decidir se ele deve fazer parte da cadeia canônica.

Em comparação, a Solana usa hashes de Proof of History (PoH) para alcançar consenso. Apesar do nome confuso, PoH não é um algoritmo de consenso. É uma forma de comprovar o tempo em uma rede adversarial. Mais especificamente, é uma função criptográfica de registro de data e hora que permite aos nós concordarem sobre uma ordem de eventos sem se comunicarem entre si. O líder (ou seja, o validador que adiciona entradas ao livro-razão) adiciona registros de data e hora aos blocos para comprovar que algum tempo se passou desde o último bloco. 

A adição desses registros de data e hora estabelece um registro histórico, pois comprova que os dados existiam em um momento específico. Um registro histórico é criado usando uma função hash sequencial resistente à pré-imagem, na qual cada hash depende de seu antecessor. As Verifiable Delay Functions (VDFs) são essenciais para gerar esses hashes. Elas garantem que cada hash seja criado com base no anterior e incorpore o tempo decorrido desde então. A integração das VDFs introduz uma dimensão temporal ao processo de hashing, permitindo criar uma sequência verificável de eventos com registro de data e hora na Solana.

Depois de entender como o mecanismo Proof of History da Solana cria uma sequência confiável de eventos por meio de registros de data e hora criptográficos, é essencial compreender como isso se integra ao mecanismo de consenso da Solana, o Tower BFT. O Tower Byzantine Fault Tolerance (BFT) é a variante da Solana do modelo tradicional de consenso Byzantine Fault Tolerance, otimizada para PoH. O Tower BFT usa o registro histórico criado pelo PoH como estrutura de referência. Essa estrutura permite que os validadores votem de forma eficiente e precisa sobre o estado do livro-razão. O Tower BFT funciona por meio de votos dos validadores que ficam bloqueados por um longo período, com o comprometimento aumentando à medida que mais votos são adicionados. Graças ao PoH, os validadores podem tomar decisões mais rápidas e bem fundamentadas sobre o estado do livro-razão sem precisar se comunicar entre si. A combinação de PoH e Tower BFT acelera o consenso e aumenta a segurança e a confiabilidade da rede. O resultado é um ambiente blockchain escalável e de alto throughput, no qual as transações são confirmadas rapidamente.

Processamento de transações e ambientes de execução

A eficiência e a escalabilidade de uma blockchain são determinadas principalmente por sua capacidade de processamento de transações e por seu ambiente de execução. Esses fatores determinam a velocidade de execução das transações e a eficiência de custos das operações na rede. A abordagem de uma blockchain ao processamento de transações e as particularidades de seus ambientes de execução afetam significativamente a experiência do desenvolvedor.

O ambiente de execução da Ethereum opera como uma máquina de pilha determinística e de thread única, conhecida como Ethereum Virtual Machine (EVM). Ela se comporta como uma função matemática. Ou seja, a EVM produz uma saída determinística quando recebe uma entrada. É útil definir a Ethereum como tendo uma função de transição de estado: f(S, T) = S’. A partir de um estado antigo (S) e de um novo conjunto de transações válidas (T), a EVM produz um novo estado de saída válido (S’). A EVM sempre alcançará o mesmo estado final quando receber o mesmo conjunto de transações. Isso é fundamental para manter a consistência entre os nós da rede.

A EVM processa transações sequencialmente. O processamento sequencial garante que cada transação seja executada em um ambiente que reflita com precisão o estado da rede até aquele momento. A execução sequencial permite calcular com precisão as alterações de estado e os custos de gas. Essa previsibilidade oferece aos desenvolvedores e usuários uma compreensão clara dos resultados e custos das transações.

A Ethereum simplifica o ambiente de execução de contratos inteligentes ao adotar um modelo de execução de thread única. Isso oferece aos desenvolvedores a vantagem de alterações de estado previsíveis, pois cada transação é processada sequencialmente. Essas alterações previsíveis tornam o ambiente de desenvolvimento da Ethereum possivelmente mais acessível para novos desenvolvedores, já que eles podem se concentrar mais na lógica dos contratos inteligentes do que nas complexidades da execução. No entanto, essa simplicidade dificulta a escalabilidade. O processamento sequencial limita o throughput da rede. Isso pode causar congestionamentos, tempos de espera maiores para transações e taxas de gas mais altas durante períodos de alta demanda. Como cada transação consome gas, os desenvolvedores precisam otimizar a eficiência no uso de gas. Essa otimização melhora a experiência geral do usuário e combate os períodos de congestionamento, nos quais um código ineficiente pode tornar as aplicações inutilizáveis para o usuário comum.

Os desenvolvedores da Solana não precisam se preocupar em otimizar o uso de gas como os desenvolvedores da Ethereum. A Solana foi projetada como uma máquina de estado de alto throughput e baixa latência, conhecida como Solana Virtual Machine (SVM). Um componente essencial da SVM é o Sealevel. Ele é um mecanismo de execução que processa transações em paralelo. Na Solana, cada transação informa ao ambiente de execução quais partes do estado serão lidas ou gravadas durante sua execução. O ambiente de execução processa em paralelo as transações sem conflitos e as transações que leem o mesmo estado. O Sealevel otimiza a execução de contratos inteligentes distribuindo a carga de trabalho das transações entre várias threads no hardware de um validador. Assim, enquanto o validador processa uma transação em um núcleo, outra pode ser processada simultaneamente em outro.

O paralelismo nativo da Solana reduz significativamente os custos das transações. As transações da Solana têm duas taxas: uma taxa-base e uma taxa de prioridade. A taxa-base é fixada em 5.000 lamports por assinatura; a maioria das transações tem apenas uma assinatura. A taxa de prioridade é opcional e permite que uma transação seja priorizada em relação a outras. Transações com uma taxa de prioridade maior são priorizadas de forma não determinística pelo agendador. As taxas de transação costumam ficar abaixo de US$ 0,001, com a taxa média de transações sem voto na faixa de 0,000005 a 0,00007 SOL. O limite superior está acima do normal devido ao aumento recente no uso de taxas de prioridade. Com o preço atual do SOL em ~US$ 98,96, essa taxa equivale a aproximadamente US$ 0,000494 a US$ 0,006968. 

Essas taxas também são previsíveis. A Solana usa mercados de taxas localizados para gerenciar a demanda. O espaço de bloco é estruturado para impedir que um único ponto de alta atividade, como a emissão muito aguardada de um NFT, domine o espaço de bloco e aumente as taxas em toda a rede. Somente as transações que tentam acessar um ponto específico de alta demanda terão taxas maiores. Os mercados de taxas localizados permitem taxas de prioridade sem provocar guerras generalizadas de gas. Essa localização difere de redes baseadas em gas, como a Ethereum, nas quais as transações são processadas sequencialmente e o congestionamento global provoca taxas voláteis.

A Ethereum é um ambiente de execução de thread única que processa apenas um contrato por vez. Atualmente, ela não aproveita o hardware moderno com vários núcleos, o que resulta na subutilização do hardware dos validadores. O objetivo de manter baixos os requisitos de hardware para os nós aumenta as limitações da Ethereum no processamento de transações. Em comparação, os recursos de processamento paralelo da Solana permitem que ela processe mais transações usando todos os núcleos disponíveis de um validador. Junto aos mercados de taxas localizados, isso torna a Solana uma máquina de estado global de desempenho muito superior. 

Linguagens de contratos inteligentes

A principal linguagem para desenvolver contratos inteligentes na Ethereum é Solidity. É uma linguagem estaticamente tipada, com chaves, criada para desenvolver contratos inteligentes executados na EVM. Ela é fortemente influenciada por JavaScript, C++ e Python, o que facilita o aprendizado para desenvolvedores familiarizados com essas linguagens.

Yul é uma linguagem intermediária de baixo nível otimizada para blockchains compatíveis com EVM. Yul oferece aos desenvolvedores mais controle sobre a execução do bytecode, sendo altamente eficiente para ajustar o consumo de gas e gerenciar outras operações de baixo nível. Os desenvolvedores podem criar contratos mais eficientes programando diretamente em Yul ou usando-a como destino de compilação.

Vyper é uma linguagem popular inspirada em Python que enfatiza a simplicidade e a segurança. Ela tem deliberadamente menos recursos que Solidity, pois busca reduzir a complexidade e possíveis vulnerabilidades de segurança. A filosofia de design da Vyper prioriza acima de tudo a legibilidade e a facilidade de auditoria. Essa abordagem inspirou o desenvolvimento de linguagens semelhantes, como Fe, e de linguagens compiladas para Vyper, como Dasy.

Rust é a lingua franca do desenvolvimento de contratos inteligentes — chamados informalmente de programas — na Solana. É uma linguagem rápida e eficiente no uso da memória, com desempenho comparável ao C++. Essas características a tornam adequada para desenvolver aplicações em uma rede de alto throughput e baixa latência. O abrangente sistema de tipos e o modelo de propriedade de Rust garantem a segurança da memória e das threads, levando os desenvolvedores a criar aplicações confiáveis e seguras. 

Embora Rust tenha uma curva de aprendizado acentuada para quem não conhece programação de sistemas, a contrapartida é a capacidade de criar código robusto e eficiente. A maior parte do desenvolvimento em Rust é feita com o Anchor. Anchor é um framework opinativo que simplifica o desenvolvimento de programas ao reduzir código repetitivo, realizar diversas verificações de segurança padrão e otimizar o processo de (des)serialização. Com isso, conhecimentos avançados de Rust são menos importantes para começar. Como referência, a documentação do Anchor recomenda que os usuários conheçam os nove primeiros capítulos do Livro de Rust, ou seja, os fundamentos de Rust. O Solana Playground tem vários tutoriais de Anchor para ajudar você a começar.

Embora Rust seja a linguagem preferida, os desenvolvedores não estão limitados a ela. É possível usar C, C++ e qualquer linguagem direcionada ao backend BPF do LLVM, ou seja, qualquer linguagem que possa ser compilada em bytecode BPF. Para quem conhece linguagens inspiradas em Python, como Vyper, a Seahorse Lang permite escrever programas em Python. Assim, os desenvolvedores obtêm a facilidade de uso do Python e mantêm as mesmas garantias de segurança que teriam ao programar em Rust. Há vários tutoriais úteis de Seahorse disponíveis para você começar a programar na Solana hoje mesmo, como a Seahorse University e o Seahorse Cookbook.

Os desenvolvedores que migram da Ethereum para Rust não estão restritos a Rust. Embora seja recomendável aprender e usar frameworks como Anchor e Seahorse devido à popularidade e às garantias de segurança que oferecem, isso nem sempre é viável. Graças aos avanços recentes da Solang e da Neon Labs com seu compilador e ambiente de desenvolvimento compatível com EVM, os desenvolvedores podem usar Solidity no desenvolvimento de programas. Solidity tem seu lugar na Solana. Para começar a desenvolver programas em Solidity, precisamos examinar mais profundamente as particularidades do modelo de programação da Solana. Compreender o modelo de contas da Solana é essencial para os desenvolvedores que fazem essa transição, pois ele é a base do desenvolvimento e da interação de programas na rede.

Entendendo o modelo de contas

A Ethereum divide as contas em duas categorias principais: contas de propriedade externa (EOAs) e contas de contrato. As EOAs são o tipo padrão de conta para usuários. Elas são controladas por chaves privadas e podem manter saldos em Ether, enviar transações e interagir com contas de contrato. Por outro lado, as contas de contrato se distinguem porque suas operações são regidas pelo código de contrato inteligente incorporado a elas. Elas não podem iniciar transações de forma autônoma e só podem agir em resposta a transações recebidas de EOAs ou de outras contas de contrato.

A Solana adota um modelo de contas mais uniforme, tratando-as como contêineres multifacetados que armazenam dados de forma persistente. Esse modelo permite que qualquer conta seja um programa, reduzindo a distinção tradicional entre uma conta e um contrato inteligente. Ao contrário da Ethereum, onde código e estado são combinados em uma única conta, os programas da Solana não têm estado. Isso significa que eles não armazenam nenhum estado internamente. Em vez disso, todos os dados necessários para operar são armazenados em uma conta separada e passados por referência em uma transação. Passar contas por referência permite implantar um único programa genérico capaz de interagir com contas diferentes. O modelo de contas da Solana separa código e dados, promovendo um ambiente de desenvolvimento mais eficiente e modular. Isso é vantajoso para usuários que desejam interagir com vários protocolos sem mover ativos entre programas diferentes. Tudo na Solana é uma conta. 

As contas da Solana podem ser classificadas como executáveis e não executáveis. Em termos simples, contas executáveis são capazes de executar código. Contas não executáveis são usadas para armazenar dados sem a capacidade de executar código. Isso ocorre porque elas não armazenam código.

Contas executáveis são contas que contêm programas. Os programas podem possuir contas adicionais, ler ou creditar outras contas, modificar dados ou debitar as contas que possuem. As contas executáveis podem ser subdivididas em programas on-chain ou nativos. Programas on-chain são códigos escritos por usuários e implantados na rede. Eles podem ser atualizados por sua autoridade de atualização, que normalmente é a conta que os implantou. Programas nativos são um subconjunto especial de contas executáveis, análogo aos contratos pré-compilados da Ethereum, mas com funcionalidades mais amplas. Esses programas estão integrados ao núcleo da Solana e fornecem as funcionalidades necessárias para a operação dos validadores. Um exemplo de programa nativo é o System Program. Esse programa é responsável por criar novas contas, alocar dados de contas, atribuir contas a programas, transferir lamports das contas que possui e pagar taxas de transação. Uma lista completa dos programas nativos está disponível aqui.

Independentemente de serem executáveis ou não executáveis, todas as contas têm os mesmos campos: 

• Um campo lamports para acompanhar o saldo nativo de uma conta em SOL
• Um campo de dados, que se refere ao array de bytes de dados brutos armazenado pela conta
• Um campo de proprietário que indica o programa capaz de modificar essa conta
• Um campo de signatário, usado em transações para indicar se a conta pode aprová-las
• Um campo gravável para especificar se os dados de uma conta podem ser modificados. Isso facilita o processamento paralelo ao marcar as contas incluídas nas transações como somente leitura ou graváveis
• Um campo executável para indicar se uma conta armazena um programa
• Um campo de época de aluguel para indicar a próxima época em que a conta deverá pagar aluguel

O aluguel é um custo de armazenamento para manter contas ativas na Solana e garantir que elas permaneçam na memória dos validadores. Isso exige que as contas mantenham um saldo mínimo para continuar ativas. O aluguel reduz o excesso de estado ao garantir que a rede recupere, com o tempo, contas sem uso ou com saldo insuficiente. Atualizações recentes eliminaram as contas que pagam aluguel na mainnet. Em vez disso, todas as contas devem ser isentas de aluguel no momento da criação. Uma conta é isenta de aluguel quando mantém um saldo mínimo equivalente a dois anos de pagamentos de aluguel. Ferramentas como o Test Drive e o subcomando rent da Solana CLI podem ser usadas para estimar a quantidade de SOL necessária para que uma conta seja isenta de aluguel. Isso difere do sistema de alocação de recursos da Ethereum, no qual o armazenamento persiste até ser explicitamente removido. A abordagem da Solana oferece uma estrutura de custos mais previsível para o armazenamento de estado e, ao mesmo tempo, reduz seu excesso.

Endereços e Program Derived Addresses (PDAs)

Todas as contas são identificadas por seu endereço, uma chave pública exclusiva de 32 bytes. Isso difere do modelo de dados da Ethereum, em que os endereços têm 20 bytes. A Solana usa ed25519, ou seja, um esquema de assinatura EdDSA que utiliza SHA-512 e a curva elíptica Curve22519, para gerar endereços. Uma conta deve ser um ponto na curva ed25519 para ter um par de chaves válido. 

Program Derived Addresses (PDAs) são contas geradas fora da curva usando um bump, isto é, um valor que desloca a saída para fora da curva. As PDAs exigem três elementos principais: o endereço do programa pai, um conjunto de seeds e um bump. As seeds são um array de strings que podem ter valores arbitrários. No entanto, a maioria dos desenvolvedores cria seeds específicas relacionadas a variáveis de estado no programa pai para criar estruturas de dados semelhantes a hashmaps. Assim, uma PDA é criada aplicando a função hash SHA-512 ao ID do programa, às seeds e ao bump.

O objetivo de as PDAs estarem fora da curva é garantir que somente o programa do qual uma PDA é derivada possa assinar em nome dela. Isso simplifica o fluxo de transações ao gerar assinaturas programaticamente, permitindo que dApps sem necessidade de confiança operem sem problemas e sem intervenção.

Interagindo com uma conta

Uma transação da Ethereum é uma ação que altera o estado e é iniciada por uma EOA. Contratos inteligentes não podem iniciar transações de forma independente; eles só podem reagir a elas. O código do contrato determina essas reações, e o custo de execução da transação é medido em gas. Os usuários precisam fornecer Ether suficiente para cobrir essa taxa de gas.

As transações da Ethereum normalmente realizam uma única operação, como chamar uma função específica de um contrato inteligente. Embora uma única transação possa causar várias alterações de estado dentro de um contrato, todas elas ficam restritas ao escopo dessa única chamada de contrato.

Na Solana, uma transação inclui um array de contas para leitura ou gravação, uma ou mais assinaturas e uma ou mais instruções. Uma instrução é uma diretiva para uma única invocação de programa. Ela é a menor unidade de lógica de execução e a unidade operacional mais fundamental. As instruções especificam o programa executor, todas as contas envolvidas e os dados operacionais. Os programas interpretam os dados de uma instrução e operam nas contas especificadas. Essa estrutura permite que uma única transação execute atomicamente uma série de ações em vários programas. Isso significa que todas as instruções são concluídas com sucesso ou falham em conjunto. O fluxo de transações da Solana difere do modelo da Ethereum, no qual uma transação geralmente está vinculada a um único contrato inteligente ou a uma ação de uma EOA.

As Cross-Program Invocations (CPIs) permitem que um programa invoque outro durante a mesma transação. A quantidade de bytes de dados de conta cobrada por unidade de computação durante uma CPI é de 250. Isso equivale a aproximadamente 50 MB com 200.000 unidades. As CPIs permitem usar assinaturas geradas programaticamente em chamadas entre programas. Isso é semelhante a um contrato inteligente da Ethereum chamando outro contrato de forma eficiente e atômica. No entanto, o programa invocador é interrompido até que o programa invocado termine de processar a instrução. A reentrância é limitada à autorrecursão direta, com uma profundidade fixa máxima de 4. Isso evita situações em que um programa invoca outro a partir de um estado intermediário sem saber que poderá ser chamado novamente mais tarde.

As transações da Solana seguem um limite de tamanho para manter a eficiência, semelhante ao limite de gas da Ethereum. No entanto, o foco está no tamanho dos dados. As transações da Solana seguem os padrões da Maximum Transmission Unit (MTU) do IPv6 para garantir a transmissão confiável de dados. Depois de reservar o espaço necessário para o cabeçalho, restam 1.232 bytes para os dados do pacote. A Solana introduziu transações versionadas para oferecer suporte a vários formatos de transação e superar as restrições de tamanho. Além do formato legado, ou seja, o formato de transação original, a Versão 0 foi lançada para oferecer suporte às Address Lookup Tables (ALTs). As ALTs armazenam endereços on-chain em uma estrutura de dados semelhante a uma tabela, na qual cada endereço é indexado por um índice u8 de 1 byte. Isso reduz significativamente o tamanho das transações, pois cada conta precisa de apenas 1 byte em vez de 32 bytes.

Solang

Solang é um compilador Solidity para Solana e Polkadot. Seu objetivo é oferecer compatibilidade de arquivos de código-fonte com a versão 0.8 do compilador Solidity da EVM, embora com algumas variações para se adequar às arquiteturas da Solana e da Polkadot. Um aspecto importante do Solang é o uso do LLVM, uma infraestrutura avançada de compilação. A flexibilidade do LLVM permite que o Solang amplie o suporte a outras linguagens de programação no futuro, facilitando implementações e compilações. Essa característica está alinhada ao objetivo do Solang de facilitar a transição de desenvolvedores para a Solana ou Polkadot e ampliar o escopo do desenvolvimento com Solidity. O Solang está em desenvolvimento contínuo, com foco em melhorar a compatibilidade, a eficiência e a facilidade de uso. É essencial que desenvolvedores de Ethereum que desejam levar suas habilidades para outras redes entendam o Solang e suas ressalvas.

Instalação

Há algumas maneiras de instalar o Solang. No Mac, é possível baixar o Solang com o Brew usando um tap privado:

brew install hyperledger/solang/solang

Outra maneira de instalar o Solang é usar os contêineres do Solang. Essa opção é ideal se você prefere usar o Docker, pois novas imagens são disponibilizadas automaticamente nesses contêineres. Há uma tag v.0.3.3 e uma tag latest:

docker pull ghcr.io/hyperledger/solang:latest

Uma das maneiras mais fáceis de instalar e usar o Solang é por meio do Anchor. Para começar, verifique se o Rust e o Node.js estão instalados no seu sistema. Usuários do Windows também precisarão configurar o Subsistema do Windows para Linux. Agora, precisamos instalar o conjunto de ferramentas da Solana. No Mac e no Linux, isso pode ser feito com o seguinte comando:

 sh -c "$(curl -sSfL https://release.solana.com/v1.17.13/install)"

Se você preferir outra versão do software, substitua “v1.17.13” pela tag da versão apropriada. Como alternativa, você pode usar um dos seguintes nomes simbólicos de canal: stable, beta ou edge. Dependendo do seu sistema, talvez seja necessário atualizar a variável de ambiente PATH. Se essa mensagem for exibida, copie e cole o comando recomendado abaixo para atualizar o PATH. Você pode confirmar a versão desejada do solana executando solana --version.

No Windows, abra uma instância do Prompt de Comando como Administrador. Copie e cole o comando a seguir para baixar o instalador da Solana em um diretório temporário:

cmd /c "curl https://release.solana.com/v1.17.13/solana-install-init-x86_64-pc-windows-msvc.exe --output C:\solana-install-tmp\solana-install-init.exe --create-dirs"

Depois, copie e cole o comando a seguir para instalar a versão mais recente da Solana: C:\solana-install-tmp\solana-install-init.exe v1.17.13. Quando a instalação terminar, pressione Enter.

Feche a janela do Prompt de Comando e abra uma nova instância como usuário comum. Confirme se a versão desejada do solana foi instalada executando solana –-version.

Em seguida, instale o Anchor.

Recomendamos instalar o Anchor usando o gerenciador de versões do Anchor (avm). Isso pode ser feito via cargo com o comando:

cargo install -git https://github.com/coral-xyz/anchor avm --locked --force.

Depois, instale e use a versão mais recente:

avm install latest
avm use latest

# Verify the installation
avm –version

A versão 0.28 do Anchor permite que desenvolvedores façam builds diretamente com o Solang. É possível criar um novo projeto Solang com o comando: anchor init project_name —solidity. Isso cria um novo programa Solang e um arquivo de teste que demonstra como interagir com o programa por meio do cliente.

Se você usa o Visual Studio Code, considere instalar a extensão do Solang para auxiliar no realce de sintaxe. Desative qualquer outra extensão ativa do Solidity para garantir que a extensão do Solang funcione corretamente.

Como criar um novo projeto

Crie um novo projeto com o comando anchor-init project_name –solidity. Isso cria um novo diretório com o nome do seu projeto. A flag Solidity informa ao Anchor que queremos usar o Solang. O diretório ./solidity do projeto fornecerá um programa inicial. O contrato terá a seguinte aparência:

@program_id("F1ipperKF9EfD821ZbbYjS319LXYiBmjhzkkf5a26rC")
contract test {
    bool private value = true;

    @payer(payer)
    constructor() {
        print("Hello, World!");
    }

    /// A message that can be called on instantiated contracts.
    /// This one flips the value of the stored `bool` from `true`
    /// to `false` and vice versa.
    function flip() public {
            value = !value;
    }

    /// Simply returns the current value of our `bool`.
    function get() public view returns (bool) {
            return value;
    }
}

Esse programa tem um constructor para criar o programa, inicializar a variável de estado value como true e registrar “Hello, World!” nos logs do programa. A função flip atualiza a variável de estado quando é chamada. A função get retorna o valor atual da variável de estado. Isso se parece com um contrato inteligente Solidity comum, mas há algumas ressalvas. A diferença mais significativa é o uso de anotações.

Anotações

As anotações são usadas para gerenciar contas. Observe a anotação @program_id(“...”). Ela é usada para especificar o endereço on-chain do programa, caso seja conhecido previamente. Se você quiser chamar um contrato por meio de uma chamada externa, o programa deverá ter a notação @program_id ou ser chamado usando o argumento {program_id: … }:

@program_id(“...”);

contract Foo {
	function hello() public pure {
		print(“Hello”);
	}
}

contract Foo2 {
	function bye() public pure {
		print(“Bye”);
	}
}

contract Bar {
	function new_foo() external {
		Foo.new();
	}
}

contract Bar2 {
	function new_foo(address new_foo_id) external {
		Foo2.new{program_id: new_foo_id}();
	}
}

Quando criamos um novo projeto, o contrato de exemplo fornecido tinha a anotação @payer sobre o construtor. Essa anotação define a conta que pagará pela inicialização da conta de dados do programa. A sintaxe @payer(payer) declara uma conta chamada payer, que será necessária em todas as chamadas ao construtor.

Quando um contrato é instanciado, ele exige uma conta de programa para armazenar o código executável e uma conta de dados para salvar as variáveis de estado. A conta de dados pode ser criada usando código no lado do cliente e, depois, passada para a transação que invoca o construtor. Como alternativa, a conta de dados pode ser criada pelo construtor. No mínimo, a anotação @payer deve ser fornecida. Uma seed e um bump devem ser fornecidos se a conta de dados for uma PDA. A anotação @seed especifica uma seed para derivar a PDA e pode ser um literal de string ou uma string hexadecimal com o formato hex”1234”. Se estiver antes de um argumento, a anotação de seed deverá fazer referência a um argumento do tipo bytes, address ou a um array de bytes de tamanho fixo. A anotação @bump especifica o valor usado para gerar um endereço fora da curva. Ele deve ser um único byte do tipo bytes1. A anotação opcional @space pode ser usada para especificar o tamanho da conta de dados. Ela é uma expressão uint64 que pode ser uma constante ou usar um dos argumentos do construtor. Segundo a documentação do Solang, no mínimo, @space deve ser o tamanho indicado ao executar o comando solang -v:

$ solang compile --target solana -v examples/solana/flipper.sol
...
info: contract flipper uses at least 17 bytes account data
…

Se um programa não tiver um construtor, essas anotações poderão ser combinadas com um construtor vazio. A documentação do Solang fornece o seguinte exemplo:

@program_id("Foo5mMfYo5RhRcWa4NZ2bwFn4Kdhe8rNK5jchxsKrivA")
contract Foo {

    @space(500 + 12)
    @seed("Foo")
    @payer(payer)
    constructor(@seed bytes seed_val, @bump bytes1 bump_val) {
        // ...
    }
}

As anotações de função são usadas para declarar as contas necessárias para funções externas:

• @account(foo) declara a conta foo como uma conta somente leitura
• @mutableAccount(bar) declara a conta bar como uma conta mutável
• @signer(fizz) declara a conta fizz como uma signatária somente leitura
• @mutableSigner(buzz) declara a conta buzz como uma signatária mutável

As contas declaradas com a anotação @payer no construtor podem ser acessadas dentro dele. As contas declaradas com anotações de função ficam disponíveis no vetor tx.accounts. Por exemplo, você usaria tx.accounts.ichigo para acessar a conta declarada @account(ichigo). Isso retornará a struct integrada AccountInfo. Essa struct segue a mesma estrutura descrita na seção “Entendendo o modelo de contas”. A nomenclatura é um pouco diferente:

• key: o endereço ou a chave pública da conta. É do tipo address
• lamports: o saldo de lamports da conta. É do tipo uint64
• data: os dados da conta. São do tipo bytes
• owner: o proprietário da conta. É do tipo address
• rent_epoch: a próxima época em que o aluguel da conta vencerá. É do tipo uint64
• is_signer: especifica se a conta assinou a transação. É do tipo bool
• is_writable: especifica se é possível gravar na conta nessa transação. É do tipo bool
• executable: especifica se a conta é um programa. É do tipo bool

Limitações

As principais incompatibilidades entre o Solang e o desenvolvimento tradicional para Ethereum são:

• msg.sender não está disponível na Solana. Com o modelo de contas, um contrato Rust pode acessar várias contas de dados. Qual delas consideraríamos o chamador? Em muitos casos, não é possível identificar uma única conta como chamador. Além disso, o runtime não tem um mecanismo para buscar contas chamadoras
• Não há uma função ecrecover(), mas existe uma função signatureVerify() para verificar assinaturas ed25519.
• Instruções try-catch não funcionam. O runtime interromperá a execução e reverterá toda a transação se alguma chamada externa ou criação de contrato falhar.
• Definições de erros e reversões com mensagens de erro ainda não funcionam
• A transferência de valor nativo com uma chamada de função não funciona.
• Muitos recursos integrados do Yul não estão disponíveis. O Solang oferece suporte à maioria deles, mas as operações de memória e de cadeia não estão implementadas.
• O formato ERC-20 não é compatível no momento. Os SPL Tokens são definidos de acordo com o Token Program. O Token Program é a forma nativa da Solana de criar, emitir, transferir e queimar tokens. O arquivo spl_token.sol deve ser copiado para sua árvore de código-fonte e importado onde for necessário usar a biblioteca SplToken

Além disso, os registradores da SVM têm 64 bits de largura, o que significa que inteiros de 64 bits (ou seja, uint64 e int64) são preferíveis a inteiros de 256 bits. Uma operação com tipos maiores que 64 bits, como uint256 ou int256, é dividida em várias operações. Isso as torna mais lentas e consome mais unidades de computação.

Quanto aos endereços, um literal de endereço deve ser especificado usando a sintaxe address"36VtvSbE6jVGGQytYWSaDPG7uZphaxEjpJHUUpuUbq4D". A sintaxe hexadecimal do Ethereum (por exemplo, 0xE0f5206BBD039e7b0592d8918820024e2a7437b9) não é compatível. Todos os saldos e valores na Solana têm 64 bits de largura. Isso significa que as funções integradas para endereços (ou seja, .balance(), .transfer() e .send()) usam inteiros de 64 bits.

Embora o Solang ofereça um caminho interessante para desenvolvedores EVM entrarem no ecossistema da Solana, ele tem várias limitações que exigem atenção. A mudança para o modelo baseado em contas da Solana não é apenas sintática — ela representa uma alteração fundamental na lógica dos contratos inteligentes. Certas funções, padrões de código e recursos específicos da EVM não estão disponíveis no Solang. Desenvolvedores não podem portar um contrato inteligente do Ethereum para o Solang e esperar que ele funcione sem ajustes significativos. A ausência de recursos, como definições adequadas de erros e reversões com mensagens de erro, pode ser bastante prejudicial. No entanto, é importante reconhecer que o Solang é uma ferramenta em constante evolução, e cada atualização busca melhorar a experiência de desenvolvedores Solidity na Solana. O Solang oferece várias vantagens distintas para aprimorar essa experiência.

Vantagens

Apesar dessas limitações, há várias funções integradas e decisões de design que melhoram a experiência de desenvolvimento. Por exemplo, contratos desenvolvidos no Solang podem interagir com programas Anchor. Isso pode ser feito gerando uma interface Solidity a partir da IDL de um programa Anchor. IDL significa “Interface Description Language”. Em essência, é um arquivo JSON que contém todas as especificações de um programa. Ele inclui tudo o que você precisa saber para interagir com um programa Anchor. O Anchor gera automaticamente uma IDL ao desenvolver um programa com seu framework. Isso é muito semelhante às ABIs no Ethereum. Para gerar uma interface Solidity a partir de uma IDL, use o seguinte comando: solang idl [-output directory] [IDL file]. Agora, o arquivo pode ser importado usando a sintaxe import “...”;.

O Solang fornece a biblioteca da Solana, uma série de bibliotecas que permitem que contratos Solidity interajam com instruções específicas da Solana. O Solang fornece a biblioteca SPL Token para emitir, queimar e transferir tokens. Ela pode ser vista como um equivalente ao ERC-20 e ao ERC-721. O Solang também fornece a biblioteca System Instructions para que desenvolvedores possam interagir com o System Program da Solana.

O Solang também inclui algumas funcionalidades integradas que podem ser importadas com solana. Isso inclui as structs AccountMeta e AccountInfo. A struct AccountMeta é usada para especificar quais contas devem ser passadas ao receptor em uma chamada externa (ou seja, uma CPI). A struct AccountMeta tem a seguinte estrutura:

• pubkey: o endereço ou a chave pública da conta. É do tipo address
• is_writable: especifica se o receptor pode gravar nessa conta. É do tipo bool
• is_signer: especifica se o receptor pode presumir que essa conta assinou a transação. É do tipo bool

Se o argumento accounts for omitido em uma chamada externa, o compilador do Solang gerará automaticamente um array AccountMeta. Isso só funciona se a função for declarada como externa. Caso contrário, o array AccountMeta deverá ser criado manualmente de acordo com a ordem das contas especificada na IDL. Se uma determinada chamada não precisar de contas, passe um vetor vazio: {accounts: []}. A documentação do Solang fornece um bom exemplo de como criar o array AccountMetas:

function build_this() external {
	// When calling a constructor from an external function, the data account for the contract
	// 'BeingBuilt' should be passed as the 'BeingBuilt_dataAccount' in the client code.
	BeingBuilt.new("my_seed");
}

function build_that(address data_account, address payer_account) public {
	AccountMeta[3] metas = [
		AccountMeta({
			pubkey: data_account,
      is_signer: true,
      is_writable: true
		}),
    AccountMeta({
    	pubkey: payer_account,
      is_signer: true,
      is_writable: true
    }),
    AccountMeta({
      pubkey: address"11111111111111111111111111111111",
      is_writable: false,
      is_signer: false
    })
  ];
  BeingBuilt.new{accounts: metas}("my_seed");

	// No accounts are needed in this call, so we pass an empty vector.
	BeingBuilt.say_this{accounts: []}("It's summertime!");
}

O Solang também tem funções integradas para:

• Calcular o saldo mínimo necessário para criar uma conta específica
• Criar uma PDA para um endereço de programa com base nas seeds e no bump fornecidos
• Encontrar uma PDA para um endereço de programa com base nas seeds e no bump fornecidos

O Solang conecta a Solana e o Ethereum ao fornecer um compilador com um conjunto avançado de ferramentas que facilita a transição para desenvolvedores EVM. Apesar de suas limitações, o Solang oferece vários recursos para melhorar a experiência de desenvolvimento, incluindo a capacidade de interagir com programas Anchor, acessar bibliotecas específicas da Solana e usar funções integradas. A integração de conceitos familiares, como IDLs e padrões de tokens, reduz ainda mais a curva de aprendizado. Não precisar se preocupar nem otimizar o consumo de gas é uma adição bem-vinda. O Solang representa um passo importante rumo à interoperabilidade entre Solana e Ethereum. Para desenvolvedores EVM que desejam entrar no universo de alto desempenho da Solana, o Solang surge como uma possível ferramenta.

Neon EVM

O Solang não é a única opção para desenvolvedores Solidity que desejam criar na Solana. A Neon EVM se apresenta como a primeira EVM paralelizável do mundo. Ela é um ambiente Ethereum totalmente compatível na Solana. Essa é uma solução sinérgica para quem deseja escalar dApps do Ethereum na Solana de forma acessível para desenvolvedores. É possível implantar dApps sem reconfigurar seus contratos inteligentes, escritos nas linguagens que preferem e usando as ferramentas que já conhecem.

Arquitetura

A Neon EVM consiste em três componentes principais: o programa Neon EVM, o Neon Proxy e a Neon DAO.

A Neon EVM é um programa da Solana que aceita transações semelhantes às do Ethereum e as processa na Solana de acordo com as regras da EVM. Essas transações semelhantes às do Ethereum direcionadas à Neon EVM são chamadas de Neon Transactions. Elas são um subconjunto dos métodos JSON RPC definidos pela API JSON-RPC do Ethereum.

O Neon Proxy permite que desenvolvedores Ethereum portem suas dApps para a Neon com alterações mínimas. Ele empacota transações EVM em transações da Solana, atuando como uma solução em contêineres para Neon Operators. Esses operadores executam servidores Neon Proxy, recebem pagamentos em NEON e fazem pagamentos no ecossistema da Solana em SOL. NEON é um token utilitário e de governança: Neon Operators o recebem para pagar as taxas de gas necessárias à execução de transações, e os proprietários podem participar da Neon DAO.

A Neon DAO é um modelo de governança conduzido pela comunidade e desenvolvido para capacitar detentores do token NEON nos processos decisórios da Neon EVM. Ela reúne usuários, operadores, colaboradores e desenvolvedores principais e de aplicações, que debatem coletivamente as regras de governança e a evolução do protocolo. A DAO opera por meio de várias assembleias descentralizadas voltadas ao ecossistema, ao desenvolvimento e à segurança. Cada assembleia facilita a tomada colaborativa de decisões e a avaliação de propostas em sua respectiva área. A assembleia voltada ao ecossistema supervisiona seu crescimento sustentável e gerencia recursos para subsídios e iniciativas. A assembleia voltada ao desenvolvimento cuida das atualizações técnicas do programa Neon e das intervenções emergenciais. A assembleia voltada à segurança protege o tesouro da Neon e o programa Neon contra possíveis ameaças.

Compatibilidade com EVM

A Neon EVM viabiliza interações EVM na Solana ao:

• Implementar a maioria dos métodos da API JSON-RPC do Ethereum
• Usar um proxy especial para processar chamadas do Ethereum
• Adaptar-se às diferenças e limitações impostas pela arquitetura da Solana

Interagir com a Neon EVM é semelhante a interagir com qualquer outra EVM. Desenvolvedores podem usar métodos familiares da API RPC direcionados ao Neon Proxy, o que proporciona uma experiência integrada. Os principais recursos incluem:

• Compatibilidade com contratos inteligentes em Solidity e Vyper, além de ferramentas padrão de desenvolvimento para Ethereum, como Metamask, Foundry e Remix
• Suporte literal à maioria dos opcodes do Ethereum
• Aceitação de solicitações de transação do Ethereum do tipo 0/legadas. No momento, transações EIP-1559 não são compatíveis

Naturalmente, certas adaptações são necessárias para que a Neon EVM funcione corretamente na Solana. Entre as diferenças relevantes estão:

• A Neon EVM oferece suporte a todos os contratos pré-compilados definidos em evm.code. No entanto, contratos Solidity que contenham as seguintes chamadas não serão executados: bigModExp, bn256Add, bn256ScalarMult e bn256Pairing. A Neon EVM precisa implementar chamadas de sistema da Solana para oferecer suporte a esses contratos no futuro
• Embora a maioria dos opcodes seja aceita literalmente, os opcodes COINBASE, PREVRANDAO (FKA DIFFICULTY), GASLIMIT, BASEFEE e GAS não são. Eles são conhecidos como opcodes variantes e foram adaptados para uso na Neon EVM.
• O consumo de gas e os cálculos de taxas são diferentes dos do Ethereum. Em geral, resultam em custos menores devido ao papel da Solana como camada de liquidação
• Os métodos transfer() e send() do Solidity não são protegidos contra reentrância na Neon EVM devido aos diferentes cálculos de gas
• O modelo de contas da Solana afeta o armazenamento dos contratos inteligentes, com diferentes funcionalidades de armazenamento e permissões de acesso para contas executáveis e não executáveis
• A Neon EVM usa transações versionadas, limitando a 64 o número máximo de contas usadas em uma única transação
• A Neon EVM usa o Berkeley Packet Filter (BPF) da Solana, com um limite de memória heap de 256 KB. Isso restringe o tamanho das chamadas de contratos e exige estratégias de otimização para gerenciar o uso da memória com eficiência
• Funções baseadas em tempo, como block.number e block.timestamp, têm comportamentos diferentes. Desenvolvedores são fortemente aconselhados a não usá-las ao desenvolver na Neon EVM

Embora a Neon EVM ofereça um ambiente familiar e compatível, desenvolvedores EVM precisam conhecer e se adaptar às principais diferenças para migrar e desenvolver com sucesso na Solana.

Como se conectar a um RPC da Neon

Desenvolvedores podem se conectar facilmente a um RPC da Neon usando o Chainlist. Nele, é possível se conectar à Mainnet ou à Devnet da Neon EVM. Clique em Conectar carteira no modal da Mainnet ou da Devnet e, quando sua carteira for exibida, clique em Aprovar.

Antes de enviar transações à Neon EVM, você deve escolher o operador ideal. Expanda os detalhes do cartão para visualizar os endpoints RPC disponíveis para cada rede:

Se você escolher um operador diferente do operador padrão fornecido durante a conexão da carteira, será necessário fazer uma conexão manual. A documentação da Neon EVM oferece guias completos sobre como se conectar a um Proxy usando Foundry, Hardhat, Remix e Truffle. Na seção sobre implantação, mostraremos como se conectar com o Foundry.

Depois da conexão, desenvolvedores podem usar o Neon Faucet para obter NEON ou outros tokens ERC-20 de teste. Também é possível usar o endpoint request_neon para solicitar tokens de forma programática:

curl -i -X POST \
	-d '{"wallet": "Your wallet", "amount": 1}' \
	'http://localhost:3333/request_neon'

Esse comando envia uma solicitação POST para receber tokens no endereço de carteira especificado.

Ciclo de vida das transações e taxas de gas

Há três etapas principais para executar uma transação de uma dApp do Ethereum na Solana por meio da Neon EVM:

• Um usuário inicia uma transação assinada semelhante às do Ethereum, direcionada a um endpoint RPC da Neon
• A transação é passada ao Neon Proxy por meio da API do Ethereum. O Proxy estima o gas necessário para executar a transação, inicia uma transmissão ao encapsular a transação semelhante às do Ethereum em uma transação da Solana e envia a transação encapsulada para a Neon EVM. Isso gera um recibo da Solana e um recibo correspondente da transação na Neon EVM. O contrato inteligente Neon desencapsula a transação, verifica a assinatura do usuário e carrega o estado da EVM a partir do armazenamento da Solana. A transação é executada dentro do BPF da Solana
• A Solana e a Neon EVM atualizam seus estados para concluir a solicitação de transação

Esse é todo o ciclo de vida de uma transação na Neon EVM, desde o início até a execução. Desenvolvedores podem acessar o NeonScan para ver as transações e os blocos mais recentes e consultar contas, tokens, blocos ou hashes de transações.

Desenvolvedores também podem enviar transações sem gas. Esse recurso foi implementado para atender usuários que não têm tokens NEON suficientes para cobrir suas taxas iniciais de transação. É possível obter um pacote inicial de transações sem gas entrando em contato com info@neonevm.org. O Proxy Operator escolhido pelo desenvolvedor ainda processará essas transações, mas a Neon cobrirá o custo. Normalmente, são oferecidas pelo menos três transações sem gas para cada nova conta Neon.

O processo das transações sem gas é o seguinte:

• Um usuário final inicia uma transação por meio de uma dApp
• A dApp solicita o preço atual do gas ao Proxy Operator escolhido. Se a conta for elegível, o Proxy Operator autoriza um número específico de transações sem gas para a conta Neon
• Para essas transações, a dApp mostrará um custo de gas igual a zero
• O usuário final assina a transação sem taxa de gas
• O Proxy Operator executa a transação, e a taxa de gas em SOL é paga pela Neon Foundation

A documentação da Neon EVM fornece o seguinte trecho para demonstrar como solicitar uma transação sem gas:

try {
	// Get gasless transaction if user account is eligible
  const rawGasPrice = await axios.post(rpcApiUrl, {
  	method: 'neon_gasPrice',
    params: [{ from: address }],
    jsonrpc: "2.0",
    id: new Date().getTime()
   })

   tx.gasPrice = rawGasPrice.data?.result;
	} catch (e) {
  	//Else, get standard GAS price
   	setError('Can\'t retrieve gas price for transaction')

    const rawGasPrice = await web3.eth.getGasPrice();

    tx.gasPrice = web3.utils.toHex(rawGasPrice);
} finally {
    setTx(tx)
}

NeonPass

O NeonPass é uma ferramenta para transferir tokens entre a Solana e a Neon EVM. Ele permite transferências integradas de ativos entre as Associated Token Accounts da Solana e as contas de tokens ERC-20 da Neon EVM. O NeonPass usa o contrato de interface da Neon EVM e um armazenamento especializado de contas. Os tokens da Solana Program Library (SPL) são empacotados em uma interface ERC-20 dentro do contrato factory da Neon EVM. Isso permite armazenar SPLs em contas de tokens ERC-20 compatíveis com dApps Solidity. O NeonPass permite a transferência bidirecional de tokens entre contas da Solana e da Neon EVM. Diferentemente das pontes tradicionais, que bloqueiam ativos e emitem novos, ele transfere os tokens diretamente entre os dois tipos de conta. Isso permite uma transição integrada de tokens da Solana e da Neon EVM.

Implantação

Desenvolvedores podem implantar na Neon EVM usando Hardhat, Foundry, Truffle e Remix. Como a maneira mais fácil de usar o Solang é por meio do Anchor, todos os testes são feitos em TypeScript. No entanto, para todos os maximalistas de Solidity, finalmente podemos testar e implantar dApps Solidity na Solana por meio do Foundry.

Primeiro, verifique se você tem uma carteira compatível com EVM conectada à Devnet da Neon EVM. Depois, clone o projeto Foundry de exemplo da Neon e acesse o diretório:

git clone https://github.com/neonlabsorg/neon-tutorials
cd neon-tutorials/foundry

Em seguida, instale o Foundryup, o instalador do conjunto de ferramentas Foundry, e execute foundryup para instalar os binários pré-compilados mais recentes (nightly), ou seja, force, cast, anvil e chisel:

curl -L https://foundry.paradigm.xyz | bash
foundryup

Instale as bibliotecas necessárias:

forge install foundry-rs/forge-std --no-commit
forge install openzeppelin/openzeppelin-contracts --no-commit

Agora, obtenha a chave privada da sua conta de carteira. No Metamask, por exemplo, você pode visualizar sua chave privada clicando no menu de hambúrguer e acessando Account Details > Show Private Key. Você precisará digitar sua senha. Clique em Confirmar para acessar a chave privada da sua conta. Não compartilhe essa chave com ninguém e tome as medidas necessárias para protegê-la.

Depois, crie um arquivo .env com as seguintes variáveis:

RPC_URL_DEVNET=https://devnet.neonevm.org
CHAIN_ID_DEVNET=245022926
RPC_URL_MAINNET=https://neon-proxy-mainnet.solana.p2p.org
CHAIN_ID_MAINNET=245022934
PRIVATE_KEY=
VERIFIER_URL_BLOCKSCOUT=https://neon-devnet.blockscout.com/api

Substitua <YOUR_PRIVATE_KEY> pela sua chave privada e execute source .env.

Para compilar os contratos do projeto, acesse o diretório src e execute forge build. O console deverá informar que a execução do compilador foi concluída com sucesso. Os contratos também podem ser testados usando o comando forge test. Para implantar o contrato do projeto, execute o seguinte comando:

forge create --rpc-url $RPC_URL_DEVNET --private-key $PRIVATE_KEY src/TestERC20/TestERC20.sol:TestERC20 --constructor-args "Test ERC20 Token" "TERC20" --legacy

Você deverá ver uma saída semelhante à seguinte:

[⠰] Compiling...
No files changed, compilation skipped
Deployer: 0x4455E84Eaa56a01676365D4f86348B311969a4f4
Deployed to: 0x5537599aa2F97Dd60a66342522a465A7f2e40Ff9
Transaction hash: 0x6de9dab8a526cbac33008056d185b93dff725605efb791bf116b6bece4f0c486

Para verificar seu contrato, execute o seguinte comando:

forge verify-contract --chain-id $CHAIN_ID_DEVNET  src/TestERC20/TestERC20.sol:TestERC20 --verifier-url $VERIFIER_URL_BLOCKSCOUT --verifier blockscout

Substitua <contract_address> pelo endereço do seu contrato inteligente. Você deverá receber uma resposta OK com uma URL que aponta para o endereço do contrato no BlockScout, o explorador da Devnet da Neon. Você também pode configurar seu arquivo .env para usar o NeonScan em vez do BlockScout, que também oferece suporte à devnet.

Vantagens e limitações

Desenvolvedores que buscam uma experiência de desenvolvimento semelhante à do Ethereum devem escolher a Neon EVM. Ela é um ambiente compatível com EVM que envia transações semelhantes às do Ethereum e usa ferramentas conhecidas. Recursos como NeonPass, suporte à maioria dos opcodes da EVM e transações sem gas tornam a transição para a Solana muito mais fácil. No entanto, a Neon EVM não é perfeita. Ela apresenta algumas limitações, como a necessidade de alterar a lógica dos contratos inteligentes para se adaptar à infraestrutura da Solana, operar dentro das restrições do Berkeley Packet Filter (BFP) e dos modelos de contas da Solana, além de certas limitações relacionadas a opcodes e contratos pré-compilados. Entender e lidar com essas particularidades é essencial para implantar com sucesso na Solana a partir de um ambiente compatível com EVM.

Migrações anteriores

Várias tarefas complexas precisam ser concluídas para que um grande protocolo da Ethereum seja implantado em uma blockchain não EVM. Entre elas estão contratar engenheiros que não trabalham com Solidity para reconstruir toda a base de código do zero, encontrar parceiros de auditoria confiáveis, auditar novamente a nova base de código e adaptar os contratos de governança para aplicar as decisões da DAO. Esses esforços podem custar milhões de dólares e exigir meses de trabalho dedicado. Isso não é viável para a maioria. No entanto, já aconteceu antes.

A Helium é uma rede LoRaWAN que busca criar uma infraestrutura sem fio descentralizada para oferecer suporte a dispositivos da Internet das Coisas (IoT). Isso é feito com hotspots, pequenos dispositivos de baixo consumo semelhantes a torres de telefonia em miniatura, que se conectam a outros hotspots a longas distâncias. Originalmente executada em sua própria blockchain de camada 1 (L1), a equipe de desenvolvimento da Helium propôs a migração para a Solana por meio da HIP 70. A mudança permitiria que a Helium alcançasse maior disponibilidade, mais capacidade de composição e uma experiência de usuário mais rápida, mantendo um alto nível de segurança e um baixo custo de uso. A comunidade votou de forma esmagadora a favor da proposta, e a Helium migrou para a Solana em abril de 2023. O COO da Helium, Scott Sigel, descreveu a migração como um evento sem grandes emoções — nada deu errado com a rede ou com a infraestrutura da Helium. Foi o sonho de qualquer engenheiro. A equipe também detalhou todo o processo de migração em uma série de guias em sua documentação. A migração da Helium foi um enorme sucesso e beneficiou muito a comunidade.

Essa migração não é um caso isolado. A Render Network, a primeira plataforma descentralizada de renderização por GPU do mundo, migrou com sucesso sua infraestrutura principal da Ethereum para a Solana em novembro de 2023. A comunidade votou a favor da RNP-002 para realizar a migração para a Solana. Jules Urbach, fundador da Render, descreveu a migração como um divisor de águas. Ele afirmou: “As incríveis velocidades de transação da Solana, seus baixos custos e seu compromisso com uma arquitetura em escala web fazem dela a opção perfeita para a Render Network enquanto continuamos construindo uma infraestrutura de metaverso escalável e descentralizada.”

A migração da Render não teve um impacto excessivamente negativo sobre seus usuários. Os usuários podem transferir fundos da Ethereum para a Solana usando o Assistente de upgrade da Render. Eles conectam sua carteira Ethereum, indicam a quantidade de RNDR que desejam migrar e aguardam a entrega dos tokens na carteira Solana especificada. 

A Maker é um projeto emblemático da Ethereum. Seu objetivo é liberar o potencial das finanças descentralizadas com a Maker Platform, uma plataforma inclusiva criada para ampliar a autonomia econômica e a igualdade de acesso ao mercado financeiro global. A plataforma consiste na MakerDAO, usada para administrar o projeto Maker, e no protocolo Maker para a DAI, “a primeira moeda imparcial do mundo e a principal stablecoin descentralizada”. Rune Christensen, fundador da Maker, publicou no Twitter sobre o uso de um fork da base de código da Solana para desenvolver uma appchain da Maker: 

Migrações são inerentemente complexas. Apesar dos custos financeiros, reputacionais e de tempo envolvidos na migração de toda a infraestrutura de um projeto da Ethereum para a Solana, os projetos estão escolhendo a Solana. Com ferramentas como Solang e Neon EVM, as migrações não precisam ser inerentemente complexas. Assim como a migração da Helium, elas podem ser tranquilas e ter pouco ou nenhum impacto negativo sobre os fundos dos usuários, como ocorreu com a Render Network. A Solana é a blockchain de maior desempenho do mercado, criada para a escala da web. Este é o lugar para construir, e cada vez mais projetos estão percebendo isso.

Conclusão

Solidity é a língua franca do desenvolvimento de contratos inteligentes. A EVM é o ambiente dominante para contratos inteligentes desde sua criação. No entanto, ela tem pontos fracos. Aplicações em escala web e voltadas ao consumidor exigem uma rede de alto throughput e baixa latência para sustentar suas operações. O ambiente de thread única da Ethereum, baseado em taxas de gas voláteis, não consegue oferecer suporte a um projeto de Rede de Infraestrutura Física Descentralizada (DePIN) com alto throughput como a Helium. 

Diante desses desafios, a Solana surge como uma alternativa poderosa. A melhor forma de aproveitar os verdadeiros benefícios da Solana é realmente construir na Solana. Com os avanços recentes, ferramentas como Solang e Neon EVM permitem que desenvolvedores EVM interessados façam a migração usando ferramentas e linguagens conhecidas. Este artigo apresenta um guia completo sobre a arquitetura da Solana, como ela se compara à Ethereum e como um desenvolvedor EVM pode começar a desenvolver na Solana. A Solana é a blockchain de maior desempenho do mercado. Ela está ganhando impulso, relevância e aplicações renomadas voltadas ao consumidor. Por que esperar a Ethereum escalar quando você pode aproveitar hoje mesmo os benefícios de uma blockchain rápida e escalável?

Se você leu até aqui, obrigado, anon! Não deixe de inserir seu endereço de email abaixo para nunca perder uma atualização sobre as novidades da Solana. Pronto para se aprofundar? Entre no nosso Discord e comece hoje mesmo a construir o futuro na blockchain de maior desempenho.

Mais recursos

• Avaliação da Solana para uso empresarial: um guia completo
• Neon EVM
• Documentação do Solang para Solana
• O livro de Rust
• O modelo de programação da Solana: uma introdução ao desenvolvimento na Solana
• Tower BFT: a implementação de alto desempenho do PBFT na Solana
• O que é SVM — a máquina virtual da Solana