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: