Na atualização do Pectra, surgiu a questão de disputa de governança mais complexa. Quando o EIP3074 foi incluído na atualização do Pectra, gerou uma enorme controvérsia, especialmente por parte da equipe do ERC4337.
EIP3074 ficou em um impasse, e o processo de governança não pôde continuar. Até que Vitalik propôs o EIP7702, que encerrou as dúvidas da equipe do ERC4337 sobre o EIP3074.
A GCC Research descobriu que há pouca discussão no mundo chinês sobre as questões de governança do EIP3074 e ERC7702 na atualização do Pectra. Mas essas questões de governança também refletem problemas profundos na governança do Ethereum, ou seja, sob o princípio de que o código é a lei, quem pode controlar o conteúdo específico do código. As questões de governança do EIP3074 e ERC7702 podem nos proporcionar uma boa perspectiva para observar o verdadeiro processo de governança interna do Ethereum.
A conclusão final deste artigo é uma paráfrase de um comentário publicado por ZeroDev, que aponta que o sistema de governança do Ethereum é o modelo VVRC. A inclusão de qualquer proposta deve primeiro estar de acordo com os valores do Ethereum (Value), depois a proposta deve refletir a visão projetada por Vitalik (Vision) e, por último, a proposta deve ser refletida no roteiro (Roadmap). Finalmente, após discussão dos desenvolvedores principais, será incorporada na implementação do cliente (Client).
A pesquisa da GCC na artigo anterior mencionou que o EIP2537 teve problemas de implementação apenas ao nível do cliente, o que levou a um atraso na inclusão do hard fork. Já o EIP3074 não foi incluído no hard fork devido a problemas de visão e roteiro. Os desenvolvedores principais do Ethereum escolheram diretamente o EIP7702, escrito por Vitalik, como a proposta final de abstração de contas.
Resumo do conteúdo da proposta
Antes de apresentar os processos de governança específicos, precisamos primeiro fazer uma breve introdução ao conteúdo específico relacionado ao EIP3074, EIP7702 e ERC4337.
EIP3074 é uma proposta de camada de execução que requer uma atualização do software do nó para ser implementada. O objetivo central do EIP3074 é implementar a funcionalidade de patrocínio de gás e transações em lote. O chamado patrocínio de gás refere-se à capacidade do usuário de pagar as taxas de gás usando qualquer token, ou o usuário pode pagar as taxas de gás offline. No entanto, é importante notar que, em comparação com outras propostas de abstração de contas que permitem a alteração do algoritmo de verificação de assinatura, o EIP3074 não permite que os usuários usem qualquer algoritmo de assinatura que não seja o secp256k1. Em outras palavras, o EIP3074 não é uma proposta que atende a todas as funcionalidades de abstração de contas. Este também é um dos pontos criticados do EIP3074.
A fim de alcançar o objetivo desejado, EIP3074 introduziu dois opcodes, AUTH e AUTHCALL. O opcode AUTH pode ser assinado pela assinatura de verificação e, quando a verificação de assinatura for aprovada, o opcode será configurado com autorizado como o endereço do signatário no contexto EVM atual. Quando autorizado no contexto é configurado, AUTHCALL pode iniciar uma transação usando o endereço autorizado como o msg.sender que chama a transação. Até certo ponto, os usuários podem delegar suas contas a um contrato inteligente em uma transação por meio de assinaturas. Geralmente chamamos esse contrato inteligente delegado pelo usuário de contrato invocador.
Qual é o conteúdo específico da assinatura do usuário? O usuário precisa assinar o seguinte conteúdo:
O endereço do invocador mencionado no conteúdo acima refere-se ao endereço do contrato invocador que o usuário deseja delegar. O EVM irá verificar se o conteúdo da assinatura do usuário corresponde ao contrato que realmente valida a assinatura, evitando que o conteúdo da assinatura AUTH do usuário seja utilizado por outros contratos.
O nonce é um identificador que impede a repetição de transações. No entanto, é importante observar que o código de operação AUTH verifica se o nonce na assinatura corresponde ao nonce da EOA atual da assinatura. Teoricamente, desde que o usuário não utilize uma conta EOA para iniciar transações que aumentem o valor do nonce, a assinatura AUTH emitida pelo usuário pode ser utilizada indefinidamente pelo contrato invoker. Isso representa uma grande vulnerabilidade de segurança, o que significa que os usuários que utilizam a EIP3074 devem confiar nos provedores de serviços de retransmissão que obtêm as assinaturas. Se o provedor de serviços de retransmissão que obtém a assinatura do usuário for malicioso, esse provedor pode, em algum momento, retransmitir a assinatura AUTH do usuário para roubar os ativos do usuário.
Outro aspecto com problemas de segurança é o campo commit. O campo commit é usado para garantir certas operações, permitindo que o usuário controle de forma mais detalhada os direitos de assinatura dentro do commit, por exemplo, escrevendo alguns conteúdos no commit para evitar que sua assinatura seja usada em transferências de ETH. No documento EIP3074, o proponente fornece uma série de exemplos de como utilizar o campo commit. No entanto, o problema é que a função do commit depende completamente da definição do contrato inteligente, sendo essencialmente um conteúdo opcional. Diferentes contratos inteligentes podem interpretar o conteúdo do commit de maneiras completamente diferentes, e pode haver casos em que alguns contratos nem leem o conteúdo do commit. Se um usuário deseja usar o EIP3074 de forma segura, deve revisar os contratos inteligentes por conta própria.
Por fim, apresentamos o impacto do EIP3074 no pool de memórias de transações do Ethereum. Após a introdução do EIP3074, pode surgir um método de ataque ao pool de memórias, onde hackers podem usar uma grande quantidade de contas para iniciar transações e, em seguida, quando as transações estiverem prestes a ser agrupadas, usar o EIP3074 para esvaziar uma única vez o ETH dessas contas, fazendo com que todas as transações iniciadas anteriormente falhem. Esse método de ataque causará um impacto considerável nos nós da camada de execução, sendo essencialmente um ataque DoS. Mas é importante notar que o EIP7702, que substitui o EIP3074, também apresentou esse problema, embora o EIP7702 tenha introduzido algumas restrições para evitar a ocorrência desse problema, que discutiremos mais adiante.
Além dos problemas que o próprio EIP3074 apresenta, o autor do ERC4337, Yova, abordou mais objeções no artigo Implications of EIP-3074 inclusion. Resumidamente, essas objeções incluem principalmente:
Risco de centralização. Devido às propriedades especiais da assinatura AUTH, os usuários devem confiar completamente nos provedores de serviços de retransmissão do EIP3074 e na infraestrutura subjacente. Ao mesmo tempo, a infraestrutura construída por protocolos de abstração de contas como o ERC4337 não é totalmente compatível com o EIP3074.
Segurança do usuário. Como mencionado acima, o EIP3074 não possui um método de controle de permissões de design unificado, e o design do nonce da assinatura também apresenta riscos de segurança, o que pode levar ao surgimento de sérios problemas de segurança.
Funcionalidade de abstração de conta incompleta. Comparado a outras propostas de abstração de conta, o EIP3074 é incompleto e não consegue implementar funcionalidades como a troca do algoritmo de assinatura do usuário.
Existem problemas na experiência do usuário. Quando os usuários precisam delegar suas contas a um contrato inteligente, eles precisam realizar uma assinatura AUTH e, em seguida, publicar a chamada que contém a assinatura AUTH na cadeia. Os usuários precisam fazer duas assinaturas.
EIP7702 é uma proposta apresentada por Vitalik para substituir o EIP3074. Esta proposta não introduziu novos códigos de operação EVM, mas sim um novo tipo de transação, que é chamado de SET_CODE_TX_TYPE. Assim que o usuário inicia uma transação do tipo EIP7702, ele pode adicionar funcionalidades de contrato inteligente à sua EOA, mantendo as funcionalidades básicas da EOA. Em termos simples, o usuário pode continuar a usar carteiras como MetaMask para iniciar transações ou outros usuários podem chamar o endereço EOA na forma de um contrato inteligente.
Apresentamos a funcionalidade do EIP7702 com um exemplo simples de transações em lote. Os usuários podem usar o EIP7702 para delegar seu endereço EOA a um contrato inteligente que pode executar chamadas em lote, e então os usuários podem chamar diretamente seu endereço EOA para iniciar transações em lote na forma de um contrato inteligente.
Em termos de implementação técnica, o novo tipo de transação introduzido pelo EIP7702 adiciona a lista authorization_list em comparação com as transações tradicionais. O conteúdo específico dessa lista é [[chain_id, address, nonce, y_parity, r, s], ...]. Aqui, address é o endereço do contrato inteligente que o usuário deseja delegar, enquanto nonce é o valor nonce atual do usuário. Os restantes y_parity, r e s são os resultados da assinatura do usuário. Durante o processo de execução, primeiro percorreremos cada item da authorization_list para processamento. O método de processamento consiste em recuperar o endereço EOA através dos parâmetros de assinatura como y_parity e, em seguida, apontar o endereço EOA para o endereço do contrato inteligente especificado como address. Depois disso, o endereço EOA poderá aceitar chamadas para executar as funções do contrato.
As vantagens do EIP7702 são muito claras, sendo a mais central que o EIP7702 essencialmente permite que EOA possua a funcionalidade de contratos inteligentes. Isso está em linha com as regras básicas de abstração de contas, como no caso do ERC4337, o que significa que o EIP7702 pode aproveitar toda a exploração atual no campo da abstração de contas e reutilizar a infraestrutura existente, como o EIP7702 pode usar diretamente a infraestrutura do ERC4337. Atualmente, o ERC4337 já lançou a EntryPoint v0.8 que suporta chamadas do EIP7702. Do ponto de vista da reutilização da infraestrutura existente, o EIP7702 e o ERC4337 têm o mesmo grau de descentralização.
É claro que EIP7702 também não resolve bem os problemas que surgem em EIP3074. Os problemas que existem na maioria dos EIP3074 ainda existem. EIP7702 exige que o contrato de conta tenha uma implementação segura, e o protocolo em si não garante qualquer segurança. Nos primeiros dias de EIP7702, alguns desenvolvedores propuseram padronizar nonces de assinatura para evitar possíveis ataques de replay, mas EIP7702 também não aceitaram essas sugestões. Portanto, se o usuário quiser usar o EIP7702 com segurança, então o usuário precisa rever a segurança do contrato por conta própria.
Ao mesmo tempo, o EIP7702 também trará uma série de problemas para a camada de execução. Na parte anterior, apresentamos um possível método de ataque DoS à memória da camada de execução utilizando o EIP3074. Este método também é eficaz no EIP7702. Portanto, o EIP7702 recomenda que todos os endereços EOA que utilizam o EIP7702 tenham apenas uma transação pendente na memória, para evitar a ocorrência de grandes ataques DoS.
Em suma, o maior problema do EIP3074 é que o EIP3074 não implementou a funcionalidade completa de abstração de contas, enquanto o EIP7702 implementou a funcionalidade completa de abstração de contas. E a definição do que inclui "abstração de contas completa" é exatamente o que os autores do ERC4337 definiram. Ao ler isto, os leitores devem conseguir entender por que o EIP3074 foi contestado pela equipe do ERC4337, sendo finalmente substituído pelo EIP7702. Discutiremos todo o processo de governança e discussão mais adiante.
O processo de governança do EIP3074 e do EIP7702
EIP3074 foi mencionado muito cedo na reunião de desenvolvedores principais do Ethereum. Em 2 de abril de 2021, na Meeting #109, os desenvolvedores principais do Ethereum realizaram uma discussão simples sobre o EIP3074. O resultado da discussão foi muito simples:
Alexey levantou que o conteúdo da assinatura EIP3074 apresenta riscos de segurança, podendo causar sérias perdas de segurança aos usuários, sugerindo que o EIP3074 deve normalizar mais especificamente o conteúdo da assinatura AUTH, proposta que recebeu apoio de Martin.
James apontou que o EIP3074 pode trazer potenciais vulnerabilidades na camada de execução, como ataques DoS, e sugeriu que o EIP3074 forneça uma análise de ameaças por escrito.
Alexey e Martin queixaram-se da qualidade da documentação do EIP3074, gastando muito tempo a ler e a compreender.
Martin acredita que o núcleo do EIP3074 é a colaboração e implementação com aplicações, especialmente com desenvolvedores de carteiras; o autor do EIP3074 afirmou que já teve uma série de intercâmbios com desenvolvedores de aplicações.
É interessante notar que Vitalik, nesta reunião, acredita que de qualquer forma o Ethereum precisa de uma solução técnica que permita que uma transação projetada para EOA gere múltiplas chamadas. Embora existam possíveis problemas de segurança com o EIP3074, o EIP3074 apresenta uma possível solução técnica, e os desenvolvedores precisam avançar com base no EIP3074.
É evidente que, devido aos problemas de segurança do EIP3074, esta reunião não incluiu o EIP3074 na atualização de Londres.
Em 11 de junho de 2021, na Reunião #115, EIP3074 desenvolvedores apresentaram um relatório sobre auditorias de segurança, que se concentrou em questões de segurança EIP3074. A conclusão simples é que EIP3074 contrato invocador é muito importante no sistema, portanto, se o contrato invocador precisa ser gerenciado é uma questão. EIP3074 desenvolvedores desejam formalizar o contrato do invocador para maior segurança.
É claro que também há uma parte da discussão sobre alguns contratos usando msg.sender == tx.origin para determinar se o endereço de chamada é EOA, e quando EIP3074 for introduzido, esses julgamentos serão invalidados, mas a conclusão é que a falha desta parte do julgamento não causará sérios problemas de segurança. Em resumo, a reunião centrou-se nos EIP3074 apresentadores que apresentaram os resultados da auditoria de segurança 3074 aos principais programadores. A conclusão final da reunião foi que a 3074 ainda precisa considerar a questão do contrato invocador, e recomenda-se não aderir ao hard fork de Londres.
Na reunião #116 de 25 de junho de 2021, o autor principal do ERC4337, Yova, apresentou materiais para "Um caso para uma alternativa mais simples ao EIP 3074", que aponta para vários problemas de segurança no EIP3074, sugerindo modificações em algumas de suas partes, como limitar o conteúdo do campo commit na assinatura, exigindo que o campo commit esteja no formato {nonce,to,gas,calldata,value,chainid}. Após a adoção deste padrão de assinatura, o EIP3074 pode ser utilizado apenas para executar algumas transações específicas para garantir a segurança das transações.
O autor do EIP3074 respondeu ao material submetido por Yova durante a reunião.
Espero incluir o endereço do contrato invoker nas normas da EIP, e então os desenvolvedores principais do Ethereum podem escrever um contrato invoker seguro para evitar problemas de segurança.
Sobre o conteúdo do commit na assinatura, os desenvolvedores do EIP3074 acreditam que isso é completamente uma questão do usuário e do software da carteira, não necessitando de padronização dentro do EIP.
Vitalik apresentou os seguintes três pontos nesta reunião:
O EIP3074 ainda utiliza o tradicional esquema de assinatura secp256k1, não conseguindo implementar características resistentes a quânticos.
EIP3074 não tem compatibilidade futura, usar EIP3074 também não permite que um EOA evolua para uma conta de contrato inteligente.
O ciclo de vida do EIP3074 é limitado. O 3074 introduziu duas instruções pré-compiladas, AUTH e AUTHCALL, mas de acordo com o roteiro da abstração de contas, no futuro todas as carteiras no Ethereum poderão ser carteiras de contratos inteligentes, e as instruções pré-compiladas do EIP3074 serão descontinuadas.
Na reunião #131 de 4 de fevereiro de 2022, os desenvolvedores discutiram os tipos de EIP que deveriam ser incluídos na atualização ShangHai. O EIP3074 foi incluído na discussão, mas os desenvolvedores apenas sincronizaram brevemente o progresso do desenvolvimento do EIP3074. Vale a pena notar que, antes do início da reunião, a Nethermind escreveu o artigo Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337, que não continha objeções ao EIP3074.
Na reunião #167 de 3 de agosto de 2023, os desenvolvedores principais mencionaram o EIP3074 ao discutir outro EIP5806. O EIP5806 é uma proposta que permite que EOA chamem contratos externos usando o método deleGate.io call durante o processo de transação. Essa proposta é, de certa forma, semelhante ao EIP7702. No entanto, os desenvolvedores principais também levantaram preocupações sobre a segurança dessa proposta, com Ansgar apontando que o EIP3074 não pôde ser incluído nas bifurcações duras devido a possíveis problemas de segurança, enquanto o EIP5806 é uma proposta mais radical.
Na reunião #182, realizada em 29 de fevereiro de 2024, os desenvolvedores discutiram em detalhes se o EIP3074 deveria ser incluído na atualização Pectra. Vitalik afirmou que qualquer padrão de abstração de conta deve ter as seguintes três funcionalidades:
Rotação de chaves
Descontinuação de chaves
Assinatura resistente a quântica compatível
Vitalik apontou que o EIP5806 pode ser uma escolha melhor do que o EIP3074. Andrew acredita que o EIP3074 é mais genérico em comparação com o EIP5806 e sugere a utilização do EIP3074. Vitalik refutou Andrew, argumentando que no futuro todas as carteiras podem ser carteiras inteligentes, e assim que isso acontecer, os códigos de operação pré-compilados introduzidos pelo EIP3074 se tornarão obsoletos. Yoav, como autor do ERC4337, fez uma longa declaração nesta reunião, e seu discurso incluiu principalmente:
O EIP3074 pode levar a ataques DoS na pool de memória do Ethereum, enquanto o ERC4337 realizou uma extensa pesquisa sobre esta parte e forneceu algumas regras para evitar ataques.
O EIP3074 requer que os usuários assinem duas vezes ao iniciar transações em lote, o que é irracional.
O EIP3074 exige o uso de um retransmissor centralizado
Yova está mais inclinado a usar o EIP5806 como uma solução de abstração de conta.
Inside Meeting #183 em 14 de março de 2024, os principais desenvolvedores convidaram Dan Finlay, da MetaMask, para discutir o que a carteira pensa sobre EIP3074. Dan é a favor de EIP3074, observando que o MetaMask também apoiará os testes de EIP3074. A MetaMask acredita que EIP3074 pode permitir funcionalmente que a EOA aproveite todas as funcionalidades da abstração de contas. Em termos de segurança, a EIP3074 fornece uma solução para prestadores de serviços de carteira, ou seja, separação de chaves quentes e frias. O provedor de serviços de carteira pode manter a assinatura EIP3074 da EOA para iniciar uma transação, e os usuários podem usar a chave privada quente em transações normais, mas a chave privada fria pode ser mantida na carteira de hardware do usuário e, quando uma emergência é encontrada, o usuário pode usar a chave privada fria na carteira fria para iniciar uma transação para revogar a assinatura do EIP3074. Esta solução de separação de chaves privadas quentes e frias dá flexibilidade aos fornecedores de carteiras.
Vitalik apontou que, no EIP3074, os designers de carteiras devem projetar uma lógica de autorização rigorosa para evitar que a assinatura EIP3074 dos usuários seja abusada. Curiosamente, ao discutir a adição de suporte para EIP3074 no MetaMask, Vitalik sugeriu que se pode usar L2 como uma solução de transição, ou seja, qualquer nova modificação na camada de execução deve ser praticada primeiro no L2, pois o volume de fundos no L2 é limitado, e mesmo que ocorram problemas sérios, isso causaria perdas significativas.
Dror Tiros apontou na discussão que a melhor forma de garantir a segurança do EIP3074 é que a oficial do Ethereum forneça diretamente o contrato invoker. Mas Dan Finlay discorda da opinião de que o contrato deve ser fornecido oficialmente, Dan acredita que o contrato invoker deve ser totalmente decidido pelos usuários, e o mercado acabará escolhendo o contrato invoker mais seguro.
Ansgar ainda defende que a EIP3074 deve ter uma única assinatura correspondente a uma única transação, e que os provedores de carteira não devem reutilizar as assinaturas dos usuários para iniciar transações, mas Dan Finlay também expressou objeções. Dan Finlay acredita que a EIP3074 deve ser assinada por uma carteira fria, e então os provedores de carteira podem reutilizar essa assinatura para iniciar transações diretamente em nome do usuário; se for necessário que o usuário assine novamente a cada vez, isso pode levar ao uso múltiplo da chave privada fria. Isso não está de acordo com a ideia de separação de chaves frias e quentes.
Na reunião, os desenvolvedores principais discutiram outro tópico importante, que é a lista de inclusão. A lista de inclusão é uma forma de aumentar as propriedades de resistência à censura do Ethereum. Simplificando, a lista de inclusão permite que algumas transações sejam prometidas para serem incluídas diretamente no próximo bloco. No entanto, os desenvolvedores principais apontaram que o EIP3074 é incompatível com a lista de inclusão.
Na reunião #185, que ocorreu em 11 de abril de 2024, a maioria das implementações de clientes concordou em incluir o EIP3074 no hard fork Pectra, mas o Geth se opôs, alegando que o EIP3074 poderia causar problemas com as árvores Verkle. Danno também expressou objeções, pois o EIP3074 poderia levar à reutilização de assinaturas. Yoav também se opôs, apresentando um plano para atacar o pool de memória usando EIP3074 e transações Blob. Resumidamente, um atacante poderia iniciar um grande número de transações Blob, todas contendo uma quantidade significativa de dados, e então usar o EIP3074 para invalidar todas essas transações Blob.
Em resumo, na reunião, todos os desenvolvedores de clientes concordaram que o EIP3074 seria incluído na atualização final.
Na reunião #187 de 9 de maio de 2024, os desenvolvedores principais discutiram pela primeira vez a questão da substituição do EIP7702 pelo EIP3074. O EIP7702 foi concluído 90 minutos antes do início da reunião dos desenvolvedores principais, onde foi reconhecido que o EIP7702 é um padrão superior ao EIP3074. Não houve vozes contrárias ao EIP7702 durante a reunião, apenas alguns pesquisadores expressaram a opinião de que o EIP7702 também possui atributos de irreversibilidade semelhantes ao EIP3074, o que pode levar a problemas de segurança dos fundos.
Na reunião #188, realizada em 23 de maio de 2024, os desenvolvedores principais discutiram a possibilidade de substituir o EIP7702 pelo EIP3074. A conclusão final da reunião foi usar o EIP7702 para substituir o EIP3074 como padrão de abstração de contas no hard fork do Pectra. Vitalik apontou que o EIP7702 também possui algumas propriedades de irreversibilidade que são consistentes com o EIP3074, e essas propriedades já foram amplamente discutidas durante a discussão do EIP3074. Curiosamente, houve uma grande participação de representantes do ERC4337 na reunião.
Na verdade, a discussão sobre a substituição do EIP3074 pelo EIP7702 já havia sido amplamente debatida antes da 188ª reunião dos desenvolvedores principais, e o resultado da discussão foi que o 3074 seria substituído, portanto, não houve muita controvérsia na reunião dos desenvolvedores principais.
Roteiro e Decisão
A infraestrutura central da abstração de contas, Zerodev, publicou um artigo interessante ao saber que o EIP3074 seria substituído. O título do artigo é "Reflections on Ethereum Governance Following the 3074 Saga". A conclusão do artigo é que o EIP7702 é uma boa proposta que pode beneficiar todos os usuários. No entanto, o processo de governança do EIP7702 que substitui o EIP3074 não é o melhor, por razões que incluem:
EIP3074 passou por um longo processo de discussão, e já discutimos anteriormente as várias discussões sobre o EIP3074 nas reuniões dos desenvolvedores principais.
Após a confirmação da inclusão do EIP3074 na atualização do Pectra, houve uma grande oposição da comunidade ERC4337. Claro, como já mencionamos acima, o principal desenvolvedor do ERC4337, yova, expressou várias vezes em reuniões de desenvolvedores principais a sua oposição ao EIP3074.
A Zerodev acredita que o melhor caminho de governança deve ser a participação ampla da comunidade ERC4337 e a expressão das suas opiniões durante o longo processo de discussão dos desenvolvedores principais do EIP3074.
EIP3074 desenvolvedores acreditam que ERC4337 devem ser responsabilizados por falhas de governança. Porque EIP3074 tem estado ativamente envolvido na governança nos últimos anos, e se comunicou com Yova, o principal desenvolvedor do ERC4337, muitas vezes.
A comunidade ERC4337 acredita que o EIP3074 deve ser o principal responsável pelo fracasso da governança. Os membros da comunidade ERC4337 acreditam que Yova, como desenvolvedor principal do ERC4337, expressou sua oposição ao EIP3074 em várias reuniões de desenvolvedores principais, mas os desenvolvedores principais parecem não ter ouvido suas opiniões. A maioria dos membros da comunidade ERC4337 não acompanhou a dinâmica de governança do EIP3074, e a maioria acredita que o EIP3074 é um padrão morto. A comunidade ERC4337 também acredita que os desenvolvedores principais não se comunicaram de forma ativa com a comunidade ERC4337.
EIP3074 e ERC4337 acreditam que realizaram um trabalho de governança correto, enquanto a outra parte deve ser a principal responsável pelo fracasso da governança. É evidente que existe uma razão mais profunda a atuar neste processo de governança.
De forma simples, a razão mais profunda na verdade é o roteiro do Ethereum. O roteiro do Ethereum tem uma autoridade superior às reuniões dos desenvolvedores principais. O roteiro da abstração de contas é centrado no ERC4337. O EIP7702 é totalmente compatível com o padrão ERC4337, mas o EIP3074 não é totalmente compatível com o padrão ERC4337. Portanto, do ponto de vista do roteiro do Ethereum, a substituição do EIP3074 é algo que certamente acontecerá.
Claro, o roteiro do Ethereum é uma demonstração pessoal da visão futura do Ethereum por Vitalik. Se ocorrer uma séria discussão durante o processo de governança do Ethereum, Vitalik, como o definidor do roteiro, terá a palavra final. E foi exatamente o julgamento de Vitalik que levou à substituição do EIP3074.
O modelo de governança do Ethereum é o modelo values ⇒ vision ⇒ roadmaps ⇒ clients, ou simplesmente o modelo VVRC. O seu processo de governança é o seguinte:
valores, especialmente os valores da comunidade, os valores da comunidade Ethereum incluem descentralização, resistência à censura, entre outros.
visão, na verdade, é o pensamento pessoal de Vitalik sobre o futuro do Ethereum
roadmaps, os pesquisadores fornecem alguns detalhes técnicos com base na visão, apresentando um roteiro de implementação mais completo.
Implementação do cliente, os desenvolvedores principais do cliente utilizam ferramentas como reuniões de desenvolvedores principais para discutir o roteiro e implementar as necessidades contidas no roteiro.
O processo acima é o verdadeiro processo de governança do Ethereum. Podemos ver que a visão pessoal de Vitalik está na parte inferior do modelo de governança do Ethereum, portanto, uma vez que surjam sérias disputas na implementação do cliente, a opinião pessoal de Vitalik será o julgamento final.
>
> Referência
>
>
>Introdução ao ZeroDev
>
>
> nulo
>
>
>
>
>
> Introdução ao ZeroDev
>
>
> null
>
>
>
>
>
> Notas sobre o roteiro de Abstração de Conta - HackMD
>
>
> # Notas sobre o roteiro de Abstração de Conta *Agradecimentos especiais a Vitalik e à equipe de AA pelo feedback
>
>
>
>
>
>
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Guerra de Governança do Ethereum: EIP3074, ERC4337 e EIP7702
Autor: shew
Resumo
Na atualização do Pectra, surgiu a questão de disputa de governança mais complexa. Quando o EIP3074 foi incluído na atualização do Pectra, gerou uma enorme controvérsia, especialmente por parte da equipe do ERC4337.
EIP3074 ficou em um impasse, e o processo de governança não pôde continuar. Até que Vitalik propôs o EIP7702, que encerrou as dúvidas da equipe do ERC4337 sobre o EIP3074.
A GCC Research descobriu que há pouca discussão no mundo chinês sobre as questões de governança do EIP3074 e ERC7702 na atualização do Pectra. Mas essas questões de governança também refletem problemas profundos na governança do Ethereum, ou seja, sob o princípio de que o código é a lei, quem pode controlar o conteúdo específico do código. As questões de governança do EIP3074 e ERC7702 podem nos proporcionar uma boa perspectiva para observar o verdadeiro processo de governança interna do Ethereum.
A conclusão final deste artigo é uma paráfrase de um comentário publicado por ZeroDev, que aponta que o sistema de governança do Ethereum é o modelo VVRC. A inclusão de qualquer proposta deve primeiro estar de acordo com os valores do Ethereum (Value), depois a proposta deve refletir a visão projetada por Vitalik (Vision) e, por último, a proposta deve ser refletida no roteiro (Roadmap). Finalmente, após discussão dos desenvolvedores principais, será incorporada na implementação do cliente (Client).
A pesquisa da GCC na artigo anterior mencionou que o EIP2537 teve problemas de implementação apenas ao nível do cliente, o que levou a um atraso na inclusão do hard fork. Já o EIP3074 não foi incluído no hard fork devido a problemas de visão e roteiro. Os desenvolvedores principais do Ethereum escolheram diretamente o EIP7702, escrito por Vitalik, como a proposta final de abstração de contas.
Resumo do conteúdo da proposta
Antes de apresentar os processos de governança específicos, precisamos primeiro fazer uma breve introdução ao conteúdo específico relacionado ao EIP3074, EIP7702 e ERC4337.
EIP3074 é uma proposta de camada de execução que requer uma atualização do software do nó para ser implementada. O objetivo central do EIP3074 é implementar a funcionalidade de patrocínio de gás e transações em lote. O chamado patrocínio de gás refere-se à capacidade do usuário de pagar as taxas de gás usando qualquer token, ou o usuário pode pagar as taxas de gás offline. No entanto, é importante notar que, em comparação com outras propostas de abstração de contas que permitem a alteração do algoritmo de verificação de assinatura, o EIP3074 não permite que os usuários usem qualquer algoritmo de assinatura que não seja o secp256k1. Em outras palavras, o EIP3074 não é uma proposta que atende a todas as funcionalidades de abstração de contas. Este também é um dos pontos criticados do EIP3074.
A fim de alcançar o objetivo desejado, EIP3074 introduziu dois opcodes, AUTH e AUTHCALL. O opcode AUTH pode ser assinado pela assinatura de verificação e, quando a verificação de assinatura for aprovada, o opcode será configurado com autorizado como o endereço do signatário no contexto EVM atual. Quando autorizado no contexto é configurado, AUTHCALL pode iniciar uma transação usando o endereço autorizado como o msg.sender que chama a transação. Até certo ponto, os usuários podem delegar suas contas a um contrato inteligente em uma transação por meio de assinaturas. Geralmente chamamos esse contrato inteligente delegado pelo usuário de contrato invocador.
Qual é o conteúdo específico da assinatura do usuário? O usuário precisa assinar o seguinte conteúdo:
O endereço do invocador mencionado no conteúdo acima refere-se ao endereço do contrato invocador que o usuário deseja delegar. O EVM irá verificar se o conteúdo da assinatura do usuário corresponde ao contrato que realmente valida a assinatura, evitando que o conteúdo da assinatura AUTH do usuário seja utilizado por outros contratos.
O nonce é um identificador que impede a repetição de transações. No entanto, é importante observar que o código de operação AUTH verifica se o nonce na assinatura corresponde ao nonce da EOA atual da assinatura. Teoricamente, desde que o usuário não utilize uma conta EOA para iniciar transações que aumentem o valor do nonce, a assinatura AUTH emitida pelo usuário pode ser utilizada indefinidamente pelo contrato invoker. Isso representa uma grande vulnerabilidade de segurança, o que significa que os usuários que utilizam a EIP3074 devem confiar nos provedores de serviços de retransmissão que obtêm as assinaturas. Se o provedor de serviços de retransmissão que obtém a assinatura do usuário for malicioso, esse provedor pode, em algum momento, retransmitir a assinatura AUTH do usuário para roubar os ativos do usuário.
Outro aspecto com problemas de segurança é o campo commit. O campo commit é usado para garantir certas operações, permitindo que o usuário controle de forma mais detalhada os direitos de assinatura dentro do commit, por exemplo, escrevendo alguns conteúdos no commit para evitar que sua assinatura seja usada em transferências de ETH. No documento EIP3074, o proponente fornece uma série de exemplos de como utilizar o campo commit. No entanto, o problema é que a função do commit depende completamente da definição do contrato inteligente, sendo essencialmente um conteúdo opcional. Diferentes contratos inteligentes podem interpretar o conteúdo do commit de maneiras completamente diferentes, e pode haver casos em que alguns contratos nem leem o conteúdo do commit. Se um usuário deseja usar o EIP3074 de forma segura, deve revisar os contratos inteligentes por conta própria.
Por fim, apresentamos o impacto do EIP3074 no pool de memórias de transações do Ethereum. Após a introdução do EIP3074, pode surgir um método de ataque ao pool de memórias, onde hackers podem usar uma grande quantidade de contas para iniciar transações e, em seguida, quando as transações estiverem prestes a ser agrupadas, usar o EIP3074 para esvaziar uma única vez o ETH dessas contas, fazendo com que todas as transações iniciadas anteriormente falhem. Esse método de ataque causará um impacto considerável nos nós da camada de execução, sendo essencialmente um ataque DoS. Mas é importante notar que o EIP7702, que substitui o EIP3074, também apresentou esse problema, embora o EIP7702 tenha introduzido algumas restrições para evitar a ocorrência desse problema, que discutiremos mais adiante.
Além dos problemas que o próprio EIP3074 apresenta, o autor do ERC4337, Yova, abordou mais objeções no artigo Implications of EIP-3074 inclusion. Resumidamente, essas objeções incluem principalmente:
EIP7702 é uma proposta apresentada por Vitalik para substituir o EIP3074. Esta proposta não introduziu novos códigos de operação EVM, mas sim um novo tipo de transação, que é chamado de SET_CODE_TX_TYPE. Assim que o usuário inicia uma transação do tipo EIP7702, ele pode adicionar funcionalidades de contrato inteligente à sua EOA, mantendo as funcionalidades básicas da EOA. Em termos simples, o usuário pode continuar a usar carteiras como MetaMask para iniciar transações ou outros usuários podem chamar o endereço EOA na forma de um contrato inteligente.
Apresentamos a funcionalidade do EIP7702 com um exemplo simples de transações em lote. Os usuários podem usar o EIP7702 para delegar seu endereço EOA a um contrato inteligente que pode executar chamadas em lote, e então os usuários podem chamar diretamente seu endereço EOA para iniciar transações em lote na forma de um contrato inteligente.
Em termos de implementação técnica, o novo tipo de transação introduzido pelo EIP7702 adiciona a lista authorization_list em comparação com as transações tradicionais. O conteúdo específico dessa lista é [[chain_id, address, nonce, y_parity, r, s], ...]. Aqui, address é o endereço do contrato inteligente que o usuário deseja delegar, enquanto nonce é o valor nonce atual do usuário. Os restantes y_parity, r e s são os resultados da assinatura do usuário. Durante o processo de execução, primeiro percorreremos cada item da authorization_list para processamento. O método de processamento consiste em recuperar o endereço EOA através dos parâmetros de assinatura como y_parity e, em seguida, apontar o endereço EOA para o endereço do contrato inteligente especificado como address. Depois disso, o endereço EOA poderá aceitar chamadas para executar as funções do contrato.
As vantagens do EIP7702 são muito claras, sendo a mais central que o EIP7702 essencialmente permite que EOA possua a funcionalidade de contratos inteligentes. Isso está em linha com as regras básicas de abstração de contas, como no caso do ERC4337, o que significa que o EIP7702 pode aproveitar toda a exploração atual no campo da abstração de contas e reutilizar a infraestrutura existente, como o EIP7702 pode usar diretamente a infraestrutura do ERC4337. Atualmente, o ERC4337 já lançou a EntryPoint v0.8 que suporta chamadas do EIP7702. Do ponto de vista da reutilização da infraestrutura existente, o EIP7702 e o ERC4337 têm o mesmo grau de descentralização.
É claro que EIP7702 também não resolve bem os problemas que surgem em EIP3074. Os problemas que existem na maioria dos EIP3074 ainda existem. EIP7702 exige que o contrato de conta tenha uma implementação segura, e o protocolo em si não garante qualquer segurança. Nos primeiros dias de EIP7702, alguns desenvolvedores propuseram padronizar nonces de assinatura para evitar possíveis ataques de replay, mas EIP7702 também não aceitaram essas sugestões. Portanto, se o usuário quiser usar o EIP7702 com segurança, então o usuário precisa rever a segurança do contrato por conta própria.
Ao mesmo tempo, o EIP7702 também trará uma série de problemas para a camada de execução. Na parte anterior, apresentamos um possível método de ataque DoS à memória da camada de execução utilizando o EIP3074. Este método também é eficaz no EIP7702. Portanto, o EIP7702 recomenda que todos os endereços EOA que utilizam o EIP7702 tenham apenas uma transação pendente na memória, para evitar a ocorrência de grandes ataques DoS.
Em suma, o maior problema do EIP3074 é que o EIP3074 não implementou a funcionalidade completa de abstração de contas, enquanto o EIP7702 implementou a funcionalidade completa de abstração de contas. E a definição do que inclui "abstração de contas completa" é exatamente o que os autores do ERC4337 definiram. Ao ler isto, os leitores devem conseguir entender por que o EIP3074 foi contestado pela equipe do ERC4337, sendo finalmente substituído pelo EIP7702. Discutiremos todo o processo de governança e discussão mais adiante.
O processo de governança do EIP3074 e do EIP7702
EIP3074 foi mencionado muito cedo na reunião de desenvolvedores principais do Ethereum. Em 2 de abril de 2021, na Meeting #109, os desenvolvedores principais do Ethereum realizaram uma discussão simples sobre o EIP3074. O resultado da discussão foi muito simples:
É interessante notar que Vitalik, nesta reunião, acredita que de qualquer forma o Ethereum precisa de uma solução técnica que permita que uma transação projetada para EOA gere múltiplas chamadas. Embora existam possíveis problemas de segurança com o EIP3074, o EIP3074 apresenta uma possível solução técnica, e os desenvolvedores precisam avançar com base no EIP3074.
É evidente que, devido aos problemas de segurança do EIP3074, esta reunião não incluiu o EIP3074 na atualização de Londres.
Em 11 de junho de 2021, na Reunião #115, EIP3074 desenvolvedores apresentaram um relatório sobre auditorias de segurança, que se concentrou em questões de segurança EIP3074. A conclusão simples é que EIP3074 contrato invocador é muito importante no sistema, portanto, se o contrato invocador precisa ser gerenciado é uma questão. EIP3074 desenvolvedores desejam formalizar o contrato do invocador para maior segurança.
É claro que também há uma parte da discussão sobre alguns contratos usando msg.sender == tx.origin para determinar se o endereço de chamada é EOA, e quando EIP3074 for introduzido, esses julgamentos serão invalidados, mas a conclusão é que a falha desta parte do julgamento não causará sérios problemas de segurança. Em resumo, a reunião centrou-se nos EIP3074 apresentadores que apresentaram os resultados da auditoria de segurança 3074 aos principais programadores. A conclusão final da reunião foi que a 3074 ainda precisa considerar a questão do contrato invocador, e recomenda-se não aderir ao hard fork de Londres.
Na reunião #116 de 25 de junho de 2021, o autor principal do ERC4337, Yova, apresentou materiais para "Um caso para uma alternativa mais simples ao EIP 3074", que aponta para vários problemas de segurança no EIP3074, sugerindo modificações em algumas de suas partes, como limitar o conteúdo do campo commit na assinatura, exigindo que o campo commit esteja no formato {nonce,to,gas,calldata,value,chainid}. Após a adoção deste padrão de assinatura, o EIP3074 pode ser utilizado apenas para executar algumas transações específicas para garantir a segurança das transações.
O autor do EIP3074 respondeu ao material submetido por Yova durante a reunião.
Vitalik apresentou os seguintes três pontos nesta reunião:
Na reunião #131 de 4 de fevereiro de 2022, os desenvolvedores discutiram os tipos de EIP que deveriam ser incluídos na atualização ShangHai. O EIP3074 foi incluído na discussão, mas os desenvolvedores apenas sincronizaram brevemente o progresso do desenvolvimento do EIP3074. Vale a pena notar que, antes do início da reunião, a Nethermind escreveu o artigo Ethereum wallets today and tomorrow — EIP-3074 vs. ERC-4337, que não continha objeções ao EIP3074.
Na reunião #167 de 3 de agosto de 2023, os desenvolvedores principais mencionaram o EIP3074 ao discutir outro EIP5806. O EIP5806 é uma proposta que permite que EOA chamem contratos externos usando o método deleGate.io call durante o processo de transação. Essa proposta é, de certa forma, semelhante ao EIP7702. No entanto, os desenvolvedores principais também levantaram preocupações sobre a segurança dessa proposta, com Ansgar apontando que o EIP3074 não pôde ser incluído nas bifurcações duras devido a possíveis problemas de segurança, enquanto o EIP5806 é uma proposta mais radical.
Na reunião #182, realizada em 29 de fevereiro de 2024, os desenvolvedores discutiram em detalhes se o EIP3074 deveria ser incluído na atualização Pectra. Vitalik afirmou que qualquer padrão de abstração de conta deve ter as seguintes três funcionalidades:
Vitalik apontou que o EIP5806 pode ser uma escolha melhor do que o EIP3074. Andrew acredita que o EIP3074 é mais genérico em comparação com o EIP5806 e sugere a utilização do EIP3074. Vitalik refutou Andrew, argumentando que no futuro todas as carteiras podem ser carteiras inteligentes, e assim que isso acontecer, os códigos de operação pré-compilados introduzidos pelo EIP3074 se tornarão obsoletos. Yoav, como autor do ERC4337, fez uma longa declaração nesta reunião, e seu discurso incluiu principalmente:
Yova está mais inclinado a usar o EIP5806 como uma solução de abstração de conta.
Inside Meeting #183 em 14 de março de 2024, os principais desenvolvedores convidaram Dan Finlay, da MetaMask, para discutir o que a carteira pensa sobre EIP3074. Dan é a favor de EIP3074, observando que o MetaMask também apoiará os testes de EIP3074. A MetaMask acredita que EIP3074 pode permitir funcionalmente que a EOA aproveite todas as funcionalidades da abstração de contas. Em termos de segurança, a EIP3074 fornece uma solução para prestadores de serviços de carteira, ou seja, separação de chaves quentes e frias. O provedor de serviços de carteira pode manter a assinatura EIP3074 da EOA para iniciar uma transação, e os usuários podem usar a chave privada quente em transações normais, mas a chave privada fria pode ser mantida na carteira de hardware do usuário e, quando uma emergência é encontrada, o usuário pode usar a chave privada fria na carteira fria para iniciar uma transação para revogar a assinatura do EIP3074. Esta solução de separação de chaves privadas quentes e frias dá flexibilidade aos fornecedores de carteiras.
Vitalik apontou que, no EIP3074, os designers de carteiras devem projetar uma lógica de autorização rigorosa para evitar que a assinatura EIP3074 dos usuários seja abusada. Curiosamente, ao discutir a adição de suporte para EIP3074 no MetaMask, Vitalik sugeriu que se pode usar L2 como uma solução de transição, ou seja, qualquer nova modificação na camada de execução deve ser praticada primeiro no L2, pois o volume de fundos no L2 é limitado, e mesmo que ocorram problemas sérios, isso causaria perdas significativas.
Dror Tiros apontou na discussão que a melhor forma de garantir a segurança do EIP3074 é que a oficial do Ethereum forneça diretamente o contrato invoker. Mas Dan Finlay discorda da opinião de que o contrato deve ser fornecido oficialmente, Dan acredita que o contrato invoker deve ser totalmente decidido pelos usuários, e o mercado acabará escolhendo o contrato invoker mais seguro.
Ansgar ainda defende que a EIP3074 deve ter uma única assinatura correspondente a uma única transação, e que os provedores de carteira não devem reutilizar as assinaturas dos usuários para iniciar transações, mas Dan Finlay também expressou objeções. Dan Finlay acredita que a EIP3074 deve ser assinada por uma carteira fria, e então os provedores de carteira podem reutilizar essa assinatura para iniciar transações diretamente em nome do usuário; se for necessário que o usuário assine novamente a cada vez, isso pode levar ao uso múltiplo da chave privada fria. Isso não está de acordo com a ideia de separação de chaves frias e quentes.
Na reunião, os desenvolvedores principais discutiram outro tópico importante, que é a lista de inclusão. A lista de inclusão é uma forma de aumentar as propriedades de resistência à censura do Ethereum. Simplificando, a lista de inclusão permite que algumas transações sejam prometidas para serem incluídas diretamente no próximo bloco. No entanto, os desenvolvedores principais apontaram que o EIP3074 é incompatível com a lista de inclusão.
Na reunião #185, que ocorreu em 11 de abril de 2024, a maioria das implementações de clientes concordou em incluir o EIP3074 no hard fork Pectra, mas o Geth se opôs, alegando que o EIP3074 poderia causar problemas com as árvores Verkle. Danno também expressou objeções, pois o EIP3074 poderia levar à reutilização de assinaturas. Yoav também se opôs, apresentando um plano para atacar o pool de memória usando EIP3074 e transações Blob. Resumidamente, um atacante poderia iniciar um grande número de transações Blob, todas contendo uma quantidade significativa de dados, e então usar o EIP3074 para invalidar todas essas transações Blob.
Em resumo, na reunião, todos os desenvolvedores de clientes concordaram que o EIP3074 seria incluído na atualização final.
Na reunião #187 de 9 de maio de 2024, os desenvolvedores principais discutiram pela primeira vez a questão da substituição do EIP7702 pelo EIP3074. O EIP7702 foi concluído 90 minutos antes do início da reunião dos desenvolvedores principais, onde foi reconhecido que o EIP7702 é um padrão superior ao EIP3074. Não houve vozes contrárias ao EIP7702 durante a reunião, apenas alguns pesquisadores expressaram a opinião de que o EIP7702 também possui atributos de irreversibilidade semelhantes ao EIP3074, o que pode levar a problemas de segurança dos fundos.
Na reunião #188, realizada em 23 de maio de 2024, os desenvolvedores principais discutiram a possibilidade de substituir o EIP7702 pelo EIP3074. A conclusão final da reunião foi usar o EIP7702 para substituir o EIP3074 como padrão de abstração de contas no hard fork do Pectra. Vitalik apontou que o EIP7702 também possui algumas propriedades de irreversibilidade que são consistentes com o EIP3074, e essas propriedades já foram amplamente discutidas durante a discussão do EIP3074. Curiosamente, houve uma grande participação de representantes do ERC4337 na reunião.
Na verdade, a discussão sobre a substituição do EIP3074 pelo EIP7702 já havia sido amplamente debatida antes da 188ª reunião dos desenvolvedores principais, e o resultado da discussão foi que o 3074 seria substituído, portanto, não houve muita controvérsia na reunião dos desenvolvedores principais.
Roteiro e Decisão
A infraestrutura central da abstração de contas, Zerodev, publicou um artigo interessante ao saber que o EIP3074 seria substituído. O título do artigo é "Reflections on Ethereum Governance Following the 3074 Saga". A conclusão do artigo é que o EIP7702 é uma boa proposta que pode beneficiar todos os usuários. No entanto, o processo de governança do EIP7702 que substitui o EIP3074 não é o melhor, por razões que incluem:
A Zerodev acredita que o melhor caminho de governança deve ser a participação ampla da comunidade ERC4337 e a expressão das suas opiniões durante o longo processo de discussão dos desenvolvedores principais do EIP3074.
EIP3074 desenvolvedores acreditam que ERC4337 devem ser responsabilizados por falhas de governança. Porque EIP3074 tem estado ativamente envolvido na governança nos últimos anos, e se comunicou com Yova, o principal desenvolvedor do ERC4337, muitas vezes.
A comunidade ERC4337 acredita que o EIP3074 deve ser o principal responsável pelo fracasso da governança. Os membros da comunidade ERC4337 acreditam que Yova, como desenvolvedor principal do ERC4337, expressou sua oposição ao EIP3074 em várias reuniões de desenvolvedores principais, mas os desenvolvedores principais parecem não ter ouvido suas opiniões. A maioria dos membros da comunidade ERC4337 não acompanhou a dinâmica de governança do EIP3074, e a maioria acredita que o EIP3074 é um padrão morto. A comunidade ERC4337 também acredita que os desenvolvedores principais não se comunicaram de forma ativa com a comunidade ERC4337.
EIP3074 e ERC4337 acreditam que realizaram um trabalho de governança correto, enquanto a outra parte deve ser a principal responsável pelo fracasso da governança. É evidente que existe uma razão mais profunda a atuar neste processo de governança.
De forma simples, a razão mais profunda na verdade é o roteiro do Ethereum. O roteiro do Ethereum tem uma autoridade superior às reuniões dos desenvolvedores principais. O roteiro da abstração de contas é centrado no ERC4337. O EIP7702 é totalmente compatível com o padrão ERC4337, mas o EIP3074 não é totalmente compatível com o padrão ERC4337. Portanto, do ponto de vista do roteiro do Ethereum, a substituição do EIP3074 é algo que certamente acontecerá.
Claro, o roteiro do Ethereum é uma demonstração pessoal da visão futura do Ethereum por Vitalik. Se ocorrer uma séria discussão durante o processo de governança do Ethereum, Vitalik, como o definidor do roteiro, terá a palavra final. E foi exatamente o julgamento de Vitalik que levou à substituição do EIP3074.
O modelo de governança do Ethereum é o modelo values ⇒ vision ⇒ roadmaps ⇒ clients, ou simplesmente o modelo VVRC. O seu processo de governança é o seguinte:
O processo acima é o verdadeiro processo de governança do Ethereum. Podemos ver que a visão pessoal de Vitalik está na parte inferior do modelo de governança do Ethereum, portanto, uma vez que surjam sérias disputas na implementação do cliente, a opinião pessoal de Vitalik será o julgamento final.
> > Referência > > >Introdução ao ZeroDev > > > nulo > > >
> > > Introdução ao ZeroDev > > > null > > > > > > Notas sobre o roteiro de Abstração de Conta - HackMD > > > # Notas sobre o roteiro de Abstração de Conta *Agradecimentos especiais a Vitalik e à equipe de AA pelo feedback > > > > > >