Transações executáveis ​​legíveis por humanos: como resolver hacks do tipo Bybit – Página 3 – Segurança

Boa crítica. Você está apontando para modos de falha reais em descrições geradas pela IU e funções de descrição na cadeia. Deixe-me mostrar como o ERC-8001 evita ambos.

Os problemas que você identificou

1. Descrições geradas pela IU: o usuário confia na UI para descrever com precisão o que está assinando

2. Funções de descrição onchain com chamadas externas: symbol(), decimals() pode ser falsificado; pesquisas entre contratos tornam-se intratáveis ​​para fluxos de múltiplas chamadas

3. Nenhuma fonte semântica unificada: Safe, Aave, USDC e Multisend têm visualizações parciais – eles não conseguem descrever o pacote completo

Estes são válidos. Mas eles têm objeções à obtenção de significado depois a transação é construída. O ERC-8001 adota uma abordagem diferente.

O que ERC-8001 assina em vez disso

{
  "intentType": "supply",
  "asset": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
  "chainId": 1,
  "rawAmount": "1000000",
  "protocol": "0x7d2768dE32b0b80b7a3454c06BdAc94A69DDc7A9",
  "constraints": {
    "noAdditionalApprovals": true,
    "noDownstreamCalls": true,
    "expiry": 1704067200
  }
}

O usuário assina este objeto. Não calldata. Não é uma string gerada pela IU.

Como isso evita os problemas

Nenhuma pesquisa de metadados de tempo de execução: a intenção está vinculada ao valor bruto e ao endereço. A carteira pode renderizar “1 USDC” como um rótulo de conveniência se tiver um mapeamento confiável. Mas o significado aplicável é 0xA0b8...1.000.000 unidades, cadeia 1.

Nenhuma UI como fonte da verdade: a IU propõe o objeto de intenção, mas a carteira verifica a estrutura e exibe os endereços vinculados. O usuário autoriza o objeto, não uma descrição.

Nenhuma função de descrição por contrato: ERC-8001 não pede que Safe, Aave ou USDC descrevam nada. A intenção é declarada na camada de aplicação e verificada em relação à execução. Os contratos são executados; eles não interpretam.

Para fluxos de múltiplas chamadas

{
  "intentType": "sequentialActions",
  "actions": (
    { "type": "approve", "token": "0xA0b8...", "spender": "0x7d27...", "maxAmount": "1000000" },
    { "type": "supply", "protocol": "0x7d27...", "asset": "0xA0b8...", "amount": "1000000" }
  ),
  "constraints": {
    "noOtherApprovals": true,
    "noOtherCalls": true
  }
}

A semântica é declarada antecipadamente. A carteira não infere a partir de calldata. Os contratos não se descrevem. O verificador verifica se a execução permaneceu dentro dos limites declarados da intenção.

Para encerrar

Sua objeção é forte contra:

• Descrições decodificadas pela UI como verdade

• DSLs com pesquisas de metadados não confiáveis

• Funções de descrição por contrato

Resposta do ERC-8001: não obtenha significado da execução. Declare o significado no objeto assinado.

A carteira apresenta a intenção de legibilidade humana. O verificador prova que a execução corresponde à intenção. Nenhuma chamada externa para contratos não confiáveis. Nenhuma coordenação de descrição entre contratos. A semântica está vinculada à própria autorização.