Um aspecto importante, e perpetuamente subestimado, de "trustlessness", "passar no teste de desistência" 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 tudo completamente com peerdas seguras quânticas e starks, se o protocolo for uma bagunça incontrolável de centenas de milhares de linhas de código e cinco formas de criptografia de nível de doutorado, no final esse protocolo falha em todos os três testes: * Não é trustless porque você tem que confiar em uma pequena classe de altos sacerdotes que lhe dizem quais propriedades o protocolo possui * Não passa no teste de desistência porque se as equipes de clientes existentes forem embora, é extremamente difícil para novas equipes alcançarem o mesmo nível de qualidade * Não é auto-soberano porque se até mesmo as pessoas mais técnicas não conseguem inspecionar e entender a coisa, não é totalmente sua É também menos seguro, porque cada parte do protocolo, especialmente se puder interagir com outras partes de maneiras complicadas, carrega o risco de o protocolo quebrar. Um dos meus medos com o desenvolvimento do protocolo Ethereum é que podemos estar muito ansiosos para adicionar novos recursos para atender a necessidades altamente específicas, mesmo que esses recursos incham o protocolo ou adicionem novos tipos inteiros de componentes interativos ou criptografia complicada como dependências críticas. Isso pode ser bom para ganhos de funcionalidade a curto prazo, mas é altamente destrutivo para preservar a auto-soberania a longo prazo e criar uma hiperestrutura descentralizada de cem anos que transcenda a ascensão e a queda de impérios e ideologias. O problema central é que se as mudanças no protocolo forem julgadas a partir da perspectiva de "quão grandes são essas mudanças em relação ao protocolo existente", então o desejo de preservar a compatibilidade retroativa significa que adições acontecem muito mais frequentemente do que subtrações, e o protocolo inevitavelmente incha ao longo do tempo. Para contrabalançar isso, o processo de desenvolvimento do Ethereum precisa de uma função explícita de "simplificação" / "coleta de lixo". "Simplificação" tem três métricas: * Minimizar 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 em componentes técnicos fundamentalmente complexos. Por exemplo, um protocolo cuja segurança depende exclusivamente de hashes (ainda melhor: de exatamente uma função hash) é melhor do que um que depende de hashes e redes. Jogar isogenias é o pior de tudo, porque (desculpe aos verdadeiros nerds brilhantes que descobriram essas coisas) ninguém entende isogenias. * Adicionar mais _invariantes_: propriedades centrais nas quais o protocolo pode confiar, por exemplo, o EIP-6780 (remoção de auto-destruiçã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 o EIP-7825 (limite de gás por transação) adicionou um máximo ao custo de 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 de custo de gás em Glamsterdam, que fazem com que muitos custos de gás que eram anteriormente arbitrários, em vez disso, dependam de um pequeno número de parâmetros que estão claramente ligados ao consumo de recursos. Uma coleta de lixo em grande escala foi substituir PoW por PoS. Outra 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 estilo Rosetta", onde recursos que são complexos, mas pouco utilizados, permanecem utilizáveis, mas são "rebaixados" de serem parte do protocolo obrigatório e, em vez disso, se tornam código de contrato inteligente, para que novos desenvolvedores de clientes não precisem se preocupar com eles. Exemplos: * Depois de atualizarmos para a abstração de conta nativa completa, todos os tipos de tx antigos podem ser aposentados, e EOAs podem ser convertidos em carteiras de contrato inteligente cujo código pode processar todos esses tipos de transação * Podemos substituir as pré-compilações existentes (exceto aquelas que são _realmente_ necessárias) por código EVM ou mais tarde RISC-V * Podemos eventualmente mudar a VM de EVM para RISC-V (ou outra VM mais simples); EVM poderia ser transformada em um contrato inteligente na nova VM. Finalmente, queremos nos afastar da necessidade de os desenvolvedores de clientes lidarem com todas as versões mais antigas do protocolo Ethereum. Isso pode ser deixado para versões mais antigas de clientes rodando em contêineres docker. A longo prazo, espero que a taxa de mudança do Ethereum possa ser mais lenta. Acho que por várias razões isso _deve_ acontecer. Esses primeiros quinze anos devem ser vistos em parte como uma fase de adolescência onde exploramos muitas ideias e vimos o que funciona e 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 fardo permanente no protocolo Ethereum. Basicamente, queremos melhorar o Ethereum de uma maneira que se pareça com isto: