Simulación de transacciones: qué hará una transacción antes de que la firmes

La dirección es correcta. El importe es correcto. Comprobaste los dos. Y la transacción sigue sin ser lo que crees que es.

Esto no es una hipótesis. Es la forma habitual de casi todas las pérdidas en cripto que involucran a una persona cuidadosa. Nadie la convenció de enviar dinero a un desconocido. Aprobó algo cuyas partes visibles eran todas correctas y cuyas consecuencias estaban en otro sitio por completo: en una autorización de gasto de tokens, en una llamada a un contrato, en un carácter de una dirección que había visto cien veces.

La simulación es el intento de cerrar esa brecha: mostrarte los efectos de una transacción en lugar de su contenido, antes de que tu firma la vuelva real.

La brecha entre lo que querías y lo que estás firmando

Una transacción no es una frase. Son bytes.

Cuando esos bytes son una transferencia simple, la brecha entre lo que dicen y lo que hacen es pequeña: una dirección, un importe, una comisión. Cuando son una llamada a un contrato, la brecha puede ser enorme. approve parece un permiso. Es un derecho permanente de otra dirección a mover tus tokens, y bajo el estándar ERC-20 nada en la llamada exige acotar cuánto ni durante cuánto tiempo. Una sola autorización, firmada una vez, puede vaciarse meses después.

La interfaz que estás mirando cuando firmas tiene que traducir esos bytes a una frase. Esa traducción es la superficie de ataque. Si la produce quien quiere tu firma, puede decir cualquier cosa.

Un ensayo, no una promesa

Simular significa ejecutar la transacción contra el estado actual de la cadena sin difundirla, y registrar qué cambia.

En SSP Enterprise eso ocurre al crear una propuesta, antes de que nadie firme. La simulación se construye a partir de lo que produjo el constructor de la propuesta —los destinatarios, los importes, el contrato del token y los datos de llamada que la propia SSP ensambló—, nunca a partir de hex firmado en crudo entregado por un cliente. Se ejecuta en solo lectura. Tres motores cubren las distintas familias de cadenas:

• Las cadenas EVM ejecutan una llamada de solo lectura contra un nodo y leen de vuelta los cambios de saldo resultantes y la llamada decodificada.
• Las cadenas UTXO no necesitan nodo alguno. Las entradas y salidas ya se conocen, así que el antes y el después es aritmética sobre las monedas seleccionadas, y los destinatarios se clasifican como cambio que vuelve a ti o como realmente externos.
• Solana deserializa la transacción sin firmar que produjo el constructor y ejecuta el propio simulateTransaction de la red, con la verificación de firmas desactivada, y luego lee los saldos de tokens del vault antes y después a partir del resultado.

Lo que vuelve es una vista previa: cuál era el saldo de cada activo antes, cuál será después y —en EVM— qué es realmente la llamada, decodificada en un método y sus argumentos.

Dos cosas que no es. No es una garantía: el estado de la cadena se mueve, y una simulación ejecutada al crear la propuesta es una foto de la cadena tal como estaba entonces. Y no es una barrera. Que es la mitad más interesante del diseño, y volveremos a ello.

Catorce cosas que conviene que te digan

Una vista previa que solo muestra números sigue pidiéndote que detectes tú el problema. Por eso la vista previa va acompañada de advertencias, y hay catorce, en cuatro niveles de gravedad.

Autorizaciones: la categoría que vacía más carteras. Una autorización ilimitada o sin acotar es crítica. Cualquier autorización de gasto distinta de cero a una dirección que no está en tu lista de permitidos es alta. Y autorizar a una cuenta de propiedad externa en lugar de a un contrato es alta, porque no hay prácticamente ninguna razón legítima para hacerlo: los contratos gastan autorizaciones, las personas no.

Destinatarios: se señala un destinatario que no esté en los contactos de tu organización ni en la lista blanca del vault. También uno al que tu vault nunca ha enviado antes. Ninguna de las dos cosas está mal por sí sola. Ambas merecen una segunda lectura.

Riesgo de contrato: un contrato de destino cuyo código fuente no está verificado, uno desplegado en los últimos siete días, valor nativo enviado a un contrato siquiera, y cualquier dirección que un proveedor marque como directamente maliciosa.

Ejecución: que la transacción revierta en la simulación, lo que significa que fallará en cadena y desperdiciará la comisión. O que la salida simulada no coincida con los importes que la propuesta declara: que el vault pierda más, o menos, de lo que dice la pantalla.

Degradación: y, claramente etiquetado, el caso en que la simulación no pudo ejecutarse. Un nodo inalcanzable produce «no disponible», no silencio ni un certificado de buena salud inventado.

La distinción entre esas gravedades importa más que el recuento. Crítica y alta hablan de una transacción que probablemente no es lo que aparenta. Media e informativa hablan de una transacción inusual, cosa que las transacciones legítimas son de vez en cuando.

Envenenamiento de direcciones: el ataque que vence a la gente cuidadosa

Una advertencia merece su propia sección, porque apunta precisamente al hábito que casi todos los consejos de seguridad recomiendan.

El envenenamiento de direcciones funciona así. Un atacante envía a tu vault una transacción de importe mínimo o nulo desde una dirección diseñada para compartir los primeros seis y los últimos cuatro caracteres de una dirección con la que ya operas. No se roba nada. Ni siquiera se hace nada, en realidad. La transacción existe para que la dirección parecida aparezca en tu historial.

Más tarde —días después, cuando vuelvas a pagar a la misma contraparte— copias la dirección de tu propio historial de transacciones, como hace la gente cuidadosa en lugar de teclearla. La compruebas como comprueba la gente cuidadosa: los primeros caracteres, los últimos caracteres. Ambos coinciden. El medio no, y el medio es adonde va el dinero.

SSP comprueba cada destinatario propuesto contra las direcciones que tu vault ya conoce, usando exactamente la comparación de prefijo y sufijo que realiza el ojo humano, y emite una advertencia crítica que nombra la dirección suplantada. La misma comprobación se ejecuta en sentido contrario sobre el historial entrante, de modo que una dirección envenenada queda marcada al llegar y no solo cuando estás a punto de usarla.

La razón para conocer este ataque aunque nunca uses SSP: el hábito de verificación que detiene todos los demás ataques de dirección es justo el que este ataque está construido para derrotar. Compara direcciones enteras, o no compares nada.

Por qué las advertencias se calculan en el servidor — y aun así no bloquean nada

El conjunto de advertencias se decide en el servidor, usando los contactos de tu organización y la lista blanca del vault como fuente de verdad. Es deliberado: si un cliente pudiera decidir qué cuenta como permitido, un cliente comprometido podría decidir en silencio que todo lo está.

Y sin embargo nada de eso puede detener una transacción. La simulación nunca condiciona la firma ni la difusión. Un proveedor que dé error, agote el tiempo o no alcance un nodo devuelve «no disponible», y la propuesta sigue siendo plenamente firmable. Todo el subsistema está aislado ante fallos para que un fallo en la vista previa nunca pueda dejar varada una propuesta.

Eso sonará a elección extraña, así que conviene enunciar el razonamiento con claridad. Una vista previa que puede bloquear es una vista previa a la que se puede hacer bloquear: tumbando un nodo, produciendo una crítica falsa, por cualquiera de las mil formas en que el software se estropea. Unos fondos que no pueden moverse porque un servicio orientativo está enfermo son fondos que has perdido en parte. El umbral del multifirma es lo que protege el dinero; la simulación está ahí para informar a las personas que tienen las claves. Qué detiene realmente una transacción es la versión larga de ese argumento.

Cuando el servidor y tu dispositivo no coinciden

Todo lo anterior es la lectura del servidor. Tu dispositivo hace la suya.

Cuando SSP Wallet te muestra una propuesta para firmar, decodifica los bytes por su cuenta y muestra lo que él encontró, no el resumen del servidor. Luego compara ambos. Si la llamada decodificada del servidor implica un conjunto de destinatarios distinto del que dedujo el dispositivo, el dispositivo emite su propia advertencia crítica de discrepancia y degrada visualmente la vista previa del servidor.

La decodificación del dispositivo es la autorizada. La comprobación es deliberadamente conservadora: una simulación del servidor ausente o pendiente es una degradación, no una contradicción, y no se señala como tal. Además solo se aplica a cadenas EVM, donde el servidor produce una llamada decodificada; en cadenas UTXO no hay nada con lo que comparar, y la decodificación propia del dispositivo simplemente se sostiene sola.

Esta es la propiedad que conviene llevarse, sea cual sea tu cartera. Una segunda opinión solo vale algo si viene de un sitio que no podría haber sido comprometido por el mismo acto que el primero. Dos resúmenes del mismo servidor son un solo resumen.

Leer una franja de riesgo sin aprender a ignorarla

Las advertencias funcionan hasta que se convierten en papel pintado. Unos pocos hábitos las mantienen útiles.

Lee primero la gravedad, luego el detalle. Crítica y alta merecen que te detengas. Una advertencia media o informativa en un primer pago a un proveedor nuevo es el sistema funcionando bien, no un motivo de preocupación.

Trata cualquier advertencia de autorización como un alto total. Las transferencias mueven lo que dicen mover. Las autorizaciones conceden un derecho que sobrevive a la transacción. Si no pretendías conceder una autorización permanente, la respuesta es no.

Cree al dispositivo antes que a la pantalla. Si ambos discrepan, el teléfono que tienes en la mano es el que corre sobre un hardware que un atacante habría tenido que comprometer aparte.

No interpretes «no disponible» como «todo bien». Significa que nadie comprobó. Eso es motivo para mirar tú con más atención, sobre todo en un pago grande o inusual.

Todo lo de aquí trata del momento anterior a una firma. Para lo que ocurre después —quién puede firmar, cuántos hacen falta y qué operaciones exigen de nuevo los dos dispositivos— empieza por configurar tu primer vault empresarial y las acciones críticas y la refirma. Y para los patrones de ataque en torno a los cuales están moldeadas estas advertencias, los ataques de phishing dirigidos a usuarios de cripto cubren la mitad humana del problema.