Ethereum possui dois tipos de contas: Conta de Propriedade Externa (EOA) e Conta de Contrato (CA). EOAs são controladas por uma chave privada, enquanto CAs são controladas pelo código do contrato inteligente contido nelas. EOAs sempre tiveram mais privilégios do que CAs, porque apenas EOAs podem iniciar a execução da transação pagando o gás. A Abstração de Conta (AA) é uma proposta que permite que um contrato seja uma conta “de alto nível”, como um EOA, que pode pagar taxas e iniciar a execução da transação.

A motivação para AA é melhorar significativamente a experiência do usuário na forma como os usuários interagem com a blockchain Ethereum hoje em vários cenários, como carteiras, misturadores, ÐApps e DeFi. AA fornece uma funcionalidade de camada base no Ethereum para decidir quando se pode pagar pelo gás, o que também tem implicações sobre quem paga pelo gás e como o pagam.

O aplicativo Status Messenger agrupa um mensageiro centrado na privacidade juntamente com uma carteira Ethereum e um navegador Web3 ÐApp. A carteira do Status atualmente é uma carteira EOA que nos limita de oferecer uma UX rica que apenas uma carteira de contrato inteligente pode oferecer, como segurança de múltiplas assinaturas, recuperação social, limitação de taxa, lista de endereços permitidos/negados e meta-transações sem gás. No entanto, a UX das carteiras de contratos inteligentes hoje é severamente prejudicada pelos preços variáveis do gás, o que não é eficientemente resolvido por relayers de terceiros. AA tem como objetivo abordar esse problema.

Neste artigo, motivamos a necessidade de Abstração de Conta no contexto de carteiras de contratos inteligentes. Em seguida, aprofundamos nos principais aspectos da AA descrevendo as mudanças de protocolo e o impacto nos nós. Por fim, discutimos algumas das extensões propostas e concluímos racionalizando o roteiro planejado para projetos do Status que se interligam com o Ethereum e, portanto, podem ser impactados pela AA.

História & Motivação

A Abstração de Conta foi inicialmente proposta como PEI-86em 2017 para implementar “Abstração da origem e assinatura da transação” mas as origens da ideia motivadora remontam ainda mais longe ainício de 2016, onde foi sugerido que: "Em vez de ter um mecanismo no protocolo onde ECDSA e o esquema de nonce padrão são consagrados como a única forma "padrão" de garantir uma conta, damos os primeiros passos em direção a um modelo onde a longo prazo todas as contas são contratos, contratos podem pagar por gasolina e os usuários são livres para definir seu próprio modelo de segurança."

As propostas iniciais foram consideradas desafiadoras de implementar devido às muitas mudanças de protocolo necessárias e às garantias de segurança a serem cumpridas. Mais recentemente, Vitalik et al. propuseram um rascunho para PEI-2938que descreve uma implementação muito mais simples mantendo as mudanças no protocolo/consenso mínimas e garantindo as garantias de segurança necessárias por meio das regras de mempool do nó. Vitalik’sApresentação do Grupo de Engenharia Ethereum MeetupeApresentação ETHOnline(juntamente com os artigos acompanhantes@SamWilsn/ryhxoGp4D">1 & @SamWilsn"/S1UQDOzBv">2) por Sam Wilson & Ansgar Dietrichs (dois dos outros autores do PEI) oferecem ótimas introduções ao tópico. Este artigo destaca aspectos chave de todas essas fontes.

Motivação: A justificativa motivadora por trás do AA é muito simples, mas fundamental: as transações do Ethereum hoje têm efeitos programáveis (atingidos através de chamadas para contratos inteligentes), mas têm validade fixa, ou seja, as transações são válidas apenas se tiverem uma assinatura ECDSA válida com um nonce válido e saldo de conta suficiente. As transações do AA atualizam a validade fixa para a validade programável, introduzindo um novo tipo de transação do AA que sempre se origina de um endereço especial para o qual o protocolo não requer assinatura, verificação de nonce ou saldo. A validade de tais transações do AA é determinada por um contrato inteligente de destino que pode impor suas próprias regras de validade, após o que pode decidir pagar por tais transações.

Então, por que isso é útil? Vamos pegar o exemplo das carteiras Ethereum para destacar o benefício do AA.

Carteiras de Contrato Inteligente: A maioria das carteiras Ethereum hoje são carteiras EOA que são protegidas por uma chave privada gerada a partir de uma frase semente. (A BIP-39frase-semente ou mnemônica é uma lista ordenada de 12-24 palavras que são escolhidas aleatoriamente de uma lista de 2048 palavras. Isso fornece a entropia necessária para obter uma semente binária que é gerada usando a função PBKDF2. A semente binária é então usada para gerar os pares de chaves assimétricas para oBIP-32carteira.) Espera-se que o usuário anote a frase-semente em um local seguro, pois ela pode ser necessária posteriormente para restaurar as chaves em outra carteira. No entanto, tais carteiras são vulneráveis a roubo da chave privada ou perda da frase-semente, o que resulta na perda dos fundos do usuário.

Carteiras de contratos inteligentes são implementadas on-chain por meio de contratos inteligentes (como o nome sugere). Tais carteiras oferecem mitigação de riscos programável e uma experiência amigável ao usuário, implementando recursos como segurança multi-assinatura, recuperação social ou baseada em tempo, limitação de taxa de transações ou montantes, lista de endereços permitidos/proibidos, meta-transações sem gás e transações agrupadas.

Embora as carteiras de contratos inteligentes estejam expostas ao risco de segurança de contratos inteligentes vulneráveis, esse risco pode ser mitigado por testes de segurança e revisões realizadas pelo provedor da carteira. O risco nas carteiras EOA reside inteiramente com o usuário da carteira, que é encarregado da segurança da frase-semente sem nenhum dos salvaguardas programáveis que são possíveis com contratos inteligentes.

Exemplos de carteiras de contratos inteligentes são Argent, Authereum, Dapper, Dharma, Gnosis Safe, Monolito e MYKEY. A adoção de tais carteiras parece estar aumentando, como indicado abaixo gráfico.

Argent implementa recuperação social sem semente com seu conceito de Guardiões que são pessoas ou dispositivos confiáveis do usuário que podem ajudar na recuperação da carteira do usuário. Argent também tem como objetivo habilitar segurança bancária (por meio de recursos como limites diários de transação, bloqueio de conta e contatos confiáveis) combinada com usabilidade semelhante ao Venmo (por meio do uso de nomes ENS em vez de endereços e suporte para meta-transações).

O Gnosis Safe é uma carteira de contrato inteligente multi-sig focada na gestão de fundos da equipe, que requer um número mínimo (m-de-n) de membros da equipe para aprovar uma transação antes que ela possa ocorrer. Ele também permite assinaturas sem gás via meta-transações.

Todas essas capacidades avançadas de carteira exigem o uso de contratos inteligentes não triviais. Os usuários da carteira precisam de um EOA com gás para interagir com eles ou dependem do provedor da carteira para dar suporte a meta-transações por meio dos relayers do provedor ou de redes de relayers de terceiros, como Rede de Postos de Gasolina. Enquanto o primeiro depende do ETH geralmente adquirido em bolsas centralizadas após KYC, o último tem como objetivo reduzir essa fricção de integração do UX transferindo o fardo do usuário para os relayers por um custo que é compensado pelo provedor de carteira on-/off-chain e/ou pelo usuário off-chain.

No entanto, as arquiteturas baseadas em relayers têm três principais desvantagens: (1) Podem ser consideradas intermediários centralizados com potencial para censurar transações. (2) São tecnicamente/economicamente ineficientes devido à taxa extra de gás base de 21000 necessária para a transação do relayer e à necessidade de negócios de obter lucro além das taxas de gás. (3) O uso de protocolos específicos do relayer obriga as aplicações a depender de infraestruturas Ethereum não baseadas com bases de usuários menores e garantias de disponibilidade incertas.

A Abstração de Conta permitirá que as carteiras de contratos inteligentes aceitem meta-transações sem gás do usuário e paguem pelo gás sem depender de redes de intermediários. Essa capacidade de camada base melhorará significativamente a experiência do usuário dessas carteiras sem sacrificar as garantias de descentralização do Ethereum.

Tornado Cash: Uma aplicação motivadora relacionada é a de um misturador como tornado.cashonde@tornadoO Tornado melhora a privacidade das transações ao quebrar o link on-chain entre endereços usando um contrato inteligente que aceita depósitos de ETH que podem ser posteriormente retirados por um endereço diferente. Espera-se que o usuário forneça o hash de um segredo durante o depósito e posteriormente forneça uma prova de zkSnark durante a retirada para mostrar o conhecimento do segredo sem revelar o segredo ou o próprio depósito anterior. Isso desvincula a retirada do depósito.

Mas há um problema de ovo e galinha com a retirada. Para executar uma transação de retirada de um endereço recém-gerado, o usuário precisa ter algum ETH nele para pagar o gás. A fonte deste ETH (tipicamente uma exchange) pode comprometer a privacidade do Tornado. A alternativa preferida é novamente usar uma rede de relays que tem as desvantagens mencionadas anteriormente.

A Abstração de Conta resolverá esse problema permitindo que o contrato Tornado aceite a transação de retirada do AA do usuário, valide o zkSnark, deduza algumas taxas de gás (do valor do depósito anterior) e então transfira o restante do valor do depósito para o endereço de retirada.

Abstração de Conta

A Abstração de Conta, conforme proposto no PEI-2938, permite que um contrato seja a conta de nível superior que paga taxas e inicia a execução da transação. Isso é alcançado introduzindo mudanças no protocolo com um novo tipo de transação AA que requer dois novos opcodes: NONCE e PAYGAS, mudanças nas regras da mempool e extensões para suportar usos avançados. Os tipos de contas continuam sendo dois (EOA e Conta de Contrato) e todas as mudanças propostas são compatíveis com transações atuais, contratos inteligentes e protocolo.

As aplicações de AA são consideradas em duas categorias: 1) Aplicações de locatário único, como carteiras de contratos inteligentes, que criam um novo contrato para cada usuário 2) Aplicações de locatário múltiplo, como tornado.cash ou Uniswap, onde vários usuários interagem com o mesmo conjunto de contratos inteligentes.

O suporte AA para aplicativos multi-inquilinos requer mais pesquisa e é proposto como trabalho futuro. Portanto, vamos focar no suporte AA para um único inquilino neste artigo.

Mudanças de Protocolo

Há um novo tipo de transação introduzido juntamente com dois opcodes de suporte de NONCE e PAYGAS. Estas são as únicas mudanças de protocolo.

Transação AA: Um novo tipo de transação AA AA_TX_TYPE é introduzido. Seu payload é interpretado como RLP([nonce, target, data]) em vez do tipo de transação existente cujo payload é RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s]).

O preço do gás omitido e o limite de gás na transação AA são especificados pelo contrato AA de destino durante a execução. A assinatura ECDSA omitida v, r, s na transação AA é substituída por verificações de verificação específicas do contrato nos dados. O endereço de destino é substituído pelo endereço do contrato de destino. O valor é omitido porque o endereço de origem para todas as transações AA é um endereço de PONTO DE ENTRADA especial (0xFFFF... FFFF) e não um EOA que tenha um valor associado a ele.

Nonces são processados de forma análoga às transações existentes, verificando se tx.nonce == tx.target.nonce. Se essa verificação falhar, então a transação é considerada inválida, mas caso contrário, tx.target.nonce é incrementado e a transação prossegue.

O custo base de gás de uma transação AA é proposto para ser 15000 em vez dos atuais 21000 (para refletir a economia de custos pela falta da assinatura ECDSA intrínseca). Além disso, as transações AA não têm um limite de gás intrínseco. Ao iniciar a execução, o limite de gás é simplesmente definido para o gás restante no bloco.

Opcode NONCE: O opcode NONCE (0x48) empurra o nonce do chamador, ou seja, o contrato alvo AA, para a pilha EVM. Os nonces são assim expostos à EVM para permitir que a verificação de assinatura seja realizada em todos os campos de transação (incluindo nonce) como parte da validação no contrato AA.

opcode PAYGAS: opcode PAYGAS (0x49) retira dois argumentos da pilha: (topo) número_da_versão, (segundo do topo) memory_start. O número_da_versão permite implementações futuras alterarem a semântica do opcode. Atualmente, o opcode tem as seguintes semânticas:

1. Verifique version_number == 0 (caso contrário, lance uma exceção)
2. Leia gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])
3. Leia gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])
4. Verifique contrato.saldo >= gas_price * gas_limit (caso contrário, lançar exceção)
5. Verifique se globals.transaction_fee_paid == False (caso contrário, lance uma exceção)
6. Verifique o quadro de execução AA == quadro de nível superior, ou seja, se a execução atual do EVM sair ou reverter, a execução do EVM da transação inteira é encerrada (caso contrário, lançar exceção)
7. Definir contrato.saldo -= gas_price * gas_limit
8. Definir globals.transaction_fee_paid = Verdadeiro
9. Defina globals.gas_price = gas_price e globals.gas_limit = gas_limit
10. Defina o contexto de execução atual como remaining_gas = gas_limit - gás já consumido

No final da execução da transação AA, (globals.gas_limit - remaining_gas)globals.gas_price é transferido para o minerador e o contrato AA é reembolsado com remaining_gasglobals.gas_price.

PAYGAS atua como um ponto de verificação de execução do EVM. Quaisquer reverter após este ponto só reverterá até aqui e então o contrato não recebe reembolso e globals.gas_limit * globals.gas_price é transferido para o minerador.

O novo tipo de transação e os dois novos códigos de operação constituem as mudanças no nível do protocolo/consenso e suas semânticas são relativamente simples de serem analisadas.

Regras da Mempool

"The mempoolrefere-se ao conjunto de estruturas de dados na memória dentro de um nó Ethereum que armazena transações candidatas antes de serem mineradas. Geth chama isso de "pool de transações"; Parity chama isso de "fila de transações". Independentemente do nome, é um pool de transações sentadas na memória esperando para serem incluídas em um bloco. Pense nisso como uma "área de espera" para transações serem aceitas em um bloco.

Atualmente, com regras fixas de validade de transações, os mineradores e outros nós precisam de esforço mínimo para validar transações em suas mempools e assim evitar ataques de DoS. Por exemplo, um minerador pode ter certeza de que uma transação realmente pagará a taxa se tiver uma assinatura ECDSA válida, nonce válido e saldo de conta suficiente. Outras transações na mempool desse minerador podem invalidar essa transação pendente apenas se forem do mesmo endereço e, ou aumentarem o nonce ou reduzirem suficientemente o saldo da conta. Essas condições são computacionalmente mínimas para dar aos mineradores e nós confiança suficiente em suas mempools para consideração de bloco ou rebroadcasting, respectivamente.

As transações AA introduzem mais complexidade com sua validade programável. As transações AA não pagam gás antecipado e dependem de seus contratos AA de destino para pagar o gás (via PAYGAS). Conceitualmente, o processamento de transações AA é dividido em duas fases: a fase de verificação mais curta (antes do PAYGAS) e a fase de execução mais longa (após o PAYGAS). Se a fase de verificação falhar (ou lançar uma exceção), a transação é inválida (assim como uma transação não-AA com uma assinatura inválida hoje), não é incluída em um bloco e o minerador não recebe taxas.

Os mineradores e nós precisam, portanto, de um mecanismo previsível para evitar a dependência da validade de uma transação AA pendente em outras transações pendentes na mempool. Caso contrário, a execução de uma transação poderia invalidar muitas/todas as transações AA na mempool, levando a ataques de DoS. Para evitar esse cenário, existem duas regras propostas a serem cumpridas (pelos mineradores e nós, mas não no próprio protocolo) em transações AA nas mempools:

Restrição de Opcode

Para evitar que a validade da transação AA dependa de qualquer estado externo ao próprio contrato AA, os seguintes opcodes são considerados inválidos na fase de verificação (ou seja, antes do PAYGAS): opcodes de ambiente (BLOCKHASH, COINBASE, TIMESTAMP, NUMBER, DIFFICULTY, GASLIMIT), BALANCE (de qualquer conta, incluindo o próprio alvo), uma chamada externa/criação para qualquer coisa que não seja o alvo ou um pré-compilado (CALL, CALLCODE, STATICCALL, CREATE, CREATE2) e acesso ao estado externo que lê código (EXTCODESIZE, EXTCODEHASH, EXTCODECOPY, DELEGATECALL) a menos que o endereço seja o alvo.

Espera-se que os nós descartem transações AA na mempool que visam contratos AA, violando essa regra de restrição de opcode. Isso garante que transações AA válidas na mempool permaneçam válidas desde que o estado do contrato AA não seja alterado.

Restrição de prefixo de bytecode

Se as transações não-AA puderem afetar o estado dos contratos AA, isso impactará a validade das transações AA na mempool. Para evitar isso, as transações AA só devem ser permitidas para contratos que tenham um AA_PREFIX no início de seu bytecode, onde o AA_PREFIX implementa uma verificação de que msg.sender é o endereço especial ENTRY_POINT das transações AA. Isso efetivamente impede que transações não-AA interajam com contratos AA.

Os nós devem esperar eliminar transações AA para contratos AA que não possuem este AA_PREFIX nos seus pontos de entrada de bytecode.

Essas duas restrições impostas aos contratos AA juntas garantem que: (1) o único estado acessível à lógica de validade de uma transação AA é o estado interno ao contrato AA e (2) esse estado só pode ser modificado por outras transações AA visando este contrato AA específico.

Uma transação AA pendente para um contrato AA só pode ser invalidada por um bloco contendo outra transação AA visando o mesmo contrato AA. No entanto, uma vez que essas não são mudanças de protocolo/consenso, os mineradores estão livres para incluir transações em um bloco que quebrem essas regras.

Extensões

As alterações de protocolo acima e as regras de mempool permitem que os contratos AA básicos implementem de forma suficiente e segura aplicativos de inquilino único, como carteiras de contratos inteligentes. Outros usos avançados que necessitam de relaxamento das regras acima ou precisam implementar aplicativos de vários inquilinos requerem mais suporte do AA na forma de extensões, tais como:

1. opcode SET_INDESTRUCTIBLE, que desativa SELFDESTRUCT e permite que contratos AA chamem bibliotecas com DELEGATECALL com segurança na fase de verificação.
2. opcode IS_STATIC, que retorna verdadeiro se o contexto atual for estático e permite que chamadores de transações não-AA substituam a restrição de prefixo de bytecode anterior e leiam valores de contratos AA com segurança.
3. Opcode RESERVE_GAS, que estabelece um limite inferior sobre o gás consumido pelo contrato AA quando invocado por uma transação não-AA que busca escrever o estado do contrato. Isso serve para forçar os atacantes a gastar uma quantidade mínima de gás para desincentivar as tentativas de invalidar quaisquer transações AA na mempool.

Há outros, como várias transações pendentes, armazenamento em cache de resultados de validação, limites de gás dinâmicos para validação e transações patrocinadas, que são necessários para dar suporte a aplicativos multi-inquilinos e provas de zk, por exemplo, Tornado Cash. Sua discussão está fora do escopo deste artigo.

Próximos Passos

A Abstração de Conta PEI-2938 está atualmente em modo de rascunho e está sendo discutida nos fóruns de pesquisa do Ethereum. O próximo passo para o PEI é ser considerado para inclusão em um dos próximos hard forks. Os autores do PEI aparentemente têm como objetivo o hard fork após Berlim (Berlim está programada provisoriamente para algum momento em início de 2021) cuja linha do tempo não está muito clara no momento. Portanto, ainda está no início do processo para PEI-2938.

Além disso, também não está claro se será necessário incluir PEI-2938 na camada base Ethereum 1 (L1). Dada a flexibilidade relativa das soluções da Camada 2 (L2) (como descrito em nosso anteriorartigo) A Abstração de Conta pode ser implementada em L2 específicos sem exigir que todo o L1 seja atualizado. No entanto, existem benefícios em ter suporte uniforme de AA no L1, mesmo que alguns L2 implementem suas próprias versões de AA. Portanto, ainda resta saber onde e como a AA será implementada.

"A abstração de conta é um pouco menos importante, porque pode ser implementada no L2 independentemente de L1 suportá-la." - Vitalik sobre as coisas que continuariam a ser importantes na camada base (em seupostagemno roadmap centrado no rollup da Ethereum).

Status: A carteira Status atualmente é uma carteira EOA que se diferencia pela inclusão de um mensageiro centrado na privacidade e habilitando integrações como pagamentos no chat ou segurança aprimorada com KeycardAs funcionalidades da carteira inteligente, como multisig e recuperação social, estão sendo consideradas, para as quais o suporte AA PEI-2938 ajudará ao remover a dependência de arquiteturas centralizadas e ineficientes baseadas em relayers, como descrito anteriormente.

A Status também está avaliando soluções L2 tanto para suportar várias cadeias em sua carteira quanto para fornecer a escalabilidade necessária para diversos casos de uso, conforme descrito anteriormente em nosso artigo. Por exemplo, Keycard está explorando um rede de pagamentoscujos requisitos de design de escalabilidade de nível de cartão de crédito e finalidade quase instantânea não são atendidos pela rede Ethereum hoje. Além disso, existem inúmeras outras iniciativas como o Programa de Indicação, Reações SNT, Tributo-para-FalareNomes ENS, todos os quais se beneficiariam da escalabilidade L2 para implantação viável e experiência do usuário razoável. Se uma solução L2 viável implementa AA, então projetos que construam nessa L2 poderão aproveitar os benefícios do AA sem depender do L1.

Resumo

Um aspecto fundamental do protocolo Ethereum é que apenas Contas de Propriedade Externa (EOAs) podem pagar taxas de gás e iniciar a execução da transação. Contas de Contrato (CAs) não podem fazer isso. A Abstração de Conta (AA) é uma proposta que visa mudar essa distinção e permitir que CAs especialmente construídas verifiquem programaticamente a validade de um novo tipo de transações de AA, decidam pagar as taxas de gás em seu nome e, assim, iniciar efetivamente sua execução sem a necessidade de um EOA.

AA tem implicações para melhorar significativamente a experiência do usuário em vários cenários, como carteiras, misturadores, ÐApps e DeFi, sem depender de arquiteturas centralizadas e ineficientes baseadas em relayers. Cenários básicos de locatário único, como carteiras de contratos inteligentes, podem ser seguramente suportados por AA com a introdução de um novo tipo de transação, dois novos opcodes e duas regras de mempool. Aplicações avançadas de vários locatários, como Tornado Cash, exigem extensões a essas mudanças de protocolo e regras de nó.

Neste artigo, motivamos a necessidade de AA no contexto das carteiras de contratos inteligentes. Destacamos aspectos-chave de AA descrevendo as mudanças no protocolo e o impacto nos nós. Abordamos algumas das extensões propostas para usos avançados e concluímos posicionando AA no contexto dos roteiros atuais do Ethereum e prioridades no Status.

Reduzir o atrito e melhorar a experiência do usuário no Web3 é uma prioridade máxima para todos os projetos neste ecossistema. A Abstração de Conta, de alguma forma, certamente pode desempenhar um papel importante nesse esforço no futuro.

Aviso Legal：

1. Este artigo foi reproduzido de [status], Encaminhe o Título Original‘Abstração de Conta (PEI-2938): Porquê & O Quê’, Todos os direitos autorais pertencem ao autor original [Rajeev Gopalakrishna]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.

2. Isenção de Responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.

3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.