EIP-712: algo que leer antes de pulsar Firmar
Un monedero puede proteger una clave sin que su dueño entienda qué está firmando. EIP-712 dio una estructura legible a los mensajes; la aplicación sigue decidiendo qué autoriza esa firma.
Resumen clave en 3 puntos
- El detonante / ParadojaEIP-712, creado en septiembre de 2017, normaliza el cálculo del hash y la firma de mensajes estructurados.
- El punto de inflexiónLa información de dominio separa contextos; la aplicación debe gestionar la reutilización de una firma.
- El legado históricoERC-2612 permite autorizar un límite de uso de tokens sin que el propietario envíe personalmente la transacción de aprobación.
Cronología de los hechos
EIP-712 incorpora campos con nombre y tipo, además de separación de dominios.
ERC-2612 define permit con un nonce y un plazo de presentación.
La clave podía firmar lo que su dueño no sabía leer
El 12 de septiembre de 2017, Remco Bloemen, Leonid Logvinov y Jacob Evans presentaron EIP-712. Partían de un problema cotidiano: un monedero podía mostrar una larga cadena hexadecimal y pedir una firma. La criptografía podía funcionar perfectamente mientras el propietario apenas entendía el contenido. La propuesta dio nombres y tipos a los campos para que el monedero pudiera mostrar qué se estaba solicitando.[1]
El cambio iba más allá de la apariencia. Remitente, destinatario y cantidad podían representarse como campos distintos. La especificación también definió un dominio de firma con los campos pertinentes, como nombre de la aplicación, versión, identificador de cadena y contrato verificador. Un mensaje aparentemente idéntico en otro contexto podía producir un resultado de firma distinto. Esos datos delimitan el contexto; no certifican la honradez de una empresa.[1]
Las etiquetas también cuentan
La documentación de MetaMask explica la consecuencia para la interfaz. Su método eth_signTypedData_v4 presenta datos estructurados y pide a los desarrolladores tratar el nombre del tipo principal, el dominio y los campos como parte de la interfaz de seguridad. Una solicitud técnicamente correcta puede resultar difícil de juzgar si sus etiquetas son confusas. La estructura ofrece un lugar para explicar; el monedero y la aplicación deben aprovecharlo.[2]
La legibilidad responde primero a una pregunta: qué datos se firman. Que estos autoricen un inicio de sesión, una orden o el uso de tokens depende de la aplicación receptora. Es una interpretación de diseño basada en separar la representación del mensaje de su efecto. Una pantalla bien ordenada no constituye, por sí sola, una recomendación de aceptar.[1][2]
El permiso puede adelantarse a la transacción
ERC-2612, creado el 13 de abril de 2020, ofrece un ejemplo concreto. Su mensaje permit identifica al propietario, la dirección autorizada para gastar, el importe, un nonce y un plazo. Una presentación válida fija la autorización de gasto en ese importe e incrementa el nonce. Cualquiera puede presentar el permiso: el propietario no tiene que enviar personalmente la transacción de aprobación. La firma no transfiere tokens por sí misma, pero la autorización resultante puede permitir una transferencia posterior mediante transferFrom.[3]
El nonce impide volver a utilizar con éxito un permit ya consumido. El plazo limita cuándo puede presentarse; no hace caducar automáticamente una autorización ya establecida. Alguien debe enviar una transacción a la cadena para que permit surta efecto. EIP-712 deja expresamente a las aplicaciones la gestión de repeticiones. Leer una solicitud implica considerar sus campos y la acción del contrato receptor. El botón seguía siendo pequeño; la decisión anterior a pulsarlo se volvió más visible.[1][3]
Historias conectadas con este personaje o suceso
Explora las repercusiones históricas y los vínculos entre figuras y momentos clave.
Trezor: la última confirmación, en una pantalla pequeña
Guardar bien una clave no decide adónde debe ir el dinero. Para eso importa la pequeña pantalla.
Leer historia →
Una sola firma puede reescribir tu billetera: la paradoja del EIP-7702 en Ethereum
La actualización Pectra de Ethereum permitió a las billeteras EOA ejecutar código mediante delegación EIP-7702. La persistencia que habilita el empaquetado y la recuperación se convirtió en un nuevo vector de phishing.
Leer historia →Fuentes y referencias
- [1]Fuente 1: EIP-712: motivación, dominios y límites frente a la reutilizaciónEthereum Improvement Proposals · 2017-09-12Consultado 2026-09-24
- [2]Fuente 2: MetaMask: firma estructurada e interfaz de seguridadMetaMaskConsultado 2026-09-24
- [3]Fuente 3: ERC-2612: autorización, nonce, plazo y presentaciónEthereum Improvement Proposals · 2020-04-13Consultado 2026-09-24