(Esta é uma continuação das discussões que tive com muitos participantes nas últimas semanas em torno da privacidade do Web3 agora e do “Cypherpunk Retreat” da Protocol Labs “.)
No momento, se uma carteira ou consultas de aplicativos eth_getLogs De um cliente de produção Ethereum, há uma chance real de perder silenciosamente os eventos. O resultado é simples e devastador: os saldos não somam, os históricos de transações mostram fundos gastos antes de serem recebidos, e os aplicativos não podem dar aos usuários uma conta confiável do que aconteceu. O consenso ainda pode estar intacto, mas os desenvolvedores da interface realmente dependem é corrompido.
Isso é pior do que um bug de consenso alto, porque é um silencioso um. Ele corroe a confiança de forma invisível, torna os resultados não reproduzí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 em seus padrões em torno do comportamento da RPC.
Exemplos concretos desse problema foram relatados em pelo menos Erigon, Nethermind e na cadeia de gnose, bem como no Ethereum Mainnet (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 ponto final do RPC que responde a essas perguntas é eth_getLogs. Todo produto grave do Ethereum depende disso. As carteiras usam para exibir transferências ERC-20; Os aplicativos defi confiam nele para verificar os estados do pool; Dexs rastreiam liquidez com ele; Ferramentas contábeis reconciliar saldos contra ele; O HOPR Mixet o usa para mapear sua topologia de canal de pagamento.
Considere o caso de uma carteira exibindo um saldo do USDC. Um simples eth_call Para o trie 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 filtrado para o endereço do usuário. Se esses eventos estiverem concluídos, o histórico poderá mostrar +100, –23, +423 = 500. Se, no entanto, o depósito inicial de +100 estiver ausente silenciosamente, o aplicativo será irremediavelmente corrompido. O histórico de transações não resume mais o saldo, o usuário parece gastar dinheiro antes de receber qualquer um e o aplicativo não pode resolver a inconsistência.
Quando a correção no limite do RPC é opcional, todos os produtos construídos no Ethereum herda essa fragilidade.
O Ethereum tem Hive, o conjunto de testes de compatibilidade do cliente e é valioso. Mas é escopo muito estreitamente e não possui poder de execução. De aproximadamente 190 testes de compatibilidade com RPC, apenas quatro tampa Eth_getlogs e cerca de metade deles estão falhando há meses. Os clientes contestam os resultados e sentem pouca pressão para resolvê -los. Passar ou falhar não tem consequências para a prontidão ou financiamento de liberação.
Os resultados atuais dos testes de colméia mostram muitos dos testes de compatibilidade de 190 RPC que falham (em vermelho).
O contraste com a web é impressionante. O conjunto de testes da plataforma da Web agora inclui mais de dois milhões de testes em HTML, CSS, JavaScript e APIs. Os vendedores do navegador os executam em integração contínua, o portão libera neles e confia neles para resolver ambiguidades nas especificações. Se o Chrome e o Firefox discordaram se document.querySelector() Retornou 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 equivalente a testes.
Os testes da plataforma da Web mostram a compatibilidade dos principais navegadores em mais de 2 milhões de testes.
O Ethereum precisa adotar a mesma combinação de padrões e conformidade que permitiu à escala da Web. Isso começa com os padrões. Um grupo de RPC e grupo de conformidade da camada de execução deve ser estabelecida, com o eth_getlogs como seu primeiro foco. A tarefa do grupo seria escrever especificações normativas e versárias para a semântica do RPC, incluindo casos de borda e manuseio de erros, e definir processos claros para gerenciamento de mudanças e resolução de disputas.
Também requer testes, não nas centenas, mas nas centenas de milhares. Deveríamos ter equipamentos 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, a falta de eventos ou o comportamento não determinístico pode ser superado rapidamente, em vez de descobrir meses depois na produção.
Finalmente, requer responsabilidade. A conformidade deve importar. As liberações do cliente não devem sair se falharem consistentemente nos testes de RPC, e o financiamento da Ethereum Foundation deve estar vinculado a atender a esses padrões. Os painéis públicos e as tabelas de compatibilidade devem tornar as discrepâncias visíveis, assim como estão no mundo do navegador. Quando todos podem ver quais clientes estão ficando para trás, os incentivos para corrigir as regressões mudam.
A credibilidade do Ethereum baseia -se em respostas determinísticas no limite do RPC. Atualmente, a correção é opcional, a cobertura é superficial e a divergência não possui consequências reais. Isso não é sustentável.
A Web quase entrou em colapso sob o peso das falhas de interoperabilidade e apenas escapou ao investir em padrões claros e suítes de teste maciças e respeitadas que os fornecedores executavam e respeitavam. O Ethereum pode evitar o mesmo destino – mas somente se faz o trabalho agora. Caso contrário, o vácuo de confiabilidade continuará sendo preenchido por provedores de API centralizados que monetizam as lacunas de correção, e a diversidade de clientes deixará de importar.
O Ethereum precisa de padrões-punk.
Fontesethresear
