A abstração de contas busca melhorar as experiências do usuário e do desenvolvedor em todo o ecossistema Ethereum. Além de tornar as experiências na cadeia mais acessíveis e agradáveis aos usuários, também capacita os desenvolvedores a realizar coisas mais poderosas no Ethereum e atender aos usuários de maneiras ainda mais significativas.

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

1. Aprimoramento/programabilidade do EOA: Isso inclui mudanças no nível do protocolo que permitem que os EOAs (Contas de Propriedade Externa) redefinam a parte lógica de execução de suas regras de validade. Como é bem conhecido na comunidade de desenvolvimento, os 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 quais tipos de ações eles podem autorizar, em comparação com a forma como isso pode ser gerenciado atualmente.
2. Conversão/migração de EOA: Esta abordagem inclui propostas que buscam a conversão completa de EOA para CA (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 deve haver necessidade de complicar as coisas; todos devem simplesmente usar uma conta de contrato como sua conta principal (através de carteiras de contratos inteligentes).

Esta abordagem apresenta mecanismos que permitem que um EOA faça a transição para uma CA, sem precisar mover seus ativos, como EIP 7377 e EIP 5003 (quando considerado juntamente com EIP 3074).

1. Contas Inteligentes: Este grupo de propostas inclui designs que permitem tanto EOAs como CAs comportarem-se como “contas inteligentes” ao permitir-lhes redefinir totalmente as suas regras de validade.

Várias propostas foram anteriormente feitas para a criação de contas inteligentes e a consolidação da abstração de contas ao 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 um tanto maioritária de que o Ethereum não está pronto para tal complexidade.

Seguindo a ressurreição do tópico por Vitalik após The Merge,ERC-4337foi proposto 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).

ERC 4337 traz os benefícios das contas inteligentes para o Ethereum atual sem consagrar nenhuma complexidade, 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, pois 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 todo o Ethereum e suas L2s, para que herde os esquemas de resistência síbil da rede em vez de ter que definir uma nova série de regras (como o ERC 4337 faz comERC 7562.)

Neste relatório, estaremos focados em explorar a programabilidade da EOA, avaliando os vários EIPs que descrevem soluções ao longo desta linha e discutindo seus méritos e desvantagens. Na Parte 2 e 3 desta série, abordaremos as duas classes restantes de abordagem para a abstração de contas que estão 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 de conta atual. 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. Elas são representadas como um “endereço” hexadecimal de 42 caracteres, que serve como um ponteiro único para as holdings e transações da conta.

Um endereço atua como uma chave no trie de estado da blockchain. Os nós folha deste 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 prevenir ataques de repetição.
2. saldo: A quantia denominada em wei de ether (ETH) possuída por uma conta.
3. codeHash: Um hash do código EVM-executável contido numa conta. O EVM (Ethereum Virtual Machine) é o ambiente de execução específico do Ethereum responsável por lidar com transições de estado complexas para além de transações simples de “envio”. O conteúdo do código de uma conta é programado de forma imutável 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 trie patricia merkle. Simplesmente, é um hash dos dados de variáveis de estado relacionados ao conteúdo do código de uma conta.

O conteúdo destes quatro campos é utilizado para definir o tipo de conta e, por fim, para definir a extensão das 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 hexadecimal de 64 caracteres, criptografável e comprovadamente aleatório, e seu complemento correspondente;
• Uma chave pública que é derivada da chave privada usando o ECDSA (Elliptic Curve Digital Signature Algorithm).

As EOAs têm campos codeHash e storageHash vazios e só podem ser controladas por qualquer pessoa que possua 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 uma EOEA preexistente. Elas são inicializadas devido a uma EOEA implantando conteúdo de código executável no EVM. Esse conteúdo de código (armazenado como o codeHash) é consagrado no EVM e é responsável por controlar a conta definindo sua lógica e interações.

As suas transações são totalmente baseadas em pull e baseadas na lógica do código implementado.

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 só possuem 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 de seu criador e de 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, compreender que um propósito primário de uma conta é enviar e receber transações, enquanto a 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 da blockchain.

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

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

A ausência de permissão acarreta custos de incentivos perversos, para lidar com estes, é necessário definir diretrizes rigorosas (ou regras de validade) para interações em tais ambientes.

Neste contexto, as transações devem seguir certas 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

Na Ethereum, as EOAs são otimizadas para facilidade de uso, uma vez que são direcionadas para o utilizador final. Têm a capacidade de enviar transações de uma forma específica e funcionar perfeitamente de forma autónoma. Também podem ser criadas localmente, sendo o método mais comum o uso de fornecedores de carteiras como MetaMask, Rainbow, Rabby etc.

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

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

Estas propriedades devem-se aos seguintes parâmetros lógicos que definem as regras às quais as transações de uma conta devem obedecer:

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 provar que tem o direito de efetuar quaisquer alterações em seu saldo.
• A lógica do nonce implementa um esquema de contagem 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/origem.
• A lógica de execução especifica que as EOAs só podem enviar as seguintes formas de transação:

1. Transferências regulares entre duas contas EOA.
2. Implementação do contrato.
3. chamadas de contrato que têm como alvo a lógica de uma conta de contrato implantada.

Mais genericamente, a lógica de execução das EOAs as restringe a uma transação por assinatura válida.

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

• A autenticação não é necessária, pois as suas transações são de natureza consequente/pull-based.
• A autorização para as CA 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âncias.
2. Capacidade de fazer alterações no código de conteúdo da CA, que depende principalmente de 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 são necessárias M das N assinaturas válidas (onde M < N) de contas específicas (comumente EOAs) para que uma mudança na lógica do CA seja válida.

• A ordenação das transações deles é baseada em nonce. O próprio CA pode enviar o máximo de transações possível para o máximo de chamadores diversos, mas cada chamador é limitado com base em suas próprias capacidades.
• O pagamento do gás é comumente tratado pelo chamador da lógica do CA.
• A lógica de execução dos ACs é mais diversa para permitir melhorias de UX, como transações multicall e transações atômicas.

Ao avaliar essas características, observamos que cada tipo de conta é projetado para ter um equilíbrio entre autonomia e programabilidade.

EOAs têm plena autonomia, 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 plena programabilidade (limitada apenas pelo design da 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 seguinte, estudaremos agora as implicações dessas escolhas de design, a fim de compreender completamente a proposição de cada EIP discutida ao longo desta série.

O 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 os problemas que eles apresentam tanto para a experiência do usuário quanto para o desenvolvedor no Ethereum.

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

Algumas das preocupações em relação a eles são:

1. Susceptibilidade a ataques quânticos - O esquema de assinatura ECDSA usado pelo par de chaves não é resistente a quântica, e com um cronograma otimista de 5 a 10 anos para que os sistemas quânticos industriais sejam alcançados, isso representa uma ameaça significativa para o Ethereum e suas aplicações que dependem muito 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 utilizadores de expressarem as suas transações de forma mais sucinta, através de funcionalidades como a atomicidade e agrupamento de transações, e a delegação de transações.
3. Auto-sustentabilidade – Todos já tiveram a sua justa quota de momentos de "fiquei sem gás" no meio de uma transação. Isto deve-se ao requisito de que as EOAs liquidem o gás das suas transações por si mesmos, o que não seria muito difícil se o ether (ETH) não fosse a única moeda de gás aceitável. Embora este seja um problema comum em máquinas de estado baseadas em contas (e até mesmo nas baseadas em UTXO), o Ethereum sempre pretendeu 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, as CAs visam os programadores e uma base de utilizadores mais técnica. Servem como veículos para contratos inteligentes (ou seja, consideramos os contratos inteligentes como a sua lógica contida ou conteúdo de código) e podem implementar formatos de transação inovadores, assim como é permitido pelo EVM.

No entanto, todas essas características são contas de segunda classe glorificadas, pois não têm autonomia. Alguns dos 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 particular.
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 resultou em bilhões de dólares em perdas devido a exploits e hacks de contratos inteligentes. No entanto, isso é quase um tópico completamente diferente que está além do nosso escopo aqui.

Após analisarmos as escolhas de design que levaram aos problemas definidos nesta subseção, agora podemos proceder à avaliação das soluções propostas.

Uma linha do tempo da abstração de contas

O conceito de abstração de contas (pelo menos via contas inteligentes) sempre fez parte integrante da roadmap do Ethereum. A lenda é que a complexidade em torno da sua implementação ameaçou atrasar ainda mais o lançamento do Ethereum, então foi descartada para o design atual com contas diferentes oferecendo funcionalidades diferentes. Foi adiada novamente pelo foco do Ethereum em The Merge, e agora está ressurgindo como parte principal da próxima grande atualização da rede - Pectra. No entanto, a sua complexidade ainda é considerada uma desvantagem significativa que impede a sua consagração, especialmente porque o Ethereum tem pivotado para uma roadmap centrada em rollup.

Os requisitos são agora duplos:

1. Os padrões de conta têm que 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 deve preencher a lacuna entre EOAs e CAs, mantendo-se totalmente compatível em Ethereum e seus ecossistemas L2.

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

A abstração de contas tem como objetivo combinar as melhores características das EOAs e CAs num novo padrão de conta - contas inteligentes, que permitem a separação completa ou parcial das regras de validade de qualquer conta numa lógica de validação e uma de execução; para que as contas possam definir as suas próprias regras de validade - conforme permitido pelo EVM - tal como as contas de contrato, mantendo-se totalmente autónomas tal 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:

• As contas inteligentes são contas Ethereum que são conceptualizadas para fornecer partes iguais de programabilidade e autonomia. A ideia é que tanto as EOAs como as CAs possam tornar-se contas inteligentes simplesmente utilizando algum mecanismo (por exemplo, ERC 4337) que lhes permita substituir as regras de validade impostas pela rede por regras de validade personalizadas, conforme considerem adequado.
• Por outro lado, as carteiras de contratos inteligentes são simplesmente fornecedores de carteiras que servem como interfaces para contas de contrato (sim, uma carteira não é uma conta).

A comercialização de carteiras de contratos inteligentes facilitou a adoção de CAs 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 às CAs.

De volta à 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 primeiros quatro 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 prosseguir.

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

EOAs programáveis

O maior atrativo da Ethereum é o seu ecossistema DeFi jovem, mas vibrante, que apresenta uma variedade de aplicações descentralizadas que são os seus principais sumidouros de liquidez. A maioria destas DApps estão otimizadas para servir EOAs, sendo assim, é difícil interagir com CAs e, eventualmente, contas inteligentes. Embora as carteiras de contratos inteligentes ajudem as CAs neste caso, elas têm as suas próprias limitações e uma UX totalmente diferente.

Uma solução provisória que está sendo explorada enquanto tanto DApps quanto provedores de carteiras se acostumam com o padrão de conta inteligente, é fornecer aprimoramentos temporários para EOAs que os permitem superar a maioria de suas restrições impostas, seja sua validação ou lógica de execução.

Abaixo, analisamos as especificações de três principais EIPs que fornecem rotas acionáveis para a programabilidade EOA; do menos conhecidoEIP 5806, para o ambicioso EIP 3074e finalmente para o vitoriosoEIP 7702.

Programabilidade via EIP-5806

Esta proposta procura trazer mais funcionalidade ao padrão EOA ao permitir que ele faça chamadas delegadas para a lógica da conta de contrato (seu contrato inteligente). Isso faz com que o contrato inteligente seja executado no contexto do EOA chamador, ou seja, o EOA permanece 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é EIP-7.

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

Em outras palavras, a conta primária 'herda' (ou empresta, se preferir) a lógica da conta secundária por algum tempo, conforme 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 barreiras de gás.

EIP-5806 resumido

Ok, então quais chamadas de delegado permitem que 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 EOAs também sejam interdependentes com CAs, porque não.

Especificações

A 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]).

Estas transações são projetadas de forma que o campo [para] – que representa o endereço do destinatário – só pode aceitar endereços como entradas de 20 bytes, desativando o remetente de usar o opcode CREATE.

A motivação por trás de cada componente do esquema RLP é a seguinte:

• chainID: O identificador EIP-115 compatível com a corrente atual, preenchido para 32 bytes. Este valor fornece proteção contra ataques de repetição, para que as transações na corrente original não sejam facilmente replicadas em correntes EVM alternativas com uma história 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, respetivamente.
• gas_limit: O valor máximo 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 que estão 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 a embalagem de transações EIP-5806 em envelopes EIP-2718 permita uma grande compatibilidade retroativa, EOAs não são equivalentes a CAs. Portanto, certas restrições devem ser definidas na forma como um EOA utiliza chamadas de delegação para evitar quebras de invariantes.

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

• SSTORE/0x55: Este opcode permite que uma conta guarde um valor na memória de armazenamento. Nas transações EIP-5806, ele é restrito para evitar que EOAs definam/acessam a memória de armazenamento usando chamadas de delegate, prevenindo assim possíveis problemas que possam surgir no futuro devido à migração de contas.
• CREATE/0xF0, CREATE2/0xF5 e SELFDESTRUCT/0xFF: Estes códigos de operação permitem extensivamente ao chamador criar uma nova conta. O acesso a estes é restrito para evitar a alteração do nonce de um EOA num quadro de execução diferente (criação/destruição de contrato neste caso) enquanto está a realizar uma transação EIP-5806, de modo a evitar a invalidação da expectativa de que as transações tenham nonces consecutivos.

Potenciais Casos de Aplicação/Utilização

A aplicabilidade primária do EIP 5806 é a abstração de execução para EOAs. Permitir que 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
• Agregação de transações
• Transações Multicall (por exemplo, aprovar e chamar)

Críticas

As alterações propostas pelo EIP-5806, embora habilitem funcionalidades necessárias, não são particularmente inovadoras; a sua existência é principalmente baseada num EIP-7 já funcional. Isso permite contornar muitos obstáculos potenciais para aceitação.

Uma das principais preocupações manifestadas nos primeiros dias foi o potencial risco de permitir que EOAs acedam ao armazenamento e o alterem, tal como os CAs fazem atualmente. Isto quebra muitos invariantes enraizados na rede relativos à forma como os EOAs devem transacionar, e por isso foi tratado introduzindo as restrições mencionadas na subseção anterior.

Uma segunda crítica (que é um pouco de uma espada 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 a pena, uma vez que apenas permite a abstração de execução e pouco mais. Todas as outras restrições de validade permanecem definidas pela rede para EOAs que aderem ao EIP-5806, ao contrário de outros EIPs um tanto semelhantes que discutimos nas subseções seguintes.

Programação via EIP-3074

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

Isso é alcançado ao assinar sua política de acesso para um contrato invoker, que então se torna responsável por definir a política de acesso do EOA.

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

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

Estes dois opcodes permitem que um EOA delegue o controlo a uma AC pré-estabelecida e, assim, aja como um só através dela, sem ter de implementar um contrato e incorrer nos custos e externalidades associados a isso.

Especificações

EIP-3074 permite que as transações usem um formato de assinatura [MAGIC] para evitar colisões com outros formatos de assinatura de transação. 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 através de uma única transação e deve ser redefinido para cada novo [AUTHCALL].

Antes de abordar as complexidades de cada operação, estas são as entidades envolvidas numa transação EIP-3074:

• [autoridade]: A conta de assinatura principal (uma EOA) que delega acesso/controle a 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 gerir 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 de contrato deste último é patrocinada pelo gás.

Contratos Invoker recebem mensagens [AUTH] com um valor [COMMIT] da [autoridade]; esse valor define as restrições que a conta deseja colocar na execução de instruções [AUTHCALL] do [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 invariáveis estabelecidas pela conta de assinatura primária em um valor [COMMIT].

O opcode [AUTH] tem três entradas de elementos de pilha; ou de forma mais simples — é definido por três entradas que calculam uma saída única. Estas entradas são:

1. autoridade: que é 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 (offset : offset+1)] - [yParity]
2. [memória(offset+1 : offset+33] – [r]
3. [memory(offset+33 : offset+65)] - [s]
4. [memória(offset+65 : offset+97)] - [COMMIT]

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

[keccak256 (MAGIC || chainID || nonce || endereço do invocador || COMMIT)]

onde:

• [MAGIC] é uma assinatura ECDSA resultante da combinação das variáveis:
  • [chainID], que é o identificador compatível com o EIP 115 da cadeia atual, usado para fornecer proteção contra ataques de replay em cadeias EVM alternativas com uma história semelhante e menor segurança econômica.
  • [nonce] que é o nonce atual do endereço do signatário da transação, preenchido à esquerda com 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 signatário for igual a [authority], o campo [authorized] é atualizado para o valor fornecido por [authority]. Se algum destes requisitos não for satisfeito, 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 a pré-compilação [ecrecover] e extra para um hash keccak256 e alguma lógica adicional, avaliada em 3100 unidades
2. Uma taxa de expansão de memória que é calculada de forma semelhante à instrução [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 um [authority] quente e 2600 unidades para um frio para evitar ataques devido a erros de preço de opcodes de acesso ao estado.

[AUTH] é implementado para não modificar a memória e recebe o valor da [authority] como argumento, de forma que seja trivial verificar o 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; Ele é usado para enviar chamadas de mensagem para uma conta e acionar uma lógica específica em seus contratos. O único desvio em sua lógica é que [AUTHCALL] é projetado para definir o valor de [CALLER] antes de prosseguir com a execução.

Assim, [AUTHCALL] é usado pela [autoridade] para desencadear comportamento específico do contexto em [autorizado] com verificações lógicas a seguir:

1. Verifique o valor de [autorizado]. Se não estiver definido, a execução é considerada inválida e o quadro é saído imediatamente. Isso ajuda a prevenir cobranças injustas devido a falhas imprevistas.
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 de gás –[valor]– no saldo da [autoridade].
5. A execução ocorre após a dedução de [value] do saldo da conta de [authority]. Se [value] for maior do 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]
• Um custo de expansão de memória de [memory_expansion_fee]; que é calculado de forma semelhante ao custo de gás para o código [CALL]
• Um custo dinâmico [dynamic_gas]
• O custo de execução da subchamada [subcall_gas]

Os dados devolvidos de uma [AUTHCALL] são acedidos através de:

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

Para simplificar sem tanto 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 - onde 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 invariante simples dá origem à maioria dos problemas que explicamos na subseção "Contas e Validade da Transação" deste relatório.

As mensagens [AUTH] da [authority] permitem que ela compense a função tx.origin para [authorized], mantendo o msg.sender. Também permite que ela defina restrições a esse privilégio usando um valor [COMMIT].

[AUTHCALL] em seguida, permite que [autorizado] 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], [autorizado] deve especificar um [invoker] específico para o seu [COMMIT].

Aplicabilidade potencial/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.

A lógica de validação completa de um EOA pode ser abstraída aplicando várias restrições/inovações ao invocador, conforme necessário, alguns dos possíveis designs baseados em sua lógica-alvo incluem:

• Lógica de Nonce: EIP-3074 permite que o nonce das EOAs permaneça inalterado após o envio de uma mensagem [AUTH], enquanto o seu nonce para cada [AUTHCALL] depende do invocador com o qual está interagindo. Desta forma, permite a paralelização do nonce para as EOAs, para que possam enviar múltiplos [AUTHCALL] não sobrepostos como desejarem.
• Lógica de pagamento de gás:Conforme especificadoNo EIP, os invocadores podem ser projetados para permitir o 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 pedidos de transação em nome do EOA.

Críticas

• Centralização do Invoker

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

Por padrão, os contratos de invocador precisam ser muito auditados para evitar ataques ainda piores do que os atualmente possíveis. Isso inevitavelmente tenderá a um ecossistema onde apenas um punhado de contratos de invocadores desenvolvidos por figuras influentes serão adotados como padrão para desenvolvedores de carteiras. Assim, resume-se a um compromisso entre tomar o caminho descentralizado de auditar constantemente e apoiar contratos de invocadores com o risco da segurança dos usuários; ou simplesmente adotar contratos invocadores de fontes estabelecidas e respeitáveis, com melhores garantias de segurança do usuário e menos supervisão sobre a segurança do contrato.

Outro aspecto deste ponto é a função de custo associada ao projeto, auditoria e marketing de um invocador funcional e seguro. Equipes menores quase sempre serão superadas por organizações maiores - especialmente no campo do marketing - que já possuem alguma reputação estabelecida, mesmo que seu produto seja melhor.

• Problemas de compatibilidade com versões futuras

O 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 invocador. Embora haja argumentos de que a resistência quântica não é atualmente um problema definitivo, e que há muito pior em jogo em um futuro onde a ECDSA é corruptível; O objetivo um tanto não declarado do Ethereum é estar sempre à frente de tais problemas. Potencialmente sacrificar a resistência quântica e à censura por melhorias marginais na UX pode não ser a melhor das escolhas no futuro próximo.

Outro ponto sobre o argumento da compatibilidade futura é que, enquanto os benefícios do 3074 estavam sendo avaliados, o ERC-4337 (que não requer quaisquer alterações de protocolo) agora tem um grande mercado, por isso também é necessário ser compatível com ele para evitar a compartimentalização dos ecossistemas.

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

• Irrevocabilidade do Esquema ECDSA

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

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

Programabilidade através do EIP-7702

Esta proposta tinha sido inicialmente concebida como uma variação um tanto minimalista do EIP 3074 e era até significouser uma atualização para ele. Foi criado para abordar as supostas ineficiências do EIP 3074, especialmente as preocupações em relação à sua incompatibilidade com o ecossistema 4337 já florescente e a proposta de abstração de contas nativas - RIP 7560.

Sua abordagem é a adição de um novo tipo de transação compatível com 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 funcionalidades que EIP 5806 e algumas mais, mantendo-se compatível com o roadmap de abstração de contas nativas e iniciativas existentes.

Especificações

O EIP-7702 permite que um EOA "importe" o conteúdo do código de um contrato através 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 útil é completamente semelhante à da 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 continuar, as partes envolvidas em um SET_CODE_TX_TYPE são:

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

Quando [authority] assina um SET_CODE_TX_TYPE especificando [address], um designador de delegação é criado. Este é um “programa de ponteiro” que faz com que todos os pedidos de recuperação de código devido às ações do [authority] em qualquer instante sejam canalizados para o código observável de [address].

Para cada tuplo [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] a partir do hash fornecido usando: autoridade = ecrecover(keccak(MAGIC || rlp([chain_id, endereço, nonce])), y_parity, r, s]
2. Prevenção de ataques de reprodução entre cadeias eoutros vetores de ataquepela verificação do ID da cadeia.
3. Verificar se [autoridade] já tem conteúdo de código.
4. Verificação do nonce para garantir que o nonce da [autoridade] é igual ao nonce incluído na tupla.
5. Se a transação é a primeira transação SET_CODE_TX_TYPE da [autoridade], é cobrada uma taxa PER_EMPTY_ACCOUNT_COST. No caso de o seu saldo ser inferior ao valor desta taxa, a operação é abandonada.
6. Ocorre a designação de delegação, na qual o código de [authority] é definido como um ponteiro do [address].
7. O nonce do signatário - [authority] - é aumentado em um.
8. [autoridade] é adicionada a uma lista de endereços acessados, que (simplificando) é um conjunto de endereços que são feitos de 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 seja inserido. Isso é definido emEIP-2929 para habilitar o cache de valores reutilizáveis e evitar cobranças desnecessárias.

Ufa! Para amarrar tudo isso; este EIP permite que EOAs enviem transações que definem um ponteiro para o código de um contrato, permitindo-lhes implementar esta lógica como a sua própria em transações subsequentes. Desta forma, é estritamente mais forte do que o EIP 5806, porque permite que EOAs tenham conteúdo de código pelo tempo que desejarem (ao contrário do EIP 5806, que simplesmente permite que EOAs enviem chamadas de delegação).

Potenciais aplicabilidades/casos de uso

• Abstração de Execução

Embora se possa argumentar 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 violada para permitir o auto-patrocínio, o EIP ainda permite a integração de intermediários de transações patrocinadas. No entanto, a ressalva é que tais intermediários precisam de um sistema baseado em reputação ou participação para evitar ataques de sabotagem.

• Políticas de Acesso Condicional

Os 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 permitem a "desescalada de privilégios", de modo que dAPPs específicos só tenham acesso ao saldo de uma conta sob 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 para interagir apenas com um aplicativo específico.

• Implementação de Contrato Inteligente Cross-chain

Devido à sua natureza não restritiva, uma transação EIP-7702 poderia permitir que um usuário acesse o opcode CREATE2 e o utilize para implantar bytecode em um endereço sem quaisquer outros parâmetros restritivos, como lógica de 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 é então responsável por definir os outros parâmetros de contexto variável.

Críticas

• Falta de compatibilidade retroativa

Embora o EIP-7702 ainda seja muito recente, já houve muitos protótipos e testes para suas dependências e potenciais desvantagens, mas seu modelo minimalista garante muita flexibilidade e, portanto, utilidade, em diferentes contextos. No entanto, ele quebra muitos invariantes 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 para garantir consistência. Isso significa que um EOA pode implementar opcodes como CREATE, CREATE2 e SSTORE enquanto executa 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 zero sejam originadoras de transações: O EIP-3607 foi implementado para diminuir as possíveis consequências de uma “colisão de endereços” entre EOAs e CAs. Uma colisão de endereço ocorre quando o valor de 160 bits do endereço de um EOA é completamente equivalente ao de um endereço de CA.

A maioria dos utilizadores não tem conhecimento do conteúdo real de uma conta (ou mesmo da diferença entre uma conta e um endereço!), portanto, permitir colisões de endereços significa que um EOA poderia mascarar-se como um CA e atrair fundos de utilizadores de forma elaborada para eventualmente roubar tudo. A EIP-3607 abordou isso estipulando que contas que contenham código não devem poder gastar o seu saldo utilizando a sua própria lógica de autorização. No entanto, a EIP 7702 quebra essa invariância para permitir que os EOAs permaneçam autónomos mesmo depois de ganhar alguma programabilidade.

• Semelhança com EIP-3074

Assinar o endereço de uma conta em vez do seu conteúdo de código é basicamente igual ao esquema 3074 com invocadores. Não fornece garantias estritas em torno da consistência do conteúdo de código entre as cadeias, 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 totalmente malicioso em outra cadeia, o que pode levar à perda de fundos do usuário.

Conclusão

As EOAs na sua forma atual hoje são grandemente limitadas, uma vez que não permitem aos utilizadores aproveitar as funcionalidades de programação oferecidas pelo EVM. Embora existam vários caminhos para atualizar contas, como destacámos no início deste relatório, a solução escolhida tem de manter os princípios da custódia própria segura e segura. Além disso, as atualizações do EOA podem impactar significativamente tanto a experiência do utilizador como os desenvolvedores de aplicações, pelo que 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 expressibilidade vem com riscos significativos e possíveis blindsides. Resolver essas compensações é fundamental para fornecer uma atualização com benefícios de UX incontestáveis para os usuários do Ethereum.

A cultura de discussão aberta do Ethereum torna-o um ótimo campo de testes para essas inovações, uma vez que 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 dos adversários.

EIP-7702 é atualmente o exemplo máximo de mecanismos que buscam trazer programabilidade de EVM para EOAs, tendo sido marcado como substituto para a posição do EIP 3074 na atualização Pectra. Ele herda o design aberto do mecanismo do 3074, ao mesmo tempo em que reduz consideravelmente a superfície de ataque/risco. Ele também possibilita muito mais ao evitar as restrições do 3074 a certas classes de opcodes.

Embora ainda haja alguns refinamentos sendo feitos no design da proposta, ela já recebeu muita boa vontade e apoio dos desenvolvedores, especialmente porque tem o apoio direto de Vitalik.

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

Assim, a programabilidade da EOA deve ser vista como um passo ao longo do caminho para contas inteligentes e não como o destino. Isso potencializa as EOAs e permite uma melhor experiência do usuário e do desenvolvedor, ao mesmo tempo 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 contas, fiquem atentos!

Isenção de Responsabilidade:

1. Este artigo é reproduzido a partir de [2077.xyz], Todos os direitos de autor pertencem ao autor original [zhev]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa, e eles vão tratar disso prontamente.
2. Isenção de Responsabilidade: As opiniões expressas 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 equipa Learn da gate. Salvo indicação em contrário, é proibida a cópia, distribuição ou plágio dos artigos traduzidos.