Precisão de dados: o problema pouco conhecido e endêmico no Web3

Uma equipe conhecida de NFT perdeu dezenas de milhares de usuários porque estava mostrando informações conflitantes para seus usuários (exemplo acima).

Um dos maiores protocolos de DeFi perdeu $2M investigando bugs que estavam causando erros de frontend para os usuários. Como o protocolo não conseguia identificar a causa raiz, o problema não foi resolvido por semanas.

Esses dois cenários vêm do mesmo problema: uma falta de precisão na infraestrutura de nós, que é um problema recorrente na Web3.

Como engenheiro, fundador, product manager ou até mesmo usuário, se a precisão dos nós ainda não está no seu radar, você precisa torná-la uma prioridade máxima para que seu app tenha sucesso.

Um pouco de contexto

Blockchains são operadas por nós que se comunicam em uma rede peer-to-peer. É esse elemento estrutural que permite a descentralização, uma das propostas de valor fundamentais da web3: em vez de depender de um intermediário central, milhares de nós registram transações propagando informações entre si de forma trustless.

Para entregar aos usuários resultados corretos e consistentes, a rede de nós precisa concordar sobre o estado mais recente da blockchain. Isso é extremamente desafiador em uma rede peer-to-peer, porque a informação não chega a cada nó ao mesmo tempo.

Isso significa que quando uma pessoa interage com um dApp que depende de nós para lhe fornecer dados:

• Os nós nem sempre servem os mesmos dados ➡️
• O usuário nem sempre recebe o que espera

Na maioria das vezes, quando usuários recebem informações inesperadas ou conflitantes que não conseguem explicar, é porque há uma falta de precisão entre os nós que estão usando.

Na Alchemy, definimos precisão como o estado em que uma pessoa interage com um dApp e recebe de volta dados corretos e consistentes.

Neste artigo, vamos explicar:

• Por que a precisão é um problema específico da web3
• As limitações de resolver a precisão com um único nó
• As limitações de resolver a precisão com um load balancer
• Como a falta de precisão pode criar problemas generalizados para um app
• Como o Cortex engine da Alchemy resolve a precisão da blockchain

Precisão existe quando uma pessoa interage com um dapp e recebe de volta dados corretos e consistentes

Na web2, [sistemas centralizados tornam a precisão um problema fácil de resolver](https://ethereum.org/en/developers/docs/web2-vs-web3/#:~:text=Web2 refers to the version,that run on the blockchain), porque a informação só pode vir de uma fonte. Mas o sistema distribuído da web3 causa uma infinidade de problemas novos e complicados, incluindo:

• Implementação complexa
• Desafios para garantir que a informação chegue aos participantes mais distantes da rede (literalmente leva mais tempo para a informação chegar a nós mais distantes em uma rede)
• Desafios com coordenação de rede

Todos esses desafios, que podem criar uma falta de precisão entre um grupo de nós, podem levar a:

• Entregar experiências quebradas
• Perder clientes
• Perder tempo e dinheiro corrigindo o problema retroativamente

Os problemas de rodar um único nó

Se o problema de precisão de dados vem da comunicação entre vários nós, você pode decidir rodar um único nó você mesmo.

Digamos que você esteja rodando seu próprio nó único, e um usuário faz uma chamada para o seu dApp:

• Ele pede o último bloco
• Seu nó diz que o último bloco é 4

✅ Isso funciona!

Mas há um problema.

Só vai funcionar até certo ponto.

Rodar tráfego por um único nó vai limitar drasticamente a escalabilidade e a confiabilidade do seu app:

• Escalabilidade: Se seu dApp tem 100 usuários hoje, mas o uso exige que ele escale 10x, um único nó não conseguirá gerenciar efetivamente o aumento de carga de requisições
• Confiabilidade: Se você depende de um único nó, quando esse nó cair, seu dApp também vai cair. E como os nós são notoriamente pouco confiáveis, com apenas um, você terá muito menos uptime do que precisa (já medimos uptime de um único nó tão baixo quanto 72% em alguns casos).

O tempo que sua equipe gastaria com manutenção de nós é tempo que ela não pode gastar construindo produtos e experiências para seus clientes.

Ok, então você percebeu que um único nó é insuficiente para as necessidades do seu negócio. Então o que você pode fazer a seguir?‍

Os problemas de usar um load balancer

Você pode querer tentar um provedor de infraestrutura que usa um load balancer para gerenciar tráfego entre múltiplos nós; esse é um design de infraestrutura super comum na web3.

Load balancing é um mecanismo de escalonamento horizontal, originalmente utilizado na web2. Pense em load balancing como escolher a fila mais curta no supermercado - o load balancer vai direcionar o tráfego do seu dApp para o nó com a fila mais curta.‍

Dê uma olhada no exemplo abaixo.

Um usuário faz uma chamada para o seu dApp:

• Ele pede o último bloco
• Via Nó A, seu dApp diz que o último bloco é 2

Então, o usuário pergunta novamente para confirmar:

• Dessa vez a query é roteada para o Nó B
• Via Nó B, seu dApp diz que o último bloco é 4

Como o sistema ainda está roteando cada requisição por um único nó, e a qualquer momento, esse nó pode não ter a informação mais recente, os resultados são frequentemente incorretos. Seus usuários vão receber resultados conflitantes impossíveis de entender.

Load balancing gera mais escala e confiabilidade do que um único nó consegue manter, mas isso vem às custas da precisão.

Quando o tráfego é roteado por um load balancer, os nós podem ter informações diferentes sobre:

• Últimos blocos
• Transações mais recentes
• Transações pendentes

Esses problemas podem significar que:

• Desenvolvedores experimentam dados inconsistentes
• Requisições falham
• Aplicações falham
• Um único usuário verá resultados conflitantes para a mesma requisição
• Múltiplos usuários verão resultados conflitantes para a mesma requisição

Ainda não está convencido de que isso é um grande problema? Continue lendo.

Como a falta de precisão causa problemas graves

Digamos que Isaac quer entrar em uma DAO, e para isso, ele precisa comprar o token dela.

• Isaac pergunta a uma Exchange Descentralizada (DEX): "O token da DAO ainda está disponível?"
• O provedor de infraestrutura da DEX roteia a requisição de Isaac para o Nó A.
• Via Nó A, a DEX diz a ele: "Sim, os tokens ainda estão disponíveis."

✅ Tokens disponíveis!

Isaac vai fazer sua compra.

• O provedor de infraestrutura da DEX roteia a requisição de Isaac para o Nó B.
• Via Nó B, a DEX diz a ele: "Transação falhou."

Como a DEX estava usando um provedor de infraestrutura que fazia load balancing entre nós (um mecanismo de escalonamento super comum na web3), quando Isaac confirmou que o token ainda estava disponível, o Nó A retornou uma informação que, nesse caso, estava desatualizada.

Isso ressalta o ponto central: em um dado momento, a informação de um nó individual, que é de onde a informação sempre vem quando se usa um load balancer, não pode ser confiável.

Esse nó pode não ter a informação mais recente, e se for esse o nó que responde à sua requisição, sua transação (ou transações subsequentes) provavelmente falhará ou apresentará comportamento inesperado.

Problemas de precisão causam uma ampla variedade de estados de falha

O que aconteceu com Isaac é um dos muitos estados de falha causados pela falta de precisão dos nós.

Vamos ver mais alguns estados de falha potenciais:

1. Execuções de smart contract retornam respostas conflitantes quando deveria haver apenas um resultado factual. Por exemplo:

• Usuário pergunta: "Quem é o dono desse Bored Ape?"
• API retorna: "Alice"
• Então o usuário pergunta: "Me diga quais apes a Alice possui?"
• API retorna: "Alice não possui nenhum"‍

Por que isso aconteceu? Com uma infraestrutura dependente de load balancer, o estado dos smart contracts, e portanto o que acontece quando você os executa, será diferente dependendo de qual nó atende à requisição.

2. Um dApp retorna um "nonce" incorreto (um identificador único para cada transação individual de qualquer endereço de carteira), fazendo transações subsequentes falharem. Por exemplo:

• Usuário completa a transação 1 com nonce 100
• Usuário pergunta: "Qual é o próximo nonce?"
• API retorna: 100 (isso deveria ser impossível, já que o nonce 100 já foi concluído)
• A próxima transação será automaticamente rejeitada

Por que isso aconteceu? Com infraestrutura imprecisa, transações pendentes podem acabar existindo apenas em um único nó, então quando você tenta obter informações sobre o estado dessas transações pendentes ou das carteiras que as enviaram, com muita frequência há dados ausentes ou enganosos retornados.

Esses estados de falha são insidiosos, impossíveis de entender, e vão impactar severamente a saúde do seu app

Algumas coisas que podem acontecer:

Você pode ingerir dados imprecisos que vão corromper seus bancos de dados, exigindo tempo e esforço para corrigir.

Veja o caso da Origin, por exemplo. Erros de RPC e depuração eram onipresentes com o primeiro provedor de infraestrutura deles, e depurar os erros tomava muito tempo da equipe.

Eles descobriram que um nó respondia a uma requisição, mas esse nó estava alguns blocos atrás de outro nó que respondeu a outra requisição.

Esses problemas de estado eram praticamente impossíveis de investigar, e quando finalmente identificaram a causa raiz, descobriram que o problema tinha corrompido todo o sistema deles.

Como não existem mensagens de erro ou códigos de falha para esses problemas, você a) não pode tratá-los proativamente no seu código e b) vai gastar horas depurando quando eles acontecerem; isso será igualmente confuso para seus usuários:

**Usuários podem enviar transações baseadas em dados desatualizados, que consequentemente têm garantia de falhar; eles perderão taxas de gas como resultado:**‍

Usuários podem ver UIs conflitantes no seu dApp, refletindo de forma inconsistente se uma transação foi ou não bem-sucedida. Eles vão atribuir essa falha à experiência de frontend do seu dApp:

Usuários podem pagar a mais porque acham que uma transação não foi minerada com sucesso, e tentam de novo; na realidade, a original passou, mas não foi refletida corretamente:

Construindo para precisão

Se ainda não está claro, em redes blockchain, a falta de infraestrutura precisa pode ter um impacto muito negativo no seu dApp e nos seus usuários.

Você precisa trabalhar com um provedor de infraestrutura que:

• Trata a precisão como uma prioridade fundamental
• Tenha um sistema sustentável, distinto de load balancing, para manter a precisão quando seu dApp escalar

Comparando provedores de nós

Compilamos dados que comparam a precisão entre alguns provedores de infraestrutura de nós bem conhecidos. Use essa ferramenta para comparar a precisão você mesmo também.

Precisão é uma parte da avaliação de um provedor. Você também pode comparar latência atual, taxas de sucesso e requisições falhadas nos benchmarks de provedores RPC da Alchemy.

Em nossos testes, consultamos o método JSON RPC eth_blockNumber um total de ~1.072.000 vezes para obter o número do bloco mais recente de cada provedor ao longo de um período de 24 horas. Este é um exemplo simples para comparar imprecisão de dados. Existem muitos outros que tendem a falhar com mais frequência, e de forma mais catastrófica.

Nota Em nosso snapshot de exemplo do dashboard, consultamos e registramos a precisão dos dados por um único dia.

*Detalhes completos da metodologia no apêndice.

O que você pode fazer para obter dados precisos?

Para garantir a precisão para seus apps e seus clientes, a Alchemy investiu centenas de milhares de horas de engenharia e desenvolveu centenas de inovações únicas para construir o Cortex engine da Alchemy, que garante precisão consistente dos dados com os benefícios de escalabilidade e confiabilidade de uma infraestrutura multi-nó.

Cortex é muito mais do que um monte de nós conectados - na verdade, isso é apenas uma fração do que o Cortex engine é. O Cortex combina sistemas personalizados, escaláveis e distribuídos que basicamente permitem que nossa API atue como um único nó, o que resolve todos os problemas de precisão que discutimos.

Como isso funciona?

Construímos uma camada explícita de consistência chamada Vox Nodi (a voz dos nós). A responsabilidade do Vox Nodi é garantir que qualquer requisição de blockchain que estamos ajudando a atender retorne um resultado consistente.

Isso funciona basicamente rodando um algoritmo de consenso em toda a nossa infraestrutura, onde cada parte da infraestrutura pode votar sobre o estado correto da blockchain.

Roteando e ajustando corretamente as queries, esse sistema garante que, apesar de vários nós terem visões diferentes dos dados de transação em um dado momento, os resultados sejam sempre consistentemente precisos.

Em resumo, o Vox Nodi garante que qualquer requisição para nossa API seja retornada rapidamente, de forma confiável, e com 100% de precisão dos dados.

E o Cortex ainda permite que desenvolvedores escalem de forma infinita e confiável, porque em vez de um nó individual, há um engine de blockchain completo e distribuído respondendo a cada requisição.

Em resumo, isso não é um load balancer.

Implicações & conclusão

Existem muitas dimensões diferentes a considerar ao escolher como conectar seu dApp à blockchain: A capacidade de um provedor de entregar precisão deve ser o número um na sua lista.

Na Alchemy, precisão é uma prioridade máxima. Comece na Alchemy gratuitamente hoje.

Apêndice

Metodologia de benchmarking

Ao pensar em como comparar precisão, partimos de princípios básicos e testamos uma das chamadas RPC mais fundamentais do Ethereum: eth_blockNumber.

Como lembrete, eth_blockNumber retorna o número do bloco mais recente da rede Ethereum, e em uma rede descentralizada, o bloco com o número mais alto contém as transações mais recentes.

Por isso, em condições normais de rede, chamar eth_blockNumber a partir de um único nó/provedor de nó deveria retornar apenas números de bloco que aumentam em valor. Qualquer inconsistência nesse aumento é indicativa de uma reversão ou, quando acontece com mais frequência, de uma possível imprecisão de dados do provedor.

Note que isso é diferente de um 'reorg', onde uma nova cadeia mais longa substitui dados existentes em um nó. 'Reorgs' sempre terão pelo menos tantos blocos quanto os dados já existentes em um nó, então se virmos o número do bloco retroceder, podemos afirmar com certeza que isso é causado por uma infraestrutura com problemas.

Para entender como medimos dados desalinhados, vamos supor que temos a seguinte sequência de números de bloco depois de consultar eth_blockNumber um total de 13 vezes.

Dada essa sequência, encontramos um total de 5 erros nos índices de bloco 6, 7, 9, 10 e 11. Isso significa que nos blocos 6, 7, 9, 10 e 11, os blocos retornados não seguiram a sequência esperada de valores ascendentes, evidenciando algum problema subjacente de precisão de dados.

NOTA: Assim que registramos que o provedor de nó está no número de bloco 2, assumimos que quaisquer valores subsequentes de 1 estão incorretos e equivalem ao provedor "viajando no tempo" e fornecendo o valor de bloco atual com 1 bloco de atraso. Da mesma forma, assim que registramos que o provedor de nó está no número de bloco 3, quaisquer instâncias dos blocos 1 ou 2 aparecendo agora estão desalinhadas. Para simplificar este teste de benchmarking, medimos explicitamente a precisão de dados de provedores individuais e não fazemos comparação cruzada de dados de bloco entre provedores diferentes.