Análise da abstração de contas multi-chain: explorando o futuro da encriptação de infraestrutura
Recentemente, a conferência da comunidade Ethereum (EthCC 7) ocorreu em Bruxelas, Bélgica, sendo o maior evento anual de Ethereum na Europa, focando em tecnologia e comunidade. Nesta edição, mais de 350 líderes de opinião da indústria de blockchain fizeram palestras, entre eles, um desenvolvedor apresentou uma palestra intitulada "Desvendando o Futuro: Análise da Abstração de Contas Multi-Chain".
Pontos-chave da palestra
A abstração de contas (AA) inclui principalmente dois pontos-chave: a abstração de assinatura e a abstração de pagamento. A abstração de assinatura permite que os usuários escolham qualquer mecanismo de verificação que preferirem, enquanto a abstração de pagamento permite o uso de várias opções de pagamento de transações. Essa flexibilidade proporciona uma experiência do usuário mais segura e melhor.
No 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. As restrições à verificação de transações e os passos para a execução de transações têm características e limitações próprias em diferentes implementações.
A implementação do ERC-4337 em cadeias compatíveis com EVM possui duas diferenças chave: as diferenças de protocolo no design de Rollup e as diferenças na forma de calcular endereços, o que resulta em detalhes de desenvolvimento que são difíceis de notar ao implementar o ERC-4337 entre L1 e L2.
Abstração de contas
O que é abstração de contas
abstração de contas (AA)主要包括两个关键点：
Abstração de assinatura: os usuários podem escolher qualquer mecanismo de verificação de sua preferência, e não estão limitados a certos algoritmos de assinatura digital (como ECDSA).
Abstração de pagamentos: os utilizadores podem utilizar várias opções de pagamento, como usar ativos ERC-20 em vez de ativos nativos para pagamento, ou permitir que terceiros patrocinem a transação.
Esta flexibilidade oferece uma experiência do utilizador mais segura e superior. O objetivo da abstração de contas é alcançar esses dois pontos-chave de várias maneiras.
Introdução ao 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 múltiplas userOp e as envia para o contrato EntryPoint através da chamada da função handleOps.
Contrato EntryPoint: Este contrato processa transações como um sistema operativo, sendo as suas principais funções:
Chamar a função validate no contrato de conta, garantindo que userOp tenha 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.
Introdução ao AA nativo
No Ethereum, as contas são divididas em EOA e contas de contrato. No entanto, na AA nativa, cada conta é um contrato, e o mecanismo de processamento de transações está diretamente incorporado no protocolo da blockchain.
A abstração de contas nativa segue o ERC-4337: era StarkNet e zkSync
abstração de contas nativa com design de privacidade: Aztec
Diferenças entre ERC-4337 e AA nativo
função do sistema operacional
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órias?
Quem dispara a função de ponto de entrada?
O que determina o fluxo de processamento das transações?
No ERC-4337, esses papéis são realizados em conjunto pelo Bundler e pelo EntryPoint Contract.
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.
No zkSync, a principal diferença entre a Era e outras implementações de AA é que o Operator precisa trabalhar em conjunto com o bootloader (contrato do sistema). O bootloader abre um novo bloco, define seus parâmetros (incluindo parâmetros de bloco e outros parâmetros de Gas) e recebe transações do Operator para validação.
interface de contrato
Devido à existência de três etapas, a interface do contrato de conta é semelhante em diferentes implementações, e esses pontos de entrada de função 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
No 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.
Limitações dos passos de verificação
Uma vez que a verificação de transações não tem restrições de custo (na essência, a verificação de transações é a chamada a uma função de visualização), um atacante pode realizar um ataque DoS ao pool de memória, prejudicando o agrupador (EIP-4337) ou o operador/classificador (AA nativo).
EIP-4337 define quais códigos de operação sã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
Armazenamento do slot keccak256(A || X) pertencente a qualquer outro endereço: isso significa usar diretamente o endereço como chave em um mapeamento (por exemplo, mapping (address => value)), equivalente ao acesso ao slot keccak256(A || X). Por exemplo, o saldo de ativos em um contrato ERC-20.
A lógica do contrato não pode acessar variáveis globais, como o número do bloco. StarkNet também não permite chamadas de contratos externos.
Limitações dos passos de execução
Na zkSync, a execução de chamadas do sistema requer a confirmação da existência de bandeiras do sistema. Por exemplo, a única maneira de aumentar o nonce é interagindo com o NonceHolder, enquanto a implantação de contratos requer interação com o ContractDeployer. As bandeiras do sistema garantem que os desenvolvedores de contas interajam conscientemente com os contratos do sistema.
Na ERC-4337 e StarkNet, a fase de execução não tem restrições especiais.
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 do sistema NonceHolder gerencia o nonce, garantindo um aumento estrito, 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 um contrato específico.
usar a primeira transação para implantação
O ERC-4337 inclui o campo initcode na estrutura userOp para implantar o remetente (contrato de conta) na sua primeira userOp.
No StarkNet e zkSync, os usuários devem enviar a primeira transação para o operador/ordenador para implantar o contrato de conta.
design especial no zkSync
Se você transferir ETH diretamente de uma EOA do Ethereum para zkSync, sem precisar implantar um contrato de conta personalizado, você receberá uma conta padrão com o mesmo endereço. Essa conta pode funcionar como uma EOA do Ethereum e também é controlada pela chave privada da EOA correspondente do Ethereum.
Este tipo de conta é a versão None e não a versão 1. Não podes chamar as funções do DefaultAccount, pois não há código implementado no espaço do kernel.
A diferença entre o 4337 do L1 e o 4337 do L2
A implementação do ERC-4337 em cadeias compatíveis com EVM tem duas diferenças chave: diferenças de protocolo e diferenças de endereço.
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, as taxas relacionadas a esse processo de upload, como taxas de segurança do L1 e taxas de blob, devem ser incluídas no Gas de pré-validação. Determinar as taxas de upload apropriadas no Gas de pré-validação é um desafio significativo.
diferença de endereço
O método de codificação de endereço 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 assumimos que o cálculo de endereços é consistente em todas as cadeias. No entanto, há um detalhe difícil de notar que pode levar a diferenças nos endereços de contratos de conta entre as implementações do ERC-4337 no Ethereum e no L2.
A questão chave é adicionar 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 EVM não for especificada durante a compilação, a introdução de push0 levará a 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.
17 gostos
Recompensa
17
2
Partilhar
Comentar
0/400
OnChainArchaeologist
· 07-09 19:30
Amo brincar com isso.
Ver originalResponder0
PriceOracleFairy
· 07-09 19:30
meh, aa é apenas matemática eth sofisticada... mas essa abstração de assinatura está parecendo meio suculenta, ngl
Análise da abstração de contas multi-chain: principais diferenças entre ERC-4337 e AA nativa
Análise da abstração de contas multi-chain: explorando o futuro da encriptação de infraestrutura
Recentemente, a conferência da comunidade Ethereum (EthCC 7) ocorreu em Bruxelas, Bélgica, sendo o maior evento anual de Ethereum na Europa, focando em tecnologia e comunidade. Nesta edição, mais de 350 líderes de opinião da indústria de blockchain fizeram palestras, entre eles, um desenvolvedor apresentou uma palestra intitulada "Desvendando o Futuro: Análise da Abstração de Contas Multi-Chain".
Pontos-chave da palestra
A abstração de contas (AA) inclui principalmente dois pontos-chave: a abstração de assinatura e a abstração de pagamento. A abstração de assinatura permite que os usuários escolham qualquer mecanismo de verificação que preferirem, enquanto a abstração de pagamento permite o uso de várias opções de pagamento de transações. Essa flexibilidade proporciona uma experiência do usuário mais segura e melhor.
No 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. As restrições à verificação de transações e os passos para a execução de transações têm características e limitações próprias em diferentes implementações.
A implementação do ERC-4337 em cadeias compatíveis com EVM possui duas diferenças chave: as diferenças de protocolo no design de Rollup e as diferenças na forma de calcular endereços, o que resulta em detalhes de desenvolvimento que são difíceis de notar ao implementar o ERC-4337 entre L1 e L2.
Abstração de contas
O que é abstração de contas
abstração de contas (AA)主要包括两个关键点：
Abstração de assinatura: os usuários podem escolher qualquer mecanismo de verificação de sua preferência, e não estão limitados a certos algoritmos de assinatura digital (como ECDSA).
Abstração de pagamentos: os utilizadores podem utilizar várias opções de pagamento, como usar ativos ERC-20 em vez de ativos nativos para pagamento, ou permitir que terceiros patrocinem a transação.
Esta flexibilidade oferece uma experiência do utilizador mais segura e superior. O objetivo da abstração de contas é alcançar esses dois pontos-chave de várias maneiras.
Introdução ao 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 múltiplas userOp e as envia para o contrato EntryPoint através da chamada da função handleOps.
Contrato EntryPoint: Este contrato processa transações como um sistema operativo, sendo as suas principais funções:
Introdução ao AA nativo
No Ethereum, as contas são divididas em EOA e contas de contrato. No entanto, na AA nativa, cada conta é um contrato, e o mecanismo de processamento de transações está diretamente incorporado no protocolo da blockchain.
Desenho de AA em várias redes de blockchain:
Diferenças entre ERC-4337 e AA nativo
função do sistema operacional
AA OS precisa resolver os seguintes problemas:
No ERC-4337, esses papéis são realizados em conjunto pelo Bundler e pelo EntryPoint Contract.
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.
No zkSync, a principal diferença entre a Era e outras implementações de AA é que o Operator precisa trabalhar em conjunto com o bootloader (contrato do sistema). O bootloader abre um novo bloco, define seus parâmetros (incluindo parâmetros de bloco e outros parâmetros de Gas) e recebe transações do Operator para validação.
interface de contrato
Devido à existência de três etapas, a interface do contrato de conta é semelhante em diferentes implementações, e esses pontos de entrada de função só podem ser chamados pelo AA OS:
No 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.
Limitações dos passos de verificação
Uma vez que a verificação de transações não tem restrições de custo (na essência, a verificação de transações é a chamada a uma função de visualização), um atacante pode realizar um ataque DoS ao pool de memória, prejudicando o agrupador (EIP-4337) ou o operador/classificador (AA nativo).
EIP-4337 define quais códigos de operação sã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:
A lógica do contrato não pode acessar variáveis globais, como o número do bloco. StarkNet também não permite chamadas de contratos externos.
Limitações dos passos de execução
Na zkSync, a execução de chamadas do sistema requer a confirmação da existência de bandeiras do sistema. Por exemplo, a única maneira de aumentar o nonce é interagindo com o NonceHolder, enquanto a implantação de contratos requer interação com o ContractDeployer. As bandeiras do sistema garantem que os desenvolvedores de contas interajam conscientemente com os contratos do sistema.
Na ERC-4337 e StarkNet, a fase de execução não tem restrições especiais.
número aleatório
usar a primeira transação para implantação
design especial no zkSync
Se você transferir ETH diretamente de uma EOA do Ethereum para zkSync, sem precisar implantar um contrato de conta personalizado, você receberá uma conta padrão com o mesmo endereço. Essa conta pode funcionar como uma EOA do Ethereum e também é controlada pela chave privada da EOA correspondente do Ethereum.
Este tipo de conta é a versão None e não a versão 1. Não podes chamar as funções do DefaultAccount, pois não há código implementado no espaço do kernel.
A diferença entre o 4337 do L1 e o 4337 do L2
A implementação do ERC-4337 em cadeias compatíveis com EVM tem duas diferenças chave: diferenças de protocolo e diferenças de endereço.
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, as taxas relacionadas a esse processo de upload, como taxas de segurança do L1 e taxas de blob, devem ser incluídas no Gas de pré-validação. Determinar as taxas de upload apropriadas no Gas de pré-validação é um desafio significativo.
diferença de endereço
O método de codificação de endereço 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 assumimos que o cálculo de endereços é consistente em todas as cadeias. No entanto, há um detalhe difícil de notar que pode levar a diferenças nos endereços de contratos de conta entre as implementações do ERC-4337 no Ethereum e no L2.
A questão chave é adicionar 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 EVM não for especificada durante a compilação, a introdução de push0 levará a uma alteração no bytecode, mesmo que o código Solidity seja o mesmo.