Análise aprofundada da evolução e futuro da abstração de contas Ethereum

Introdução

Este artigo é dividido em duas grandes partes:

A primeira parte parte da proposta inicial de abstração de contas de 2015, sistematizando o conteúdo das principais propostas de EIP até hoje, revisitando a evolução histórica das soluções de abstração de contas e avaliando as vantagens e desvantagens de cada uma.

A segunda parte foca na comparação da fraca reação do mercado após o lançamento do EIP4337 e analisa em profundidade o EIP7702, que será incluído na próxima atualização da Ethereum. Assim que esta proposta for integrada, mudará fundamentalmente a forma das aplicações na cadeia.

EIP-7702 como uma revolução histórica, vamos discutir detalhadamente seu conteúdo.

1. A background da abstração de contas

1.1 localização da abstração de contas

O fundador do Ethereum, Vitalik, atualizou novamente o roteiro de desenvolvimento do ETH no final de 2023, mas a definição de abstração de contas não mudou. Atualmente, o principal caminho de desenvolvimento é a conversão EOA voluntária a partir do EIP-4337 ( Voluntary EOA Conversion ).

1.2 O estado atual do mercado de abstração de contas

Após um ano e meio de desenvolvimento, o número total de endereços do EIP4337 nas principais blockchains é apenas de 12 milhões, dos quais apenas 6.764 são endereços ativos na mainnet do Ethereum, o que está longe do número de endereços EOA e CA. O número de endereços independentes na mainnet do Ethereum já atingiu 270 milhões, pode-se dizer que o EIP4337 não teve quase nenhum desenvolvimento substancial na mainnet.

No entanto, isso não afeta o valor essencial da AA. O objetivo do design do EIP4337 é resolver o problema de compatibilidade para frente da mainnet, portanto, houve um crescimento explosivo em várias L2 chains que suportam nativamente a AA. Por exemplo, o número de usuários ativos mensais na cadeia Base e na cadeia Polygon atingiu 1 milhão e 3 milhões em julho, apresentando um desempenho notável.

Portanto, o design do EIP4337 não está errado, ele possui muitas vantagens. A situação atual é principalmente causada pelas diferenças entre a mainnet e o L2, que precisam adotar soluções adequadas a cada uma.

2. O que é a abstração de contas?

A abstração de contas é essencialmente uma solução para o problema da separação da propriedade.

Na arquitetura da Máquina Virtual Ethereum ( EVM ), existem dois tipos de contas: conta externa ( EOA ) e conta de contrato ( Contract Account ). Na conta externa, a propriedade e o direito de assinatura são, na verdade, detidos pela mesma entidade. A pessoa que possui a chave privada não só possui a "propriedade" da conta, mas também tem o direito de "assinar a transferência de todos os ativos".

Isto é determinado pela estrutura de transação da conta Ethereum. A partir da estrutura de transação, pode-se ver que a transação padrão do Ethereum na verdade não possui o campo From. Então, como é determinado o endereço de saída de uma transferência de fundos? Na verdade, é feito através do parâmetro VRS (, ou seja, o usuário assina ) e a partir daí deduz-se o endereço From.

Isso envolve conceitos como criptografia assimétrica, como ECDSA, e funções de limiar unidirecionais, que não serão abordados aqui. Em suma, esse mecanismo garante a segurança por meio da criptografia, mas também levou à atual dificuldade de consolidação da propriedade do endereço EOA.

E o papel central do EIP4337 é adicionar o Endereço do Remetente no campo da transação, permitindo assim a separação entre a chave privada e o endereço a ser operado.

A razão pela qual a separação de propriedade é tão importante é que o design da conta externa (EOA) gerará mais problemas:

1. Difícil proteção da chave privada: a perda da chave privada (, ataques de hackers ou quebra criptográfica ) significa a perda de todos os ativos.

2. Algoritmo de assinatura único: o protocolo nativo só pode usar o algoritmo de assinatura e verificação ECDSA ao validar transações.

3. Permissão de assinatura muito alta: não suporta assinatura múltipla nativa ( a assinatura múltipla só pode ser realizada através de contratos inteligentes ), uma única assinatura pode executar qualquer operação.

4. A taxa de transação só pode ser paga em Éter, não suporta transações em massa.

5. Divulgação de privacidade de transações: transações um a um podem expor informações privadas dos titulares de contas.

Essas restrições tornam difícil para os usuários comuns utilizarem o Ethereum:

Primeiro, ao usar qualquer aplicação na Ethereum, os usuários devem possuir Éter ( e assumir o risco de volatilidade do seu preço ).

Além disso, os usuários precisam lidar com a lógica complexa de taxas, preço do Gas, limite do Gas, bloqueio de transações ( ordem do Nonce ) e outros conceitos que são demasiado complexos para os usuários.

Por fim, apesar de muitas carteiras ou aplicações de blockchain tentarem melhorar a experiência do usuário através da otimização do produto, os resultados são limitados.

Portanto, a solução reside na implementação da abstração de contas, desacoplando a propriedade (Owner) e o direito de assinatura (Signer), permitindo assim a resolução gradual dos problemas mencionados acima.

Ao longo da história, foram propostas várias soluções, que foram finalmente resumidas em duas principais direções.

3. Contexto das propostas históricas de abstração de contas

A solução para o problema parece ter várias propostas de EIP, mas no fundo há apenas duas ideias centrais. Cada problema considerado por um EIP que não foi aprovado contribuiu para os pontos de ruptura das soluções existentes.

( 3.1 Primeiro caminho: transformar o endereço EOA em endereço CA

Em 15 de novembro de 2015, em torno do EIP-101, Vitalik propôs uma nova estrutura de conta baseada em contratos. As principais mudanças incluem:

• Mudar o endereço para apenas código e espaço de armazenamento
• Alterar o suporte a taxas, permitindo o pagamento em tokens ERC20
• Através de contratos pré-compilados, transformar tokens nativos em tokens do tipo ERC20, com funcionalidades como autorização de dedução.
• Reduza os campos da transação para to, startgas, data e code

Esta proposta pode ser considerada uma revolução, pois irá alterar significativamente o design subjacente, fazendo com que cada endereço de conta tenha sua própria lógica de "código" ), que é exatamente o efeito que o EIP-7702 pretende alcançar ###.

Ele também pode derivar outras funções, como:

1. Permitir que as transações utilizem mais algoritmos de criptografia, podendo ser o método de verificação e autenticação especificado pelo código interno de cada endereço.

2. Possui características de resistência a ataques quânticos, pois o código pode ser atualizado.

3. Permitir que o Éter tenha características funcionais consistentes com os contratos ERC20, sendo o efeito principal a realização da autorização de dedução, sem consumir a moeda nativa.

4. Aumentar o espaço de personalização da conta, compatível com recuperação social, suporte a SBT, recuperação de chaves e outras funcionalidades

A razão pela qual este plano não foi continuado é muito simples: o passo foi grande demais. As preocupações em relação ao problema de colisão de hash de transação e às vulnerabilidades de segurança na época não foram devidamente consideradas, por isso foi sempre adiado. No entanto, cada um dos conceitos positivos tornou-se uma das funcionalidades centrais das posteriores EIP4337 e EIP7702.

Depois, houve uma série de EIPs que tentaram aperfeiçoar essa lógica:

EIP-859: abstração de contas da cadeia principal (2018-01-30)

Tentar resolver o problema de implantação do Code. A função principal é: se o contrato da parte transacionadora não estiver implantado, então utilizar o parâmetro code anexado à transação para executar a implantação da carteira do contrato. Além disso, foi proposto um novo opcode PAYGAS, que, além de pagar gas, também se torna um delimitador entre a parte de verificação e a parte de execução nos parâmetros da transação.

Embora não tenha sido alcançado na época, isso se tornou uma das lógicas centrais do EIP7702 atualmente. Cada transação do EIP7702, combinada com uma estrutura de transação especial, pode incluir um certo código, permitindo que o endereço EOA tenha habilidades de contrato nesta transação.

EIP-7702: definir código de conta EOA (2024-05-07)

Este é também o núcleo da discussão subsequente deste artigo, apresentado por Vitalik, como uma alternativa ao EIP-3074. Assim, o EIP-3074 foi descontinuado, e o EIP-7702 foi determinado para ser incluído no próximo hard fork ETH Prague/Electra(Pectra), cujos detalhes serão elaborados a seguir.

( 3.2 Segunda rota: permitir que o endereço EOA dirija o endereço CA

EIP-3074: adicionar os códigos de operação AUTH e AUTHCALL )2020-10-15###

Adicionar dois novos códigos de operação AUTH e AUTHCALL no EVM, permitindo que EOA autorize contratos a chamar outros contratos em vez da identidade de EOA através desses dois códigos de operação.

Em resumo, um EOA pode enviar uma mensagem assinada ( para um contrato de confiança ) chamado Invoker (. Este contrato Invoker pode usar os códigos de operação AUTH e AUTHCALL para enviar transações em nome desse EOA.

EIP-4337: implementar a abstração de contas com o pool de memórias de transação )2021-09-29(

Esta proposta foi desenhada com base na inspiração do MEV, tendo como valor central a completa evitação de alterações no protocolo da camada de consenso.

A EIP4337 propôs um novo objeto de transação chamado UserOperation, que os usuários enviam para o pool de memórias, e os bundlers, a partir da dimensão dos mineradores, agrupam em massa para entregar a execução de transações de contratos, essencialmente trazendo as transações subjacentes e a operação de contas para serem executadas a nível de contrato.

EIP-5189: operar contas abstratas através de endossantes )2022-06-29(

Isto pode ser visto como uma otimização da lógica do EIP4337, através da criação de um mecanismo de endosse de multa de fundos )endorser( para prevenir ataques de bloqueio DoS de Bundlers maliciosos.

) 3.3 Outras propostas para apoiar a abstração de contas

EIP-2718: embalagem de novo tipo de transação (2020-06-13)

Esta é uma proposta já finalizada, que define um novo tipo de transação, como um envelope para futuros tipos de transação a serem adicionados.

O efeito final é que, ao introduzir um novo tipo de transação, é possível distinguir diferentes transações através de uma codificação específica, permitindo que elas tenham apenas compatibilidade retroativa, sem a necessidade de compatibilidade para frente. O exemplo mais comum é o EIP1559, que distingue as taxas de transação, utilizando uma nova codificação de tipo de transação, sem afetar o tipo de transação legacy original.

EIP-3607: proibição de endereços EOA de implantar contratos ###2021-06-10(

Este é um plano suplementar na rota AA, destinado a evitar conflitos entre o endereço de implantação de contratos e o endereço EOA. Ele controlará o método de geração de contratos, não permitindo que o sistema implante código em endereços que já são endereços EOA. Este risco é, na verdade, muito pequeno, já que os endereços Ethereum têm 160 bits de comprimento; embora exista um método para colidir a chave privada para gerar a chave privada de um endereço de contrato específico, estima-se que com o poder computacional total da rede Bitcoin, ainda levaria um ano.

) 3.4 Como entender a evolução da abstração de contas?

Primeiro, é necessário entender o valor após a conversão para CA.

Basicamente, é o efeito prático do EIP-4337, que pode realizar:

• recuperação social
• transações sem gas
• Transação em lote
• regras baseadas no tempo
• Multassinado
• Pagamento baseado em regras

No entanto, a principal desvantagem do EIP-4337 é que viola o princípio da motivação humana.

Parece melhor, mas caiu em um ciclo vicioso de desenvolvimento do mercado: muitos Dapps ainda não são compatíveis, levando os usuários a não quererem usar endereços CA. Até mesmo o uso de CA pode resultar em custos de transação mais altos ( em cenários de transferência comuns, as taxas de transação podem dobrar ), e depende demais da compatibilidade do próprio Dapp.

Portanto, ainda não se popularizou na rede principal do Ethereum.

O custo é o critério de avaliação mais importante para os usuários, e deve ser reduzido.

Mas para realmente reduzir o GAS, é necessário realizar uma atualização de soft fork no próprio Ethereum, modificando o cálculo de GAS ou os módulos de consumo de GAS dos códigos de operação. Uma vez que é necessário um soft fork, por que não considerar diretamente o EIP-7702?

![Análise profunda da abstração de contas do Ethereum: passado e futuro]###https://img-cdn.gateio.im/webp-social/moments-65d1ef9656425666ee30c38bbb63e769.webp(

4. Análise abrangente do EIP-7702

) 4.1 O que é EIP-7702

Ele distingue-se através de um novo tipo de transação, permitindo que uma EOA possua temporariamente as funcionalidades de um contrato inteligente em uma única transação, suportando assim transações em lote, transações sem Gas e gestão de permissões personalizada, sem a necessidade de introduzir um novo código de operação EVM ( que afete a compatibilidade para a frente ).

Isso permite que os usuários obtenham a maioria das capacidades de AA sem implantar contratos inteligentes, e ainda pode oferecer a capacidade de terceiros iniciarem transações em nome dos usuários, sem que seja necessário fornecer a chave privada, apenas assinando a informação de autorização.

4.2 estrutura de dados

Ele define um novo tipo de transação 0x04, cujo TransactionPayload é o resultado da serialização RLP do seguinte conteúdo:

rlp([ chain_id, // ID da cadeia, usado para prevenir ataques de repetição nonce, // contador de transações, garante a exclusividade da transação max_priority_fee_per_gas, // taxa de transação 1559 max_fee_per_gas, // taxa de transação 1559 gas_limit, destino, // endereço de destino da transação valor, dados, access_list, // lista de acesso, usada para otimização de Gas no EIP-2929 lista_de_autorização, signature_y_parity, // 3 parâmetros de assinatura, usados para verificar a assinatura da transação signature_r, signature_s ])

É importante notar que foi adicionado um objeto authorization_list, que armazena o código que os signatários desejam executar em sua EOA. O usuário assina a transação ao mesmo tempo que assina o código do contrato a ser executado, que existe como uma lista bidimensional, indicando que pode