Análise aprofundada do passado e futuro da abstração de conta Ethereum

Este artigo está dividido em duas partes:

Primeiro, começando com a primeira proposta AA de 2015, o sistema revisa os principais conteúdos das propostas EIP até agora, revisitando a história das propostas AA e avaliando de forma abrangente as vantagens e desvantagens de cada plano.

Em segundo lugar, é importante comparar o feedback negativo do mercado enfrentado após a proposta do EIP4337, analisando profundamente o EIP7702, que será incluído na próxima atualização do Ethereum; uma vez integrado, esta proposta mudará completamente a forma das aplicações em cadeia.

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

1. Background da abstração de conta

1.1 A importância da abstração da conta

O fundador do Ethereum, Vitalik, atualizou novamente o roteiro de desenvolvimento do ETH no final de 2023, mas a posição sobre a abstração de contas não mudou. O modelo principal atual está a transitar do EIP-4337 para a próxima fase de conversão voluntária de contas EOA.

Desde o lançamento do EIP4337 há mais de um ano, o ( foi oficialmente apresentado a 1 de março de 2023 na WalletCon em Denver, recebendo amplo reconhecimento por parte dos utilizadores, mas ainda não sendo amplamente utilizado. Neste ambiente de mercado contraditório, o progresso do EIP-7702 foi significativamente antecipado, e já foi confirmado que será integrado na próxima atualização.

) 1.2 estado atual do mercado de abstração de conta

Após um ano e meio de desenvolvimento, o EIP4337 possui apenas 12 milhões de endereços nas blockchains principais, dos quais apenas 6.764 estão ativos na rede principal do Ethereum, muito abaixo do número de endereços EOA e CA. O número de endereços independentes na rede principal do Ethereum já atingiu 270 milhões, podendo-se dizer que o EIP4337 não teve praticamente nenhum 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 ter dificuldades em resolver bem o problema de compatibilidade para frente da mainnet. Com a incorporação nativa do AA em vários L2, o número de endereços EIP4337 obteve uma explosão em L2, com os usuários ativos em julho nas cadeias Base e Polygon atingindo 1 milhão e 3 milhões, respectivamente, o que é bastante considerável.

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

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

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

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

Na máquina virtual Ethereum)EVM( existem dois tipos de contas: conta externa)EOA( e conta de contrato)CA(. A propriedade e o direito de assinatura da EOA são, na verdade, detidos pelo mesmo sujeito. A pessoa que possui a chave privada não apenas 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. Na estrutura de transação padrão, não há o campo From; a transferência de fundos é realizada através do parâmetro VRS ), onde a assinatura do usuário ( é utilizada para decifrar o endereço From. Isso causa a atual dificuldade de fusão de propriedade dos 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 de operação.

A importância da separação de propriedade reside em:

1. Dificuldade em 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 múltiplas assinaturas nativas, 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. Vazamento de privacidade da transação: transações um a um facilitam a análise das informações do titular da conta.

Estas restrições tornam difícil para os utilizadores comuns usarem Ethereum:

• É necessário possuir ETH e assumir o risco de volatilidade de preços ao usar qualquer aplicativo.
• É necessário lidar com uma lógica de taxas complexa, os conceitos de preço do gás, limite do gás, nonce, etc. são demasiado complexos.
• Embora a aplicação de carteira tente otimizar a experiência do utilizador, os resultados são limitados.

Portanto, a chave para a solução está na realização da abstração da conta, desacoplando a propriedade )Owner( e o direito de assinatura )Signer(, resolvendo assim gradualmente os problemas mencionados.

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

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

3. Contextualização da Proposta Histórica AA

A solução para o problema parece ter muitas propostas de EIP, mas no fundo, são apenas duas linhas de pensamento principais. Cada EIP não aprovado considerou questões que acabaram por convergir nas soluções existentes.

) 3.1 A primeira rota: converter o endereço EOA em endereço CA

No dia 15 de novembro de 2015, Vitalik propôs uma nova estrutura de contas como contratos no EIP-101. A mudança de endereço para conter apenas código e espaço de armazenamento, suportando o pagamento de taxas com ERC20, através de contratos pré-compilados, transforma o token nativo em um tipo de ERC20 para manter saldo, reduzindo os campos da transação para apenas to, startgas, data e code.

Esta é uma transformação de grande avanço, que mudará significativamente o 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 também derivar outras funcionalidades:

1. As transações utilizam mais algoritmos criptográficos, especificados pelo método de verificação de assinatura interno do endereço.
2. Possui características de resistência a ataques quânticos, pois o código pode ser atualizado.
3. Fazer com que o Éter tenha funcionalidades consistentes com o ERC20, como a autorização de dedução.
4. Aumentar o espaço de personalização da conta, compatível com recuperação social, suporte SBT, recuperação de chaves, etc.

A razão pela qual não foi continuado é muito simples, é evidente que o passo foi grande demais, e a consideração dos problemas de colisão de hash nas transações atuais e das questões de segurança não foi adequada, por isso foi sempre adiado. Mas cada conceito positivo se tornou uma das funcionalidades centrais das EIPs 4337 e 7702.

Depois houve uma série de EIPs que tentaram aprimorar essa lógica:

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

Tentativa de resolver problemas de implantação de código. Se o contrato da parte transacionadora não estiver implantado, utilize o parâmetro code anexado à transação para executar a implantação da carteira do contrato. Também foi proposto um novo código de operação PAYGAS, que além de pagar o gás, também serve como delimitador entre a parte de verificação e a parte de execução nos parâmetros da transação.

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

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

Este é o EIP central que será discutido mais adiante no artigo, apresentado por Vitalik como uma alternativa ao EIP-3074. O EIP-3074 foi abandonado e o EIP-7702 está confirmado para ser incluído na próxima bifurcação dura ETH Prague/Electra.

) 3.2 Segunda rota: permitir que o endereço EOA conduza o endereço CA

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

Adicionar duas novas OpCodes no EVM: AUTH e AUTHCALL, permitindo que EOA autorize contratos a chamar outros contratos em vez de usar a identidade EOA.

Resumidamente, um EOA pode enviar uma mensagem assinada ) transação ( para um contrato ) em que confia, chamado de Invoker (. O contrato Invoker pode usar AUTH e AUTHCALL para emitir transações em vez do EOA.

EIP-4337: implementar abstração de conta usando o pool de memórias de transação )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 o pool de memória, onde os bundlers empacotam em massa e entregam as transações de execução do contrato a partir da perspectiva dos mineradores, essencialmente elevando as transações subjacentes e a operação da conta para serem executadas a nível de contrato.

EIP-5189: Operação de conta abstrata através de endossantes )2022-06-29(

Otimizou a lógica do EIP4337, estabelecendo um mecanismo de endossante de multa de fundos ) para prevenir ataques DoS maliciosos de Bundler.

( 3.3 Outras propostas que suportam AA

EIP-2718: Envelope de nova tipo de transação )2020-06-13###

A proposta já finalizada define um novo tipo de transação como um envelope para novos tipos de transações futuras.

Ao introduzir um novo tipo de transação, a distinção é feita através de codificação específica, apenas precisando ser compatível com versões anteriores e não com versões futuras. 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: Proibir endereços EOA de implantar contratos (2021-06-10)

Solução complementar 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, não permitindo que o código seja implantado em um endereço que já seja EOA. Esse risco é muito pequeno, o endereço Ethereum tem 160 bits de comprimento, embora exista um método para colidir a chave privada para obter a chave privada do endereço do contrato especificado, mas com a totalidade da capacidade de cálculo do Bitcoin, estima-se que também levaria um ano.

( 3.4 Como entender a evolução da abstração da conta?

Primeiro, é preciso 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ções em massa
• Pagamento de gas
• bloqueio de conta
• Assinatura personalizada

Mas a principal desvantagem do EIP-4337 é que vai contra o princípio da motivação humana.

Parece melhor, mas preso em um ciclo vicioso de desenvolvimento do mercado: muitos Dapps ainda não são compatíveis, os usuários relutam em usar endereços CA, e usar CA resulta em custos de transação mais altos ) as taxas de transação em cenários de transferência comuns dobram ###, dependente demais da compatibilidade do próprio Dapp.

Portanto, até agora não houve uma ampla adoção na rede principal do Ethereum.

O custo é o critério de medição mais importante para os usuários, deve-se reduzir os custos.

Para realmente reduzir o GAS, é necessário que o próprio Ethereum faça uma atualização de soft fork, modificando o cálculo de GAS ou módulos de consumo de GAS de operação. Já que se vai fazer um soft fork, seria melhor considerar diretamente o EIP-7702.

4. Análise completa do EIP-7702

( 4.1 O que é o EIP-7702

Através de um novo tipo de transação, permite que EOA tenha temporariamente funcionalidades de contrato inteligente em uma única transação, suportando transações em lote, transações sem Gas e gerenciamento de permissões personalizadas, sem a necessidade de introduzir um novo opCode EVM ) que afete a compatibilidade para trás ###.

Permitir que os usuários obtenham a maioria das capacidades de AA sem a necessidade de implantar contratos inteligentes, podendo até oferecer a capacidade de iniciar transações em nome dos usuários por terceiros, sem que os usuários forneçam a chave privada, apenas assinando a informação de autorização.

( 4.2 Estruturas de Dados

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

rlp)[ chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destino, valor, dados, access_list, lista_de_autorização, signature_y_parity, assinatura_r, assinatura_s ]###

É importante notar que foi adicionado o objeto authorization_list, que armazena o código que o signatário deseja executar em sua EOA. O usuário assina o contrato de código a ser executado ao assinar a transação, existindo como uma lista bidimensional, podendo armazenar múltiplas informações de operação 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 o início da fase de transação, para cada tupla [chain_id, address, nonce, y_parity, r, s] da authorization_list:

1. Recuperar o endereço do signatário a partir da assinatura r, s usando ecrecover.

2. Verificar a cadeia ID### para evitar a reprodução da cadeia de bifurcação ###.

3. Verifique se o código do signatário authority está vazio ou se foi delegado ( para validar se a transação é uma transação válida 7702 ).

4. Verificar nonce do signatário authority ( para prevenir a reprodução da assinatura authority ).

5. Defina o código do signatário authority como 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 parciais).

7. Adicionar a conta do signatário authority à lista de endereços acessados ( para o endereço quente, reduzindo o custo de gas para consulta de armazenamento ).

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

A versão "nova" altera apenas o comportamento de implantação do código.

Não defina mais o código da conta como contract_code, mas sim recupere o código address a partir da authorization_list e defina-o como o código da conta.

Ao executar o código de autorização, carregue o código a partir do campo address da authorization_list, executando-o no contexto da conta do signatário.

O código do contrato do usuário é armazenado em um endereço específico na cadeia, não está diretamente incluído na transação.

Os comandos de operação e os parâmetros relacionados são armazenados no campo data da carga da transação.

) 4.4 O valor do EIP-7702

Houve mudanças em toda a cadeia do Web3 wallet, experiência do usuário