O Ethereum tem dois tipos de contas: Conta Externa Proprietária (EOA) e Conta de Contrato (CA). As EOAs são controladas por uma chave privada enquanto as CAs são controladas pelo código do contrato inteligente nelas contido. As EOAs sempre foram mais privilegiadas do que as CAs porque apenas as EOAs podem iniciar a execução da transação pagando gas. A Abstração de Conta (AA) é uma proposta que permite que um contrato seja uma conta "top-level", como uma 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 interação com a blockchain Ethereum hoje em várias situações, como carteiras, misturadores, ÐApps e DeFi. AA fornece uma funcionalidade de camada base no Ethereum para decidir quando alguém pode pagar pelo gás, o que também tem implicações sobre quem paga pelo gás e como o paga.

A aplicação Status Messenger inclui uma aplicação de mensagens centrada na privacidade juntamente com uma carteira Ethereum e um navegador Web3 ÐApp. A carteira 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 multi-assinatura, recuperação social, limitação de taxa, permitir/negar lista de endereços e meta-transações sem gás. No entanto, a UX das carteiras de contrato inteligente hoje é severamente prejudicada por preços de gás flutuantes, o que não é eficientemente resolvido por intermediários de terceiros. A AA tem como objetivo resolver este problema.

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

História & Motivação

A Abstração de Conta foi inicialmente proposta como EIP-86em 2017 para implementar a “Abstração da origem da transação e assinatura” mas as origens da ideia motivadora remontam ainda mais atrás 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 maneira 'padrão' de garantir uma conta, damos os primeiros passos em direção a um modelo em que, a longo prazo, todas as contas são contratos, os contratos podem pagar pelo gas e os usuários têm liberdade para definir seu próprio modelo de segurança."

As propostas iniciais foram consideradas desafiadoras de implementar devido às muitas alterações de protocolo necessárias e às garantias de segurança a cumprir. Mais recentemente, Vitalik et al. propuseram um rascunho paraEIP-2938que descreve uma implementação muito mais simples, mantendo as mudanças mínimas no protocolo/consenso e garantindo as garantias de segurança necessárias através 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 &@SamWilsn2) de Sam Wilson & Ansgar Dietrichs (dois dos outros autores da EIP) oferecem ótimas introduções ao tópico. Este artigo destaca aspectos-chave de todas essas fontes.

Motivação: A justificação motivadora por trás do AA é muito simples, mas fundamental: as transações Ethereum hoje têm efeitos programáveis (atingidos através de chamadas a contratos inteligentes), mas têm uma 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 tiverem saldo de conta suficiente. AA atualiza as transações de validade fixa para validade programável ao introduzir um novo tipo de transação 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 dessas transações AA é determinada por um contrato inteligente alvo 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 escolhidas aleatoriamente de uma lista de 2048 palavras. Isto 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 o BIP-32 carteira.) Espera-se que o utilizador anote a frase-semente num local seguro, uma vez que poderá ser necessária mais tarde para restaurar as chaves noutra carteira. No entanto, tais carteiras são vulneráveis ao roubo da chave privada ou à perda da frase-semente, o que resulta na perda dos fundos do utilizador.

As carteiras de contratos inteligentes são implementadas on-chain via 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 de múltiplas assinaturas, recuperação social ou baseada em tempo, limitação de taxa de transações ou quantias, lista de endereços permitidos/proibidos, meta-transações sem gás e transações em lote.

Embora as carteiras de contratos inteligentes estejam expostas a riscos de segurança provenientes de contratos inteligentes vulneráveis, esse risco pode ser mitigado por testes de segurança e revisões realizadas pelo fornecedor da carteira. O risco nas carteiras EOA recai inteiramente sobre o utilizador da carteira, a quem é confiada a segurança da frase semente, sem qualquer uma das salvaguardas programáveis que são possíveis com contratos inteligentes.

Exemplos de carteiras de contratos inteligentes são Argent, Authereum, Elegante, Dharma, Gnosis Safe, MonólitoeMYKEY. A adoção de tais carteiras parece estar aumentando, como indicado abaixo gráfico.

A Argent implementa a recuperação social sem semente com o seu conceito de Guardiões que são pessoas ou dispositivos de confiança do utilizador que podem ajudar na recuperação da carteira do utilizador. A Argent também tem como objetivo possibilitar uma segurança bancária (através de funcionalidades como limites diários de transação, bloqueio de conta e contactos de confiança) combinada com uma usabilidade semelhante à do Venmo (através do uso de nomes ENS em vez de endereços e suporte para meta-transações).

Gnosis Safe é uma carteira de contrato inteligente multi-assinatura que se concentra na gestão da equipa de fundos, que requer um número mínimo (m-de-n) de membros da equipa para aprovar uma transação antes que esta possa ocorrer. Também permite assinaturas sem gás através de meta-transações.

Todas essas capacidades avançadas da carteira requerem 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 suportar meta-transações via relayers do provedor ou redes de relayers de terceiros como Rede de Postos de GasolinaEnquanto o primeiro depende normalmente de ETH comprado em bolsas centralizadas após KYC, o último visa reduzir esta fricção UX de integração transferindo o fardo do utilizador para intermediários a um custo que é compensado pelo fornecedor da carteira on-/off-chain e/ou pelo utilizador 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 de gás base extra 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 base com bases de usuários menores e garantias de disponibilidade incertas.

A Abstração de Conta permitirá que carteiras de contratos inteligentes aceitem meta-transações sem gás do usuário e paguem pelo seu gás sem depender de redes de relé. 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 mixer como tornado.cashonde@tornadoO Tornado melhora a privacidade das transações ao quebrar o elo on-chain entre endereços usando um contrato inteligente que aceita depósitos de ETH, que posteriormente podem ser retirados por um endereço diferente. Espera-se que o usuário forneça o hash de um segredo durante o depósito e depois forneça uma prova de zkSnark durante a retirada para demonstrar o conhecimento do segredo sem revelar o segredo ou o próprio depósito anterior. Isso desvincula a retirada do depósito.

Mas existe um problema do ovo e da 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 pelo gás. A fonte desse ETH (tipicamente uma exchange) pode quebrar a privacidade do Tornado. A alternativa preferida é novamente usar uma rede de retransmissão que tem as desvantagens delineadas anteriormente.

A Abstração de Conta resolverá este problema ao permitir 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 depois transfira o restante do valor do depósito para o endereço de retirada.

Abstração de Conta

A Abstração de Conta, tal como proposto no EIP-2938, permite que um contrato seja a conta de nível superior que paga taxas e inicia a execução de transações. Isto é alcançado através da introdução de alterações no protocolo com um novo tipo de transação AA que requer dois novos opcodes: NONCE e PAYGAS, alterações nas regras de mempool e extensões para suportar utilizações avançadas. Os tipos de contas continuam a ser dois (EOA e Conta de Contrato) e todas as alterações propostas são retrocompatíveis com as transações atuais, contratos inteligentes e protocolo.

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

O suporte AA para aplicações multi-inquilinos requer mais pesquisa e é proposto como trabalho futuro. Por isso, vamos focar no suporte AA para um único inquilino neste artigo.

Alterações 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: É introduzido um novo tipo de transação AA, o AA_TX_TYPE. A sua carga útil é interpretada como RLP([nonce, alvo, dados]) em vez do tipo de transação existente, cuja carga útil é RLP([nonce, preço_gas, limite_gas, para, valor, dados, 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 v, r, s omitida 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.

Os nonces são processados de forma análoga às transações existentes, verificando se tx.nonce == tx.target.nonce. Se esta 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 de 15000 em vez dos atuais 21000 (para refletir as economias de custo da falta de assinatura ECDSA intrínseca). Além disso, as transações AA não têm 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) coloca o nonce do chamador, ou seja, o contrato alvo AA, na pilha EVM. Os nonces são, assim, expostos à EVM para permitir que a verificação da assinatura seja realizada em todos os campos da transação (incluindo nonce) como parte da validação no contrato AA.

opcode PAYGAS: A opcode PAYGAS (0x49) retira dois argumentos da pilha: (no topo) número_da_versão, (segundo do topo) início_da_memória. O número_da_versão permite implementações futuras alterar a semântica do opcode. Atualmente, o opcode tem a seguinte semântica:

1. Verifique a versão_number == 0 (caso contrário, lançar exceção)
2. Ler 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 globals.transaction_fee_paid == False (caso contrário, lançar exceção)
6. Verifique o quadro de execução AA == quadro de nível superior, ou seja, se a execução atual do EVM sai ou reverte, a execução do EVM da transação inteira é terminada (caso contrário, lança exceção)
7. Definir contrato.saldo -= preço_gas * limite_gas
8. Definir globals.transaction_fee_paid = Verdadeiro
9. Definir globals.gas_price = gas_price e globals.gas_limit = gas_limit
10. Definir o contexto de execução atual 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 remaining_gas globals.gas_price.

PAYGAS atua como um ponto de verificação de execução do EVM. Quaisquer reverteres após este ponto apenas reverterão até aqui e, em seguida, o contrato não recebe reembolso e globals.gas_limit * globals.gas_price é transferido para o mineiro.

O novo tipo de transação e os dois novos opcodes constituem as alterações a nível de protocolo/consenso e a sua semântica é relativamente fácil de compreender.

Regras da Mempool

“A mempoolrefere-se ao conjunto de estruturas de dados em memória dentro de um nó Ethereum que armazena transações candidatas antes de serem mineradas. O Geth chama-o de 'pool de transações'; o Parity chama-o de 'fila de transações'. Independentemente do nome, é um pool de transações que está em memória à espera de ser incluído num bloco. Pense nele como uma 'área de espera' para transações serem aceites num bloco.

Atualmente, com regras fixas de validade de transações, os mineiros e outros nós precisam de um esforço mínimo para validar transações em sua mempool e assim evitar ataques DoS. Por exemplo, um mineiro pode ter a 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 mineiro podem invalidar esta transação pendente apenas se forem do mesmo endereço e, ou aumentar o nonce ou reduzir suficientemente o saldo da conta. Estas condições são computacionalmente mínimas para dar aos mineiros e nós confiança suficiente em suas mempools para consideração de bloco ou retransmissão, respetivamente.

As transações AA introduzem mais complexidade com a sua validade programável. As transações AA não pagam gás antecipadamente e contam com os seus contratos AA de destino para pagar o gás (via PAYGAS). Conceptualmente, o processamento das 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 (tal como uma transação não-AA com uma assinatura inválida hoje em dia), não é incluída num bloco e o mineiro não recebe taxas.

Os mineiros 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 negação de serviço (DoS). Para evitar esse cenário, existem duas regras propostas a serem aplicadas (pelos mineiros 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/criação externa para algo 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 eliminem as transações AA na mempool que visam contratos AA, quebrando esta regra de restrição de opcode. Isso garante que as 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 transações não-AA puderem afetar o estado de contratos AA, isso irá impactar na validade de transações AA na mempool. Para evitar isso, transações AA só devem ser permitidas para contratos que tenham um AA_PREFIX no início do 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.

Espera-se que os nós rejeitem transações AA para contratos AA que não tenham este AA_PREFIX nos seus pontos de entrada de bytecode.

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

Uma transação AA pendente para um contrato AA só pode ser invalidada por um bloco que contenha outra transação AA direcionada para o mesmo contrato AA. No entanto, dado que estas não são alterações de protocolo/consenso, os mineiros têm liberdade para incluir transações num bloco que quebrem estas 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 aplicações de inquilino único, como carteiras de contratos inteligentes. Outros usos avançados que necessitam de relaxamento das regras acima ou precisam implementar aplicações de inquilino múltiplo requerem mais suporte do AA na forma de extensões, como:

1. opcode SET_INDESTRUCTIBLE, que desativa SELFDESTRUCT e permite que os 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 permitir que os 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. O opcode RESERVE_GAS, que estabelece um limite inferior sobre o gás consumido pelo contrato AA quando invocado a partir de uma transação não-AA que procura escrever o estado do contrato. Isso serve para forçar os atacantes a gastar uma quantidade mínima de gás para desincentivar tentativas de invalidar quaisquer transações AA na mempool.

Existem outros, como várias transações pendentes, armazenamento em cache de resultados de validação, limites dinâmicos de gás para validação e transações patrocinadas, que são necessários para suportar aplicações multi-inquilino e provas zk, por exemplo, Tornado Cash. A discussão sobre eles está fora do âmbito deste artigo.

Próximos Passos

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

Além disso, também não está claro se será necessário incluir EIP-2938 na camada base Ethereum 1 (L1). Dada a flexibilidade relativa das soluções da Camada 2 (L2) (conforme 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 está por se ver onde e como AA é implementada.

A 'abstração de conta é algo menos importante, pois pode ser implementada no L2 independentemente de o L1 a suportar ou não.' — Vitalik sobre as coisas que continuariam a ser importantes na camada base (no seupostagemno roadmap centrado em rollup Ethereum).

Estado: A carteira Status atualmente é uma carteira EOA que se diferencia pela inclusão de um mensageiro centrado na privacidade e pela possibilidade de integrações como pagamentos em chat ou segurança aprimorada com Keycard. Recursos da carteira de contrato inteligente, como multisig e recuperação social, estão sendo considerados para os quais o suporte AA EIP-2938 ajudará a remover a dependência de arquiteturas centralizadas e ineficientes baseadas em relayers, como descrito anteriormente.

A Status também está a avaliar soluções de L2 tanto para suportar várias cadeias na sua carteira como para fornecer a escalabilidade necessária para vários casos de uso, conforme descrito anteriormente na nossa artigo. Por exemplo, a Keycard está a explorar um rede de pagamentoscuja exigência de escalabilidade ao nível de cartões de crédito e finalidade quase instantânea não é cumprida pela rede Ethereum hoje. Além disso, existem inúmeras outras iniciativas como o Programa de Referência, reacções SNT, Tribute-to-Talk e nomes ENS, todos os quais beneficiariam da escalabilidade L2 para implementação viável e experiência do usuário razoável. Se uma solução L2 viável implementa AA, então os projetos construindo nesse L2 poderão aproveitar os benefícios de AA sem depender de 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 de transações. Contas de Contrato (CAs) não podem fazer isso. A Abstração de Contas (AA) é uma proposta que visa alterar essa distinção e permitir que CAs especialmente construídas verifiquem programaticamente a validade de um novo tipo de transações 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 utilizador 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 inquilino único, como carteiras de contratos inteligentes, podem ser suportados com segurança 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 inquilinos, como Tornado Cash, exigem extensões a estas 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 do AA descrevendo as mudanças de protocolo e o impacto nos nós. Abordamos algumas das extensões propostas para usos avançados e concluímos posicionando o AA no contexto dos roteiros atuais do Ethereum e prioridades no Status.

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

Aviso legal：

1. Este artigo é reproduzido a partir de [estado], Encaminhe o Título Original ‘Abstração de Conta (EIP-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 Learnequipa e eles tratarão do assunto prontamente.

2. Responsabilidade de Isenção de Responsabilidade: As visualizações e opiniões expressas neste artigo são exclusivamente as 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, é proibido copiar, distribuir ou plagiar os artigos traduzidos.