Análise da abstração de contas multi-chain: explorando o futuro da encriptação de infraestruturas
De 8 a 11 de julho de 2024, o maior evento anual de Ethereum na Europa — a Conferência da Comunidade Ethereum (EthCC) — será realizada em Bruxelas, na Bélgica, com foco no desenvolvimento técnico e comunitário.
A Conferência da Comunidade Ethereum (EthCC 7) convidou mais de 350 líderes de opinião da linha de frente da indústria de blockchain para dar palestras. O desenvolvedor da imToken Labs, Alfred, foi convidado a participar e apresentou uma palestra intitulada "Revelando o Futuro: Análise da Abstração de Contas Multichain".
Visão geral dos pontos da palestra
Os dois pilares da abstração de contas (AA): abstração de assinaturas e abstração de pagamentos. A abstração de assinaturas permite que os usuários escolham qualquer mecanismo de verificação, enquanto a abstração de pagamentos oferece várias opções de pagamento de transações, melhorando assim a segurança e a experiência do usuário.
As funções de ponto de entrada na fase de "verificação" de ERC-4337 e AA nativa são fixas, mas na fase de "execução", apenas a AA nativa mantém o ponto de entrada fixo. Diferentes implementações têm características distintas nas limitações de transação de verificação e nos passos de execução de transação.
Ao implementar o ERC-4337 em cadeias compatíveis com EVM, existem duas diferenças principais: as diferenças de protocolo no design de Rollup e as diferenças na forma de cálculo de endereços. Essas diferenças resultam em alguns detalhes de desenvolvimento que podem ser facilmente negligenciados ao implementar o ERC-4337 entre L1 e L2.
Abstração de contas简介
1. definição da abstração de contas
abstração de contas (AA)主要包含两个关键点：
Abstração de assinatura: os usuários podem escolher livremente o mecanismo de verificação, não se limitando a algoritmos de assinatura digital específicos (como ECDSA).
Abstração de pagamentos: os utilizadores podem usar várias opções de pagamento para transações, como pagar com ativos ERC-20 em vez de ativos nativos, ou ser patrocinados por terceiros para transações.
Esta flexibilidade aumentou significativamente a segurança e a experiência do usuário. A abstração de contas visa alcançar esses dois objetivos centrais de várias maneiras.
2. Análise do ERC-4337
Atualmente, existem algumas limitações nas contas de propriedade externa (EOA) no protocolo Ethereum, como métodos de assinatura fixos e design de pagamento. O ERC-4337 resolve esses problemas ao introduzir métodos de gestão de contas e processamento de transações mais flexíveis.
Estrutura userOp: No ERC-4337, o usuário envia a estrutura userOp para o Bundler. O Bundler coleta várias userOp e as envia para o contrato EntryPoint chamando a função handleOps.
Contrato EntryPoint: Este contrato é semelhante a um sistema operacional, e as principais funções de processamento de transações incluem:
Chamar a função validate no contrato da conta, garantindo que userOp receba a autorização do proprietário da conta.
Cobrança de taxas.
Chamar a função execute no contrato da conta para executar a operação alvo do userOp.
3. Introdução ao AA nativo
No Ethereum, as contas são divididas em EOA e contas de contrato. E na AA nativa, cada conta é um contrato, e o mecanismo de processamento de transações está diretamente embutido no protocolo da blockchain.
Seguir a abstração de contas nativa do ERC-4337: StarkNet e zkSync Era
Abstração de contas nativa com design de privacidade: Aztec
Diferenças entre ERC-4337 e AA nativo
1. Papel do sistema operativo
AA OS precisa resolver os seguintes problemas:
Quem decide o preço do Gas?
Quem decide a ordem das transações? Onde está o pool de memória?
Quem aciona a função do ponto de entrada?
O que determina o processo de processamento de transações?
No ERC-4337, esses papéis são realizados em conjunto pelo Bundler e pelo Contracto EntryPoint.
Na AA nativa, os usuários enviam suas userOps para o operador/classificador do servidor oficial, em vez de para o Bundler e o EntryPoint Contract.
No StarkNet, o Sequencer é responsável por lidar com todas essas tarefas.
A principal diferença entre zkSync Era e outras implementações de AA é que o Operator precisa trabalhar em conjunto com o bootloader (contrato do sistema). O bootloader abre novos blocos, define seus parâmetros (incluindo parâmetros de bloco e outros parâmetros de Gas) e recebe transações do Operator para validação.
2. Interface de contrato
Devido à existência de três etapas, a interface do contrato da conta é semelhante em diferentes implementações, e esses pontos de entrada de funções só podem ser chamados pelo AA OS:
ERC-4337: validação de operações do utilizador
zkSync: validação de transações, pagamento de transações, execução de transações
Na ERC-4337 e na AA nativa, a função de ponto de entrada da fase de "verificação" é fixa, enquanto na fase de "execução", apenas o ponto de entrada na AA nativa é fixo.
3. Limitações dos passos de verificação
Devido à ausência de limites de custo para a validação de transações, um atacante pode realizar um ataque DoS na pool de memórias, afetando o agrupador (EIP-4337) ou o operador/classificador (AA nativa).
EIP-4337 define os códigos de operação proibidos e como limitar o acesso ao armazenamento. O zkSync Era relaxou o uso de alguns OpCode:
A lógica do contrato só pode acessar seu próprio slot de armazenamento. Se o endereço do contrato da conta for o endereço A, ele pode acessar:
slot de armazenamento pertencente ao endereço A
slot de armazenamento pertencente a qualquer outro endereço A
O slot de armazenamento keccak256(A || X) pertencente a qualquer outro endereço: isso significa usar diretamente o endereço como chave no mapeamento, equivalente a acessar o slot keccak256(A || X). Por exemplo, o saldo de ativos no contrato ERC-20.
A lógica de contrato não pode acessar variáveis globais, como o número do bloco. O StarkNet também não permite chamadas de contratos externos.
4. Limitações dos passos de execução
No zkSync, a execução de chamadas de sistema requer a confirmação da existência de sinalizadores do sistema. Por exemplo, a única maneira de aumentar o nonce é interagir com o NonceHolder, enquanto o deployment de contratos requer interação com o ContractDeployer. Os sinalizadores do sistema garantem que os desenvolvedores de contas interajam conscientemente com os contratos do sistema.
Na ERC-4337 e StarkNet, não há restrições especiais na fase de execução.
5. número aleatório
No ERC-4337, o design do número aleatório do ponto de entrada diferencia o valor da chave de 192 bits e o valor aleatório de 64 bits.
No zkSync, o contrato de sistema NonceHolder gerencia o nonce, garantindo que seja estritamente crescente, ou seja, aumentando o número aleatório em 1.
No StarkNet, o nonce também é estritamente crescente, mas não há nonce abstrato gerido por contratos específicos.
6. Usar a primeira transação para a implementação
O ERC-4337 inclui o campo initcode na estrutura userOp para implantar o remetente (contrato de conta) em seu primeiro userOp.
No StarkNet e no zkSync, os usuários devem enviar a primeira transação para o operador/classificador para implantar o contrato da conta.
7. design especial no zkSync
Se você transferir ETH diretamente de uma EOA Ethereum para zkSync, sem a necessidade de implantar um contrato de conta personalizado, você receberá uma conta padrão com o mesmo endereço. Essa conta pode funcionar como uma EOA Ethereum e é controlada pela chave privada da EOA Ethereum correspondente.
Este tipo de conta é da versão None e não da versão 1. Você não pode chamar as funções do DefaultAccount, pois ele não tem código implantado no espaço do núcleo.
Diferença entre L1 4337 e L2 4337
Existem duas diferenças chave na implementação do ERC-4337 em cadeias compatíveis com EVM: diferenças de protocolo e diferenças de endereço.
1. Diferenças de protocolo
No design de Rollup, o L2 precisa enviar dados para o L1 para segurança e liquidação. No contexto do ERC-4337, os custos relacionados a esse processo de envio, como a taxa de segurança do L1 e a taxa de blob, devem ser incluídos no Gas de pré-validação. Determinar a taxa de envio apropriada no Gas de pré-validação é um desafio significativo.
2. Diferença de endereço
O método de codificação de endereços na função create do zkSync ERA é diferente do Ethereum e do OP rollup. Além disso, o StarkNet utiliza uma função hash única para o cálculo de endereços. No contexto do ERC-4337 em cadeias compatíveis com EVM, geralmente presumimos que o cálculo de endereços é consistente entre as várias cadeias. No entanto, há um detalhe sutil que pode levar a endereços de contratos de conta diferentes entre as implementações do ERC-4337 no Ethereum e no L2.
A questão chave é a adição de novos códigos de operação em um hard fork. Por exemplo, se a cadeia L2 não suportar o hard fork de Xangai e a versão do EVM não for especificada na compilação, a introdução do push0 resultará em uma alteração no bytecode, mesmo que o código Solidity seja o mesmo.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
7 gostos
Recompensa
7
4
Partilhar
Comentar
0/400
SigmaValidator
· 16h atrás
a abstração de contas é apenas para se divertir
Ver originalResponder0
NeverPresent
· 16h atrás
O pagamento abstrato é tão bull assim?
Ver originalResponder0
GateUser-beba108d
· 16h atrás
Não serve para nada, só fala e não faz.
Ver originalResponder0
StableNomad
· 16h atrás
meh, mais uma conversa de AA... lembra-me das alegações de "segurança" da celsius, para ser honesto
Análise da abstração de contas multi-chain: diferenças e desafios entre ERC-4337 e AA nativo
Análise da abstração de contas multi-chain: explorando o futuro da encriptação de infraestruturas
De 8 a 11 de julho de 2024, o maior evento anual de Ethereum na Europa — a Conferência da Comunidade Ethereum (EthCC) — será realizada em Bruxelas, na Bélgica, com foco no desenvolvimento técnico e comunitário.
A Conferência da Comunidade Ethereum (EthCC 7) convidou mais de 350 líderes de opinião da linha de frente da indústria de blockchain para dar palestras. O desenvolvedor da imToken Labs, Alfred, foi convidado a participar e apresentou uma palestra intitulada "Revelando o Futuro: Análise da Abstração de Contas Multichain".
Visão geral dos pontos da palestra
Os dois pilares da abstração de contas (AA): abstração de assinaturas e abstração de pagamentos. A abstração de assinaturas permite que os usuários escolham qualquer mecanismo de verificação, enquanto a abstração de pagamentos oferece várias opções de pagamento de transações, melhorando assim a segurança e a experiência do usuário.
As funções de ponto de entrada na fase de "verificação" de ERC-4337 e AA nativa são fixas, mas na fase de "execução", apenas a AA nativa mantém o ponto de entrada fixo. Diferentes implementações têm características distintas nas limitações de transação de verificação e nos passos de execução de transação.
Ao implementar o ERC-4337 em cadeias compatíveis com EVM, existem duas diferenças principais: as diferenças de protocolo no design de Rollup e as diferenças na forma de cálculo de endereços. Essas diferenças resultam em alguns detalhes de desenvolvimento que podem ser facilmente negligenciados ao implementar o ERC-4337 entre L1 e L2.
Abstração de contas简介
1. definição da abstração de contas
abstração de contas (AA)主要包含两个关键点：
Esta flexibilidade aumentou significativamente a segurança e a experiência do usuário. A abstração de contas visa alcançar esses dois objetivos centrais de várias maneiras.
2. Análise do ERC-4337
Atualmente, existem algumas limitações nas contas de propriedade externa (EOA) no protocolo Ethereum, como métodos de assinatura fixos e design de pagamento. O ERC-4337 resolve esses problemas ao introduzir métodos de gestão de contas e processamento de transações mais flexíveis.
3. Introdução ao AA nativo
No Ethereum, as contas são divididas em EOA e contas de contrato. E na AA nativa, cada conta é um contrato, e o mecanismo de processamento de transações está diretamente embutido no protocolo da blockchain.
Design de AA em várias redes de blockchain:
Diferenças entre ERC-4337 e AA nativo
1. Papel do sistema operativo
AA OS precisa resolver os seguintes problemas:
No ERC-4337, esses papéis são realizados em conjunto pelo Bundler e pelo Contracto EntryPoint.
Na AA nativa, os usuários enviam suas userOps para o operador/classificador do servidor oficial, em vez de para o Bundler e o EntryPoint Contract.
No StarkNet, o Sequencer é responsável por lidar com todas essas tarefas.
A principal diferença entre zkSync Era e outras implementações de AA é que o Operator precisa trabalhar em conjunto com o bootloader (contrato do sistema). O bootloader abre novos blocos, define seus parâmetros (incluindo parâmetros de bloco e outros parâmetros de Gas) e recebe transações do Operator para validação.
2. Interface de contrato
Devido à existência de três etapas, a interface do contrato da conta é semelhante em diferentes implementações, e esses pontos de entrada de funções só podem ser chamados pelo AA OS:
Na ERC-4337 e na AA nativa, a função de ponto de entrada da fase de "verificação" é fixa, enquanto na fase de "execução", apenas o ponto de entrada na AA nativa é fixo.
3. Limitações dos passos de verificação
Devido à ausência de limites de custo para a validação de transações, um atacante pode realizar um ataque DoS na pool de memórias, afetando o agrupador (EIP-4337) ou o operador/classificador (AA nativa).
EIP-4337 define os códigos de operação proibidos e como limitar o acesso ao armazenamento. O zkSync Era relaxou o uso de alguns OpCode:
4. Limitações dos passos de execução
No zkSync, a execução de chamadas de sistema requer a confirmação da existência de sinalizadores do sistema. Por exemplo, a única maneira de aumentar o nonce é interagir com o NonceHolder, enquanto o deployment de contratos requer interação com o ContractDeployer. Os sinalizadores do sistema garantem que os desenvolvedores de contas interajam conscientemente com os contratos do sistema.
Na ERC-4337 e StarkNet, não há restrições especiais na fase de execução.
5. número aleatório
6. Usar a primeira transação para a implementação
7. design especial no zkSync
Se você transferir ETH diretamente de uma EOA Ethereum para zkSync, sem a necessidade de implantar um contrato de conta personalizado, você receberá uma conta padrão com o mesmo endereço. Essa conta pode funcionar como uma EOA Ethereum e é controlada pela chave privada da EOA Ethereum correspondente.
Este tipo de conta é da versão None e não da versão 1. Você não pode chamar as funções do DefaultAccount, pois ele não tem código implantado no espaço do núcleo.
Diferença entre L1 4337 e L2 4337
Existem duas diferenças chave na implementação do ERC-4337 em cadeias compatíveis com EVM: diferenças de protocolo e diferenças de endereço.
1. Diferenças de protocolo
No design de Rollup, o L2 precisa enviar dados para o L1 para segurança e liquidação. No contexto do ERC-4337, os custos relacionados a esse processo de envio, como a taxa de segurança do L1 e a taxa de blob, devem ser incluídos no Gas de pré-validação. Determinar a taxa de envio apropriada no Gas de pré-validação é um desafio significativo.
2. Diferença de endereço
O método de codificação de endereços na função create do zkSync ERA é diferente do Ethereum e do OP rollup. Além disso, o StarkNet utiliza uma função hash única para o cálculo de endereços. No contexto do ERC-4337 em cadeias compatíveis com EVM, geralmente presumimos que o cálculo de endereços é consistente entre as várias cadeias. No entanto, há um detalhe sutil que pode levar a endereços de contratos de conta diferentes entre as implementações do ERC-4337 no Ethereum e no L2.
A questão chave é a adição de novos códigos de operação em um hard fork. Por exemplo, se a cadeia L2 não suportar o hard fork de Xangai e a versão do EVM não for especificada na compilação, a introdução do push0 resultará em uma alteração no bytecode, mesmo que o código Solidity seja o mesmo.