A Ethereum Foundation está explorando asserções de transação que permitiriam aos usuários anexar condições aplicáveis ao resultado final de uma transação, em vez de depender apenas da aprovação da ação solicitada. A pesquisa, parte de sua iniciativa Trillion Dollar Security, visa preencher uma lacuna na segurança das transações: uma assinatura válida não garante que os saldos, as permissões ou os controles da conta resultantes correspondam ao que o signatário pretendia.
Principais conclusões
- As verificações propostas avaliariam os resultados das transações durante a execução e reverteriam ações que violassem uma regra assinada.
- A proteção depende de regras aprovadas independentemente de um possível criador de transações comprometido.
- A pesquisa poderia dar suporte a políticas de segurança de carteiras, agentes delegados e fluxos de trabalho de solvers, mas não se trata de um lançamento anunciado.
Sumário
- Por que aprovar uma transação ainda pode resultar em prejuízo
- Como as asserções de transação verificariam o resultado
- Quais informações a implementação proposta disponibilizaria
- Onde carteiras e protocolos precisariam mudar
- O que agentes e fluxos de trabalho de solvers poderiam ganhar
- Conclusão
Por que aprovar uma transação ainda pode resultar em prejuízo
O Ethereum executa a solicitação autorizada por um usuário com base no código e no estado disponíveis no momento da execução. Essas condições podem diferir daquilo que o usuário examinou. Por exemplo, a implementação de um proxy pode mudar antes da execução, enquanto a ordenação das transações pode alterar o preço encontrado por uma operação de swap.
A fundação distingue solicitações enganosas de resultados indesejados. Nos ataques à Bybit e à BadgerDAO, frontends comprometidos apresentaram solicitações de assinatura diferentes daquilo que os usuários acreditavam estar aprovando. Em contrapartida, mesmo uma solicitação exibida com precisão pode permitir um resultado economicamente prejudicial.
O exemplo apresentado é um swap de garantia na Aave e na CoW envolvendo cerca de US$ 50,4 milhões em aEthUSDT. A baixa liquidez de AAVE e o limite de gas da CoW deixaram uma cotação verificada de aproximadamente 329 aEthAAVE. Apesar de um aviso exibido de impacto sobre o preço de 99,9% e da confirmação de que todo o valor poderia ser perdido, o usuário assinou e recebeu tokens no valor de cerca de US$ 36.000.
Essa distinção explica por que descrições melhores das transações não são a solução completa. O Clear Signing ajuda os usuários a entender a ação solicitada. A simulação estima os efeitos com base em um estado selecionado da rede. Nenhum dos dois, por si só, impõe uma condição independente ao resultado que efetivamente ocorre.
| Item | Detalhes |
|---|---|
| TXTRACE | Enumera as alterações líquidas de estado da transação e os eventos emitidos. |
| TXDIFF | Recupera os valores iniciais e finais de endereços e posições de armazenamento especificados. |
| EVENTDATACOPY | Copia os dados de um evento para a memória para inspeção. |
| Informações de implantação | Os dados propostos sobre alterações de estado incluem contratos recém-implantados e seus hashes de código. |
Como as asserções de transação verificariam o resultado
Uma asserção compararia o estado inicial e final de uma transação usando lógica somente de leitura após a execução de suas ações. A condição seria incluída na transação e assinada junto com as ações. Se não fosse satisfeita, essas ações seriam revertidas.
Entre as regras possíveis estão um valor mínimo recebido, um limite máximo de gastos, restrições a novas aprovações de tokens ou a preservação da lógica de controle de uma conta. A capacidade de inspeção proposta vai além dos saldos e abrange armazenamento, código, contratos recém-implantados e eventos emitidos.
Verificações existentes em contratos já protegem resultados específicos. A Uniswap pode rejeitar swaps abaixo de um valor mínimo de saída especificado, e um guard do Safe pode inspecionar o estado da conta após a execução. A limitação está na visibilidade: essas verificações precisam antecipar o que examinar e, em geral, dependem das interfaces expostas por outros contratos. Um proxy, por exemplo, não precisa fornecer uma função que revele o endereço de sua implementação.
As asserções nativas disponibilizariam para verificação todos os efeitos líquidos da transação, inclusive alterações que um guard comum talvez não soubesse procurar. Mas uma visibilidade mais ampla só é útil se a regra for confiável. Um frontend malicioso poderia fornecer uma condição que permitisse seu próprio ataque; por isso, a política precisa se basear em uma intenção aprovada independentemente, em uma política da conta ou em lógica de protocolo protegida.
Quais informações a implementação proposta disponibilizaria
O anúncio da fundação sobre asserções nativas de transação descreve a EIP-7906 como uma possível implementação, não como um projeto definitivo. Ela se baseia nas transações de quadro da EIP-8141, que organizam etapas de validação e ação em uma sequência ordenada. A EIP-8141 está prevista para a Hegotá; a EIP-7906 alcançou o status de “Considered for Inclusion”, mas não foi confirmada para essa atualização.
Nessa abordagem, um quadro POST_TX somente de leitura inspecionaria os resultados ao fim da execução. As instruções propostas para acesso a dados funcionariam apenas dentro desse quadro, e não por toda a EVM.
As informações descreveriam os efeitos líquidos, não um histórico de cada gravação intermediária. Uma posição de armazenamento alterada repetidamente apareceria com seus valores inicial e final; uma posição restaurada ao valor original não apareceria. Por isso, é importante distinguir a imposição de condições sobre o estado final do monitoramento de cada etapa da execução.
Se uma verificação falhasse, o corpo da execução seria revertido, mas a transação permaneceria no bloco como falha. O pagador do gas ainda pagaria pelo gas consumido, impedindo que transações deliberadamente malsucedidas impusessem trabalho de execução gratuito aos construtores de blocos.
Onde carteiras e protocolos precisariam mudar
A proposta oferece um mecanismo de verificação, não uma exigência automática de uso. Para as transações de um usuário, a carteira teria de incluir sua política de segurança na construção da transação, em vez de deixar o criador livre para omiti-la. Essa política poderia derivar da própria simulação da carteira ou se aplicar como regra permanente da conta.
Nos protocolos, a proteção teria de ser incorporada às condições de acesso a uma função protegida. Não bastaria fornecer uma transação compatível com asserções: a chamada precisaria incluir a verificação específica exigida pelo protocolo. Isso alteraria os requisitos de integração para os chamadores, enquanto contratos imutáveis já implantados não poderiam incorporar retroativamente essa verificação de admissão.
Essas dependências separam uma capacidade potencialmente poderosa da EVM de uma garantia voltada ao usuário. Uma proteção eficaz exigiria tanto uma condição sólida quanto software que a tornasse sistematicamente incontornável.
O que agentes e fluxos de trabalho de solvers poderiam ganhar
Agentes delegados poderiam ser limitados pelos resultados, além das permissões. Restrições sobre quais contratos um agente pode usar ou quanto pode gastar poderiam ser complementadas por requisitos que determinem o que cada transação deixa ao final.
Na execução baseada em solvers, um protocolo poderia especificar um resultado aceitável, permitindo que o solver escolhesse o caminho. A garantia se restringiria a uma transação em uma única rede, e não a uma rota que abrangesse várias redes.
As asserções também poderiam verificar a limpeza de um fluxo de trabalho, como a devolução de tokens não utilizados e a revogação de aprovações restantes. A fundação está buscando contribuições de equipes de carteiras e protocolos enquanto o projeto continua, o que torna essas aplicações potenciais direções de pesquisa, e não funcionalidades de produto anunciadas.
Conclusão
As asserções nativas de transação deslocariam parte da segurança das transações no Ethereum da interpretação de uma solicitação para a imposição de seu resultado. Seu valor prático dependeria de políticas confiáveis e da adoção pelas carteiras e pelos protocolos responsáveis por aplicá-las.
Leia mais notícias
Isenção de responsabilidade
Este artigo da FinanceVelix fornece informações gerais, não aconselhamento financeiro, de investimento, jurídico ou tributário personalizado. Os preços das criptomoedas podem mudar rapidamente, e você pode perder todos os fundos investidos. Os fatos refletem o material disponível no momento da publicação e podem mudar. Verifique informações importantes de forma independente e consulte um profissional qualificado quando necessário. A menção a um ativo, empresa ou serviço não constitui endosso.
