Hot vs Cold Wallets: gestión de claves, modelos de amenaza y verificación

Respuesta directa y alcance

Una hot wallet es cualquier wallet cuya clave privada o capacidad de firma esté disponible para un proceso conectado a Internet sin un paso de aprobación separado. Una cold wallet es cualquier wallet cuyo material de firma se mantiene fuera de línea y solo se utiliza tras una aprobación explícita, normalmente física. La distinción se refiere a la exposición y al flujo de firma, no a si el dispositivo es un teléfono, una extensión de navegador, un componente de hardware o una copia de seguridad en papel.

Este artículo cubre las diferencias operativas que importan cuando se elige o audita una configuración de wallet: exposición de claves, frecuencia de transacciones, recuperación y verificación. No clasifica proveedores ni afirma resultados de seguridad medidos. Cualquier cifra de rendimiento o fiabilidad que vea en la tabla de resultados es un marcador de posición para mediciones que usted realice en su propio entorno.

Supuestos y requisitos previos

Los procedimientos a continuación asumen que tiene una wallet de prueba con fondos en una testnet o una cuenta de mainnet con poco valor, un endpoint JSON-RPC que controla o en el que confía, y herramientas básicas de línea de comandos. Nunca debe pegar una clave privada de producción en el historial de un shell, una ventana de chat o la consola de un navegador. Utilice variables de entorno y una clave desechable para cada prueba.

También necesita una forma de consultar el estado de la cadena. Si aún está decidiendo qué endpoint usar, la guía de RPC Assistant sobre cómo elegir un endpoint fiable y la descripción general del servicio RPC de OnFinality son puntos de partida razonables. Para parámetros específicos de la red, consulte la lista de redes compatibles.

• Una clave de prueba con valor insignificante, almacenada en una variable de entorno como PRIVATE_KEY.
• Una RPC_URL para la red que está probando; no codifique endpoints públicos en scripts que comparta.
• Node.js 18+ o Python 3.10+ si desea ejecutar los ejemplos de firma.
• Una hardware wallet o un firmante aislado (air-gapped) si está probando un flujo en frío.

El modelo mental: superficie de exposición frente a frecuencia de firma

Cada wallet tiene dos propiedades independientes: cuánto tiempo la clave es accesible por software y con qué frecuencia necesita firmar. Una hot wallet minimiza la fricción pero maximiza la ventana en la que malware, una extensión de navegador maliciosa o una dependencia comprometida pueden alcanzar la clave. Una cold wallet minimiza esa ventana pero añade pasos a cada transacción, lo que crea su propio modo de fallo: la gente mueve fondos a una hot wallet y los deja allí.

Una forma útil de razonar sobre esto es separar la clave de la dirección. La dirección es pública y segura de compartir; la clave es lo único que autoriza el gasto. Por lo tanto, hot versus cold es una cuestión de dónde vive la clave y qué debe suceder antes de usarla. Una hardware wallet que permanece conectada a un portátil y firma sin confirmación está más cerca de una hot wallet de lo que sugiere su marketing. Una wallet móvil con una frase de contraseña fuerte y sin permiso de Internet para la aplicación de firma está más cerca de cold de lo que sugiere su formato.

• Hot: clave accesible por un proceso en línea; la firma es rápida y a menudo automática.
• Cold: clave mantenida fuera de línea; la firma requiere una aprobación explícita o un dispositivo separado.
• Warm: un híbrido donde las claves se cifran en reposo pero se descifran para firmar en una máquina conectada.
• La etiqueta importa menos que la respuesta a: ¿qué puede firmar sin una persona presente?

Verificar una dirección y un saldo con curl

Antes de confiar en cualquier interfaz de wallet, verifique que la dirección que muestra coincide con la clave que cree controlar. La comprobación más sencilla es consultar la cadena directamente. Las siguientes llamadas curl utilizan métodos JSON-RPC compatibles con la mayoría de las redes EVM. Reemplace RPC_URL y ADDRESS con sus valores.

La primera llamada devuelve el saldo en wei. La segunda devuelve el número de transacciones, lo que es útil para detectar un hueco de nonce tras una transacción fallida. Si la interfaz de la wallet y el RPC no coinciden, deténgase e investigue antes de firmar cualquier cosa.

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBalance","params":["'"$ADDRESS"'","latest"]}'

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_getTransactionCount","params":["'"$ADDRESS"'","latest"]}'

Derivar una dirección a partir de una clave en JavaScript

Un error común en cold wallets es hacer copia de seguridad de lo incorrecto. Necesita la frase semilla o la clave privada, no la dirección. El siguiente script deriva una dirección a partir de una clave privada para que pueda confirmar que una copia de seguridad realmente controla la dirección que espera. Ejecútelo solo en una máquina fuera de línea o con una clave desechable.

El script utiliza ethers, que está ampliamente disponible. Imprime la dirección y nunca registra la clave. Compare la salida con la dirección que muestra su wallet. Si difieren, su copia de seguridad no es para esa dirección.

// npm install ethers
import { Wallet } from 'ethers';

const pk = process.env.PRIVATE_KEY;
if (!pk) throw new Error('Set PRIVATE_KEY to a throwaway key');

const wallet = new Wallet(pk);
console.log('address:', wallet.address);
// Do not print the private key.

Probar un flujo de firma de extremo a extremo

El diagnóstico más útil para decidir entre hot y cold es una prueba en seco de la ruta de firma exacta que utilizará en producción. Para una hot wallet, eso significa confirmar qué proceso puede acceder a la clave y qué sucede si ese proceso se ve comprometido. Para una cold wallet, significa confirmar que el firmante fuera de línea produce una firma válida y que la máquina en línea puede transmitirla sin ver nunca la clave.

Un procedimiento práctico es firmar una transacción de valor cero o mínimo, transmitirla y verificar su inclusión. El ejemplo de Python a continuación construye y envía una transacción usando web3.py. Asume una testnet y una clave de prueba con fondos. Si está utilizando una hardware wallet, reemplace la cuenta local por la interfaz de firma de su dispositivo y mantenga la clave fuera de la máquina anfitriona.

from web3 import Web3
import os

w3 = Web3(Web3.HTTPProvider(os.environ['RPC_URL']))
acct = w3.eth.account.from_key(os.environ['PRIVATE_KEY'])

nonce = w3.eth.get_transaction_count(acct.address)
tx = {
    'to': acct.address,
    'value': 0,
    'gas': 21000,
    'gasPrice': w3.eth.gas_price,
    'nonce': nonce,
    'chainId': w3.eth.chain_id,
}
signed = acct.sign_transaction(tx)
tx_hash = w3.eth.send_raw_transaction(signed.raw_transaction)
print('sent:', tx_hash.hex())
receipt = w3.eth.wait_for_transaction_receipt(tx_hash, timeout=120)
print('status:', receipt.status, 'block:', receipt.blockNumber)

Resultados de verificación esperados

Una prueba en seco exitosa produce un hash de transacción, un recibo con estado 1 y un número de bloque. El nonce del remitente aumenta en uno. Si consulta el saldo antes y después, la diferencia debe ser igual al valor más el gas. Para una autotransferencia de valor cero, el saldo disminuye solo por el gas, lo que es una forma limpia de confirmar que la firma y la transmisión funcionan sin mover fondos significativos.

Para un flujo en frío, el resultado esperado es que la máquina en línea nunca tenga acceso a la clave. Puede verificar esto comprobando que la clave no esté presente en el entorno del proceso de transmisión. Si su firmante requiere que la clave se cargue en la máquina en línea, tiene una configuración warm o hot independientemente de la etiqueta del dispositivo.

• El estado del recibo 1 y un número de bloque confirman la inclusión.
• El nonce se incrementa exactamente en uno por cada transacción exitosa.
• El delta de saldo es igual al valor más el gas para una transferencia simple.
• El proceso de transmisión no debe contener la clave privada en su entorno.

Tabla de resultados para sus propias mediciones

Utilice la tabla a continuación para registrar lo que observa en su entorno. No la complete con números de la configuración de otra persona; el objetivo es comparar sus rutas hot y cold en las mismas condiciones. Mida la latencia de firma, la latencia de transmisión y el número de pasos manuales requeridos. La tabla es una plantilla, no un benchmark.

• | Métrica | Ruta hot wallet | Ruta cold wallet | Notas |
• | --- | --- | --- | --- |
• | Tiempo desde la intención hasta la transacción firmada | (medir) | (medir) | Incluir pasos de aprobación |
• | Tiempo desde firmada hasta incluida | (medir) | (medir) | Depende del RPC y la red |
• | Pasos de aprobación manual | (contar) | (contar) | Las confirmaciones físicas cuentan |
• | Clave accesible por proceso en línea | sí/no | sí/no | Verificar con inspección de procesos |
• | Recuperación probada | sí/no | sí/no | Restaurar desde copia de seguridad en una máquina limpia |

Solución de problemas comunes

La mayoría de los fallos de wallet no son criptográficos; son operativos. Una transacción que nunca se confirma suele ser un hueco de nonce, una configuración de gas demasiado baja o un endpoint RPC que está por detrás de la cabeza de la cadena. Una cold wallet que muestra una dirección diferente a la esperada generalmente significa una ruta de derivación incorrecta o una copia de seguridad de otra cuenta. Una hot wallet que de repente muestra transacciones desconocidas generalmente significa que la clave quedó expuesta.

Cuando vea una discrepancia, detenga la firma y verifique contra una fuente independiente. Consulte la cadena directamente, compruebe la derivación de la dirección y confirme el ID de cadena. Si está utilizando un endpoint compartido o público, una respuesta obsoleta puede parecer un error de la wallet. El acceso a un nodo dedicado reduce ese tipo de ambigüedad, y la descripción general del nodo dedicado de OnFinality explica cuándo eso importa.

• Hueco de nonce: consulte eth_getTransactionCount y compárelo con el recuento pendiente de la wallet.
• Cabeza de cadena obsoleta: compare blockNumber entre dos endpoints.
• Dirección incorrecta: vuelva a derivar desde la copia de seguridad y compare.
• Transacción saliente inesperada: trate la clave como comprometida y mueva los fondos restantes.

Limitaciones y compensaciones

El almacenamiento en frío no es automáticamente más seguro. Traslada el riesgo de atacantes remotos a pérdida física, error del usuario y compromiso de la cadena de suministro del dispositivo de firma. Una frase semilla perdida sin copia de seguridad es irrecuperable. Una hardware wallet comprada a un revendedor no confiable puede llegar con una semilla preinicializada. Las hot wallets tampoco son automáticamente inseguras; una hot wallet con un saldo pequeño y una frase de contraseña fuerte puede ser una cuenta de gastos aceptable.

La compensación práctica suele ser una división: mantener un pequeño saldo operativo en una hot wallet y la mayor parte del valor detrás de una ruta de firma en frío. Esa división reduce el radio de impacto de un compromiso de la hot wallet sin forzar un paso de firma en frío para cada pago pequeño. La división exacta depende de su frecuencia de transacciones y su tolerancia al esfuerzo de recuperación, no de una regla universal.

Próximos pasos

Comience escribiendo su modelo de amenaza en un párrafo: quién o qué podría alcanzar su clave, y qué perdería si lo hicieran. Luego ejecute los pasos de verificación anteriores en una testnet. Una vez confirmado el flujo de trabajo, pruebe la recuperación en una máquina limpia antes de mover valor significativo.

Si necesita un endpoint fiable para los pasos de verificación, revise la guía de endpoints RPC y compare planes en la página de precios de RPC. Para equipos que ejecutan infraestructura de firma, la opción de nodo dedicado y la descripción general del servicio API son las siguientes lecturas naturales. Para una recomendación concreta de endpoint o proveedor, pregunte a RPC Assistant en lugar de adivinar a partir de una lista.

• Documente la ruta de firma y quién puede aprobar.
• Pruebe la recuperación desde la copia de seguridad en un dispositivo limpio.
• Separe los saldos operativos y de reserva.
• Vuelva a verificar las direcciones después de cualquier actualización del software de la wallet.