Por qué algunas blockchains muestran lo que firmas (y otras no)

Nivel 1: Arquitectura transparente — la intención de la transacción es legible por diseño

Cuatro ecosistemas destacan por hacer de la firma clara una consecuencia natural de su diseño de protocolo, en lugar de una solución posterior que requiera herramientas externas.

XRP Ledger

XRP Ledger ofrece el caso más sólido de firma clara entre las principales blockchains. Su arquitectura utiliza un conjunto finito de más de 50 tipos de transacción enumerados (Payment, OfferCreate, TrustSet, EscrowCreate, NFTokenMint, etc.), cada uno con un esquema completamente definido de campos nombrados y tipados. 

El formato binario es autodescriptivo — un campo TransactionType permite un análisis completamente determinista, y el esquema completo de campos se mantiene en el archivo de definiciones del código fuente de rippled. 

Una billetera de hardware puede mostrar cada campo de cada tipo de transacción conocido: destinatario, monto (con moneda y emisor para tokens), comisión, memos y parámetros específicos del tipo. El modelo basado en cuentas significa que los montos son explícitos (sin la complejidad UTXO), y las comisiones son un campo simple en lugar de un cálculo implícito. 

Casi el 100% de las transacciones actuales en mainnet pueden ser firmadas claramente. El único riesgo es que los nuevos tipos de transacción agregados mediante actualizaciones del protocolo (como las recientes operaciones Vault y Loan) requieran actualizaciones de la app de la billetera de hardware; los tipos desconocidos pasarían a firma ciega.
 

Polkadot / Substrate

Polkadot ha desarrollado la solución de firma clara técnicamente más sofisticada de la industria. Su sistema de metadatos en tiempo de ejecución (MetadataV14/V15) proporciona un registro completo y autodescriptivo de tipos para cada pallet (módulo), llamada y tipo de datos en el runtime. 

Cada transacción (extrinsic) se estructura como pallet_index || call_index || encoded_arguments, y los metadatos te indican exactamente qué significan esos índices y cómo decodificar los argumentos. 

El principal desafío era que los metadatos completos superan los 200 KB — demasiado para billeteras de hardware con ~64 KB de RAM. La solución, RFC-0078 (Merkleized Metadata), construye un árbol de Merkle a partir de los metadatos y transmite solo el subconjunto relevante (tipos necesarios para la transacción específica) junto con una prueba criptográfica de inclusión. 

El hash de los metadatos se verifica en cadena mediante la extensión firmada CheckMetadataHash, haciendo el sistema sin confianza. Esto permite una sola aplicación genérica de Ledger que funciona en todas las parachains y relay chains de Polkadot sin actualizaciones por cadena.

El enfoque gestiona las actualizaciones del runtime de manera elegante, incluso cuando cambian los índices de llamada, ya que los metadatos y pruebas frescas mantienen la firma precisa.

Cosmos / Tendermint

Cosmos/Tendermint se benefician de una arquitectura de mensajes tipados donde cada transacción contiene uno o más objetos sdk.Msg envueltos en google.protobuf.Any de Protobuf, que incluye un campo type_url que identifica el tipo de mensaje.
Los mensajes estándar como MsgSend, MsgDelegate y MsgVote tienen esquemas bien conocidos. 

La solución dedicada de firma clara del ecosistema es SIGN_MODE_TEXTUAL (ADR-050), introducida en Cosmos SDK v0.50. Renderiza las transacciones como una secuencia de pantallas adaptadas a dispositivos pequeños (~40 caracteres), con value renderers que convierten los datos en formatos legibles: las monedas se muestran como "2 ATOM" en vez de "2000000uatom", las direcciones usan bech32 y las fechas RFC3339. 

Los desarrolladores pueden proveer renderizadores personalizados para sus tipos de mensaje (con la condición de que las funciones de formato y análisis sean perfectamente invertibles). La carga firmada incluye tanto la representación textual como un hash de los bytes originales, preservando las garantías de seguridad.

NEAR Protocol

NEAR Protocol logra la firma clara mediante varias decisiones arquitectónicas que priorizan la legibilidad humana. Los identificadores de cuenta son nombres legibles, como "alice.near", en lugar de direcciones hexadecimales. 

Las transacciones contienen enums tipados Action (Transfer, Stake, FunctionCall, AddKey, etc.) que siempre son identificables. Lo más importante es que la acción FunctionCall incluye un method_name como cadena de texto (por ejemplo, "transfer", "set_greeting") y argumentos serializados en JSON por defecto. 

Una billetera de hardware puede mostrar: "Llamar al método 'swap' en app.defi.near con args: {amount: 1000, token: 'usdc.near'}." Esto es mucho más legible que cualquier sistema basado en selectores. La principal limitación es que algunos contratos optan por argumentos serializados en Borsh por eficiencia de gas, lo que los vuelve opacos sin el esquema.

Nivel 2: Condicionalmente clara — operaciones nativas funcionan, los contratos inteligentes complican

Buena firma clara para operaciones de capa base. Hay una degradación significativa cuando entra la programabilidad de propósito general.

Bitcoin

Bitcoin ocupa una posición única: su modelo de transacciones genera desafíos para la firma clara incluso sin contratos inteligentes. El modelo UTXO implica que las transacciones crudas no contienen los montos de entrada, es decir, las entradas hacen referencia a salidas previas por hash de transacción e índice, pero omiten cuánto valían esas salidas. 

Sin esta información, una billetera de hardware no puede calcular la comisión (que equivale al total de entradas menos el de salidas) ni verificar que no esté pagando de más. PSBT (BIP 174) resuelve esto envolviendo las transacciones sin firmar con metadatos de UTXO y rutas de derivación BIP32 para identificar direcciones de cambio. 

Con PSBT, las billeteras de hardware pueden mostrar claramente direcciones de destinatario, montos y comisiones para pagos estándar, cubriendo cerca del 90% de las transacciones típicas. La complejidad aumenta con configuraciones multisig, scripts con bloqueo de tiempo y gastos por Taproot script-path—P2SH y P2WSH ocultan scripts arbitrarios tras hashes, y la estructura MAST de Taproot hace invisibles las condiciones alternativas de gasto hasta que se usan.

Aptos

Aptos se beneficia del sólido sistema de tipos de Move y la disponibilidad de ABIs en cadena. Las cargas de transacción contienen identificadores de función totalmente calificados, como 0x1::aptos_account::transfer, dirección del módulo, nombre del módulo y nombre de la función, todos visibles. 

El SDK puede consultar los ABIs en cadena para deserializar los argumentos codificados en BCS. Esto significa que una billetera de hardware con acceso al ABI podría mostrar: "Llamar 0x1::aptos_account::transfer(destinatario: 0xABC..., monto: 1000)." 

Sin embargo, BCS (Binary Canonical Serialization) no es autodescriptivo; sin el esquema ABI, los bytes BCS crudos carecen de sentido. Las cargas de script (bytecode Move arbitrario) omiten el formato estructurado de función de entrada. La app de Ledger para Aptos incluye una opción explícita "Enable Blind Signing" para transacciones complejas, confirmando la brecha entre operaciones simples y complejas.

Stellar

El patrón de nivel 2 en su forma más pura. Sus 26 tipos de operación clásicos (Payment, ChangeTrust, ManageSellOffer, etc.) tienen esquemas fijos y son completamente analizables: la app de Ledger muestra tipo de operación, monto, destino, activo, memo y comisión en una revisión paso a paso. Cobertura de ~95% para operaciones clásicas.

• Los contratos inteligentes Soroban (lanzados en 2024) reintroducen exactamente el problema de opacidad encontrado en Ethereum. Las llamadas llegan como operaciones InvokeHostFunction con direcciones de contrato en formato opaco y parámetros codificados como tipos ScVal que requieren conocimiento específico del contrato para decodificarse. Prácticamente 0% de firma clara para interacciones Soroban sin metadatos externos.

Algorand

Siete tipos de transacción tipados (Payment, Asset Transfer, Asset Configuration, Key Registration, Application Call, Asset Freeze, State Proof), todos completamente analizables desde su codificación MessagePack. El estándar ARC-4 ABI proporciona firmas de métodos, nombres de parámetros y descripciones para contratos inteligentes compatibles.

• Los contratos que no son ARC-4 tienen argumentos opacos.
• Todos los contratos inteligentes pueden generar hasta 256 transacciones internas, incluyendo llamadas anidadas hasta 8 niveles de profundidad, que son completamente invisibles al momento de firmar.

Cardano & Tezos

El modelo eUTXO de Cardano permite mostrar claramente entradas, salidas, comisiones y valores multi-activo para transacciones simples. Pero las interacciones con scripts Plutus involucran datums y redeemers que son estructuras arbitrarias codificadas en CBOR sin un esquema estándar para interpretación humana. CIP-21 señala explícitamente que el modo Plutus "apunta a máxima flexibilidad a costa de que los usuarios puedan ser engañados".

Tezos tiene una ventaja estructural: los tipos de parámetros de contrato se almacenan en cadena y los entrypoints usan nombres de cadena en vez de selectores basados en hash, eliminando el problema de colisiones. Pero la codificación binaria Micheline aún requiere el esquema de tipos del contrato para decodificar completamente, y la app de Ledger para Tezos reconoce la visualización limitada de parámetros complejos.

❌ Arquitectura opaca — la firma clara es una batalla cuesta arriba

Las decisiones de diseño fundamentales —no la falta de herramientas— hacen que la firma clara sea inherentemente difícil aquí. Las capas externas de metadatos ayudan en los márgenes pero no pueden arreglar la arquitectura subyacente.

Ethereum / Cadenas EVM

El caso más prominente y estudiado. Cuando un usuario interactúa con un contrato inteligente, el campo de datos de la transacción contiene un selector de función de 4 bytes (los primeros 4 bytes de keccak256 de la firma de la función) seguido de parámetros codificados en ABI en palabras de 32 bytes. Sin el ABI JSON del contrato—que no se almacena en cadena—esto es puro ruido hexadecimal. Una billetera de hardware que ve 0xa9059cbb000...03e8 no puede saber que significa "Transferir 1000 tokens a 0xABC..." salvo que tenga metadatos externos.

Los desafíos se agravan con patrones endémicos de EVM:

• Colisiones de selectores de función: La base de datos 4byte.directory contiene cerca de un millón de firmas—mucho más allá del umbral del problema del cumpleaños para un espacio de 32 bits. Diferentes funciones pueden producir selectores idénticos.
• Contratos proxy: Redirigen la ejecución mediante delegatecall a contratos de implementación cuyas direcciones pueden cambiar en cualquier momento. El hackeo de Bybit explotó exactamente esta brecha.
• Patrones multicall: Anidan calldata codificada en ABI dentro de parámetros, requiriendo decodificación recursiva.
• EIP-712: Mejora la legibilidad para mensajes fuera de cadena (permisos, órdenes) pero no resuelve la opacidad de las transacciones en cadena.

Solana

Probablemente la arquitectura más desafiante para la firma clara. Las instrucciones de transacción contienen un program_id, una lista de cuentas y un arreglo de bytes opaco con los datos de la instrucción. No existe un ABI estandarizado—cada programa define su propio formato de serialización. El framework Anchor ofrece un enfoque semi-estándar (discriminadores de 8 bytes derivados de SHA-256 del nombre de la instrucción), pero es una convención de framework, no un requisito de protocolo. Muchos programas no usan Anchor ni publican IDLs.

• Las Address Lookup Tables en transacciones versionadas comprimen direcciones de 32 bytes en índices de 1 byte—las billeteras de hardware no pueden verificar el contenido de la lookup table porque carecen de acceso en cadena. La documentación oficial de Solana lo reconoce explícitamente.
• Las cadenas de Cross-Program Invocation son invisibles al momento de firmar.
• Las transferencias simples de SOL y operaciones de tokens SPL—Ledger puede analizarlas. Las interacciones DeFi, que representan la gran mayoría del volumen de transacciones de Solana—requieren firma ciega casi siempre.

TON

Combina múltiples características arquitectónicas que, por separado, ya dificultan la firma clara, y en conjunto la hacen aún más compleja:

• Estructura de datos basada en celdas: Todos los datos se representan como árboles de celdas (cada una con hasta 1023 bits y hasta 4 referencias), requiriendo recorridos recursivos para analizar mensajes que exceden una sola celda.
• Codificación TL-B: Opera a nivel de bit con constructores complejos y referencias recursivas—mucho más difícil de analizar en hardware limitado que los formatos alineados por byte.
• Sin ABI universal: Los códigos de operación de 32 bits son una convención, no una exigencia del protocolo.
• Ejecución asíncrona: Una sola acción de usuario puede desencadenar mensajes internos en cascada entre múltiples contratos y shards en bloques posteriores. El usuario solo firma el mensaje externo inicial—todo lo que ocurre después es invisible e impredecible al momento de firmar.

Sui (Mención honorífica)

Comparte el sólido sistema de tipos de Move con Aptos, lo que ayuda a nivel de instrucción. Pero los Programmable Transaction Blocks de Sui pueden contener hasta 1.024 comandos que encadenan resultados entre operaciones—dividir una moneda, depositar en un protocolo DeFi, pedir un préstamo con garantía, transferir los fondos, todo en una sola transacción atómica. Aunque los comandos individuales están bien tipados, mostrar un PTB de varios pasos en la pantalla de una billetera de hardware de manera realmente comprensible es un desafío extremo de UX. Entender la transacción completa requiere analizar toda la secuencia de comandos y sus dependencias de datos.