(Esta é uma continuação das discussões que tive com muitos participantes nas últimas semanas em torno do Web3 Privacy Now e do “Cypherpunk Retreat” do Protocol Labs.)
Neste momento, se uma carteira ou aplicativo consultar eth_getLogs de um cliente Ethereum de produção, há uma chance real de que ele perca eventos silenciosamente. O resultado é simples e devastador: os saldos não batem, os históricos de transações mostram que os fundos foram gastos antes mesmo de serem recebidos e os aplicativos não podem fornecer aos usuários um relato confiável do que aconteceu. O consenso ainda pode estar intacto, mas a interface na qual os desenvolvedores realmente confiam está corrompida.
Isto é pior do que um grande erro de consenso, porque é um silencioso um. Ele corrói a confiança de forma invisível, torna os resultados irreproduzíveis entre os clientes e leva os desenvolvedores a alguns provedores de infraestrutura “abençoados” que podem garantir respostas corretas. Isso, por sua vez, acelera a centralização. E este não é um bug isolado: é um sintoma de uma lacuna na cultura de testes do Ethereum e nos seus padrões em torno do comportamento RPC.
Exemplos concretos deste problema foram relatados pelo menos em Erigon, Nethermind e na Gnosis Chain, bem como na rede principal Ethereum (1, 2, 3, 4, 5, 6, 7, 8). Isso é sistêmico.
Para os usuários, as perguntas mais básicas são “De onde veio meu dinheiro?” e “Para onde foi?” O endpoint RPC que responde a essas perguntas é eth_getLogs. Todo produto Ethereum sério depende disso. As carteiras o utilizam para exibir transferências ERC-20; Os aplicativos DeFi dependem dele para verificar os estados do pool; Os DEXs rastreiam a liquidez com ele; as ferramentas contábeis reconciliam os saldos; o mixnet HOPR o utiliza para mapear sua topologia de canal de pagamento.
Considere o caso de uma carteira exibindo um saldo em USDC. Um simples eth_call à tentativa de armazenamento pode informar ao aplicativo que o usuário possui 500 USDC. Para explicar esse número, o aplicativo consulta todos os eventos de transferência anteriores do contrato filtrados para o endereço do usuário. Se esses eventos forem concluídos, o histórico poderá mostrar +100, –23, +423 = 500. Se, no entanto, o depósito inicial de +100 estiver faltando silenciosamente, o aplicativo estará irremediavelmente corrompido. O histórico de transações não soma mais ao saldo, o usuário parece gastar dinheiro antes mesmo de recebê-lo e o aplicativo não consegue resolver a inconsistência.
Quando a correção no limite RPC é opcional, todo produto construído no Ethereum herda essa fragilidade.
Ethereum tem Hive, o conjunto de testes de compatibilidade de cliente, e é valioso. Mas o seu âmbito é demasiado restrito e não tem qualquer poder de aplicação. Dos cerca de 190 testes de compatibilidade de RPC, apenas quatro cobrem eth_getLogs, e cerca de metade deles falha há meses. Os clientes contestam os resultados e sentem pouca pressão para resolvê-los. A aprovação ou a reprovação não acarretam consequências para a preparação do lançamento ou para o financiamento.
Os resultados atuais dos testes do Hive mostram que muitos dos 190 testes de compatibilidade RPC falharam (em vermelho).
O contraste com a web é impressionante. O conjunto de testes de plataforma web agora inclui mais de dois milhões de testes em HTML, CSS, JavaScript e APIs. Os fornecedores de navegadores os executam em integração contínua, liberam lançamentos neles e confiam neles para resolver ambigüidades nas especificações. Se o Chrome e o Firefox discordassem sobre se document.querySelector() retornasse o nó correto, a web moderna entraria em colapso. Ethereum está em uma situação análoga hoje com eth_getLogsmas sem a cultura ou governança de testes equivalente.
Os testes da plataforma Web mostram a compatibilidade dos principais navegadores em mais de 2 milhões de testes.
Ethereum precisa adotar a mesma combinação de padrões e conformidade que permitiu o crescimento da web. Isso começa com padrões. Um grupo de padrões e conformidade de RPC da camada de execução deve ser estabelecido, com eth_getLogs como seu primeiro foco. A tarefa do grupo seria escrever especificações normativas e versionadas para a semântica de RPC, incluindo casos extremos e tratamento de erros, e definir processos claros para gerenciamento de mudanças e resolução de disputas.
Também requer testes, não na casa das centenas, mas na casa das centenas de milhares. Deveríamos ter dispositivos canônicos para chamadas sensíveis ao histórico, testes diferenciais de grande alcance entre clientes e execuções contínuas em escala. Dessa forma, eventos ausentes ou comportamentos não determinísticos podem surgir rapidamente, em vez de serem descobertos meses depois na produção.
Finalmente, requer responsabilidade. A conformidade deve ser importante. Os lançamentos de clientes não devem ser lançados se falharem consistentemente nos testes de RPC, e o financiamento da Fundação Ethereum deve estar vinculado ao cumprimento desses padrões. Painéis públicos e tabelas de compatibilidade devem tornar as discrepâncias visíveis, assim como no mundo dos navegadores. Quando todos conseguem ver quais clientes estão ficando para trás, os incentivos para corrigir as regressões mudam.
A credibilidade do Ethereum depende de respostas determinísticas na fronteira RPC. Actualmente, a correcção é opcional, a cobertura é superficial e a divergência não acarreta consequências reais. Isso não é sustentável.
A web quase entrou em colapso sob o peso das falhas de interoperabilidade e só escapou investindo em padrões claros e conjuntos de testes massivos e respeitados que os fornecedores executavam e respeitavam. Ethereum pode evitar o mesmo destino – mas apenas se fizer o trabalho agora. Caso contrário, o vácuo de confiabilidade continuará a ser preenchido por provedores de API centralizados que monetizam em torno de lacunas de correção, e a diversidade de clientes deixará de ter importância.
Ethereum precisa de padrões punk.
Fontesethresear
