Vitalik e Yoav gentilmente revisaram este post, mas as opiniões são minhas.

Se você não acompanhou o drama AA, aqui está uma rápida recapitulação:

• Várias semanas atrás, o PEI-3074, uma proposta que traria muitos dos benefícios do AA para os usuários do EOA, foi aprovado pelos principais devs para entrar no "Pectra", o próximo garfo difícil de Ethereum.
• Desde então, muitos na comunidade ERC-4337, especialmente os próprios autores do 4337, têm fortemente recuando no 3074, com base em @yoav/3074-implications">preocupações de centralização e sua incompatibilidade com @yoav/AA-roadmap-May-2024">AA roadmap, que é centrado em torno de 4337 e seu primo 7560 (também conhecido como "AA nativo").
• Na semana passada, Vitalik propôs PEI-7702 como alternativa ao 3074. Ele atinge principalmente o mesmo objetivo - trazendo muitos benefícios do AA para os usuários do EOA - mas de uma forma que é mais compatível com o 4337 hoje, e compatível com o "final AA" que é o 7560.
• Neste momento, os principais devs estão deliberando sobre o PEI-7702, mas discussões preliminares e sentimentos da comunidade sugerem que o PEI-7702 provavelmente substituirá o PEI-3074 em Pectra.

Pessoalmente, fiquei muito feliz com o resultado: os usuários do EOA em breve poderão desfrutar da maioria dos benefícios do AA, usando as ferramentas e infra construídos para o ERC-4337.

E, no entanto, não posso deixar de sentir que a forma como alcançámos este resultado estava longe de ser a ideal, uma opinião que muitos tinham expressado nas últimas semanas. Sinto que, com um processo melhor, poderíamos ter economizado coletivamente uma tremenda quantidade de energia e dor de cabeça, e chegado ao resultado desejado muito mais cedo.

Neste post, eu quero:

• Identifique o que deu errado no processo.
• Propor um modelo mental para pensar Ethereum governança.
• Sugerir melhorias para evitar falhas de governança semelhantes no futuro.

Por que o processo deixou as pessoas infelizes

Toda essa saga deixou muita gente infeliz por vários motivos:

• Demorou anos para que o 3074 fosse aprovado.
• Somente depois que o 3074 foi finalmente aprovado, os devs principais receberam uma enorme tonelada de rejeições da comunidade 4337.
  • Os próprios 4337 autores, por outro lado, expressaram repetidamente suas preocupações com o 3074 para devs centrais, sem sucesso.
• Agora estamos no caminho certo para não aprovar o 3074 e substituí-lo por outro PEI (7702).

Agora, não há nada inerentemente errado com qualquer um dos itens acima:

• Tudo bem que uma discussão demore anos.
• Não há problema em um PEI receber rejeições depois de aprovado.
• Não há problema em cancelar a aprovação de um PEI depois que ele for aprovado, se novos problemas forem identificados.

No entanto, provavelmente podemos concordar que as coisas poderiam ter corrido de forma mais tranquila. Imagine se foi assim:

• A comunidade 4337 engajou ativamente os devs principais enquanto eles estavam debatendo o 3074. Agora, apenas um dos dois resultados é possível:
  • Ou o 3074 foi aprovado (e possivelmente modificado) depois de levar o feedback da comunidade 4337 para conta, caso em que a comunidade 4337 estaria a bordo do 3074 e não estaríamos revertendo o 3074.
  • Ou, o 3074 nunca foi aprovado, mas a comunidade 4337 e os devs do núcleo trabalharam juntos para uma proposta com a qual todos estão felizes, à la 7702.

A voz de todos é ouvida e não há reversões dramáticas. Isso teria sido bom – então por que não aconteceu?

O que deu errado?

Refletindo sobre o processo, os dois lados do debate apontaram o dedo um para o outro.

Os principais devs (e autores de PEI-3074) sentiram que era culpa das "4337 pessoas" não se envolverem ativamente com o processo All Core Devs (ACD), onde os EIPs são deliberados por um longo tempo antes de serem finalmente aceitos pelas equipes do cliente e, assim, implementados no protocolo.

A qualquer momento desta deliberação, diz o argumento, as "4337 pessoas" poderiam ter entrado e expressado suas preocupações, em vez de esperar até depois que 3074 já tivessem sido aprovadas. Afinal, o processo de ACD é bem documentado, as reuniões são abertas a todos, e há pessoas como Tim Beiko que tuitam ativamente resumos após cada reunião de ACD. Então, se as 4337 pessoas se preocupavam tanto com essa questão, por que não gastaram tempo para se engajar?

Por outro lado, a equipe AA (4337 autores) apontou que eles estavam participando de reuniões de ACD e empurraram para trás em 3074 todas as chances que puderam, mas os devs principais não ouviram. Quanto à comunidade 4337, eles se sentiram principalmente cegos - a maioria das pessoas estava sob a impressão de que 3074 estava morto, e nem mesmo estavam cientes de que 3074 estava sendo ativamente considerado para a inclusão.

Muitas pessoas também sentiram que o processo de ACD era muito opaco e não amigável para a participação de pessoas que têm "empregos reais" e não podiam se dar ao luxo de acompanhar todas as atualizações do ACD. Alguns também consideraram que deveria ser responsabilidade da ACD procurar ativamente o feedback das partes interessadas relevantes, neste caso a comunidade 4337.

É minha opinião, no entanto, que ambos os lados erraram o alvo. Há um problema muito mais profundo no trabalho e, até que consertemos ou, pelo menos, reconheçamos o problema, continuaremos nos deparando com falhas de governança seguidas de apontamentos improdutivos.

A causa raiz

A verdadeira causa da falha de governança foi que, ao contrário do que se pensa, o ACD NÃO é o único poder de governança para atualizações protocolo e, neste caso, foi substituído por outro poder de governança.

Problematicamente, o outro poder de governança raramente é reconhecido, apesar de ter uma influência ainda maior do que a ACD nas questões mais importantes da Ethereum, como AA e dimensionamento.

Neste artigo, vou chamar esse poder de "roteiros".

Toda essa saga 3074/7702, como argumentarei, não é mais nem menos do que um exemplo do poder dos roteiros que sobrecarregam o poder do ACD. E se estamos falando de governança, então toda vez que notamos um poder invisível sobrecarregando um poder visível, devemos estar muito preocupados, pois o que é invisível é irresponsável e, portanto, deve ser trazido à luz.

O que é um roteiro?

Qualquer pessoa na comunidade Ethereum deve ter se deparado muito com o termo "roadmap", como no "roadmap centrado em rollup", "ETH 2.0 roadmap" ou neste debate "@yoav/AA-roadmap-May-2024">the AA roadmap".

Uma busca de "roteiro" em Ethereum Magicians

Para ilustrar meu ponto, vamos imaginar uma reunião do ACD onde os principais desenvolvedores estão discutindo como dimensionar Ethereum:

• Core Dev Bob: Eu apoiar PEI 1234 que propõe que nós acelerar tempo de bloqueio 10X, aumentar o tamanho do bloco 10X & Gota taxa 100X.
• Outros devs principais: ... você está fora de sua * mente?

Vamos pensar por um segundo aqui. Por que os devs do núcleo simplesmente derrubaram o que Bob disse? Ele apenas propôs uma forma muito legítima de escala. Solana e muitos outros L1s fazem isso, com grandes efeitos de escala.

A razão, é claro, é que esse PEI imaginário é contra o próprio roteiro de escalabilidade "rollup-centric" do próprio Ethereum, que diz, entre outras coisas, que é crucial para a descentralização do blockchain para que usuários regulares possam executar um nóe, portanto, o PEI imaginário está fora de questão, uma vez que aumentaria consideravelmente a barreira para executar um nó.

O que eu queria ilustrar com este exemplo é que os principais devs, que participam do processo de ACD e decidem sobre protocolo atualizações, são guiados por uma força maior que estou chamando de roteiros. Há o roteiro de escala, o roteiro AA, o roteiro MEV, você o nomeia – e coletivamente eles formam o roteiro Ethereum no qual os desenvolvedores principais baseiam suas decisões.

Quando os devs principais estão desalinhados com um roteiro

Como os roteiros não são uma parte formal da governança, não há garantia de que os desenvolvedores principais estejam alinhados com eles. Em particular, como não há um processo formal para "aprovar" um roteiro, nem todos os roteiros são percebidos como tendo igual legitimidade. Cabe aos pesquisadores por trás dos roteiros defender diligentemente seus roteiros para os devs principais e a comunidade em geral, a ordem de ganhar legitimidade e, portanto, adesão dos devs principais.

No caso do AA, o próprio Vitalik pressionou por um roteiro AA centrado em 4337 em @vbuterin/conta_abstraction_roadmap">multiple ocasiões, mas no geral tem sido principalmente a equipe 4337, notavelmente Yoav e Dror, que defendem o roteiro AA centrado em 4337 em conferências, fóruns online e reuniões ACD.

No entanto, apesar desses esforços, houve fortes oposições de alguns desenvolvedores centrais contra o roteiro AA centrado em 4337. Eles sentiram que o 7560, a versão nativa do 4337 que os clientes eventualmente teriam que implementar, é excessivamente complexo e não o único candidato viável para o "final AA". Eventualmente, o ACD decidiu aprovar o 3074, apesar das objeções da equipe do 4337 de que ele fragmentaria o ecossistema AA criando uma alternativa e @yoav/3074-implications">pilha de tecnologia AA menos descentralizada.

Uma vez que o 3074 foi aprovado, no entanto, houve uma forte reação de toda a comunidade do 4337, o que forçou os devs do núcleo a se envolverem novamente no debate do 3074. O debate então tornou-se um impasse onde nem os 4337 autores nem os 3074 autores conseguiram convencer uns aos outros, até que Vitalik veio em na décima primeira hora e propôs PEI-7702 como uma alternativa ao 3074 que é explicitamente compatível com o "final AA" centrado em 4337, e assim empurrando o conflito em favor do roteiro AA.

O papel de Vitalik

Embora Vitalik se carregue como pesquisador, esta saga mostra claramente que Vitalik traz um poder de governança qualitativamente diferente do que outros pesquisadores. Por isso, levanta-se a questão: que papel desempenha Vitalik na governação Ethereum?

Pessoalmente, acho útil pensar na Vitalik como o CTO de uma empresa muito, muito grande.

(Para fins desta analogia, não há CEO nesta empresa, diga-se de passagem.)

Se você trabalhou em qualquer empresa de tecnologia com mais de, digamos, 50 pessoas, sabe que a CTO não pode estar envolvida em todas as decisões técnicas. Em uma certa escala, as decisões técnicas necessariamente se tornam descentralizadas – normalmente há uma subequipe para cada área do produto da empresa, e a subequipe é principalmente livre para tomar suas próprias decisões em relação a detalhes específicos de implementação.

Além disso, o CTO também não é necessariamente o maior especialista em todos (ou quaisquer) assuntos. Poderia muito bem haver engenheiros em uma empresa que são melhores do que os CTO em áreas específicas. Portanto, em questões de debates técnicos, muitas vezes são os engenheiros que tomam as decisões finais.

O CTO, no entanto, define a visão técnica da empresa. A execução da visão fica a cargo dos devs.

Embora esta não seja uma analogia perfeita, acho que captura razoavelmente o papel de Vitalik no ecossistema. Vitalik não está envolvido em todas as decisões técnicas – ele não pode estar. Ele também não é o maior especialista em todas as áreas. Mas ele tem uma influência esmagadora na definição dos roteiros para todos os aspectos críticos da Ethereum (escala, AA, Proof-of-Stake...), não apenas por causa de sua experiência técnica, mas também porque ele é o juiz final para saber se um roteiro é consistente com a visão de Ethereum – sua visão.

Todo produto de sucesso começa com uma visão

Se minha opinião de que Vitalik é o CTO de Ethereum não é controversa o suficiente para você, aqui vem a parte mais controversa: devemos abraçar Vitalik como o CTO.

É minha opinião como fundador de uma startup que por trás de todo produto de sucesso – e sim, Ethereum é um "produto" no sentido de que resolve problemas reais para pessoas reais – deve haver uma visão coerente. E uma visão coerente deve necessariamente ser definida por um pequeno número de pessoas, como os fundadores de uma startup e, muitas vezes, apenas um fundador.

A beleza de Ethereum é que, apesar de ser um sistema tão complexo com tantas partes móveis, as peças se encaixam lindamente em um computador descentralizado funcional que está movimentando bilhões de dólares em valor todos os dias. E a forma como chegamos até aqui não foi por meio de projetos de comissões. É precisamente por causa da liderança ativa de Vitalik através de sua visão que somos capazes de chegar a um produto coerente e bonito que é Ethereum hoje. Ethereum foi uma ideia de Vitalik em 2015, e continua sendo assim até hoje.

Não se trata, é claro, de menosprezar as contribuições de outros pesquisadores e engenheiros, que merecem a maior parte dos créditos por levarem Ethereum até onde estão hoje. No entanto, isso não é incompatível com o fato de que Ethereum é uma realização da visão de Vitalik, ordens de magnitude mais do que a de qualquer outra pessoa.

E sinceramente, pode reclamar? Quando você foi atraído para o ecossistema Ethereum por sua abertura, censura resistência e ritmo de inovação – você reclamou que começou com a visão de Vitalik? Talvez você não tenha pensado assim – mas agora que você pensa, você realmente se importa?

E a descentralização?

Mas mas, você diz, e a descentralização? Se uma pessoa tem um poder tão avassalador sobre Ethereum, como podemos afirmar que ela é descentralizada?

Para responder a essa pergunta, devemos voltar a @VitalikButerin/the-meaning-of-de-decentralization-a0c92b76a274">este artigo clássico sobre o significado de descentralização, escrito por, tosse, Vitalik. O principal insight do artigo é que existem três tipos de descentralização:

• Descentralização arquitetônica: quantos nós podem ser comprometidos antes que o sistema deixe de funcionar?
• Descentralização lógica: os subsistemas do sistema podem evoluir de forma independente, mantendo o sistema funcionando? Ou devem ser estreitamente coordenados?
• Descentralização política: quantas pessoas ou organizações acabam por controlar esse sistema?

Dadas essas definições, Ethereum é claramente descentralizado arquitetonicamente, e provavelmente é justo dizer que também é logicamente descentralizado, dada a falta de forte acoplamento entre seus vários componentes (por exemplo, consenso versus execução).

Em termos de descentralização política, a boa notícia é que nenhum indivíduo ou organização pode fechar Ethereum, nem mesmo Vitalik. No entanto, pode-se argumentar que Ethereum não é tão politicamente descentralizada quanto se poderia pensar, dado o papel proeminente que Vitalik desempenha na definição de sua visão e, portanto, na definição de seus roteiros.

No entanto, é minha opinião que, se quisermos que Ethereum continue inovando, devemos abraçar Vitalik como o CTO de fato, mesmo que isso signifique sacrificar alguma descentralização política.

Se Ethereum se "ossificar" em um blockchain quase imutável como Bitcoin, então Vitalik pode se aposentar. Mas antes de chegarmos a esse final, é fundamental que haja uma autoridade que todos os lados respeitem, a quem é confiada para fazer julgamentos sobre decisões técnicas não baseadas apenas em méritos técnicos, mas também em se elas são consistentes com a visão de Ethereum.

Sem uma figura como Vitalik, apenas dois resultados são possíveis, ambos vividamente ilustrados por esta saga 3074:

• Ethereum governo poderia se dissolver em impasses intermináveis onde nenhum dos lados está disposto a ceder e ninguém poderia fazer qualquer progresso, como visto por como o debate 3074 estava em um impasse até a entrada de Vitalik.
• Ou, Ethereum poderia acabar se tornando um monstro Frankenstein de projetos incoerentes, como indicado pelo quão perto estávamos de ter 3074 e 4337 servindo como duas pilhas AA paralelas que são em grande parte incompatíveis.

O papel da comunidade

Estamos muito perto de ter um modelo mental completo de governança Ethereum, mas há uma omissão gritante de nossa discussão até agora – a comunidade.

Se Vitalik define a visão, que são seguidas por roteiros definidos por pesquisadores, que por sua vez são implementados por devs centrais – qual o papel da comunidade? Com certeza não é nada??

Felizmente, a comunidade realmente desempenha o papel mais importante de todos. A razão é que, antes mesmo de haver uma visão, existem valores. Todos nós nos unimos como uma comunidade porque nos unimos em torno de certos valores, que, em última análise, a visão de Vitalik deve ser consistente, ou perderia a comunidade.

Talvez tenha sido a sua criação. Talvez tenha sido algo que aconteceu no seu último trabalho. Mas, em um momento ou outro, todos nós da comunidade Ethereum decidimos que seria bom para o mundo ter um computador descentralizado que seja acessível a todos, que não possa ser censurado, que seja credivelmente neutro. Afirmamos e afirmamos esses valores todos os dias com o trabalho que fazemos em cima de Ethereum e, ao fazê-lo, fornecemos legitimidade à visão, roteiros e código produzidos pela Vitalik, pesquisadores e desenvolvedores principais.

O modelo VVRC de governança Ethereum

Então, aqui, então, está um modelo mental completo para a governança do Ethereum, que estou chamando de valores ⇒ visão ⇒ roteiros ⇒ modelo de clientes, ou VVRC para curto:

• V == Valores == Comunidade
• V == Visão == Vitalik
• R == Roteiros == Pesquisadores
• C == Clientes == Core Devs

Juntos, eles funcionam assim:

• A comunidade se une em torno de certos valores.
• Vitalik articula uma visão coerente com esses valores.
• Os pesquisadores elaboram roteiros de acordo com a visão.
• Os desenvolvedores principais implementam clientes com base nos roteiros.

Mal desenhado pelo novo GPT-4o.
Ele se recusou a desenhar a palavra "Vitalik" devido à "política de conteúdo".

Claro, a realidade é muito mais confusa do que qualquer modelo simples pode capturar. Por exemplo, os core devs na realidade são as únicas pessoas que podem "votar" em qualquer decisão, em virtude da implementação dos clientes. Vitalik e outros pesquisadores servem apenas um papel consultivo, e às vezes sua contribuição não é aceita pelos desenvolvedores do núcleo, e foi por isso que o 3074 foi aprovado.

Dito isso, acho que o modelo VVRC captura razoavelmente como a governança Ethereum funciona no caso feliz, e cabe a nós "depurar" o processo para que ele não falhe como aconteceu com o 3074.

Como podemos melhorar a governança Ethereum

Agora que temos um modelo mental de como a governança Ethereum deve funcionar, aqui estão algumas ideias para melhorar o processo de governança para que possamos evitar o tipo de chicote que experimentamos com o 3074/7702.

• Tem de haver mais visibilidade para os PIE que estão a ser activamente considerados para a inclusão. A comunidade em geral nunca deve ser "pega de surpresa" que um PEI seja aceito, como foi o caso do 3074.
  • Ao contrário do que você poderia esperar, o "status" de um PEI em o site EIPs não reflete seu status no processo de ACD. É por isso que ele ainda diz que o 3074 está em "Revisão", mesmo que os devs principais já tivessem votado para aprová-lo, e havia ainda menos indicação de que ele estava sendo considerado para inclusão em primeiro lugar.
  • O ideal seria que a EF deixasse claro nas redes sociais quando um PEI está prestes a ser aceito, para aumentar a conscientização da comunidade.
• Às vezes, os desenvolvedores principais podem subestimar o impacto que um determinado PEI tem para projetos downstream e usuários, que é o caso do 3074 e da comunidade 4337. Como as reuniões do ACD são limitadas no tempo e devem ser coordenadas entre fusos horários, compreensivelmente há uma ênfase de que apenas "pessoas relevantes" devem falar nas reuniões. Dito isso, poderia fazer sentido alocar algum tempo, de vez em quando, para que os membros da comunidade comentassem o impacto a jusante de certas propostas PEI.
  • Se os pesquisadores sentirem que sua contribuição não está sendo recebida pelos desenvolvedores principais, como foi o caso da equipe do 4337, eles poderiam trazer membros da comunidade para o chamado para fortalecer seu caso.
• Crucialmente, deve haver um reconhecimento mútuo entre os principais desenvolvedores e pesquisadores de que ambos são poderes de governança, embora com pontos fortes diferentes. O "poder do cliente" dos desenvolvedores principais é o único poder que pode realmente "votar" em virtude da implementação de clientes. O "poder do roteiro" dos pesquisadores normalmente goza de mais apoiar público graças aos pesquisadores falando ativamente e escrevendo sobre seus roteiros.
  • Quando os dois poderes estão em desacordo, pode ser tentador para os devs principais simplesmente substituir os pesquisadores, como quando os devs principais anulam as objeções da equipe 4337. No entanto, a sobreposição como tal pode resultar em chicote, uma vez que os poderes são instáveis quando estão em conflito, como visto no drama que se seguiu depois que 3074 foi aprovado.
  • Da mesma forma, quando confrontados com resistência, pode ser tentador para os pesquisadores simplesmente desistir de se envolver com devs principais, o que é uma das razões pelas quais o processo RIP foi criado e por que o AA nativo (7560) agora está sendo empurrado principalmente como um RIP, não um PEI. Embora haja benefícios reais em ajudar os L2s a experimentar atualizações de protocolo que são muito controversas para o L1, não podemos ver os RIPs como um substituto para se envolver com o processo de governança PEI. Os pesquisadores devem continuar se envolvendo com os principais desenvolvedores até que estejam totalmente alinhados com os roteiros.

Conclusão

A saga 3074/7702 lança luz sobre como a governança Ethereum realmente funciona – que, além do poder explícito de governança que é o processo de PEI/ACD conduzido por devs centrais, há também o poder de governança implícito de roteiros conduzidos por pesquisadores. Quando esses poderes se desalinham, vemos impasses e chicotadas, e pode ser necessário outro poder – Vitalik – para inclinar a balança de uma forma ou de outra.

Em seguida, argumentamos que Vitalik representa um poder distinto que é a "visão" de Ethereum, que é a base de legitimidade para quaisquer roteiros. Comparamos Vitalik com o CTO de uma grande empresa e reconhecemos que seu papel como pseudo-CTO é necessário para que Ethereum mantenha seu ritmo de inovação, sem degenerar em um sistema Frankenstein de projetos incoerentes.

Finalmente, apresentamos um modelo mental para pensar a governança Ethereum como VVRC: valores (comunidade) ⇒ visão (Vitalik) ⇒ roteiros (pesquisadores) ⇒ clientes (core devs). Em seguida, sugerimos várias maneiras de corrigir os "bugs" que às vezes fazem com que o processo se desvie desse modelo na prática.

Ethereum governança é "a máquina que constrói a máquina" – para acertar Ethereum, precisamos acertar na governança. Como tal, o 3074 forneceu um estudo de caso inestimável para quando a governação correu mal, e espero ter sido capaz de retirar dele algumas lições úteis para que possamos melhorar a governação Ethereum para o futuro.

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [zerodev]. Todos os direitos autorais pertencem ao autor original [derek]. Se houver objeções a essa reimpressão, entre em contato com a equipe Gate Learn e eles lidarão com isso prontamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.