Por qué algunas blockchains ocultan lo que firmas
Por qué cadenas como Ethereum y Solana te obligan a firmar a ciegas, y cómo la industria intenta solucionarlo.
Este artículo está disponible en los siguientes idiomas:
Cuando apruebas una transacción cripto en una billetera de hardware, haces una de dos cosas: o lees un resumen claro en español de lo que va a ocurrir, o firmas una pared de código hexadecimal esperando que todo salga bien. La firma a ciegas es el acto de aprobar una transacción digital sin poder verificar todos sus detalles en un formato legible para humanos.
En febrero de 2025, blind signing contribuyó al $1.5 billion Bybit hack, el mayor robo de criptoactivos de la historia. Los atacantes no rompieron ninguna criptografía. Aprovecharon que los firmantes humanos no podían distinguir entre una transferencia rutinaria y una actualización maliciosa de contrato.
Que tu billetera pueda mostrarte un resumen claro y legible antes de firmar no depende de la calidad del software. Todo se reduce a cómo fue diseñada cada blockchain a nivel de protocolo. Algunas cadenas fueron creadas para que las transacciones se describan a sí mismas. Otras ocultan detalles críticos dentro de datos binarios que requieren información externa para ser descifrados. Este artículo explica cómo esas decisiones de diseño se reflejan en las principales blockchains y qué significa esto para tu seguridad.
El marco de los tres niveles
La firma clara es un proceso de seguridad que te permite verificar todos los detalles de una transacción digital en un formato legible para humanos en una pantalla segura antes de aprobarla.
En 13 de los principales ecosistemas blockchain, el soporte para la firma clara se divide en tres niveles distintos según la arquitectura del protocolo. No se trata de cuáles cadenas son mejores o peores, sino de decisiones de diseño tomadas hace años, muchas veces antes de comprender plenamente sus implicaciones de seguridad.
Nivel 1: diseñado para la transparencia
Estas blockchains dejan claro que la firma es una consecuencia natural de su diseño. La razón principal: utilizan un conjunto finito de estructuras de transacción tipadas donde cada campo tiene un nombre, un tipo y un esquema definido. Una billetera de hardware no necesita información externa para interpretarlas; la transacción te dice exactamente qué es.
El XRP Ledger ofrece probablemente la experiencia de firma clara más sólida y transparente de cualquier cadena importante. Su formato binario incluye un campo TransactionType que permite el análisis determinista en más de 50 tipos de transacciones enumeradas: Payment, OfferCreate, TrustSet, EscrowCreate y más. Cada campo tiene un esquema definido. Una billetera de hardware puede mostrar el destinatario, el monto, la comisión, el memo y cada parámetro específico sin consultar información externa. Cerca del 100 % de las transacciones actuales en mainnet pueden ser firmadas de forma clara.
Polkadot desarrolló la solución de firma clara técnicamente más sofisticada de la industria mediante su sistema de metadatos de tiempo de ejecución (MetadataV14/V15). Cada transacción referencia índices de pallet y de llamada, y los metadatos te dicen exactamente qué significan esos índices y cómo decodificar los argumentos. El reto es que los metadatos completos superan los 200 KB, demasiado para las billeteras de hardware con memoria limitada.
La solución, RFC-0078 (Merkleized Metadata), construye un árbol criptográfico a partir de los metadatos, transmite solo el subconjunto relevante y verifica la prueba de inclusión en la cadena. El resultado es una sola aplicación de Ledger que funciona en todos los parachains de Polkadot sin actualizaciones por cadena.
Cosmos utiliza una arquitectura de mensajes tipados y el estándar SIGN_MODE_TEXTUAL (ADR-050), introducido en Cosmos SDK v0.50, que muestra las transacciones en pantallas legibles para humanos, adaptadas a dispositivos pequeños. Los montos de monedas se muestran como "2 ATOM" en lugar de "2000000uatom". NEAR Protocol lleva la legibilidad aún más lejos con nombres de cuentas legibles para humanos como "alice.near" y argumentos de función serializados en JSON que la billetera puede mostrar como texto plano.
Nivel 2: funciona para lo básico, falla bajo presión
Seis ecosistemas ofrecen una firma clara y sólida para sus operaciones nativas, pero se degradan considerablemente cuando se introducen smart contracts. Bitcoin es el caso ilustrativo. El modelo UTXO implica que las transacciones en bruto no contienen los montos de entrada; una billetera de hardware no puede calcular tu comisión sin información adicional sobre esas salidas previas. PSBT (BIP 174) soluciona esto para pagos estándar, cubriendo aproximadamente el 90 % de las transacciones típicas, pero los gastos por script-path de Taproot y configuraciones multisig complejas siguen generando opacidad.
Stellar muestra la división del nivel 2 de forma clara. Sus 26 tipos clásicos de operación (Payment, ManageSellOffer, ChangeTrust) tienen esquemas fijos y se visualizan perfectamente en billeteras de hardware. Pero los smart contracts Soroban, lanzados en 2024, reintroducen la opacidad estilo EVM; los parámetros llegan como tipos binarios codificados que requieren conocimiento específico del contrato para ser interpretados, reduciendo la cobertura de aproximadamente 95 % para operaciones clásicas a casi cero para interacciones Soroban en bruto. Algorand, Cardano, Aptos y Tezos siguen patrones similares: cobertura fuerte para operaciones nativas, pero grandes vacíos para lógica programable compleja.
Nivel 3: la opacidad está en el diseño
Tres ecosistemas presentan decisiones arquitectónicas que hacen que la firma clara sea una batalla cuesta arriba, sin importar la calidad del software de la billetera. Entender el motivo ayuda a explicar por qué existen advertencias de firma a ciegas en casi todas las interfaces DeFi importantes.
Ethereum y todas las cadenas compatibles con EVM comparten el problema central: la codificación ABI no se describe a sí misma. Cuando interactúas con un smart contract, el campo de datos de la transacción contiene un selector de función de 4 bytes, los primeros cuatro bytes de un hash del nombre de la función, seguido de parámetros codificados en bloques de 32 bytes. Sin el ABI JSON del contrato, esto es puro ruido hexadecimal. Ese ABI no se almacena en la cadena. Una billetera de hardware no tiene forma de saber que 0xa9059cbb... significa "transferir 1,000 USDC a 0xABC..." a menos que cuente con metadatos externos.
Los contratos proxy, que enrutan la ejecución a contratos de implementación cuyas direcciones pueden cambiar, agravan el problema, que es exactamente como se ejecutó el hack de Bybit.
La respuesta de la industria a esto es ERC-7730, un estándar de metadatos creado en 2024 que proporciona archivos JSON que describen cómo decodificar y mostrar interacciones específicas de contratos. Funciona, pero requiere que alguien escriba y mantenga esos metadatos para cada contrato con el que puedas interactuar. Es, en esencia, un parche aplicado a una arquitectura que no fue creada para la transparencia.
Solana es, si cabe, aún más desafiante. Las instrucciones de transacción contienen un ID de programa y un arreglo de bytes opaco con datos de instrucción, sin un ABI estandarizado; cada programa define su propio formato de serialización. El framework Anchor ofrece un enfoque semi-estándar usando discriminadores de 8 bytes, pero muchos programas no usan Anchor ni publican sus definiciones de interfaz. Para las interacciones DeFi, la mayoría del volumen de transacciones de Solana requiere firma a ciegas.
TON añade aún más complejidad mediante la ejecución asíncrona: solo firmas el mensaje inicial, y todo lo que sucede después en bloques subsiguientes es invisible al momento de firmar.
Conclusiones
La recomendación más práctica: conoce en qué nivel está tu cadena antes de usar una billetera de hardware para DeFi. En cadenas de Nivel 1, la firma clara funciona como debe. En el Nivel 2, las transferencias simples son seguras de firmar con confianza, pero deberías investigar cualquier interacción compleja con smart contracts. En el Nivel 3, trata cada transacción en un protocolo DeFi con escepticismo adicional y revisa si la combinación de dApp y billetera soporta metadatos ERC-7730 antes de aprobar cualquier operación importante.
Los fabricantes de billeteras de hardware están trabajando activamente en esto. El Generic Parser de Ledger lee archivos de metadatos ERC-7730 y muestra los detalles de la transacción en la pantalla segura.
El enfoque de Merkleized Metadata de Polkadot es probablemente la solución más elegante de la industria: sin confianza, verificada criptográficamente y nativa del protocolo. La industria avanza hacia mejores estándares, pero las limitaciones de protocolo subyacentes de las cadenas de Nivel 3 no van a desaparecer.
La regla más simple: si tu billetera te muestra un hash o una secuencia de bytes hexadecimales y te pide que lo firmes, considéralo una señal de alerta.
Recursos y lecturas recomendadas
Los siguientes recursos ofrecen mayor profundidad técnica sobre los protocolos y estándares mencionados en este artículo.
Estándar de metadatos para firma clara en EVM | |
Firma parcial de transacciones en Bitcoin | |
Firma clara sin confianza en Polkadot | |
Firma legible para humanos en Cosmos | |
Identificadores de cuenta legibles para humanos | |
Esquemas de transacciones tipadas en XRP | |
Estándar de firma de datos tipados fuera de cadena | |
Sistema de metadatos de Polkadot/Substrate | |
Envíos comunitarios de metadatos | |
ABI para smart contracts en Algorand |
FAQ
-
La firma clara significa que tu billetera de hardware muestra detalles legibles en su pantalla de confianza antes de que apruebes: dirección de destino, monto del token, comisión de red y qué acción estás autorizando. La firma a ciegas implica que la billetera muestra datos binarios codificados (generalmente una cadena hexadecimal) que no puedes interpretar, y los apruebas a ciegas. El riesgo es que una aplicación comprometida podría mostrarte una cosa en pantalla mientras envía tu firma para una transacción completamente diferente.
-
No siempre, pero el riesgo es real. Para transferencias simples de ETH entre billeteras normales, tu billetera de hardware generalmente puede mostrar claramente el destinatario y el monto. El problema de opacidad surge cuando interactúas con smart contracts: hacer swaps, aportar liquidez, aprobar permisos. En esas operaciones, si ves un resumen claro depende de si la dApp y la billetera han implementado los metadatos ERC-7730. Si no lo han hecho, firmas a ciegas.
-
El diseño de protocolos implica compromisos. El sistema ABI flexible de Ethereum permite el rico ecosistema de aplicaciones DeFi que no podría existir en una cadena más restringida como XRP Ledger. Esa flexibilidad tiene el costo de no tener transacciones autodescriptivas. Cambiar esto de forma retroactiva rompería la compatibilidad hacia atrás de miles de smart contracts ya desplegados. El enfoque de metadatos ERC-7730 y esfuerzos como EIP-712 son mejoras pragmáticas dentro de la arquitectura existente, no un rediseño total del protocolo.
-
ERC-7730 es un estándar de metadatos JSON creado en 2024 que indica a las billeteras de hardware cómo decodificar y mostrar interacciones específicas con smart contracts. Un equipo de protocolo puede enviar un archivo de metadatos que mapea la codificación ABI bruta de sus funciones de contrato a etiquetas y formatos legibles para humanos.
-
Sí, de manera significativa. Incluso cuando una billetera de hardware muestra datos codificados en lugar de un resumen claro, la clave privada nunca sale del elemento seguro y la decisión de firmar ocurre en hardware aislado. Una computadora comprometida no puede extraer tu clave. El riesgo con la firma a ciegas en hardware es que podrías aprobar una transacción que no aprobarías si la entendieras, pero tu clave permanece segura. Las billeteras de software que firman a ciegas exponen tanto tu decisión de aprobación como, si el software está comprometido, potencialmente tu clave.
