Análise aprofundada da evolução da abstração de contas do Ethereum e perspetivas futuras

Introdução

Este artigo é dividido em duas partes principais:

A primeira parte começará com a primeira proposta AA de 2015, sistematizando o conteúdo das principais propostas EIP até hoje, rastreando o desenvolvimento histórico das propostas AA e avaliando de forma abrangente as vantagens e desvantagens de cada uma.

A segunda parte foca na comparação das respostas ao mercado em baixa enfrentadas após a proposta do EIP4337, analisando em profundidade o EIP7702 que será incluído na próxima atualização do Ethereum. Uma vez que esta proposta seja integrada, irá mudar de forma abrangente a forma das aplicações em blockchain.

EIP-7702 tem um significado revolucionário, vamos explorar isso em detalhe.

1. O contexto da abstração de contas

1.1 Significado da abstração de contas

O fundador do Ethereum, Vitalik, atualizou novamente o roteiro de desenvolvimento do ETH no final de 2023, mas as definições relacionadas à abstração de contas não foram alteradas. O modelo atual está a passar da EIP-4337 para a próxima fase: conversão voluntária de contas EOA.

Após mais de um ano do lançamento do EIP4337, em 1 de março de 2023, foi oficialmente anunciado que ( passou na auditoria ). Em um ambiente de mercado contraditório, onde os usuários reconhecem amplamente, mas não utilizam amplamente, o progresso do EIP-7702 foi adiantado significativamente e já foi confirmado que será integrado 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 número total de contas do EIP4337 nas principais cadeias é de apenas 12 milhões, dos quais apenas 6.764 são endereços 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á alcançou 270 milhões, e o EIP4337 praticamente não teve desenvolvimento substancial na rede principal.

No entanto, isso não afeta o valor essencial do AA. O design do EIP4337 foi desde o início destinado a não resolver o problema de compatibilidade para frente da rede principal. Com as várias cadeias L2 geralmente incorporando AA nativo, o número de endereços EIP4337 cresceu de forma explosiva nas L2, com os usuários ativos mensais da Base e da Polygon atingindo 1 milhão e 3 milhões em julho, mostrando um desempenho considerável.

O design do EIP4337 não está errado, mas é originado das diferenças entre a mainnet e o L2, necessitando de soluções adequadas para cada um.

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 posse e o direito de assinatura da conta externa são detidos pelo mesmo sujeito. A pessoa que possui a chave privada não só tem a "posse da conta", mas também o direito de "assinar a transferência de todos os ativos".

Isso é determinado pela estrutura de transações da conta Ethereum. Na estrutura de transação padrão, não há campo From, a transferência de fundos é realmente realizada através dos parâmetros VRS (, que são assinados pelo usuário ) para decifrar o endereço From. Isso envolve conceitos como ECDSA e funções de limite unidirecionais, garantindo a segurança por meio da criptografia, mas também leva à atual dificuldade de fusão da propriedade dos endereços EOA.

O efeito central do EIP4337 é adicionar o Endereço do Remetente no campo da transação, realizando a separação da chave privada e do endereço a ser operado.

A importância da separação de propriedade reside na resolução de vários problemas derivados do design da conta externa (EOA):

1. Difícil de proteger a chave privada: perder a chave privada significa perder todos os ativos.
2. Algoritmo de assinatura único: o protocolo nativo suporta apenas verificação de assinatura ECDSA.
3. Permissões de assinatura excessivas: sem multi-assinatura nativa, uma única assinatura pode executar quaisquer operações.
4. A taxa de transação só pode ser paga com ETH, não suporta transações em lote.
5. Vazamento de privacidade nas transações: transações um a um podem expor a privacidade dos detentores de conta.

Essas limitações dificultam o uso do Ethereum por usuários comuns:

• Para usar qualquer aplicativo, é necessário possuir ETH e assumir o risco de volatilidade de preços.
• Os usuários precisam lidar com a lógica de taxas complexas, como preço do Gas, limite do Gas, Nonce, etc.
• Embora muitas carteiras tentem melhorar a experiência do usuário através da otimização do produto, os resultados são limitados.

O caminho para a solução reside na realização da abstração de contas, desacoplando a propriedade (Owner) e o direito de assinatura (Signer), resolvendo assim gradualmente os problemas mencionados.

Embora haja muitos planos históricos, eles se resumem a duas rotas.

3. Contextualização das propostas históricas de AA

As soluções para o problema parecem ter várias propostas de EIP, mas, no fundo, existem apenas duas ideias principais. Cada EIP não aprovado considerou questões que foram incorporadas nos pontos de ruptura das soluções existentes.

3.1 Primeiro tipo de rota: converter endereço EOA em endereço CA

Em 15 de novembro de 2015, Vitalik propôs uma nova estrutura de contas como contratos no EIP-101. As principais alterações incluem:

• Mudar o endereço para que tenha apenas código e espaço de armazenamento
• Alterar o suporte a taxas, permitindo o pagamento com tokens ERC20
• Através de contratos pré-compilados, converter tokens nativos em saldo de tipo ERC20.
• Simplificar os campos de transação, mantendo apenas to, startgas, data e code

Este plano pode ser considerado uma transformação tipo Grande Salto, que irá alterar significativamente o design de base, 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. ).

As funções derivadas incluem:

1. Suporte a mais algoritmos de criptografia, com o método de verificação de assinatura especificado pelo código interno do endereço
2. Possui características de resistência a ataques quânticos, pois o código pode ser atualizado
3. Conferir ao ETH as mesmas funcionalidades que os contratos ERC20, como autorização de desconto.
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 possível continuar a avançar é evidente: o passo foi demasiado grande, com uma consideração inadequada sobre o atual problema de colisão de hash em transações e as preocupações de segurança, levando assim à suspensão. No entanto, cada princípio vantajoso tornou-se uma das funções centrais das subsequentes EIP4337 e EIP7702.

Uma série de EIPs subsequentes tentaram aprimorar essa lógica:

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

• Resolver problemas de implantação de código: quando o contrato da parte transacionante não está implantado, usar o parâmetro code anexado à transação para executar a implantação da carteira do contrato.
• Propor um novo opcode PAYGAS, como delimitador da parte de verificação e execução nos parâmetros da transação.

Embora não tenha sido bem-sucedido na época, tornou-se uma das lógicas centrais do EIP7702. Cada transação do EIP7702 combina uma estrutura de transação especial, podendo anexar um certo código, permitindo que o endereço EOA tenha capacidade de contrato nesta transação.

EIP-7702(2024-05-07): definir código da conta EOA Como alternativa ao EIP-3074, o EIP-7702 foi confirmado para ser incluído na próxima bifurcação dura ETH Prague/Electra.

3.2 Segunda rota: deixar o endereço EOA conduzir o endereço CA

EIP-3074(2020-10-15): adicionar os códigos de operação AUTH e AUTHCALL Adicionar duas novas instruções no EVM, permitindo que EOA autorize contratos a chamar outros contratos em vez da identidade EOA através desses opcodes.

EIP-4337(2021-09-29): implementar a abstração de contas utilizando o pool de memória de transações Inspirado pelo MEV, o valor central está em evitar completamente alterações no protocolo da camada de consenso. Um novo objeto de transação, UserOperation, é proposto, onde os usuários enviam este objeto para o pool de memória, que é empacotado em massa pelos bundlers para a execução de transações contratuais, essencialmente elevando as transações subjacentes e a operação da conta para o nível do contrato.

EIP-5189(2022-06-29): através de endossadores, operação de abstração de contas Otimizar a lógica do EIP4337, estabelecendo um mecanismo de endosse de penalização de fundos para prevenir ataques de bloqueio DoS.

3.3 outras propostas que suportam AA

EIP-2718(2020-06-13): envelopes de embalagem para novos tipos de transação Propostas finalizadas definem um novo tipo de transação como um envelope para futuros tipos de transação a serem adicionados. Ao introduzir novos tipos de transação, são diferenciados através de codificação específica, permitindo a compatibilidade retroativa sem a necessidade de compatibilidade para frente. Assim como o EIP1559 diferencia 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(2021-06-10): proibição de endereços EOA de implantar contratos Solução complementar na rota 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, proibindo a implantação de código em endereços que já são EOA.

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 real do EIP-4337:

• Suporte a transações em lote
• Suporte para pagamento de Gas
• Suporte à recuperação de contas
• Suporte a múltiplas assinaturas
• Suporte a transações de retransmissão
• Suporte para atualização de algoritmos de assinatura
• Suporte a carteiras de contrato ERC4337
• Suporte para pagamento Gas por terceiros

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 relutam em usar endereços CA; usar CA, na verdade, aumenta o custo das transações (, as taxas de transação em cenários de transferência comum dobram ), e há uma dependência excessiva da compatibilidade do Dapp.

Portanto, nunca conseguiu se popularizar na mainnet 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 Ethereum em si passe por uma atualização de soft fork, modificando o cálculo de Gas ou módulos como o consumo de Gas dos códigos de operação. Já que se vai fazer um soft fork, por que não considerar diretamente o EIP-7702?

4. Análise abrangente do EIP-7702

4.1 EIP-7702 visão geral

Através de um novo tipo de transação, permite que EOA possua temporariamente funcionalidades de contrato inteligente em uma única transação, suportando 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 ).

Os utilizadores podem obter a maior parte das capacidades de AA sem precisar de implantar contratos inteligentes, e até suportar terceiros a iniciar transações em seu nome, apenas necessitando de assinar informações de autorização em vez de fornecer a chave privada.

4.2 estrutura de dados

Defina um novo tipo de transação 0x04, o 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, lista_de_acesso, lista_de_autorização, signature_y_parity, signature_r, signature_s ])

Adiciona o objeto authorization_list, que armazena o código que os signatários desejam executar no EOA. O usuário assina a transação ao mesmo tempo que assina o código do contrato a ser executado. Existe como uma lista bidimensional, podendo armazenar várias informações de operação, permitindo a execução de 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 validaçã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 o ID da cadeia ( para evitar a reprodução de cadeias de bifurcação )
3. Verifique se o código do signatário authority está vazio ou delegado
4. Verificar o nonce do assinante authority ( para evitar a reprodução da assinatura authority )
5. Defina o código do signatário authority como 0xef0100 || endereço
6. Aumentar nonce do signatário authority( para prevenir a reprodução de assinaturas locais)
7. Adicionar a conta do signatário authority à lista de endereços visitados

4.3.2 fase de execução de operações

A nova versão altera apenas o comportamento de implantação do código. Não define mais o código da conta como contract_code, mas recupera o código especificado pelo endereço da authorization_list e o define como código da conta.

Ao executar o código autorizado, carregue o código do campo address da authorization_list e execute-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, e não está diretamente incluído na transação. As instruções de operação e os parâmetros relacionados são armazenados no campo data da carga útil da transação.

4.4 O valor do EIP-7702

Mudanças na cadeia completa de carteiras Web3, melhorando significativamente a experiência do usuário. Transações comuns iniciadas por EOA podem executar várias lógicas de contrato, como transferências em lote. Isso afeta a identificação de transações em cenários CeFi, bem como taxas de coleta e retirada.

Quebrar múltiplos paradigmas existentes:

1. O saldo da conta pode ser reduzido devido a transações que não se originaram dessa conta.
2. Após o início da execução da transação, o nonce da EOA pode aumentar várias vezes.
3. A lógica de proteção da comparação entre tx.origin e msg.sender falha
4. EOA pode emitir eventos, afetando a identificação e monitoramento de eventos na cadeia
5. O endereço EOA pode falhar ao receber ativos ERC20, 721, 1155, etc. mecanismo de callback ( )

4.5 Comparação entre EIP-7702 e EIP-4337

Vantagens do EIP-7702:

• Gas mais baixo, sem necessidade de passar pelo módulo entrypoint
• O custo de migração do usuário é menor, não é necessário implantar contratos em cadeia com antecedência.
• Também suporta a execução de delegação de código, dividida em total