Saltar al contenido
Financial Context Wiki

Firmas tipadas EIP-712: dominios, resúmenes y verificación segura

EIP-712 hace que los mensajes estructurados de Ethereum sean deterministas y legibles, pero firmar con seguridad exige verificar dominio, tipo, valor, nonce, plazo, ejecución y política del firmante.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

EIP-712 estandariza cómo las aplicaciones de Ethereum describen, resumen y solicitan firmas sobre datos estructurados tipados. Una solicitud contiene types, primaryType, domain y message; su resumen es keccak256("\x19\x01" || domainSeparator || hashStruct(message)). Así, la codificación es determinista y una cartera compatible puede mostrar los campos con más claridad que un hash opaco.

Pero no convierte el mensaje en verdadero, inocuo, revocable ni resistente a repeticiones. La aplicación debe vincular la autoridad con la cadena y el verificador correctos, definir cada campo sin ambigüedad, aplicar nonces y límites temporales, validar al firmante adecuado y restringir la ejecución. Una firma válida acredita la aprobación de un resumen exacto conforme a una regla de verificación; no acredita la identidad, el consentimiento informado ni la seguridad del sitio o del contrato.

Firmas tipadas EIP-712
0 / 5
0 elementos revisados; 5 elementos pendientes

Completar esta revisión no demuestra que un activo, una transacción o un sistema sean seguros.

Cómo funciona

1. Identificar la acción y la ruta de verificación

Determine si la solicitud autoriza un inicio de sesión, una orden, un voto, una allowance de tokens, una transferencia, una llamada retransmitida u otra acción. Localice el código que reconstruye el resumen y consume la firma. Para una cuenta de propiedad externa suele recuperarse una dirección desde una firma ECDSA; para una cuenta de contrato puede ser necesario llamar a ERC-1271 isValidSignature(hash, signature) y comprobar su valor de éxito 0x1626ba7e.

2. Fijar el dominio

Examine el tipo EIP712Domain exacto y sus valores. Los campos estándar son name, version, chainId, verifyingContract y salt, pero solo se resumen los incluidos. Confirme de forma independiente la cadena activa, el código desplegado y el verificador previsto; un nombre, símbolo, rótulo de proxy o dirección con checksum familiar no bastan. ERC-5267 eip712Domain() puede revelar el dominio, aunque su compatibilidad es opcional y aún deben revisarse proxies y actualizaciones.

3. Reconstruir el grafo de tipos

Parta de primaryType, conserve el orden de los miembros y reúna recursivamente las estructuras referenciadas. encodeType agrega sus definiciones ordenadas por nombre de tipo. EIP-712 admite enteros de ancho fijo, address, bool, de bytes1 a bytes32, bytes y string dinámicos, matrices y estructuras; el estándar no define los alias uint e int, tipos de punto fijo ni valores cíclicos.

4. Decodificar cada valor y unidad

Relacione cada valor con su tipo declarado y significado en la aplicación. Verifique direcciones completas, unidades enteras sin formatear, signo, orden de matrices, destinatarios, spenders, activos, importes, comisiones, límites, destinos, hashes de calldata y cadenas legibles. Los bytes y string dinámicos se representan en encodeData mediante el hash Keccak-256 de su contenido; las matrices resumen las codificaciones concatenadas y las estructuras anidadas usan su propio hashStruct.

5. Recalcular el resumen de forma independiente

Calcule typeHash = keccak256(encodeType(primaryType)) y después hashStruct(message) = keccak256(typeHash || encodeData(message)). Calcule igual el separador de dominio y combínelo con los bytes de versión ERC-191 0x19 0x01. Compare el resultado del frontend, la biblioteca de firma, el contrato verificador y una implementación independiente; un JSON de aspecto idéntico no demuestra una codificación tipada idéntica.

6. Auditar repetición, tiempo y ejecución

EIP-712 no incluye protección contra repeticiones. Confirme que el verificador comprueba al firmante previsto, consume o invalida el nonce correcto, aplica deadline o ventanas de validez, vincula todos los parámetros críticos y conserva el resultado previsto si un relayer o un atacante se adelanta. La separación de dominio solo evita colisiones entre los dominios realmente codificados; los campos ausentes o erróneos pueden permitir reutilización entre contratos o cadenas.

7. Firmar con alcance mínimo y conciliar el resultado

Rechace campos ocultos, tipos inexplicados, valores ilimitados, plazos lejanos, contratos desconocidos, identificadores de cadena distintos, pantallas de firma ciega o contexto de ejecución incompleto. Conserve el JSON tipado exacto y el resumen, use una cuenta de propósito limitado si es posible y revise transacción, recibo, eventos, saldos, allowances, nonces, estado de la orden y finalidad. Desconectar el sitio no revoca una firma utilizable ni una autoridad ya creada.

Ejemplos calculados

Ejemplo 1: Construcción del tipo y el resumen

Para Order(address maker,address token,uint256 amount,uint256 nonce,uint256 deadline), typeHash es el hash Keccak-256 de esa cadena exacta, incluido el orden de campos. El hash del mensaje es keccak256(typeHash || maker || token || amount || nonce || deadline) y cada miembro codificado ocupa 32 bytes. El resumen final añade 0x1901, el separador de dominio y el hash del mensaje; cambiar amount de 250000000 a 250000001 cambia el resumen e invalida la firma anterior.

Ejemplo 2: Unidades y plazo

Un importe de 250 USDC con seis decimales se codifica como 250000000, no como 250. Si la marca de tiempo actual es 1727000000 y el plazo 1727000900, la ventana es 900 seconds = 15 minutes. La visualización decimal de la cartera y el reloj local solo orientan; el verificador usa el entero sin formatear y su regla temporal en cadena.

Ejemplo 3: Control de repetición

Una orden lleva el nonce 41 y un máximo de 5 ETH. Tras marcar el nonce 41 como consumido, una segunda presentación debe fallar aunque la firma siga siendo criptográficamente válida. Si el contrato no consume el nonce ni hace idempotente la ejecución, la misma firma puede autorizar otros 5 ETH; el separador de dominio no impide por sí solo esa repetición.

Ejemplo 4: Validez de una cartera de contrato

Una cartera de contrato 2-de-3 aprueba un resumen con los firmantes A, B y C configurados. Las firmas de A y B pueden hacer que ERC-1271 devuelva hoy 0x1626ba7e. Si una actualización sustituye B por D, los mismos bytes pueden dejar de ser válidos: ERC-1271 puede depender del estado, política, tiempo y llamadas externas actuales, y la mera recuperación de dirección no decide la validez de una cuenta de contrato.

Riesgos

  • chainId incorrecto o ausente
  • verifyingContract falsificado o inesperado
  • name o version de dominio engañosos
  • Implementación proxy o dominio cambiado tras una actualización
  • primaryType incorrecto o tipo sombra con rótulo parecido
  • Orden de miembros, dependencias o codificador incompatible
  • Dirección truncada, sustituida o etiquetada de forma engañosa
  • Error de decimales o de entero con signo frente a sin signo
  • Elemento de matriz, estructura anidada o carga bytes ocultos
  • Importe ilimitado, alcance amplio o destinatario controlado por un atacante
  • Nonce ausente, obsoleto, compartido o consumido incorrectamente
  • Plazo ausente, lejano, desbordado o interpretado de forma ambigua
  • Repetición entre cadenas, contratos, cuentas o acciones
  • Retención, censura, front-running o redirección por el relayer
  • Maleabilidad de firma o recuperación ECDSA demasiado permisiva
  • Cambio de firmante, módulo, umbral, estado o código ERC-1271
  • Error de renderizado, firma ciega o tipo no compatible en la cartera
  • JSON del frontend distinto del resumen del verificador
  • Revocación o cancelación que pierde una carrera de ordenación
  • Confundir el resultado del aviso de firma con recibo, estado o finalidad

Errores frecuentes

Error 1: Las firmas EIP-712 son transacciones

Son mensajes firmados fuera de la cadena. Un relayer u otro actor puede presentarlos después a un contrato, y la transacción resultante puede gastar Gas y cambiar estado sin que la envíe el firmante.

Error 2: Una vista estructurada significa que la solicitud es segura

Los campos tipados facilitan la inspección, pero esquemas, valores, contratos, rótulos, anidación oculta o renderizado incompleto maliciosos aún pueden engañar.

Error 3: El separador de dominio impide toda repetición

Solo separa el dominio codificado. La repetición dentro de él necesita nonce, plazo, cancelación, contabilidad de ejecuciones o idempotencia; un campo de dominio omitido no aporta límite alguno.

Error 4: Recuperar la dirección esperada demuestra la autorización

La recuperación demuestra una firma EOA sobre el resumen, no la semántica de la aplicación. Las cuentas de contrato requieren su política ERC-1271, no una recuperación ordinaria.

Error 5: Cerrar la página o desconectar la cartera cancela la firma

Una firma copiada puede usarse hasta que el nonce, plazo, cancelación, estado o política del verificador la invalide. Compruebe el estado en cadena correspondiente, no el estado de la sesión.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...