Criando confiabilidade de app: a chave para o sucesso no web3

Muitas equipes têm apps web3 fadados ao fracasso.

Por quê?

Porque os apps dependem totalmente de nodes, e nodes são extremamente difíceis de manter. Alguns motivos:

1. A confiabilidade dos nodes não pode ser construída em um vácuo; ela precisa vir acompanhada de escalabilidade e precisão dos dados
2. Nodes não são projetados para ser soluções de produção em larga escala
3. Espera-se que os nodes façam coisas demais
4. Nodes exigem manutenção em tempo integral
5. A eficácia dos nodes depende de navegar com sucesso por upgrades de rede ou hard forks de tempo imprevisível

Essas complicações tornam os nodes difíceis de gerenciar e manter.

Mas há duas dimensões arquiteturais que melhoram significativamente a confiabilidade dos nodes, ou seja, a capacidade de um usuário interagir com seu app com sucesso quando precisar:

• Heterogeneidade: sistemas diversos e complementares que conseguem lidar com requisições diferentes
• Redundância: sistemas de backup, de modo que, se um sistema cair, outros continuem no ar

No web3, a falta de confiabilidade pode ter consequências prejudiciais.

Veja o caso de um marketplace de NFT conhecido usando infraestrutura pouco confiável...

A plataforma deles era instável, o que gerava:

• Alta carga de engenharia
• UX degradada
• Mais de 190 horas de indisponibilidade em um único trimestre

Qual foi o impacto? $6M em receita perdida.

Não deixe isso acontecer com você.

Neste artigo, vamos explicar:

1. Por que manter a confiabilidade dos nodes é desafiador
2. Padrões comuns de infraestrutura de nodes e por que eles falham
3. Como a Alchemy trata os desafios de confiabilidade e constrói para confiabilidade em escala

Por que manter a confiabilidade dos nodes é desafiador

Há cinco motivos principais pelos quais a confiabilidade é particularmente difícil de manter no web3:

(1) A confiabilidade dos nodes não pode ser construída em um vácuo; ela precisa vir acompanhada de escalabilidade e precisão dos dados

Para criar um app altamente funcional, você precisa de confiabilidade, combinada com escalabilidade e precisão dos dados.

• Escalabilidade: a capacidade de continuar interagindo com a blockchain à medida que o tráfego do seu app escala 10x, 100x, 1000x ou mais.
• Precisão dos dados: o estado em que seu app retorna dados corretos e consistentes para cada usuário.

(2) nodes não são projetados para ser soluções de produção em larga escala‍

Os nodes foram inicialmente projetados para ser executados por indivíduos, em casos de uso pessoais e de pequena escala. Embora sejam caros ($1000 / mês), para esse caso de uso limitado, conseguem gerar confiabilidade suficiente e manter:

• Escalabilidade; o volume de requisições é controlado de forma previsível, limitando os riscos relacionados à escalabilidade necessária
• Precisão dos dados; como há apenas um node, não há espaço para inconsistências de dados entre nodes

No entanto, um ambiente de desenvolvimento não é um ambiente de produção, e produção exige ferramentas muito diferentes.

(3)** **espera-se que os nodes façam coisas demais

Espera-se que os nodes façam um número ilimitado de coisas, por exemplo, executar software peer-to-peer, funcionar como um banco de dados escalável, executar código arbitrário, etc.

Os nodes também não têm nenhuma "opinião" sobre o que devem ou não fazer.

Juntos, esses fatores têm duas ramificações principais:

• Escalabilidade; conforme você escala com o aumento do volume de requisições, é preciso colocar novos nodes no ar; e cada novo node precisa ser construído incluindo aquela longa lista de funcionalidades, o que cria ineficiências e custos incômodos (novamente, no lado mais barato, rodar um node custa $1.000/mês).
• Casos extremos; como o node não tem proteções básicas, uma única query pode derrubar sozinha o seu node.

(4) Nodes exigem manutenção em tempo integral

Em média, a cada 5 dias, os nodes podem apresentar problemas como:

• Vazamentos de memória
• Problemas de armazenamento de dados
• CPUs no limite
• Peering inconsistente
• Bancos de dados internos corrompidos
• Problemas na transmissão de transações
• Bugs + regressões
• 1 em cada 6 "releases estáveis" vem com problemas

Cada problema exige tempo significativo para diagnosticar, investigar e corrigir, o que significa muito menos tempo focado na experiência de usuário do seu front-end.

(5) A eficácia dos nodes depende de navegar com sucesso por upgrades de rede ou hard forks de tempo imprevisível

Upgrades de rede e hard forks acontecem no cronograma do protocolo, não no seu. Cada um exige preparação significativa, e errar pode significar nodes derrubados, com impacto prejudicial.

Padrões comuns de arquitetura de infraestrutura e por que falham

Rodar infraestrutura de nodes confiável é intrinsecamente desafiador, e boa parte da arquitetura comum do web3 é ineficaz para criar confiabilidade:

Rodar um único node

É mais simples de configurar, mas sujeito a um único ponto de falha, sem heterogeneidade nem redundância. O uptime de um único node pode ser medido em apenas 72%, e escalar um único node é altamente ineficiente.

Rodar um node com backup

Isso cria um pouco mais de redundância do que um único node, mas ainda sem heterogeneidade (sem diversidade de sistemas), e frequentemente, uma requisição que derruba o primeiro node também derruba o segundo. Os problemas de escalabilidade continuam existindo, e você introduziu problemas de precisão de dados, o que significa que os nodes retornarão respostas diferentes, já que a maioria dos sistemas não consegue garantir que cada node esteja na mesma block head (ou até mesmo na mesma chain).

‍Load balancing entre uma frota de nodes

Esse modelo cria mais redundância, mas ainda sem heterogeneidade. Os problemas de precisão de dados e escalabilidade persistem (uma série de retries vai derrubar toda a frota de nodes).

Nodes frequentemente caem e são muito, muito incômodos de consertar.

Se ainda não ficou claro, muitas "soluções" para conectar à blockchain não oferecem heterogeneidade ou redundância suficientes e, por isso, acabam falhando. A falha tem ramificações graves.

Nodes podem exigir dias ou semanas de tempo de recuperação até voltarem a funcionar. Esses problemas são caros, difíceis de resolver e exigem trabalho concentrado de toda a equipe.

Em 2019, a BlockCypher tentou navegar pelo Constantinople Hard Fork do Ethereum. Eles se depararam com um erro de dados ausentes e não conseguiram diagnosticar a causa raiz. Sofreram mais de um mês de indisponibilidade e, no fim, tiveram que basicamente recomeçar do zero.

Não deixe isso acontecer com você ;)

Quanto mais heterogênea e redundante for sua infraestrutura web3, mais confiável ela será.

Como a Alchemy constrói para confiabilidade em escala

O Cortex engine da Alchemy combina sistemas customizados, escaláveis e distribuídos que viabilizam confiabilidade e escalabilidade, ao mesmo tempo em que permitem que nossa API funcione como um único node, garantindo assim a precisão dos dados.

O Cortex alcança redundância e heterogeneidade com sistemas escaláveis e diversos

Sistemas redundantes e heterogêneos para minimizar requisições de dados nos nodes

A infraestrutura web2 cria confiabilidade e escalabilidade removendo o armazenamento de dados dos servidores e criando centros de armazenamento externos.

No entanto, por causa da natureza singular da arquitetura de nodes, remover o armazenamento de dados dos nodes é essencialmente impossível.

Para criar confiabilidade e escalabilidade, o Cortex engine da Alchemy usa uma arquitetura avançada, chamada infraestrutura secundária, para replicar os dados dos nodes.

O Vox Nodi, a camada de coordenação do Cortex, executa verificações constantes no sistema para garantir que a infraestrutura secundária tenha os dados mais recentes e, assim, qualquer requisição por dados, por exemplo, número do bloco, logs de transação, recibos de transação, será precisa.

Ao rotear as requisições primeiro para a infraestrutura secundária, os nodes ficam protegidos e sua "carga de trabalho" é reduzida.

A maioria das requisições pode ser atendida pela infraestrutura secundária, e apenas casos extremos serão roteados para os nodes.

Vamos a um exemplo:

Usuários querem informações sobre vários tipos de dados e blocos:

• Usuário 1 pede dados de Transactions até o Block 82
• Usuário 2 pede dados de Logs a partir do Block 85
• Usuário 3 pede dados de Blocks a partir do Block 92

A requisição do Usuário 1 pode ser atendida pelo sistema de infraestrutura secundária. (É importante notar que, se uma requisição como essa atingisse um node diretamente, o node cairia, enquanto o sistema de infraestrutura secundária consegue lidar com essa carga sem problemas).

A requisição do Usuário 2 também pode ser atendida pela infraestrutura secundária.

A requisição do Usuário 3 não pode ser atendida via infraestrutura secundária, porque o sistema ainda não tem os dados mais recentes de Blocks a partir do Block 92. A requisição do Usuário 3 será então atendida pelos nodes.

Neste exemplo, a experiência dos Usuários 1, 2 e 3 é exatamente a mesma. Não há diferença de tempo de resposta entre uma requisição atendida via infraestrutura secundária ou diretamente pelos nodes. Mas, ao rotear as requisições primeiro para o sistema de infraestrutura secundária, os nodes ficam protegidos e sua "carga de trabalho" é reduzida.

Sistemas redundantes e heterogêneos para execução de código

Como a Ethereum Virtual Machine (EVM) é Turing completa, é possível solicitar que os nodes executem código. Como os nodes não conseguem se autorregular, há um potencial constante de uma requisição arbitrária derrubar toda uma frota de nodes.

Para proteger contra isso, a Alchemy deduplica e armazena todas as requisições que nosso sistema já respondeu anteriormente.

Isso significa que apenas uma requisição genuinamente nova será executada nos nodes, e, fora isso, a grande maioria das requisições pode ser executada por esses sistemas de armazenamento.

Nodes heterogêneos, especializados para requisições diferentes

Além dos sistemas de infraestrutura secundária, a Alchemy adiciona heterogeneidade com tipos distintos de node. Nos cenários atípicos em que a infraestrutura secundária não consegue responder a uma requisição, o sistema recorre ao node mais escalável.

A Alchemy roda múltiplos tipos de node, incluindo:

• Light: baixa apenas os cabeçalhos de bloco, o mínimo de dados necessário para transacionar na rede. Nodes light conseguem interagir com a rede de forma eficiente e economizam megabytes de banda e gigabytes de armazenamento, mas são limitados por não terem acesso aos dados completos.
• Full: tem tudo o que precisa para verificar que os blocos na rede estão corretos e pode interagir com qualquer smart contract e implantar o seu próprio. Nodes full exigem recursos significativos de computação e banda.
• Archive: vai um passo além de um node full. Enquanto um node full descarta entradas que não precisa mais verificar, o node archive mantém tudo (terabytes de dados extras). Esses detalhes são ótimos para consultar informações com mais eficiência e úteis para algumas aplicações, mas são excessivos na maioria dos casos.
• Debug: nodes debug vão ainda mais longe que um node archive, armazenando mais informações do que qualquer outro tipo de node, para que você possa percorrer a execução de um smart contract em detalhes extremos.

Propriedades distintas dos tipos de node os tornam bons em coisas diferentes, então, se um node não conseguir responder a uma requisição, os outros provavelmente ainda estão saudáveis e bem adequados para responder.

Por exemplo, se houver uma requisição pelos dados mais recentes, que talvez ainda não estejam registrados na infraestrutura secundária, essa requisição pode ser roteada para um node fast, e o node archive ficará "protegido", já que vasculhar os dados do node archive seria significativamente mais custoso.

Para facilitar colocar novos nodes no ar conforme necessário, o Cortex engine tira "snapshots" dos nodes, de modo que, para criar um novo node, o sistema pode partir do "checkpoint" mais recente, encurtando significativamente o processo de sincronização.

Clients heterogêneos para mitigar o impacto de bugs

Por fim, a Alchemy roda diferentes implementações do client Ethereum, incluindo geth, Erigon e Parity. Isso essencialmente triplica o trabalho de manutenção de backend necessário, mas tem grande valor a serviço da heterogeneidade: a chance de esses clients terem o mesmo bug é essencialmente zero.

Criando confiabilidade por meio de redundância e heterogeneidade

Na Alchemy, dedicamos centenas de milhares de horas para engenheirar o Cortex, um conjunto complexo de sistemas construídos do zero para ser heterogêneo e redundante, aumentando drasticamente nossa tolerância a falhas e garantindo que possamos responder com confiabilidade a qualquer requisição de blockchain.

Levamos anos para construir os sistemas complexos e interdependentes que tornam essa confiabilidade possível. Construir para controlar a confiabilidade é extremamente desafiador, mas contar com infraestrutura confiável é crucial para o sucesso do seu app.

Ao explorar opções de infraestrutura, uma das primeiras perguntas que você deve fazer a um provedor é: "Quão heterogênea e redundante é a sua infraestrutura? E que evidências você pode me mostrar que comprovem a confiabilidade dos seus sistemas?"

Benchmarks públicos de provedores de RPC podem ajudar a avaliar latência, taxas de sucesso e requisições que falharam, ao lado das alegações de arquitetura de um provedor.

O sucesso do seu app depende dessa escolha. Conte com a gente para ajudar!