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

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

• Há algumas semanas, o EIP-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 forquilha duro do Ethereum.
• Desde então, muitos na comunidade ERC-4337, especialmente os próprios 4337 autores, têm sido fortemente empurrando para trás em 3074, com base em @yoav/3074-implications">preocupações de centralização e sua incompatibilidade com Ethereum@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 EIP-7702 como alternativa ao 3074. Ele atinge principalmente o mesmo objetivo - trazendo muitos benefícios de AA para os usuários EOA - mas de uma forma que é mais compatível com o 4337 hoje, e compatível com o "final AA" que é 7560.
• Neste momento, os principais devs estão deliberando sobre o EIP-7702, mas discussões preliminares e sentimentos da comunidade sugerem que o EIP-7702 provavelmente substituirá o EIP-3074 em Pectra.

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

E, no entanto, não posso deixar de sentir que a forma como alcançámos este resultado esteve longe de ser ótima, uma opinião que muitos tinham manifestado 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.

Nesta postagem do blog, eu quero:

• Identifique o que deu errado com o 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 esta saga deixou muita gente infeliz por várias razões:

• Demorou anos para 3074 ser aprovado.
• Somente depois que o 3074 foi finalmente aprovado, os devs principais receberam uma enorme tonelada de pushbacks da comunidade 4337.
  • Os próprios 4337 autores, por outro lado, expressaram repetidamente suas preocupações com 3074 para devs centrais, sem sucesso.
• Agora estamos no caminho certo para desaprovar o 3074 e substituí-lo por outro EIP (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 EIP receber pushbacks depois de aprovado.
• Não há problema em cancelar a aprovação de um EIP após sua aprovação, se novos problemas forem identificados.

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

• A comunidade 4337 engajou ativamente os devs principais enquanto eles debatiam 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 com o 3074 e não estaríamos revertendo o 3074.
  • Ou, 3074 nunca foi aprovado, mas a comunidade 4337 e devs core trabalharam juntos para uma proposta com a qual todos estão satisfeitos, à 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 correu mal?

Refletindo sobre o processo, ambos os lados do debate apontaram o dedo um ao outro.

Os principais devs (e autores do EIP-3074) sentiram que era culpa das "4337 pessoas" não se envolverem ativamente com o processo as reuniões são abertas a todos, e há pessoas como Tim Beiko que tuitam ativamente resumos após cada reunião da ACD. Então, se as 4337 pessoas se preocupavam tanto com essa questão, por que não gastaram o tempo para se envolver?

Por outro lado, a equipe AA (4337 autores) apontou que eles estavam participando de reuniões do ACD e adiaram 3074 todas as chances que podiam, 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 sequer estavam cientes de que 3074 estava sendo ativamente considerado para inclusão.

Muitas pessoas também sentiram que o processo ACD era muito opaco e não amigável para participações 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 sentiram que deveria ser responsabilidade da ACD buscar ativamente feedback de 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 em ação e, até que resolvamos ou, pelo menos, reconheçamos o problema, continuaremos a deparar-nos com falhas de governação seguidas de apontamentos de dedos improdutivos.

A causa raiz

A verdadeira causa da falha de governança foi que, ao contrário das crenças populares, 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 governação raramente é reconhecido, apesar de ter uma influência ainda maior do que a ACD nas questões mais importantes da Ethereum, como AA e escala.

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

Toda esta saga 3074/7702, como irei argumentar, é nem mais nem menos do que um exemplo do poder dos roteiros que sobrecarregam o poder da ACD. E se estamos a falar de governação, sempre que notamos um poder invisível a sobrepor-se a um poder visível, devemos estar muito preocupados, pois o que é invisível não é responsável e, portanto, deve ser trazido à luz.

O que é um roteiro?

Qualquer pessoa na comunidade Ethereum deve ter se deparado muito com o termo "roteiro", como no "roteiro centrado no rollup", "roteiro ETH 2.0" 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 devs estão discutindo como dimensionar Ethereum:

• Core Dev Bob: Eu suporte EIP 1234 que propõe que nós acelerar tempo de bloco 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 L1 fazem-no, com grandes efeitos de escala.

A razão, é claro, é que essa EIP imaginária é contra o próprio roteiro de escalonamento "rollup-centric" da 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, a EIP imaginária está fora de questão, uma vez que aumentaria enormemente a barreira para executar um nó.

O que eu queria ilustrar com este exemplo é que os devs principais, que participam do processo ACD e decidem sobre protocolo atualizações, são guiados por uma força superior 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 principais devs baseiam suas decisões.

Quando os principais devs 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 principais desenvolvedores estejam alinhados com eles. Em particular, uma vez que não existe 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 desenvolvedores principais e a comunidade maior, 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 devs centrais contra o roteiro AA centrado no 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 4337 de que ele fragmentaria o ecossistema AA criando uma pilha de tecnologia AA alternativa e @yoav/3074-implications">less descentralizada pilha de tecnologia AA.

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 entrou

O papel de Vitalik

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

Para responder a esta pergunta, devemos voltar a @VitalikButerin/the-meaning-of-de-descentralization-a0c92b76a274">este artigo clássico sobre o significado de descentralização, escrito por, tosse 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 controlam, em última análise, este sistema?

Dadas essas definições, Ethereum é claramente descentralizada arquitetonicamente, e é provavelmente justo dizer que também é logicamente descentralizada, dada a falta de forte acoplamento entre seus vários componentes (por exemplo, consenso vs 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, assim, na definição de seus roteiros.

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

Se Ethereum "ossificar" em um blockchain praticamente imutável como Bitcoin, então Vitalik poderia se aposentar. Mas antes de chegarmos a esse fim, é fundamental que haja uma autoridade que todos os lados respeitem, a quem se confie 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 governação poderia dissolver-se em impasses intermináveis em que nenhum dos lados está disposto a ceder e ninguém pode fazer qualquer progresso, como se vê pela forma como o debate 3074 estava num impasse até à entrada de Vitalik.
• Ou, Ethereum poderia acabar se tornando um monstro Frankenstein de designs 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 em nossa discussão até agora – a comunidade.

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

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

Talvez tenha sido a sua educação. Talvez tenha sido algo que aconteceu no seu último emprego. Mas, em um momento ou outro, todos nós na 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 O modelo VVRC de governança Ethereum

Então, aqui 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:

• Tem de haver mais visibilidade para as PEI que estão a ser ativamente consideradas para efeitos de inclusão. A comunidade em geral nunca deve ser "apanhada de surpresa" por um EIP ser aceite, como foi o caso do 3074.
  • Ao contrário do que seria de esperar, o "estado" de um EIP em o site EIPs não reflete o seu estado no processo ACD. É por isso que ele ainda diz que o 3074 está em "Revisão", embora 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.
  • Idealmente, a EF deixaria alto e bom som nas redes sociais quando um EIP está prestes a ser aceito, para aumentar a conscientização da comunidade.
• Às vezes, os principais devs podem subestimar o impacto que um determinado EIP tem para projetos a jusante 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 isto, poderia fazer sentido reservar algum tempo, de vez em quando, para os membros da comunidade comentarem o impacto a jusante de certas propostas EIP.
  • Se os pesquisadores sentirem que suas contribuições não estão sendo recebidas pelos desenvolvedores principais, como foi o caso da equipe do 4337, eles podem trazer membros da comunidade para a chamada 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 principais devs é o único poder que pode realmente "votar" em virtude da implementação de clientes. O "poder do roteiro" dos investigadores goza normalmente de mais suporte públicas graças ao facto de os investigadores falarem e escreverem ativamente sobre os 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 superaram as objeções da equipe 4337. No entanto, a sobreposição como tal pode resultar em chicotadas, uma vez que os poderes são instáveis quando estão em conflito, como visto no drama que se seguiu após a aprovação do 3074.
  • Da mesma forma, quando confrontados com resistência, pode ser tentador para os pesquisadores simplesmente desistirem de se envolver com os principais devs, o que é uma razão pela qual o processo RIP foi criado e por que AA nativo (7560) agora está sendo empurrado principalmente como um RIP, não como um EIP. 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 EIP. Os pesquisadores devem continuar se envolvendo com os principais desenvolvedores até que eles 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 de governança explícito que é o processo EIP/ACD impulsionado pelos principais devs, há também o poder de governança implícito dos roteiros impulsionados pelos pesquisadores. Quando esses poderes se desalinham, vemos impasses e chicotadas, e pode ser necessário outro poder – Vitalik – para fazer pender 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 o seu papel de pseudo-CTO é necessário para que Ethereum mantenha o seu ritmo de inovação, sem degenerar num sistema Frankenstein de designs incoerentes.

Finalmente, apresentamos um modelo mental para pensar a governança Ethereum como VVRC: valores (comunidade) ⇒ visão (Vitalik) ⇒ roadmaps (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 é "

Declaração de exoneração de responsabilidade:

1. Este artigo foi reproduzido a partir 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 imediatamente.
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.