Como a Ledger gerencia os Hard Forks da Ethereum

Este artigo foi escrito por Valentin Bergeron e traduzido por Diogo Jorge. O artigo original pode ser encontrado aqui.

Principais conclusões:

• No ano passado, vimos a introdução de duas grandes atualizações na blockchain Ethereum: os forks Berlim e Londres. Como esses eventos nos impactaram na Ledger?
• Uma dessas atualizações levantou um grande problema para todo o ecossistema Ethereum. Como lidamos com a crise? O que aprendemos com isso? E quanto ao suporte NFT? Como nos adaptamos para lidar com essas novas transações?
• Na Ledger, nosso objetivo é fornecer aos nossos clientes os melhores serviços da categoria. É por isso que procuramos constantemente melhorar as nossas soluções, manter-nos atualizados com as últimas inovações e resistir a qualquer abalo neste ecossistema!

Hard Forks: mantendo nossos clientes no lado certo da chain

O ano de 2021 foi selvagem para o protocolo Ethereum. Ele viu a introdução de duas grandes atualizações, introduzindo o que chamamos de hard fork nas chains subjacentes.

Um hard fork ocorre quando o código de um blockchain muda tanto que não é mais compatível com os blocos anteriores. A blockchain então se divide em dois , onde o original não é afetado, e o novo fork segue o novo conjunto de regras.

Sinta-se à vontade para conferir este artigo da Ledger Academy para obter mais detalhes sobre forks.

Isso significa que todas as implementações de protocolo de cliente Ethereum - em resumo, implementações de nó ETH - devem conter as alterações do protocolo antes da atualização. Se você tiver um nó desatualizado, acabará em uma cadeia paralela ao chamado bloco hard-fork, com todos os outros membros da rede que não atualizaram. Se a atualização for adiante, essa cadeia paralela eventualmente se extingue.

Obviamente, na Ledger, queremos que nossos clientes permaneçam no lado certo das cadeias, portanto, essas atualizações são críticas para o serviço que prestamos. Aqui está como fazemos isso.

Qual o Fork?

No ano passado, dois _forks _ocorreram na Ethereum Mainnet:

• O fork Berlim na Ethereum Mainnet no bloco 12.244.000, em 15 de abril de 2021.
• O fork Londres na Ethereum Mainnet no bloco 12.965.000, em 30 de julho de 2021.

Esses forks modificaram bastante a economia do ecossistema Ethereum, tornando os ativos ETH parcialmente deflacionários (como o BTC). Não entraremos em detalhes aqui, pois isso já é bastante abordado na literatura . E para quem tiver mais interesse, também pode conferir a documentação sobre o EIP 1559 .

Além disso, o Ethereum é antes de tudo um protocolo implementado por uma variedade de clientes. Cada cliente tem seu próprio conjunto de vantagens e desvantagens, e os nós devem ser escolhidos de acordo com o objetivo desejado. Já que vamos falar muito sobre eles, aqui estão:

• open-ethereum : uma implementação focada em desempenho, indexação,consultas eficientes e mineração.
• go-ethereum : a implementação de referência, com foco na correção das especificações.

Se você não sabe o que é um cliente Ethereum, ou quer mais detalhes, pode ler a documentação oficial do Ethereum .

Neste artigo, também falaremos sobre Ethereum Virtual Machines (EVMs). Uma máquina virtual Ethereum (EVM) é um mecanismo de computação que atua como um computador descentralizado com milhões de projetos executáveis. Ela realizou todos os tipos de ações na blockchain.

Se você quiser saber mais sobre EVMs, existem muitos artigos bons por aí.

A anatomia e as limitações de uma transação

Para entender melhor a diferença entre essas duas implementações de nós, vamos começar com o que realmente é uma transação Ethereum .

Sem surpresas aqui, a blockchain Ethereum é uma única lista vinculada de blocos, com cada bloco contendo um conjunto de transações. Quando um bloco é “jogado” (quando um nó da rede adiciona um bloco ao seu estado), todas as transações pendentes são executadas em ordem, cada uma delas modificando o estado da chain.

Uma transação pode ser:

• Uma transferência de fundos de um endereço para outro. Este caso é simples: o estado modificado diz respeito apenas aos saldos das duas contas.
• Uma chamada de método de contrato inteligente. Este caso é mais complicado.

Os contratos inteligentes podem ser vistos como contas especiais que possuem uma coleção de subestados de uma cadeia (chamados “estado do contrato”) e possuem um grupo de métodos de bytecode EVM que são executados quando o método é chamado. Os contratos são contas especiais que possuem dados na chain (o estado do contrato) e interagem com ela por meio de transações. Toda vez que alguém interage com um contrato, o bytecode EVM é executado para ler ou modificar o estado do contrato. Cada pedaço de código elementar (ou opcode) pode desencadear uma atualização de estado, outro evento, armazenamento de dados, etc., e custos de gás individuais.

Em particular, uma transação para um contrato (ou seja, uma transação que executa código) pode acionar uma chamada para outro contrato em alguns casos. Isso significa que ele interage com ele como uma transação normal faria, mas está completamente dentro da transação.

A principal coisa a entender é que você pode receber fundos por meio de um contrato sem interagir diretamente com ele. Um bom exemplo disso é um contrato de mercado. Se você vende algo, precisa ser pago quando o comprador decidir emitir a transação, mesmo que seu alvo inicial seja o endereço do contrato do marketplace.

Concluindo, você precisa recuperar essas transações internas de alguma forma para ter total responsabilidade (tendo um evento para cada alteração de saldo). Infelizmente , não há como no padrão atual da API web3 buscar essas transações internas. Eles são completamente invisíveis do ponto de vista do usuário, e esse é o caso da maioria das carteiras.

Hard forks e migração de clientes

No início de 2021, usamos amplamente o open-ethereum como nosso nó padrão. O OpenETH foi muito útil para obter total accountability, pois mantém um índice nas árvores de chamadas de transação (com o trace_transactione trace_blockRPCs). Assim foi fácil para nós indexar cada operação para cada conta e mostrar ao cliente o real motivo da movimentação de seus fundos. Até agora tudo bem!

Mas então, em abril, veio o Berlim fork. E deu errado porque a equipe por trás do open-ethereum já tinha planos de mudar para outro projeto (que era outro nó de blockchain eth orientado ao desempenho chamado Erigon), e a versão compatível com Berlin-fork simplesmente não fez o trabalho. Nenhum novo bloco pode ser processado! Essa situação foi crítica para nós, já que o open-ethereum é muito usado por nossos usuários.

Felizmente, dentro de alguns dias um patch foi lançado e pudemos retomar as operações. Parabéns aos nossos bombeiros, pois fomos uma das primeiras empresas de criptomoedas a fazê-lo.

Decidimos então analisar outras implementações para mitigar os riscos. Começamos adaptando nossa base de código e estratégia de indexação de operação para usar o nó go-ethereum .

Com go-ethereum , as chamadas internas não estão disponíveis diretamente via RPC. A única maneira de recuperar o encadeamento de chamadas é reproduzindo totalmente as transações e sua execução na EVM usando debug_traceTransaction(ou debug_traceBlock). Podemos então extrair transações que aconteceram nos bastidores e adicioná-las aos nossos índices. Esta operação é muito cara, por razões óbvias.

Avançando rápidamente para julho, quando implementamos essa lógica usando chamadas go-ethereum e a segunda atualização correu bem. Nenhum imprevisto; Operações normais; Yay!

E quanto ao suporte NFT?

Para ter suporte completo a NFT, precisávamos fazer o que chamamos de reindexação da blockchain Ethereum para incluir eventos de transferência NFT anteriores . Em outras palavras, reconstruir completamente nossos índices. Isso significa que temos que reproduzir cada transação em um EVM local enquanto indexamos, e isso torna o processo de indexação extremamente lento: nossa velocidade de indexação era de 8 a 10 blocos/segundo (para blocos com rastreamentos) e 40 a 50 blocos/segundo sem eles.

O rastreamento de transações acabava de se tornar o gargalo mais significativo . Para resolver esse problema, investigamos e encontramos sua fonte no mecanismo JS usado pelo go-ethereum para implementar o rastreador.

De fato, como era uma debugde interface, foi uma jogada inteligente propor um mecanismo programável. Os casos mais comuns (incluindo obter a árvore de chamadas) são pré-carregados com aliases. A primeira coisa foi alterar o código JS para ter um rastreador personalizado buscando apenas os dados que precisávamos. Procuramos fazer alterações na base de código go-ethereum diretamente, mas ao mesmo tempo, o geth 1.16 foi lançado com uma completa reformulação do tracer escrito em go.

Uma vez aplicado, observamos uma melhora significativa na velocidade de rastreamento! No entanto, em termos de magnitude, ainda era mais lento que o ethereum aberto, por exemplo.

Fornecendo os melhores serviços da categoria para nossos usuários

A transação interna é fundamental para obter total responsabilidade nas blockchain semelhantes à Ethereum. O rastreamento de chamadas de contrato aninhadas é uma parte que faltava na web3 e um caminho de melhoria para ter um sistema sólido e funcional.

Na Ledger, nosso objetivo é fornecer aos nossos clientes os melhores serviços da categoria, e o histórico completo é um componente fundamental disso . É por isso que estamos constantemente procurando melhorar nossas soluções, manter-nos atualizados com as últimas inovações e resistir a qualquer abalo que esse ecossistema possa encontrar!