Encaminhe o título original 'Reflexões sobre a governança Ethereum após a saga 3074'

Resumo: O artigo é uma declaração de Derek Chiang, CEO da ZeroDev, em resposta à proposta de V de EIP-7702 para equilibrar as contradições entre ERC-4337 e EIP-3074. Escrito a partir da perspectiva de um fundador de projeto dentro do ecossistema AA, ele destaca objetivamente o modelo de governança atual do Ethereum e seus pontos problemáticos. Derek aponta sucintamente:

Um dos conflitos de governança do Ethereum está nas discrepâncias entre o roteiro determinado pelos pesquisadores e as perspectivas de equipes de desenvolvimento de clientes como a Geth. Vitalik, atuando em um papel semelhante a um CTO, acaba se tornando o fator decisivo.

Depois de afirmar o papel de Vitalik, Derek descreve as melhorias que o Ethereum deve fazer em seu modelo de governança, oferecendo insights valiosos para as comunidades Ethereum e Bitcoin.

Texto:

Se você não estava familiarizado com os eventos em torno da Abstração de Conta (AA) do Ethereum anteriormente, aqui está uma breve recapitulação: Várias semanas atrás, a proposta EIP-3074 foi aprovada pelos desenvolvedores principais do Ethereum para ser incluída no próximo hard fork, "Pectra". Esta proposta introduz dois novos opcodes para a Ethereum Virtual Machine (EVM), permitindo que as Contas de Propriedade Externa Ethereum (EOAs) tenham uma experiência AA quase nativa. Desde então, muitos membros da comunidade ERC-4337, particularmente seus proponentes, se opuseram fortemente ao EIP-3074, citando preocupações sobre potenciais riscos de segurança e sua incompatibilidade com o roteiro AA do Ethereum. No roteiro anterior do Ethereum, o ERC-4337 e propostas semelhantes como o 7560 (também conhecido como "nativeAA") eram centrais. No início de maio, Vitalik propôs o EIP-7702 como uma alternativa ao EIP-3074, alcançando um equilíbrio entre 4337 e 3074 — fornecendo uma experiência AA para usuários EOA, mantendo a compatibilidade com o ERC-4337 até certo ponto, bem como a compatibilidade com a "solução AA final" 7560. Atualmente, os principais desenvolvedores do Ethereum estão considerando as implicações do EIP-7702, e discussões preliminares e o sentimento da comunidade indicam que o EIP-7702 provavelmente substituirá o EIP-3074 mencionado anteriormente. Estou muito satisfeito com este resultado: os usuários do EOA em breve poderão experimentar vários produtos dentro do ecossistema ERC-4337 e desfrutar da maioria dos benefícios do AA. No entanto, não posso deixar de sentir que poderia ter havido uma maneira melhor de alcançar esses resultados, como muitos apontaram nas últimas semanas. Acredito que, com um melhor processo de governança, poderíamos ter economizado muita energia e alcançado o resultado desejado mais rapidamente. Neste artigo, eu gostaria:

• Identificar o que deu errado no processo de governança
• Propor um modelo de pensamento para a governança Ethereum
• Oferecer sugestões de melhorias para evitar acidentes de governança semelhantes no futuro

Conclusão e Reflexão sobre o Incidente EIP-3074

A história mencionada acima deixou muitas pessoas descontentes por vários motivos: a EIP-3074 levou vários anos para ser aprovada. Depois que o 3074 foi finalmente aprovado, os principais desenvolvedores do Ethereum enfrentaram forte oposição da comunidade 4337. Por outro lado, os autores do ERC-4337 expressaram repetidamente suas preocupações sobre o EIP-3074 para a equipe principal do Ethereum, mas sem sucesso. Agora, o Ethereum está planejando cancelar a aprovação do 3074 e substituí-lo por outro EIP (7702). Não há nada inerentemente errado com qualquer ponto do processo mencionado acima:

• É normal que as discussões sobre uma PEI demorem vários anos.
• É normal que uma EIP aprovada seja rejeitada depois.
• Se novos problemas forem descobertos, a aprovação de um EIP pode ser revogada após a aprovação.

No entanto, as coisas poderiam ter sido mais tranquilas. Vamos imaginar se as coisas tivessem se desenvolvido assim: durante a discussão do 3074, a comunidade do 4337 se envolveu ativamente com os desenvolvedores principais do Ethereum. Se essa premissa for verdadeira, então há apenas dois resultados possíveis:

• Depois de considerar o feedback da comunidade 4337, a proposta 3074 é aprovada (e possivelmente modificada). Neste caso, a comunidade 4337 aceitaria 3074, e a equipe principal do Ethereum não precisaria revogar 3074.
• Alternativamente, o 3074 nunca é aprovado, mas a comunidade 4337 e a equipe principal do Ethereum propõem conjuntamente uma solução que satisfaz a todos, semelhante ao 7702. As vozes de todos são ouvidas, e não há reversão dramática. Isso teria sido o ideal, então por que não aconteceu?

O que deu errado?

Olhando para todo o processo, os dois lados do evento estão se culpando. Os desenvolvedores do núcleo Ethereum (bem como os autores do EIP-3074) acreditam que a culpa é dos "apoiadores do 4337" porque eles não participaram ativamente do processo de discussão All Core Developers (ACD). Nesse processo, os EIPs precisam passar por longas deliberações e, finalmente, serem aceitos e implementados por equipes de desenvolvimento de clientes Ethereum como a Geth. Alguns argumentam que, durante o período em que a EIP-3074 esteve em análise, "4337 apoiantes" poderiam ter participado e expressado as suas opiniões, em vez de a criticarem depois de já ter sido aprovada. Afinal, todo o processo de ACD é transparente, as reuniões são abertas a todos e indivíduos como Tim Beiko publicam consistentemente tweets resumidos após cada reunião do ACD. Então, se "4337 apoiadores" se preocuparam tanto com o tema, por que não participaram ativa e prontamente das reuniões relevantes?

Por outro lado, os membros principais do 4337 indicam que têm participado das reuniões do ACD e se oposto ao 3074 tanto quanto possível, mas os desenvolvedores do núcleo Ethereum não ouvem. Quanto aos 4337 membros da comunidade, muitos se sentiram cegos – muitos pensaram que o 3074 já estava morto, e alguns nem sabiam que o 3074 provavelmente seria aprovado. Muitos apontam que todo o processo de reuniões do ACD é opaco e não amigável para aqueles que são "sérios" na comunidade Ethereum, mas não conseguem acompanhar as atualizações do ACD em tempo real. Alguns também acreditam que a ACD deve buscar ativamente feedback das partes interessadas (aqui referindo-se à comunidade 4337).

No entanto, acredito que nenhum dos lados acertou em cheio. Há questões mais profundas por trás disso e, a menos que abordemos ou pelo menos reconheçamos esse problema, continuaremos a cair em acidentes de governança, seguidos de acusações contraditórias de ambos os lados, que em última análise não fazem sentido.

A causa raiz dos acidentes de governança: o roteiro

Ao contrário da crença popular, a causa raiz dos acidentes de governança está no fato de que a ACD não é a única autoridade de governança para atualizações do protocolo Ethereum; foi substituído por outra autoridade de governação. O problema aqui é que, apesar de ter mais influência do que o ACD em questões centrais do Ethereum (como AA e escalabilidade), essa outra autoridade de governança raramente é reconhecida. Neste artigo, vou me referir a esse tipo de poder como o "roteiro". Como apontarei abaixo, todo o evento de falha de governança "3074-4337-7702" é um caso de poder de roteiro existente do Ethereum substituindo o poder ACD. Se falamos de governança, quando notamos que uma força intangível está sobrecarregando uma força tangível, devemos estar extremamente preocupados, porque as coisas intangíveis são muitas vezes difíceis de explicar e não podem ser facilmente percebidas por muitas pessoas, então devem ser expostas.

O que é um roteiro?

Qualquer pessoa na comunidade Ethereum deve ter ouvido frequentemente o termo "roadmap", seja no "roadmap ETH2.0" ou no contexto do "AA roadmap" relacionado a este evento.

Para ilustrar meu ponto, vamos imaginar uma cena em uma reunião da ACD onde os desenvolvedores principais estão discutindo como escalar o Ethereum:

• Core Developer Bob: Eu apoio o EIP-1234, que propõe aumentar a velocidade do bloco em 10 vezes, aumentar o tamanho do bloco em 10 vezes e reduzir as taxas em 100 vezes.
• Outros desenvolvedores principais: ... Você está fora de si?

Vamos pensar sobre isso. Por que a equipe principal do Ethereum rejeitaria o que Bob está propondo? Ele está apenas sugerindo uma maneira aparentemente razoável de escalar, algo que muitas cadeias públicas como Solana, Aptos, Sui e outras fizeram, alcançando TPS alto. A razão é que este EIP-1234 fictício contradiz o roteiro de escalabilidade "centrado em rollup" do Ethereum. Este roteiro enfatiza que, para a descentralização, os usuários comuns devem ser capazes de executar nós a baixo custo. Portanto, é improvável que o EIP-1234 fictício seja aceito porque aumentaria significativamente o custo de executar nós Ethereum. Quero usar este exemplo para ilustrar que os desenvolvedores principais que participam do processo de governança do ACD e decidem sobre atualizações de protocolo são guiados por uma força de nível superior, que chamo de "roteiro". Atualmente, em torno do roteiro do Ethereum, existem "roteiros de escala", "roteiros AA", "roteiros MEV" e assim por diante. Eles formam coletivamente o roteiro geral do Ethereum, e os desenvolvedores principais devem tomar decisões com base nessa base.

Quando as visões dos desenvolvedores principais não se alinham com o roteiro

Como o roteiro não é uma parte formal do processo de governança do Ethereum, muitas vezes não há garantia de que a equipe principal irá aderir a ele. Além disso, não há um processo formal para "aprovar" o roteiro, portanto, nem todos os roteiros têm o mesmo nível de "ortodoxia". Os pesquisadores por trás do roteiro Ethereum devem trabalhar duro para promover seu roteiro para desenvolvedores principais e a comunidade para obter "ortodoxia" e apoio da equipe de desenvolvimento principal do Ethereum. Em relação ao AA e à abstração de contas, o próprio Vitalik tem defendido repetidamente o roteiro AA centrado em 4337, mas no geral, é principalmente a equipe por trás do 4337, especialmente Yoav e Dror, que defendem o roteiro de AA centrado em 4337 em fóruns e em reuniões de ACD.

No entanto, apesar desses esforços, alguns desenvolvedores do núcleo Ethereum ainda se opõem fortemente ao roteiro AA centrado em 4337. Eles acreditam que o 7560 (a versão nativa 4337 a ser implementada por clientes Ethereum no futuro) é muito complexo e não é a única solução viável para o "final AA". Por fim, a ACD decidiu aprovar a proposta 3074, apesar da oposição da equipe 4337, que acreditava que a 3074 fraturaria todo o ecossistema AA. Depois que o 3074 foi aprovado, toda a comunidade do 4337 reagiu fortemente, forçando os desenvolvedores do núcleo Ethereum a se envolverem novamente em discussões sobre o 3074. A discussão então chegou a um impasse, com os autores de 4337 e 3074 incapazes de persuadir uns aos outros. Vitalik propôs o EIP-7702 como uma alternativa ao 3074 no último minuto, que acomoda explicitamente o "final AA" centrado no 4337, resolvendo assim o conflito e alinhando o resultado final com o roteiro AA.

Papel da Vitalik: CTO de fato da Ethereum

Apesar de Vitalik se identificar como pesquisador, a história acima indica claramente que Vitalik detém poderes de governança distintos de outros pesquisadores. Então, surge a pergunta: Qual o papel do Vitalik na governança do Ethereum? Pessoalmente, acredito que pode não ser inapropriado considerar Vitalik como o CTO de fato de uma empresa muito grande (aliás, assumindo Ethereum como uma "empresa" sem um CEO para se alinhar com a realidade). Se você já trabalhou em uma empresa de tecnologia com mais de 50 funcionários, sabe que o CTO não pode estar envolvido em todas as decisões técnicas. À medida que a empresa cresce, os processos de tomada de decisão para várias soluções técnicas inevitavelmente se tornam descentralizados – normalmente, cada área do produto/negócio da empresa tem uma equipe dedicada, que muitas vezes tem autonomia para decidir sobre os detalhes da solução. Além disso, o CTO pode não ser o principal especialista em todos (ou quaisquer) tópicos. Pode haver engenheiros dentro da empresa que são melhores em áreas específicas do que o CTO, portanto, em discussões sobre detalhes técnicos das soluções, muitas vezes são engenheiros individuais que tomam as decisões finais. No entanto, o CTO define a visão técnica da empresa. A execução da visão é deixada para os desenvolvedores. Embora esta não seja uma analogia perfeita, acredito que encapsula razoavelmente o papel da Vitalik no ecossistema Ethereum. Vitalik não participa de todas as decisões técnicas – ele possivelmente não poderia. Ele também não é o maior especialista em todos os domínios. Mas ele tem uma influência esmagadora na definição do roteiro para todas as soluções Ethereum cruciais (escala, AA, POS...), não apenas por causa de sua experiência técnica, mas também porque ele é o juiz final de se o roteiro se alinha com a visão Ethereum (sua visão).

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

Se considerar Vitalik como CTO da Ethereum não é controverso o suficiente, aqui está a parte mais controversa: devemos abraçar Vitalik como CTO. Como fundador de uma startup, acredito que todo produto de sucesso deve ter uma visão coerente de longo prazo – sim, o Ethereum também é um "produto" porque resolve problemas reais para usuários reais. Uma visão coerente deve ser trabalhada por algumas pessoas, como os fundadores de uma startup, e geralmente, há apenas um fundador. A beleza do Ethereum é que, apesar de ser um sistema extremamente complexo com tantos componentes, todos esses componentes se unem perfeitamente para formar um computador descentralizado que funciona bem, liquidando bilhões de dólares em transações todos os dias. Chegamos até aqui não através de alguns esquemas de design do comitê, mas porque Vitalik, com sua visão e discernimento, forneceu liderança ativamente, permitindo-nos construir o Ethereum coerente e gracioso de hoje. Ethereum é a ideia que Vitalik propôs em 2015, e continua sendo. Claro, isso não é para diminuir as contribuições de outros pesquisadores e engenheiros – eles fizeram a maior parte das conquistas do Ethereum hoje. No entanto, isso não é contraditório, porque Ethereum é a realização da visão de Vitalik, magnitudes maiores do que a visão de qualquer outra pessoa. Honestamente, você pode reclamar disso? Quando você é atraído pela abertura, resistência à censura e velocidade de inovação do ecossistema Ethereum, você já reclamou que isso surgiu da visão da Vitalik? Talvez você não tenha reclamado porque não pensou dessa forma – mas agora que você está, você se importa com essa questão?

Como lidar com a descentralização?

Mas você pode perguntar, e a descentralização? Se uma pessoa detém um poder tão avassalador sobre o Ethereum, como podemos dizer que ele é descentralizado? Para responder a essa pergunta, devemos revisitar o clássico artigo de Vitalik sobre o significado de descentralização. Os principais insights do artigo são que a descentralização vem em três tipos:

• Descentralização arquitetônica: quantos nós podem falhar antes que o sistema pare de funcionar?
• Descentralização lógica: Os vários subsistemas do sistema podem desenvolver-se de forma independente, sem deixar de trabalhar em conjunto de forma coesa?
• Descentralização política: afinal, quantos indivíduos ou organizações controlam o sistema?

De acordo com essas definições, o Ethereum é claramente descentralizado arquitetonicamente, e pode-se argumentar que ele é logicamente descentralizado porque seus componentes carecem de forte acoplamento (por exemplo, entre a camada de consenso e a camada de execução). Quanto à descentralização política, a boa notícia é que nenhum indivíduo ou organização pode fechar o Ethereum, nem mesmo a Vitalik. No entanto, alguns podem argumentar que o nível de descentralização política do Ethereum não é tão alto quanto se imaginava, porque Vitalik desempenha um papel significativo na formação da visão e do roteiro do Ethereum.

No entanto, acredito que se quisermos que o Ethereum continue inovando, devemos aceitar Vitalik como o CTO de fato, mesmo que isso signifique sacrificar alguma descentralização política. Se o Ethereum se tornasse tão "estagnado" quanto o Bitcoin, um blockchain quase imutável, então Vitalik poderia muito bem se aposentar. Mas antes de chegarmos a esse passo final, é crucial ter uma autoridade respeitada por todas as partes, alguém confiável para tomar decisões técnicas com base não apenas na superioridade das soluções técnicas propostas, mas também em se essas decisões estão alinhadas com a visão do Ethereum.

Sem alguém como Vitalik, apenas dois resultados são prováveis, vividamente ilustrados pela história em torno da EIP-3074:

O processo de governança do Ethereum pode cair em um impasse sem fim, com partes conflitantes não dispostas a se comprometer e ninguém fazendo progressos, como demonstrado pelo impasse no debate 3074 antes da intervenção de Vitalik.

Ou o Ethereum poderia se tornar um "Frankenstein" incoerente com o design, com 3074 e 4337 possivelmente não cedendo um ao outro, resultando na ruptura completa do ecossistema AA em dois espaços paralelos incompatíveis.

O papel da comunidade

Após as considerações acima, estamos quase esboçando uma mentalidade completa de governança do Ethereum, mas há uma omissão óbvia em nossa discussão até agora: a comunidade. Se Vitalik define a visão do Ethereum, os pesquisadores definem o roteiro e os desenvolvedores principais implementam o roteiro, então qual papel a comunidade desempenha? Certamente, não é só ficar parado, certo? Felizmente, a comunidade desempenha o papel mais crucial. A razão é que, antes de haver uma visão, há valores. Nós nos unimos como uma comunidade porque nos unimos em torno de certos valores, e a visão da Vitalik deve, em última análise, se alinhar com esses valores para manter o apoio da comunidade. Todos na comunidade Ethereum acreditam que ter um computador descentralizado acessível a todos, sem censura e neutro em termos de confiança é benéfico para o mundo. Defendemos e afirmamos esses valores todos os dias por meio do trabalho que fazemos no Ethereum, legitimando assim a visão, o roteiro e o código estabelecidos pela Vitalik, pesquisadores e desenvolvedores principais.

O Modelo VVRC de Governança Ethereum

Portanto, aqui está a mentalidade completa da governança Ethereum, abreviada como VVRC:

• V==Valores==Comunidade;
• V==Visão==Vitalik;
• R==Roteiro==Pesquisadores;
• C==Cliente==Desenvolvedor principal;

Juntos, eles desempenham os seguintes papéis:

• A comunidade se une em torno de valores específicos.
• Vitalik articula uma visão coerente com esses valores.
• Os pesquisadores formulam um roteiro com base na visão.
• Os desenvolvedores principais implementam clientes com base no roteiro.

É claro que a realidade é muito mais complexa do que qualquer modelo simples pode capturar. Os desenvolvedores principais do Ethereum são os únicos que podem realmente "votar" em qualquer proposta, alterando o código do cliente. Vitalik e outros pesquisadores servem como conselheiros, e às vezes suas opiniões não são aceitas pelos desenvolvedores principais, e é precisamente por isso que o EIP-3074 foi aprovado. No entanto, acredito que o modelo VVRC captura razoavelmente o modo operacional da governança Ethereum em circunstâncias normais, e precisamos "depurar" esse processo para evitar que acidentes como o EIP-3074 aconteçam novamente.

Como melhorar o modelo de governança do Ethereum

Agora que temos um modelo mental de como o processo de governança Ethereum opera, aqui estão algumas ideias para melhorar os processos de governança:

A visibilidade dos progressos do debate para os PEI em análise deve ser aumentada. Toda a comunidade não deve ficar "surpresa" com a aceitação de uma EIP, e aprovações inesperadas como a EIP-3074 não devem se repetir. O actual "estado" dos PEI no sítio Web do PEI não reflecte o seu estatuto no processo de ACD. É por isso que ainda diz que o EIP-3074 está "em revisão", apesar de os desenvolvedores principais terem votado para aprová-lo, sem indicação de que ele tenha sido considerado para aprovação desde o início. Idealmente, quando uma EIP está prestes a ser aceita, a Fundação Ethereum deve fazer um anúncio público definitivo nas mídias sociais para aumentar a conscientização dentro da comunidade.

Por vezes, os promotores principais podem subestimar o impacto de EIPs específicos em projetos e usuários a jusante, como foi o caso das comunidades 3074 e 4337. Devido ao tempo limitado das reuniões da ACD e à necessidade de coordenação entre fusos horários, apenas "pessoal relevante" pode frequentemente falar nas reuniões. No entanto, faria sentido atribuir ocasionalmente algum tempo de uso da palavra aos membros da comunidade para comentarem o impacto de certas propostas de PEI em projectos a jusante após a sua aprovação. Se os pesquisadores sentirem que suas opiniões não foram aceitas pelos desenvolvedores principais, como foi o caso do 4337, eles podem convidar membros da comunidade para reforçar seus argumentos.

É crucial que os principais desenvolvedores e pesquisadores reconheçam mutuamente que, apesar das diferenças de poder, ambos fazem parte da autoridade de governança do Ethereum. Os desenvolvedores principais têm o poder de alterar e atualizar os clientes Ethereum, que é a única maneira de fazer alterações no próprio protocolo e "votar". Os pesquisadores geralmente têm mais apoio público para mudanças e interpretações do roteiro, graças à sua discussão ativa e escrita de suas ideias.

Quando essas duas forças se chocam, os desenvolvedores principais podem tender a derrubar diretamente as opiniões dos pesquisadores, como foi o caso da equipe do 4337. No entanto, tal derrubada pode levar a conflitos, pois a instabilidade surge quando as duas forças se chocam, como evidenciado pelos eventos dramáticos após a aprovação da EIP-3074.

Da mesma forma, quando confrontados com resistências, os pesquisadores podem tender a desistir da colaboração com desenvolvedores principais. Na minha opinião, esta é também uma das razões para a criação do processo RIP e por que o AA nativo (7560) é agora promovido principalmente como RIP em vez de EIP.

Embora a experimentação de atualizações de protocolo em L2 que são controversas para L1 tenha seus benefícios, não podemos ver o RIP como um substituto para participar do processo de governança do EIP. Os pesquisadores devem continuar a colaborar com os desenvolvedores principais até que os valores de ambos os lados estejam totalmente alinhados com o roteiro.

Conclusão

O incidente 3074/7702 revelou o verdadeiro funcionamento da governança Ethereum – além do poder de governança explícito impulsionado pelos processos EIP/ACD dos desenvolvedores principais, também há poder de governança implícito impulsionado pelo roteiro impulsionado pelos pesquisadores. Quando esses poderes estão desalinhados, vemos impasses e provocações, e outra força – Vitalik – pode precisar intervir de alguma forma para perturbar o equilíbrio.

Em seguida, propomos que o Vitalik representa uma força única, ou seja, a "visão" do Ethereum, que forma a base da legitimidade de qualquer roteiro. Comparamos Vitalik a um CTO de uma grande empresa e reconhecemos que seu papel como pseudo-CTO é necessário para que o Ethereum mantenha seu ritmo de inovação, evitando que o Ethereum se transforme em um "Frankenstein" – como um monstro remendado.

Por fim, apresentamos o modelo VVRC, descrevendo o modelo de governança Ethereum: Valores (Comunidade) ⇒ Visão (Vitalik) ⇒ Roadmap (Pesquisadores) ⇒ Cliente (desenvolvedores principais). Em seguida, propomos vários métodos para "depurar" as "falhas" desse modelo.

A governança Ethereum é uma "máquina de fazer máquinas" – para fazer o Ethereum funcionar corretamente, devemos governá-lo corretamente.

Disclaimer:

1. Este artigo foi reproduzido de [极客 Web3]. Encaminhe o título original 'Reflexões sobre a governança Ethereum após a saga 3074'. Todos os direitos autorais pertencem ao autor original [Derek Chiang, CEO da ZeroDev]. Se houver objeções a essa reimpressão, entre em contato com a equipe do 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.