Numa discussão abrangente que rapidamente se espalhou pela comunidade de desenvolvedores do Ethereum, Vitalik Buterin apresentou esta semana um argumento contundente a favor de um pilar da descentralização que ele chamou de “subestimado”: a simplicidade do protocolo. Publicando no X, Buterin argumentou que a resiliência a longo prazo de blockchains como o Ethereum depende menos de criptografia exótica ou de números massivos de descentralização e mais de se o protocolo permanece pequeno o suficiente para que desenvolvedores e investigadores comuns possam inspecionar, compreender e reimplementar de forma significativa.
O ponto de Buterin é direto, mas simples. Mesmo que uma rede tenha centenas de milhares de nós, 49% de tolerância a falhas bizantinas e ferramentas de verificação de última geração, ela ainda falha em ser verdadeiramente “sem confiança”, em passar no “teste de saída” ou em ser genuinamente autossoberana se essas garantias só puderem ser explicadas por uma classe restrita de especialistas. “Se o protocolo é uma confusão desajeitada de centenas de milhares de linhas de código e cinco formas de criptografia de nível de doutoramento,” escreveu ele, “esse protocolo acaba falhando em todos os três testes.” Em resumo, a complexidade cria novas formas de centralização.
Simplicidade é uma Característica de Segurança
As implicações dessa observação são práticas, bem como filosóficas. Buterin alertou que recursos acumulados e adições criptográficas direcionadas podem oferecer benefícios de curto prazo ao ecossistema, enquanto minam sua capacidade de sobreviver por décadas. Quando as equipes de clientes se dissolvem ou quando novos contribuidores tentam assumir a manutenção, uma base de código extensa torna-se uma barreira. Se mesmo participantes altamente técnicos não podem auditar razoavelmente o sistema, sua reivindicação de ser “seu” é enfraquecida.
Buterin propôs uma definição tripla do que chama de “simplificação”. Primeiro, minimizar o total de linhas de código. Um protocolo que, em princípio, poderia caber numa única página, ou pelo menos em algumas páginas, é inerentemente mais fácil de entender. Segundo, evitar dependências desnecessárias em primitivas técnicas fundamentalmente exóticas.
Segurança que pode ser reduzida a um pequeno conjunto de suposições, idealmente uma única função hash, é preferível a um patchwork que mistura hashes, reticulados e isogenias, sendo que este último território, ele admitiu, é “ninguém entende” mesmo para os especialistas que o construíram. Terceiro, aumentar o número de invariantes: propriedades claramente declaradas e rigidamente aplicadas que tornam o desenvolvimento de clientes mais simples. Ele apontou para EIPs recentes, como a remoção de auto-destruição e limites de gás por transação, como exemplos de passos que adicionaram invariantes úteis e reduziram a complexidade para os implementadores.
A discussão vai além do apelo e esboça caminhos concretos. Buterin defendeu uma “coleta de lixo” contínua no desenvolvimento de protocolos: passos deliberados para podar ou rebaixar recursos que são complexos, pouco utilizados ou que podem viver com segurança fora do código obrigatório do cliente. Isso poderia ser feito aos poucos; as reformas recentes no custo do gás que ele mencionou visam substituir valores arbitrários de gás por modelos de custo vinculados ao consumo de recursos, ou em uma revisão maior. Ele observou que a transição de proof-of-work para proof-of-stake foi, ela própria, uma grande limpeza e sugeriu que o consenso Lean pode oferecer outra oportunidade para “corrigir uma grande quantidade de erros ao mesmo tempo.”
Outra ideia que ele propôs é uma espécie de compatibilidade retroativa ao estilo Rosetta. Em vez de forçar cada cliente a implementar todas as peculiaridades veteranas da cadeia, rebaixar recursos raramente utilizados, mas complexos, para camadas de contratos inteligentes opcionais. Nesse modelo, a abstração de conta nativa poderia permitir que tipos antigos de transações fossem tratados ao nível de contratos inteligentes, enquanto pré-compilados legados poderiam ser re-codificados como contratos ou migrados para uma VM mais simples, como RISC-V, a longo prazo. Desenvolvedores preocupados com suporte a legado poderiam rodar clientes mais antigos em containers, enquanto os novos permanecem mais leves.
Um Roteiro para o Futuro do Ethereum
O que emerge do thread de Buterin é um apelo à mudança cultural tanto quanto técnica. Ele pediu à comunidade que pare de julgar propostas apenas pelo tamanho em relação ao protocolo existente, uma mentalidade que tende a favorecer mudanças aditivas em nome da compatibilidade retroativa. Em vez disso, ele sugeriu que o processo inclua uma função explícita de simplificação: um esforço disciplinado e contínuo para subtrair, assim como adicionar.
A imagem que acompanha muitas republicações do thread, três motores de foguete complexos alinhados lado a lado, cada um um estudo em tubos, fios e detalhes engenheirados, tem sido amplamente compartilhada como uma metáfora. Assim como um sistema de foguete, um protocolo com muitas partes interagindo pode ser frágil: quanto mais peças móveis e componentes especializados, mais maneiras há de algo dar errado. A mensagem de Buterin, na prática, é que a melhor hiperestrutura de longa duração é aquela cujo núcleo você pode colocar numa página e entregar a um novato.
Para um protocolo que aspira a transcender regimes políticos e modas tecnológicas, esses novatos importam. “Estes primeiros quinze anos,” escreveu ele, referindo-se ao ciclo de vida do Ethereum até agora, “devem, em parte, ser vistos como uma fase de adolescência,” um período de experimentação criativa. O desafio, argumentou, é manter os experimentos úteis enquanto impede que os inúteis se tornem um peso permanente.
O thread já provocou debates animados. Alguns desenvolvedores alertam que a simplicidade deve ser equilibrada com a necessidade de primitivas poderosas e flexibilidade, enquanto outros veem uma necessidade urgente de uma poda sistemática que Buterin defende. Se nada mais, a conversa marca um consenso crescente de que a descentralização não é medida apenas por contagens de nós ou por sinos e apitos criptográficos, mas por quão acessível o sistema permanece para aqueles que constroem, mantêm e, por fim, se afastam dele, e depois voltam a entendê-lo.
Isenção de responsabilidade: As informações contidas nesta página podem ser provenientes de terceiros e não representam os pontos de vista ou opiniões da Gate. O conteúdo apresentado nesta página é apenas para referência e não constitui qualquer aconselhamento financeiro, de investimento ou jurídico. A Gate não garante a exatidão ou o carácter exaustivo das informações e não poderá ser responsabilizada por quaisquer perdas resultantes da utilização destas informações. Os investimentos em ativos virtuais implicam riscos elevados e estão sujeitos a uma volatilidade de preços significativa. Pode perder todo o seu capital investido. Compreenda plenamente os riscos relevantes e tome decisões prudentes com base na sua própria situação financeira e tolerância ao risco. Para mais informações, consulte a
Isenção de responsabilidade.
