Análise profunda do passado e futuro da abstração de contas do Ethereum

Introdução

Este artigo é dividido em dois grandes módulos:

A parte superior parte da primeira proposta de AA de 2015, organizando o conteúdo principal das propostas de EIP até agora, explorando a evolução das propostas históricas de AA e avaliando de forma abrangente as vantagens e desvantagens de cada solução.

A parte inferior foca na comparação da fraca reação do mercado após o lançamento do EIP4337, analisando profundamente o EIP7702, que será incluído na próxima atualização do Ethereum; esta proposta, uma vez integrada, mudará completamente a forma das aplicações na cadeia.

O EIP-7702 tem um significado revolucionário, vamos entender isso em detalhes.

1. O contexto da abstração de contas

1.1 a localização do significado da abstração de contas

O fundador do Ethereum, Vitalik, atualizou novamente o roteiro do ETH no final de 2023, mas não fez alterações na definição da abstração de contas. Atualmente, o modelo predominante está mudando do EIP-4337 para a próxima fase "conversão voluntária de contas EOA".

Mais de um ano após o lançamento do EIP4337, em 1 de março de 2023, na WalletCon em Denver, o contrato central ERC-4337, desenvolvido por desenvolvedores da Fundação Ethereum, foi auditado pela OpenZeppelin e considerado oficialmente lançado (, sempre recebendo amplo reconhecimento dos usuários, mas não sendo amplamente utilizado. Nesse ambiente de mercado contraditório, o progresso do EIP-7702 foi adiantado significativamente e já foi confirmado que será fundido na próxima atualização.

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

Após um ano e meio de desenvolvimento, o EIP4337 possui apenas 12 milhões de endereços em cadeias principais, dos quais apenas 6.764 são endereços ativos na rede principal do Ethereum, uma diferença significativa em relação ao número de endereços EOA e CA. O número de endereços únicos na rede principal do Ethereum já alcançou 270 milhões, pode-se dizer que o EIP4337 não teve desenvolvimento substancial na rede principal.

No entanto, isso não afeta o valor essencial do AA. O design do EIP4337, desde o início, estava destinado a não resolver o problema de compatibilidade retroativa da mainnet. Com a incorporação nativa do AA em vários L2, o número de endereços EIP4337 explodiu nos L2, com a Base e a Polygon alcançando 1 milhão e 3 milhões de usuários ativos mensais em julho, o que é bastante considerável.

Portanto, não é que o design do EIP4337 esteja errado, ele tem muitas vantagens. A situação atual decorre das diferenças entre a mainnet e o L2, que precisam de soluções adequadas a cada uma.

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

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

A abstração de contas resolve essencialmente o problema da separação de propriedade.

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

Isso é determinado pela estrutura de transação da conta Ethereum. Em uma transação padrão, na verdade, não existe o campo From; a transferência de fundos é extraída a partir do endereço From através da assinatura do usuário com os parâmetros VRS ) (. Isso envolve conceitos como ECDSA e funções de limiar unidirecionais, garantidos pela segurança criptográfica, o que também resulta na situação atual de fusão de propriedades de endereços EOA.

O efeito central do EIP4337 é adicionar o Endereço do Remetente no campo da transação, separando assim a chave privada do endereço sendo operado.

A separação de propriedade é importante porque as contas externas )EOA( geram mais problemas no design:

1. Difícil proteger a chave privada: perder a chave privada significa perder todos os ativos.
2. Algoritmo de assinatura único: a verificação de transações do protocolo nativo só pode usar o algoritmo ECDSA.
3. Permissões de assinatura excessivas: sem multiassinatura nativa, uma única assinatura pode executar qualquer operação.
4. As taxas de transação só podem ser pagas em ETH, não suportam transações em lote.
5. Vazamento de privacidade de transações: as transações um a um facilitam a análise das informações pessoais dos titulares de contas.

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

Primeiro, ao usar qualquer aplicativo Ethereum, é necessário ter ETH e assumir o risco de volatilidade de preços.

Em segundo lugar, 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.

Por fim, embora muitas carteiras ou aplicações de blockchain tentem melhorar a experiência do usuário através da otimização de produtos, o efeito real é muito limitado.

Portanto, a solução reside na implementação da abstração de contas, desacoplando a propriedade )Owner( e o direito de assinatura )Signer(, resolvendo assim os problemas mencionados um a um.

Historicamente, houve várias propostas, que acabaram convergindo para duas rotas.

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

3. Revisão do contexto das propostas de abstração de contas

As soluções para o problema parecem ter várias propostas de EIP, mas no fundo existem apenas duas abordagens centrais. Cada EIP não aprovado reúne questões que se tornaram pontos de ruptura das soluções existentes.

) 3.1 Primeira rota: transformar o endereço EOA em endereço CA

No dia 15 de novembro de 2015, Vitalik propôs uma nova estrutura de conta como contrato no EIP-101. A mudança do endereço para apenas código e espaço de armazenamento, alteração do suporte a taxas para pagamento em ERC20, através de contratos pré-compilados, transformou tokens nativos em saldo semelhante ao ERC20 com a funcionalidade de autorização de dedução, e simplificou os campos de transação para to, startgas, data e code.

Esta é uma transformação ao estilo do Grande Salto Adiante, que fará alterações significativas no design subjacente, permitindo que cada endereço de conta tenha sua própria lógica de "código". ### é exatamente o efeito que o EIP-7702 pretende alcançar. (.

pode ainda derivar outras funcionalidades, como:

1. Transações usam mais algoritmos de criptografia, cada endereço interno tem um código que especifica o método de verificação e autenticação.
2. Possuir características de resistência a ataques quânticos, código pode ser atualizado
3. A moeda Éter possui funcionalidade consistente com contratos ERC20, com efeitos centrais como autorização de dedução, sem necessidade de desgaste da moeda nativa.
4. Melhorar o espaço de personalização da conta, compatível com recuperação social, suporte SBT, recuperação de chaves, entre outros.

A razão para não continuar é simples: o passo foi grande demais, e a consideração inadequada dos problemas de conflito de hash de transação atuais e das questões de segurança levou à suspensão. No entanto, cada conceito positivo tornou-se uma das funções centrais das EIP4337 e EIP7702 subsequentes.

Mais tarde, 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(

Tentativa de resolver o problema de implantação do código, a função principal é que se o contrato da parte transacionadora não estiver implantado, então usa-se o parâmetro code anexo à transação para executar a implantação da carteira do contrato. Também foi proposto um novo opcode PAYGAS, que além de pagar o gas, também se tornou um delimitador entre a parte de verificação e a parte de execução nos parâmetros da transação.

Embora tenha terminado sem resultados na época, tornou-se uma das lógicas centrais do atual EIP7702. Cada transação do EIP7702, combinando uma estrutura de transação especial, pode incluir um determinado código, permitindo que o endereço EOA tenha capacidades de contrato nesta transação.

EIP-7702: configurar código da conta EOA )2024-05-07(

Este é o núcleo do mecanismo discutido posteriormente neste artigo, apresentado por Vitalik como uma alternativa ao EIP-3074. Assim, o EIP-3074 foi descontinuado, e o EIP-7702 está definido para ser incluído no próximo fork hard ETH Prague/Electra)Pectra(.

) 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 OpCodes no EVM: AUTH e AUTHCALL, permitindo que EOA autorize contratos a chamar outros contratos em vez de usar a identidade EOA.

Em resumo, um EOA pode enviar uma mensagem assinada ### transação ( para um contrato confiável ) chamado Invoker (, este contrato Invoker pode usar os códigos de operação AUTH e AUTHCALL para substituir o EOA na emissão de transações.

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

Inspirado pelo MEV, o valor central é evitar completamente alterações no protocolo da camada de consenso.

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

EIP-5189: através de endossantes, operação de abstração de contas )2022-06-29(

Otimizou a lógica do EIP4337, enfrentando Bundlers maliciosos através do estabelecimento de um mecanismo de penalização de fundos para endossadores, prevenindo ataques de bloqueio DoS.

) 3.3 Outras propostas que suportam a abstração de contas

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

Proposta já Finalizada, define um novo tipo de transação como o envelope para futuros tipos de transação a serem adicionados.

O efeito final é que, ao introduzir um novo tipo de transação, é feito uma distinção através de uma codificação específica, apenas precisa ser retrocompatível, não precisa ser compatível para a frente. O exemplo mais comum é o EIP1559, que diferencia as taxas de transação, utilizando uma codificação de novo tipo de transação, sem afetar o tipo de transação legacy original.

EIP-3607: tornar o endereço EOA incapaz de implantar contratos ###2021-06-10(

Solução adicional no caminho AA, para evitar conflitos entre o endereço de implantação do contrato e o endereço EOA. Controlar o método de geração de contratos, o sistema não permite que o código seja implantado em um endereço que já é um endereço EOA. Este risco é muito baixo, o endereço Ethereum tem 160 bits de comprimento, embora exista um método para colidir a chave privada para gerar a chave privada do endereço de contrato específico, estima-se que, mesmo com toda a capacidade de cálculo do Bitcoin, 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:

1. Pagamento de gas com qualquer token
2. Transações em lote
3. Programabilidade da assinatura
4. A lógica da carteira pode ser atualizada
5. Multisig e recuperação social
6. Transações sem gas
7. Pagamento de gas programável

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

Parece melhor, mas caiu em um ciclo vicioso de desenvolvimento do mercado. Muitos Dapps não são compatíveis, os usuários não estão dispostos a usar endereços CA, usar CA pode até ter custos de transação mais altos ( em cenários de transferência comuns, as taxas de transação dobram ), e depende demais da compatibilidade do próprio Dapp.

Portanto, até agora, não foi amplamente adotado na rede principal Ethereum.

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

Mas para realmente reduzir o GAS, é necessário que o próprio Ethereum passe por uma atualização de soft fork, modificando o cálculo de GAS ou alterando módulos como o consumo de GAS dos códigos de operação. Já que vamos fazer um soft fork, por que não considerar diretamente o EIP-7702?

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

4. Análise completa do EIP-7702

) 4.1 O que é EIP-7702

Através de um novo tipo de transação, permite que EOA possua temporariamente funcionalidades de contrato inteligente em uma única transação, suportando assim transações em lote, transações sem Gas e gestão de permissões personalizadas, sem a necessidade de introduzir um novo opCode EVM ( que afete a compatibilidade retroativa ).

pode permitir que os usuários obtenham a maior parte das capacidades de AA sem a necessidade de implementar contratos inteligentes, e até mesmo fornecer a capacidade de iniciar transações em nome dos usuários por terceiros, sem que os usuários precisem fornecer a chave privada, apenas exigindo a assinatura da informação de autorização.

4.2 estrutura de dados

Definir um novo tipo de transação 0x04, onde o tipo de transação TransactionPayload é o resultado da serialização RLP do conteúdo a seguir:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

É importante adicionar o objeto authorization_list, que armazena o código que o signatário deseja executar em sua EOA. O usuário assina a transação ao mesmo tempo que assina o código do contrato a ser executado, existindo como uma lista bidimensional, indicando que é possível armazenar várias informações de operação em lote e executar operações em lote.

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

4.3 ciclo de vida da transação

(# 4.3.1 fase de verificação

Executar a fase de início da transação, para cada tupla [chain_id, address, nonce, y_parity, r, s] da authorization_list:

1. A partir da assinatura r, s, utiliza-se o ecrecover para recuperar o endereço do signatário ), o mecanismo do próprio Ethereum, esta EIP não alterou o algoritmo de assinatura ###.
2. Verificar o ID da cadeia ### para evitar a reprodução de cadeia de bifurcação (.
3. Verifique se o código do signatário authority está vazio ou já delegado ) para validar se a transação é uma transação válida 7702, e posteriormente execute a transação ( por meio do mecanismo de delegação.
4. Verificar o nonce do assinante authority ) para evitar a repetição da assinatura authority (.
5. Definir o código do signatário authority para 0xef0100 || address) para contornar a estratégia de prevenção de colisões EIP3607(.
6. Aumentar o nonce do signatário authority ) para prevenir a reprodução de assinaturas locais (.
7. Adicione a conta do signatário authority à lista de endereços acessados ) para o endereço quente, reduzindo a taxa de gás de armazenamento de consulta (.

)# 4.3.2 Fase de Execução da Operação