Um aspecto importante, e perenivelmente subestimado, de "falta de confiança", "passar no teste de saída" e "auto-soberania" é a simplicidade do protocolo. Mesmo que um protocolo seja super descentralizado com centenas de milhares de nós, e tenha 49% de tolerância a falhas bizantinas, e os nós verifiquem completamente tudo com peerdas e starks quânticos seguros, se o protocolo for uma bagunça desajeitada de centenas de milhares de linhas de código e cinco formas de criptografia em nível de doutorado, no fim das contas esse protocolo falha nos três testes: * Não é sem confiança porque você tem que confiar em uma pequena classe de sumos sacerdotes que dizem quais propriedades o protocolo tem * Não passa no teste de saída porque, se equipes clientes existentes desaparecerem, é extremamente difícil para novas equipes alcançarem o mesmo nível de qualidade * Não é auto-soberano porque, se nem as pessoas mais técnicas conseguem inspecionar e entender a coisa, ela não é totalmente sua Também é menos seguro, porque cada parte do protocolo, especialmente se puder interagir com outras de maneiras complicadas, apresenta o risco de o protocolo falhar. Um dos meus receios com o desenvolvimento de protocolos Ethereum é que possamos ser muito ansiosos para adicionar novos recursos para atender necessidades altamente específicas, mesmo que esses recursos inflem o protocolo ou adicionem novos tipos de componentes interativos ou criptografia complicada como dependências críticas. Isso pode ser bom para ganhos funcionais de curto prazo, mas é altamente destrutivo para preservar a auto-soberania a longo prazo e criar uma hiperestrutura descentralizada de cem anos que transcende a ascensão e queda de impérios e ideologias. O problema central é que, se as mudanças no protocolo forem avaliadas sob a perspectiva de "quão grandes são elas como alterações ao protocolo existente", então o desejo de preservar a compatibilidade retroativa faz com que adições ocorram muito mais frequentemente do que subtrações, e o protocolo inevitavelmente incha com o tempo. Para combater isso, o processo de desenvolvimento do Ethereum precisa de uma função explícita de "simplificação" / "coleta de lixo". "Simplificação" possui três métricas: * Minimizando o total de linhas de código no protocolo. Um protocolo ideal cabe em uma única página – ou pelo menos em algumas páginas * Evitar dependências desnecessárias de componentes técnicos fundamentalmente complexos. Por exemplo, um protocolo cuja segurança depende exclusivamente de hashes (ainda melhor: exatamente de uma função de hash) é melhor do que um que depende de hashes e reticulados. Incluir isogenias é o pior de tudo, porque (desculpe aos nerds realmente brilhantes e trabalhadores que descobriram essas coisas) ninguém entende isogenias. * Adicionar mais _invariantes_: propriedades centrais nas quais o protocolo pode confiar, por exemplo, EIP-6780 (remoção por autodestruição) adicionou a propriedade de que no máximo N slots de armazenamento podem ser alterados por slot, simplificando significativamente o desenvolvimento do cliente, e EIP-7825 (por tampa de gás de transmissão) adicionou um custo máximo no processamento de uma transação, o que ajuda muito os ZK-EVMs e a execução paralela. A coleta de lixo pode ser fragmentada ou em grande escala. A abordagem fragmentada tenta pegar recursos existentes e simplificá-los para que sejam mais simples e façam mais sentido. Um exemplo são as reformas do custo do gás em Glamsterdam, que fazem com que muitos custos do gás antes arbitrários dependam de um pequeno número de parâmetros claramente ligados ao consumo de recursos. Uma coleta de lixo em grande escala estava substituindo o PoW pelo PoS. Outro provavelmente acontecerá como parte do consenso lean, abrindo espaço para corrigir um grande número de erros ao mesmo tempo ( ). Outra abordagem é a "compatibilidade retroativa no estilo Rosetta", onde recursos complexos mas pouco usados permanecem utilizáveis, mas são "rebaixados" de parte do protocolo obrigatório e se tornam código de contrato inteligente, de modo que novos desenvolvedores de clientes não precisam se preocupar com eles. Exemplos: * Depois de atualizarmos para abstração nativa total da conta, todos os tipos antigos de transmissão podem ser aposentados, e EOAs podem ser convertidos em carteiras de contratos inteligentes cujo código pode processar todos esses tipos de transação * Podemos substituir pré-compilações existentes (exceto aquelas que são _realmente_ necessárias) por EVM ou código RISC-V posterior * Eventualmente podemos mudar a VM de EVM para RISC-V (ou outra VM mais simples); O EVM poderia ser transformado em um contrato inteligente na nova VM. Por fim, queremos nos afastar dos desenvolvedores clientes que sentem a necessidade de lidar com todas as versões antigas do protocolo Ethereum. Isso pode ser deixado para versões mais antigas do cliente rodando em containers docker. A longo prazo, espero que a taxa de mudança para o Ethereum possa ser mais lenta. Acho que, por vários motivos, no fim das contas isso _deve_ acontecer. Esses primeiros quinze anos devem, em parte, ser vistos como uma fase da adolescência, onde exploramos muitas ideias e vimos o que funciona, o que é útil e o que não é. Devemos nos esforçar para evitar que as partes que não são úteis sejam um obstáculo permanente para o protocolo Ethereum. Basicamente, queremos melhorar o Ethereum de uma forma que se pareça com esta:

2026 é o ano em que recuperamos o terreno perdido em termos de auto-soberania e falta de confiança. Algumas do que isso significa na prática: Nós completos: graças ao ZK-EVM e ao BAL, será novamente mais fácil rodar localmente um nó e verificar a Ethereum chain no seu próprio computador. Helios: verifique de fato os dados que você está recebendo dos RPCs em vez de confiar cegamente neles. ORAM, PIR: peça dados de RPCs sem revelar quais dados você está pedindo, para que você possa acessar dapps sem que seus padrões de acesso sejam vendidos para dezenas de terceiros ao redor do mundo. Carteiras de recuperação social e timelocks: carteiras que não fazem você perder todo o seu dinheiro se você perder sua seed phrase, ou se um atacante online ou offline extrair sua seedphrase, e *também* não fazem todo o seu dinheiro ser backdoored pelo Google. UX de privacidade: faça pagamentos privados da sua carteira, com a mesma experiência do usuário que fazer pagamentos públicos. Resistência à censura de privacidade: pagamentos privados com o mempool ERC-4337, e em breve AA + FOCIL nativo, sem depender do ecossistema da emissora pública. UIs de aplicação: use mais dapps de uma interface onchain com IPFS, sem depender de servidores confiáveis que bloqueariam sua recuperação prática dos seus ativos se eles ficassem offline, e dariam uma interface sequestrada que rouba seus fundos se forem hackeados por um milésimo de segundo. Em muitas dessas áreas, nos últimos dez anos vimos um retrocesso sério no Ethereum. Os nós passaram de fáceis de rodar para difíceis de rodar. Os dapps passaram de páginas estáticas para gigantes complicados que vazam todos os seus dados para uma dúzia de servidores. As carteiras passaram de rotear tudo pelo RPC, que podia ser qualquer nó de sua escolha, inclusive no seu próprio computador, para vazar seus dados para uma dúzia de servidores de sua escolha. A construção de blocos tornou-se mais centralizada, colocando garantias de inclusão de transações Ethereum sob o controle de um número muito pequeno de construtores. Em 2026, não mais. Cada compromisso de valores que a Ethereum fez até agora – cada momento em que você poderia ter pensado: será que realmente vale a pena nos diluir tanto em nome da adoção mainstream – não estamos mais fazendo esse compromisso. Será um caminho longo. Não vamos conseguir tudo o que queremos no próximo lançamento do Kohaku, nem no próximo hard fork, nem no hard fork depois desse. Mas isso fará do Ethereum um ecossistema que merece não apenas seu lugar atual no universo, mas um muito maior. No computador mundial, não existe um senhor centralizado. Não existe um único ponto de falha. Só existe amor. Milady.