A abstração de conta busca melhorar as experiências do usuário e do desenvolvedor em todo o ecossistema do Ethereum. Além de tornar as experiências on-chain mais acessíveis e agradáveis ​​para os usuários, também capacita os desenvolvedores a fazerem coisas mais poderosas no Ethereum e atenderem os usuários de maneiras ainda mais significativas.

Nossa classificação das abordagens para abstração de conta é a seguinte:

1. Melhoria/programabilidade da EOA: Isso inclui mudanças no nível do protocolo que permitem que as EOAs (Contas de Propriedade Externa) redefinam a porção lógica de execução de suas regras de validade. Como é bem conhecido na comunidade de desenvolvimento, as EOAs são contas normalmente associadas a usuários finais. Portanto, as soluções que se enquadram nessa abordagem capacitarão as contas de usuários finais com mais controle sobre que tipo de ações eles podem autorizar, em comparação com como isso pode ser gerenciado hoje.
2. Conversão/migração EOA: Esta abordagem inclui propostas que buscam a conversão completa de EOAs para CAs (contas de contrato). A ideia integral desta abordagem é que as contas de contrato já oferecem a maioria dos benefícios oferecidos pelas contas inteligentes, portanto, não deveria haver necessidade de complicar as coisas ainda mais; todos deveriam simplesmente usar uma conta de contrato como sua conta principal (através de carteiras de contratos inteligentes).

Esta abordagem apresenta mecanismos que permitem a um EOA transicionar para um CA, sem ter que mover seus ativos, como EIP 7377eEIP 5003 (quando considerado junto com EIP 3074).

1. Contas inteligentes: Este grupo de propostas inclui designs que permitem que EOAs e CAs se comportem como "contas inteligentes", permitindo que eles redefinam totalmente suas regras de validade.

Várias propostas foram feitas anteriormente para a criação de contas inteligentes e a abstração de conta consagrada no nível do protocolo;EIP-86eEIP-2938são alguns dos mais citados. No entanto, houve muita resistência devido à complexidade percebida introduzida por este design e à opinião majoritária de que o Ethereum não está pronto para tanta complexidade.

Após o ressurgimento do assunto por Vitalik após The Merge,ERC-4337foi proposta como uma versão opcional do padrão de conta inteligente, semelhante à infraestrutura PBS (Proposer-Builder Separation) para MEV (Maximal Extractable Value). Assim, os usuários que buscam acessar os benefícios das contas inteligentes poderiam simplesmente usar o pipeline ERC-4337 para redefinir a lógica de suas contas e as regras de validade das transações em estruturas referidas como UserOperation (ou UserOps, para abreviar).

O ERC 4337 traz os benefícios das contas inteligentes para o Ethereum atual sem consagrar nenhuma das complexidades, funcionando como uma alternativa fora do protocolo para contas inteligentes consagradas. No entanto, isso não significa que a infraestrutura seja ótima em seu estado atual, já que sua própria complexidade ainda é um ponto considerável de falha.

Para lidar com essa complexidade, RIP 7560foi elaborado como uma versão consagrada da infraestrutura ERC 4337 em toda a Ethereum e suas camadas L2, para que herde os esquemas de resistência a sybil da rede, em vez de ter que definir um novo conjunto de regras (como o ERC 4337 faz comERC 7562.

Neste relatório, estaremos focados em explorar a programabilidade do EOA, avaliando as várias EIPs que descrevem soluções ao longo dessa linha e discutindo seus méritos e desvantagens. Na Parte 2 e 3 desta série, abordaremos as duas classes restantes de abstração de conta sendo exploradas dentro do Ethereum.

Um Guia sobre Contas e Transações Ethereum

Para descobrir o que pode ser abstraído, precisamos de uma imagem (um tanto) completa do design atual da conta. Esta seção servirá principalmente como uma revisão do que as contas no Ethereum realmente são e como suas transações são validadas e executadas.

As contas Ethereum são entidades com um saldo de ether (ETH) e a capacidade de enviar transações na blockchain Ethereum. Eles são representados como um "endereço" hexadecimal de 42 caracteres, que serve como um ponteiro exclusivo para as participações e transações da conta.

Um endereço atua como uma chave na trie de estado do blockchain. Os nós folha desta trie são estruturas de dados de conta que podem ser decompostas em quatro campos:

1. nonce: Um contador linear usado para indicar o número de transações de saída iniciadas por uma conta. Também é crucial para evitar ataques de repetição.
2. saldo: A quantidade de ether (ETH) denominada em wei de propriedade de uma conta.
3. codeHash: Um hash do código executável EVM contido em uma conta. O EVM (Máquina Virtual Ethereum) é o ambiente de execução exclusivo do Ethereum responsável por lidar com transições de estado complexas além de transações simples de 'envio'. O conteúdo do código de uma conta é imutavelmente programado para realizar formas específicas de transição de estado na blockchain do Ethereum, através do EVM.
4. storageHash: Um hash da raiz de armazenamento de uma conta, usado para representar o conteúdo de armazenamento de uma conta como um hash de 256 bits de um nó raiz de árvore patricia merkle. Simplesmente, é um hash dos dados de variáveis de estado relacionados ao conteúdo do código de uma conta.

Os conteúdos destes quatro campos são usados para definir o tipo de conta e, por fim, definir a extensão de suas funcionalidades. Assim, os dois tipos de contas Ethereum são:

1. Contas de Propriedade Externa (EOAs) - que são inicializadas como um par de chaves criptográficas:

• Uma chave privada que é um caractere hexadecimais criptografável e comprovadamente aleatória de 64 dígitos, e seu complemento correspondente;
• Uma chave pública que é derivada da chave privada usando o ECDSA (Elliptic Curve Digital Signature Algorithm).

EOAs têm campos codeHash e storageHash vazios e só podem ser controlados por quem possui as chaves privadas. Seus endereços podem ser obtidos a partir da chave pública correspondente, prefixando "0x" aos últimos vinte caracteres do hash keccak-256 da chave pública da conta.

1. Contas de Contrato (CAs) - que só podem ser criadas por um EOA pré-existente. Elas são inicializadas devido a um EOA implantando conteúdo de código executável no EVM. Este conteúdo de código (armazenado como codeHash) é consagrado no EVM e é responsável por controlar a conta, definindo sua lógica e interações.

Suas transações são completamente baseadas em pull e baseadas na lógica do código implantado.

Uma vez que essas contas só podem ser controladas pelo conteúdo de seu código, elas não precisam de uma chave privada e têm apenas uma chave pública. Assim, qualquer agente que tenha a capacidade de atualizar/mudar o conteúdo do código de uma conta de contrato seria capaz de acessar seu saldo.

O endereço de um CA é derivado do endereço do seu criador e do seu nonce até o ponto de implantação do contrato.

Transações

Recentemente descrevemos contas como entidades que possuem a capacidade de enviar transações através do Ethereum. Podemos, portanto, entender que um propósito primário de uma conta é enviar e receber transações, enquanto o blockchain atua como um livro-razão que registra o histórico de transações, além de descrever como as transações alteram os campos da conta com base nas regras descritas na especificação do protocolo blockchain.

Então, o que são essas “transações”?

Transações são operações enviadas de uma conta, que causam uma mudança no 'estado' da rede. São instruções criptograficamente assinadas de contas, que resultam em uma atualização do estado em toda a rede quando executadas.

A permissão vem com o custo de incentivos perversos, para lidar com isso, diretrizes rigorosas (ou regras de validade) devem ser definidas para interações em tais ambientes.

Nesse contexto, as transações devem seguir determinadas regras de validade para serem consideradas válidas e executadas. A maioria dessas regras de validade é implementada por meio de restrições colocadas na conta que envia a transação e varia com base no tipo de conta que é.

Contas e Validade de Transação

No Ethereum, as EOAs são otimizadas para a usabilidade, pois são voltadas para o usuário final. Elas têm a capacidade de enviar transações de maneira específica e funcionam perfeitamente de forma autônoma. Elas também podem ser criadas localmente, sendo o método mais comum o uso de provedores de carteira, como MetaMask, Rainbow, Rabby, etc.

Por outro lado, as contas de contrato só podem enviar transações permitidas por sua lógica, em resposta a serem "chamadas". Além disso, eles só podem ser criados por um EOA que tenha um saldo suficiente para pagar por seu armazenamento estatal.

Uma descrição mais avançada seria que EOAs só podem manter um saldo, enquanto CAs podem manter tanto um saldo quanto a lógica que dita como esse saldo pode ser gasto.

Essas propriedades são devidas aos seguintes parâmetros lógicos que definem as regras às quais as transações de uma conta devem aderir:

1. Lógica de autenticação - Usada para definir como uma conta prova sua identidade para a rede ao alterar seu saldo e/ou lógica.
2. Lógica de autorização - Usada para definir a política de acesso de uma conta, ou seja, quem pode acessar e fazer alterações no saldo e/ou lógica da conta.
3. Lógica de nonce - que define a ordem em que as transações de uma conta devem ser executadas.
4. Lógica de pagamento de gás - Usada para definir a parte responsável por liquidar a taxa de gás de uma transação.
5. Lógica de execução - Usada para definir quais formas de transações uma conta pode enviar, ou como uma transação deve ser executada.

Esses parâmetros são projetados para serem rígidos para EOAs assim:

• A autenticação e autorização são fornecidas por uma chave privada baseada em ECDSA, ou seja, um usuário que deseja enviar uma transação de sua EOA deve usar sua chave privada para acessar a conta e assim comprovar que ele tem o direito de realizar quaisquer alterações em seu saldo.
• A lógica do nonce implementa um esquema de contador sequencial, que permite que apenas uma transação por nonce único seja executada sequencialmente por conta.
• A lógica de pagamento de gás especifica que a taxa de gás para transações deve ser liquidada pela conta do remetente/de origem.
• A lógica de execução especifica que as EOAs só podem enviar os seguintes formulários de transação:

1. Transferências regulares entre duas EOAs.
2. Implantação de contrato.
3. chamadas de contrato que visam a lógica da conta do contrato implantado.

De maneira mais geral, a lógica de execução das EOAs as restringe a uma transação por assinatura válida.

Por outro lado, os CAs têm mais flexibilidade em relação a esses parâmetros:

• Autenticação não é necessária, pois suas transações são consequenciais/puxadas por natureza.
• Autorização para CAs pode assumir duas formas:

1. Capacidade de 'chamar' o código de conteúdo do CA (ou executar seu contrato inteligente), que depende da lógica do contrato inteligente da conta e de suas invariáveis.
2. Capacidade de fazer alterações no código de conteúdo das ACs, o que depende principalmente se o código de conteúdo é atualizável ou não.

Na maioria dos casos práticos, a lógica usada neste caso é um esquema de assinatura múltipla que estipula que um M de N assinaturas válidas (onde M < N) é necessário de contas específicas (comumente EOAs) para que uma alteração na lógica do CA seja válida.

• Sua ordenação de transação é baseada em nonce de forma flexível. O próprio CA é capaz de enviar o máximo de transações possível para o maior número possível de chamadores diversos, no entanto, cada chamador é limitado com base em suas próprias capacidades.
• O pagamento de gás é comumente tratado pelo chamador da lógica do CA.
• A lógica de execução dos CAs é mais diversa para permitir melhorias na UX, como transações multicall e transações atômicas.

Avaliando essas características, observamos que cada tipo de conta é projetado para ter uma compensação entre autonomia e programabilidade.

EOAs têm autonomia total, mas programabilidade limitada; eles podem autorizar e enviar transações sempre que desejarem, mas essas transações devem seguir um formato rígido para serem consideradas válidas. CAs têm programabilidade total (limitada apenas pelo design do EVM) mas autonomia limitada; suas transações não precisam seguir nenhum formato rígido, mas só podem ser enviadas devido à sua lógica ser chamada primeiro.

Na subseção a seguir, estudaremos agora as implicações dessas escolhas de design, a fim de entender completamente a proposição de cada EIP discutida ao longo desta série.

Dilema da conta do Ethereum

Agora que temos um conhecimento um tanto sucinto das funcionalidades das diferentes contas, podemos identificar facilmente seus pontos de venda, bem como as questões que apresentam tanto para a experiência do usuário quanto para a do desenvolvedor na Ethereum.

Como mencionamos anteriormente, EOAs são projetadas como contas de primeira classe voltadas para usuários finais. As aplicações são projetadas para interagir facilmente com elas, não há quase nenhuma complexidade nelas e, é claro, não há custo para criar uma. No entanto, sua simplicidade vem com uma perda significativa de novidade, pois são projetadas para serem estritamente determinísticas.

Algumas das preocupações em torno delas são:

1. Susceptibilidade a ataques quânticos – O esquema de assinatura ECDSA usado pelo par de chaves não é resistente a ataques quânticos, e com um cronograma otimista de 5 a 10 anos para a realização de sistemas quânticos industriais, isso representa uma ameaça significativa para o Ethereum e suas aplicações, que dependem fortemente do esquema ECDSA para provas criptográficas e segurança.
2. Falta de expressão - O formato rígido das regras de validade das EOAs elimina a capacidade dos usuários de expressarem suas transações de forma mais sucinta através de recursos como atomicidade e agrupamento de transações, e delegação de transações.
3. Autossustentabilidade – Todo mundo teve sua cota justa de momentos de "fiquei sem gás" no meio de uma transação. Isso se deve à exigência de que as EOAs liquidem o gás para suas transações por si mesmas, o que não seria muito interessante se o ether (ETH) não fosse a única moeda de gás aceitável. Embora este seja um problema geral com máquinas de estado baseadas em contas (e até mesmo baseadas em UTXO), o Ethereum sempre quis ser diferente.

Nem todos querem (ou seriam capazes de) sempre manter ETH (quero dizer, olhe para a ação de preço), então as soluções viáveis seriam permitir várias moedas de gás (muito difícil, quebra muitas invariantes conforme descrito na seção "Moeda").aqui), ou permitir que os pagamentos de gás sejam liquidados por outra conta que não seja a origem da transação.

No outro extremo do espectro de contas, CAs visam desenvolvedores e uma base de usuários mais técnica. Eles servem como veículos para contratos inteligentes (ou seja, consideramos contratos inteligentes como o conteúdo lógico ou de código contido neles) e, portanto, podem implementar formatos de transação inovadores conforme habilitado pela EVM.

No entanto, para todas essas características, eles são contas de segunda classe glorificadas, pois não têm autonomia. Alguns de seus inconvenientes são os seguintes:

1. Total falta de autonomia - Os CAs não podem iniciar uma transação, eles só podem enviar transações em resposta a serem invocados de uma maneira muito específica.
2. Susceptibilidade a erros humanos em sua lógica - A falta de rigidez muitas vezes leva a uma definição incorreta de invariantes e outras lógicas semelhantes, o que levou a bilhões de dólares em perdas devido a exploits e hacks de contratos inteligentes. No entanto, este é quase um tópico completamente diferente que está além do escopo aqui.

Após analisar as escolhas de design que levaram aos problemas definidos nesta subseção, agora podemos prosseguir para avaliar as soluções propostas.

Uma linha do tempo da abstração de conta

O conceito de abstração de contas (por meio de contas inteligentes, pelo menos) sempre foi parte integrante do roteiro do Ethereum. A lenda é que a complexidade que envolve sua implementação ameaçou atrasar ainda mais o lançamento do Ethereum, e por isso foi descartado para o design atual, com contas diferentes oferecendo funcionalidades diferentes. Foi adiado novamente pelo foco do Ethereum no The Merge e agora está ressurgindo como parte principal da próxima grande atualização da rede - Pectra. No entanto, sua complexidade ainda é considerada uma desvantagem significativa que impede sua consagração, especialmente porque o Ethereum mudou para um roteiro centrado em rollup.

Os requisitos agora são duplos:

1. Os padrões de conta precisam ser mais expressivos, mas sem perda de autonomia. Um novo padrão que sela a divisão entre os padrões EOA e CA.
2. O novo padrão tem que preencher a lacuna entre EOAs e CAs, enquanto permanece totalmente compatível em todos os ecossistemas Ethereum e L2.

Intuitivamente, esse conceito desempenha um papel maior no contexto da abstração de contas e interoperabilidade, no entanto, nosso escopo ao longo deste relatório se limita às iniciativas técnicas adotadas para alcançar a própria abstração de contas.

A abstração de conta tem como objetivo combinar as melhores características das EOAs e CAs em um novo padrão de conta - contas inteligentes, que permitem a separação total ou parcial das regras de validade de qualquer conta em uma lógica de validação e uma de execução; para que as contas possam definir suas próprias regras de validade - conforme permitido pelo EVM - assim como as contas de contrato, mantendo-se totalmente autônomas como as contas de propriedade externa.

Há frequentemente confusão em torno das diferenças entre contas inteligentes e carteiras de contratos inteligentes, por isso vamos descrever explicitamente quais são essas diferenças abaixo:

• Contas inteligentes são contas Ethereum que são concebidas para fornecer partes iguais de programabilidade e autonomia. A ideia é que tanto EOAs quanto CAs podem se tornar contas inteligentes simplesmente utilizando algum mecanismo (por exemplo, ERC 4337) que lhes permita substituir suas regras de validade impostas pela rede por regras de validade feitas sob medida, conforme considerem adequado.
• Carteiras de contratos inteligentes, por outro lado, são simplesmente provedores de carteiras que servem como interfaces para contas de contrato (sim, uma carteira não é uma conta).

A comercialização das carteiras de contratos inteligentes facilitou a adoção de ACs por um mercado mais amplo, permitindo que usuários menos técnicos aproveitem os recursos que eles oferecem. No entanto, eles ainda enfrentam as armadilhas associadas aos ACs.

Voltando à conversa; tínhamos discutido anteriormente os parâmetros que são usados para definir as regras de validade das transações das contas:

• Autenticação
• Autorização
• Lógica de nonce
• Lógica de pagamento de gás
• Lógica de execução

Os valores dos quatro primeiros parâmetros podem ser coletivamente referidos como lógica de validação de uma conta, que são verificações que ocorrem antes do início da execução de uma transação.

O último parâmetro define como a execução da transação deve proceder.

Na introdução, fornecemos uma visão geral de alto nível da atual paisagem AA na forma de uma classificação para os vários designs propostos. Agora vamos nos concentrar na primeira classe de soluções para o dilema de conta do Ethereum - programabilidade EOA.

EOAs programáveis

O maior atrativo do Ethereum é seu ecossistema DeFi jovem, mas vibrante, que apresenta uma variedade de aplicativos descentralizados que são seus principais pontos de liquidez. A maioria desses DApps é otimizada para atender a EOAs, tornando-as difíceis de interfacear com CAs e, eventualmente, contas inteligentes. Embora as carteiras de contratos inteligentes ajudem as CAs nesse caso, elas têm suas próprias limitações e uma UX completamente diferente.

Uma solução temporária em estudo enquanto tanto DApps quanto provedores de carteira se adaptam ao padrão de contas inteligentes, é fornecer melhorias temporárias às EOAs que permitem que elas superem a maioria de suas restrições impostas, seja sua validação ou lógica de execução.

Abaixo, vamos analisar as especificações de três EIPs principais que fornecem rotas acionáveis para a programabilidade de EOA; a partir do menos conhecido EIP 5806, para os ambiciososEIP 3074e finalmente para o vitoriosoEIP 7702.

Programabilidade via EIP-5806

Esta proposta busca trazer mais funcionalidade para o padrão EOA, permitindo que ele faça chamadas de delegação para a lógica da conta do contrato (seu smart contract). Isso faz com que o smart contract seja executado efetivamente no contexto do EOA chamador, ou seja, o EOA continua no controle de sua lógica de validação, enquanto sua lógica de execução é tratada pela lógica correspondente do CA.

Antes de prosseguirmos, vamos fazer uma viagem pela memória da evolução do Ethereum até agoraEIP-7.

A EIP-7 propôs a criação do opcode 0xf4/DELEgateCALL, que é usado para enviar chamadas de mensagem para uma conta principal com a lógica de uma conta secundária, mantendo os valores dos campos [sender] e [value] da conta principal.

Em outras palavras, a conta principal “ herda” (ou empresta, se preferir) a lógica da conta secundária por algum tempo especificado na chamada de mensagem, para que a lógica desta última seja executada no contexto da primeira.

Este opcode permitiu aos desenvolvedores de dApp dividir a lógica de sua aplicação em vários contratos inteligentes mantendo a interdependência, para que pudessem contornar facilmente as barreiras de tamanho de código e de gás.

EIP-5806 resumido

Ok, então quais chamadas de delegado permitem que os CAs sejam interdependentes? Bem, o EIP-5806 usa o EIP-7 como inspiração para propor a expansão da funcionalidade de chamada de delegado para EOAs também; ou seja, vamos permitir que os EOAs também sejam interdependentes com os CAs, porque não.

Especificações

EIP 5806 introduz um novocompatível com EIP-2718tipo de transação que é empacotado da seguinte forma:

rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s]).

Essas transações são projetadas de forma que o campo [to] - que representa o endereço do destinatário - só possa aceitar endereços como entradas de 20 bytes, incapacitando o remetente de usar o opcode CREATE.

A motivação por trás de cada componente do esquema RLP são as seguintes:

• chainID: O identificador compatível com EIP-115 da cadeia atual é preenchido com 32 bytes. Esse valor fornece proteção contra ataques de repetição, para que as transações na cadeia original não sejam replicadas trivialmente em cadeias EVM alternativas com um histórico semelhante e menos segurança econômica.
• nonce: Um identificador único para cada transação que também fornece proteção contra ataques de repetição.
• max_priority_fee_per_gas e max_fee_per_gas: Os valores da taxa de gás que uma transação EIP-5806 deve pagar para ordenação e inclusão, respectivamente.
• limite_de_gas: A quantidade máxima de gás que uma única transação do tipo 5806 pode consumir.
• destino: O destinatário da transação
• dados: O conteúdo do código executável
• access_list: Agentes condicionalmente autorizados a executar transações EIP-5806.
• signature_y_parity, signature_r e signature_s: três valores que juntos representam uma assinatura secp256k1 sobre a mensagem - keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).

Embora o empacotamento de transações EIP-5806 em envelopes EIP-2718 permita que sejam altamente retrocompatíveis, as EOAs não são equivalentes às CAs. Portanto, certas restrições devem ser definidas na forma como um EOA utiliza chamadas delegadas para evitar quebras de invariantes.

Essas restrições são direcionadas aos seguintes opcodes:

• SSTORE/0x55: Este opcode permite que uma conta salve um valor no armazenamento. Ele é restrito em transações EIP-5806 para evitar que EOAs definam/acessam armazenamento usando chamadas de delegação, evitando assim possíveis problemas que possam surgir no futuro devido à migração de contas.
• CREATE/0xF0, CREATE2/0xF5 e SELFDESTRUCT/0xFF: Esses opcodes permitem extensivamente que o chamador crie uma nova conta. O acesso a eles é restrito para evitar a alteração de um nonce de EOA em um quadro de execução diferente (criação/destruição de contrato neste caso) enquanto ele está realizando uma transação EIP-5806, a fim de evitar a invalidação da expectativa de que as transações carregam nonces consecutivos.

Potencial Aplicabilidade/Casos de Uso

A aplicabilidade primária do EIP 5806 é a abstração de execução para EOAs. Permitir que os EOAs interajam de forma confiável com contratos inteligentes além de chamadas simples para sua lógica lhes concede recursos como:

• Execução condicional de transações
• Lote de transações
• Transações multicall (por exemplo, aprovar e chamar)

Críticas

As mudanças propostas pelo EIP-5806, embora habilitem recursos necessários, não são particularmente inovadoras; sua existência é em grande parte baseada em um EIP-7 já funcional. Isso permite que ele evite muitos obstáculos potenciais para aceitação.

Uma das principais preocupações levantadas em seus primeiros dias foi o risco potencial de permitir que EOAs acessem o armazenamento e o alterem, assim como os CAs fazem atualmente. Isso quebra muitas invariâncias consagradas na rede em relação à forma como EOAs devem transacionar, e foi tratado introduzindo as restrições mencionadas na seção anterior.

Uma segunda crítica (que é um pouco uma faca de dois gumes) é a simplicidade do EIP-5806; há algum sentimento de que as recompensas devido à aceitação do EIP-5806 podem não valer o custo, uma vez que só permite a abstração da execução e não muito mais. Todas as outras restrições de validade permanecem definidas em rede para EOAs que optam pelo EIP-5806, em contraste com outros EIPs um pouco semelhantes que discutimos nas subseções a seguir.

Programabilidade através do EIP-3074

O EIP-3074 propõe permitir que as EOAs deleguem a maior parte de sua lógica de validação para contas de contrato especializadas, chamadas de invocadoras, sobrepondo a lógica de autorização destas últimas sobre a deles para formas específicas de transações.

Isso é alcançado assinando sua política de acesso a um contrato invocador, que se torna responsável por definir a política de acesso da EOA.

Esta PEI propõe a adição de dois novos opcodes ao EVM:

• [AUTH] que define uma variável de contexto [autorizada] conta para agir em nome de uma segunda conta de [autoridade], com base na assinatura ECDSA desta última.
• [AUTHCALL], que envia/implementa chamadas para a conta de [autoridade] de/da conta [autorizada].

Esses dois opcodes permitem que um EOA delegue o controle a uma CA pré-estabelecida e, assim, atue como um por meio dela, sem ter que implantar um contrato e incorrer nos custos e externalidades associados a isso.

Especificações

O EIP-3074 permite que as transações usem um formato de assinatura [MAGIC] para evitar colisões com outros formatos de assinatura de transações. A conta ativa para a qual as instruções [AUTHCALL] são passadas é definida como um campo de variável de contexto chamado [autorizado], que persiste apenas por meio de uma única transação e deve ser redefinido para cada novo [AUTHCALL].

Antes de abordar as complexidades de cada opcode, estas são as entidades envolvidas em uma transação EIP-3074:

• [autoridade]: A conta principal de assinatura (um EOA) que delega acesso/controle para uma segunda conta, que normalmente é uma conta de contrato.
• [autorizado]: A conta para a qual as instruções [AUTHCALL] devem ser passadas para execução. Em outras palavras, é a conta na qual a lógica de um [AUTHCALL] é executada, em nome da [autoridade], usando restrições definidas por um [invocador].
• [invoker]: Um contrato subsidiário destinado a gerenciar as interações entre a conta [autorizada] e a lógica do [AUTHCALL], especialmente nos casos em que a lógica primária do código do contrato do último é patrocínio de gás.

Os contratos Invoker recebem mensagens [AUTH] com um valor [COMMIT] de [autoridade]; esse valor define as restrições que a conta deseja impor à execução das instruções [AUTHCALL] por [autorizado].

Assim, os invocadores são responsáveis por garantir que o [contract_code] definido em uma conta [autorizada] não seja malicioso e tenha a capacidade de satisfazer as invariantes estabelecidas pela conta de assinatura principal em um valor [COMMIT].

O opcode [AUTH] tem três entradas de elemento de pilha; ou mais simplesmente — é definido por três entradas que computam uma única saída. Essas entradas são:

1. autoridade: qual é o endereço do EOA que gera a assinatura
2. offset
3. comprimento

Os dois últimos inputs são usados para descrever uma faixa de memória modificável de 0 a 97, onde:

1. [memória(off-set : off-set+1)] - [yParidade]
2. [memória(deslocamento+1 : deslocamento+33] – [r]
3. [memória(offset+33 : offset+65)] - [s]
4. [memória(deslocamento+65 : deslocamento+97)] - [COMMIT]

As variáveis [yParity], [r] e [s] são coletivamente interpretadas como uma assinatura ECDSA, [magic], na curva secp256k1 sobre a mensagem:

[keccak256 (MAGIC || chainID || nonce || invoker address || COMMIT)]

onde:

• [MAGIC] é uma assinatura ECDSA resultante da combinação das variáveis:
  • [chainID], que é o identificador compatível com EIP 115 da cadeia atual usado para fornecer proteção contra ataques de replay em cadeias EVM alternativas com uma história semelhante e menos segurança econômica.
  • [nonce] que é o nonce atual do endereço do remetente da transação, preenchido com zeros à esquerda até 32 bytes.
  • [invokerAddress] que é o endereço do contrato que contém a lógica para a execução de [AUTH].
• [COMMIT] é um valor de 32 bytes usado para especificar condições adicionais de validade da transação na lógica de pré-processamento do invocador.

Se a assinatura calculada for válida e o endereço do assinante for igual a [authority], o campo [authorized] é atualizado para o valor fornecido por [authority]. Se algum desses requisitos não for atendido, o campo [authorized] permanece inalterado em seu estado anterior, ou como um valor não definido.

O custo de gás para este opcode é calculado como a soma de:

1. Uma taxa fixa para o pré-compilador [ecrecover] e um extra para um hash keccak256 e alguma lógica adicional, avaliado em 3100 unidades
2. Uma taxa de expansão de memória que é calculada de forma semelhante ao opcode [RETURN] e aplicada quando a memória é expandida além do intervalo especificado da alocação atual (97 unidades)
3. Um custo fixo de 100 unidades incorrido para uma [autoridade] quente e 2600 unidades para uma fria para evitar ataques devido à precificação incorreta de opcodes de acesso ao estado.

[AUTH] é implementado para não modificar a memória e recebe o valor de [authority] como argumento para que seja fácil verificar seu valor a partir da assinatura fornecida.

O opcode [AUTHCALL] tem sete entradas de elementos de pilha que são usadas para calcular uma única saída de elemento de pilha.

Tem a mesma lógica que o opcode [CALL], ou seja, é usado para enviar chamadas de mensagem para uma conta e acionar lógica específica em seus contratos. A única divergência em sua lógica é que [AUTHCALL] é projetado para definir o valor do [CALLER] antes de prosseguir com a execução.

Assim, [AUTHCALL] é usado pela [autoridade] para acionar comportamento específico do contexto em [autorizado] com verificações lógicas seguindo da seguinte forma:

1. Verifique o valor de [autorizado]. Se não configurada, a execução é considerada inválida e o quadro é imediatamente encerrado. Isso ajuda a evitar cobranças injustas devido a falhas sem precedentes.
2. Verifica o custo de gás do comportamento pretendido de [authorized].
3. Verifica o valor compatível com EIP-150 do operando [gas].
4. Verifica a disponibilidade do custo total do gás –[valor]– no saldo da [autoridade].
5. A execução ocorre após a dedução de [valor] do saldo da conta de [autoridade]. Se [valor] for maior que o saldo deles, a execução é invalidada.

O custo de gás para [AUTHCALL] é calculado como a soma de:

• Um custo fixo para chamar [warm_storage_read]
• O custo de expansão da memória é de [memory_expansion_fee]; que é calculado de forma semelhante ao custo de gás para o opcode [CALL]
• Um custo dinâmico [dynamic_gas]
• O custo de execução da subchamada [subcall_gas]

Os dados retornados de uma [AUTHCALL] são acessados através de:

• [RETURNDATASIZE] - que coloca o tamanho do buffer de dados de retorno na pilha de saída
• [RETURNDATACOPY] - que copia os dados do buffer de dados de retorno para a memória.

Para juntar tudo isso com muito menos jargão técnico; as transações do Ethereum normalmente especificam dois valores:

1. tx.origin - que fornece autorização para a transação.
2. msg.sender - no qual a transação realmente ocorre.

Em EOAs, como mencionado anteriormente, a autorização está intimamente ligada à execução, ou seja, (tx.origin == msg.sender). Este simples invariante dá origem à maioria dos problemas que explicamos na subseção "Contas e Validade da Transação" deste relatório.

mensagens [AUTH] de [autoridade] permitem que ela compense a função tx.origin para [autorizado], permanecendo como msg.sender. Também permite que defina restrições a esse privilégio usando um valor [COMMIT].

[AUTHCALL] em seguida, permite que [authorized] acesse a lógica de um contrato, usando um [invoker] como intermediário para garantir que o contrato que deseja acessar seja inofensivo. Ou seja, para cada [AUTHCALL], [authorized] deve especificar um [invoker] específico para o seu [COMMIT].

Potencial Aplicabilidade/Casos de Uso

EIP 3074 é principalmente responsável por permitir que EOAs deleguem sua lógica de autorização para uma conta diferente, no entanto, seu design aberto permite muito mais em diferentes contextos.

Toda a lógica de validação de um EOA pode ser abstraída aplicando várias restrições/inovações ao invocador conforme necessário, alguns dos possíveis designs com base na sua lógica alvo incluem:

• Lógica de nonce: EIP-3074 permite que o nonce do EOA permaneça intocado após o envio de uma mensagem [AUTH], enquanto seu nonce para cada [AUTHCALL] depende de com quem ele está interagindo. Dessa forma, ele permite o paralelismo de nonce para EOAs, para que possam enviar vários [AUTHCALL]s não sobrepostos conforme desejarem.
• Lógica de pagamento de gás: Conforme especificadoNo EIP, os invocadores podem ser projetados para permitir patrocínio de gás. Como tal, as taxas de gás para um [COMMIT] do usuário podem ser deduzidas da origem da transação, ou de qualquer conta de apoio, seja pessoal ou de um relé baseado em serviço (serviços de patrocínio de gás).

Além disso, a lógica de execução é intuitivamente abstraída; afinal, o invocador (que é um CA) agora é responsável por executar solicitações de transação em nome do EOA.

Críticas

• Centralização do Invoker

Citaçãoum de seus autores: "Eu não esperaria que as carteiras expusessem funcionalidades para assinar sobre invocadores arbitrários ...". Talvez o maior problema colocado pela iniciativa 3074 seja que a inovação acima dela tenderá muito facilmente para fluxos de negócios permissivos e proprietários; assim como as iterações atuais dos mercados MEV e PBS do Ethereum.

Por padrão, os contratos invoker precisam ser amplamente auditados para evitar ataques ainda piores do que os atualmente possíveis. Isso inevitavelmente levará a um ecossistema onde apenas um punhado de contratos invoker desenvolvidos por figuras influentes será adotado como padrão para desenvolvedores de carteiras. Assim, isso se resume a um tradeoff entre seguir o caminho duro e descentralizado de constantemente auditar e apoiar contratos invoker arriscando a segurança dos usuários; ou simplesmente adotar contratos invoker de fontes estabelecidas e respeitáveis com melhores garantias para a segurança do usuário e menos supervisão sobre a segurança do contrato.

Outro aspecto desse ponto é a função de custo associada à concepção, auditoria e comercialização de um invocador funcional e seguro. Equipes menores quase sempre serão superadas por organizações maiores – especialmente na frente de marketing – que já têm alguma reputação estabelecida, mesmo que seu produto seja melhor.

• Problemas de Compatibilidade Futura

EIP-3074 consolida o esquema de assinatura ECDSA, uma vez que ainda é considerado mais válido do que o esquema de autorização introduzido através do invoker. Embora haja argumentos de que a resistência quântica atualmente não é um problema definitivo, e que há muito pior em jogo em um futuro onde o ECDSA é corrompível; o objetivo um tanto implícito do Ethereum é sempre estar à frente de tais problemas. Sacrificar potencialmente a resistência quântica e à censura por melhorias marginais na UX pode não ser a melhor escolha num futuro próximo.

Outro ponto sobre o argumento de compatibilidade futura é que, enquanto os benefícios do 3074 ainda estavam sendo avaliados, o ERC-4337 (que não requer nenhuma mudança de protocolo) agora tem um ótimo mercado, então você também precisa ser compatível com ele para evitar a compartimentalização dos ecossistemas.

Mesmo com o roadmap de abstração de conta nativa, os opcodes [AUTH] e [AUTHCALL] eventualmente se tornariam obsoletos no EVM, introduzindo uma grande quantidade de dívida técnica ao Ethereum para entregar uma melhoria marginal na experiência do usuário.

• Esquema de Irrevogabilidade ECDSA

Depois de enviar uma mensagem [AUTH] e delegar controle, espera-se que o EOA evite o esquema usual de autorização de chave privada, pois o envio de uma transação "normal" faz com que a autorização delegada a cada invocador seja revogada.

Assim, o esquema ECDSA continua estritamente superior a qualquer outro esquema de autorização que os contratos associados possam habilitar, o que significa que a perda das chaves privadas resultaria em uma perda total dos ativos da conta.

Programabilidade via EIP-7702

Esta proposta inicialmente se propôs a ser uma variação um tanto minimalista do EIP 3074, e foi mesmo significadoser uma atualização para isso. Foi criado para abordar as supostas ineficiências do EIP 3074, especialmente as preocupações em torno de sua incompatibilidade com o ecossistema já florescente do 4337 e a proposta de abstração de conta nativa - RIP 7560.

Sua abordagem é a adição de um novo tipo de transação compatível com o EIP 2718 - [SET_CODE_TX_TYPE] - que permite que um EOA se comporte como uma conta inteligente para transações especificadas.

Este design permite as mesmas características que EIP 5806 e algumas mais, enquanto permanece compatível com o roadmap de abstração de conta nativa e iniciativas existentes.

Especificações

O EIP-7702 permite que um EOA "importe" o conteúdo do código de um contrato por meio de uma transação compatível com [SET_CODE_TX_TYPE] 2718 do formato:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Esta carga é totalmente semelhante à do EIP 5806, exceto que introduz uma “lista de autorização”. Esta lista é uma sequência ordenada de valores no formato:

[[chain_id, address, nonce, y_parity, r, s], …]

onde cada tupla define o valor do [endereço].

Antes de prosseguir, as partes envolvidas em um SET_CODE_TX_TYPE são:

• [autoridade]: que é a conta de assinatura EOA/primária
• [endereço]: que é o endereço de uma conta contendo código delegável.

Quando [autoridade] assina um SET_CODE_TX_TYPE especificando [endereço], um designador de delegação é criado. Este é um “programa de ponteiro” que faz com que todas as solicitações de recuperação de código devido às ações da [autoridade] em qualquer instante sejam direcionadas para o código observável do [endereço].

Para cada tupla [chain_id, endereço, nonce, y_parity, r, s], o fluxo lógico de uma transação do tipo 7702 é o seguinte:

1. Verificação da assinatura da [autoridade] fornecida a partir do hash fornecido usando: autoridade = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
2. Prevenção de ataques de repetição entre cadeias e Outros vetores de ataquepela verificação do ID da cadeia.
3. Verificando se [autoridade] já possui conteúdo de código.
4. Verificação de nonce para garantir que o nonce da [authority] seja igual ao nonce incluído na tupla.
5. Se a transação for a primeira transação SET_CODE_TX_TYPE de [autoridade], será cobrada uma taxa PER_EMPTY_ACCOUNT_COST. No caso de seu saldo ser menor que o valor dessa taxa, a operação é abandonada.
6. Ocorre a designação de delegação, em que o código de [autoridade] é definido como um ponteiro do [endereço].
7. O nonce do signatário –[autoridade]– é aumentado em um.
8. [authority] é adicionado a uma lista de endereços acessados, que (simplificando) é um conjunto de endereços que são feitos de tal forma que a reversão de um escopo de uma transação a partir deles faz com que eles (o endereço) voltem ao seu estado anterior, antes que o escopo revertido fosse inserido. Isso está definido emEIP-2929para habilitar o cache de valores reutilizáveis e evitar cobranças desnecessárias.

Ufa! Para amarrar tudo isso; esse EIP permite que EOAs enviem transações que definem um ponteiro para o código de um contrato, permitindo que eles implementem essa lógica como se fosse deles em transações subsequentes. Dessa forma, é estritamente mais poderoso que o EIP 5806, porque permite que EOAs tenham realmente conteúdo de código pelo tempo que quiserem (em oposição ao EIP 5806 que simplesmente permite que EOAs enviem chamadas de delegação).

Potencial Aplicabilidade/Casos de Uso

• Abstração de Execução

Embora possa ser argumentado que não é mais uma abstração, uma vez que o EOA ativamente incorpora a lógica que deseja executar, ainda não é o 'proprietário principal' dessa lógica. Além disso, não contém diretamente a lógica, apenas especifica um ponteiro para a lógica (para reduzir a complexidade computacional). Portanto, estamos usando abstração de execução!

• Patrocínio de Gás

Embora a invariante require(msg.sender == tx.origin) seja quebrada para permitir o auto-patrocínio, o EIP ainda permite a integração de retransmissores de transações patrocinadas. No entanto, a ressalva é que tais retransmissores precisam de um sistema baseado em reputação ou participação para evitar ataques de luto.

• Políticas de Acesso Condicional

EOAs podem apontar apenas para uma parte específica do código da conta, de modo que apenas a lógica dessa parte seja executável em seu contexto.

Isso também permite a existência de subchaves que possibilitam a "desescalada de privilégios", para que aplicativos descentralizados específicos tenham acesso ao saldo de uma conta apenas em condições específicas. Por exemplo, você pode imaginar uma permissão para gastar tokens ERC-20, mas não ETH, ou para gastar até 1% do saldo total por dia, ou interagir apenas com aplicativos específicos.

• Implantação de Contrato Inteligente entre Cadeias

Devido à sua natureza não restritiva, uma transação EIP-7702 poderia permitir que um usuário acesse o opcode CREATE2 e o use para implantar bytecode em um endereço sem quaisquer outros parâmetros restritivos, como a lógica do mercado de taxas (por exemplo, EIP-1559 e EIP-4844). Isso permite que o endereço seja recuperado e usado em várias máquinas de estado, com o mesmo bytecode, onde sua conta em cada cadeia é responsável por definir os outros parâmetros de contexto variáveis.

Críticas

• Falta de compatibilidade com versões anteriores

Embora o EIP-7702 ainda seja muito recente, já houve muitos protótipos e testes para suas dependências e desvantagens potenciais, mas seu modelo minimalista garante muita flexibilidade e utilidade em diferentes contextos. No entanto, ele quebra muitas invariâncias e não é imediatamente compatível com versões anteriores.

Alguma da sua lógica inclui:

1. Alteração de nonce EOA durante a transação: EIP-7702 não limita nenhum opcode na tentativa de garantir consistência. Isso significa que um EOA pode implementar opcodes como CREATE, CREATE2 e SSTORE ao executar uma transação EIP-7702, permitindo que seu nonce seja aumentado em um contexto diferente.
2. Permitindo que contas com um valor de codeHash não nulo sejam originadoras de transações: EIP-3607 foi implementado para diminuir as possíveis consequências de uma “colisão de endereço” entre EOAs e CAs. Uma colisão de endereço ocorre quando o valor de 160 bits do endereço de um EOA é totalmente equivalente ao de um endereço de CA.

A maioria dos usuários não está familiarizada com o conteúdo real de uma conta (ou até mesmo a diferença entre uma conta e um endereço!), de modo que permitir colisões de endereço significa que um EOA pode se passar por um CA e atrair fundos do usuário em uma longa sequência de eventos para eventualmente roubá-los. O EIP-3607 abordou isso estipulando que contas que contenham código não devem poder gastar seu saldo usando sua própria lógica de autorização. No entanto, o EIP 7702 quebra essa invariante para permitir que os EOAs permaneçam autônomos mesmo depois de adquirirem alguma programabilidade.

• Semelhança com EIP-3074

Assinar sobre o endereço de uma conta em vez de seu conteúdo de código é basicamente como o esquema 3074 com invocadores. Isso não fornece garantias estritas em relação à consistência do conteúdo do código entre cadeias cruzadas, já que um endereço pode assumir um conteúdo de código diferente em cadeias diferentes. Isso significa que um endereço cujo conteúdo de código contém a mesma lógica em uma cadeia pode ser predatório ou malicioso em outra cadeia, e isso pode levar à perda de fundos do usuário.

Conclusão

As EOAs em sua forma atual hoje são bastante limitadas, pois não permitem que os usuários aproveitem os recursos de programabilidade oferecidos pelo EVM. Embora existam várias formas de atualizar contas, como mencionamos no início deste relatório, a solução escolhida deve manter os princípios de custódia segura e autônoma. Além disso, as atualizações de EOAs podem ter um impacto significativo tanto na experiência do usuário quanto nos desenvolvedores de aplicativos, portanto, todas as vozes interessadas devem ser consideradas.

Permitir que EOAs executem código de qualquer maneira expande imensamente a funcionalidade das contas, mas essa nova expressividade vem com riscos significativos e possíveis surpresas. Resolver esses trade-offs é fundamental para oferecer uma atualização com benefícios de UX incontestáveis para os usuários do Ethereum.

A cultura de discussão aberta do Ethereum o torna um ótimo campo de testes para essas inovações, pois quase todas as implicações de cada design são minuciosamente desconstruídas por especialistas no assunto. Essa consideração abrangente deve ajudar a mitigar os riscos de má conduta por parte de adversários.

EIP-7702 é atualmente o exemplo principal de mecanismos que buscam trazer programabilidade EVM para EOAs, tendo sido marcado como substituto do slot do EIP 3074 na atualização Pectra. Ele herda o design aberto do mecanismo 3074, ao mesmo tempo em que reduz significativamente a superfície de ataque / riscos. Também possibilita muito mais ao evitar as restrições do 3074 a certas classes de códigos de operação.

Embora ainda haja alguns refinamentos sendo feitos no design da proposta, ela já recebeu muita boa vontade e apoio dos desenvolvedores, especialmente porque Vitalik a apoia diretamente.

Dentro da comunidade, há alegações de que essa abordagem de abstração de conta pode ser ainda melhor do que contas inteligentes. Este comentário enfatiza que este caminho requer menos mudanças e não é tão complexo, e que EOAs já estão consagradas. No entanto, devemos lembrar do marco de segurança futuro da resistência quântica em todos os níveis da rede Ethereum. Esta segurança quântica é inviável com o modelo de conta atual devido à utilização de esquemas de assinatura baseados em ECDSA para autorização de EOA.

Assim, a programação EOA deve ser vista como um passo no caminho para contas inteligentes e não o destino. Ele sobrecarrega EOAs e permite uma melhor experiência do usuário e do desenvolvedor, ao mesmo tempo em que permanece compatível com o objetivo final de abstração de contas inteligentes.

No nosso próximo relatório, vamos mergulhar nos esquemas de migração EOA para ver como eles se encaixam bem no roteiro de abstração de conta, fiquem ligados!

Aviso Legal:

1. Este artigo é reproduzido a partir de [2077.xyz], Todos os direitos autorais pertencem ao autor original [Zhev]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe, e eles lidarão com isso prontamente.
2. Aviso de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe de aprendizado da gate. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.