Explorando o impacto do Vitalik & Vários roteiros na governança do Ethereum

IntermediárioJun 03, 2024
"A atualização narrativa é um conceito emergente que não se limita mais a transformações de projetos singulares, mas engloba um escopo mais amplo. Na sua essência, este conceito envolve a modernização e reforma abrangentes dos projetos para os revitalizar e recuperar a competitividade. Especificamente, a trilha de atualização narrativa pode ser alcançada através da mudança da abordagem narrativa do projeto, ajustando sua lógica fundamental, atualizando modelos de negócios, lançando produtos inovadores, ajustando mecanismos de token, fundindo-se com outros projetos ou até mesmo rebranding."
Explorando o impacto do Vitalik & Vários roteiros na governança do Ethereum

Encaminhe o título original 'Reflexões sobre a governança do 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 perspetiva de um fundador de projeto dentro do ecossistema AA, ele destaca objetivamente o atual modelo de governança do Ethereum e seus pontos problemáticos. Derek aponta sucintamente:

Um dos conflitos de governança do Ethereum reside nas discrepâncias entre o roteiro determinado pelos pesquisadores e as perspetivas de equipes de desenvolvimento de clientes como 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 principais desenvolvedores do Ethereum para ser incluída no próximo hard fork, "Pectra". Esta proposta introduz dois novos opcodes para a Máquina Virtual Ethereum (EVM), permitindo que as Contas de Propriedade Externa (EOAs) do Ethereum 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, estabelecendo um equilíbrio entre o 4337 e o 3074 — fornecendo uma experiência AA para os usuários do EOA, mantendo a compatibilidade com o ERC-4337 até certo ponto, bem como a compatibilidade com a "solução final AA" 7560. Atualmente, os principais desenvolvedores do Ethereum estão considerando as implicações do EIP-7702, e discussões preliminares e sentimento da comunidade indicam que o EIP-7702 provavelmente substituirá o EIP-3074 mencionado anteriormente. Estou muito satisfeito com este resultado: os utilizadores EOA poderão em breve 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 governação, poderíamos ter poupado muita energia e alcançado o resultado desejado mais rapidamente. Neste artigo, eu gostaria:

  • Identificar o que correu mal no processo de governação
  • Proponha um modelo de pensamento para a governança do Ethereum
  • Oferecer sugestões de melhoria para evitar acidentes de governação semelhantes no futuro

Conclusão e reflexão sobre o incidente EIP-3074

A história mencionada acima deixou muitas pessoas insatisfeitas por vários motivos: o EIP-3074 levou vários anos para ser aprovado. 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 PEI aprovada seja rejeitada posteriormente.
  • Se forem detetados novos problemas, a aprovação de uma PEI 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 4337 se envolveu ativamente com os principais desenvolvedores do Ethereum. Se esta 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 em conjunto uma solução que satisfaça 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 correu mal?

Olhando para trás em todo o processo, ambos os lados do evento estão se culpando mutuamente. Os desenvolvedores principais do Ethereum (bem como os autores do EIP-3074) acreditam que a culpa é dos "4337 apoiadores" porque eles não participaram ativamente do processo de discussão All Core Developers (ACD). Neste processo, os EIPs precisam passar por longas deliberações e, finalmente, ser aceitos e implementados por equipes de desenvolvimento de clientes Ethereum como Geth. Alguns argumentam que, durante o período em que a EIP-3074 estava 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 da 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 da ACD. Então, se "4337 apoiantes" se preocupavam tanto com o tema, por que não participaram ativa e prontamente nas reuniões relevantes?

Por outro lado, os membros do núcleo do 4337 indicam que eles têm participado de reuniões do ACD e se oposto ao 3074 tanto quanto possível, mas os desenvolvedores do núcleo do 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 detrás disto e, a menos que abordemos ou, pelo menos, reconheçamos este problema, continuaremos a cair em acidentes de governação, seguidos de acusações contraditórias de ambos os lados, que, em última análise, não têm sentido.

A causa principal dos acidentes de governação: o roteiro

Ao contrário da crença popular, a causa raiz dos acidentes de governança reside no fato de que a ACD não é a única autoridade de governança para atualizações do protocolo Ethereum; foi substituída 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, referir-me-ei a este tipo de poder como o "roteiro". Como apontarei abaixo, todo o evento de falha de governança "3074-4337-7702" é um caso do poder do roteiro existente do Ethereum sobrepondo-se ao poder do ACD. Se falamos de governação, quando notamos que uma força intangível está a sobrecarregar 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 notadas por muitas pessoas, pelo que têm de ser expostas.

O que é um roteiro?

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

Para ilustrar meu ponto, vamos imaginar uma cena em uma reunião do ACD onde os principais desenvolvedores 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: ... Perdeste o juízo?

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 escalonamento "rollup-centric" 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 execução dos nós Ethereum. Quero usar este exemplo para ilustrar que os principais desenvolvedores 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 principais desenvolvedores devem tomar decisões com base nessa base.

Quando as visões dos principais desenvolvedores não estão alinhadas 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, então nem todos os roteiros têm o mesmo nível de "ortodoxia". Os pesquisadores por trás do roteiro do Ethereum devem trabalhar duro para promover seu roteiro para os principais desenvolvedores e a comunidade para ganhar "ortodoxia" e apoio da equipe de desenvolvimento do núcleo do Ethereum. Em relação ao AA e à abstração de contas, o próprio Vitalik tem defendido repetidamente o roteiro do AA centrado no 4337, mas, no geral, é principalmente a equipe por trás do 4337, especialmente Yoav e Dror, que defendem o roteiro do AA centrado no 4337 em fóruns e reuniões do ACD.

No entanto, apesar desses esforços, alguns desenvolvedores principais do Ethereum ainda se opõem fortemente ao roteiro AA centrado no 4337. Eles acreditam que o 7560 (a versão nativa do 4337 a ser implementada pelos 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 do 3074, apesar da oposição da equipe do 4337, que acreditava que o 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 do Ethereum a se envolverem novamente em discussões sobre o 3074. A discussão chegou então a um impasse, com os autores de 4337 e 3074 incapazes de persuadir um ao outro. 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.

O papel de 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 inadequado considerar Vitalik como o CTO de fato de uma empresa muito grande (aliás, assumindo o 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 tornam-se inevitavelmente descentralizados – normalmente, cada área do produto/negócio da empresa tem uma equipa dedicada, que muitas vezes tem autonomia para decidir sobre os detalhes da solução. Além disso, o CTO pode não ser o maior 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 de 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 ela encapsula razoavelmente o papel de Vitalik no ecossistema Ethereum. Vitalik não participa de todas as decisões técnicas, 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 está alinhado com a visão Ethereum (sua visão).

Todo produto bem-sucedido 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 bem-sucedido 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 dos esquemas de design de alguns comitês, mas porque Vitalik, com sua visão e visão, forneceu ativamente liderança, 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, pode queixar-se 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 de Vitalik? Talvez você não tenha reclamado porque não pensou dessa forma – mas agora que 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 esta pergunta, devemos revisitar o clássico artigo de Vitalik sobre o significado da 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, trabalhando juntos de forma coesa?
  • Descentralização política: em última análise, quantos indivíduos ou organizações controlam o sistema?

De acordo com essas definições, o Ethereum é claramente arquitetonicamente descentralizado, e pode-se argumentar que ele é logicamente descentralizado porque seus componentes não têm acoplamento forte (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 Vitalik. No entanto, alguns podem argumentar que o nível de descentralização política do Ethereum não é tão alto quanto se imagina 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 baseadas não apenas na superioridade das soluções técnicas propostas, mas também em se essas decisões se alinham 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 do EIP-3074:

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

Ou o Ethereum poderia se tornar um "Frankenstein" incoerente em termos de design, com 3074 e 4337 possivelmente não cedendo um ao outro, resultando na rutura 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 principais desenvolvedores implementam o roteiro, então qual o papel da comunidade? Certamente, não é apenas 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 de 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 através 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==Investigadores;
  • C==Cliente==Desenvolvedor principal;

Juntos, desempenham os seguintes papéis:

  • A comunidade reúne-se em torno de valores específicos.
  • Vitalik articula uma visão coerente com estes valores.
  • Os investigadores formulam um roteiro com base na visão.
  • Os principais desenvolvedores implementam clientes com base no roteiro.

É claro que a realidade é muito mais complexa do que qualquer modelo simples pode capturar. Os principais desenvolvedores 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 principais desenvolvedores, 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:

Deve ser aumentada a visibilidade dos progressos dos debates sobre as PEI em análise. Toda a comunidade não deve ser "surpreendida" pela aceitação de uma PEI, e aprovações inesperadas como a EIP-3074 não devem repetir-se. O atual «estado» das PEI no sítio Web da PEI não reflete o seu estatuto no processo da DCA. É por isso que ainda diz que o EIP-3074 está "em revisão", apesar de os principais desenvolvedores terem votado para aprová-lo, sem nenhuma indicação de que ele tenha sido considerado para aprovação desde o início. Idealmente, quando um EIP está prestes a ser aceito, 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 principais promotores podem subestimar o impacto de PIE específicas nos projetos a jusante e nos utilizadores, 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 o "pessoal relevante" pode muitas vezes falar nas reuniões. No entanto, faria sentido, ocasionalmente, atribuir algum tempo de uso da palavra aos membros da comunidade para comentarem o impacto de determinadas propostas PEI nos projetos 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 investigadores têm geralmente mais apoio público para mudanças e interpretações do roteiro, graças à sua discussão ativa e redação das suas ideias.

Quando essas duas forças se chocam, os desenvolvedores principais tendem a derrubar diretamente as opiniões dos pesquisadores, como foi o caso da equipe 4337. No entanto, tal derrube 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 do EIP-3074.

Da mesma forma, quando confrontados com resistência, os pesquisadores tendem a desistir da colaboração com os principais desenvolvedores. 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 experimentar 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 da PEI. Os pesquisadores devem continuar a colaborar com os principais desenvolvedores 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 principais desenvolvedores, há também o 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 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" deste modelo.

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

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

  1. Este artigo foi reproduzido a partir de [极客 Web3]. Encaminhe o título original 'Reflexões sobre a governança do 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 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.

Explorando o impacto do Vitalik & Vários roteiros na governança do Ethereum

IntermediárioJun 03, 2024
"A atualização narrativa é um conceito emergente que não se limita mais a transformações de projetos singulares, mas engloba um escopo mais amplo. Na sua essência, este conceito envolve a modernização e reforma abrangentes dos projetos para os revitalizar e recuperar a competitividade. Especificamente, a trilha de atualização narrativa pode ser alcançada através da mudança da abordagem narrativa do projeto, ajustando sua lógica fundamental, atualizando modelos de negócios, lançando produtos inovadores, ajustando mecanismos de token, fundindo-se com outros projetos ou até mesmo rebranding."
Explorando o impacto do Vitalik & Vários roteiros na governança do Ethereum

Encaminhe o título original 'Reflexões sobre a governança do 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 perspetiva de um fundador de projeto dentro do ecossistema AA, ele destaca objetivamente o atual modelo de governança do Ethereum e seus pontos problemáticos. Derek aponta sucintamente:

Um dos conflitos de governança do Ethereum reside nas discrepâncias entre o roteiro determinado pelos pesquisadores e as perspetivas de equipes de desenvolvimento de clientes como 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 principais desenvolvedores do Ethereum para ser incluída no próximo hard fork, "Pectra". Esta proposta introduz dois novos opcodes para a Máquina Virtual Ethereum (EVM), permitindo que as Contas de Propriedade Externa (EOAs) do Ethereum 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, estabelecendo um equilíbrio entre o 4337 e o 3074 — fornecendo uma experiência AA para os usuários do EOA, mantendo a compatibilidade com o ERC-4337 até certo ponto, bem como a compatibilidade com a "solução final AA" 7560. Atualmente, os principais desenvolvedores do Ethereum estão considerando as implicações do EIP-7702, e discussões preliminares e sentimento da comunidade indicam que o EIP-7702 provavelmente substituirá o EIP-3074 mencionado anteriormente. Estou muito satisfeito com este resultado: os utilizadores EOA poderão em breve 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 governação, poderíamos ter poupado muita energia e alcançado o resultado desejado mais rapidamente. Neste artigo, eu gostaria:

  • Identificar o que correu mal no processo de governação
  • Proponha um modelo de pensamento para a governança do Ethereum
  • Oferecer sugestões de melhoria para evitar acidentes de governação semelhantes no futuro

Conclusão e reflexão sobre o incidente EIP-3074

A história mencionada acima deixou muitas pessoas insatisfeitas por vários motivos: o EIP-3074 levou vários anos para ser aprovado. 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 PEI aprovada seja rejeitada posteriormente.
  • Se forem detetados novos problemas, a aprovação de uma PEI 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 4337 se envolveu ativamente com os principais desenvolvedores do Ethereum. Se esta 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 em conjunto uma solução que satisfaça 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 correu mal?

Olhando para trás em todo o processo, ambos os lados do evento estão se culpando mutuamente. Os desenvolvedores principais do Ethereum (bem como os autores do EIP-3074) acreditam que a culpa é dos "4337 apoiadores" porque eles não participaram ativamente do processo de discussão All Core Developers (ACD). Neste processo, os EIPs precisam passar por longas deliberações e, finalmente, ser aceitos e implementados por equipes de desenvolvimento de clientes Ethereum como Geth. Alguns argumentam que, durante o período em que a EIP-3074 estava 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 da 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 da ACD. Então, se "4337 apoiantes" se preocupavam tanto com o tema, por que não participaram ativa e prontamente nas reuniões relevantes?

Por outro lado, os membros do núcleo do 4337 indicam que eles têm participado de reuniões do ACD e se oposto ao 3074 tanto quanto possível, mas os desenvolvedores do núcleo do 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 detrás disto e, a menos que abordemos ou, pelo menos, reconheçamos este problema, continuaremos a cair em acidentes de governação, seguidos de acusações contraditórias de ambos os lados, que, em última análise, não têm sentido.

A causa principal dos acidentes de governação: o roteiro

Ao contrário da crença popular, a causa raiz dos acidentes de governança reside no fato de que a ACD não é a única autoridade de governança para atualizações do protocolo Ethereum; foi substituída 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, referir-me-ei a este tipo de poder como o "roteiro". Como apontarei abaixo, todo o evento de falha de governança "3074-4337-7702" é um caso do poder do roteiro existente do Ethereum sobrepondo-se ao poder do ACD. Se falamos de governação, quando notamos que uma força intangível está a sobrecarregar 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 notadas por muitas pessoas, pelo que têm de ser expostas.

O que é um roteiro?

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

Para ilustrar meu ponto, vamos imaginar uma cena em uma reunião do ACD onde os principais desenvolvedores 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: ... Perdeste o juízo?

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 escalonamento "rollup-centric" 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 execução dos nós Ethereum. Quero usar este exemplo para ilustrar que os principais desenvolvedores 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 principais desenvolvedores devem tomar decisões com base nessa base.

Quando as visões dos principais desenvolvedores não estão alinhadas 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, então nem todos os roteiros têm o mesmo nível de "ortodoxia". Os pesquisadores por trás do roteiro do Ethereum devem trabalhar duro para promover seu roteiro para os principais desenvolvedores e a comunidade para ganhar "ortodoxia" e apoio da equipe de desenvolvimento do núcleo do Ethereum. Em relação ao AA e à abstração de contas, o próprio Vitalik tem defendido repetidamente o roteiro do AA centrado no 4337, mas, no geral, é principalmente a equipe por trás do 4337, especialmente Yoav e Dror, que defendem o roteiro do AA centrado no 4337 em fóruns e reuniões do ACD.

No entanto, apesar desses esforços, alguns desenvolvedores principais do Ethereum ainda se opõem fortemente ao roteiro AA centrado no 4337. Eles acreditam que o 7560 (a versão nativa do 4337 a ser implementada pelos 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 do 3074, apesar da oposição da equipe do 4337, que acreditava que o 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 do Ethereum a se envolverem novamente em discussões sobre o 3074. A discussão chegou então a um impasse, com os autores de 4337 e 3074 incapazes de persuadir um ao outro. 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.

O papel de 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 inadequado considerar Vitalik como o CTO de fato de uma empresa muito grande (aliás, assumindo o 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 tornam-se inevitavelmente descentralizados – normalmente, cada área do produto/negócio da empresa tem uma equipa dedicada, que muitas vezes tem autonomia para decidir sobre os detalhes da solução. Além disso, o CTO pode não ser o maior 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 de 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 ela encapsula razoavelmente o papel de Vitalik no ecossistema Ethereum. Vitalik não participa de todas as decisões técnicas, 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 está alinhado com a visão Ethereum (sua visão).

Todo produto bem-sucedido 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 bem-sucedido 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 dos esquemas de design de alguns comitês, mas porque Vitalik, com sua visão e visão, forneceu ativamente liderança, 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, pode queixar-se 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 de Vitalik? Talvez você não tenha reclamado porque não pensou dessa forma – mas agora que 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 esta pergunta, devemos revisitar o clássico artigo de Vitalik sobre o significado da 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, trabalhando juntos de forma coesa?
  • Descentralização política: em última análise, quantos indivíduos ou organizações controlam o sistema?

De acordo com essas definições, o Ethereum é claramente arquitetonicamente descentralizado, e pode-se argumentar que ele é logicamente descentralizado porque seus componentes não têm acoplamento forte (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 Vitalik. No entanto, alguns podem argumentar que o nível de descentralização política do Ethereum não é tão alto quanto se imagina 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 baseadas não apenas na superioridade das soluções técnicas propostas, mas também em se essas decisões se alinham 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 do EIP-3074:

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

Ou o Ethereum poderia se tornar um "Frankenstein" incoerente em termos de design, com 3074 e 4337 possivelmente não cedendo um ao outro, resultando na rutura 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 principais desenvolvedores implementam o roteiro, então qual o papel da comunidade? Certamente, não é apenas 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 de 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 através 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==Investigadores;
  • C==Cliente==Desenvolvedor principal;

Juntos, desempenham os seguintes papéis:

  • A comunidade reúne-se em torno de valores específicos.
  • Vitalik articula uma visão coerente com estes valores.
  • Os investigadores formulam um roteiro com base na visão.
  • Os principais desenvolvedores implementam clientes com base no roteiro.

É claro que a realidade é muito mais complexa do que qualquer modelo simples pode capturar. Os principais desenvolvedores 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 principais desenvolvedores, 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:

Deve ser aumentada a visibilidade dos progressos dos debates sobre as PEI em análise. Toda a comunidade não deve ser "surpreendida" pela aceitação de uma PEI, e aprovações inesperadas como a EIP-3074 não devem repetir-se. O atual «estado» das PEI no sítio Web da PEI não reflete o seu estatuto no processo da DCA. É por isso que ainda diz que o EIP-3074 está "em revisão", apesar de os principais desenvolvedores terem votado para aprová-lo, sem nenhuma indicação de que ele tenha sido considerado para aprovação desde o início. Idealmente, quando um EIP está prestes a ser aceito, 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 principais promotores podem subestimar o impacto de PIE específicas nos projetos a jusante e nos utilizadores, 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 o "pessoal relevante" pode muitas vezes falar nas reuniões. No entanto, faria sentido, ocasionalmente, atribuir algum tempo de uso da palavra aos membros da comunidade para comentarem o impacto de determinadas propostas PEI nos projetos 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 investigadores têm geralmente mais apoio público para mudanças e interpretações do roteiro, graças à sua discussão ativa e redação das suas ideias.

Quando essas duas forças se chocam, os desenvolvedores principais tendem a derrubar diretamente as opiniões dos pesquisadores, como foi o caso da equipe 4337. No entanto, tal derrube 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 do EIP-3074.

Da mesma forma, quando confrontados com resistência, os pesquisadores tendem a desistir da colaboração com os principais desenvolvedores. 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 experimentar 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 da PEI. Os pesquisadores devem continuar a colaborar com os principais desenvolvedores 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 principais desenvolvedores, há também o 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 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" deste modelo.

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

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

  1. Este artigo foi reproduzido a partir de [极客 Web3]. Encaminhe o título original 'Reflexões sobre a governança do 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 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.
Comece agora
Registe-se e ganhe um cupão de
100 USD
!